Title : Area Recovery after IMS Abend during /STO AREA processing Submitter : Frank Fleming Barclays Computer Operations Radbroke Hall Knutsford Cheshire WA16 9EU Phone : 0565-621000 ext 3581 Release Submitter Details - Y Text :- If IMS abends between a /STO AREA command being entered and the X'5922' (area closed) log record being written then the area is in an uncertain state and IMS emergency restart (ERE) is not sure what to do with the area and hence marks it 'Recovery Needed' in DBRC and stops the area within IMS. The processing involved for a /STO AREA command is as follows :- (0.) DMAC & current SDEP CI logged at system checkpoint 1. /STO AREA command logged in X'02' record 2. DMAC contents logged in X'5957' record 3. OTHREADs scheduled for DMAC & SDEP CI writes 4. X'5923' Area status change log record written 5. Wait for OTHREAD completion 6. X'5922' Area closed log record written In the our environment the /STO AREA is issued by a command issuing BMP which 'front ends' daily image copy jobs. This step may abend U0002 due to the IMS abend or processing may continue at the next step (either a short analyse or the IC itself) which may fail due to VSAM SHROPTNS or DBRC (as SHARECTL is in use and AREA is still authorised to IMS). When the IC job is resubmitted (after the ERE has marked the area as recovery needed) the /STO AREA step completes OK (area already stopped) and the short analyse step may find an out of date DMAC (SDEP pointer errors etc) and abend or the IC step will fail due to the recovery needed setting in DBRC If the IMS abend was after point 5 but before 6 then the area would not need recovery (assuming the analyse completed sucessfully) but merely marking as OK within DBRC :- CHANGE.DBDS DBD(xxxxxxxx) AREA(yyyyyyyy) NORECOV and CHANGE.ADS DBD(xxxxxxxx) ADS(yyyyyyyy) ADDN(zzzzzzzz) AVAIL for each ADS However, if the IMS abend was before point 5 (DMAC not written and hence analyse failed) then the area will need to be recovered. In the case of an area being stopped to take an image copy and (in our case) the logs are not change accumulated (due to the use of MADS instead) a whole day's logs are required (typically 80 3480 cassettes in our environment) for the recovery and this takes about 8 hours to run. This constitutes a major loss of availability. Note also, that once the recovery is completed the MADS create utility still needs to be run in order to recreate the MADS environment where applicable. In discussing this problem with colleagues it was suggested that BMC Trimar Fast Recovery Utility (FRU) may be able to assist and testing has shown this to be the case. FRU (which is normally used to recover all DEDB areas during an enforced cold start) takes in IMS log(s) (normally the OLDS closed by DFSULTR0 or the failed ERE attempt) plus a system checkpoint ID (normally taken from the RDS) and produces a file of all DEDB updates after that checkpoint. This file is then sorted and input into a second step which applies the changes to all areas in a single pass of the data. In the scenario relating to our problem the log input to the first step (program TSSAFR1) would be the OLDS closed by the ERE (or the SLDS to which it was archived) and a checkpoint ID selected from that log (supplied on a control card as the IMS Restart Dataset cannot be used as it is now in use by IMS). Note that the checkpoint ID could be specified as 99999/999999 to force TSSAFR1 to select the first checkpoint on that log. The input card should look something like :- CTL IMSID=aaaa,DEDB=01,MSDB=NO,DBRC=NO,RDS=NO,CHKPT=99999/999999 The file output from TSSAFR1 and input to the second stage (TSSAFR2) should be filtered to produce updates for the AREA of interest by supplying a utility control card to TSSAFR2 specifying a start/stop DBD and Area. START=(xxxxxxxx,yyyyyyyy),STOP=(xxxxxxxx,yyyyyyyy) Note that FRU applies any updates found to all ADS for an area so there is no need to run ADS create. The final step of the procedure is to mark the area and all of it's ADSs as available by using the DBRC commands shown above.