Chris’s post about SLIP made me think about CICS storage checking and CSFE. As this blog is supposed to be for people with all levels of CICS skills, I thought I’d try and write something for beginners about CICS storage checking.
Note for Chris: Yes, it is called “storage” not “memory”!
For CICS task lifetime related storage, CICS puts some eyecatchers on the start and end of the buffer that it obtains for you. These are called storage crumple zones. If you look at some CICS storage using a tool like CEDF, you can see these at the bounds of the area obtained for your user storage. For example:
15014A80 000010 E4F0F0F1 F6F8F0F0 838983A2 979385A7 U0016800cicsplex 15014A90 000020 00000000 00000000 E4F0F0F1 F6F8F0F0 ........U0016800
In the above example U0016800 is the crumple zone. The U means this is user key storage, (you can also get a C for CICS key storage). The number after the U is the task number that owns the storage. Task number 16800 in this example. Notice that there are two occurrances of the U0016800 string – a leading and a trailing crumple zone. In this example I used EXEC CICS GETMAIN to obtain 8 bytes of storage (CICS rounded it up to 16).
When CICS obtains storage for your task – either directly because you’ve issued an EXEC CICS GETMAIN or indirectly e.g. task working storage – then CICS will setup the storage crumple zones.
When the storage is freed – again either directly because you’ve issued an EXEC CICS FREEMAIN or indirectly e.g. when your task ends, then CICS checks the crumple zones associated with the storage. If the crumple zones are not correct, then a storage violation is detected.
So if my program wrote more than 16 bytes worth of data to the piece of storage above, the trailing crumple zone would be changed. However the overwrite could occur in my program at any time, yet the error might only be detected when the task ends.
When CICS does detect the storage violation, the CICS sysprog, will then typically need to try and figure out which CICS application programmer to harass. However in order to do this, the sysprog needs some evidence as to which program is likely to be at fault. The task that suffered the violation might be the victim of another tasks errant program. If the task was long running, and the storage violation was detected at end of task, then there may be a significant amount of code or other tasks that could have run.
This is where the CSFE transaction may be able to help. For reproducable storage violations – typically on a test system – you can use the storage violation trap function of the CSFE.
Using CSFE DEBUG,CHKSTSK=CURRENT will cause similar storage checking that occurs when user storage is freed to occur after every CICS trace record is produced. So as long as your CICS is running with CICS internal trace active and the tasks are invoking CICS functions that cause trace enties to be written, then CSFE has something to work with.
When the storage violation trap is active, then when the CICS trace program writes a trace record to the internal trace table, the CICS storage manager domain will be called to check that the storage crumple zones of the current task are intact. If they are, processing will continue as normal. However if not, the storage violation trap will be tripped, and you will then get a dump.
Then armed with the handy dump and IPCS (or your other favourite dump debugging aid) you can then examine the trace to determine which programs were in control and what commands they were issuing. This should hopefully help narrow down the culprit and identify which program, and possibly even sections of code in the program deserve a close inspection.
There are other CICS facilities e.g. storage protection, transaction isolation, re-entrant program protection and EXEC command storage checking that can help with resolving storage overlays in CICS, so all is not lost if CSFE doesn’t deliver the goods. However when you do have a situation where it can be used, it can be invaluable.
An area that I have been very active in over the past 15 years or so has been technical authorship. I’ve done a lot of writing about CICS, transaction processing, debugging, and problem determination. I’ve found that this has been an effective way for me to communicate with CICS customers, and with other IBMers too. It has also helped me enormously because I have had to learn about an area before I can go ahead and write about it myself, so the act of writing has forced me to try and master the subject matter beforehand As well as working with the IBM ITSO team on redbooks and education classes, I have also been published in a number of external journals and publications. I’d be interested in knowing what experiences other authors have had in writing and publishing about CICS, CICSPlex SM, transaction processing or IBM System z in general. I know my fellow blogger Phyllis has been very active with her writing over the years… what about anyone else out there?
Corneel Booysen has raised some interesting thoughts on his blog about COBOL and whether or not it is killing CICS. Being classed in the “you young ones” category I hope I can perhaps offer a slightly different perspective, so I’ll take a stab at replying.
As a young developer, I have to say I’m pretty language neutral. I don’t really care what language I’m programming in and I’m smart enough to know that no language is perfect. What I love is innovating and creating smart solutions. How I get there is largely immaterial. Generally I will just try and choose the right tool for the job. With CICS I have quite a few choices and all of them have their own uses.
Any young developer worth their salt will pick up enough to get started with COBOL within a day to a week. Certainly reading the code isn’t going to cause too many problems, assuming your code is of reasonable quality of course.
Corneel mentions “the guy in the cubicle next to you created a new web application comprising of several class libraries using his favorite scripting language, deployed it then created a blog entry and proceeded to read up on the latest technology trends before lunch – while you were compiling for the seventh time…”. Well last time I looked you could use things like URIMAPS and DOCTEMPLATES to build a fairly sweet model-view-controller style web application. You don’t even need to download any libraries! Sure you might have to compile your application a few times but I promise you with some of the great new tooling available like RDz v7.1 the code-compile cycle is almost eliminated.
I actually believe the problem isn’t related to any particular skill shortage but a more general lack of bright young graduates that are interested in working with some of the most exciting hardware around; the mainframe. So how can we fix this? Well IBM is already putting a lot of effort into the Academic Initiative as well as developing and hosting the Mainframe Challenge. There also has to be a push from CICS customers all over the world to start marketing jobs aimed a new graduates that include basic training on the mainframe. Approaching universities and asking them if they could provide courses on COBOL and mainframes in general would also help.
I am constantly reading about skills shortages around CICS and the mainframe and yet rarely I see the community standing up and shouting about how they NEED young developers. The reason that CICS feels old is simply because the community has let itself feel old. I have another blog post coming entitled “Where are all the CICS rockstars?” but that is a question for another day. For the moment though think about this. You are not too old, you are experienced. The younger generation are not about to take your jobs any time soon so relax and enjoy having us around. We can’t match your experience and all we have in our pockets are youth and enthusiasm. You don’t have to be young to be enthusiastic and you don’t have to be young to be innovative. We are down here looking up at you waiting for you to pass on your knowledge but if all we get back is resentment then we are not going to hang around for long. One of my colleagues in our excellent service team once said to me after I had thanked him for passing on some of his knowledge to me, “Helping you, helps keep me in a job.” He understood that as long as there was energy, skills and knowledge around the product there would always be a place for him. Smart guy!
So help us to build the community. Get blogging, get networking and tell the IBM CICS team what we can do to help you. Remember that us “young ones” have feelings and all we need is a little encouragement to help us and you shine. The future of CICS is in YOUR hands so stand up and be counted as the leading innovators and experts that you are.
SupportPac CA8K, released on 20 March 2008, shows you how to introduce some of the very latest Web technologies into your CICS TS system. The primary technology it demonstrates is how to create an Atom feed from existing CICS data, such as a Temporary Storage queue. The purpose of the SupportPac is to show that this can be done today, using existing CICS facilities. So it uses the funky new URIMAP and PIPELINE resources to map Atom feed request URLs into CICS resources that you want to publish. In its simplest form, this means that if you want to publish some data into a feed, all that your application needs to do is write the data on to a TS queue, and then let the SupportPac code do the heavy lifting of the Atom protocol.
Now you might have thought that PIPELINE definitions were only for use by SOAP and Web Services, but that’s not strictly true. You can also configure a pipeline to execute an arbitrary program as a message handler for any protocol, and that’s just what this SupportPac does to handle Atom. But it also uses the pipeline’s XML configuration file to provide some of the Atom metadata, and to help you to specify exactly which CICS resource you want to publish, and how its data is laid out.
If you want to publish CICS data that is not in a CICS TS queue, the SupportPac lets you do that, too. It can link to a program that you provide, which can extract data from wherever it likes – from your database manager, for instance – and return it in a container for insertion into the feed. There is a sample program that demonstrates using the sample FILEA file that is distributed with CICS.
The SupportPac doesn’t only let you request data from CICS, it also lets you manipulate it using a REST interaction style. So, as well as using the HTTP GET method to request TS queue items, you can use the POST, PUT, and DELETE methods to create, update and destroy them as well. The ability to use all four of these methods in a pipeline request did show up a CICS problem, so you have to apply the fix for PK58721 before using the SupportPac.