View previous topic :: View next topic
|
Author |
Message |
chagoyal
New User
Joined: 03 May 2007 Posts: 11 Location: India
|
|
|
|
My Error ON Unit is as follows.
ON ERROR SNAP
BEGIN;
ON ERROR SYSTEM;
CALL Proc1 ;
CALL Proc2 ;
END;
My initialization steps have PLIRETC declared as a builtin function.
Proc1 prints the error messages.
Proc2 accepts the return code via a global variable which is set to the desired return code and prints system statistics like the system time, the proc in which the program abended etc. Proc2 calls pliretc and passes the desired return code as a parameter. It is a generic finalization proc that is invoked even if the program ends successfully. I set the desired return code to 12 before I signal any error in the program.
I am supposed to set a return code of 9 if an if condition evaluates to True and thereafter end the program. If I give a signal error statement after setting the return code variable to value 9 for proc2 it works fine but the spool shows the generic abend U4038. I want it to display the message as return code 9.
However if I don't give a signal error statement and just replace it with normal calls to proc1 and proc2 after passing a return code value of 9 to proc 2, my program runs in an endless loop until I cancel it. All the messages in the error file and sysprint are repeated. Kindly help ! |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
On a normal exit from ON ERROR, LE performs an abend to be "helpful". It's necessary to execute an abnormal exit from the on-unit. Code like this:
Code: |
ON ERROR SNAP BEGIN;
ON ERROR SYSTEM;
CALL PROC1;
CALL PROC2;
GO TO FOO; /* <--- THIS IS THE ABNORMAL EXIT */
END;
everything else
FOO: ;
END; /* END OF MAIN ROUTINE */
|
|
|
Back to top |
|
|
chagoyal
New User
Joined: 03 May 2007 Posts: 11 Location: India
|
|
|
|
Thanks Akatsukami. But that isn't something I am gonna do.
I am precisely looking for the following answers.
Whenever we call the builtin function PLIRETC() and pass a return code value as an argument, does the spool always display the return code that was passed as a parameter regardless of the value passed as the argument. In other words, does the program/job always abend with the same return code ? Isn't there a possibility of some setting defined at a compiler level or at the JCL level to abend the program with an RC of 4038 in case an error is signalled and which leads to the standard operating system action and which in this case could be to abend the job with RC 4038..
Please help ! |
|
Back to top |
|
|
chagoyal
New User
Joined: 03 May 2007 Posts: 11 Location: India
|
|
|
|
Hello Akatsukami,
I just read your first statement again. Do you mean the LE would invariably abend it with RC U4038 in case I signal an error.
In that case, looks like the approach you mentioned is the only way out.. But do you have any other alternatives ..? I am not very much convinced about the usage of GOTO.. Could you suggest me something else.. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
No. The U4038 abend (and note that it is a genuine abend, not a return code; this implies differences in the processing of later steps in the job with the COND parameter or IF/THEN/ELSE statement) comes from LE, not from PL/I. Any LE program, whether the source be PL/I, COBOL, FORTRAN, C/370, or Java, will behave this way. There is no way to change it. |
|
Back to top |
|
|
chagoyal
New User
Joined: 03 May 2007 Posts: 11 Location: India
|
|
|
|
@Akatsukami
I realize I have so much to read on LE. But Thanks for your response.. I think I'll get back after reading a bit .. ! |
|
Back to top |
|
|
sraammr
New User
Joined: 24 Apr 2008 Posts: 3 Location: hyd
|
|
|
|
Hi
I have any example here to share.
PLIRETC is used in PLI program to set the return code of the JCL .
000340 RUN_DATE1 = '500';
000390 IF RUN_DATE1 = '500'
000400 THEN
000410 CALL PLIRETC(05);
===========
In Spool, the output is as follows:
SDSF STATUS DISPLAY ALL CLASSES LINE 1-1 (1)
COMMAND INPUT ===> SCROLL ===> HALF
NP JOBNAME JobID Owner Max-RC Prty Queue C Pos SAff ASys S
xxxxx9 JOB08087 xxxxZZ CC 0005 1 PRINT L 19954
=========
The PLIRETC argument '05' is displayed |
|
Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
|
|
|
|
sraammr wrote: |
I have any example here to share. |
And how do you think this contributes in any way to the above discussion????? |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
I'm sorry for referring to a post which is really old. I'm only trying to catch up with some forgotten basic concepts.
Could somebody also enlighten as to what could have gone wrong with a normal call to proc 1 followed by a call to proc 2 ( I'm assuming that nothing else went wrong - no illogical construct caused an error to be signaled) . I don't think that a normal call to PLIRETC with an argument '09' or may be '9' could have signaled an error ( Please correct me if it can ) because of which there was may be a recursive phenomenon. Is there something I need understand or I may have missed. |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Sorry, I meant 9. |
|
Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009 Posts: 1788 Location: Bloomington, IL
|
|
|
|
goyal.chanchal wrote: |
Could somebody also enlighten as to what could have gone wrong with a normal call to proc 1 followed by a call to proc 2 |
Almost anything. Give us some more details (abend, return, and/or reason codes, error messages and numbers, etc.) |
|
Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
|
|
|
|
The whole point of coding
at the start of your error block is to enable the system to take over error handling if there is an error in your error routine. And GOTO program end is, possibly, the only legit use of GOTO in PL/1 - others may argue differently! |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
@Akatsukami I'm sorry I don't have that piece of code now. It's just a case I remember now. For this case, we had used a signal error construct only but a more pleasing approach would have been to call proc1 and proc2 without signaling the error. Now I'm trying to understand what could have possibly gone wrong then ( I will understand if this irritates you and others but I just cannot curb my curiosity now. Sorry- for the weirdness.)
Can I assume that there was possibly something wrong - may be some other error within proc 1 or proc 2 that signaled an error. But even if there was one, could this have led to a recursive call - considering the on unit?
Or do you think something else must have gone wrong? Could you please tell me one possible case that you can think of ( I will understand if you'd this taxing! )
I'm the one who had posted this question back in 2007 and after I left my previous organization, my email id and hence the username on ibmmainframes no longer work.
|
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
Quote: |
Or do you think something else must have gone wrong? Could you please tell me one possible case that you can think of |
I've seen a situation where a WRITE to a file raised the ON ERROR condition. The programmer had coded the ON ERROR unit to close the same file and this then raised the ERROR condition, the ON ERROR unit was re-driven, tried to close the file which rasied the ERROR condition..... &c. The developer had omitted the ON ERROR SYSTEM - so we had an endles loop.
Garry. |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Hi, Garry. Thanks for your response. But this ON condition already had an ON ERROR SYSTEM.
ON ERROR SNAP
BEGIN;
ON ERROR SYSTEM;
CALL Proc1 ;
CALL Proc2 ;
END;
And yes, proc 2 had close file statements. |
|
Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006 Posts: 1193 Location: Dublin, Ireland
|
|
|
|
goyal.chanchal wrote: |
Hi, Garry. Thanks for your response. But this ON condition already had an ON ERROR SYSTEM.
ON ERROR SNAP
BEGIN;
ON ERROR SYSTEM;
CALL Proc1 ;
CALL Proc2 ;
END;
And yes, proc 2 had close file statements. |
The action taken was to put the ON ERROR SYSTEM in place and then we were able to diagnose the original issue which was the file WRITE. We still got abend U4038 until we fixed the file write issue (which was a write from an area based on a pointer where the structure based on the pointer exceeded allocated HEAP storage, giving a S0C4). The CLOSE in the ON ERROR u nit tries to flush the buffer which repeats the S0C4 &c.
Garry. |
|
Back to top |
|
|
Michael Jakob
New User
Joined: 13 Mar 2011 Posts: 17 Location: Switzerland
|
|
|
|
Hi chagoyal
do I understand the situation correctly? You have an on ERROR with the calls to PROC1 and PROC2 and you call PROC1 and PROC2 at the end of the program. This caused an endless loop. Is this correct?
In this case, would you please try this:
REVERT ON ERROR;
CALL PROC1();
CALL PROC2();
RETURN; /*end of programm*/
With REVERT you prevent PL/I to call PROC1 ord PROC2 recursive in case of any condition or error.
(I wonder which condition, caused to enter the on error - on unit block.)
With kind regards Michael |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Hi Gary,
Thanks for sharing the instance and providing the valuable insight. The only thing I didn't understand is 'The CLOSE in the ON ERROR tries to flush the buffer and repeats the soc4' .. Would you have some time to explain this, if you know more. Or if you could suggest why would a close which would issue instructions to flush the buffer repeat the soc4-- it'll help me understand it better.
I took time to read the file handling in PL/1 before I'd respond to this post.
Hi, JaMi.
Yes the call to proc1 and proc2 caused the endless loop. And perhaps it was because of file close statements ( I think so - have no way of checking now ).
I was not aware of a 'REVERT' keyword before or anything ( except the programming logic ) that could prevent a recursive call. Thanks, so much. I will try this and will get back for sure. Thank you, so much.. |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Or perhaps the file close only caused a recursive call but confusion that prevails is why did an 'ON ERROR SYSTEM' not rectify it. Why did I have to cancel the job manually to stop the endless loop.
Sorry, if it is funny.. |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Not only a file close error- any error for that matter.. if it was siganlled in those procs- why did an on error system not stop the program execution. |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Not only a file close error- any error for that matter.. if it was siganlled in those procs- why did an on error system not stop the program execution. |
|
Back to top |
|
|
goyal.chanchal
New User
Joined: 09 Mar 2011 Posts: 9 Location: India
|
|
|
|
Now, I'm forced to think that I must have coded something like the following.
do while (more_records)
Call Read_proc ;
Call Process_proc ;
If (some_var = specific_value) then do;
call proc1; ---> pliretc function was called with value 9 but these procs
call proc2; ---> did not set the value of more_records to '0'B.
end;
Control returns here -->
end ;
I think the read reopened the file and I kept on processing it again and again from the beginning but an error was not signalled. Perhaps, this is what had happened.. |
|
Back to top |
|
|
|