Archiving and Merging OPSLOG Data

OPSLOG archive is the OPS/MVS facility for automating the archival of OPSLOG data.
coema123
Your OPSLOG can be archived on demand using a manual process or periodically using an automated process. Both processes are described in the following sections.
Automated OPSLOG Archive Process
OPSLOG archive is the 
CA OPS/MVS
 facility for automating the archival of OPSLOG data.
OPSLOG archive lets you schedule the routine archiving of OPSLOG data by adjusting parameters. Once these parameters have been set, 
CA OPS/MVS
 automatically archives OPSLOG entries at intervals that the parameter settings determine. Automatic archival requires no further work by the systems manager or operators.
You can schedule the OPSLOG archive to perform the archive routine through the ARCHIVETRIGGER parameter with the following triggers:
  • A specific time of day
  • The accumulation of a specific number of messages
Once invoked, the archive facility writes all OPSLOG entries that have accumulated since the last archive operation to a designated data set. The archive facility consists of a supplied started task that is started internally once an ARCHIVETRIGGER value is reached. The started task is passed information such as the OPSLOG logname and the required size to contain the archive data and runs a supplied OPS/REXX program to gather customized parameter values. The supplied REXX program initiates the copying of OPSLOG data and updates the archive tracking facility for retrieval of the archived data. The archive facility uses OPS/MVS global variables, with the prefix of GLOBAL0, to store tracking data.  You must enable the supplied OPS/MVS Security rule to allow the started task access to perform these steps.  
How to Set up the OPSLOG Archive Facility
Use this procedure to set up the OPSLOG Archive Facility:
  1. Copy the supplied started task (STC) JCL PROC located in member ARCHPROC of the installed
    hlq.
    CCLXCNTL data set to a valid system procedure library (PROCLIB). Update this deployed copy of the STC PROC with a valid JOB card and data set names as indicated in the supplied JCL.
    Your customized archive STC PROC is deployed.
  2. Update the ARCHIVEPROC parameter with the member name of your deployed STC PROC.
    The ARCHIVEPROC parameter is set.
  3. Create the Generation Data Group (GDG) base, with the desired number of generations to be kept, and the model dataset. A sample job to do this is provided in member ARCHGDG of the installed
    hlq.
    CCLXCNTL(ARCHGDG) data set.
    Any pre-existing OPSLOG archive GDG base and model data sets can be used in place of creating new ones.
    The OPSLOG archive GDG base and model data sets are established.
  4. Update the ARCHIVEHLQ parameter with the name of the GDG base and the ARCHIVEMODEL parameter with the name of the GDG model data set.
    The ARCHIVEHLQ and ARCHIVEMODEL parameters are set.
  5. Choose a desired trigger method to initiate the OPSLOG archive process and update the ARCHIVETRIGGER parameter with the appropriate value. The ARCHIVETRIGGER parameter accepts two types of trigger values:
    • hh:mm
      A Time-of-Day value that causes the archive process to be initiated once daily at the specified TOD.
    • nnnnnnn
      A numeric value that indicates a number of OPSLOG entries/events. This is an interval value. The archive process is initiated after every
      nnnnnnn
      OPSLOG entries/events has occurred.
  6. (Optional) Update the ARCHIVETRACKBASE parameter with the OPS/REXX global variable stem that is used for OPSLOG archive tracking entries. The default value is 'GLOBAL0.ARCH_TRACK.'.
    The ARCHIVETRACKBASE parameter is set.
  7. If you are not using
    CA OPS/MVS
    External Security (that is, the EXTSECURITY parameter is set to OFF), copy the supplied AOF security rule located in member ARCHSECA of the installed
    hlq.
    CCLXRULB data set to a valid AOF ruleset. If you have a dedicated security ruleset, copy ARCHSECA into that ruleset.
    The ARCHSECA security rule is deployed.
  8. If you are not using
    CA OPS/MVS
    External Security (that is, the EXTSECURITY parameter is set to OFF), enable and auto-enable your deployed copy of the ARCHSECA rule.
    The ARCHSECA rule is enabled and auto-enabled.
  9. If you are using
    CA OPS/MVS
    External Security (that is, the EXTSECURITY parameter is set to ON), update your External Security Manager (ESM) rules for the following
    CA OPS/MVS
    security event resources to permit access by the userid assigned to the archive STC, where
    OP$MVS
    is the value of the EXTSECPREFIX parameter.
    • UPDATE access to resource
      OP$MVS
      .OPSPARM
    • READ access to resource
      OP$MVS
      OPSLOG
    • UPDATE access to resource
      OP$MVS
      OPSGLOBAL.
      stem
      Where
      stem
      is the value of the ARCHIVETRACKBASE parameter.
    Your ESM rules are updated.
