BACKUP
Purpose
The BACKUP command is used to initiate a backup of the current plan (CP) or the JCL repository (JS) on request. You can request the backup process by issuing the BACKUP command from your TSO session or from within a batch job. You can schedule current plan or JS backups by defining the job as an operation in the current plan.
The JS and current plan files are managed by the controller. A request generated by the BACKUP command is communicated to the controller as an event record processed by the event writer task of a tracker. The BACKUP command can be issued from any z/OS® system that runs a tracker from HCL Workload Automation for Z Release 2 or a later release. If you request a BACKUP on multiple systems at the same time, you will cause multiple file backups to occur when the events reach the controller.
- During normal shutdown of the controller.
- At the beginning and end of the daily planning process.
- When the number of new job-tracking records is greater than the value specified by the JTOPTS keyword BACKUP. But if the JTOPTS BACKUP keyword specifies NO, these regular backups of the current plan are not taken.
- Request a backup at a predefined time for disaster recovery purposes.
- Ensure regular backups are taken when HCL Workload Automation for Z activity is low.
- Take backups only at set times, in which case the JTOPTS BACKUP keyword is probably set to NO.
Backup of the JS file is performed automatically at regular intervals based on the value defined in the MAXJSFILE keyword of the JTOPTS initialization statement. You can also issue the BACKUP command for the JS resource at any time to schedule an immediate backup of the JS file. If the value of the MAXJSFILE keyword is specified as NO, regular backups of the JS file are not taken. You might do this to ensure that backups are only taken at a time when the disruption is minimized. During a JS file backup, the current plan resource is locked to prevent panel users and other HCL Workload Automation for Z tasks from updating the JCL for operations in the current plan.
Usage Notes
You can invoke the BACKUP command as a TSO command or by using a batch job that executes program EQQEVPGM. If you invoke BACKUP as a TSO command, you must allocate the EQQMLIB data set to the address space of the TSO user, either by adding DD statements to the logon procedure, or by using the ALLOC command after TSO logon. In the TSO environment, error messages and trace records are sent directly to the terminal user. Messages are not delivered to indicate successful command execution.
Use of the BACKUP command can be restricted with the fixed resource code BKP. The authority of the requester is verified by the subsystem name identified in the command if an AUTHDEF statement is defined for that subsystem. When SUBSYS(MSTR) is specified, all subsystems defined on the z/OS® system to which the command is directed will attempt to verify the authority of the requester before an event is generated. It is possible to be rejected by one subsystem and accepted by another.
You must be defined with update authority to the BKP resource to use the BACKUP command. Resource codes are documented in Customization and Tuning. Check with your administrator to confirm that you have this authority before you use BACKUP.
The subsystem to which you direct the command does not have to be active when the command is issued. An event will be generated and queued in CSA along with other job-tracking events. If the subsystem is not active when the command is issued, the authority of the requester is verified using the class name specified in the AUTHDEF statement when the subsystem was last started. If the subsystem has not been started since a z/OS® IPL, no authority verification can be performed.
Syntax
Parameters
- RESDS (CP | JS)
- The RESDS keyword specifies which data set the backup will be
performed on. If you specify CP as the keyword value, a current plan
backup will be performed. If you specify JS as the value for this
keyword, the JCL repository data set will be copied to the alternate
JS file.
The RESDS keyword must be specified.
- SUBSYS (MSTR | subsystem name | OPCA)
- The name of the tracker subsystem that the BACKUP command is directed
to. The name can be up to four characters long. The first character
must be alphabetic; the remaining characters must be alphanumeric.
All lowercase characters are converted to uppercase. If the SUBSYS
keyword is omitted the on-request backup command will be directed
to a subsystem called OPCA.
If you specify MSTR, the BACKUP command is directed to all tracker subsystems on the z/OS® system that the BACKUP command was directed to.
Attention: This will cause multiple backups to occur if more than one tracker subsystem is active on the system.Subsystem name is the name of the subsystem that the BACKUP command will be directed to. If the tracker and controller run in separate address spaces in your HCL Workload Automation for Z configuration, specify the name of the tracker subsystem in this parameter.
- TRACE (level | 0)
- Event tracing indicator. When a positive number is specified, a trace entry is created for each event generated by the BACKUP command. The trace record is written to the message log file identified by ddname EQQMLOG. The record identifies the name of each receiving subsystem. The default value 0 will not generate trace records.
Examples
These two examples demonstrate how you can use the BACKUP command in TSO, or in a batch job (using the batch program EQQEVPGM).
BACKUPALLOC F(EQQMLIB) DA('OPC.MESSAGE.LIBRARY') SHR REUSE
BACKUP RESDS(CP) SUBSYS(OPCA)//CPBACKUP JOB (ACCOUNT),'Backup CP',CLASS=A
//STEP1 EXEC PGM=EQQEVPGM
//STEPLIB DD DSN=OPC.LOAD.MODULE.LIBRARY,DISP=SHR
//EQQMLIB DD DSN=OPC.MESSAGE.LIBRARY,DISP=SHR
//EQQMLOG DD SYSOUT=A
//SYSIN DD *
BACKUP RESDS(CP) SUBSYS(OPCA)
/*In both of these examples, the current plan data set will be copied to the old current plan data set, on a subsystem called OPCA.