As the errortext suggests (see below) I would check if the parameters sent/received to the cobol subprog are actually correct (or that the definitions are ?)
Finn
NAT0954 Abnormal termination :1: during program execution.
TEXT:
Abnormal termination … during program execution.
EXPL:
An abnormal termination has occurred during the
execution of a Natural object program.
A common cause of this error is the use of an arithmetic operand
which does not contain valid numeric data at execution time.
ACTN:
Check program and correct error.
A NAT0954 is Natural’s handling of a S0C7 condition. You have data your Natural program assumes is numeric according to your definitions but it is not actually numeric. This could be anything in your parameter list that is numeric, packed, date format, time format, etc.
To test, change your program to receive the data in a purely alphanumeric string and display the contents in order to see where the problem resides.
as Wolfgang says, you should issue the Natural Dump command to get more details. Or use the Natural parameter DU=ON to get the abend information.
A S0C7 abend (data exception) is one possibility, but the NAT0954 can be any abend - S0C1, S0C4, user abends, etc. The called COBOL program may be linked incorrectly, it may be issuing a user abend condition, unable to address expected parameter values or whatever. You need to know the real abend code before you can resolve it.
Did the Natural link to the Cobol program ever work? If so, you have probably fouled up the contents of one or more parameters.
Have you ever called the Cobol program from another Cobol program? In other words, is there any reason to assume the Cobol
linkage section is coded correctly?
I like to do things simple. Rather than resort to a dump, why not comment out the CALL to the cobol program. Replace it with a WRITE statement
of all the parameters that will be passed. I like to write out parameters twice; once using their given format, and once with a hex edit mask. The latter is useful for locating non printable characters in “strange” places (like what might look like leading blanks in a numeric field.
Did the Natural link to the Cobol program ever work? If so, you have probably fouled up the contents of one or more parameters.
I am using this program for the first time in the testing environment.And i am pretty sure that it didnot worked for years.Same program is working in production environemnt perfectly
Have you ever called the Cobol program from another Cobol program? In other words, is there any reason to assume the Cobol
linkage section is coded correctly?
No .But the cobol program which is called by my Natural program was codded some years back and no changes were made to it
I like to do things simple. Rather than resort to a dump, why not comment out the CALL to the cobol program. Replace it with a WRITE statement
The cobol program inturn invoking IP fabric contract with another interface.Do you think we can replace it with WRITE Statement.
":The cobol program inturn invoking IP fabric contract with another interface.Do you think we can replace it with WRITE Statement.
A WRITE statement followed by a STOP.
This will achieve several things.
The WRITE statement will tell you if there is a problem with data you are passing to the Cobol program.
If the data looks okay, the problem is further down the line (not before, otherwise you would not have reached the WRITE).
Since you indicated that the “system” (Natural program, cobol program, IPFabric ) works in production, clearly the primary candidate for a problem is anything that has changed. From your posting, that would be the Natural code.
Do a code compare to see if the production code and the test code match.
Last Friday I had to call a COBOL program from Natural in BATCH (OS/Z 370), and I got exactly the same problem:
NEXT PA0891R
PA0891R 1080 NAT0954 Abnormal termination 4038 during program execution.
After looking into the DUMP, I realized what was my mistake:
IGZ0044S There was an attempt to call the COBOL main program PPERDEC that was not in initial state
(my NATURAL program called COBOL within a LOOP)
I solved this by recompiling the COBOL program and declaring it as “re-entrant” (compiler`s parameter RENT) and the same parameter for the LINK-EDITOR IEWL:
Thank you all for your valuable suggestions.
Can you please provide me the documentation links for
Checking the Dumps, calling a cobol program , compiler options …
I usually use Google (theres also Bing from Microsoft) or whatever else Internet search engines. It is not that difficult to find the necessary info on the Web on your own, Id say…
As for the COBOL compilers options (for example), theres a link:
I am facing a similar error while executing a Natural program and getting a 954 error. From the error line number, I could see that the error was on a Line with a WRITE statement to a file (no values being written. just hard coded line). This module has been running in production for years with out any issues. I recreated the issue after getting down the code from production to development region. When I stow the module and run it in development region it works fine without any issues. From the SYSABEND, I can see that it is a S0C1 error with a reason code of 0001. I am not an expert in reading the DUMP. Any help or pointers on how to look at the dump or suggestions appreciated.
Then there may be issues with the file itself - it has run out of extents or space on the allocated volumes, or you’re switching from write to read or read to write in the same program without closing in between, or you have a permissions issue, DDNAME not allocated…
Check for other messages in the console log for issues with the file.
All we are trying to do is READ an INPUT Sequential file, do some processing and write to an OUTPUT Sequential File. I can see from the dump that it is a SOC1 error with a Reason Code of 00001. I am not able to find exact line where the error is from the Address and OFFSET in the dump. Any suggestions or documentation on how to read a dump or atleast get to the line using the Address and Offset.
Strange thing is that the 954 error is showing on a line where it is just a write statement with some plain text in the job.