Technical Notes › Run Multiple Copies of the Product On a Single z/OS Image › OPS/REXX Program and Command Processor Considerations

OPS/REXX Program and Command Processor Considerations

Use the following techniques when working with multiple copies of CA OPS/MVS:

• To properly communicate with alternate copies of CA OPS/MVS from OPS/REXX programs, use the following technique (SubsysName is the name of the CA OPS/MVS subsystem):

  ADDRESS AOF "SUBSYS" SubsysName
  if RC <> 0 then
      do
       say "OPS/MVS subsystem "SubsysName" is not active"
       exit
      end
  

• When an OPS/REXX program runs as a batch job or as a started task and you are either running multiple CA OPS/MVS copies on one system or the subsystem where CA OPS/MVS is running is not called OPSS, you can ensure that the program executes on the correct subsystem. To do so, include the following DD statement when invoking the program or submitting the batch job (OPSx is the name of the CA OPS/MVS subsystem):

  //OPS$OPSx DD DUMMY
  

• To ensure that CA OPS/MVS command processors (including the OPS/REXX command processors OI and OX) execute on the correct subsystem, modify the CA OPS/MVS default subsystem ID for each TSO user by allocating a ddname of the form OPS$OPSx (x is any alphabetic character). The last four characters of this ddname will then be used as the default subsystem ID for all CA OPS/MVS command processors invoked by the user.

  For example, a TSO user could issue the following command to set the default subsystem ID for his or her session to OPSA:

  ALLOC F(OPS$OPSA) DUMMY
  

  When multiple ddnames of this form are found, the first one that is found in the TIOT is used. This order has no connection to the order that the TSO ALLOCATE command allocates the ddnames.