Without obtaining more details (SSM controlled or not, what tools currently in place, # of regions on each system, etc) to provide more specific suggestions based on your environment, I'll provide a high level overview of how we would put this DDF cycle request within our current automation structure 'if' we needed to perform this request and assuming you have 'many' DB2 regions across all your systems. Perhaps you can take some of this as you create/modify your application. The trigger of the primary pgm (DB2DDF) would be dependent on your configuration (From some SSM UP_DB2DDF or ACTMODE=DB2DDF action, or from focal pgm on each system. Basically, the root of the logic is to initiate the DDF 'process' for all regions and then wake up and display 'where the process is for all regions' as set in monitor rules.This approach of course would expedite the process if you do have 'many' regions.
Here is an outline of how we would incorporate this DB2 DDF cycle request into our existing automation environment.
We would add DB2DDF options to our focal point of control OPS/MVS ISPF utility (OPS/REXX pgm adapted from OPSINQRY sample OPS/REXX available in yourhlq.CCLXSAMP ) which is triggered from TSO/E foreground. We have made various additions to the logic of this template utility including passing a Scope option to direct the request across a system,plex, group of systems, or all MSF systems. We would probably create DB2DDF options, having something like:
TSO OPSI DB2DDF BEGIN S=ALL
Trigger DB2DDF BEGIN process on all systems. The primary logic here would be to initiate the 'actual' process/application against all DB2s on all systems. This can be by setting SSM action UP_CYCLEDDF for all DB2s and then driving actual DB2DDF OPS/REXX from action TBL or triggering the DB2DDF program via OPSRMT to each system, and it would start the process for all DB2s on that system. "OI P(DB2DDF) P("region" BEGIN)"…
TSO OPSI DB2DDF STATUS S=ALL
Show status info for DB2 DDF process for all DB2 regions on all systems. This info would come from unique DB2 DDF status variables set by predefined rules or dynamic rules created within the 'BEGIN' routine at the start of the of the DB2DDF pgm as mentioned below.
The primary DB2DDF OPS/REXX pgm would perform the overall process of all the required DDF actions - SET LOG SUSPEND, SET LOG RESUME, STOP DDF, and START DDF. The logic would be performed in unique subroutines , passed as an argument to the pgm such as BEGIN,RESUME,STOP,START,ALLDONE,TIMEOUT.
The BEGIN phase/routine would enable a max time allotted TOD monitor rule with a spec of *+x mins where x is some number in mins of how long this process 'should' take to complete. The logic of this dynamic TOD rule would invoke this primary DB2DDF with a TIMEOUT option ("OI P(DB2DDF) ARG("region" TIMEOUT)"). Logic within this BEGIN routine would also enable dynamic MSG rules to monitor and set OPS Variables of the 'status' of the process. I havent looked at it all the cmds, but it looks like DSNL004I, and DSNL006I indicate that DDF is started/stopped. Thus, dynamic MSG rules on these would be created with logic to set some unique GLVTEMPx variable such as GLVTEMP1.DB2DDF.region.STATUS to a value representing the msg event (DDF STARTED/DDF STOPPED ). Logic in each of these monitor rules would also trigger the primary DB2DDF pgm with the 'next' action as an argument. So in the LOG SUSPEND monitor rule , set GLVTEMP1 status variable to 'SUSPENDED' and then "OI P(DB2DDF) ARG("region" RESUME)" to cause the next action cmd of SET LOG RESUME to be issued. Sure you can do the next action in the dynamic MSG monitor rule if desired, but we like to keep the 'actions/processes' self contained in one focal OPS/REXX pgm. Up to you. The BEGIN routine would then issue the first SET LOG SUSPEND command to begin the process.
The 'All Done' logic (firing on the DDF STARTED msg) would of course do the disablement of all the monitor rules Including the monitor TOD rule. Note – you were looking at sysplex variables. Sure,this is another option you can use if desired and if it fits better in 'your' final design.Just a note with plex vars you would have to trigger an OPS/REXX pgm from the monitor MSG rule (or update the var in the DB2DDF when retriggered) because the OPSVASRV() cannot be done in rules.
Issuing TSO OPSI DB2DDF STATUS S=ALL as stated above would of course have the code to loop through all the systems and present a formatted view (System,Region,DDF status) as obtained by each GLVTEMP1.DB2DDF.region.STATUS variable on all systems.