OPS/MVS

Hello,

I hope someone out there can provide some help here.

I have some resources that do not shutdown when the state is changed to DOWN. OPS/MVS seems to be selecting UNKNOWN as the action, not UP_DOWN.

Any idea on why it would do this?

I get the following messages.

OPS1181H OPSOSF   OPSS (*Local*) MVS N/A CICSDOWN !OI STATESET PRTXWOR2  

DESIRED(DOWN)                                                            

!OI STATESET PRTXWOR2 DESIRED(DOWN)                                      

OPS3092H OI STATESET PRTXWOR2 DESIRED(DOWN)                              

OPS3092H OPS3730I STCTBL.PRTXWOR2 RESOURCE: CURRENT=UP DESIRED=DOWN      

MODE=ACTIVE PMD=ACTIVE RMD=ACTIVE AMD=ACTIVE                             

OPS3092H READY  

OPS7902H STATEMAN ACTION FOR STCTBL.PRTXWOR2: UNKNOWN RULE=SSMSTATE         

TABLE(STCTBL) NAME(PRTXWOR2) TYPE(CICS) JOBNAME(PRTXWOR2)

This is the Resource table, with defined actions.

Thanks

Mark Noonan

Anyone able to offer Mark assistance? Thank you

Mark,

Did you capture all of the related messages?   The UNKNOWN action wouldn't have fired if it had not been set to UNKNOWN by something.  You may want to turn the parm SSMDEBUG to YES and run the scenario again.   If all else fails, open an incident with CA.

-Russ

Hello Russ,

I don't have an OPSLOG going back to when the problem occurred. These messages were taken from the SYSLOG. I don't see any others in relation to the resources that had this problem.

However, Russ and Mike. I went back even further in the SYSLOG to see what was happening with the resources. And that shows some problems with a previous shutdown.

This is what happened.

1. Early in the morning, a shutdown request was issued against the resources.
   P resource
2. SSMSTOP rule executed, to capture and set the desired state to DOWN.

3. The right action occurred UP_DOWN.

4. The shutdown command issued.

5. The resource did not terminate. And OPS/MVS tracked them in this state:

6. Then later for the IPL shutdown.

[This is what I think OPS/MVS decided, and I'd like to know if that is a correct deduction on my part.]

    As the resource was already DESIRED state DOWN, and the UP_DOWN action had already triggered, (OPS/MVS keeps record of this?) OPS/MVS couldn't perform any more action against the resource, and selected UNKNOWN.

Regards,

Mark Noonan

Mark,

OPS/MVS doesn't keep track of the number of times that a task is put in the same DESIRED_STATE.  When it scans the tables for mismatches it is just looking for CURRENT_STATE not matching DESIRED_STATE.  It then compares that to the Check Point State.  If it's a new mismatch the corresponding Action table entry will be fired, if not a new mismatch then no action is taken.  I would suggest scanning your code for anything that sets the CURRENT_STATE to UNKNOWN.  Then seeing if there is anyway that code could have triggered around the given time frame.

You should also open a ticket with support.  Without the OPSLOG it will make it more difficult to find the problem, but they might be able to find something in the SYSLOG.  If this occurs again get a copy of the OPSLOG that will really help track down the issue.

Mike Kiehl

Mark,

You wouldn't happen to have the SSMSTOP sample rule enabled on your system?  The SSMSTOP CMD rule would intercept the command.  Part of the processing for this CMD rule is to change the CURRENT_STATE to UNKNOWN.  The newest version of this rule will ignore the command if it is issued via the Action table process MVSCMD or if it is issue by OPSMAIN or OPSOSF.

Mike Kiehl

Hello Mike,

The SSMSTOP rule is enabled. I reviewed it, and the version we have doesn't set the state to UNKNOWN.

Also the shutdown request was part of SSMSHUT to bring down the whole system.

Thanks,

Mark Noonan