OPS/MVS

  • 1.  CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Posted Jun 30, 2014 10:51 PM

    The start command for initializing various system resources within System State Manager is usually the exact format each and every time the resource is started. However, there are times when a start command other than the ‘normal’ start command must be issued, such as starting a CICS region with a COLD option, or using a different option on the start command for a particular resource if it is being issued on a disaster recovery system. As there are many different ways you can customize your automation to implement this type of logic within SSM, you should always utilize the ACTMODE functionality to cause SSM to trigger different actions for the same resource state condition.  Using the ACTMODE functionality will ensure that your SSM automation is running effectively and efficiently.

     

    The outline below will demonstrate the steps needed to configure SSM to issue a ‘S jobname,START=COLD‘ command when needed instead of the normal ‘S jobname’ command when the CICS regions are in a DOWN_UP state condition. Use this outline to assist you with the effort of utilizing this ACTMODE functionality within your SSM environment when this type of logic is needed.

     

    Assuming the normal DOWN_UP action for a CICS region (TYPE=CICS in resource table) is ‘S jobname’, but for a COLD start condition the command to be issued is ‘S jobname,START=COLD’ , follow these steps with SSM to implement this logic:

     

    1.       Repeat current ‘normal’  DOWN_UP  action within the SSM action table and define an action mode value to represent a cold start (COLDSTRT)

     

           ACTION_PROCESS          : ACTION

                     ACTION_CURRENT          : DOWN

                     ACTION_DESIRED           : UP

                     ACTION_MODE                 : COLDSTRT        

                     ACTION_RES_TYPE        : CICS

                     ACTION_TEXT                  : MVSCMD("START &JOBNAME,START=COLD")

          

    2.       Enable a SELECT switch to cause SSM to process a MATCH event within the SSM action table when a cold start is being performed:

     

                     ACTION_PROCESS         : SELECT

                     ACTION_CURRENT         :  DOWN

                     ACTION_DESIRED          : UP

                     ACTION_MODE                : COLDSTRT         

                     ACTION_RES_TYPE       : CICS

                     ACTION_TEXT                 : PROCESS(“MATCH”)

     

    3.       Define a MATCH event within the SSM action table to reset the  ACTMODE column so that the normal default DOWN_UP  start command will be used in non COLDSTRT conditions:

     

                     ACTION_PROCESS        : MATCH

                     ACTION_CURRENT        : UP

                     ACTION_DESIRED         : UP

                     ACTION_MODE               : COLDSTRT        

                     ACTION_RES_TYPE      : CICS

                     ACTION_TEXT                : SETCOL(“ACTMODE,ACTIVE”)

     

    4.       Update or create procedures to update the ACTMODE column to initiate a COLD start of a region the next time it is restarted (assuming this was for job CICSABC and it had to be canceled during shutdown) . This will cause SSM to  select the COLDSTRT action that was implemented above. After reaching its UP_UP state the ACTMODE setting will be reset to ACTIVE to reset the DOWN_UP action back to the normal start command.

     

      address SQL

                    “Update STCTBL set ACTMODE = ‘COLDSTRT’ where NAME=‘CICSABC’ ”



  • 2.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Posted Jul 01, 2014 06:37 AM

    Hi Dave. How is that more efficient than just defining an DOWN_UPCOLD action in your action_table and set the desired state to UPCOLD? I understand how it works with ACTMODE, but it makes things more complex, esp. for operators that do not have the full SSM insight and/or knowledge.



  • 3.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Posted Jul 08, 2014 12:11 PM

    Hi Marcel, First thank you for the feedback on the Tuesday Tip info. Good to see someone is reading! The point here is to do this type of action processing within the ACTION table as you are doing with DOWN_UPCOLD setup and I assume setting DS=UP in UP_UPCOLD action or some other variation of actions in the table.I was referring to logic that sets variables and then references these variables in the startup script as well as other forms of logic that did this 'outside' of the SSM action table. So the ACTMODE has no advantage for you in this case. If anything, just illustrates another tool in the tool box.

     

    Dave



  • 4.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Posted Jul 16, 2018 06:34 AM

    Dave, Marcel,

     

    As we currently do not have our CICS regions as STCs, would you recommend Dave's or Marcel's technique for when we convert?

     

    As I understand both solutions, Dave's says 'Next time you start this CICS region (whenever that may be), do a cold start' and Marcel's says 'Do a cold start now".

     

    Thanks,

     

    Steve

    @MarcelvanEk



  • 5.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Posted Jul 16, 2018 06:29 AM

    Hi Dave,

     

    Thanks for this - it looks interesting and a possible solution to our 'Convert CICS jobs to STCs' project we are initiating. It's using features of SSM that I've not used before and I want to make sure I understand to process correctly:

     

    The 'SELECT' entry in the ACTION table makes the 'MATCH' entry 'active' so that when the relevant CICS region reaches CURRENT_STATE=UP (and therefore MATCHes the DESIRED_STATE), the MATCH action fires to set the ACTMODE for this resource in the STCTBL to ACTIVE (is ACTIVE the default? Currently my ACTMODE for CICS is blank).

     

    I was originally not sure because I read (in  the 'PROCESS EVENTS section of How to Specify and Store Actions - CA OPS/MVS® Event Management and Automation - 12.2 - CA Technologies Documentation ) that MATCH events  "Occurs once when the current state equals the desired state for the first time. " but your code implies that MATCH events are only processed once they are enabled via a  PROCESS(“MATCH”)., but what enables the SELECT event?

     

    " A SELECT action should be used to issue a PROCESS command that enables or disables subsequent process events as needed to implement your automation strategy." Does this mean that 'SELECT' events are always active but other types of event have to be enabled? 

     

     

    Thanks, 

     

    Steve

     



  • 6.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Broadcom Employee
    Posted Jul 17, 2018 11:52 AM

    Hi Steve,

     

    Yes, it is true that other "ACTION_PROCESS"s have to be activated by a previous "SELECT".
    So, for the "MATCH" action to occur there has to be a previous SELECT with PROCESS(“MATCH”) action.

    Regards,
    Mario

     

    Carlos Mario Filho
    Principal Support Engineer



  • 7.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Posted Jul 18, 2018 03:46 AM

    Thanks Mario,

     

    Sometimes the ACTION table editor (invoked via option 4.11.1 and then selecting the SSM table with AE) does not always appear to take my commands. It's almost as though SSM only refreshes an internal copy of the table at certain intervals? I was convinced that the 'MATCH' function wasn't working until I was half-way through composing a case for CA support when it suddenly started working.

     

    Have you ever noticed this behavior?

     

    Thanks,

     

    Steve



  • 8.  Re: CA OPS/MVS Tuesday Tip: Issuing different start commands for a SSM defined resource

    Broadcom Employee
    Posted Jul 18, 2018 12:44 PM

    Hi Steve,

     

    Can it be that you have actions that invoke request rules that have some type of wait in the code? This type of thing may cause this behavior. 

    It can also be the system was too busy at the time you changed the tables or perhaps the action itself required some resource that was not available at the moment. For example, if your action was the execution of a REXX program it went to the execution REXX queue and took some time to be serviced. 

     

    Regards,

    Mario