MQ Channels and queues in SSM?

[Steve Ives]

I did do a search but didn't find an answer to this:

Is anyone using SSM to manage their MQ resources (Channels and queues), probably via a separate SSM table and if so, would you recommend it and whwat are the advantages and disadvantages?

Thanks,

Steve

[Dave Gorisek]

Hi Steve,

The decision to keep Onlines (MQ,CICS,DB2,Websphere,etc) within the primary STCTBL where all of the core resources reside is really up to you and how it fits into your environment specifically with how the resources are maintained (by someone that supports/maintains all of the resources, by groups or teams - CICS team, DB2 team,etc). Internally, I do not believe there are any pros/cons meaning that the SSM component is not more efficient one way or the other (single table versus multiple). I recall back in my CA days doing some SSM benchmarking with both types of setups simulating hundreds/thousands of resources and didnt see any real performance differences.  

We do segregate onlines into tables at current shop  - STCTBL for core resources, CICSTBL, DB2TBL,etc. Primary reason is that we have additional columns added needed to perform different types of decisions/automation based on the online resource. For example within the CICSTBL we have ENV and APPLICATIONS columns where we specify running environments (Production, Testing,Integration,etc) and list corresponding application types for different CICS regions. So the pro here is that these extra columns are only in the CICSTBL and not the others versus having one STCTBL with these extra columns added, but NULL or N/A for all the other resources. The con with multiple tables is that you will have to update any rules/pgms that manipulate the STCTBL to directly update the corresponding table, or invoke an external subroutine (like the SSMQUERY sample pgm) that determines what table a resource resides and then substitute the table name within the SQL insert/update/select statement. For example in your SSMMQ rule that sets the CS to UP/STOPPING for MQ regions, you can hardcode MQTBL name in the SQL update, but if using SSMSTART/SSMSTOP/SSMCNTL to manage resources , you'll have to add logic to invoke SSMQUERY to see what table the specific resources reside so that the correct table can be updated.

Good luck!

Dave

[Steve Ives]

Thanks Dave for the answer. Sorry - I didn't explain myself very well. We currently don't use SSM at all to manage our MQ channels and queues and I wanted to know the pros and cons of doing so.

Thanks,

Steve

[Dave Gorisek]

Hi Steve,
I'll give you my 'spill' from both sides of the fence - While supporting OPS and SSM at CA, my view was 'put everything in SSM' so in your case here that would be the MQ mstr and channel initiator asids. For the most part I'm still an advocate of this approach, because ideally with SSM you have one focal point to control/maintain/monitor all your system critical address spaces. No guessing of what is started at IPL, where it is started, start/stop commands, what the prereqs are, what it is (assuming you include other info columns in your SSM tables such as DESCRIPTION,OWNER columns which are short blurbs of what it is, owner, any special start/stop details), etc, etc. Now here on the 'user' side of the fence, it comes down to 'what is the less pain for the automation team, while creating the best automation to support/maintain the system' and make everyone happy! I would at least look at including the MQmstr regions into SSM (either STCTBL or MQTBL as mentioned before) and leaving out the internally started/stopped channel initiator asids. Treat the MSTR regions as you do any other resource you add into SSM - Prereqs, Current state monitor rule to set CS=UP/STOPPING, start/stop commands in action table (SHUTMQ OPS/REXX works good for shutdown but may depend on env setup). 'IF' you want to look at putting the channel initiator asids, you will have to take some extra steps to ensure that normal start/stop actions do not actually issue start/stop commands since the CHINs are controlled by the MSTR regions. Off the top of my head -Setting IPL_STATE to something like STRTMSTR  and then creating an UP_STRTMSTR to SETCOL DS=UP to address IPL time assuming IPL_STATE of the MSTR is UP. This of course will allow MQMSTR to internally start the CHIN and once the CS state rule for MQCHIN sets CS=UP, SSM will set DS=UP. You also want to ensure the SSMSTART rule (or any SSM rule firing on S jobname) allows for MQMSTR to internally issue S MQCHIN (default SSMSTART should be set up). Last thing is to address the direct setting of DS=UP/DOWN for the CHINs as set from user via your SSM tools (OPSVIEW panel, SSM SJ/PJ JOB=MQCHIN via SSMCNTL rule etc) and to ensure the correct UP_DOWN or DOWN_UP 'action' fires - Do nothing for MQCHINs? Maybe set DS=STOPMSTR if IPL time or MQMSTR is also stopping then having DOWN_STOPMSTR action that sets DS=DOWN? Some other action?? May be some other pieces I'm missing here, but hopefully enough here to see that you have to cross more T's, and dot more I's if you also manage the CHINS.

Good Luck!

Dave

[Steve Ives]

Thanks Dave. What about putting each channel & queue into SSM? The would seem to help with situations where we have to so SSL changes (fairly frequent here) and other situations where we are asked to validate that everything that should be up, is up following a change, but we have nearly 300 channels and 5,000 queues.

[Dave Gorisek]

OK...so managing the 'function/processing' of the resource and not its own state (up/down/failed). This will come down to the amount of juice- you get from the 'squeeze'. In this case specifically the 5000 queues - is it worth the effort of setting it all up as a SSM application and if so, what is the impact on SSM? Perhaps its better to just manage with monitor rules (some MQ message of them starting/stopping or some MQ query command to extract), or even using a non SSM RDF table. Like to get some more details especially the process of SSL changes. I'm tied up today, but I'll contact you early next week to chat, and assist.