I am attempting to set up multiple resource tables in Stateman. I got the tables constructed and added to SSM. I can see the resources in 4.11.2 and everything seems fine from that point of view. Some of the resources have prerequisites on other resource tables within SSM.
STCTBL_ACT - Action table connected to all three tables above.
I would like to modify the states on the other two resource tables independently from the main resource table STCTBL. In otherwords: UPDATE STCTBL_DB2 SET DESIRED_STATE='UP' WHERE JOBNAME=resource.
If the task is down then this should invoke the DOWN_UP action from the action table and the task should start and vice versa. I do not see that happening. I have a feeling I am missing something but am not sure what or maybe it is done another way?
Once the newly SSM resource tables are added via OPSVIEW option 4.11.1 to the SSM_MANAGED_TBLS directory table then the resources should be visible via option 4.11.2 as you reported.
Also actions should start triggering when current and desired states changes as long as you have the appropiate entries in the common SSM action table STCTBL_ACT.
Question for you, when you created the new SSM resource tables via OPSVIEW option 2.6 did you select this option to make sure it has the proper layout:
System State Manager (SSM) tables
s SSM STC resource table
Also are the new SSM resource tables and resources in mode active?
I have tried this under CA OPS/MVS release 12.2 and this should all work as advertised.
Are you using an older release Travi?
Yes the tables were active. I am using CA-OPS 12.1. I found the option you mentioned when I do an INSERT of a table and it lets me select a model for the table. However, there is an OR in the options. The panel asks what table to use as a model OR select SSM STC RESOURCE TABLE. Do I still need to select this option if the table I am modeling is the SSM STCTBL?
EDIT: I found my answer. The panel will not let you select both. It gives you an error.
If you can afford recreate the new resource tables one more time I would give a try the option I mentioned in my prior post.
Also check Marcel's comments in this post:
Especially verify if your ACTION_RES_TABLE column in STCTBL_ACT has the correct table reference for your resources......
(It defaults to STCTBL, which in your case is not always good)
Let us know if this helps and for the resource you are testing make sure you not have pre reqs specified for now.
I think the issue turned out to be my Action Table. The ACTION_RES_TABLE column needed updated. After I took care of that, set the prereqs to "table.resource" and tweaked the rules for setting states (SSMEOM, etc.) it worked like a charm. Multiple tables definitely adds a serious level of complexity to SSM.
Glad to hear you figure this out Travi
Thanks to Marcel who spot that out too.
Dicussion is closed.
Travi, good you've got it sorted out, and yes, multiple tables do challenge you ...
Just to clarify - If sharing an action table (STCTBL_ACT for STCTBL,STCTBL_DB2,STCTBL_CICS, etc) you only need to specify the table name in the ACTION_RES_TABLE if the action is to only occur for a specific table. Meaning, if the DOWN_UP action for all resource tables is the same, (START &JOBNAME), you wouldn't need to code a DOWN_UP for STCTBL,STCTBL_DB2, and STCTBL_CICS as the ACTION_RES_TABLE='' entry would cover all tables. Your issue must of been resolved by either the fixing of the prereqs (tablename.resourcename needed if in different table), and/or updating the state management rules (SSMDB2,SSMCICS,SSMEOM,etc) to see where a resource resides. This is the biggest setup 'issue' when you decide to use multiples tables (state management rules) as you need to determine where the resource resides . The sample SSMQUERY OPS/REXX pgm can be called from the CS rules and will assist in this effort and keep your rules 'clean'. Logic simply searches the SSM managed tables to determine where a resource resides.
Just to clarify the clarification, I did need to add commands for the other tables because the stop commands were only going to occur on those tables. The main table ended up being devoid of DB2 and CICS tasks. As for the SSMQUERY OPS/REXX, funny enough I actually coded almost the exact same code on my own. I just used SSM_MANAGED_TABLES and a SELECT statement instead of OPSSMTBL to get my list of tables.
OK...yes...then different commands for same action definitely needed multiple entries using ACTION_RES_TYPE...yes also on SQL select from the directory table SSM_MANAGED_TABLES. Although highly unlikely, you do have the ability to have different directory tables as set via the STATETBL parm (SSM_MANAGED_PROD,SSM_MANAGED_DR,SSM_MON_ONLY,etc). In this case, the OPSSMTBL always returns whatever directory table is set to...