Mainframe, MVS and zOS Discussion

Hi,

What is the difference between STOP RUN and GO BACK in COBOL?

• STOP RUN terminates the run unit and deletes all dynamically called programs in the run unit and all programs link-edited with them.
• STOP RUN statement does not have to be the last statement in a sequence, but the statements following the STOP RUN will not be executed.
• STOP RUN statement closes all files defined in any of the programs

• GOBACK statement specifies the logical end of a called program or invoked method.
• Should appear as the only statement or as the last of a series of imperative statements in a sentence because any statements following the GOBACK are not executed.

Hope this helps.

So for an IMS COBOL Program, can we use STOP RUN also?

No.

IMS is running under zOS as just another "sub-system" -- the program DFSRRC00, establishes the environment for you "COBOL Program" -- DFSRRC00 invokes the 'logic program' like it were a submodule but without any knowledge about parameters to be passed to thad module. Becuase your COBOL program is used as submodule, you use GOBACK.

What if I just don't code GOBACK altogether? Actually, I tried it and and got U4038 - the question is -- why it abends, I thought it'll go in infinite loop?

And why did we stop using STOP RUN, could not GOBACK & 'STOP RUN' both be used as synonyms to each other?

Executing STOP RUN in a CICS program would bring the entire CICS region down. GO BACK or EXIT PROGRAM merely return to the calling program (operating system for a batch program or CICS for a CICS program). So they are not exactly synonyms.

There are still many program that have STOP RUN in them -- not everybody has stopped using it. And for a batch program there is no harm in using it and only very minor differences between STOP RUN, GO BACK, and EXIT PROGRAM.

Robert Sample wrote:Executing STOP RUN in a CICS program would bring the entire CICS region down.

As far as I know - in old days, STOP RUN was the only way to "stop" the program - does that mean, during those days CICS had frequent problems because of STOP RUN?

No -- the rule was, and is, that STOP RUN (or equivalent) be coded in the COBOL program. However, normally the logic wasto ensure that the STOP RUN was not ever executed. The compile failed if the STOP RUN was not present, but CICS came down if the STOP RUN was executed.

Robert Sample wrote:The compile failed if the STOP RUN was not present, but CICS came down if the STOP RUN was executed.

Thanks for the explanation Robert. However, Could you please explain a bit more on above text. If CICS came down when STOP RUN was executed - then how did they prevent it ti execute. Perhaps I did not follow you properly...

Some sites used code reviews before a CICS program was allowed to be tested -- my first employer back in the late 70's and early 80's insisted their CICS team review every program for this type of problem before it could be defined in the test region. Some sites accepted the occasional CICS shut down in test. There was no programmatic way to prevent the CICS shut down if the STOP RUN statement was executed, so it was either code reviews or accept the occasional shut down.

Re-reading your post, I think you might be confused between having the code in the source so it is compiled and actually having the statement executed during processing. A program may contain code that cannot be executed; if the compiler detects this it labels the code as "DEAD CODE" and does not generate any instructions in the load module for that code. Similarly, the STOP RUN had to appear in the source (else, as I said, the compile would fail) -- but the STOP RUN was usually set up with EXEC CICS RETURN just ahead of it so there was no way the STOP RUN could be executed.

Robert Sample wrote:Re-reading your post, I think you might be confused between having the code in the source so it is compiled and actually having the statement executed during processing. A program may contain code that cannot be executed; if the compiler detects this it labels the code as "DEAD CODE" and does not generate any instructions in the load module for that code. Similarly, the STOP RUN had to appear in the source (else, as I said, the compile would fail) -- but the STOP RUN was usually set up with EXEC CICS RETURN just ahead of it so there was no way the STOP RUN could be executed.

Thank you Robert - this precisely answers my concern.

This is an excellent reply and helps.

Glad to hear your question was fully answered!