I have never heard of a recommendation to check RETURN-CODE after an SQL call. Or was that not what you were saying? Mostly, in our environment anyway, RETURN-CODE is used only to set the return code when returning to the operating system. If one wants to return something back to the calling program one would place it in an explicit parameter.
I agree that RETURN-CODE should be used only immediately before a GOBACK or STOP RUN. I just don't agree that its "obvious to anyone" that this is the case. Once its explained to someone (as I had to do yesterday) it becomes obvious, but I don't know that use of RETURN-CODE (which is an IBM extension, not a COBOL standard) is given much (any?) attention in COBOL courses and books. (Steve Comstock will perhaps correct me on this!) This is the reason why I think the standard (COBOL 2002) use of STOP RUN WITH STATUS would be preferable to the IBM RETURN-CODE special register. Just like C has exit(rc), COBOL would have STOP RUN WITH ERROR STATUS RC. I guess would should still be free to use RETURN-CODE to pass data between caller and callee. But I still think it's not a great idea, because one then has to remember to set RETURN-CODE back to zero if they don't want the callee's return code to be passed back to the operating system. (unless, of course, they call another subroutine which implicitly sets RETURN-CODE to zero!) The real "cause" of this problem was that most of our programs were originally written in pre-COBOL II (DOS/VS COBOL, specifically), where there was no RETURN-CODE at all, and you could not pass a return code back to the operating system (at least not that I recall!). So for the most part RETURN-CODE had not been used at all (and thus no one really had a need to understand it). We also did not for the longest time have a scheduler. Operators were "notified" of an issue by one of two ways: - We'd intentionally cause an abend by either doing division by zero or moving a non-numeric COMP-3 field and cause a data exception, or - We'd write an error message to the console and wait for a reply of EOJ. Once the reply was received we'd just do a STOP RUN or GOBACK. In either case the operator would not submit any jobs depending on the current job. When we got the scheduler (by which time all old-COBOL was now "new COBOL") we needed to have a way to let the scheduler know to not run any successor jobs. So it was decided to write a program to parse the COBOL source code for each program and insert the following after any COBOL ACCEPT...FROM CONSOLE statement. IF CONSOLE-REPLY = 'EOJ' MOVE 16 TO RETURN-CODE END-IF Perhaps we should have added a line to immediately do a STOP RUN / GOBACK. But, not really having used RETURN-CODE before we didn't have the experience to understand the issues that we've now run in to. (And admittedly we've only ran into it twice in the last four years, so it's not a HUGE issue.) Anyway, if we had done that we would have bypassed any "cleanup" code that occurs after the ACCEPT FROM CONSOLE. So we probably should have (and I suppose we could go back and re-do this in this manner) added a WS field (RET-CODE or whatever) and then place "MOVE RET-CODE TO RETURN-CODE" before each GOBACK / STOP RUN. So that's something to consider for us. I still like STOP RUN WITH ERROR xxx, though. And the only point of my OP was wondering if STOP RUN was safe in all environments, not to discuss the actual use or misuse of RETURN-CODE! :-) Frank >________________________________ > From: "Pommier, Rex" <[email protected]> >To: [email protected] >Sent: Thursday, February 27, 2014 3:26 PM >Subject: Re: Using (COBOL) STOP RUN in "subsystem" environments > > >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 > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
