OPS/MVS

 View Only
  • 1.  Logic necessary to set up a multi-step IPL.

    Posted Oct 23, 2015 02:47 PM

     

    OPS/MVS multi stage IPL.  I have read through all the posts related to multi stage IPL's that I can find.  At this point I need a little hand holding.  I am aware of the initial startup load of OPSTART1-OPSSPA00-OPSTART2, and that you can define a custom rexx to be executed from AOFINITREXX, but I would like to know the logic that actually initiates a standard IPL.  I have also read through most of the SSM doc in the automation users guide. 

     

    I am looking for where the logic comes in to initiate the startup of the tasks.  My theory is to either add a column to the resource table to group the tasks, base for necessary tasks, then DB2 or Onlines for post base startup.  Depending on where the task startup initiates, what is the most efficient way to modify the start process?   Should I modify the standard process or create a new local process?

     

    Thanks

    Chris Allamon

     



  • 2.  Re: Logic necessary to set up a multi-step IPL.

    Posted Oct 23, 2015 04:26 PM

    Hello Chris,

     

    When time permits please review in the User Guide on Chapter 7 "Using System State Manager" the item "Step 7: Perform an IPL with SSM" for sections "Perform a System Shutdown" and "Perform a System IPL".

    Let us know if these sections of the User Guide can help you implement your IPL and Shutdown procedures.

     

    Regards, Cesar



  • 3.  Re: Logic necessary to set up a multi-step IPL.

    Posted Oct 26, 2015 09:02 AM

    Cesar, the SSM IPL doc you mention is pretty slim on detail, I am looking to get opinions on what others have done to allow for a custom IPL.  At what point in the start up process do I perform the intervention to customize the start?  Basically, at what point does stateman kick in and what is called that actually decides on what tasks to start?   Should stateman be turned off, run a custom rexx from AOFINITREXX, that starts all the tasks that are needed for a base IPL, then turn on stateman after a query is sent to Operations to see if they want to continue with a full IPL?

     

    where is the initial logic located that decides what tasks to start through stateman and is it alterable?

     

    Thanks

    Chris



  • 4.  Re: Logic necessary to set up a multi-step IPL.

    Posted Oct 26, 2015 03:32 PM

    Chris,

     

    Is good you are requesting other client's input but still let me give you some answers to your questions.

    As documented in the manual once CA OPS/MVS initializes and SSM becomes active, the SSMBEGIN request rule executes and prompts you to choose a startup option.

    If you look at the sample code provided in your_hlq.CCLXRULM(SSMBEGIN) you will notice that a call is made to the sample OPS/REXX code SSMBEGUX.

    User written code can be added to set the desired states of Stateman resources without modification of the standard SSMBEGIN request rule.                               

    Keep in mind that at this point of CA OPS/MVS startup internal checks have been already performed to confirm that SSM can be activated as the environment it needs to run has just become available.

    As an example the ability to read and update RDF tables that SSM uses to keep track of resources and keep the actions performed when a mismatch between current and desired status takes place is guaranteed.

     

    I will leave the rest of the community to answer your question if the parameter AOFINITREXX could be used to interfere SSM normal processing but SSMBEGUX sounds like a better option.

     

    Hope this helps Chris

    Regards, Cesar



  • 5.  Re: Logic necessary to set up a multi-step IPL.

    Posted Oct 28, 2015 12:49 PM

    As Cesar states, the logic you are basically looking for is in the SSMBEGUX member. It sounds like you are looking to create something similar to what we did at my shop. We wanted a base system so that we could have the fewest tasks running but still log in and do things we needed to. I was originally going to try a dummy task and categorizing the tasks by type but neither seemed like good methods. I finally stumbled onto something that made complete sense and seem so simple when I thought of it that I couldn't believe I hadn't thought of it before. What we did was defined which tasks would be in our base system. After that we set all of the base system task IPL_STATE to 'UP' and all the non-base system tasks IPL_STATE to 'DOWN'. So now when we IPL the base system automatically starts. When it is up, <insert highlighted message of your choosing here>, we issue the SSM STARTSYS command which brings up everything else. Likewise at shut down we issue the SSM SHUTMAINT command to bring everything but our base system down. This way we can do maintenance and other things before the whole system comes down. When we are ready we issue the SSM SHUTSYS command and bring the rest of the system down. It has worked really well for us so far and avoids doing any special logic or jumping through hoops.

     

    Additionally, if you wanted to start individual groups from the base system point on, DB2 or CICS for example, I would then suggest setting up some TYPEs for each of the groups of tasks and then issuing the SSM ST TYPE=typename command.

     

    The SSM commands I am referring to are found in the SSMCNTL sample rule.



  • 6.  Re: Logic necessary to set up a multi-step IPL.

    Posted Nov 09, 2015 02:56 PM

    Travi,  Sorry I was out for a while.

     

    So did you put all the logic in the SSMBEGUX?  So that it loops through an SQL starting the tasks with the IPL_STATE of UP and verifies that they are all up, then puts out the WTOR and finishes the IPL, depending on what the opers reply?

     

    Thanks

    Chris



  • 7.  Re: Logic necessary to set up a multi-step IPL.

    Posted Nov 10, 2015 12:48 PM

    No. In fact nothing went into SSMBEGUX. All we did was set the IPL_STATE in the STCTBL to 'UP' for each resource we wanted to be in the "BASE" system. Every other task we set the IPL_STATE to 'DOWN'. At IPL the sequence goes as follows:

     

    1. Stateman initializes and copies IPL State to Desired State. This ends up with Base system tasks with a Desired State of UP and non-base system tasks with a desired state of IPL.

    2. Anything with desired state of IPL is set to the current state which should be down.

    3. The base system tasks start based on STCTBL_ACT.

    4. Once the final task in the base system is UP the operators then issue the command SSM STARTSYS. This pause in the startup will allow you to perform maintenance tasks, etc. before the rest of the system comes up.

    5. STARTSYS sets ALL desired states to UP. Since the base system tasks were already up, no harm no foul. All the tasks still listed as DOWN are now set to desired state of UP and follow the normal Stateman method.

    6. Once all of the additional tasks are UP, the system is UP and ready to use.

     

    Now, this is a two stage IPL with a Base System and Secondary System. If you want, you can create more commands similar to STARTSYS for each group of resources you wish to start. STARTDB2 would start your DB2 regions. STARTCICS would start the CICS regions*. If you use the TYPE column to categorize your resources these start commands could be as varied as the TYPE and could really multi stage an IPL.

     

    *Note - do not confuse these with the REXX samples provided by CA for use with Stateman.



  • 8.  Re: Logic necessary to set up a multi-step IPL.

    Posted Dec 11, 2015 07:01 AM

    We added columns to all resource tables for our specific situations: MAINT_STATE DR_STATE or whatever situation you may think of.

    We then added extra choices to the standard SSMBEGIN options, like M(aint) or D(r), which then select those other columns as source to be copied over to DESIRED_STATE at reply. Gives full freedom per resource in every situation.

     

    Oh, and added an SSMBEGIN command rule to trigger SSMBEGIN outside IPL from console to get to the next stage (and yes, theoretically that could be reverting back to an earlier state)

     

    Marcel van Ek

    Atos