This article is aimed at somebody with advanced SAS skills, it will discuss two ways to recover from an abend in aging: restore the data base or use PROC DATASETS to determine which files had not been aged and manually age them.
Of course, the first thing you must do in the event on any abend is to identify what the abend is. To do this, you should reference section 4.3.11 of the Planning, Installation, Operation, and Maintenance guide (PIOM). An abend in aging is identified by a user abend code of 101. This means that the data base is marked non-updatable and that aging was in progress when the failure occurred.
The Corrective Action in the PIOM asks that you contact MICS Product Support with the following: The SAS log for the abended run and PROC DATASETS reports for the DETAIL, DAYS, WEEKS, MONTHS, and YEARS files. We ask this for a specific reason. When an abend in aging occurs, you essentially have two options. One is to RESTORE the data base and RERUN the current DAILY process from the beginning. The second is to manually age the files enabling you to RESTART in the next step of the jobstream.
The RESTORE and RERUN is generally the easier of the two, assuming you run BACKUP processing frequently. However, manually aging the files is an option. Based on the output from the SAS log and the PROC DATASETS reports, you can determine which files were aged. Next, you will construct a job to "pick up" where the aging process left off.
The job will be as follows:
//** Put Your JOBCARD Here **
//stepname EXEC MICSDBx
//mysource DD DISP=SHR,DSN=your.dataset.name
//SYSIN DD *
The 'mysource' dataset will contain your changes to complete the aging process. The 'stepname' should be the name of the MICS step (for example, DAY030) and 'ccc' refers to the product identifier. Copy prefix.MICS.USER.SOURCE($cccCYCS) into your dataset. Find the age statements that have executed and delete them (see NOTE1). Then, copy sharedprefix.MICS.SOURCE(DYcccAGE) into your dataset and delete the statements that have fully executed (see NOTE1).
Finding the AGE statements that have executed and deleting them will be the most difficult task. In addition, this should only be attempted by a person quite familiar with SAS. First, you will need the PROC DATASETS reports for the DETAIL, DAYS, WEEKS, MONTHS, and YEARS files. From these, you should be able to determine which files have aged. For example, if the aging abend occurred in DAY030 (SMF) and on the BATJOBnn files, then you would do the following:
- Create your own jobstream as above
- Copy prefix.MICS.USER.SOURCE($SMFCYCS) into your dataset
- Determine if the abend occurred in the DETAIL or DAYS files. You should see a break in the cycles pattern, or files not renamed, or you may still have a 00 cycle in the DETAIL time span.
- Suppose the DETAIL BATJOBnn files were the last aged, then you would find these AGE statements in the BATCYDT macro and delete the AGE statement for BATJOB as well as the previous AGE statements in the macro.
- Copy sharedprefix.MICS.SOURCE(DYSMFAGE) into your dataset
- Delete all statements prior to PROC DATASETS execution which calls macro BATCYDT.
- You should be ready to execute your job.
- Following successful execution, restart the original MICS process in the next step.
- The above steps are merely an example. Your situation could be quite different. What happens if the files do not reflect the fact that an abend in aging occurred? How do you know if aging started after the flag was set or if aging was completed and the flag was not cleared? If the PROC DATASETS reports do not show anything definite, you will need to do a PROC CONTENTS and examine the dates when the files were created. That will give you the answer.
- Do you take a BACKUP as part of your RESTORE job? If your RESTORE job has backup processing before the restore, then you will need to change the prefix.MICS.CHECKPT.DATA file flags to permit the job to run.
- The final point is that the RESTORE and then rerunning the job is the safest option available. Should you attempt the manual aging, you should consider doing a BACKUP before beginning and proceed with extreme caution. This should not be attempted unless the person is quite familiar with SAS and especially PROC DATASETS.