BACKUP LINKS
Whenever and element (COBOL, TELON, LINKCARD) is moved to Endevor stage 2 through a package, backups are done automatically by the move processor attached to the element. The backups are done as follows:
ELEMENT BACKUPS TAKEN
Batch non-DB2 (standalone link) LOAD
Batch DB2 (standalone link) DBRM, LOAD
Online non-DB2 no backup taken
Online DB2 DBRM
Online Link LOAD
The backups are made from the previous version of the member in the production library as follows:
PRODUCTION LIBRARY BACKUP LIBRARY
PROD.OT.END.LOADLIB PROD.OT.END.LOADLIB.BACKUP
PROD.OT.END.IMSLOAD PROD.OT.END.IMSLOAD.BACKUP
PROD.OT.END.DBRMLIB PROD.OT.END.DBRMLIB.BACKUP
XV. RESTORING PRODUCTION LOAD MODULES FROM BACK-UP
IT IS VERY IMPORTANT THAT YOU NOTIFY YOUR PROJECT LEADER AND/OR A MEMBER OF THE TECHNICAL TEAM BEFORE ATTEMPTING TO RESTORE FROM BACK-UP. THEY WILL BE ABLE TO ASSIST YOU AND MAKE SURE THAT A RESTORE IS NEEDED. ALWAYS CONSULT YOUR ANALYST AND/OR THE TECHNICAL TEAM BEFORE RESTORING FROM BACK-UP. THE SYSTEM MANAGER SHOULD ALSO BE NOTIFIED.
At this point, our backout procedures are still manual. We have looked into the Endevor backout, however, it only works if you are backing out your changes the same day you put them in and the elements are sitting in the stage 2 libraries. Once they have been moved to the production libraries, the Endevor backout does not work.
If your restore is not an emergency, you do not have to run the special jobs described below to copy the members from the backup libraries to the production libraries. In this case, you may simply follow the cleanup procedures outlined in step 6 to recompile/relink/move to stage 2.
NOTE: If an MFS change had been made you cannot use these procedures to restore from back-up. You will have to get together with your project leader and work out a solution.
1. Before attempting restore, it may be a good idea to save a copy of the existing production module. This will allow you to return to it if the module was needlessly restored.
2. Find the back-up files you have to restore. The back-up files are in the libraries:
PROD.OT.END.IMSLOAD.BACKUP
PROD.OT.END.LOADLIB.BACKUP
PROD.OT.END.DBRMLIB.BACKUP
NOTES:
All our systems, ACES, URS, Subro, FRACS, and Notes are backed up to these "OT" libraries.
The load modules that are copied to both the batch and online load library by the processor CIANBL47 are backed up only to PROD.OT.END.LOADLIB.BACKUP.
3. You will submit special jobs in order to copy the backed up members to the production libraries. There are jobsysin members (outside of Endevor) that you must update with the members you wish to restore.
The procs are in SYS1.PRODPROC; the jobsysins are in SYS1.JOBSYSIN; the jobs are in OTXX94.SPECIAL.JOBS. The names are as follows:
OTBKOLLD - Edit this jobsysin and run this job to restore online load modules.
OTBKBCLD - Edit this jobsysin and run this job to restore batch load modules.
OTBKDBRM - Edit this jobsysin and run this job to restore dbrms.
Once the job(s) run, check the newly copied members in the production libraries.
Remember that the new online modules will not appear until the LLA has been refreshed. See step 5 below.
4. A special bind job will have to be run if the module you are restoring has DB2 in it. You must copy the production binddeck to the dataset PROD.OT.PRODBIND. Be sure your entry is the only entry in the prodbind dataset. If it is not you will have to copy the other(s) to another dataset, run your special bind and then replace the previous entries after you run this special bind. The JCL to run this bind can be found in OTXX94.SYSG.DB2.CNTL(BIND). (The only thing that may need to be changed in this JCL is possibly the job name on the jobcard and the notify. It needs to run on G). Check the control cards before submitting the job. Check the job once it ends. The production binddecks for our systems are in the following libraries:
ACES - PROD.OT.END.BINDDECK
SUBRO - PROD.SU.END.BINDDECK Mudetail, Notes and URS have no DB2.
FRACS - PROD.FS.END.BINDDECK
ALF - PROD.OJ.LF.END.BINDDECK
NOTE: There is a timing issue between the bind and region refresh. If the new bind is done and the region refresh is not done right away, the load module will be out of sync with the application plan(s) and a -818 may occur. Similarly, if the region refresh is done and the bind is not done right away, the application plan(s) will be out of sync with the new load module and a -818 may occur.
5. For online restores call the TP room and have the production region refreshed and also an LLA refresh if the load library is under LLA control. You can check for LLA control by issuing a LISTQ command on system G against the PROD.OT.END.IMSLOAD library. If it is under LLA control the LISTQ will tell you that the library is in use by LLA.
The production regions are:
APPLICATIONS W/ TRANSACTIONS
SYSTEM EXECUTING IN REGION REGION
SYSTEM A ACES/FRACS/URS IMCLIFE1
IMCLIFE2
IMCLIFE3
SYSTEM G ACES/SUBRO/ADD CLAIM/NOTES/ALF/MUDETAIL
IF ANY OF THESE SYSTEMS REQUIRE A REGION REFRESH, REQUEST ALL OF SYSTEM G TO BE REFRESHED.
6. Cleanup - you may follow the procedures outlined above to quickly restore your systems to their previous state. However, it is important that all the pieces are in sync. It is important that we do not leave the "bad" source as the latest level in Endevor. As part of the cleanup, you should retrieve the previous version of source that you want to restore and add it back to Endevor using the procedures outlined in section V. This will create a new level of the element reflecting what is currently in production. If the element is associated with a link group, you must also re-link using the procedures outlined in section VII for linking an existing linkcard. You will then move the source and linkcard element(s) to stage 2 via a package.
Custom Search
