Technical Notes › Back Up and Restore the SYSCHK1 VSAM File Data

Back Up and Restore the SYSCHK1 VSAM File Data

As automated applications begin to create and manipulate GLOBALx stemmed variables and/or Relational Data Framework (RDF) tables, we recommend that you implement site-specific backup and restore methods for the CA OPS/MVS SYSCHK1 VSAM file that stores this data. This system-unique file is allocated either through a //SYSCHK1 DD JCL statement within the OPSMAIN procedure, or through allocation statements that are performed within the CA OPS/MVS start-up member (default name of OPSSPA00).

You can utilize various backup-and-restore methods to help ensure that this critical application data is protected. Consider the following methods, and choose the method that best suits the needs of your environment:

• (Recommended) Adapt the current site methods that back up critical system data sets, to back up the entire SYSCHCK1 VSAM file.
• Configure and utilize the OPSSGVBK and OPSSGVRS procedures that back up the entire SYSCHCK1 VSAM file.
• Create a backup of GLOBALx variables only (no RDF tables).
• Back up and restore Specific Relational Data Framework (RDF) tables only.

Adapt the Current Site Methods that Back Up SYSCHCK1 VSAM

We recommend that you adapt to current site methods of backing up critical system data sets, to back up the entire SYSCHCK1 VSAM file (RDF tables and GLOBALx variables).

Create system backup jobs that the external scheduler package submits, or modify the jobs to back up the SYSCHK1 VSAM file also, just as other critical system data sets are backed up through some in-house backup utility (IDCAMS, DFDSS, and so on). When, or if needed, you can restore the SYSCHK1 data in one of two ways:

To restore the entire SYSCHK1 file:

1. Stop CA OPS/MVS.
2. Restore SYSCHK1 from a backup file that the in-house backup utility created.
3. Restart CA OPS/MVS.

   The RDF tables and global variables restore back to current values based on the last time the system backup job of the SYSCHK1 file executed successfully.

To access and utilize the SYSCHK1 Restore option from within OPSVIEW:

1. Select Option 7.6 within OPSVIEW to allocate a backup SYSCHK1 file.
2. Choose the RDF tables and/or GLOBALx variables that you want to restore.

   If a SYSCHK1 dataset with the required restore data is not available, use the option to restore an OPSSGVBK backup dataset to an inactive SYSCHK1.

   Note: For more information about how to use the SYSCHK1 Restore option, see the OPSVIEW User Guide.

Configure and Utilize the OPSSGVBK and OPSSGVRS Procedures

CA OPS/MVS provides a backup and restore utility that you can configure to back up the entire SYSCHCK1 VSAM file. You might need the OPSSGVBK (backup) and OPSSGVRS (restore) procedures within installations where the automation group wants to manage this SYSCHK1 backup process separately from the other system backups, and/or you want to create and access backups regularly.

Such as some automated application updates variables frequently, and/or RDF tables and you want a more specific point-in-time backup. The backup process utilizes generation data groups (GDGs) to store each backup copy, allowing the restore process to access a specific point in time backup, if needed.

To implement the OPSSVBK (backup) procedures:

1. Locate, tailor, and submit member GVBKGDG of your opsmvsHLQ.CCLXCNTL data set. This member allocates the required GDG pattern and data set names that are used within the backup procedures.

   Ensure that the GDG data set name is named uniquely per each copy of CA OPS/MVS. You use the systems SMFID as part of the naming convention, such as SYS2.OPSS.smfid.GLOBAL.BACKUP.

2. Locate member OPSSGVBK of your opsmvsHLQ.CCLXCNTL data set. This member is the actual started task that performs the backup process (copy current SYSCHK1 to a GDG) when triggered.
3. Copy this member into a valid systems PROCLIB in which started tasks reside.
4. Tailor the JCL accordingly. The backup program must be run from an APF-authorized library and must be run at the highest dispatching priority.
5. Define the required GLOBALBACUP* CA OPS/MVS parameters for the backup process. You must define these parameters within the CA OPS/MVS start-up procedure (OPSSPA00 by default) to help ensure that the parameters are defined each time CA OPS/MVS initializes.

   Utilize OPSVIEW option 4.1.1 to set these parameters dynamically if a restart of CA OPS/MVS is not desirable to proceed with this backup configuration. You define the following parameters:

   GLOBALBACKUPINTVAL

   Specifies the time interval in minutes in which the backup procedure is submitted to generate a backup copy. If desired, you can omit this parameter setting, and can start the backup procedure (START OPSSGVBK) through an in-house batch job that a scheduler package submits. You can start this procedure manually from a console when a backup is needed, or can start it through a CA OPS/MVS TOD rule.

   GLOBALBACKUPPROC

   Specifies the name of the backup JCL procedure that you created in Step 2 (default name of OPSSGVBK).

   GLOBALBACKUPDSN and GLOBALBACKUPMDSCB

   These parameters correspond to the GDG pattern and data set names that you created in Step 1 (GVBKBDG job).

   GLOBALBACKUPSTCLASS

   Specifies the SMS storage class that controls the allocation of global variable backup data sets.

   Note: When you set this parameter to a nonblank value, the GLOBALBACKUPUNIT and GLOBALBACKUPVOLSER parameters are ignored.

   GLOBALBACKUPUNIT

   If GLOBALBACKUPSTCLASS is not set (no SMS), this parameter specifies the generic or esoteric device name for the backup data set (for example, 3390, SYSDA, and so on). You can either use the GLOBALBACKUPUNIT on its own to direct the backup data set to any volume in the generic or esoteric group, or you can use it with the GLOBALBACKUPVOLSER parameter to direct the allocation to a specific volume.

   GLOBALBACKUPVOLSER

   Specifies the volume serial (VOLSER) associated with the allocation of a backup data set. When you specify this parameter, you also specify the GLOBALBACKUPUNIT parameter. For example, GLOBALBACKUPUNIT is set to SYSBK. You can use GLOBALBACKUPVOLSER to direct the backup data set to a specific volume in the SYSBK group, for example, WORK01.

   Note: For more information about these CA OPS/MVS Global Variable backup parameters, see the Parameter Reference.