OPSLOG Archive Parameters
The following 
CA OPS/MVS
 parameters control how the OPSLOG archive system works:
  • ARCHIVEHLQ
    Specifies the dataset name for the Generation Data Group (GDG) base that contains the archived OPSLOG data. The maximum length of the parameter is 35 characters.
    Limits:
     1-35 characters
    The value of the ARCHIVEHLQ parameter is expected to be the name of a GDG. You cannot change the HLQ while
    CA OPS/MVS
    is running and must restart
    CA OPS/MVS
    to change the HLQ. However, you can restart the subtask to accommodate other new parameter values by entering the following command:
    F OPS
    x
    ,RESTART(ARCH)
  • ARCHIVEMODEL
    Specifies the Generation Data Group (GDG) model dataset name.
    Limits: 
    1-44 characters
  • ARCHIVEPROC
    Specifies the name of the archive procedure JCL that resides in a valid proclib.
  • ARCHIVESTORCLAS
    (Optional) Specifies the allocation of the storage class.
  • ARCHIVETRACKBASE
    Specifies the OPS/REXX global variable stem that is used for OPSLOG archive tracking entries.
  • ARCHIVETRIGGER
    Controls the triggering of the OPSLOG archive, which is based on number of messages and time of day.
  • ARCHIVEUNIT
    (Optional) Specifies a default unit type for the OPSLOG archive.
  • ARCHIVEVOLSER
    (Optional) Specifies the allocation of the volume serial.
  • BROWSELASTARCH
    Display-only parameter that contains the OPSLOG message sequence number of the last message that was successfully archived.
  • BROWSEARCHNEEDED
    Display-only parameter that contains the OPSLOG message sequence number of the message that caused the OPS4403O message to be issued in order to start an OPSLOG archive process.
  • DEBUGARCH
    Debugs the archival process. To generate archival-related trace messages, set the DEBUGARCH parameter to ON.
  • INITARCH (YES/NO)
    Initiates the startup and shutdown of the ARCH subtask that controls the archival process.
    Default:
     NO
    You can stop the archival process by setting the INITARCH parameter to NO. If you restart the ARCH subtask after setting the INITARCH parameter to NO, the subtask terminates immediately. If no restart is invoked, the last archive is finished and the subtask terminates automatically. In both cases, there is no need to restart
    CA OPS/MVS
    .
