Home > Archive > Cobol > July 2007 > Stop Run vs GoBack
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Stop Run vs GoBack
|
|
| William M. Klein 2007-06-24, 6:55 pm |
| (new thread, "old" topic)
Facts and Options inter-mixed:
1) GoBack is in the '02 Standard (but not any earlier ones).
2) In previous (pre-02) Standards, it was "non-conforming" (but often accepted
as an extension) to code an EXIT Program immediately followed by a Stop Run.
3) COBOL (unlike many - possibly MOST - other languages) does NOT require you to
"declare" a program as either a "MAIN" or "SUB" at compile time. (Having a
LINKAGE section *implies* that you are a subprogram, but that is neither
required nor universally even true if you access the fields in it).
4) For as long as I have been involved in IBM mainframe (mostly MVS)
programming, the use of GOBACK "universally" instead of Stop Run and Exit
Program has been recommended by most shops (and classes). (As mentioned
elsewhere - at one time it was REQUIRED for CICS and some IMS programming).
5) Use of STOP RUN in a DECLARATIVE (or ABEND routine) is medium common. This
means that when the situation occurs, one wants the application to STOP - no
matter whether it is "sub" or "main".
6) The "biggest" issue with GoBack (IMHO) has to do with "multi-language"
applications. It is a little unclear where a GoBack takes you - to the CALLing
non-COBOL system or to the operating system. IBM even changed this (at one
stage) with VS COBOL II - although it is now back to the "traditional" return to
the CALLing program (or CLASS/Method - in the case of OO).
***
Personally, I can't see any reason NOT to "universally" use GOBACK - (except to
require immediate application termination). However, if you want "portable"
code to non-IBM compatible (and pre '02 Standard) applications, you might want
to think twice about it.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Pete Dashwood 2007-06-24, 6:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:IPyfi.318341$dg3.215593@fe10.news.easynews.com...
> (new thread, "old" topic)
>
> Facts and Options inter-mixed:
>
> 1) GoBack is in the '02 Standard (but not any earlier ones).
>
> 2) In previous (pre-02) Standards, it was "non-conforming" (but often
> accepted as an extension) to code an EXIT Program immediately followed by
> a Stop Run.
>
> 3) COBOL (unlike many - possibly MOST - other languages) does NOT require
> you to "declare" a program as either a "MAIN" or "SUB" at compile time.
> (Having a LINKAGE section *implies* that you are a subprogram, but that is
> neither required nor universally even true if you access the fields in
> it).
>
> 4) For as long as I have been involved in IBM mainframe (mostly MVS)
> programming, the use of GOBACK "universally" instead of Stop Run and Exit
> Program has been recommended by most shops (and classes). (As mentioned
> elsewhere - at one time it was REQUIRED for CICS and some IMS
> programming).
>
> 5) Use of STOP RUN in a DECLARATIVE (or ABEND routine) is medium common.
> This means that when the situation occurs, one wants the application to
> STOP - no matter whether it is "sub" or "main".
>
> 6) The "biggest" issue with GoBack (IMHO) has to do with "multi-language"
> applications. It is a little unclear where a GoBack takes you - to the
> CALLing non-COBOL system or to the operating system. IBM even changed
> this (at one stage) with VS COBOL II - although it is now back to the
> "traditional" return to the CALLing program (or CLASS/Method - in the case
> of OO).
>
> ***
>
> Personally, I can't see any reason NOT to "universally" use GOBACK -
> (except to require immediate application termination). However, if you
> want "portable" code to non-IBM compatible (and pre '02 Standard)
> applications, you might want to think twice about it.
....or even use STOP RUN in main programs and GOBACK in called ones, in the
certain knowledge that your code will then behave correctly on any COBOL
platform, including PCs, and that you have complied with the "spirit" of
COBOL in making your code semantically accurate. (People for whom IBM is the
World, may see it differently.)
(Of course, if you decide to make a called program a main one, or vice
versa, then you will have to amend the code, and test it, but you would've
done that anyway before promoting it to live, right? :-))
Pete.
| |
| William M. Klein 2007-06-25, 3:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5e880dF37scomU1@mid.individual.net...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:IPyfi.318341$dg3.215593@fe10.news.easynews.com...
>
> ...or even use STOP RUN in main programs and GOBACK in called ones, in the
> certain knowledge that your code will then behave correctly on any COBOL
> platform, including PCs, and that you have complied with the "spirit" of COBOL
> in making your code semantically accurate. (People for whom IBM is the World,
> may see it differently.)
>
> (Of course, if you decide to make a called program a main one, or vice versa,
> then you will have to amend the code, and test it, but you would've done that
> anyway before promoting it to live, right? :-))
>
> Pete.
>
>
Well, NO - you wouldn't have to test it if you design (from scratch) a program
to be usable as BOTH a main and SUB program. This can be done on an IBM
platform (or with any of the MULTI-IBM compatible compilers such as Fujitsu,
Micro Focus, RM - and any '02 conforming compiler) by using GOBACK.
For compilers allowing an extension to the '85 Standard which allows EXIT
PROGRAM to be followed (immediately) by STOP RUN, then code:
Exit Program
Stop Run
of course, unlike GOBACK this may not work within a Method or user-defined
function. Therefore, as I said before, use GOBACK unless you REALLY think your
code will ever be compiled on a system without support for it.
P.S. GoBack within a METHOD or FUNCTION avoids needing to know which type of
"procedural" (i.e Procedure Division) your code is in. This allows for "common
code" to be brought in via a COPY statement (without REPLACING).
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Richard 2007-06-25, 3:55 am |
| On Jun 25, 3:15 pm, "William M. Klein" <wmkl...@nospam.netcom.com>
wrote:
> Well, NO - you wouldn't have to test it if you design (from scratch) a program
> to be usable as BOTH a main and SUB program. This can be done on an IBM
> platform (or with any of the MULTI-IBM compatible compilers such as Fujitsu,
> Micro Focus, RM - and any '02 conforming compiler) by using GOBACK.
While one can design a program to be both a MAIN or a SUB it is
usually not useful outside a mainframe environment. I understand that
a MAIN can have a LINKAGE SECTION filled by command line parameters
(or similar) on mainframes but this is not usually the case on, say,
PCs or Unix.
This means that if the LINKAGE SECTION exists for the purpose of being
called then using this as a MAIN will fail if any reference is
actioned to a L-S item. Because of this it is not a good idea to
"design (from scratch) a program .." if this is not only for use on
IBM. A sensible design can be made on either by creating a called
program and a simple MAIN program that creates data areas and calls
the subroutine. ie there is no actual point for a design that can be
MAIN or SUB, except possibly on IBM mainframe.
In any case Fujitsu on Unix or PC _requires_ that a program be
nominated at compile time as MAIN or called so one executable cannot
be both.
> For compilers allowing an extension to the '85 Standard which allows EXIT
> PROGRAM to be followed (immediately) by STOP RUN, then code:
>
> Exit Program
> Stop Run
It is not an extension that one be followed by the other in execution
sequence, only that the full stop be omitted and this is regardless of
whether both occur in the execution sequence.
ie:
EXIT PROGRAM
| |
|
|
| Pete Dashwood 2007-06-25, 9:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1182751045.387557.300000@d30g2000prg.googlegroups.com...
> On Jun 25, 3:15 pm, "William M. Klein" <wmkl...@nospam.netcom.com>
> wrote:
>
>
> While one can design a program to be both a MAIN or a SUB it is
> usually not useful outside a mainframe environment. I understand that
> a MAIN can have a LINKAGE SECTION filled by command line parameters
> (or similar) on mainframes but this is not usually the case on, say,
> PCs or Unix.
>
> This means that if the LINKAGE SECTION exists for the purpose of being
> called then using this as a MAIN will fail if any reference is
> actioned to a L-S item. Because of this it is not a good idea to
> "design (from scratch) a program .." if this is not only for use on
> IBM. A sensible design can be made on either by creating a called
> program and a simple MAIN program that creates data areas and calls
> the subroutine. ie there is no actual point for a design that can be
> MAIN or SUB, except possibly on IBM mainframe.
>
> In any case Fujitsu on Unix or PC _requires_ that a program be
> nominated at compile time as MAIN or called so one executable cannot
> be both.
>
>
> It is not an extension that one be followed by the other in execution
> sequence, only that the full stop be omitted and this is regardless of
> whether both occur in the execution sequence.
>
> ie:
> EXIT PROGRAM
> .
> STOP RUN
> .
>
> does not require any extension. Each statement must be the last in the
> sentence it is in.
>
> GOBACK, however, is always an extension prior to '02 standard.
>
>
> IBMers tend to be completely anal about GOBACK because, it seems, they
> were taught it in 1902 and never bothered to learn real COBOL (ie EXIT
> PROGRAM).
>
> I have no idea whether any particular implementation would handle EXIT
> METHOD correctly with a GOBACK but why bother to find out when a
> perfectly good verb has been designed to do this correctly without
> having to check.
>
>
> How would one _not_ know.
>
>
> 'COPYed' procedure code is very poor design. If you want to have
> 'common code' then write a method or function with the code and call
> it. In any case, even with COPYed procedure code, it is unlikely to
> be useful to have the EXIT ~ within it, this can follow the COPY
> statement giving better reuse - or just have it fall off the end of
> the code.
>
> I would always advise against having code that is positionally
> dependent. Any EXIT ~, GOBACK, or GO within a block of code makes it
> less reusable. It would make a difference if it was 'dropped through'
> or performed, or perormed in-line and thus is likely to cause bugs.
>
> If you really think that COPYed procedure code might be sensible then
> you should ensure that it is 'pure' code and thus GOBACK would be
> bannished from it. This leaves your argument moot.
>
I had promised myself not to post any further on this stupid topic, but I
was impressed by your post.
I also share your aversion to COPY code in the procedure division, and would
never do this.
(I don't even like doing it in the Data Division; instead I'd have an access
module (for the file that would be COPYed) that combines procedure and data
into a separate layer. Ths would then be CALLED instead of code being
COPYed. I can generate such a module very quickly from templates I have.)
Good job :-)
Pete.
| |
| Howard Brazee 2007-06-25, 9:55 pm |
| On Sun, 24 Jun 2007 18:35:20 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>3) COBOL (unlike many - possibly MOST - other languages) does NOT require you to
>"declare" a program as either a "MAIN" or "SUB" at compile time. (Having a
>LINKAGE section *implies* that you are a subprogram, but that is neither
>required nor universally even true if you access the fields in it).
The LINKAGE section had some interesting variations. On the Univac
9030 (around 1980), most all of our data fields were in the Linkage
Division for our pseudo-conversational programs. They were called by
the program that ran on-line stuff. Other computer systems got the
same results without a LINKAGE section.
| |
| Howard Brazee 2007-06-25, 9:55 pm |
| On Mon, 25 Jun 2007 10:02:53 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>...or even use STOP RUN in main programs and GOBACK in called ones, in the
>certain knowledge that your code will then behave correctly on any COBOL
>platform, including PCs, and that you have complied with the "spirit" of
>COBOL in making your code semantically accurate. (People for whom IBM is the
>World, may see it differently.)
The semantically inaccurate command that bothers me (but which is
useful with some compilers), is PERFORM ABEND-ROUTINE.
I ain't coming back.
| |
| Howard Brazee 2007-06-25, 9:55 pm |
| On Sun, 24 Jun 2007 22:57:25 -0700, Richard <riplin@Azonic.co.nz>
wrote:
>ie:
> EXIT PROGRAM
> .
> STOP RUN
> .
That syntax always bothered me. Logically, if we exit a program at
EXIT PROGRAM, subsequent statements would be meaningless.
| |
| Howard Brazee 2007-06-25, 9:55 pm |
| On Sun, 24 Jun 2007 22:57:25 -0700, Richard <riplin@Azonic.co.nz>
wrote:
>'COPYed' procedure code is very poor design. If you want to have
>'common code' then write a method or function with the code and call
>it. In any case, even with COPYed procedure code, it is unlikely to
>be useful to have the EXIT ~ within it, this can follow the COPY
>statement giving better reuse - or just have it fall off the end of
>the code.
It can be efficient with some quick algorithms. It's also useful for
database binds and standard abort routines.
We also have 3 programs that have virtually the same code with a
couple of lines different which are compiled with different compilers.
One of our applications that interfaces cash machines still needs to
be compiled under CoBOL II. One version of the program is called by
on-line programs, and the third is normal batch. The latter 2 could
easily be replaced by a call, but the high-low memory limitations of
the cash system preclude that solution.
| |
|
| In article <l8nv73lbaajgladcst6hno6cetau466h18@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Mon, 25 Jun 2007 10:02:53 +1200, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz> wrote:
>
>
>The semantically inaccurate command that bothers me (but which is
>useful with some compilers), is PERFORM ABEND-ROUTINE.
>
>I ain't coming back.
This might be a reason for the Third Permissible GO TO.
First Permissible: to the bottom (-EXIT) for the present paragraph.
Second Permissible: to the top (PARA-NAME) of the current paragraph.
Third Permissible: to the ABEND routine.
DD
| |
| Frank Swarbrick 2007-06-25, 9:55 pm |
| >>> On 6/25/2007 at 9:49 AM, in message <f5oo68$6jl$1@reader2.panix.com>,
<docdwarf@panix.com> wrote:
> In article <l8nv73lbaajgladcst6hno6cetau466h18@4ax.com>,
> Howard Brazee <howard@brazee.net> wrote:
> the
[color=darkred]
[color=darkred]
[color=darkred]
> the
>
> This might be a reason for the Third Permissible GO TO.
>
> First Permissible: to the bottom (-EXIT) for the present paragraph.
> Second Permissible: to the top (PARA-NAME) of the current paragraph.
> Third Permissible: to the ABEND routine.
Doc! No! Please don't start this thread up!
(Everyone please avert your eyes!)
Frank
| |
|
| In article <467FF889.6F0F.0085.0@efirstbank.com>,
Frank Swarbrick <Frank.Swarbrick@efirstbank.com> wrote:
><docdwarf@panix.com> wrote:
>
>Doc! No! Please don't start this thread up!
>(Everyone please avert your eyes!)
Too late, it has been brought to life... don't worry, you can control it
easily, just tell it to... uhhhhh... fetch water from the well!
DD
| |
| Frank Swarbrick 2007-06-25, 9:55 pm |
| >>> On 6/25/2007 at 9:18 AM, in message
<62nv73llefa7mdevhm4gb5bk50uu6t9r6j@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Sun, 24 Jun 2007 18:35:20 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
[color=darkred]
> you to
[color=darkred]
> a
>
> The LINKAGE section had some interesting variations. On the Univac
> 9030 (around 1980), most all of our data fields were in the Linkage
> Division for our pseudo-conversational programs. They were called by
> the program that ran on-line stuff. Other computer systems got the
> same results without a LINKAGE section.
Perhaps I shouldn't start this, but...
While use of a LINKAGE SECTION seems to imply that the program is a
sub-program, it is not necessarily true for two reasons.
1) As you (or someone) mentioned, main programs on IBM mainframes can have a
LINKAGE SECTION to receive "command line parameters" from the operating
environment.
2) For those COBOLs without BASED storage (which is pretty much all of them,
as far as I can tell, with a few exceptions (OpenCobol and Fujitsu-Siemens
COBOL2000 are the only ones I know about) you have to use the linkage
section to be able to address dynamically allocated storage (such as storage
allocated using GETMAIN in CICS or storage using the new COBOL "ALLOCATE"
statement. Even in FS COBOL2000 the BASED clause is only allowed on a
LINKAGE SECTION item, so this almost defeats its purpose.
Maybe the LINKAGE SECTION should be renamed the BASED-STORAGE SECTION. :-)
Frank
| |
| Charles Hottel 2007-06-25, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:oenv731931gr8c1uol2iaot9m5ai17d97m@
4ax.com...
> On Sun, 24 Jun 2007 22:57:25 -0700, Richard <riplin@Azonic.co.nz>
> wrote:
>
>
> That syntax always bothered me. Logically, if we exit a program at
> EXIT PROGRAM, subsequent statements would be meaningless.
Long ago I worked on a CDC 6400 computer with the Scope 3.2 operating
system. My very first COBOL assignment in that environment was to write a
simple subroutine that read a record from a file and did an EXIT PROGRAM.
Someone gave me the Scope statments to compile and instead of a short cpu
time limit it had IIRC all 9's for unlimted amount of cpu time. IIRC the
EXIT PROGRAM occurred in an IF or some other conditional so I coded it
without a period at the end. Unfortunately for me on that COBOL compiler the
official EXIT PROGRAM ends with a period and at least in this particular
code the COBOL went into an infinite loop with not job time limit to stop
it. One particular error meassage was repeated a huge number of times.
| |
| Charles Hottel 2007-06-25, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:l8nv73lbaajgladcst6hno6cetau466h18@
4ax.com...
> On Mon, 25 Jun 2007 10:02:53 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> The semantically inaccurate command that bothers me (but which is
> useful with some compilers), is PERFORM ABEND-ROUTINE.
>
> I ain't coming back.
One place I worked used CALL 'ABEND'. Of course the ABEND module did not
exist.
| |
| Roger While 2007-06-26, 7:55 am |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> schrieb im Newsbeitrag
news:46800366.6F0F.0085.0@efirstbank.com...
<snip>
> While use of a LINKAGE SECTION seems to imply that the program is a
> sub-program, it is not necessarily true for two reasons.
> 1) As you (or someone) mentioned, main programs on IBM mainframes can have
> a
> LINKAGE SECTION to receive "command line parameters" from the operating
> environment.
> 2) For those COBOLs without BASED storage (which is pretty much all of
> them,
> as far as I can tell, with a few exceptions (OpenCobol and Fujitsu-Siemens
> COBOL2000 are the only ones I know about) you have to use the linkage
> section to be able to address dynamically allocated storage (such as
> storage
> allocated using GETMAIN in CICS or storage using the new COBOL "ALLOCATE"
> statement. Even in FS COBOL2000 the BASED clause is only allowed on a
> LINKAGE SECTION item, so this almost defeats its purpose.
>
> Maybe the LINKAGE SECTION should be renamed the BASED-STORAGE SECTION.
> :-)
OC, as per 2002 standard, allows BASED in WORKING/LINKAGE/LOCAL
sections.
You can also use the SET verb to set (sic) the addressability of
L/S items.
Of course, ABSENCE of L/S does not imply anything about a
program either.
In fact, I have 2 ported apps that each contain a prog (without L/S) that is
both run as a free-standing (main) program and as a callable
module.
Original machine environment for these app's is unknown
except it was "big iron".
Interestingly enough, both of these progs have a single exit
point which is an EXIT PROGRAM as the last statement in
the source. (That, at least, is the state in which I received them;
I can not say if they have been modified from the real original)
Roger
| |
| Rick Smith 2007-06-26, 7:55 am |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:f5q485$ngp$03$1@news.t-online.com...
[snip]
> Of course, ABSENCE of L/S does not imply anything about a
> program either.
> In fact, I have 2 ported apps that each contain a prog (without L/S) that
is
> both run as a free-standing (main) program and as a callable
> module.
> Original machine environment for these app's is unknown
> except it was "big iron".
> Interestingly enough, both of these progs have a single exit
> point which is an EXIT PROGRAM as the last statement in
> the source. (That, at least, is the state in which I received them;
> I can not say if they have been modified from the real original)
Beginning with COBOL 85, if control passes through
the last statement in a program, the runtime behavior
is an implicit EXIT PROGRAM statement followed
by an implicit STOP RUN statement. With 2002, an
implicit GOBACK statement is executed.
FDIS ISO/IEC 1989:2002, page 388, 14.5.3 Explicit
and implicit transfers of control,
"There is also no next executable statement after the last
statement in a source element when the paragraph in
which it appears is not being executed under the control
of some other COBOL statement in that source element,
after the end marker, and if there are no procedure
division statements in a program, function, or method. In
these cases, an implicit GOBACK statement without any
optional phrases is executed."
| |
| Howard Brazee 2007-06-26, 9:55 pm |
| On Tue, 26 Jun 2007 00:55:30 GMT, "Charles Hottel"
<chottel@earthlink.net> wrote:
>One place I worked used CALL 'ABEND'. Of course the ABEND module did not
>exist.
That's funny.
We have a program that has a purpose of abending. It is called when
EasyTrieve programs return abending return codes. We also have an
old standard abending routine that creates a SOC9.
My opinion is if they want to disguise the abend, use the standard IBM
'CEE3ABC'. Or better yet, use return codes.
| |
| Roger While 2007-06-26, 9:55 pm |
| OK. Rick, thanks for that clarification.
And now to throw a spanner in the works :-)
When is a "module" a "main" program?
Consider that for MF,ACU,OC the default when compiling
is to produce a "module" which is (when "main") then executed by
respectively
cobrun, runcbl, cobcrun :-)
All of these compilers also have the possibility to produce
an executable - (For MF,OC option -x, don't know currently for ACU)
So, the runtimes need to determine (how/from where) they are being
called.
That's maybe why Fuji needs the compile time determination whether
main/module :-)
Generally speaking on POSIX systems (Win has POSIX components),
one always compiles to a module and executes "main" progs
with a driver program.
Below is OC usage.
Note that I do NOT here include calling from another language.
There are special initialization sequences involved (as indeed with MF)
HOWEVER, it is possible (and has been done) to produce a
library of Cobol progs that are self-initializing (per compile option).
Roger
"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:1381lfha78puod8@corp.supernews.com...
>
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:f5q485$ngp$03$1@news.t-online.com...
> [snip]
> is
>
> Beginning with COBOL 85, if control passes through
> the last statement in a program, the runtime behavior
> is an implicit EXIT PROGRAM statement followed
> by an implicit STOP RUN statement. With 2002, an
> implicit GOBACK statement is executed.
>
> FDIS ISO/IEC 1989:2002, page 388, 14.5.3 Explicit
> and implicit transfers of control,
> "There is also no next executable statement after the last
> statement in a source element when the paragraph in
> which it appears is not being executed under the control
> of some other COBOL statement in that source element,
> after the end marker, and if there are no procedure
> division statements in a program, function, or method. In
> these cases, an implicit GOBACK statement without any
> optional phrases is executed."
>
>
>
| |
| Frank Swarbrick 2007-06-26, 9:55 pm |
| >>> On 6/26/2007 at 2:56 AM, in message
<1381lfha78puod8@corp.supernews.com>,
Rick Smith<ricksmith@mfi.net> wrote:
> "Roger While" <simrw@sim-basis.de> wrote in message
> news:f5q485$ngp$03$1@news.t-online.com...
> [snip]
> that
> is
>
> Beginning with COBOL 85, if control passes through
> the last statement in a program, the runtime behavior
> is an implicit EXIT PROGRAM statement followed
> by an implicit STOP RUN statement. With 2002, an
> implicit GOBACK statement is executed.
>
> FDIS ISO/IEC 1989:2002, page 388, 14.5.3 Explicit
> and implicit transfers of control,
> "There is also no next executable statement after the last
> statement in a source element when the paragraph in
> which it appears is not being executed under the control
> of some other COBOL statement in that source element,
> after the end marker, and if there are no procedure
> division statements in a program, function, or method. In
> these cases, an implicit GOBACK statement without any
> optional phrases is executed."
That, combined with what Roger said, makes sense. The problem I have when I
accidentally use EXIT PROGRAM in a main program is when I have something
like this.
PROCEDURE DIVISION.
PERFORM HOUSEKEEPING
PERFORM MAINLINE
PERFORM CLEANUP
EXIT PROGRAM.
* ^^ should be STOP RUN or GOBACK
HOUSEKEEPING.
* DO STUFF HERE
MAINLINE.
* DO STUFF HERE
CLEANUP.
* DO STUFF HERE
After it does the expected CLEANUP it then starts over and does
HOUSEKEEPING, MAINLINE and CLEANUP all over again. Not good! :-)
Frank
| |
| Doug Miller 2007-06-26, 9:55 pm |
| X-Newsreader: News Xpress 2.01
X-NFilter: 1.2.1-b1
Lines: 33
Message-ID: <ppdgi.8867$c06.3358@newssvr22.news.prodigy.net>
NNTP-Posting-Host: 71.156.95.184
X-Complaints-To: abuse@prodigy.net
X-Trace: newssvr22.news.prodigy.net 1182884565 ST000 71.156.95.184 (Tue, 26 Jun 2007 15:02:45 EDT)
NNTP-Posting-Date: Tue, 26 Jun 2007 15:02:45 EDT
X-UserInfo1: TSU[@IONQBUIRRXXBJJ@NFP@XB]BAAXOGHTVOBPL
AH[\BQUBLNTC@AWZWDXZXQ[K\FFSKCVM@F_N_DOB
WVWG__LG@VVOIPLIGX\\BU_B@\P\PFX\B[APHTWA
HDCKJF^NHD[YJAZMCY_CWG[SX\Y]^KC\HSZRWSWK
GAY_PC[BQ[BXAS\F\\@DMTLFZFUE@\VL
Date: Tue, 26 Jun 2007 19:02:52 GMT
Bytes: 2305
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:165642
In article <4680FA70.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
>That, combined with what Roger said, makes sense. The problem I have when I
>accidentally use EXIT PROGRAM in a main program is when I have something
>like this.
>
>PROCEDURE DIVISION.
> PERFORM HOUSEKEEPING
> PERFORM MAINLINE
> PERFORM CLEANUP
> EXIT PROGRAM.
>* ^^ should be STOP RUN or GOBACK
Boy, that's stupid. I've *never* done anything *that* dumb.
<cough> <cough>
<shuffles feet & looks around nervously>
<cough> <cough>
At least not while anyone was watching.
[snip]
>After it does the expected CLEANUP it then starts over and does
>HOUSEKEEPING, MAINLINE and CLEANUP all over again. Not good! :-)
No, it's not -- but it's typically caught pretty early in the testing cycle.
Or so I'm told. Not that I've ever actually done that, you know. ;-)
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Charles Hottel 2007-06-26, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:mt52831elnu7vfkre8lu4c0jm0k591dm1f@
4ax.com...
> On Tue, 26 Jun 2007 00:55:30 GMT, "Charles Hottel"
> <chottel@earthlink.net> wrote:
>
>
> That's funny.
>
>
> We have a program that has a purpose of abending. It is called when
> EasyTrieve programs return abending return codes. We also have an
> old standard abending routine that creates a SOC9.
>
> My opinion is if they want to disguise the abend, use the standard IBM
> 'CEE3ABC'. Or better yet, use return codes.
Back then I don'tthink there was a CEE3ABC.
| |
| Michael Mattias 2007-06-26, 9:55 pm |
| "Charles Hottel" <chottel@earthlink.net> wrote in message
news:fOggi.1378$rR.851@newsread2.news.pas.earthlink.net...[color=darkred]
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:mt52831elnu7vfkre8lu4c0jm0k591dm1f@
4ax.com...
One place I worked at had a module to call to abend which simply did a
divide by zero. (Damn, I wish I were bright enough to have thought of that!)
Apparently setting return codes in COBOL and using them in JCL is just too
difficult for some programmers... the programmers who also find it difficult
to fart and chew gum at the same time.
MCM
| |
| Charles Hottel 2007-06-26, 9:55 pm |
|
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:v3hgi.18052$y_7.1425@newssvr27.news.prodigy.net...
> "Charles Hottel" <chottel@earthlink.net> wrote in message
> news:fOggi.1378$rR.851@newsread2.news.pas.earthlink.net...
>
> One place I worked at had a module to call to abend which simply did a
> divide by zero. (Damn, I wish I were bright enough to have thought of
> that!)
>
> Apparently setting return codes in COBOL and using them in JCL is just too
> difficult for some programmers... the programmers who also find it
> difficult to fart and chew gum at the same time.
>
> MCM
>
>
Yeah I have seen that divide by zero trick.
| |
| Frank Swarbrick 2007-06-26, 9:55 pm |
| >>> On 6/26/2007 at 1:02 PM, in message
<ppdgi.8867$c06.3358@newssvr22.news.prodigy.net>, Doug
Miller<spambait@milmac.com> wrote:
> In article <4680FA70.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
> when I
>
> Boy, that's stupid. I've *never* done anything *that* dumb.
>
> <cough> <cough>
> <shuffles feet & looks around nervously>
> <cough> <cough>
>
> At least not while anyone was watching.
>
> [snip]
>
>
> No, it's not -- but it's typically caught pretty early in the testing
> cycle.
> Or so I'm told. Not that I've ever actually done that, you know. ;-)
Did I say that I did it? Umm, I meant that a cow-worker did it. Several
times.
:-)
Frank
| |
| Doug Miller 2007-06-26, 9:55 pm |
| In article <46815DBC.6F0F.0085.0@efirstbank.com>, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote:
><ppdgi.8867$c06.3358@newssvr22.news.prodigy.net>, Doug
>Miller<spambait@milmac.com> wrote:
>
>Did I say that I did it? Umm, I meant that a cow-worker did it. Several
>times.
>
>:-)
LOL
--
Regards,
Doug Miller (alphag at milmac dot com)
It's time to throw all their damned tea in the harbor again.
| |
| Rick Smith 2007-06-27, 7:55 am |
|
"Roger While" <simrw@sim-basis.de> wrote in message
news:f5rdur$f45$02$1@news.t-online.com...
[snip]
>
> When is a "module" a "main" program?
FDIS ISO/IEC 1989:2002, page 386, 14.5.2.1.1 Active state,
"An instance of a program is placed in an active state when
it is successfully activated by the operating system ...."
It might appear that a compiled program definition
(runtime module) when placed in an active state by the
operating system is a "main" program. However, the
concept "main" as it applies to POSIX-type environments
is not universal and the COBOL programming language,
having not been designed specifically for such environments,
simply does not, as far as I can tell, address that concept.
| |
|
| In article <1384g2jtj1d5f4d@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
>"Roger While" <simrw@sim-basis.de> wrote in message
>news:f5rdur$f45$02$1@news.t-online.com...
>[snip]
>
>FDIS ISO/IEC 1989:2002, page 386, 14.5.2.1.1 Active state,
>"An instance of a program is placed in an active state when
>it is successfully activated by the operating system ...."
How utterly fascinating... this might give Mr Dashwood a bit of insight as
to why, for IBM-style mainframes for at least the past twenty years or so,
all Good Programmers were taught 'always GOBACK, never STOP RUN'.
>
>It might appear that a compiled program definition
>(runtime module) when placed in an active state by the
>operating system is a "main" program. However, the
>concept "main" as it applies to POSIX-type environments
>is not universal and the COBOL programming language,
>having not been designed specifically for such environments,
>simply does not, as far as I can tell, address that concept.
Precisely. According to the definition cited above there are, by my
experience, rather few COBOL programs on IBM-style mainframes that are
'activated by the operating system', successfully or no. COBOL programs
are, overwhelmingly, activated by JCL/REXX/CLIST/etc. or by various
methods in the CICS region... none of which is, as I underatsnd the term,
an 'operating system'.
As to the question of 'why was this taught before FDIS ISO/IEC 1989:2002
existed?'... well, some folks might just be a little ahead of their time,
that's all, and a shop is fortunate to have programmers who benefitted
from their tutelage.
DD
| |
| Howard Brazee 2007-06-27, 9:55 pm |
| On Tue, 26 Jun 2007 22:54:03 GMT, "Charles Hottel"
<chottel@earthlink.net> wrote:
>
>Back then I don'tthink there was a CEE3ABC.
Back when they created the shop standard - probably. But those who
created the shop standards are long gone, times have changed, but the
standards haven't.
| |
|
|
| Alistair 2007-07-10, 6:55 pm |
| On 27 Jun, 00:12, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> "Charles Hottel" <chot...@earthlink.net> wrote in message
>
> news:fOggi.1378$rR.851@newsread2.news.pas.earthlink.net...
>
>
>
>
>
> One place I worked at had a module to call to abend which simply did a
> divide by zero. (Damn, I wish I were bright enough to have thought of that!)
>
> Apparently setting return codes in COBOL and using them in JCL is just too
> difficult for some programmers... the programmers who also find it difficult
> to fart and chew gum at the same time.
>
> MCM
Is it any surprise that p'ers can't handle cc in jcl when the correct
interpretation is 'byepass this step if the cc from stepxxx is....'.
It is so BACKWARD. I still don't understand ONLY and EVEN.
| |
| Howard Brazee 2007-07-10, 6:55 pm |
| On Tue, 10 Jul 2007 11:29:02 -0700, Alistair
<alistair@ld50macca.demon.co.uk> wrote:
>Is it any surprise that p'ers can't handle cc in jcl when the correct
>interpretation is 'byepass this step if the cc from stepxxx is....'.
>It is so BACKWARD. I still don't understand ONLY and EVEN.
That was fixed a decade or two ago, when IBM added IF-THEN-ELSE-ENDIF
condition code processing. Trouble is, most existing JCL has never
been updated, and lots of programmers are completely unaware of this
enhancement.
|
|
|
|
|