Here's a tip that may help avoid a "missing data" condition on a MICS audit archive file.
Remember, the audit archive file contains a previous week time-frame of a particular file stored in a single GDG generation on tape. This type of file is useful for more detailed, audit-type analysis where either DETAIL or DAYS-level (if DETAIL is inactive) MICS file information is to be used but there is insufficient cycles online to perform the analysis. Activating audit archive must be planned in advance, if a desired file has been identified as being useful beyond the normal DETAIL cycle retention limit; some MICS files are shipped active in Audit Archive but there is also a JCLDEF option to control an entire unit data base regards to capturing Audit Archive. One example of using this type of file would be a historical analysis back several weeks analyzing the MICS BATSPL file to determine what percent of jobs are generating output in "1-Up" format where the capacity of a capable laser-type printer could be extended if more users took advantage of multiple impressions per physical page such as "2-Up." Of course, it could be asked why paper output is even being generated at all ... but that's another discussion.
For this discussion, MICS requires that there be sufficient DETAIL (or DAYS) cycles available online when the WEEKLY/WEEK300 (presuming the separate AUDIT/HISTW/HISTM operational jobs are not used) process runs to capture the prior week's data but only if the information is contained in cycles 10 through 01, meaning from the past 10 DAILY update cycles. By the way, any observations from the current week are discarded during the WEEK300 archive creation process to help ensure that only prior week data is captured on the new generation. The potential exposure is when there are insufficient DETAIL (or DAYS) cycle retention limits defined in prefix.PARMS(DBMODEL) for any MICS files activated for Audit Archive.
Consider, the CYCLEGEN process and the WEEK300 process will generate NO warning message. The only symptom observed will be when you go to access a particular audit archive file generation and there are one or more days missing, normally that being a Sunday or possibly Monday of the collected week. Also note that more than just the prior week's data will be saved in the new archive generation, up to the maximum of cycle 10. Given this condition, any reporting that uses or crosses multiple audit archive generations must consider that duplicate observation may be found in two consecutive generations and must be removed at reporting time to ensure accuracy.
The amount of MICS database-cycle data captured (or possibly lost) on an audit archive generation is directly affected by the DBMODEL DETAIL (or DAYS, if DETAIL is inactive) retention limit along with when the WEEKLY job is scheduled for a unit data base. If there are 8 DAILY updates in a period before a WEEKLY update occurs say Sunday night (into Monday AM), the minimum DETAIL (or DAYS) cycle retention limit necessary for a complete Audit Archive generation is 08. But, for example, say the WEEKLY job is run on Monday night (into Tuesday AM) after the 9th DAILY update since the start of the PRIOR week, the cycle retention limit must be 09 to capture a complete prior week of data in cycles 09 through 03, viewing the cycles chronologically. That is why the default setting for most MICS files is 10, those that are set with Audit Archive active in the sp.GENLIB(cccGENIN) member. This condition provides upwards of 10 DAILY cycles before the next WEEKLY cycle.
So, verify that your DBMODEL cycle retention limits are sufficient to handle the maximum number of DAILY update cycles between WEEKLY cycles, if you have AUDIT ARCHIVE activated in prefix.PARMS(JCLDEF). Also, remember that the most recent generation of an audit archive file will NOT have data from the current week; any reporting on the current week will need to be done using the online time-span cycles. Lastly, beware that audit archive files can have duplicate observations across generations because the audit archive creation process captures up to 10 cycles, if available, while only deleting observations from the current week. Any MICS AUDIT reporting effort will need to ensure that a PROC SORT NODUP is performed (using a discrete BY list) in order to remove the duplicates and avoid inaccurate reporting.
As well, MICS sites may want to explore running a separate AUDIT jobstream more than once weekly - a feature that was added to MICS several years ago. Also, another feature available is the ability to override the number of cycles captured by AUDIT (defaults to 10 to accommodate a delayed WEEKLY processing) - that is the AUDITCYC option in prefix.MICS.PARMS(SITE).
Scott Barry
SBBWorks, Inc.