Frank,

Actually, having been an application programmer in my past, I would have been 
somewhere between surprised and dismayed to see the lines of code function as 
you want.  The RETURN-CODE variable is documented as returning a code either 
back to the operating system or to the calling program.  Simply replace the 
EXEC SQL with a CALL PROGRAMB which in essence the EXEC is doing.  I would 
think you would want to verify that the SQL call came back with RC=0.  As John 
said, you want to set the return code as close to the end of the program as 
possible, which in your example's case, would be after the EXEC SQL statement.

I must be in the minority then, because I don't feel most developers are "dumb 
as posts".  




John, 

I slightly disagree with one point you made.  I don't feel that in this example 
that the RETURN-CODE is being changed "behind the scenes".  It's being changed 
in the wide open.  The code snippet is setting the RETURN-CODE then calling 
another program.  That's about as "in the open" as I can think of.  



Now an ignorance question from me - if I have a COBOL/CICS program and do an 
"EXEC CICS do something", will the RETURN-CODE variable get set by this program 
call or would CICS just return a code in the COMMAREA (or elsewhere besides 
RETURN-CODE)?

Rex

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Frank Swarbrick
Sent: Thursday, February 27, 2014 3:59 PM
To: [email protected]
Subject: Re: Using (COBOL) STOP RUN in "subsystem" environments

I don't feel they are ignorant.  I simply find it to be a less than obvious 
behavior that can be replaced by more obvious behavior.  (I realize most 
sysprogs think app developers are dumb as posts.)


>________________________________
> From: John McKown <[email protected]>
>To: [email protected] 
>Sent: Thursday, February 27, 2014 1:39 PM
>Subject: Re: Using (COBOL) STOP RUN in "subsystem" environments
> 
>
>On Thu, Feb 27, 2014 at 2:23 PM, Frank Swarbrick
><[email protected]>wrote:
>
>> It can be used for that, but it is also used for indicating the return
>> code to be passed back to the operating system, which is the particular
>> situation I'm concerned about.
>>
>>
>I apologize in advance for being "tacky". But I consider this to be
>unnecessary. In the original message, you basically seem to say that the
>current crop of COBOL programmers are simply too ignorant, or lazy, to
>learn that the value of RETURN-CODE is volatile and can often be changed
>"behind the scenes".  Perhaps whomever it is who is responsible for
>teaching programmers COBOL needs to emphasize that RETURN-CODE should be
>set at the last possible instant. In fact, I feel that programmers really
>should create their own variable, perhaps WS-RETURN-CODE and learn to
>modify that variable. And to always MOVE WS-RETURN-CODE TO RETURN-CODE just
>before any GOBACK or STOP RUN.
>
>I _can_ see your point. I simply think that a programmer who cannot learn
>this should not be entrusted with writing Enterprise Level code. In any
>language.
>
>-- 
>Wasn't there something about a PASCAL programmer knowing the value of
>everything and the Wirth of nothing?
>
>Maranatha! <><
>John McKown
>
>

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to