Using the SETCOL action clause in SSM - can I specify a table on another system?

[Steve Ives]

The SETCOL action clause is used to set a specified column in a table to a value:

SETCOL("column name,column value,resource name,table name")

Can 'table name' be a table on another MSF system? I have a pair of systems and I'd like to set the mode of a resource on one system to PASSIVE with an IPL State of DOWN if the task is started on the other system inthe pair and vice-versa.

E.g. : define ACTION_TEXT as:

SETCOL("IPL_STATE,DOWN,TESTRES,TEST2.STCTBL");SETCOL("ACTMODE,PASSIVE,TESTRES,TEST2.STCTBL")

[Dave Gorisek]

There is not a SYSTEM() type keyword on the SETCOL action from what I can see, and if there was I wouldn't use it. 'Blindly' issuing any cross system action/cmd via SYSTEM() is 'poke and hope' automation. Hope that MSF is active, Hope that the action really did what is was supposed to......For any cross system cmd/action/request it is best to do this in an OPS/REXX pgm in a server where you can 1) Query the MSF status of the desired system to ensure its ACTIVE and 2) Validate the action and if you have a failure you can now be able to take some 'failure' action such as send out an alert, queue up the action to retry later, etc

[Steve Ives]

Well I can't reply to Dave's comment so this is what I discovered after raising a case: No there isn't, but you can specify SYSSTEM() in an OPSQL statement to acheive something similar:

TSOCMD("OPSQL Update STCTBL set IPL_STATE='UP' where JOBNAME='&JOBNAME' SYSTEM(msfid)

Or at least you can if you have the right level of maintenance - on our sytem, the SYSTEM(msfid) is validated but simply not executed. In fact, in OPSLOG you see the defines OPSQLK statemnt but with blanks there the SYSTEM(msfid) was coded. 

[Dave Gorisek]

Sure, TSOCMD("OPSQL.........SYSTEM(SYXX)") will simply asynchronously execute a cross system OPSQL, but you still are in the 'dark' if it worked or not. Since you are dispatching a TSO cmd to the server, why not just take the extra steps and dispatch an OPS/REXX to the server that has the logic to programmatically react to the system possibly not being there yet rather than 'assume' it is? Also, is this 'other' system in a sysplex? If it is in a sysplex, and you still just want to 'ship' over a command and not validate it, why not just send over a pseudo command (such as the SSMPLEXC sample does) via the ROUTE command as sysplex communication is set up in early IPL with less pieces involved than MSF. Lastly, as I dont know all the details of this resource and the exact control requirements you are needing to set up, perhaps an OPS/REXX program triggered for the UP_DOWN action that simply determines if it needs to be started or not (up on the other system so just set CS=DOWN/DS=DOWN or maybe CS=SYxx DS=SYxx to show its active on SYxx) or whatever. You would of course programmatically 'recheck' the other system every 30 secs or so 'if' you are unable to communicate to the 'other' system (MSF and/or Sysplex  connectivity not established yet). Also, if the other system is in a sysplex, you can utilize the SSMXCHCK sample OPS/REXX pgm in this startup OPS/REXX pgm to determine if the resource is active on the other system. That sample uses either MSF or Sysplex (via Route) to manipulate the cross system status. It will return a value of 'UNKNOWN' if either probe check failed.

[Steve Ives]

@Dave - I get what you're saying. Any cross-system Ops/MVS command could fail though so in this instance my preferred approach would be to add another action to trigger a rule to fire after some appropriate delay that says "Hey - you know that thing you askfor 30 second ago? Well it hasn't happened yet" 

On our system, even OPSQL doesnt work with SYSTEM so I have written a generic cross-system ReqRule to do the update to which I could add code to check that it actually worked. But then I'd have to check that the check worked. :-)