Since I started in CICS almost 5 years ago (has it been that long already!) I’ve always just accepted that if I’d forgotten to activate my VTAM applids before I brought a CICS region up, the quickest course of action was just to activate my applids and restart CICS. Now, I had always just assumed that there was a better way of doing that but there was always something else more important to worry about. So, no idea what we were discussing at the time, but somehow Grant managed to slip the solution to this one into our conversation. Now I am sure this is just the most obvious thing in the world to most of our readers but I thought I’d share the solution anyway.

So the problem, you bring up CICS and you spot in the JESYSMSG log:

DFHSI1592  XXXXXXXX CICS applid not (yet) active to VTAM.               
DFHSI1572  XXXXXXXX Unable to OPEN VTAM ACB - RC=00000008, ACB Code=5A.

You utter an unrepeatable curse (just loud enough so that the colleague next to you raises his head, but not so loud that the sysprog overhears you and starts revoking your privileges) and dig out that SDSF command for activating your applids. Or if you are not the sysprogs drinking buddy, submit a ticket or offer baked goods, liquid refreshments or anything else that might be accepted as payment in kind.

Now normally, this is where I would kill/cancel/purge bring my CICS region gracefully to it knees and restart so everything comes back up and CICS successfully re-opens my VTAM ACB. Now, however armed with our new-found solution, we can simply just go to our SDSF panel and run the command:

/f <CICS region jobname>,cemt set vtam open

Marvelous eh! Now depending on your setup, you are now:

1. Annoyed that you read all the way down the post just to find out something that obvious
2. Celebrating this wonderful insight and are off to tell all your CICS friends how wonderful the blog is
3. Once again uttering unrepeatable curses at your 3270 emulator

For those who are experiencing 1 or 2. Thanks for reading!

For those now cursing, please read on. I’m assuming you just received the following message on SDSF:

+DFHAC2015  XXXXXXXX Console <userid> has not been defined to CICS. Input is ignored.

To be able to communicate with CICS from SDSF, you need to install a terminal into the CICS region with the CONSNAME attribute set to that of your TSO userid. You can find out a little more on how to define this here:

https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/topic/com.ibm.cics.ts.resourcedefinition.doc/terminals/dfha23q.html

Remember to add your terminal definition into one of the lists defined on the GRPLIST SIT parameter on your CICS region so it actually gets installed. Sadly, this is one of those problems that can only be solved if you have already created the required definitions. With your trusty terminal now added, you should be safe to repeat the steps above. If all goes well you should see something like:

RESPONSE=XXXX                                              
 +                                                         
 Openstatus( Open )                                      
 Pstype(Snps)                                            
 Psdinterval( 000000 )                                   
 Grstatus(              )                                
 Grname()                                                
 NORMAL                                                  
 RESPONSE: NORMAL TIME: XX.XX.XX  DATE: XX/XX/XX         
 SYSID=XXXX APPLID=XXXXXXXX

So failing to batter the problem into submission with the normal tools, a kind colleague pointed me at the MVS SLIP (Serviceability Level Indication Processing) operator command. A few painful moments passed as the correct command incantation was established and lo and behold I received a dump with the PSW pointing handily at the module that changed the storage location. Thankfully we use eye-catchers at the top of each internal method so detecting the module is simply a matter of browsing the dump at the address suggested and scrolling up.

Generally within the CICS TS team the most commonly used tools for debugging problems are CEMT, CECI, IPCS, AUX trace and an internal interactive debugging tool called Source Language Debug (SLD). In CICSPlex SM development/service we also use the customer-provided COD0 transaction to quickly walk-around the system control blocks and dump out specific data.

The SLIP command is definitely one tool I’ll be adding to my toolbelt. What tools can you not live without?