IMS RECOVERY-When IC Entry removed from DBRC

Problem: There was required to Recovery set databases in an application. Found couple of Databases IC needed for recovery is removed from DBRC. As the Application team have run a NOTIFY.UIC JOB twice wrongly. Even though the GENMAX was set 16, because this problem the required IC was entry was missing.

For example below is one such entry:

NOTIFY.UIC DBD(DBDNAME) DDN(DDNNAME)-
UDATA('RE-INITIALIZE DB, NO IC IS REQUIRED')
DSP0203I COMMAND COMPLETED WITH CONDITION CODE 00
DSP0220I COMMAND COMPLETION TIME 09.088 04:55:00.9

If we issue a NOTIFY.UIC, one entry is getting added to the RECON dataset and oldest entry gets purged. This is the reason for missing IC entry for the required date.

Solution: Inserting/Notifying DBRC about Image Copy

Only if DBRC entry is available IMS will allow recovery. The approach was to remove the oldest entry available and Notify using the following Job, NOTIFY.IC was issued with time stamp from Image copy sysout.

//RCNLST EXEC PGM=DSPURX00
//STEPLIB DD DSN=IMSVS.CA.DBO.RESLIB,DISP=SHR
// DD DSN=IMSSYS.RESLIB,DISP=SHR
// DD DSN=IMSSYS.USER.RESLIB,DISP=SHR
//DFSRESLB DD DSN=IMSSYS.RESLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD *
LIST.DB DBD(DBDNAME) DBDS
DELETE.IC DBD(DBDNAME) DDN(DDNNAME) RECTIME(090822101379)
LIST.DB DBD(DBDNAME) DBDS
NOTIFY.IC DBD(DBDNAME) DDN(DDNNAME) ICDSN(IC.DATASET.NAME) RUNTIME(090801601562) -
FILESEQ(0004) BATCH UNIT(TAPEC) VOLLIST(B00878)
LIST.DB DBD(DBDNAME) DBDS

/*
//

After completion of NOTIFY.IC we ran the Restore job but it failed with :

DFS391I S DBDNAME DDNNAME 090801601562-0400
E N D O F S Y S I N C O N T R O L C A R D S
DFS391I **RECOVER DATA BASE DBDNAME DDNAME DDNNAME
DSP0822I RECOVERY REQUESTED TO TIMESTAMP 09.080 16:01:56.2
DSP0822I DBD=DBDNAME DDN=DDNNAME
DFS2804A HEADER RECORD ON DDNAME DFSUDUMP IS NOT CONSISTENT WITH DBPCB FOR FUNCTION RV
DFS339I FUNCTION RV HAS COMPLETED ABNORMALLY RC=08
************************** Bottom of Data ****************************


To fix this problem Ran IEBGENER to copy the Image copy from TAPE to DASD and HEX ON and found timestamp of the Image Copy. Time stamp was found to be 090801601549. So Delete the existing entry of the image copy and Issued NOTIFY.IC with correct Timestamp.



Below is HEX ON of ImageCopy dataset:
-----------------------------------------------------
.D..DBDNAMEDDNNAME......èpâo._DBDNAME.Y.Y.Y.Y......
0C00CEECCCDECEEDCCDE200020594906CEEDCCDE1E1E1E1E020000
54004321413863274138098F0147261D63274138787878780B0560
-----------------------------------------------------


After making appropriate entry in RECON ran the RESTORE job and recovered the Database.

TIMESTAMP -Calculation Useful Info

TIMESTAMP CONVERSIONS AND EXAMPLES

Assume that local time is PST, offset -08:00
(Offset is always added to UTC to obtain local time.
to obtain UTC from local time, reverse the sign and add.)

An event occuring at:
1998.030 10:00:00.1 -08:00 (punctuated format)
yyyy ddd hh mm ss t
or:
980301000001 -0800 (compressed format)
yydddhhmmsst

is recorded in 12 hex bytes as:
--------------------------------
|1998030F | 18000012 | 3456032D|
--------------------------------
yyyyddd hhmmsstx xxxxfqqs

hh = UTC, 8 hours later than local
x xxxx = low-order time digits ignored by DBRC and you
fqqs = offset:
f = flag bits, normally 0
qq = quarter hours (32 / 4 = 8)
s = sign (D is negative, C is positive)

Given a record identified by a time (such as a PRILOG):

Listed time entered as:
Finds recorded time:
'1998.030 10:00:00.1 -08:00' 1998030F 18000012 3456032D

(Note that DBRC ignores the low-order time digits and the
offset when searching - only the UTC date and time are
significant).

If you supply NO OFFSET, DBRC uses the TIMEZIN value,
which may not be correct.

With the wrong offset:
DBRC looks for the wrong time
'1998.030 16:00:00.1 -02:00' 1998030F 18000012 3456008D

This means that time stamps from different RECON listings,
even with time stamps displayed in different formats, can
be used freely, SO LONG AS THE OFFSETS ARE INCLUDED.