Our CICS Application has been experiencing some problems. When we checked with our IT, the CICS server fails whenever a certain Natural program (a subprogram that has been executing flawlessly since 2002…cataloged date is 2002-03-21) is invoked by the front-end program (PowerBuilder object). According to IT, CICS issues an error message (please refer to the attached file for details on the CICS error).
What we did was to STOW the subprogram involved and all the other Natural objects used within that subprogram and uploaded the recompiled objects to our production environment. After that, the CICS server did not fail anymore.
Can anyone explain the following:
What could have caused the problem? And why did it only happen now after 10 years?
Why did a simple STOW command solve the problem? What did it have to do with the CICS error?
There’s really no way of finding the cause without knowing WHERE in Natural the S0C4 happened,
so one would either need the CICS transaction dump, or, when Natural is run with DU=OFF, check
with the DUMP command inside Natural.
Sorry, but I don’t know what you mean by “knowing WHERE in Natural the S0C4 happened”. I can only say that the error would seem to point to a certain line in the source code where the Natural subprogram calls another subprogram.
At any rate, what I was trying to say is that error like this cannot be solved or even
reasoned by looking at just the CICS messages and knowing the line of Natural code
causing the abend.
This requires at least the CICS transaction dump, then open an incident with Software AG
support and forward the dump for analysis.
Back to your initial question “why does it happen after 10 years” - did your site upgrade
Natural when this started to happen ?
Unfortunately, IT doesn’t use transaction dump as it adds additional overhead.
Actually, our Natural version was upgraded last 2008. Until yesterday, we never encountered any issues similar to this. However, it would seem that during the upgrade, IT did not perform a recompilation of all our Natural objects as part of their upgrade activities. I could still see Natural objects with cataloged dates as early as 1999 still. Do you think this could be the reason?
Ok, no upgrades (no zaps either ?), then it doesn’t look like an issue with a new version of Natural.
In that case I assume you hit an issue with a corrupted object in the Natural Bufferpol,
which was “resolved” by reSTOWing the offended objects, but a simple purge of the
objects from the bufferpool (followed by a reload) would have cleared it as well.
Again, this is just a reasoned GUESS, to be sure one would have to investigate the dump.
I see. But doesn’t the Natural Bufferpool get purged automatically when restarting CICS? Whenever the CICS server fails, IT automatically just restarts it. So I suppose that whatever needs to be purged from the buffer should’ve been purged during the restart? Just second-guessing here.
According to IT, the organization uses a global bufferpool.
I’m beginning to understand the problem more clearly now and leads are starting to form now, thanks to you.
Just a follow-up question. If I correctly understand how the Natural Bufferpool works, am I right to say that when executing Natural objects (in this case a subprogram), whatever version of the subprogram is currently loaded in the global buffer pool, that is what is executed? And if the object is not yet present in the buffer pool, it loads a version from the “production” library?
If that’s the case, I’m wondering two things:
Without issuing a purge-reload, or re-STOW-ing of objects, how else could the present version in the bufferpool be overwritten?
