Re: COBOL record length on z/series

On 6/22/2007 at 7:10 PM, in message
<5e3a8qF371drcU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:467BCC91.6F0F.0085.0@xxxxxxxxxxxxxxxxx
On 6/22/2007 at 10:58 AM, in message
<5e2dd1F36hpt6U1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

<docdwarf@xxxxxxxxx> wrote in message
news:f5gs30$2s5$1@xxxxxxxxxxxxxxxxxxxx
In article <5e28lvF367palU1@xxxxxxxxxxxxxxxxxx>,
Pete Dashwood <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

"Howard Brazee" <howard@xxxxxxxxxx> wrote in message
news:d2on7394uvs92g926r2cnc62ata2dbjlb7@xxxxxxxxxx
On Fri, 22 Jun 2007 12:24:51 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


Nice code and a nice approach, the only thing that struck me as
"odd"
was
using GOBACK in a main program. I didn't know you could do that. Yet
I

see
you "STOP RUN" in the declaratives.

[snip]

That was the full extent of my comment. It would be nice if the next
sentence had started with something like: "I do that because..."

... or not...

With these quotes within quotes within quotes it is hard to keep track of
who said what. Please don't attribute malicious intent to simple
carelessness in quoting by either myself or others in this thread.


I currently always use GOBACK in new programs.

Whether they are Main programs or SubPrograms? Why?

I cannot speak for Mr Brazee but I was taught, lo, those many years
ago,
to *always* code (when the compiler would accept it) GOBACK and
*never*
to
code a STOP RUN.

The reason for this is the 'just in case' - and I've seen it happen -
of
something that started out life as a Main program getting turned into
a
subroutine.

So how long did it run before they realised it was hitting a STOP RUN
in
the
called program? Given that IBM environments often use different
procedures
for compiling main and sub programs, and given that the whole run unit
would stop pretty quickly, you'd kind of think someone might notice
there
was something wrong... Possibly during testing, before it went live?
No...?
Well of course, we live in different worlds.

The teaching was 'GOBACK will always return control to the program
which
next-up in the invocation hierarchy;

AND sometimes that would be OK and other times it wouldn't.

a 'Main' program will GOBACK to the
Operating System (or the next executable statement in the
JCL/CLIST/REXX/etc which invoked the 'Main'). If you have a
subroutine
with a STOP RUN coded then the invocation hierarchy will be ignored
and
everything will, for lack of a better term, Just Die;

And this is worse than letting control continue up the hierarchy when
it

shouldn't....er...How?

control will be
returned to the Operating System (or the next executable statement in
the
JCL/CLIST/REXX/etc that invoked the 'Main' which passed control of
execution to the subroutine).

And that step will check the condition code and find it wasn't set as
expected, so it abends, exactly as it should (or it doesn't, depending
on
how the JCL is written).

Either way, whether you use GOBACK or STOP RUN (and personally I don't
care;
I didn't suggest it was "wrong", it struck me in passing as "odd",
that's
all), the job will STILL proceed to the next step in the JCL/CLIST/REXX
whatever, and "go back to the OS". Using GOBACK makes no difference.

I know of two specific cases where GOBACK is *required* (or at least was
required) otherwise bad things will happen.

Sure. In CALLED Programs. My point was about using it in a MAIN program.
And
there is NO case (even in a called SubProgram), where GOBACK behaves any

differently from EXIT PROGRAM. (I should add I have nothing against
GOBACK
and have used it myself on countless occasions, but only in SubPrograms.
I
never said your use of it was wrong, simply that it struck me as odd.)

I may be reading this wrong, but I don't believe your statement above is
true.

EXIT PROGRAM in a sub-program returns control to the calling program.
EXIT PROGRAM in a main program does nothing. Control continues to the next
statement.
STOP RUN in a main program returns control to the "operating environment".
STOP RUN in a sub-program also returns control to the "operating
environment".
GOBACK in a sub-program returns control to the calling program.
GOBACK in a main program returns control to the "operating environment".

You state "And there is NO case (even in a called SubProgram), where GOBACK
behaves any
differently from EXIT PROGRAM." This is not true, since in a main program
GOBACK returns to the operating environment while EXIT PROGRAM continues to
the next statement.

Again, this is all for the IBM z/VSE operating system. Whether or not it is
true elsewhere I couldn't say for sure.



If a CICS program has a STOP RUN in it it actually 'stops' CICS itself.
This is because all CICS user programs are sub programs. CICS itself is


the
main program. So when a CICS user program issues STOP RUN it would
cause
CICS itself to terminate and return back to the OS. Or something like
that.
Never tried it myself, and it may have been 'fixed' in recent versions.

It doesn't need fixing. CICS programmers know and understand the
environment. So do people using DL/1 or IMS or VANDL. (If there still
are
any outside of Retirement Homes...).


Hmm, I'm not sure I'd place any bets on that. I could be just being
pessimistic, but I am guessing that there may be some programmers here (at
my shop) that know only that they should use GOBACK (and not STOP RUN) to
terminate CICS and DL/I programs, but they might not know *why*. Then
again, maybe they do and I just don't have enough faith!

Somewhat the same issue with a DL/I batch program. You actually execute

a
DL/I assembler "driver" program. This program in turn calls your use
program, so your user program is again a called program and not a main
program. Therefore GOBACK (or EXIT PROGRAM, I assume, though I've never
tried it) is required to go back to the driver program.

Frank

In both the cases you cite, you are talking about called programs. You
even
said so yourself. I have no issue with that (in fact, I don't really
have
any issue with any of this because I frankly don't care.)

It is quite incredible to me that something mentioned in passing,
becomes an
issue prompting posts that ignore what I actually said, trot out the
party
line without anybody actually thinking about it, and then seek to
educate me
in the error of my ways.

I'm not sure who you are/were upset at here and why. I hope it was not me,
because it was definitely not my intention. For myself I was simply
answering your question as to why I used STOP RUN in one place and GOBACK in
another, and also trying to clarify for those who may not understand the
differences between each of those COBOL statements.

I'm no longer irritated, but decided the forum can read it anyway :-)

Well that's good. Hopefully this message will not be too irritating. :-)

Frank

.

Relevant Pages

  • Re: COBOL record length on z/series
    ... The teaching was 'GOBACK will always return control to the program ... GOBACK returns to the operating environment while EXIT PROGRAM continues ... If a CICS program has a STOP RUN in it it actually 'stops' CICS itself. ...
    (comp.lang.cobol)
  • Re: COBOL record length on z/series
    ... using GOBACK in a main program. ... everything will, for lack of a better term, Just Die; control will be ... returned to the Operating System (or the next executable statement in the ...
    (comp.lang.cobol)
  • Re: COBOL record length on z/series
    ... using GOBACK in a main program. ... Operating System (or the next executable statement in the ... If a CICS program has a STOP RUN in it it actually 'stops' CICS itself. ... and writing CICS and IMS COBOL in IBM environments. ...
    (comp.lang.cobol)
  • Re: COBOL record length on z/series
    ... Pete Dashwood wrote: ... using GOBACK in a main program. ... Operating System (or the next executable statement in the ... If a CICS program has a STOP RUN in it it actually 'stops' CICS itself. ...
    (comp.lang.cobol)
  • Re: more GoBack problems :-(
    ... The program hooks "very" deeply into the operating ... You can restore the MBR and GoBack will be out of the picture. ... You can also install a recovery option using TrueImage that is ... re-installed and working I highly recommend you uninstall it. ...
    (microsoft.public.windowsxp.help_and_support)