Hello all!
The past few days some of our users are getting NAT0932 without any reason. The crazy thing is: The regarding programs were not stowed or catalogued.
The error is not reproduceable. We deleted the buffer pool, we recataloged the program itself. Nothing helps. Any ideas?
Matthias
Hi Mathias;
When the obvious is not applicable, try the impossible (or at least unlikely).
What time of the day do the 932’s occur? Anything unusual about that time of day (e.g.a big job that executes then).
Assume that the specified program is not the problem; look at subprograms CALLNAT’ed by the specified program. Are any of them being worked on? How about Maps? Are any being redesigned that are part of the existing system?
Are there any modules that utilize dynamic programming (ampersand “variables”)?
steve
Hi Steve,
Thanks for answering.
No there’s nothing unusual at that time.
Example:
Today at 08:02am we got a NAT0932 for a program which was stowed on 2012-09-09 the last time. The maps were stowed at the same time. Since then adabas was rebooted. So there is no “old” session that could get a NAT0932 today.
I checked the modification time of the GPs in fuser: The latest stow of any program in the library (i.e. the whole System) was on 2012-09-13…
I still got no idea what’s going on. 
Matthias
Hi Matthias,
Natural throws error code NAT0932 when the timestamp of the object code is changed. This happens by cataloging (CAT, STOW) the sourcecode. This also happens, if you replace the existing object code by an object code with a different timestamp (via SYSMAIN e.g.). This is my experience on Natural/mainframe.
So the following might happen: Someone wants to make modifications to the source/object code. First, the person copies the original source/object code to another library. Then it makes the modifications.
Afterwards the person copies / moves back the original Natural modules (including the directory information) into the library. Natural throws error NAT0932. But the timestamps of the directory information make you believe that no Natural modules have ever been changed.
Hi Helmut Spichtinger,
Good idea but that’s out of the question. No one changed the code, copied or stowed the program. By the way: SYSMAIN-Copy or SYSMAIN-Move on Solaris would have changed the modification time on file system level.
Matthias
Perhaps, RECAT=ON ?
Hi,
Are there multiple copies of the same program in different libraries , used as steplibs?
Peter
No. RECAT is OFF, no other program with the same name in any other steplib.
Hi Matthias;
I do not know if this is practical in your environment; but, if it is, you might try it.
Do a CATALL of everything in the library. Confirm that nothing is being accessed in another library via steplib (if so, recat that as well.
Wait and see if the 932 occurs again. If so, see if the date is the same as the catall. If the date is different, find the offender. Suitable punishment; send them to Oktoberfest with a dribble glass. :lol:
steve