search cancel

Converting from OPSMVS SSM Wizard to SSM.


Article ID: 53840


Updated On:


SOLVE:Operations Automation SOLVE:Access Session Management SOLVE:FTS OPS/MVS Event Management & Automation SOLVE



Summary of conversion steps that need to be performed across all current SSM Wizard V2 configurations to implement base SSM.


Here is a summary of conversion steps that need to be performed across all current SSM Wizard v2 configurations to implement base SSM:

  1. Create a new production AOF ruleset. This ruleset will hold the base SSM required rules. The recommended ruleset name is STATEMAN. If the existing Wizard ruleset is named STATEMAN, then simply create a new ruleset name for now, then rename prior to the implementation of the new base SSM tables.

  2. In the new ruleset, copy from the opsmvshlq.STATEMAN.RULES (created during install) the following rules. (Do not enable or auto-enable rules yet)

    1. SSMEOM




    Also copy/move the existing SSMBEGIN and SSMBEGUX routines. (If SSMBEGUX is in the SYSEXEC DD of OPSMAIN then there is no need to copy/move)

  3. From the opsmvshlq.STATEMAN.RULES data set, locate product specific rule packets that match up to those STCs that are currently being monitored by the SSM Wizard configuration. For example, if TSO is being managed, then the SSMTSO rule packet should be copied to the new ruleset created in step 1. The same for resources such as JES2 - SSMJES2, VTAM - SSMVTAM, etc. Each resource managed by SSM must have a unique rule created that sets the current state of the product to UP (and optionally STOPPING). The DOWN state will be detected via the SSMEOM rule.

    For products that do not have a corresponding rule packet, use the SSMNEW rule (see below) as a template rule to create a rule to set CS=UP for this product. An OPSLOG of the last IPL or starting of the product, will greatly assist in the creation of this rule packet. Use the PROFILE command within OPSLOG to profile the specific job in which the rulepacket is being created to locate a unique event that indicates the product is ?UP? and functioning.

    For any 'user' created rules or programs that were possibly created to update the SSM Wizard tables, then logic must be modified (as illustrated within SSMNEW via 'Address SQL' ) to accommodate the new SSM base table names of STCTBL and STCTBL_ACT.

  4. Review and execute the uploaded binary version of the attached SSMCWZRD OPS/REXX program. The default names for the SSM tables used in this program will be STCTBL and STCTBL_ACT (recommended for new base SSM tables) and existing SSM wizard tables of SWZ_STCTBL and SWZ_STCTBL_ACT. Update the variable names if needed.

  5. When ready to 'implement' the new SSM base tables:

    1. Enable and auto-enable the new ruleset that was created in step 1

    2. Disable and reset-auto enable bit for existing SSM Wizard rulesets.

    3. Review and Execute the uploaded binary version of the attached SSMCWZR2 OPS/REXX program to remove existing SSM Wizard tables from SSM control, and to add newly created SSM base tables. Additionally, if SSMV1 is running the logic will implement SSMV2 dynamically. You still must update the parameters SSMVERSION=2 and SSMAUDIT=YES permanently within your OPS/MVS start-up member (OPSSPA00 by default) to ensure SSMV2 will be running after the next OPS recycle
                               SSMNEW Rule
 )MSG initmsg
 /*                                                                               */
 /*   NAME       -  SSMNEW                                                        */
 /*   PURPOSE    - Set the CURRENT_STATE FOR a SSM  controlled region             */
 /*                 to UP based on a unique initialization  message.              */
 /*   RELATED    -  STATEMAN                                                      */
 /*   GLOBALS    -  None                                                          */
 /*   PARMS      -  None                                                          */
 /*   KEYWORDS   -  None                                                          */
 /*   LANGUAGE   -  OPS/REXX                                                      */
 /*   Notes      - CS=UP in SSM is set when  that product  produces               */
 /*                 its unique initialization or 'product  ready'                 */
 /*                 message. Use logic like this when a  supplied                 */
 /*                 SSM product specific rule packet does not  exist.             */
 /*                 This initialization message can be easily  obtained           */
 /*                 by profiling on this jobname within the  OPSLOG.              */
 /*                 Additonally, display the MSGID column in the  OPSLOG          */
 /*                 to determine the exact message as OPS/MVS sees  it            */
 /*                 and then use this value for the )MSG  specifier.              */
 /* As a safe guard, you should do a quick check to ensure that  this             */
 /* is really the initialization message. Some producst use the  same             */
 /* message id to represent different meanings. Change the text  in               */
 /* the POS() function to something that is unique in this  message.              */
 /* As an example, suppose the message  is:                                       */
 /*     PRODABCD is now accepting  logons                                         */
 /* In the below POS() you would  code:                                           */
 /*     If POS('NOW ACCEPTING LOGONS',msgtxt) = 0 then  Return                    */

msgtxt = TRANSLATE(msg.text) If POS('UNIQUE UP MSG STRING',msgtxt) = 0 then return

/*********************************************************************************/ /* This logic will update the SSM STCTBL to CS=UP */ /*********************************************************************************/ jobname=msg.jobname Address SQL "Update STCTBL set current_state='UP'", "where name=:jobname" return


Component: SOPMVS