Manual OPSLOG Archive Process
Sample batch JCL is provided in member ARCHCRTE of the installed
hlq
.CCLXCNTL data set for manually archiving OPSLOG on-demand. The ARCHCRTE job runs program OPARLGGE. This section describes the syntax and keywords of the ARCHIVE control statement required by OPARLGGE.
As an alternative to manually coding JCL in the ARCHCRTE sample job, you may want to use OPSVIEW option 7.1.2 to manually archive OPSLOG.
Syntax
The ARCHIVE control statement for the OPARLGGE program is placed in the SYSIN of the ARCHCRTE job. The control statement has the following format:
ARCHIVE
keyword1 … keywordN
/* Keywords */ {DSNAME(
dsn
)} [GDGNUM(
rel#
)] [GDGMODEL(
modelname
)] [VOLUMES(
volser1,volser2,…,volser6
)] [UPDATE(YES|NO)] [REUSE(YES|NO)] [STORCLAS(
storageclass
)] [MGMTCLAS(
managementclass
)] [DATACLAS(
dataclass
)] [LOGNAME(
logname
)] [SUBSYS(
ssid
)] {UNIT(
unit
)} [BLKSIZE(
blocksize
)] [CYLINDERS(
primary
[
secondary
]) | TRACKS(
primary
[
secondary
]) | BLOCKS(
primary
[
secondary
])] [START(
yyyy/mm/dd hh:mm
|
nnnnnnnnnn
|AUTO)] [END(
yyyy/mm/dd hh:mm
|
nnnnnnnnnn
)] [DEBUG(YES|NO)]
Keyword Descriptions
The OPSLOG archive control statement for the OPARLGGE program accepts the following keywords:
  • DSNAME(
    dsn
    )
    Required keyword. Specifies the name of the data set that contains the OPSLOG archive, either a fully qualified data set name or a GDG. The data set is automatically created if you do not specify REUSE(YES).
  • GDGNUM(
    rel#
    )
    Specifies the relative generation number of the specified data set. The typical value is +1. You can also specify the fully qualified GDG data set name with relative generation number on the DSNAME keyword and omit this keyword. Required if the DSNAME keyword specifies a GDG base.
  • GDGMODEL(
    modelname
    )
    Specifies the name of the GDG model if the data set specified on the DSNAME keyword is a GDG base. Default is the value of the ARCHIVEMODEL parameter. Required if the DSNAME keyword specifies a GDG base and the ARCHIVEMODEL parameter is not set.
  • VOLUMES(
    volser1,volser2,…,volser6
    )
    Specifies the list of volume serial numbers on which to allocate the new OPSLOG archive data set. A maximum of six volsers can be specified. This keyword is mutually exclusive with the STORCLAS, MGMTCLAS, and DATACLAS keywords.
    Default: The z/OS system default
  • UPDATE(YES|NO)
    Controls whether the display-only BROWSELASTARCH parameter is updated with the OPSLOG message sequence number of the last OPSLOG message that was successfully archived.
    • YES
      The BROWSELASTARCH parameter is updated.
      If START(AUTO) is specified, the BROWSEARCHNEEDED parameter is also updated, and the values of BROWSELASTARCH and BROWSEARCHNEEDED will be the same if the archive completed successfully.
      If message numbers are used for the START and END keywords, the value of the BROWSELASTARCH parameter can be used as a reference for coding the START keyword for the next execution of the ARCHCRTE job.
    • NO
      The BROWSELASTARCH parameter is not updated.
    Default: NO
  • REUSE(YES|NO)
    Controls whether a new OPSLOG archive data set is allocated or an existing data set is reused.
    • YES
      An existing archive data set is reused.
    • NO
      A new archive data set is created.
      This is the required setting when the DSNAME keyword specifies a GDG base.
    Default: NO
  • STORCLAS(
    storageclass
    )
    Specifies the SMS storage class used for the allocation of a new OPSLOG archive data set. This keyword is mutually exclusive with the VOLUMES keyword.
  • MGMTCLAS(
    managementclass
    )
    Specifies the SMS management class used for the allocation of a new OPSLOG archive data set. This keyword is mutually exclusive with the VOLUMES keyword.
  • DATACLAS(
    dataclass
    )
    Specifies the SMS data class used for the allocation of a new OPSLOG archive data set. This keyword is mutually exclusive with the VOLUMES keyword.
  • LOGNAME(
    logname
    )
    Specifies the name of the source OPSLOG to be archived.
    Default: Name of the live OPSLOG
  • SUBSYS(
    ssid
    )
    Specifies the
    CA OPS/MVS
    subsystem id OPS
    x
    of the source OPSLOG to be archived.
    Default: OPSS
  • UNIT(
    unit
    )
    Required keyword. Specifies the unit name used for the allocation of a new OPSLOG archive data set. Typical value is SYSDA.
  • CYLINDERS(
    primary
    [
    secondary
    ])
    TRACKS(
    primary
    [
    secondary
    ])
    BLOCKS(
    primary
    [
    secondary
    ])
    Specifies the amount of space allocated to a new OPSLOG archive data set. The abbreviations CYLS, TRKS, and BLKS are also accepted. You can specify only one of these keywords. Use of these keywords is needed only if the new OPSLOG archive data set will reside on a DASD device. If the OPSLOG archive data set will not reside DASD (for example, on tape), omit these keywords. The keyword values can be any valid numeric value. A secondary value is not required. For a 3390 device, 1 track can store about 90 OPSLOG records.
    Default: The z/OS system default (which may not be enough to archive all the requested OPSLOG records)
  • BLKSIZE(
    blocksize
    )
    An optimal blocksize will be determined based upon the device type of the new OPSLOG archive data set. Specify this keyword only when you cannot use the system-determined blocksize.
  • START(
    yyyy/mm/dd hh:mm
    |
    nnnnnnnnnn
    |AUTO)
    Controls where in OPSLOG to start the archive. Specify one of the following values:
    • yyyy/mm/dd hh:mm
      The date and time in OPSLOG after which messages are to be archived.
    • nnnnnnnnnn
      The ten-digit OPSLOG message sequence number of the first message in OPSLOG to be archived. OPSLOG message sequence numbers are displayed in the MSGNO column of OPSLOG Browse.
    • AUTO
      The OPSLOG is archived starting from the message after the last message that was previously archived. (The OPSLOG message sequence number of the last OPSLOG message that was previously archived is stored in the BROWSELASTARCH parameter.) The most current message in OPSLOG is the last message archived.
      The END keyword is ignored and is not required.
      It is recommended to specify UPDATE(YES) if START(AUTO) is specified.
    Default: The entire specified OPSLOG is archived
  • END(
    yyyy/mm/dd hh:mm
    |
    nnnnnnnnnn
    )
    Controls where in OPSLOG to end the archive. Specify one of the following values:
    • yyyy/mm/dd hh:mm
      The date and time in OPSLOG before which messages are to be archived. Required if START(
      yyyy/mm/dd hh:mm
      ) is specified.
    • nnnnnnnnnn
      The ten-digit OPSLOG message sequence number of the last message in OPSLOG to be archived.
  • DEBUG(YES|NO)
    Controls whether OPS9998I debug messages are created in the job log of the ARCHCRTE job.
    Default: NO