Between 1997 and 1998, I worked at Seer Technologies, a US software firm, from their London offices. I was actually rarely in the office, I spent my time "on the road", out troubleshooting customer installations, in the UK and in Europe. The below is an ancient article, written in 1998, probably intended for publishing in our in-house magazine or newsletter. Well, it never got that far - today, 10 November 2026, I have just stumbled over it again. It is 28 years ago - I expect everyone involved will have long gone on to pastures greener.
I was assigned to one of our UK customers to do HPS support. In fact, I was meant to replace an in-house support person, who had been seconded to another project. One of the first things I got to look at were the local 'procedures' for static linking. As you will know, by statically linking all the rules and components belonging to a particular transaction, we eliminate the over-head implicit in dynamic calling, thereby speeding up the transaction. This is a well-known and widely used method.
However, at this particular client, I found a procedure for excluding certain components and certain rules from the static linking, which I initially thought to be very odd. The explanation was as follows:
"well, we found out that we couldn't link these rules and components statically, coz when we did, the transaction abended. So we created a procedure for excluding these from the link."
Notice that there is no explanation of WHY the statically linked transactions abended. This made me very curious, and I started digging into this. Initially, the first thing all the excluded components had in common was that they were all making calls to an external system called Hogan. Fine. All the calls were done using EXEC CICS LINK, so nothing wrong with that.
I then did a few trial runs of some statically linked transactions. And sure enough, they all abended. System abend code 0C4. Aha, protection violation! So, armed with this fact, I got hold of the CICS dumps, and started analysing those. And it turned out that the 0C4 was caused by a tiny little module, only a few bytes long. It was trying to modify its own storage.
This is obviously bad coding practice, but not exactly prohibited. That is, unless the entire module happens to marked REENTRANT, and we happen to be running in CICS 4.1. When CICS 4.1 loads a re-entrant module, it is placed in read-only storage. And you CAN'T write to read-only storage. Hence the 0C4 abend.
Right, so I looked up the source for one of the components, and the little self-modifying module. It turned out to be a utility (a la HPSADDR), that simply takes the address of one argument and returns it in another. About 20 lines of assembler code. And, as I had already suspected, this particular module was NOT re-entrant. It had a 4 byte save-area, in which the programmer saved the address of something or other. So, when this module was linked with the rest of the rules and components (that are re-entrant), the link-editor would have complained, but not loudly (rc=04). And the effect would be that the entire statically linked module would be marked re-entrant, but without actually being so.
To fix this, I modified the assembler module - in fact, reduced it by a few lines and made it re-entrant. Eureka! - we could now statically link everything, make it re-entrant and got no abends in CICS.
This particular customer had created a very elaborate and time-consuming procedure for working around a problem, rather than actually identifying and resolving it. The procedure had been in place for quite some time, and was in the process of being moved into the client's 5.3 environment. It is likely it would have been in place for years to come, creating an unnecessary workload in maintaining the list of rules to be excluded, and potentially creating a performance impact.
Thus, when you come across a problem, don't just try to solve the problem. Do not be obsessed by 'just getting it to work'. This may create a lot of unnecessary work, and will perhaps only hide the problem. When you come across such a problem, identify it, then understand it, and only THEN try to fix it. What had happened in this case was - "oh, we have an 0C4 abend. Hmmm, can't do much about that. Let's do something else." - no-one had attempted to understand WHY they were getting this abend.