CICS failing due to Natural


I am a Natural programmer.

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:

  1. What could have caused the problem? And why did it only happen now after 10 years?
  2. Why did a simple STOW command solve the problem? What did it have to do with the CICS error?

Thank you very much! :slight_smile:
CICSFMS1 Error Messages.doc (58 KB)

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.

Thank you for your immediate reply. :slight_smile:

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.

Sorry, with

I am talking about the Natural runtime environment.

When you say this subprogram is “invoked by a PowerBuilder object” I assume this is
a RPC call, and not terminal driven ?

Sorry again, I don’t know what you mean by “RPC”. If you mean how Powerbuilder communicates with Natural, it’s through a middleware called Openlink.

RPC = Remote Procedure Call

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. :frowning:

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.

What do you mean by “zaps”? :smiley:

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. :smiley:

It depends.

A local bufferpool (which is a storage area within CICS) - yes.

When your site operates a global bufferpool (not allocated in the CICS region) - no.

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. :slight_smile:

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:

  1. Without issuing a purge-reload, or re-STOW-ing of objects, how else could the present version in the bufferpool be overwritten?
  2. What could corrupt an object in the bufferpool?

Thank you in advance sir Wolfgang! :slight_smile:

Correct :wink:

When the bufferpool runs full an aging algorithm will determine objects to be replaced by newly loaded ones.

After all the bufferpool is just a storage area, so …

Just noticed your IT department opened an incident with Software AG support anyway yesterday,
and basically received the same answers :wink:

So are you saying that it’s possible that the object stored in the buffer pool at the time of execution was stored in a “bad cluster” of the storage? :slight_smile:

Yeah, we’re all at wits-end trying to figure this out. :smiley:

No, what I was trying to say that it will be hard to figure out WHO tripped over a certain storage area.

Again, I apologize if I don’t understand what you mean by “WHO tripped over a certain storage area.” :stuck_out_tongue:

Can you explain further?

Thank you very much! :slight_smile:

What I was trying to say is that it usually is almost impossible
to find out why a bufferpool object has been corrupted, and by whom.