Set up OPSLOG Archive daily as well as after nnnnnn events

Products

• OPS/MVS Event Management & Automation

Issue/Introduction

We would like to set up the OPSLOG Archive to trigger daily at a specific time and also have the ability to archive in the event of a message flood (e.g after nnnnnn events). 

The ARCHIVETRIGGER parameter appears to only accept one or the other options.

A solution we were looking to use is -

1. Using the manual archive method outlined in the documentation (sample JCL CCLXCNTL(ARCHCRTE) to trigger on a TOD.RULE e.g at midnight. This would handle the normal day to day archiving and archive the log daily at midnight.

2. We also set up the automated process with ARCHIVETRIGGER using nnnnnn, ie the number of messages as an emergency method if we get a flood of messages.

This appears to work and archives are taken. The issue we have observed is that the archive tracking using option 1, the manual method is not working. The global ARCHIVETRACKBASE (set to the default value) is not getting updated. The GDG archive is then not available in the OPSVIEW OPSLOG tracking panel. We only see the archive produced from option 2 (using the ARCHIVETRIGGER=nnnnnn).

 

Environment

OPS/MVS R14.0

Cause

New OPS/MVS user wanting to know how to Archive their OPSLOG data.

Resolution

There are a couple solutions to how you wish to have OPSLOG archives work in your environment.  A bit of background first - the new OPSLOG archive method was designed to prefer the archiving of OPSLOG records based on number of events as this insures no loss of OPSLOG data.  The ARCHCRTE JCL for OPSLOG archiving is a 'scaled-down' or quick method archive, as if you noticed that JCL does not invoke the ARCHNTRK OPS/REXX exec, which does the work of gathering parameter values AND updating the Archive tracking facility of the recent archive. 

1) Set and keep the ArchiveTrigger as a number of events.  Set up a TOD rule for the desired 'organized' archive, issue the S archprocvalue command passing the needed parm values of SSID, Current_LOGNAME, number of tracks needed to store the OPSLOG records in Primary and Secondary format.  These values can be observed in OPSLOG if you set the DebugArch parameter to ON / YES. This will require some logic in the TOD rule to obtain the current in use OPSLOG Logname. The TRACK parm values will also not be accurate, the new method calculates these based on the number of events being archived.  If you use the TRACK values from the largest of your recent archives, you should be ok, but there is still a very small 'hole' here where you may not specify enough of the needed DASD tracks to accommodate a larger than normal day of OPSLOG records.  This method uses the ArchiveTrigger value as a preventive to any loss of OPSLOG data, rather than the main method for OPSLOG archiving.

2) Set the ArchiveTrigger value to the number of events to archive. Create a TOD rule to fire a minute to two before the time that you wish to have a daily archive begin.  This TOD rule will update the ArchiveTrigger value to the TOD value that you wish to have a daily archive, then this TOD rule will need to issue the 'F OPSS,RESTART(ARCH)' command to restart the Archive subtask within OPS/MVS to recognize the new ArchiveTrigger value.  This process of updating the ArchiveTrigger value and restarting the ARCH subtask will need to be done again once the archive is complete to insure that the trigger is set back to the number of events that insures no loss of OPSLOG data.

Additional Information

Archiving and Merging OPSLOG data - refer for further information