View - Virtual tape damaged. Reports inaccessible.
Article ID: 233622
Updated On:
Products
Issue/Introduction
Reports from the "BD.VP $ VW.ARC0003A" database are inaccessible. Our analysis confirms an accidental rewrite of the virtual tape (KA0SWS)!
A copy of the lost reports are in the mirror database "BS.VP $ VW.ARC0003B".
What is the procedure to restore lost reports from the mirror database?
Attachments :
- Joblog from STC VIEW database ,
- SARPAC log file on virtual tape KA0SWS ,
- SARTSLST log file on virtual tape KA0SWS ,
- SARPAC tapemap log file virtual tape KA0SWS.
Environment
Release : 12.2
Component : View
Resolution
To recover the lost reports from another database/tape, the client was given this procedure:
. As none of the reports can be recalled from the nominal (PROD) database tape BD.VP$VW.ARC0003A.SARTAPE.T0001724, run the SARTSLST job, creating a //CTLCARDS file.
Run the CTLCARDS file through program SARBCH, which will remove the report entries from the index of the original database.
At the next View backup, View will expire the T0001724 tape.
. From a review of the SARTSLSTs of the PROD tape T0001724 and mirror tapes T0001778
and T0001779:
. . Tape T0001724 shows to have 2530 active reports.
. . Tapes T0001778 and T0001779 show to have the same 2530 active reports.
==> From those tapes have been created the following files:
. . Files of SARBCH /LOAD transactions, to load reports to the mirror database disk layer:
. . . File 1: SARBCH /LOAD transactions, from mirror generation 2738, that correspond to nominal database generation 2395.
. . . File 2: SARBCH /LOAD transactions, from mirror generation 2738, that correspond to nominal database generation 2396.
. . . File 3: SARBCH /LOAD transactions, from mirror generation 2738, that correspond to nominal database generation 2397.
. . Files of SARDBASE Selective UNLOAD transactions, to extract reports from the mirror database disk layer:
. . . File 1: UNLOAD transactions, from mirror generation 2738, that correspond to nominal database generation 2395.
. . . File 2: UNLOAD transactions, from mirror generation 2738, that correspond to nominal database generation 2396.
. . . File 3: UNLOAD transactions, from mirror generation 2738, that correspond to nominal database generation 2397.
==> Here is what will happen in each of the 3 instances:
. . Run SARBCH /LOAD transactions, to bring reports to the mirror database disk layer:
//XXXXXXXX JOB ...
//SARBCH EXEC PGM=SARBCH,PARM='VIEW_HLQ' <=== MODIFY DB NAME
//STEPLIB DD DISP=SHR,DSN=VIEW.CVDELOAD <=== MODIFY, IF USED
//SYSPRINT DD SYSOUT=*
//REPORT DD SYSOUT=*
//SYSIN DD DISP=SHR,DSN=load.file_n <=== Modify /LOAD file name
//
==> Tasks against the mirror database will need to be brought down.
. . Run SARDBASE UNLOAD, on the mirror database, with the UNLOAD transactions, to a tape:
//XXXXXXXX JOB ...
//SARDBASE EXEC PGM=SARDBASE,PARM='VIEW_HLQ' <=== MODIFY DB NAME
//STEPLIB DD DISP=SHR,DSN=VIEW.CVDELOAD <=== MODIFY, IF USED
//SYSPRINT DD SYSOUT=*
//*******************************************
//* USE THE FOLLOWING SARUNLTB STATEMENT *
//* TO DO A "SELECTIVE" UNLOAD *
//*******************************************
//SARUNLTB DD DISP=SHR,DSN=unload.file_n <=== Modify, UNLOAD table file name
//SARUNLD DD DISP=(,CATLG,DELETE),
// DSN=XXXXXX.XXXXXX.SARUNLDn,
// DCB=(RECFM=VB,LRECL=32756,BLKSIZE=32760),
// UNIT=tape,LABEL=(1,SL)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
UNLOAD
/*
//
==> Tasks against the mirror database can be brought back up.
==> Run the REXX program, to create another UNLOAD file.
. . . For the first run, in the FIXGCRG REXX program, have:
. . . . fgen = 2738
. . . . tgen = 2395
. . . For the second run, in the FIXGCRG REXX program, have:
. . . . fgen = 2738
. . . . tgen = 2396
. . . For the third run, in the FIXGCRG REXX program, have:
. . . . fgen = 2738
. . . . tgen = 2397
. . . Here is the JCL to run the FISGCRG REXX program:
//FIXUNLD JOB ...
//$$$$$$@ EXEC PGM=IRXJCL,PARM='FIXGCRG'
//SYSEXEC DD DSN=YOUR.REXX.LIBRARY,DISP=SHR <=== Modify REXX library name
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
//SYSUDUMP DD SYSOUT=*
//INDD DD DSN=XXXXXX.XXXXXX.SARUNLDn,
// DISP=SHR
//OUTDD DD DSN=YOUR.NEW.UNLOAD.DSN,
// DISP=(,CATLG),UNIT=SYSDA,
// SPACE=(CYL,(500,50),RLSE),
// DCB=(RECFM=VB,LRECL=32756,BLKSIZE=32760)
==> Ensure that the REXX altered the generation number correctly prior to loading.
. . Find a report (GCR) record, which has:
. . . Positions 1-32: Sysout ID
. . . Positions 33-34: Generation number (in hex)
. . . . Generation 2395 has a hex value of x'095B'
. . . . Generation 2396 has a hex value of x'095C'
. . . . Generation 2397 has a hex value of x'095D'
==> Tasks against the PROD database will need to be brought down.
==> Perform a backup of the PROD database. This can be accomplished with the
DFDSS or FDR utilities, or can be run using SARDBASE UNLOAD.
==> Run the below SARDBASE LOAD job, to load reports to the disk layer of the PROD database:
//XXXXXXXX JOB ...
//SARDBASE EXEC PGM=SARDBASE,PARM='VIEW_HLQ' <=== MODIFY DB NAME
//STEPLIB DD DISP=SHR,DSN=VIEW.CVDELOAD <=== MODIFY, IF USED
//SYSPRINT DD SYSOUT=*
//SARLOAD DD DISP=SHR,DSN=YOUR.NEW.UNLOAD.DSN
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LOAD
/*
//
==> Tasks against the nominal database can be brought back up.
Note: Please ensure that there is sufficient disk space on both the PROD and mirror databases, for the SARBCH /LOAD step and the REXX program step.
Feedback
