by Brenda J. Christie with Eloy O. Cruz-Bizet
Whose Fault Is It Anyway?
Today's post has its genesis in an article which appeared in Enterprise System Media entitled, "Reducing the Potential for CICS Storage Violations." It's all about that, but it doesn't miss the opportunity to blame those careless application programmers for sloppy code which can bring an entire CICS region down with the dreaded SOc4. And yes, there are sloppy application programmers out there just like there are sloppy system programmers out there as well.
The article traces the handling of storage violations (S0c4) from the early days of CICS to the CICS/ESA architecture. It does a decent job of explaining how storage violations can occur, most likely through Getmain instructions or runaway indexes, and in the process lays the responsibility for causing storage violations on the shoulders of application developers. For example, an application programmer could write a piece of code that executes a Getmain to load a commonly used routine into memory and then perform some actions passing parameters back and forth. A sloppy application programmer could neglect to code a Freemain for the temp storage once the routine was no longer needed. However, the most likely scenario would entail creating and using an index and then referencing an address outside the scope of the index. When I say referencing, I mean writing to an address outside the index scope which would overwrite an address potentially used by CICS or some other user application. The result could be an S0c4, storage violation. This could have considerable consequences in a production environment, resulting in outages, loss of data, and possibly money. I think the system programmers dislike the difficulty of debugging the problem more so than outages, loss of data and/or money. How many system programmers still read HEX and EBCDIC? Are there any real system programmers left?
The article also describes how the advent of CICS/ESA has ameliorated storage violations. It explains that prior to CICS/ESA, the critical control blocks were actually embedded within the same space as the user application and CICS so that a storage violation had the potential to corrupt not only the user program, but other user programs and CICS itself. Looking back at this configuration it seems ridiculous to have embedded the links to next-executable instruction, links to tasks keeping CICS running within the same space. But then, we call it evolution for a reason.
The Crumble Zone
With CICS./ESA the critical addressing control blocks were moved outside the application user space and in doing so, reduced the likelihood that an application programmer could inadvertently bring down CICS with a faulty index. IBM actually came up with a fairly sophisticated Concept: The Crumble Zone. The Crumble Zone is an 8-byte storage area which contains the concatenation of a task's task number and a 1-byte literal which indicates the type of storage which follows. The Crumble Zone also proceeds the user data/application so that the user data is encased by a Crumble Zone on either side. Something like a strait-jacket. Maybe that's what the system programmers had in mind.
The article ends by discussing some other improvements IBM has developed in CICS/ESA 4.1 to prevent storage violations. These include CICS storage protection as well as transaction isolation which confines the task to its own storage and certain shared storage areas while preventing it from accessing task-related storage for other user tasks. Read more about it here.
Guess Which Team I'm On?
Bye for now,
Brenda J. Christie
No comments:
Post a Comment