6. Start the OPSSGVBK procedure.

You must run the backup program while CA OPS/MVS is active. Review the joblog and/or OPSLOG to confirm the success or failure of the backup procedure. After OPSSGVBK executes successfully, verify that a GDG backup was created. Future executions of this job are performed through the defined trigger mechanism (GLOBALBACKUPINTVAL setting, CA OPS/MVS TOD rule, scheduled job that issues START OPSSGVBK, or upon a manual start).

To execute the OPSSGVRS global variable restore process:

1. Locate member OPSSGVRS of your opsmvsHLQ.CCLXCNTL data set. This member is the actual started task that restores the SYSCHK1 VSAM file from a backup GDG data set created through the OPSSGVBK procedure. Copy this member into a valid systems PROCLIB in which started tasks reside.
2. Customize the OPSSGVRS procedure.

   You can customize the OPSSGVRS sample JCL procedure to allocate the desired GDG dataset that the OPSSGVBK procedure created, or it can allocate the most recent generation (+0). You must specify a single parameter in the started task procedure OPSSGVRS. This parameter identifies the CA OPS/MVS subsystem ID whose global variables you want to restore (for example, PARM='OPSS'). You must run the restore program must from an APF-authorized library, and you run it at the highest dispatching priority.

3. Start the OPSSGVRS procedure.

   You must run the restore program while CA OPS/MVS is active. All global variables reset to their backed-up values, and all RDF tables are replaced with all RDF tables that were part of the last global variable backup. Review the joblog and/or OPSLOG to confirm the success or failure of the restore procedure. After OPSSGVRS executes successfully, the global variable tree rebuilds, and if being utilized, the SSM engine restarts to resynch with the newly loaded/restored tables.

   Note: The global variable restores the entire global variable database from the designated backup data set. If the size of the global variable database (determined by the value of the GLOBALMAX parameter) has been changed since the backup was taken, then the restore fails. Therefore, we recommend that you take new backups immediately after changing the value of the GLOBALMAX parameter.

Return Codes for the OPSSGVBK Procedures

The following list provides the OPSSGVBK global variable backup return codes:

Return Codes for the OPSSGVRS Procedures

The following list provides the OPSSGVRS global variable restore return codes:

Create a Backup of GLOBALx Variables Only

To take a backup of all GLOBALx variables or a particular stem quickly, utilize the OPSVIEW 7.5 option.

This online option simply creates an OPS/REXX member that contains the necessary OPSVALUE() instructions that back up (reset) the desired GLOBALx. variable values.

You can also use this method, if you want to transfer some particular GLOBALx variables quickly from one system to the next. Meaning, you could back up the desired variables (creates an OPS/REXX exec), and then execute this OPS/REXX exec on another system to reset/initialize these desired variables.

Note: For more information about this online option, see the OPSVIEW User Guide.

Back Up and Restore Specific RDF Tables Only

Use the supplied WRITETBL (creates a sequential DSN backup copy of an RDF table) and READTBL (creates an RDF table from a DSN backup copy) OPS/REXX programs of the opsmvshlq.SAMPLE.REXX library as backup and restore procedures for one or more RDF tables.

You can invoke these programs whenever you want a backup of a table, such as making a copy of the SSM STCTBL before making new changes. Then, you have this backup in the event the new changes were not successful, or need backing out. Additionally, you can invoke the WRITETBL exec from within an CA OPS/MVS TOD rule to create a more specific point-in-time backup of a specific table.

Note: For execution details, see the comments within the WRITETBL and READTBL OPS/REXX programs for execution details.