View previous topic :: View next topic
|
Author |
Message |
shrivatsa Warnings : 1 Active User
Joined: 17 Mar 2006 Posts: 174 Location: Bangalore
|
|
|
|
Hi All,
My Program is failed with MAXCC 0012 with below information
Code: |
IEF142I XXXXXXX STEP040 - STEP WAS EXECUTED - COND CODE 0012 |
Earlier same program was completed with MAXCC00
We found that code changes has been done for below moves
Code: |
MOVE from S9(09) COMP-3 to 9(08)
MOVE from 9(09) to 9(03)
and
Move from 9(04) to 9(02) |
other than this no changes has been made, is this failing due to the above truncation moves?
No other Information is SPOOL is provided by the program except the IEF142I
Please let me know all your inputs on this.
Thanks |
|
Back to top |
|
|
shrivatsa Warnings : 1 Active User
Joined: 17 Mar 2006 Posts: 174 Location: Bangalore
|
|
|
|
One more information that the program output file is created properly, as the truncation fields we haven't used in our output. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Does the program have MOVE 12 TO RETURN-CODE in it?
COBOL assumes you know what you're doing -- if you move 9(09) to 9(03), any truncation will not generate any kind of run-time error code unless your program does it. Using SIZE ERROR with an arithmetic statement allows you to pick up on truncation problems but MOVE is not one of the statements that can take SIZE ERROR coding. |
|
Back to top |
|
|
shrivatsa Warnings : 1 Active User
Joined: 17 Mar 2006 Posts: 174 Location: Bangalore
|
|
|
|
No in program we haven't moved any return code in case of any fail.
I am still wondering why this is happening. As these are the only changes happened to the program which I listed.
Before that it was completing with MAXCC00. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
In this case, you have some investigation ahead of you. If the program is not setting the return code, then something being called by the program is setting the return code. You'll have to look at what is being called by the program, locate the source for each called program, and determine which is causing the 12 return code. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
is the program being invoked via IKJEFT..
or
directly from the EXEC jcl statement. |
|
Back to top |
|
|
shrivatsa Warnings : 1 Active User
Joined: 17 Mar 2006 Posts: 174 Location: Bangalore
|
|
|
|
Program is called with EXEC PGM=Program Name.
Important thing I noticed is that none of the called program has hard coding of 12 when it fails actually program complete successfully processing of all the records which is ; delimited file produced. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Is STEP040 your cobol program?
Beside that show the original code and the updated code. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
As long as you are convinced that none of the called programs nor the calling program are setting return code 12, you cannot solve the problem. Proper attitude is the hardest part of debugging, and the one most people have trouble with. If your program was working correctly, and you changed something after which the program is no longer working correctly, your attitude should be that you introduced a problem. Maybe you merely uncovered an existing bug in the code, but as long as you state that things with YOUR changes are fine, you're not going to figure out why the return code 0012.
My advice: either accept there's something wrong and really try to understand what, or change the system to allow a return code 12 to reflect a good completion (yeah, this approach may lead to other problems in a week ... or month ... or year -- but at least you don't have to actually think something is wrong in the code you wrote). |
|
Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
Okay, for an experiment - take the changes back, you talked about, from your current module and execute it again. Don't execute the program from prod instead from your current package (if you're using changeman) and see what happens? If all is not well, we're back to the square one but then it was just an experiment! |
|
Back to top |
|
|
ovreddy
Active User
Joined: 06 Dec 2004 Posts: 211 Location: Keane Inc., Minneapolis USA.
|
|
|
|
Hi,
IEF142I shows that some error has occurred and it was supressed. Copy your JESMSG log and SYSOUT from SPOOL and paste here that helps to find out what happened.
Or you can even try XPEDITOR or INTERTEST.
Thanks,
Reddy |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Quote: |
IEF142I shows that some error has occurred and it was supressed. |
please refrain from posting wrong suggestions/explanation/considerations
you will be just wasting resources and everybody' s time
read the messages manual about the meaning of the IEF142i message
in the context it means only that the cobol return code special register was clobbered
the return code is just and only a feedback to the JCL with no absolute inherent meaning
it' s just a convention to use 0 as a no issues/no errors indication
for example
once upon a time when schedulers were not readily available
if wanting to execute different programs based on the day of the week it
was customary to have the first step execute a program which would issue a return code from 1 to 7
depending on the day of the week
so that the following steps could be properly executed/skipped using the jcl COND construct
so a non zero return code infer/suggests/implies only what is written in the program documentation,
nothing less nothing more
I just checked Your profile... better stick to music and stay away from programming |
|
Back to top |
|
|
|