OPS/MVS interfaces callable by z/OSMF
search cancel

OPS/MVS interfaces callable by z/OSMF

book

Article ID: 274973

calendar_today

Updated On:

Products

OPS/MVS Event Management & Automation

Issue/Introduction

We are automating various software deployments and have a query regarding the availability of interfaces supported by OPS/MVS that could be utilized by a product such as z/OSMF. We can envisage a use case where we could use a product such as z/OSMF to call OPS/MVS to perform some automation, then have OPS/MVS pass back the result to z/OSMF.

We can see various scenarios where we would use z/OSMF work flows to upgrade software running on z/OS. As part of those upgrades we may need to stop and start tasks that are managed using SSM and therefore the work flow would need to be able to drive that. Alternatively we may want to disable some OPS/MVS automation that monitors a set of tasks while we update related software and recycle tasks that run that software. There could also be a situation where we use OPS/MVS automation routines to perform health checks and following a software upgrade we may want to trigger those automation routines and retrieve the result, before continuing with the work flow.

Please could you help clarify whether OPS/MVS supports interfaces that could be utilized by a product such as z/OSMF to enable this type of interaction?

 

Resolution

Both OPS/MVS and z/OSMF can utilize the REST API, however an API is not necessary to accomplish the desired result. A much simpler and more flexible approach follows:

1. All scenarios mentioned can be accomplished via OPS/REXX programs.

2. OPS/REXX programs can be executed from JCL batch jobs.

3. JCL jobs that call an OPS/REXX program can be submitted by a z/OSMF workflow step. 

4. Any OPS automation command output or error messages gathered in the rexx code can be passed back to the job's JESMSGLG via SAY statements, where they can be easily assessed in the JESMSGLG tab for the workflow step.

5. The return code set by the rexx execution can be passed back to the job, which in turn will set the return/condition code for the job.

6. A zero return code reported by the z/OSMF job step will allow the z/OSMF workflow to continue to the next step, whereas a non-zero return code will fail the workflow step and the workflow will stop.

As a simple example, let's say there is a z/OSMF workflow step that needs to check that 4 global variables are defined to OPS/MVS and values are present.

 

The following is the CHKGLBL OPS/REXX program that will check that the global variables are defined and report their values:

retcode = 0                         <<<< Set an initial RC of 0                      
do i=1 to 4                       
 varname = 'GLOBAL.TEST.'i        
 value = opsvalue(''varname'','0')
 if value = 0 then                
  do                              
 retcode = 8 <<<< Set RC 8 if a global is missing                 
 say varname 'DOES NOT EXIST!' <<<< SAY statements can be used to pass any output back to the job's JESMSGLG
end                             
 else                             
say varname '=' value <<<<          
end                               
return retcode <<<< Send the return code back to the job                 

 

The following is the JCL defined in the workflow step to call the CHKGLBL rexx referenced above:

<jobcard>
//STEP1    EXEC PGM=OI,PARM=CHKGLBL <<<< This executes the rexx member CHKGLBL            
//SYSIN    DD DUMMY                                
//STEPLIB  DD DISP=SHR,DSN=hlq.CCLXLOAD <<<< Steplib to the OPS loadlib
//SYSEXEC  DD DISP=SHR,DSN=
your.rexx.library <<<< REXX library where the CHKGLBL rexx resides  
//OPS$OPSS DD DUMMY <<<< Set the SSID of the OPS/MVS region to execute the rexx, in this case OPSS        
//SYSPRINT DD SYSOUT=*                             
//SYSTSIN  DD DUMMY                                

 

If all the globals are present and accounted for, the following will be returned to the job's JESMSGLG which can be accessed via the workflow step's JESMSGLG tab:

19.43.28 JOB06618 ---- FRIDAY,    06 OCT 2023 ----           
19.43.28 JOB06618  TSS7000I MYUSERID Last-Used 06 Oct 23 15:40
19.43.28 JOB06618  TSS7001I Count=00383 Mode=Fail Locktime=No
19.43.28 JOB06618  $HASP373 TESTJOB  STARTED - INIT 1    - CL
19.43.28 JOB06618  IEF403I TESTJOB - STARTED - TIME=19.43.28 
19.43.28 JOB06618  +OPS0996I GLOBAL.TEST.1 = FRED <<<< Here is the output passed from the rexx execution         
19.43.28 JOB06618  +OPS0996I GLOBAL.TEST.2 = WILMA <<<<          
19.43.28 JOB06618  +OPS0996I GLOBAL.TEST.3 = BARNEY   <<<<      
19.43.28 JOB06618  +OPS0996I GLOBAL.TEST.4 = BETTY   <<<<       
19.43.28 JOB06618  IEF404I TESTJOB - ENDED - TIME=19.43.28   
19.43.28 JOB06618  $HASP395 TESTJOB  ENDED - RC=0000 <<<< The RC 0 passed back from the rexx will allow the workflow to continue        

 

Now, what if a global is missing? In that case, the following will be returned to the job's JESMSGLG:

19.54.22 JOB06619 ---- FRIDAY,    06 OCT 2023 ----           
19.54.22 JOB06619  TSS7000I MYUSERID Last-Used 06 Oct 23 15:40
19.54.22 JOB06619  TSS7001I Count=00383 Mode=Fail Locktime=No
19.54.22 JOB06619  $HASP373 TESTJOB  STARTED - INIT 1    - CL
19.54.22 JOB06619  IEF403I TESTJOB - STARTED - TIME=19.54.22 
19.54.22 JOB06619  +OPS0996I GLOBAL.TEST.1 = FRED            
19.54.22 JOB06619  +OPS0996I GLOBAL.TEST.2 DOES NOT EXIST! <<<< There's a problem 
19.54.22 JOB06619  +OPS0996I GLOBAL.TEST.3 = BARNEY          
19.54.22 JOB06619  +OPS0996I GLOBAL.TEST.4 = BETTY           
19.54.22 JOB06619  IEF404I TESTJOB - ENDED - TIME=19.54.22   
19.54.22 JOB06619  $HASP395 TESTJOB  ENDED - RC=0008 <<<< The RC 8 passed back from the rexx will fail the workflow step and stop the workflow.

 

The above is a simple example, but complex processing and reporting can be implemented within any OPS/REXX program called via a JCL step in the z/OSMF workflow, allowing control of virtually every aspect of OPS/MVS. Documentation of OPS/REXX commands/functions specific to the example scenarios that were mentioned follow:

 

"we may need to stop and start tasks that are managed using SSM and therefore the work flow would need to be able to drive that."

Address SQL Commands

 

"we may want to disable some OPS/MVS automation that monitors a set of tasks while we update related software and recycle tasks that run that software."

Address AOF Commands

 

"we use OPS/MVS automation routines to perform health checks and following a software upgrade we may want to trigger those automation routines and retrieve the result, before continuing with the work flow."

If the "automation routines" are already in the form of OPS/REXX programs, then they too can be called via a z/OSMF JCL workflow step.