Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

PL/1 Error Handling Error
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
View previous topic :: :: View next topic  
Author Message
chagoyal

New User


Joined: 03 May 2007
Posts: 11
Location: India

PostPosted: Thu Dec 31, 2009 4:37 pm    Post subject: PL/1 Error Handling Error
Reply with quote

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
View user's profile Send private message

Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Thu Dec 31, 2009 9:15 pm    Post subject:
Reply with quote

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
View user's profile Send private message
chagoyal

New User


Joined: 03 May 2007
Posts: 11
Location: India

PostPosted: Sun Jan 03, 2010 7:58 pm    Post subject:
Reply with quote

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
View user's profile Send private message
chagoyal

New User


Joined: 03 May 2007
Posts: 11
Location: India

PostPosted: Sun Jan 03, 2010 8:09 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Sun Jan 03, 2010 8:23 pm    Post subject:
Reply with quote

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
View user's profile Send private message
chagoyal

New User


Joined: 03 May 2007
Posts: 11
Location: India

PostPosted: Sun Jan 03, 2010 8:33 pm    Post subject:
Reply with quote

@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
View user's profile Send private message
sraammr

New User


Joined: 24 Apr 2008
Posts: 3
Location: hyd

PostPosted: Tue Apr 19, 2011 11:19 am    Post subject: Reply to: PL/1 Error Handling Error
Reply with quote

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
View user's profile Send private message
prino

Active Member


Joined: 07 Feb 2009
Posts: 984
Location: Oostende, Belgium

PostPosted: Tue Apr 19, 2011 1:11 pm    Post subject: Re: Reply to: PL/1 Error Handling Error
Reply with quote

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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Tue Jul 19, 2011 11:49 pm    Post subject: Part 2 of the question.
Reply with quote

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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Wed Jul 20, 2011 12:01 am    Post subject: Cont ..
Reply with quote

Sorry, I meant 9.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1738
Location: Bloomington, IL

PostPosted: Wed Jul 20, 2011 12:39 am    Post subject: Re: Part 2 of the question.
Reply with quote

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
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1715
Location: UK

PostPosted: Wed Jul 20, 2011 2:37 am    Post subject:
Reply with quote

The whole point of coding
Code:
ON ERROR SYSTEM
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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Wed Jul 20, 2011 10:04 am    Post subject:
Reply with quote

@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.
Code:
Back to top
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Wed Jul 20, 2011 12:41 pm    Post subject:
Reply with quote

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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Wed Jul 20, 2011 1:23 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Garry Carroll

Active Member


Joined: 08 May 2006
Posts: 990
Location: Dublin, Ireland / Edinburgh, Scotland

PostPosted: Wed Jul 20, 2011 1:33 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Michael Jakob

New User


Joined: 13 Mar 2011
Posts: 17
Location: Switzerland

PostPosted: Fri Aug 05, 2011 4:19 am    Post subject: ON ANYCONDITION
Reply with quote

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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Fri Aug 05, 2011 10:54 am    Post subject:
Reply with quote

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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Fri Aug 05, 2011 11:03 am    Post subject:
Reply with quote

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
View user's profile Send private message
goyal.chanchal

New User


Joined: 09 Mar 2011
Posts: 9
Location: India

PostPosted: Fri Aug 05, 2011 11:06 am    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts S922 Error yuvan ABENDS & Debugging 3 Fri Dec 02, 2016 6:58 pm
No new posts Invoke Webservice Fails with DFHPI100... divated CICS 2 Thu Nov 24, 2016 5:57 pm
No new posts Error during restore rename archanamuthukrishnan All Other Mainframe Topics 2 Fri Oct 14, 2016 3:30 pm
No new posts Error IEC161I 052(009,XXXRS00)-084 wh... amitc23 JCL & VSAM 10 Wed Oct 12, 2016 5:00 pm
No new posts IDMS/DC-COBOL program - SNAP error wh... rakeshsekar1987 IDMS/ADSO 5 Tue Sep 13, 2016 8:28 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us