OPSMVS PREREQ/SUBREQS

[Randy Knapton]

I have a special situation (aren't they all),  at system startup they want a certain order for tasks to come up, but once they are up they want to cycle any of the tasks at will..  basic scenario :

 

SERVER TASKA   Up first

SERVER TASKB   Up after TASKA

DATACOLLECTOR TASKC Up after TASKA TASKB 

DATACOLLECTOR TASKD Up after TASKA TASKB

 

So they would like to CYCLE TASKB during the week, quite frequently(for some reason), of course it will wait for TASKC and TASKD to be down also. There are different ways to handle this,  not sure what is the best. Just wondering if other customers have this same issue.....    

[SAL COSTANZO]

Randy

 

In STCTBL – you have your PREREQ column

Add 2 additional columns.   PREREQS_AT_INITIAL    PREREQS_AFTER_UP

 

At startup, before STATEMAN starts anything: copy PREREQS_AT_INITIAL to PREREQ 

Once a task is UP UP, Copy PREREQS_AFTER_UP to PREREQ

Once a task goes to current state DOWN, Copy PREREQS_AT_INITIAL to PREREQ

 

PREREQS_AFTER_UP – most will have a keyword to indicate “SAME_AS_INITIAL”  - so these are never changed – no need to copy over.

In some cases, this will not have the prereqs you only needed for initial startup of the task..

 

 

Let me know if you have any questions

Sal

[Phil Stanoch]

We have provided users a command with a parameter to bypass the PREREQs. If they issue an OPSTOP taskname NOPREREQ, we update the MODE on the STCTBL to NOPREREQ to bypass PREREQ and SUBREQ checking. A dynamic rule is issued that will set the MODE back to ACTIVE after the task comes down. We then update the STCTBL to a DESIRED_STATE of DOWN for the task(s) that is/are being brought down.

[gorda05]

Many different ways of accomplishing this request as you noted and as Sal has outlined. Another method to look at to see if it fits your environment, is the addition of a 'Force Cycle' type of action for your SSM controlled resources. Ideally, within your end user control tool such as the SSM pseudo command rule (SSMCNTL sample rule) you would have logic to allow for a 'SSM FCYCLE JOB=TASKB' command. The FCYCLE logic in the rule together with previously set up actions in the SSM action table (utilizes ACTION_MODE and logic to bypass Subreq checking) would cause SSM to stop/restart the resource without doing any subreq checking. Refer the the FCYCLE subroutine of the SSMCNTL sample rule if you would like some details of the actions that need to be added to the SSM action table to implement this type of control..    

[Randy Knapton]

Thanks for everyone's input! That gives me some idea what direction we can take.

[Anon Anon]

If the user wants to just cycle the task, FCYCLE is the way to go. As David made mention it will cycle the task and inheritenly avoids pre/subreq checking. However, we also have a situation where users want to bring their tasks down, do some stuff and then bring them back up. What we did was created a batch job/REXX combo. The batch job can then be scheduled as part of the job flow (which our users were already doing) and the input to the REXX is all the columns and column values for selection and update criteria. Prior to this combination, the users were just issuing commands blindly and hoping they worked. The REXX will wait for a task to reach its desired state and throw an error if it doesn't. This eliminates the guess work and makes the batch process much, much faster. The users were waiting n seconds (up to 15 minutes of wait through the entire cycle if I recall) to give the commands time to resolve and the tasks come down. Now, as soon as the tasks are down we can immediately move on to the next job/step.