Re: GO TO "cobol"

[Clark Morris]

On Sun, 29 Apr 2012 16:22:48 +0200 (CEST), Nomen Nescio
 wrote:

>> much snipped
>
>Newsgroups: bit.listserv.ibm-main,comp.lang.cobol
>Subject: Re: GO TO "cobol"
>References: <9v9ac3fpj...@mid.individual.net>
>Message-ID: <0820aa7adfc1d5a4b35ae840243ab...@dizum.com>
>Date: Thu, 19 Apr 2012 11:42:24 +0200 (CEST)
>
> I wrote
>
>COBOL doesn't inline PERFORM. A coder can choose to code an inline PERFORM,
>so there is a good example of one thing the coder can do better in source
>than the compiler.

If PERFORM READ-RECORD performs a paragraph that CAN NOT be reached
via GO TO or a fall through from the previous paragraph AND there is
no GO TO or GOBACK / STOP RUN / EXIT PROGRAM in the paragraph AND the
OPTIMIZE option is chosen on any IBM 370 / 390 / z series compiler
starting with VS COBOL II V1R4, the code may well be inlined (moved
out of sequence).   I have verified this by reading the procedure
division map produced by the compiler.  There have been SHARE
presentations given by Tom Ross of IBM COBOL development in Santa
Teresa stating this and noting that a paragraph may be copied to more
than one place.

Based on my reading of the generated code back in the 1990s I changed
my code to ONLY use PERFORM and NEVER PERFORM ... THRU on new
programs.  This change in how things worked also allowed me to
simplify nested IF ... END-IF statements by moving appropriate nesting
levels to a separate paragraph with no loss of efficiency because the
compiler moved the statements back in line.  

Another optimization that came in at the same time was recognizing
that an offset related to a subscript had been calculated and using
that offset for subsequent subscripted references thus eliminating the
value of moving entries to a work area.

Any time you get a new version of a compiler in any language, read the
manual to see what coding changes would be beneficial and what
compiler options can work in your environment.  Some techniques that
were valuable with the COBOL VS (1974 standard) and saved time using
the right OPTIMIZE options became counter productive with VS COBOL II
V1R4.  

Clark Morris 
>
> I wrote
>
> PERFORM READ-RECORD.
> PERFORM SOMETHING ELSE.
>
>
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Paul Gilmartin]

On Fri, 27 Apr 2012 15:18:05 -0700, Edward Jaffe wrote:
>
>That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing
>itself recursively! :-D
> 
At times when I want to write pure Rexx, insensitive to default
command environment, I start my EXEC with "address NOTHING"
and explicitly qualify each command, range of commands, or
procedure.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

Back in my NOMAD days, those types of Nomad procedures were called NOBOL 
programs:  Nomad COBOL.  We had lots of people tryng to follow COBOL structure 
to write Nomad and many of them ended up with similar issues.

Lloyd



- Original Message 
From: Edward Jaffe 
To: IBM-MAIN@bama.ua.edu
Sent: Fri, April 27, 2012 6:19:05 PM
Subject: Re: GO TO "cobol"

On 4/27/2012 2:40 PM, Steve Comstock wrote:
> But, Ed, it does have "DO FOREVER".
>
> I like to joke "You gotta' love a language that does
> not have a GOTO but does have a DO FOREVER"

LOL! Actually, DO FOREVER is _extremely_ useful. We have the same control 
structure in HLASM called DO INF (infinite).

>
> So somehow you've combined the two in one exec! Very
> strange behavior.
>
> Do you have a local TSO command called 'goto'? When
> REXX sees a command it does not know, it passes it
> to the underlying host as a host command.

That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing 
itself recursively! :-D

-- 
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/27/2012 3:18 PM, Edward Jaffe wrote:


That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing 
itself recursively! :-D


Now that I've renamed it, I get the following expected behavior:

 3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
IKJ56500I COMMAND GOTO NOT FOUND
   +++ RC(-3) +++
 4 *-* say 'the goto failed'
>L>   "the goto failed"
the goto failed
 5 *-* exit
***

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/27/2012 2:40 PM, Steve Comstock wrote:

But, Ed, it does have "DO FOREVER".

I like to joke "You gotta' love a language that does
not have a GOTO but does have a DO FOREVER"


LOL! Actually, DO FOREVER is _extremely_ useful. We have the same control 
structure in HLASM called DO INF (infinite).




So somehow you've combined the two in one exec! Very
strange behavior.

Do you have a local TSO command called 'goto'? When
REXX sees a command it does not know, it passes it
to the underlying host as a host command.


That's it, Steve! The name of my test EXEC is 'GOTO'. So, it was executing 
itself recursively! :-D


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Steve Comstock]

On 4/27/2012 3:18 PM, Edward Jaffe wrote:

On 4/26/2012 3:46 AM, Shmuel Metz (Seymour J.) wrote:

3. Rexx does not have a GOTO. Those who try to use SIGNAL as if it were GOTO
often shoot themselves in the foot as a result


Wow! Not only does Rexx not support GOTO, but if you try to use it you get an
infinite loop!

Consider the following test program:

/* REXX */
trace i
goto a
say 'the goto failed'
exit
a: say 'the goto worked'
exit

If you execute under TSO on z/OS 1.13 you get:

3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
3 *-* goto a
 >L> "GOTO"
 >L> "A"
 >O> "GOTO A"
.. (never-ending loop...)



But, Ed, it does have "DO FOREVER".

I like to joke "You gotta' love a language that does
not have a GOTO but does have a DO FOREVER"


So somehow you've combined the two in one exec! Very
strange behavior.

Do you have a local TSO command called 'goto'? When
REXX sees a command it does not know, it passes it
to the underlying host as a host command.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/26/2012 3:46 AM, Shmuel Metz (Seymour J.) wrote:
3. Rexx does not have a GOTO. Those who try to use SIGNAL as if it were GOTO 
often shoot themselves in the foot as a result


Wow! Not only does Rexx not support GOTO, but if you try to use it you get an 
infinite loop!


Consider the following test program:

/* REXX */
trace i
goto a
say 'the goto failed'
exit
a: say 'the goto worked'
exit

If you execute under TSO on z/OS 1.13 you get:

3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
3 *-* goto a
>L>   "GOTO"
>L>   "A"
>O>   "GOTO A"
.. (never-ending loop...)

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[John Gilmore]

The finding that fewer explicit GOTOs are used and need be used in
writing a routine in a statement-level language that makes the
standard structured-programming figures available is at once trivial
and important.

As I noted in an earlier post I tend to use GOTOs chiefly in recursive
processing, which the structured-programming theorists have largely
ignored.  If and when they formalize and implement recursive figures
that meet my needs, I will of course use them.  Until then I will
continue to use GOTOs, implemented as cleanly as I know how in at
least
locally standard ways.

What I have found at once odd and a distressing is all of this
late-in-the-day zealotry.  I feel no lively sense of guilt when I use
a GOTO, and I doubt that programming students shoulkd be taught to do
so.   GOTOs are and will be infrequent in well written code., but
anathema are dubious  here and elsewhere.  They belong to another,
prescientific tradition.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <4f959964.2060...@phoenixsoftware.com>, on 04/23/2012
   at 11:03 AM, Edward Jaffe  said:

>http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf

A few comments:

 1. Most of the macro instructions the paper mentions come with
the HLA toolkit. I'm not sure how they compare to the older
Concept 101 macros, which I haven't used in decades.

 2. The paper by Böhm and Jacopini makes much narrower claims than
what is often attributed to it. 

 3. Rexx does not have a GOTO. Those who try to use SIGNAL as if
it were GOTO often shoot themselves in the foot as a result.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On Wed, 25 Apr 2012 22:58:17 +0200, Fritz Wuehler
 wrote:

>"HeyBub"  wrote:
>
>> Nomen Nescio wrote:
>> >>
>> >> If you've already done it, get someone to show you the miracle of
>> >> cut-and-paste. I'd like to see the code.
>> >
>> > Sign the NDA! You should be thanking us for telling you how to save
>> > money but you just want to argue 5 billion instructions in one batch
>> > job are insignificant. So what's the point? Believe what you want.
>> > Better yet, try it yourself and learn. If you got the stuff, that is!
>> 
>> So, I took your challenge and coded it up.  Here's my code:
>> 
>>MOVE 520 TO MAX. *> 5 billion
>
>Can you show the PICTURE for MAX?
>
>>CALL 'TIMEIT-BEGIN'.
>
>Don't have this routine obviously. I'll see what else I can use. Probably
>safest to write two separate programs but with this tiny example it's not
>going to be very useful. For best results take a big program and straight
>line it as the other poster suggested. We have seen the difference. Anybody
>who tries it will also.
>
>>PERFORM MAX TIMES
>> MOVE MAX TO DUMMY
>>END-PERFORM.
>
>
>This is an inline PERFORM. It should compile like two GO TOs. We have been
>talking about old-style (non-inline) PERFORMs. If you have optimization on
>the compiler should move the MOVE outside the PERFORM and eliminate the loop
>entirely resulting in a nice piece of code one instruction long that doesn't
>loop. Of course this doesn't represent what we have been discussing which is
>hundreds of PERFORMS performing large blocks of code. The test case you
>wrote probably isn't worth anything. You have to test it with a real
>production program and you will find the same results me and the other
>poster reported.
>
>To change your inline PERFORM to the ones we have been fixing use the format
>
> PERFORM TIME-LOOP THRU TIME-LOOP-EXIT MAX TIMES.

PERFORM TIME-LOOP THRU TIME-LOOP-EXIT may not optimize because of
ambiguity of path to reach TIME-LOOP-EXIT.  If Tom Ross reads this on
IBM-MAIN he can clarify.  If you code PERFORM TIME-LOOP and TIME-LOOP
can NOT be reached by GO TO or fall through, The IBM z series compiler
will either move the code in line or general fewer instructions for
the PERFORM because it doesn't have to handle the fall through
condition.  This is based on coding programs for VS COBOL II V1R4 and
COBOL for MVS and VM in the late 1990s and reading the generated code.
If all the programs you deal with have PERFORM ... THRU or GO TO
statements you may never see the new PERFORM optimizations.  The COBOL
VS  PERFORM ... VARYING ... UNTIL was a pig.  The VS COBOL II V1R4 and
later compilers could generate some slick code.  Techniques I used to
take an hour off a compute bound program compiled with the COBOL VS
compiler and which were detailed in an article by me in a 1991 or 1992
issue of Technical Support published by NaSPA would have to be
revisited when moving to VS COBOL II V1R4 and later to reduce the CPU
time further.

Clark Morris
>
> ..
>
>TIME-LOOP.
> MOVE MAX TO DUMMY.
>TIME-LOOP-EXIT.
> EXIT.
>
>
>>CALL 'TIMEIT-DURATION' USING DURATION.
>>DISPLAY DURATION.
>>MOVE 0 TO WSCOUNT.
>>CALL 'TIMEIT-BEGIN'.
>
>>  LOOP.
>>ADD 1 TO WSCOUNT
>>MOVE MAX TO DUMMY
>>IF WSCOUNT > MAX
>> GO TO LOOP-EXIT
>>ELSE
>>  GO TO LOOP.
>>  LOOP-EXIT.
>
>This is pretty poor looping code. Unoptimized it probably generates twice as
>many tests as even an inline PERFORM. The first test is going to execute 5
>billion times for nothing since it will never be true until the end.
>
>A simple way to do this would be
>
>   MOVE ZERO TO WSCOUNT.
>
>   LOOP.
> ADD 1 TO WSCOUNT.
> MOVE MAX TO DUMMY
> IF WSCOUNT < MAX
>  GO TO LOOP.
>
>I'll check if Enterprise COBOL is smart enough to unroll this loop with
>optimization.
>
>>CALL 'TIMEIT-DURATION' USING DURATION.
>>DISPLAY DURATION.
>> 
>> The results were:
>> 
>> PERFORM = 2.36seconds
>> GO TO LOOP = 37.78 seconds
>
>Not sure why there should be so much difference. Your compiler may have
>(should have) optimized your inline PERFORM out of existence. Inline PERFORM
>is fine, it's the out of line PERFORMs we have been discussing (see previous
>posts).
>
>If you have optimization turned on also make sure it hasn't reordered the
>calls to TIMEIT-BEGIN or done anything else that could affect the timing
>between the two sections. As stated above this example isn't useful because
>it just shows the difference without paging effects. Actually it doesn't
>even show that at this point until we correct the things I mentioned.
>
>These trivial examples don't give an accurate performance measurement since
>you're running on a PC with nothing else going on and we have been talking
>about a busy mainframe shop with batch work. In a small example everything
>is on one page. Out of line PERFORM can affect the paging rate when spread
>out over a big program. The results are significant on busy systems. Another
>poster's confus

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <4f972a24.4020...@phoenixsoftware.com>, on 04/24/2012
   at 03:33 PM, Edward Jaffe  said:

>It finds that GOTO is most often used when the programmer is 
>attempting to write more efficient code yet tends to have exactly 
>the opposite effect.

Attempts at micro-optimization often have the opposite effect to that
which is intended. I'd be interested in a study of efficiency issues
when GOTO is used only to implement control structures not natively
available.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/24/2012 4:33 AM, David Crayford wrote:




http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf



That's a very interesting presentation. If I were coding in assembler I would 
follow! If IBM had made PL/X generally available would you have used that, or 
still used assembler?


PL/X? Possibly. It would have required a firm support commitment from IBM.

My fervent hope is that HLASM will eventually support these constructs (and my 
extensions to the language syntax provided by FLOWASM) natively, without 
requiring the use of macros or exits.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Bob Woodside]

The equivalent Marine rank (E-3) is Lance Corporal. The Marines do use the 
rank of Private First Class, but it is one grade lower, the equivalent of an 
Army Private (E-2).

And, with a nod to Shmuel ("Give me back my Air Force") , the Air Force 
equivalent is A1C (Airman First Class), which may be confusing to people 
diagnosed with diabetes.  :-)


Bob
--
 
On Tuesday, April 17, 2012 05:10:36 AM you wrote:
> PFC = Private First Class.  An Army rank.  The Marines may also use it.
> 
> 
> Lloyd
> 
> 
> - Original Message 
> From: Paul Gilmartin 
> To: IBM-MAIN@bama.ua.edu
> Sent: Mon, April 16, 2012 7:27:30 PM
> Subject: Re: GO TO "cobol"
> 
> On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
> >You could have the exact same result by placing a period
> >after the "2000-exit".  Then the End-if is not needed.
> >
> >
> 
> I sure am glad that COBOL attained its design objective
> of being intelligible (intuitively? unambiguously?) to a
> PFC-level programmer with only an understanding of
> vernacular English.
> 
> (Is "PFC" a Navy rank?)
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/23/2012 2:13 PM, Shmuel Metz (Seymour J.) wrote:

In<4f931b2a.9020...@phoenixsoftware.com>, on 04/21/2012
at 01:40 PM, Edward Jaffe  said:


Good compiler optimization depends on the compiler understanding
what your code  is attempting to do and structured, GOTO-less, code
is FAR easier to optimize  than its GOTO-laden counterparts.

That's an issue for ALTER and its equivalents in other languages, not
for the GOTO itself.


You might find the following of interest:

Wolfgang Gellerich, Markus Kosiol and Erhard Plödereder, "Where does GOTO Go 
to?", Reliable Software Technologies — Ada-Europe '96, Montreux, Switzerland, 
June 10–14, 1996 Proceedings, Lecture Notes in Computer Science, Volume 
1088/1996, pp. 385-395


This paper documents the disastrous effects GOTO can have on compiler 
optimization for RISC, superscalar, out-of-order execution and other 
non-obvious, but important execution efficiencies of which optimizers are 
increasingly aware. It finds that GOTO is most often used when the programmer is 
attempting to write more efficient code yet tends to have exactly the opposite 
effect.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <4f9574f3.1080...@actionsoftware.com>, on 04/23/2012
   at 11:27 AM, Gord Tomlin  said:

>Some languages allow the provision of a label for a block, and a
>LEAVE statement that takes a label as an argument. In such 
>languages this construct performs the same function as your GOTO, 
>but in a way that can  be better understood by the optimizer.

I'm not sure that there is a difference in code optimization, but the
code will be more maintamable if you use leave and next in those
languages that support them, rather than equivalent goto statements. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <4f931b2a.9020...@phoenixsoftware.com>, on 04/21/2012
   at 01:40 PM, Edward Jaffe  said:

>This is good general programming advice -- not just for COBOL
>programmers, but  for for anyone writing in any modern compiled
>language.

As defined in Alan Sherman's song "Good Advice".

>The behavior of well-defined coding structures like IF/THEN/ELSE,
>DO, SELECT,  CASE, etc. are extremely well understood--both by
>programmers and by code  optimizers no matter which language is
>being employed. This is one of the chief  reasons why structured
>programs are so much more maintainable than unstructured  ones.

Use of those constructs does not make a program well structured, and
use of goto does not make a program ill structured. You have to carve
the bird at the joints.

>Every programmer understands a-priori how the control structures
>work

Which is quite different from understanding how a particular program
using the control structure works.

>without tedious inspection of the logic to understand the possible
>paths taken.

Understanding how the *program* works can involve tedious inspection
of the logic to understand the possible paths taken even if there is
not a single goto.

>Good compiler optimization depends on the compiler understanding
>what your code  is attempting to do and structured, GOTO-less, code
>is FAR easier to optimize  than its GOTO-laden counterparts.

That's an issue for ALTER and its equivalents in other languages, not
for the GOTO itself.

>Most modern languages disallow GOTO.

FSVO modern.


>IMHO it's usually better, even when programming in older 
>languages, to avoid their use unless the language's control  
>structures are truly insufficient to handle a specific, 
>necessary case.

In most endeavors it's best to not use a hammer as a screwdriver.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[David Crayford]

http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf 





That's a very interesting presentation. If I were coding in assembler I 
would follow! If IBM had made PL/X generally available would you have 
used that, or still used assembler?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Ed Finnell]

Oh well, looked great when I sent it. Guessed it got Mime munged
 
 
In a message dated 4/23/2012 1:34:27 P.M. Central Daylight Time,  
efinnel...@aol.com writes:

Courier  New(Fixed  font)?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Ed Finnell]

___
|   | Fortran |   C| Ada   | PL8   | HLASM |
|Files without  GOTO | none| 81.5% | 99.4% | 98.5% | none   |
|Lines/GOTO | ~10 |  386   | 13614 | 1310  | <8 |
'-'

Courier  New(Fixed font)?
 
 
In a message dated 4/23/2012 1:10:13 P.M. Central Daylight Time,  
edja...@phoenixsoftware.com writes:

___
|   | Fortran  |  C| Ada   | PL8   | HLASM |
|Files  without GOTO | none| 81.5% | 99.4% | 98.5% | none   |
|Lines/GOTO | ~10 |  386   | 13614 | 1310  | <8 |
'-'



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/23/2012 11:03 AM, Edward Jaffe wrote:

___
| | Fortran | C | Ada | PL8 | HLASM |
|Files without GOTO | none | 81.5% | 99.4% | 98.5% | none |
|Lines/GOTO | ~10 | 386 |13614 | 1310 | <8 |
'-'


Ugh. Hopefully this formats better:

___
|   | Fortran |  C| Ada   | PL8   | HLASM |
|Files without GOTO | none| 81.5% | 99.4% | 98.5% | none  |
|Lines/GOTO | ~10 | 386   | 13614 | 1310  | <8|
'-'



http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf



--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/23/2012 10:48 AM, Clark Morris wrote:

If IBM had implemented the EXIT enhancements in the 2002 standard we
would have available

EXIT PERFORM (for inline PERFORMs which are like DO loops)
EXIT PERFORM CYCLE which allows iteration without having to do
unnatural things in the code
EXIT PARAGRAPH
EXIT SECTION.

I know I could have used them.  Unfortunately many companies seem
stuck on coding standards last updated for COBOL VS.



Though not specific to COBOL, there are two excellent studies/papers worth 
reading on this subject:


Wolfgang Gellerich, Markus Kosiol and Erhard Plödereder, "Where does GOTO Go 
to?", Reliable Software Technologies — Ada-Europe '96, Montreux, Switzerland, 
June 10–14, 1996 Proceedings, Lecture Notes in Computer Science, Volume 
1088/1996, pp. 385-395


This paper documents the disastrous effects GOTO can have on compiler 
optimization for RISC, superscalar, out-of-order execution and other 
non-obvious, but important execution efficiencies of which optimizers are 
increasingly aware. It finds that GOTO is most often used when the programmer is 
attempting to write more efficient code yet tends to have exactly the opposite 
effect.


W.Gellerich and E.Plödereder, "The Evolution of GOTO Usage and Its Effects on 
Software Quality," Informatik'99,

K.Beiersdörfer, G.Engels, and W.Schäfer, Eds., Springer-Verlag, Berlin, 1999

This paper presents the results of a study in which the frequency and typical 
applications of GOTO in over 400 MB of C and Ada source code were analyzed. The 
analysis demonstrated that the availability of sufficiently powerful control 
structures in a language significantly reduces the frequency of GOTO. Relating 
these results to error rates reported for large software projects indicates that 
programs written with lower GOTO density are more reliable.


Though tangential to the core discussion, the following article references the 
above studies and might be of interest to those involved with this platform:


W.Gellerich, T.Hendel, R. Land, H.Lehmann, M. Mueller, P. H.Oden, H.Penner, "The 
GNU 64-bit PL8 compiler: Toward an open standard environment for firmware 
development", IBM Journal of Research & Development, 48, No. 3/4, May/July 2004, 
pp. 3-4.


This paper compares GOTO density metrics for Fortran, C, Ada, and PL8 (the 
language in which System z firmware is written). I added HLASM to the chart for 
a SHARE presentation I gave back in 2008 in San Jose (link below).


___
| | Fortran | C | Ada | PL8 | HLASM |
|Files without GOTO | none | 81.5% | 99.4% | 98.5% | none |
|Lines/GOTO | ~10 | 386 |13614 | 1310 | <8 |
'-'

http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8133EJ131525.pdf

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On 23 Apr 2012 10:21:03 -0700, in bit.listserv.ibm-main you wrote:

>Gord,
>
>Not quite.

If IBM had implemented the EXIT enhancements in the 2002 standard we
would have available 

EXIT PERFORM (for inline PERFORMs which are like DO loops)
EXIT PERFORM CYCLE which allows iteration without having to do
   unnatural things in the code
EXIT PARAGRAPH
EXIT SECTION.

I know I could have used them.  Unfortunately many companies seem
stuck on coding standards last updated for COBOL VS.

Clark Morris 
>
>PL/I is the archetypical; language that makes these facilities
>available, and in it the label associated with a leave statement can
>only be that of a containing group, as in
>
>outer: do ;
>  inner: do ;
> . . .
> leave outer :
> . . .
>  end inner :
>end outer ;
>
>in which execution of the leave statement transfers control to the
>statement following the
>
>end outer ;
>
>statement.
>
>The GOTO I described transfers control to the statement following the
>instance of a label associated with the first invocation of a
>procedure from the invocation of that procedure in which it is
>executed.
>
>Note that PL/I can do this.  If you supply a label constant, call it
>gubbins, to a procedure as an argument and then, within that
>invocation or a subsequent, recursive invocation of this procedure
>execute the statement
>
>goto gubbins ;
>
>control will be returned to the instance of the label gubbins active
>at the time of the first call,he DSA stack weill be purged
>appropriately, etc., etc..
>
>John Gilmore, Ashland, MA 01721 - USA
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Gord Tomlin]

Nice trick.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-04-23 13:18, John Gilmore wrote:

Gord,

Not quite.

PL/I is the archetypical; language that makes these facilities
available, and in it the label associated with a leave statement can
only be that of a containing group, as in

outer: do ;
   inner: do ;
  . . .
  leave outer :
  . . .
   end inner :
end outer ;

in which execution of the leave statement transfers control to the
statement following the

end outer ;

statement.

The GOTO I described transfers control to the statement following the
instance of a label associated with the first invocation of a
procedure from the invocation of that procedure in which it is
executed.

Note that PL/I can do this.  If you supply a label constant, call it
gubbins, to a procedure as an argument and then, within that
invocation or a subsequent, recursive invocation of this procedure
execute the statement

goto gubbins ;

control will be returned to the instance of the label gubbins active
at the time of the first call,he DSA stack weill be purged
appropriately, etc., etc..

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[John Gilmore]

Gord,

Not quite.

PL/I is the archetypical; language that makes these facilities
available, and in it the label associated with a leave statement can
only be that of a containing group, as in

outer: do ;
  inner: do ;
 . . .
 leave outer :
 . . .
  end inner :
end outer ;

in which execution of the leave statement transfers control to the
statement following the

end outer ;

statement.

The GOTO I described transfers control to the statement following the
instance of a label associated with the first invocation of a
procedure from the invocation of that procedure in which it is
executed.

Note that PL/I can do this.  If you supply a label constant, call it
gubbins, to a procedure as an argument and then, within that
invocation or a subsequent, recursive invocation of this procedure
execute the statement

goto gubbins ;

control will be returned to the instance of the label gubbins active
at the time of the first call,he DSA stack weill be purged
appropriately, etc., etc..

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Gord Tomlin]

Some languages allow the provision of a label for a block, and a LEAVE 
statement that takes a label as an argument. In such languages this 
construct performs the same function as your GOTO, but in a way that can 
be better understood by the optimizer.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-04-23 10:44, John Gilmore wrote:

Edward Jaffe's already cited point, that


The behavior of well-defined coding structures like IF/THEN/ELSE, DO,
SELECT, CASE, etc. are extremely well understood--both by programmers
and by code optimizers no matter which language is being employed.


is fundamentally important.   Optimizers distinguish many special
cases of each of these figures, generating slightly but significantly
different code for each of them.

A routine that is comprised chiefly of instances of these figures is
thus easy to optimize, and this is often the case even when these
figures are used less felicitously than than they should be.  An
optimizer can mitigate the bad-performance effects of ugly code.

It must, however, be remembered that the code generated for, say, a DO
WHILE or a DO UNTIL contains and makes critical use of unconditional
branches.  They are indeed implicit in these two figures and, of
course, in IF-THEN-ELSE too.

The question when GOTOs, i.e., unconditional branches, should be used
explicitly is thus the interesting one.

I myself use them where 1) I judge that they confer a significant
performance benefit and 2) they can be used in a regular/orderly way.

IN looking through code that I have written recently for instances
of them I discovered something that I had not really been aware of.
I use them most often to unwind recursions and for catastrophic
error-handling.

If, say, in traversing a binary-search tree recursively in some key
sequence I find what I
want,  I use a 'stack-cleaning long branch' to return to the point at
which I began the traversal.  This 'out-of-block GOTO' is not strictly
necessary; but the alternative, a sequence of several stack-unwinding
returns, is ugly and slow.

To summarize now, there are,  I think, situations in which explicit
GOTOs are appropriate, in which their use can confer significant,
readily measurable performance benefits.

Unfortunately, these situations are also highly problematic.  To use
GOTOs effectively in them one needs to know more about run-time
dynamics than most programmers now know  or  are, I fear, ever again
likely to be taught.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[John Gilmore]

Edward Jaffe's already cited point, that


The behavior of well-defined coding structures like IF/THEN/ELSE, DO,
SELECT, CASE, etc. are extremely well understood--both by programmers
and by code optimizers no matter which language is being employed.


is fundamentally important.   Optimizers distinguish many special
cases of each of these figures, generating slightly but significantly
different code for each of them.

A routine that is comprised chiefly of instances of these figures is
thus easy to optimize, and this is often the case even when these
figures are used less felicitously than than they should be.  An
optimizer can mitigate the bad-performance effects of ugly code.

It must, however, be remembered that the code generated for, say, a DO
WHILE or a DO UNTIL contains and makes critical use of unconditional
branches.  They are indeed implicit in these two figures and, of
course, in IF-THEN-ELSE too.

The question when GOTOs, i.e., unconditional branches, should be used
explicitly is thus the interesting one.

I myself use them where 1) I judge that they confer a significant
performance benefit and 2) they can be used in a regular/orderly way.

IN looking through code that I have written recently for instances
of them I discovered something that I had not really been aware of.
I use them most often to unwind recursions and for catastrophic
error-handling.

If, say, in traversing a binary-search tree recursively in some key
sequence I find what I
want,  I use a 'stack-cleaning long branch' to return to the point at
which I began the traversal.  This 'out-of-block GOTO' is not strictly
necessary; but the alternative, a sequence of several stack-unwinding
returns, is ugly and slow.

To summarize now, there are,  I think, situations in which explicit
GOTOs are appropriate, in which their use can confer significant,
readily measurable performance benefits.

Unfortunately, these situations are also highly problematic.  To use
GOTOs effectively in them one needs to know more about run-time
dynamics than most programmers now know  or  are, I fear, ever again
likely to be taught.


John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[David Andrews]

On Sat, 2012-04-21 at 16:40 -0400, Edward Jaffe wrote:
> The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, 
> CASE, etc. are extremely well understood--both by programmers and by code 
> optimizers no matter which language is being employed.

Hmm.  I wonder if the COBOL compiler generates equivalent code for:
GO TO ... DEPENDING ON X
(which I've always understood was a simple branch table) and:
EVALUATE X
WHEN 1 ...
WHEN 2 ...

Hey John, there's a research topic for you in your copious spare time!

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On Sun, 22 Apr 2012 08:14:11 -0500, "HeyBub" 
wrote:

>Nomen Nescio wrote:
>>
>> These aren't "microscopic optimizations" but something easy to do
>> that every programmer should be aware of. It doesn't take longer to
>> do things right the first time.
>>
>>> If you worked for me, I'd fire you for wasting my money.
>>
>> Don't flatter yourself. You couldn't find your ass with both hands
>> much less fire anybody.
>
>Show me. Supply some sample code comparing a PERFORM to a GO TO.
>
>It will be easy enough to stick timers in the code for a million (or a 
>billion) iterations.
>
>So, I say again, show me that the difference is significant, or even 
>measurable. 
>
In a program with heavy use of PERFORM where the compiler has to
assume that execution can fall through to the next instruction at the
exit point rather than always return to the instruction following the
PERFORM, it could make a modest difference.  Nomen and Fritz both seem
to be coding based on how the IBM 370 COBOL VS compiler worked.  In
most cases even with the 1974 compiler the difference was trivial
because the CPU time was a small part of the overall run time.  Also
the instruction path length was and is far longer for I-O requests and
implied or explicitly coded CALL statements, especially if the DYNAM
(load the CALLED module at execution time or delayed binding) was
chosen.

Having said the above, I am confident that I can take any program
optimized for the COBOL VS environment and restructure it eliminating
GO TO statements and have the resulting program execute with the same
or less CPU time.  I am assuming that both the before and after
versions are compiled with OPTIMIZE.

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/21/2012 12:52 PM, Clark Morris wrote:

On Thu, 19 Apr 2012 04:42:55 +0200, Fritz Wuehler
| ... Practical experience
| beats the college boys every time, especially burnt-out duffers like
| Dijkstra who never sold a line of code and probably never wrote one either.
Based on presentations by Tom Ross at SHARE (IBM COBOL representative)
and my reading of the generated assembler code, I changed my coding
practices to make sure all GO TO statements were eliminated because
they mess up PERFORM optimization.


This is good general programming advice -- not just for COBOL programmers, but 
for for anyone writing in any modern compiled language.


The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, 
CASE, etc. are extremely well understood--both by programmers and by code 
optimizers no matter which language is being employed. This is one of the chief 
reasons why structured programs are so much more maintainable than unstructured 
ones. Every programmer understands a-priori how the control structures work 
without tedious inspection of the logic to understand the possible paths taken.


Good compiler optimization depends on the compiler understanding what your code 
is attempting to do and structured, GOTO-less, code is FAR easier to optimize 
than its GOTO-laden counterparts. A GOTO will often serve as a "monkey wrench" 
thrown into the "works" of the compiler optimization algorithms. GOTOs are 
unpredictable; compilers don't know in advance where they will appear in the 
code; they don't know in advance what the target of the GOTO will be. The 
optimization algorithms must adapt to a "surprise" situation they best they can. 
In some cases the GOTO will be highly disruptive; in other cases less so.


Most modern languages disallow GOTO. IMHO it's usually better, even when 
programming in older languages, to avoid their use unless the language's control 
structures are truly insufficient to handle a specific, necessary case.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On Thu, 19 Apr 2012 04:42:55 +0200, Fritz Wuehler
 wrote:

>mathwst...@bellsouth.net (Matthew Stitt) wrote:
>
>> Having said that, I still use GO TO extensively, and have not kept up with 
>> the "modern" programming extensions and constructs.
>> I've had many instances in my career where a "structured" program has been 
>> "straight lined" with extremely dramatic performance
>> results.  Mostly I believe that knowing Assembler language and how the COBOL 
>> compiler would generate the assembler code version
>> of the program provided the reasons for my coding techniques.  I would write 
>> the program as close to what the assembler code
>> would be as possible.  This would usually provide some great performance
>> at run time (and at compile time).
>
>and
>
>> One example (out of several) was a program which normally took 4-6 hours to 
>> do its magic.  When I re-wrote it due to the necessity
>> of adding more functionality, I went ahead and "straight lined" it according 
>> to the logic of what the program was supposed to do.
>> When the re-write was finished, the new program took 20 minutes to run the 
>> first time it was in production.  I have several other
>> examples with these type of results.
>
>This gets back to what I said. PERFORM is net 5 instructions more *per
>PEFORM* than two GO TOs so loops processing millions of records get very
>expensive fast and avoiding GO TO and being forced to use PERFORM causes you
>to create more loops than you would need with GO TO. Last time I looked,
>COBOL doesn't inline PERFORM so you pay the penalty hundreds or thousands of
>millions of times in a big program processing a big file. And paging is
>usually worse because of the unnatural long branches caused byPERFORM, when
>straight line coding with careful use of GO TOs would have reduced paging.
>
>> Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a 
>> perform.  Went to the Well in the early-mid 80's over that 
>> one with a bunch of certain "whiz-kids" who were trained under the good
>> doctors premises.
>
>Thanks for your post, it is what I experienced as well. Practical experience
>beats the college boys every time, especially burnt-out duffers like
>Dijkstra who never sold a line of code and probably never wrote one either.

I am writing this as some one who used ALTER ... GO TO to replace
PERFORM statements in DOS 360 COBOL.  I had an article published in an
issue of Technical Support, the magazine of the National Systems
Programmer Association (now Network and Systems Professionals
Association) telling how I cut the execution time of a compute bound
run by over an hour (it was running on a 3081).  The program was COBOL
VS and the 1974 standard COBOL running on MVS.  This included
replacing PERFORM ... VARYING with simple PERFORMs and looping within
the PERFORMed paragraph by using IF statements within the paragraph
that would GO TO the paragraph being performed.  I am grateful that I
had the caveat in the article that the new VS COBOL II might change
some of the optimizations.  

As someone who has looked carefully at the code generated by PERFORM
on IBM 360/370/390/z series systems, starting with VS COBOL II 1.4,
the first Ansi 85 IBM compiler the ball game changed. On COBOL VS (74
standard) and prior there were statements like
MVC save_exit_address,exit_address
MVC exit_address,return_address
L R15,perform_paragraph_start
BR R15
return_point DS 0H
MVC exit_address,save_exit_address.

There would be a
L R15,exit_address
BR R15
at the end of the perform range. With COBOL 85, if the paragraph
being performed is entered by a PERFORM statement, and there is never
a fall through to the next paragraph and there are no GO TO statements
in the paragraph, depending on various algorithms the performed
paragraph may be moved inline with all perform code eliminated.
PERFORM ... VARYING went from being a pig to having very efficient
code. PERFORM x THRU x-exit in most if not all cases will still
require the same 3 moves with even the latest COBOL because of the
semantics of COBOL.

Based on presentations by Tom Ross at SHARE (IBM COBOL representative)
and my reading of the generated assembler code, I changed my coding
practices to make sure all GO TO statements were eliminated because
they mess up PERFORM optimization. Code optimization I did that saved
substantial time on that compute bound run for COBOL VS would have to
have be redone to take advantage of the PERFORM optimization in VS
COBOL II release 1.4 and newer.  There were other things done that
were valuable when using the COBOL VS compiler that became
counter-productive with the VS COBOL compiler.

With any major compiler upgrade, you should review the language
reference manual and the programmers guide to see if changes should be
made in coding style to take advantage of different ways of
optimization or newer constructs.  The IBM COBOL compiler
optimizations (when OPTIMIZE is chosen) are designed to supp

Re: GO TO "cobol"

[Lloyd Fuller]

My use was in 1969 and only at Fort Ben.  From school, I went to Fort Monroe, 
VA 
and worked on a 360/40 running PCP version of OS/360.

I remembered that the 1004 had a plugboard, but I thought that you could also 
run programs on it.  We may have had to assembler the programs on the 1005.  
The 
1005 that we were taught on was the single address machine version.  I do not 
remember being told about a two-address version.

Lloyd



- Original Message 
From: Shmuel Metz (Seymour J.) 
To: IBM-MAIN@bama.ua.edu
Sent: Thu, April 19, 2012 5:23:52 PM
Subject: Re: GO TO "cobol"

In <1334839226.16701.yahoomai...@web180901.mail.ne1.yahoo.com>, on
04/19/2012
   at 05:40 AM, Lloyd Fuller  said:

>Actually, the 1004 and the 1005 versions. 

The 1004 was programmed with a plugboard. The 1005 started life as a
special plugboard for the 1004. There were two versions of the 1005; a
single address machine and a two-address machine. SAAL was Single
Address Assembly Language for the single address 1005.

>The only thing that I really remember about them is that you had to
>know which panel(s) to kick to get the machine to boot.

I guess that I was lucky. The only one that I saw was at Ft.
MacArthur, and it loaded without any issues. Of course, with my last
use in 1968 it might not have worked so well by the time you came
around.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <1334839226.16701.yahoomai...@web180901.mail.ne1.yahoo.com>, on
04/19/2012
   at 05:40 AM, Lloyd Fuller  said:

>Actually, the 1004 and the 1005 versions. 

The 1004 was programmed with a plugboard. The 1005 started life as a
special plugboard for the 1004. There were two versions of the 1005; a
single address machine and a two-address machine. SAAL was Single
Address Assembly Language for the single address 1005.

>The only thing that I really remember about them is that you had to
>know which panel(s) to kick to get the machine to boot.

I guess that I was lucky. The only one that I saw was at Ft.
MacArthur, and it loaded without any issues. Of course, with my last
use in 1968 it might not have worked so well by the time you came
around.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

Actually, the 1004 and the 1005 versions.  I could not remember the names.  The 
only place that I ever saw them was at the school.

The only thing that I really remember about them is that you had to know which 
panel(s) to kick to get the machine to boot.  The interlocks were very worn and 
did not seat properly.  We were told that some of the ones in the field were 
even worse.

Lloyd



- Original Message 
From: Shmuel Metz (Seymour J.) 
To: IBM-MAIN@bama.ua.edu
Sent: Wed, April 18, 2012 7:32:08 PM
Subject: Re: GO TO "cobol"

In <1334691539.94814.yahoomai...@web180906.mail.ne1.yahoo.com>, on
04/17/2012
   at 12:38 PM, Lloyd Fuller  said:

>Univac SAAL computers

ITYM UNIVAC 1005[1]. I had successfully ripped the memory out by the
roots; thank you for reminding me :-(

[1] SAAL was the assembler.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Steve Comstock]

On 4/18/2012 11:06 PM, Dale Miller wrote:

Years ago, I learned my first programming language (FORTRAN) from an excellent
book by Daniel McCracken who was justly famous for his excellent programming
books. He was also known, (but not quite as well) for a mid-life crisis which
involved completing a degree from a seminary, but never getting ordained, if my
memory serves me. His popularity peaked around the time of the big push for
structured programming, and I attended a discussion by him of structured
programming. He was positive about it, but with a few caveats. I do remember his
saying (approximately):"Pity the poor COBOL programmer working on the error
recovery routines for Indexed-Sequential file handling, who finds himself 5
levels deep in nested PERFORMS, and is heard to shout as he sinks beneath the
waves: 'Just one GO TO!'.".
Looking at the situation where there are multiple conditions under which a
procedure/block should terminate, if one is forced to follow the stricture of a
single exit from a procedure, one is forced to choose between a convoluted set
of nested if's or using goto's to the single exit point. The use of goto's could
be considerably easier to follow, especially in the case of the original
non-structured COBOL where PERFORM's would be necessary.

Dale Miller


Well that brings back memories! I worked with Dan, back in the late
70's I think it was. I wrote the script and accompanying handouts
for is ASI video tape series on structured COBOL. Many of you
probably remember ASI and Deltak (and a few others, but these
were the big two) when large chunks of training were built around
video libraries.

When I left IBM to work for myself, I thought IBM would be my
biggest competitor. In those days, however, it was ASI and Deltak.
Over the years I ended up doing some work for both of them and
speaking at their conferences. Even did some work in London for
ASI. Good days.



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Dale Miller]

Years ago, I learned my first programming language (FORTRAN) from an  
excellent book by Daniel McCracken who was justly famous for his  
excellent programming books. He was also known, (but not quite as  
well) for a mid-life crisis which involved completing a degree from a  
seminary, but never getting ordained, if my memory serves me. His  
popularity peaked around the time of the big push for structured  
programming, and I attended a discussion by him of structured  
programming. He was positive about it, but with a few caveats. I do  
remember his saying (approximately):"Pity the poor COBOL programmer  
working on the error recovery routines for Indexed-Sequential file  
handling, who finds himself 5 levels deep in nested PERFORMS, and is  
heard to shout as he sinks beneath the waves: 'Just one GO TO!'.".
Looking at the situation where there are multiple conditions under  
which a procedure/block should terminate, if one is forced to follow  
the stricture of a single exit from a procedure, one is forced to  
choose between a convoluted set of nested if's or using goto's to the  
single exit point. The use of goto's could be considerably easier to  
follow, especially in the case of the original non-structured COBOL  
where PERFORM's would be necessary.


Dale Miller

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Paul Gilmartin]

On Wed, 18 Apr 2012 21:59:33 -0300, Clark Morris wrote:

>On Wed, 18 Apr 2012 23:04:51 +0200 (CEST), in bit.listserv.ibm-main
>Nomen Nescio wrote:
> 
Hoo dat!?

>>This gets back to what I said. PERFORM is net 5 instructions more *per PEFORM*
>>than two GO TOs (to and fro) so loops processing millions of records get very
>>expensive fast and avoiding GO TO by being forced to use PERFORM causes you
>>to create more loops  ...
>
I'm just sitting here trying to imagine what significant fraction of the
time required to "process [a] record" is 5 instructions.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On Wed, 18 Apr 2012 23:04:51 +0200 (CEST), in bit.listserv.ibm-main
Nomen Nescio wrote:

* this is a response to a posting to just the newsgroup and not the
listserv

>mathwst...@bellsouth.net (Matthew Stitt) wrote:
>
>> Having said that, I still use GO TO extensively, and have not kept up with 
>> the "modern" programming extensions and constructs.
>> I've had many instances in my career where a "structured" program has been 
>> "straight lined" with extremely dramatic performance
>> results.  Mostly I believe that knowing Assembler language and how the COBOL 
>> compiler would generate the assembler code version
>> of the program provided the reasons for my coding techniques.  I would write 
>> the program as close to what the assembler code
>> would be as possible.  This would usually provide some great performance
>> at run time (and at compile time).
>
>&&
>
>> One example (out of several) was a program which normally took 4-6 hours to 
>> do its magic.  When I re-wrote it due to the necessity
>> of adding more functionality, I went ahead and "straight lined" it according 
>> to the logic of what the program was supposed to do.
>> When the re-write was finished, the new program took 20 minutes to run the 
>> first time it was in production.  I have several other
>> examples with these type of results.
>
>This gets back to what I said. PERFORM is net 5 instructions more *per PEFORM*
>than two GO TOs (to and fro) so loops processing millions of records get very
>expensive fast and avoiding GO TO by being forced to use PERFORM causes you
>to create more loops than you would have used with GO TO since it changes
>the paradigm from essentially full steam ahead (straight line) to LET'S MAKE
>A LOOP! Last time I looked, COBOL doesn't inline PERFORM so you pay the
>penalty hundreds or thousands of millions (yeah billions, definitely
>billions) of times in a big program processing a big file. And paging is
>usually significantly worse because of the unnatural long branches caused by
>PERFORM, when straight line coding with careful use of GO TOs would have
>reduced paging since only errors and stuff like page breaks are handled out
>of line.

What you are saying was true with the COBOL VS (1974 standard)
compiler.  If you use OPTIMIZE AND do not reach any PERFORMed
paragraph via GO TO or fall through, with VS COBOL II V1R4 and
subsequent 390 and z compilers, the PERFORM will NOT take 5
instructions and depending on various conditions the PERFORM will be
replaced by the code of the paragraph being PERFORMed.  Having coded
many programs using ALTER switch-paragraph TO next-para GO TO
process-paragraph to save perform overhead, the change was dramatic.
The addition of inline PERFORM, the EVALUATE statement and the END-IF,
END-EVALUATE etc. statements have drastically changed the ball game.
If you are still coding COBOL for use on IBM z series boxes spend time
reading both the Language Reference and the Programmers Guide.
Understand and select the OPTIMIZE and TRUNC options that work in the
environment you are coding for and then code some programs and look at
the code generated.  Programs with large numbers of GO TO statements
will drive the optimizer crazy. 

I just wish that IBM would find it worth while to add the really
useful constructs in the 2002 standard such as USAGE BIT, bit
manipulation, EXIT PARAGRAPH and others.  However if the majority of
programmers remain actually or mentally stuck on the 1974 compiler, it
probably would be a waste of money.

Clark Morris 
>
>> Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a 
>> perform.  Went to the Well in the early-mid 80's over that 
>> one with a bunch of certain "whiz-kids" who were trained under the good 
>> doctors premises.
>
>Thanks for your post, it is what I experienced as well and not just once but
>dozens of times. In the old days this was never a question but decades later
>I fixed a lot of code by tearing out the spaghetti PERFORMS and processing
>forward in an orderly fashion. It is easier to understand and maintain and
>it works a lot better. For COBOL and assembler programmers that is. I don't
>really care what the C and Java crowd think of it and if they push me I'll
>rip out all their do whiles and fors and replace them all with GOTOs. Don't
>make me open this can!
>
>Practical experience beats the college boys every time, especially burnt-out
>duffers like Dijkstra who never sold a line of code and probably never wrote
>one either.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <1334691539.94814.yahoomai...@web180906.mail.ne1.yahoo.com>, on
04/17/2012
   at 12:38 PM, Lloyd Fuller  said:

>Univac SAAL computers

ITYM UNIVAC 1005[1]. I had successfully ripped the memory out by the
roots; thank you for reminding me :-(

[1] SAAL was the assembler.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Ed Finnell]

And the Computer Systems Command was out of Ft. Belvoir, VA and  had 
administrative offices out at the Melpar bldg. on Route 50 along with a  drone 
development pgm out of DARPA. Classes were offered from DODCI at the Naval  
Yard for civilians and military.
 
 
In a message dated 4/18/2012 6:46:58 A.M. Central Daylight Time,  
leful...@sbcglobal.net writes:

could  have been programming classes taught there.  Fort Ben was the  
administrative and financial training  base.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

Fort Huachuca is in Arizona, and when I was in the Army was the training base 
for some of the communications stuff.  The other communications training was 
Fort Monmouth, New Jersey.

I believe that Fort Huachuca also had some intelligence schools there.  That 
could have been programming classes taught there.  Fort Ben was the 
administrative and financial training base.

Lloyd



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Wed, April 18, 2012 1:03:56 AM
Subject: Re: GO TO "cobol"

Loyd:

Fort Wauchooka (sp??) rings a bell somewhere in my cob  ridden memory. But I 
also now remember Ft Ben Harrison (now). I remember the guys talking about the 
desert and thats about all.

Ed

On Apr 17, 2012, at 7:17 AM, Lloyd Fuller wrote:

> In 1969, and until sometime in the 1970s or later, the Army programming school
> was at Fort Benjamin Harrison in Indiana.
> 
> 
> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming
> since then.
> 
> lLOYD
> 
> 
> 
> - Original Message 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 12:16:33 AM
> Subject: Re: GO TO "cobol"
> 
> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>> SNIP-
>> Also remember that COBOL, at least originally, was supposed to be very
>> English-like and so usable by people at the Army PFC level of training.
>> 
>> --John McKown
>> Systems Engineer IV
>> IT
> 
> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
its
> been 40 years so forgive me). We had two groups, one COBOL (batch processing)
> and one ASM group (essentially sysprogs). The ASM group was by far the best 
>IMO.
> I was on call quite often and had to "fix" the cobol programs that went boom 
in
> the middle of the night. The COBOL people were semi useless in debugging and
> when I looked at the code they had produced (except for a few people) it was
> hopeless to understand. I spent more time trying to figure out the logic and
> compare what I was seeing in the dump. 1/3 the time I helped the programmer
> figure out where his problem was and supplying answers to his questions on 
what
> was in this field or that field.
> What was interesting was that as the guys (no female programmers so don't call
> me sexist blame the Army not me) as they became more experienced the code 
>became
> easier to follow. As they became became better programmers there were less 
>logic
> problems. Now having said that most of the programs were  smallish and only a
> few were considered large so the smallish programs there was no excuse for 
>logic
> issues or mangled code. My memory is foggy here as to goto's but I think the
> "rule" no standards if memory serves me that goto's were to be minimized as a
> result flow was easier to follow and frankly debugging was easier.
> 
> Ed
> 
> ps: We had one person who at the time he was drafted was working for IBM and 
he
> privately told me about some OS enhancements that when I first heard I 
couldn't
> wrap my head around as virtual (at least that I had never heard of) was a
> nightmare that I couldn't wrap my head around. After I got out of the Army (2
> years) IBM announced Virtual and I was able to ask some semi intelligent
> questions as my "preview" and the questions helped jump start by job.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Ed Gould]

Loyd:

Fort Wauchooka (sp??) rings a bell somewhere in my cob  ridden  
memory. But I also now remember Ft Ben Harrison (now). I remember the  
guys talking about the desert and thats about all.


Ed

On Apr 17, 2012, at 7:17 AM, Lloyd Fuller wrote:

In 1969, and until sometime in the 1970s or later, the Army  
programming school

was at Fort Benjamin Harrison in Indiana.


Graduated in March 1969 as a Staff Sergeant converted to a SP6.   
Programming

since then.

lLOYD



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 12:16:33 AM
Subject: Re: GO TO "cobol"

On Apr 16, 2012, at 8:34 AM, McKown, John wrote:

SNIP-
Also remember that COBOL, at least originally, was supposed to be  
very
English-like and so usable by people at the Army PFC level of  
training.


--John McKown
Systems Engineer IV
IT


Hmmm... I was in the Army and we got PFC's from the programming  
school (AZ? its
been 40 years so forgive me). We had two groups, one COBOL (batch  
processing)
and one ASM group (essentially sysprogs). The ASM group was by far  
the best IMO.
I was on call quite often and had to "fix" the cobol programs that  
went boom in
the middle of the night. The COBOL people were semi useless in  
debugging and
when I looked at the code they had produced (except for a few  
people) it was
hopeless to understand. I spent more time trying to figure out the  
logic and
compare what I was seeing in the dump. 1/3 the time I helped the  
programmer
figure out where his problem was and supplying answers to his  
questions on what

was in this field or that field.
What was interesting was that as the guys (no female programmers so  
don't call
me sexist blame the Army not me) as they became more experienced  
the code became
easier to follow. As they became became better programmers there  
were less logic
problems. Now having said that most of the programs were  smallish  
and only a
few were considered large so the smallish programs there was no  
excuse for logic
issues or mangled code. My memory is foggy here as to goto's but I  
think the
"rule" no standards if memory serves me that goto's were to be  
minimized as a

result flow was easier to follow and frankly debugging was easier.

Ed

ps: We had one person who at the time he was drafted was working  
for IBM and he
privately told me about some OS enhancements that when I first  
heard I couldn't
wrap my head around as virtual (at least that I had never heard of)  
was a
nightmare that I couldn't wrap my head around. After I got out of  
the Army (2
years) IBM announced Virtual and I was able to ask some semi  
intelligent

questions as my "preview" and the questions helped jump start by job.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 14:32:30 -0700, in bit.listserv.ibm-main you wrote:

>Use of NEXT SENTENCE is as dangerous as GO TO.  Try using CONTINUE.
>
>The former takes you to the next period;  the latter takes you to the end 
>of the current conditional.  One missed period and 
>
>--
>
>I've seen many programs without a single period.  How they work is beyond
>my comprehension.  Of course, a paragraph name does imply a period.

All paragraphs have to end with a period.  

Clark Morris
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 14:25:19 -0700, in bit.listserv.ibm-main you wrote:

>I have many years' experience writing COBOL code and have used GO TO and
>THRU only as a means of exiting a paragraph.  I frequently code paragraph
>subroutines that perform a series of related edits, and would use them like
>this:
>
> Perform 2000-Validate-Input thru 2000-exit.
>*test resultant switch settings here... 
>
>
> 2000-Validate-Input.
>
> If some-test-here-failed
> Set indicator-switch to true
> Go to 2000-exit
> End-if.
>
> If some-other-test-fails
> Set indicator-different-switch to true
> Go to 2000-exit
> End-if.
>
>* Blah, blah, blah
>
>* When you get here, all tests are good and action can be taken
>
> 2000-exit.
> Exit.
>
>
>The THRU clause is only to support an "exit paragraph" ability.  Because I
>follow some rules with this technique, it has never caused me a problem.
>The rules?  They are simple:
>
>- Only "go to" the exit point for the current paragraph.  I never span.
>This means that the "go to" statements are always pointed downward - the
>same way my perform statements always point.
>
>- I verify that this rule is observed by F GO WORD in ISPF (with comments
>excluded).  Each time I find a GO, I then look for P'-' 8 to ensure that
>the exit paragraph is the next paragraph.
>
>I, too, believe that "thru" and "section" is a preference that can't be
>persuaded in most people.  I personally hate to use sections and view them
>as evil.  When forced to use sections, such as when performing an internal
>sort, I just code unreferenced "dummy" sections around my input and output
>sections.
>
>It would be nice if an "exit paragraph" statement existed.  When it does,
>I'll never need a THRU or GO TO again - and good riddance!
>
It has existed in the COBOL standard since 2002, just not in any IBM
compiler.  Add it to the list of SHARE requirements for functions that
exist in the 2002 standard.

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 11:02:51 -0700, in bit.listserv.ibm-main you wrote:

>A dirty myth about COBOL is the belief the THRU is required and that SECTIONs 
>are a good idea. Unless specifically required by SORT or something, I never 
>used either. It has been 20+ years since I did much COBOL. Haven't had the 
>pleasure of the newer constructs.

Nothing requires sections any more.  My comments on GO TO are based on
the compiler optimizations done for PERFORM and what GO TO does to
those optimizations.  Also the IF ... END-IF READ ... END-READ etc.
statements greatly reduce complexity.  If you don't believe that GO TO
can have an effect try compiling a program generated by CSP release 4
with all its GO TO statements with OPTIMIZE.  If the module is large
enough it can give the compiler real fits and chew CPU time
unbelievably.

Clark Morris 
>
>As to the OP's belief about performance, structured programming has never been 
>about performance, it is about understandability.
>
>Dave Gibney
>Information Technology Services
>Washington State University
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> Behalf Of McKown, John
>> Sent: Monday, April 16, 2012 5:28 AM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: GO TO "cobol"
>> 
>> Our use of GO TO is generally restricted to usage such as:
>> 
>>PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
>> 
>> I-P.
>> READ FILE AT END
>>  SET CONDITION TO TRUE
>>  GO TO I-P-EXIT
>> END-READ
>> ...
>> I-P-EXIT.
>> EXIT.
>> 
>> Otherwise, to avoid the GO TO, we'd need to do:
>> 
>> I-P.
>> READ FILE AT END
>>  SET CONDITION TO TRUE
>> END-READ
>> IF NOT CONDITION THEN
>> ...
>> END-IF.
>> I-P-EXIT.
>> EXIT.
>> 
>> Which I consider to be worse than the exit, so far as comprehension is
>> concerned.
>> 
>> --
>> John McKown
>> Systems Engineer IV
>> IT
>> 
>> Administrative Services Group
>> 
>> HealthMarkets®
>> 
>> 9151 Boulevard 26 . N. Richland Hills . TX 76010
>> (817) 255-3225 phone .
>> john.mck...@healthmarkets.com . www.HealthMarkets.com
>> 
>> Confidentiality Notice: This e-mail message may contain confidential or
>> proprietary information. If you are not the intended recipient, please 
>> contact
>> the sender by reply e-mail and destroy all copies of the original message.
>> HealthMarkets® is the brand name for products underwritten and issued by
>> the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life
>> Insurance Company®, Mid-West National Life Insurance Company of
>> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>> 
>> 
>> 
>> > -Original Message-
>> > From: IBM Mainframe Discussion List
>> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
>> > Sent: Monday, April 16, 2012 5:40 AM
>> > To: IBM-MAIN@bama.ua.edu
>> > Subject: SV: GO TO "cobol"
>> >
>> > An alternative is to have e g an 88-type LEAVE item that is
>> > checked for every code-block including all iterations and selections.
>> > (You set leave to true when wanting to do a "leave" type jump.)
>> >
>> >
>> >
>> > Regards,
>> > Thomas Berg
>> > __
>> > Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
>> >
>> >
>> >
>> > > -Ursprungligt meddelande-
>> > > Från: IBM Mainframe Discussion List
>> > [mailto:IBM-MAIN@bama.ua.edu] För
>> > > Edward Jaffe
>> > > Skickat: den 16 april 2012 08:15
>> > > Till: IBM-MAIN@bama.ua.edu
>> > > Ämne: Re: GO TO "cobol"
>> > >
>> > > On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:
>> > > > For devotees of Jackson Structured programming, the GOTO
>> > is a must for
>> > > > POSIT and ADMIT processing. Otherwise it can be messy
>> > avoiding a GOTO.
>> > >
>> > > The problem with GOTO is that the suitability of the target branch
>> > > location is
>> > > not enforced by the compiler according to any structured discipline.
>> > >
>> > > Premature terminations (posit/quit/admit) can almost always
>> > be handled
>> > > with
>> > > LEAVE-type statements or immediate return from a 

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 13:46:08 -0700, in bit.listserv.ibm-main you wrote:

>IBM Mainframe Discussion List  wrote on 04/16/2012 
>10:57:47 AM:
>
>> From: Binyamin Dissen 
>
>> The elimination of GOTOs was to save people time at the cost of CPU 
>time.
>
>?
>
>> Obviously, if a procedure was called from several points ALTER GOTO 
>would
>> generate fewer instructions than perform.
>
>The last time I looked at a PMAP, the Cobol compiler implements PERFORM 
>exactly like an ALTERed GO TO, except that all addresses are stored in a 
>table.

Take a look at the optimized code where paragraphs can only be reached
by PERFORM.  In many cases the code for a PERFORM is actually the code
for the paragraph being PERFORMED.  

Clark Morris
>
>> But with GOTOless programming the logic is easier to read. There is no
>> question about how you got somewhere.
>
> agreed
>
>-
>The information contained in this communication (including any
>attachments hereto) is confidential and is intended solely for the
>personal and confidential use of the individual or entity to whom
>it is addressed. If the reader of this message is not the intended
>recipient or an agent responsible for delivering it to the intended
>recipient, you are hereby notified that you have received this
>communication in error and that any review, dissemination, copying,
>or unauthorized use of this information, or the taking of any
>action in reliance on the contents of this information is strictly
>prohibited. If you have received this communication in error,
>please notify us immediately by e-mail, and delete the original
>message. Thank you 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 07:35:00 -0700, in bit.listserv.ibm-main you wrote:

>This topic I cannot resist...  Uggg...
>
>Having learned COBOL in the mid 70's, the instructor taught that PERFORM was 
>to be used only in situations where you wanted
>to do a certain routine at several locations in the program.  The teaching was 
>also about "straight line" programming.  Flow 
>Charts were also part of the curriculum.
>
>Having said that, I still use GO TO extensively, and have not kept up with the 
>"modern" programming extensions and constructs.
>I've had many instances in my career where a "structured" program has been 
>"straight lined" with extremely dramatic performance
>results.  Mostly I believe that knowing Assembler language and how the COBOL 
>compiler would generate the assembler code version
>of the program provided the reasons for my coding techniques.  I would write 
>the program as close to what the assembler code
>would be as possible.  This would usually provide some great performance at 
>run time (and at compile time).
>
>One example (out of several) was a program which normally took 4-6 hours to do 
>its magic.  When I re-wrote it due to the necessity
>of adding more functionality, I went ahead and "straight lined" it according 
>to the logic of what the program was supposed to do.
>When the re-write was finished, the new program took 20 minutes to run the 
>first time it was in production.  I have several other
>examples with these type of results.

What compiler were you working with?  What other changes did you make?
COBOL VS (the 1974 standard) had poor code generation for PERFORM and
PERFORM ... UNTIL was especially poor.  VS COBOL II V1R4 drastically
changed that with simplified linkage where paragraphs could only be
reached by PERFORM and in many cases PERFORMED paragraphs were moved
inline to eliminate the branching.  The compiler could detect where a
one byte field was initialized and never changed so it could use
immediate instructions (MVI, CLI) when the field was used in a MOVE or
COMPARE.  Making sure all sequential files had BLOCK 0 coded also did
wonders.

Clark Morris
>
>Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a perform. 
> Went to the Well in the early-mid 80's over that 
>one with a bunch of certain "whiz-kids" who were trained under the good 
>doctors premises.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Mike Schwab]

On Tue, Apr 17, 2012 at 5:21 PM, Shmuel Metz (Seymour J.)
> Listen to "Every OS Sucks" by 3 Dead Trolls in a Baggie.
>
> --
>     Shmuel (Seymour J.) Metz, SysProg and JOAT

Animated version.
http://www.youtube.com/watch?v=hg0iRd4i0qk
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In , on 04/16/2012
   at 05:57 PM, Binyamin Dissen  said:

>But with GOTOless programming the logic is easier to read.

Except when it's harder. The real issue is structuring the code so
that it's easier to read and maintain, not blindly following  a
theological dictum. If that requires more goto statements then I'll
cheerfully use them. Read "Structured Programming Using goto" (I'm not
sure of the spelling.)
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In
,
on 04/16/2012
   at 09:32 PM, Mike Schwab  said:

>TLA for ARMY Private FIrst Class.

Give me back my Air Force. I believe that the Marines also have the
rank.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on
04/16/2012
   at 12:01 PM, "Staller, Allan"  said:

>BTW, I agree w/Dykstra. Maintaining a structured program is far
>easier than spaghetti code. 

False dichotomy. You can have spaghetti code without goto and you can
use goto judiciously without writing spaghetti code. You have to carve
the bird at the joints.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <4809508338399138.wa.paulgboulderaim@bama.ua.edu>, on
04/16/2012
   at 08:10 AM, Paul Gilmartin  said:

>Rexx is a nightmare here.

No. The signal statement in Rexx is not a go to. What is a nightmare
is using a hammer as a screwdriver. Not that Rexx doesn't have issues,
but what language doesn't?

Listen to "Every OS Sucks" by 3 Dead Trolls in a Baggie.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In <1334665025.13456.yahoomai...@web180919.mail.ne1.yahoo.com>, on
04/17/2012
   at 05:17 AM, Lloyd Fuller  said:

>In 1969, and until sometime in the 1970s or later, the Army
>programming school  was at Fort Benjamin Harrison in Indiana.

Uncle Bennie's Rest Home. Indianapolis has a reputation as unfriendly,
but it was the only one of the three[2] training facilities I went
through where the local civilians treated us decently.

[2] The other two were Gordon and Jackson.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Shmuel Metz (Seymour J.)]

In ,
on 04/16/2012
   at 08:34 AM, "McKown, John"  said:

>Also remember that COBOL, at least originally, was supposed to be
>very English-like

Not to native Anglophones :-(
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

When I went in 1969, we used a 1401 with 4 tape drives.  We were taught COBOL 
but could not compile:  the COBOL compiler for the 1401 needed either disk or 
at 
least 6 tape drives.  


We also learned to "program" PCM and two Univac SAAL computers that were in use 
by the Army at the time.

Lloyd



- Original Message 
From: Ed Finnell 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 2:38:44 PM
Subject: Re: GO TO "cobol"

I didn't get there 'til '76. They had a CDC 3300 as the main record keeper  
with somebody's MassStor and several ancillary processors. I didn't notice 
the  unit record equipment just the sound of a drum bouncing around in the 
bottom of  the cage. The programming course was taught on DOS under VM(Lt. 
Farmer  participated in SHARE).


In a message dated 4/17/2012 9:27:22 A.M. Central Daylight Time,  
leful...@sbcglobal.net writes:

Army  Finance Center there.  I think that they used  Unisys.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Ed Finnell]

I didn't get there 'til '76. They had a CDC 3300 as the main record keeper  
with somebody's MassStor and several ancillary processors. I didn't notice 
the  unit record equipment just the sound of a drum bouncing around in the 
bottom of  the cage. The programming course was taught on DOS under VM(Lt. 
Farmer  participated in SHARE).
 
 
In a message dated 4/17/2012 9:27:22 A.M. Central Daylight Time,  
leful...@sbcglobal.net writes:

Army  Finance Center there.  I think that they used  Unisys.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Scott Ford]

Yes sir, for many years, large systems CE ...


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 10:07 AM, Lloyd Fuller  wrote:

> Probably at the Army Finance Center there.  I think that they used Unisys.
> 
> Lloyd
> 
> 
> 
> - Original Message 
> From: Scott Ford 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 9:36:59 AM
> Subject: Re: GO TO "cobol"
> 
> Lloyd,
> 
> My father was a Unisys CE at the Fort for many years...
> 
> 
> Scott Ford
> Senior Systems Engineer
> www.identityforge.com
> 
> 
> 
> On Apr 17, 2012, at 8:17 AM, Lloyd Fuller  wrote:
> 
>> In 1969, and until sometime in the 1970s or later, the Army programming 
>> school 
> 
>> was at Fort Benjamin Harrison in Indiana.
>> 
>> 
>> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
>> since then.
>> 
>> lLOYD
>> 
>> 
>> 
>> - Original Message 
>> From: Ed Gould 
>> To: IBM-MAIN@bama.ua.edu
>> Sent: Tue, April 17, 2012 12:16:33 AM
>> Subject: Re: GO TO "cobol"
>> 
>> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>>> SNIP-
>>> Also remember that COBOL, at least originally, was supposed to be very 
>>> English-like and so usable by people at the Army PFC level of training.
>>> 
>>> --John McKown
>>> Systems Engineer IV
>>> IT
>> 
>> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
>> its 
>> 
>> been 40 years so forgive me). We had two groups, one COBOL (batch 
>> processing) 
>> and one ASM group (essentially sysprogs). The ASM group was by far the best 
>> IMO. 
>> 
>> I was on call quite often and had to "fix" the cobol programs that went boom 
>> in 
>> 
>> the middle of the night. The COBOL people were semi useless in debugging and 
>> when I looked at the code they had produced (except for a few people) it was 
>> hopeless to understand. I spent more time trying to figure out the logic and 
>> compare what I was seeing in the dump. 1/3 the time I helped the programmer 
>> figure out where his problem was and supplying answers to his questions on 
>> what 
>> 
>> was in this field or that field.
>> What was interesting was that as the guys (no female programmers so don't 
>> call 
> 
>> me sexist blame the Army not me) as they became more experienced the code 
>> became 
>> 
>> easier to follow. As they became became better programmers there were less 
>> logic 
>> 
>> problems. Now having said that most of the programs were  smallish and only 
>> a 
>> few were considered large so the smallish programs there was no excuse for 
>> logic 
>> 
>> issues or mangled code. My memory is foggy here as to goto's but I think the 
>> "rule" no standards if memory serves me that goto's were to be minimized as 
>> a 
>> result flow was easier to follow and frankly debugging was easier.
>> 
>> Ed
>> 
>> ps: We had one person who at the time he was drafted was working for IBM and 
>> he 
>> 
>> privately told me about some OS enhancements that when I first heard I 
>> couldn't 
>> 
>> wrap my head around as virtual (at least that I had never heard of) was a 
>> nightmare that I couldn't wrap my head around. After I got out of the Army 
>> (2 
>> years) IBM announced Virtual and I was able to ask some semi intelligent 
>> questions as my "preview" and the questions helped jump start by job.
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

Probably at the Army Finance Center there.  I think that they used Unisys.

Lloyd



- Original Message 
From: Scott Ford 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 9:36:59 AM
Subject: Re: GO TO "cobol"

Lloyd,

My father was a Unisys CE at the Fort for many years...


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 8:17 AM, Lloyd Fuller  wrote:

> In 1969, and until sometime in the 1970s or later, the Army programming 
> school 

> was at Fort Benjamin Harrison in Indiana.
> 
> 
> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
> since then.
> 
> lLOYD
> 
> 
> 
> - Original Message 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 12:16:33 AM
> Subject: Re: GO TO "cobol"
> 
> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>> SNIP-
>> Also remember that COBOL, at least originally, was supposed to be very 
>> English-like and so usable by people at the Army PFC level of training.
>> 
>> --John McKown
>> Systems Engineer IV
>> IT
> 
> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
> its 
>
> been 40 years so forgive me). We had two groups, one COBOL (batch processing) 
> and one ASM group (essentially sysprogs). The ASM group was by far the best 
>IMO. 
>
> I was on call quite often and had to "fix" the cobol programs that went boom 
> in 
>
> the middle of the night. The COBOL people were semi useless in debugging and 
> when I looked at the code they had produced (except for a few people) it was 
> hopeless to understand. I spent more time trying to figure out the logic and 
> compare what I was seeing in the dump. 1/3 the time I helped the programmer 
> figure out where his problem was and supplying answers to his questions on 
> what 
>
> was in this field or that field.
> What was interesting was that as the guys (no female programmers so don't 
> call 

> me sexist blame the Army not me) as they became more experienced the code 
>became 
>
> easier to follow. As they became became better programmers there were less 
>logic 
>
> problems. Now having said that most of the programs were  smallish and only a 
> few were considered large so the smallish programs there was no excuse for 
>logic 
>
> issues or mangled code. My memory is foggy here as to goto's but I think the 
> "rule" no standards if memory serves me that goto's were to be minimized as a 
> result flow was easier to follow and frankly debugging was easier.
> 
> Ed
> 
> ps: We had one person who at the time he was drafted was working for IBM and 
> he 
>
> privately told me about some OS enhancements that when I first heard I 
> couldn't 
>
> wrap my head around as virtual (at least that I had never heard of) was a 
> nightmare that I couldn't wrap my head around. After I got out of the Army (2 
> years) IBM announced Virtual and I was able to ask some semi intelligent 
> questions as my "preview" and the questions helped jump start by job.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Scott Ford]

Lloyd,

My father was a Unisys CE at the Fort for many years...


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 8:17 AM, Lloyd Fuller  wrote:

> In 1969, and until sometime in the 1970s or later, the Army programming 
> school 
> was at Fort Benjamin Harrison in Indiana.
> 
> 
> Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
> since then.
> 
> lLOYD
> 
> 
> 
> - Original Message 
> From: Ed Gould 
> To: IBM-MAIN@bama.ua.edu
> Sent: Tue, April 17, 2012 12:16:33 AM
> Subject: Re: GO TO "cobol"
> 
> On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
>> SNIP-
>> Also remember that COBOL, at least originally, was supposed to be very 
>> English-like and so usable by people at the Army PFC level of training.
>> 
>> --John McKown
>> Systems Engineer IV
>> IT
> 
> Hmmm... I was in the Army and we got PFC's from the programming school (AZ? 
> its 
> been 40 years so forgive me). We had two groups, one COBOL (batch processing) 
> and one ASM group (essentially sysprogs). The ASM group was by far the best 
> IMO. 
> I was on call quite often and had to "fix" the cobol programs that went boom 
> in 
> the middle of the night. The COBOL people were semi useless in debugging and 
> when I looked at the code they had produced (except for a few people) it was 
> hopeless to understand. I spent more time trying to figure out the logic and 
> compare what I was seeing in the dump. 1/3 the time I helped the programmer 
> figure out where his problem was and supplying answers to his questions on 
> what 
> was in this field or that field.
> What was interesting was that as the guys (no female programmers so don't 
> call 
> me sexist blame the Army not me) as they became more experienced the code 
> became 
> easier to follow. As they became became better programmers there were less 
> logic 
> problems. Now having said that most of the programs were  smallish and only a 
> few were considered large so the smallish programs there was no excuse for 
> logic 
> issues or mangled code. My memory is foggy here as to goto's but I think the 
> "rule" no standards if memory serves me that goto's were to be minimized as a 
> result flow was easier to follow and frankly debugging was easier.
> 
> Ed
> 
> ps: We had one person who at the time he was drafted was working for IBM and 
> he 
> privately told me about some OS enhancements that when I first heard I 
> couldn't 
> wrap my head around as virtual (at least that I had never heard of) was a 
> nightmare that I couldn't wrap my head around. After I got out of the Army (2 
> years) IBM announced Virtual and I was able to ask some semi intelligent 
> questions as my "preview" and the questions helped jump start by job.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Scott Ford]

Whatever happened to everyone talking about structured COBOL code.
I usually perform paragraph- name thru paragraph- name exit. I but agree flow 
logic in COBOL need revision. Especially, when you in the middle of the 
perform. Using 'continue' to good, but sometimes deadlines force you to write 
not the way you want too


Scott Ford
Senior Systems Engineer
www.identityforge.com



On Apr 17, 2012, at 9:12 AM, Jeff Holst  wrote:

> Without the GO TO, Grace Hopper might have been forever stuck in Japan.
> 
> Many years ago, I was at an ACM meeting where Grace Hopper was a speaker. One 
> of the stories she told was of a visit to a data center in Japan. Somehow, 
> she was left there without an interpretter. The folks at the data center 
> spoke no English and she spoke no Japanese. Fortunately, the programmers knew 
> COBOL. And while COBOL was designed so that the english commands could be 
> easily translated into other languages (in most languages, the verb in a 
> command is the first thing in the sentence), this is almost never done. Her 
> solution was simple. She poiinted at herself, then said GO TO and the name of 
> the hotel. This was enoungh so that the programmers were able to get her to 
> the hotel.
> 
> Jeff Holst 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Jeff Holst]

Without the GO TO, Grace Hopper might have been forever stuck in Japan.

Many years ago, I was at an ACM meeting where Grace Hopper was a speaker. One 
of the stories she told was of a visit to a data center in Japan. Somehow, she 
was left there without an interpretter. The folks at the data center spoke no 
English and she spoke no Japanese. Fortunately, the programmers knew COBOL. And 
while COBOL was designed so that the english commands could be easily 
translated into other languages (in most languages, the verb in a command is 
the first thing in the sentence), this is almost never done. Her solution was 
simple. She poiinted at herself, then said GO TO and the name of the hotel. 
This was enoungh so that the programmers were able to get her to the hotel.

Jeff Holst 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Patrick Roehl]

This is true, but I prefer to use the "end" constructs because they are
safer.  The safety comes from the compiler complaining about IF and END-Ifs
not matching.  An errant period generates no such indicator and causes a
bug.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Matthew Stitt
Sent: Monday, April 16, 2012 5:45 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: GO TO "cobol"

If some-test-here-failed
 Set indicator-switch to true
 Go to 2000-exit
 End-if.

 If some-other-test-fails
 Set indicator-different-switch to true
 Go to 2000-exit
 End-if.

---

You could have the exact same result by placing a period after the
"2000-exit".  Then the End-if is not needed.



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

In 1969, and until sometime in the 1970s or later, the Army programming school 
was at Fort Benjamin Harrison in Indiana.


Graduated in March 1969 as a Staff Sergeant converted to a SP6.  Programming 
since then.

lLOYD



- Original Message 
From: Ed Gould 
To: IBM-MAIN@bama.ua.edu
Sent: Tue, April 17, 2012 12:16:33 AM
Subject: Re: GO TO "cobol"

On Apr 16, 2012, at 8:34 AM, McKown, John wrote:
> SNIP-
> Also remember that COBOL, at least originally, was supposed to be very 
>English-like and so usable by people at the Army PFC level of training.
> 
> --John McKown
> Systems Engineer IV
> IT

Hmmm... I was in the Army and we got PFC's from the programming school (AZ? its 
been 40 years so forgive me). We had two groups, one COBOL (batch processing) 
and one ASM group (essentially sysprogs). The ASM group was by far the best 
IMO. 
I was on call quite often and had to "fix" the cobol programs that went boom in 
the middle of the night. The COBOL people were semi useless in debugging and 
when I looked at the code they had produced (except for a few people) it was 
hopeless to understand. I spent more time trying to figure out the logic and 
compare what I was seeing in the dump. 1/3 the time I helped the programmer 
figure out where his problem was and supplying answers to his questions on what 
was in this field or that field.
What was interesting was that as the guys (no female programmers so don't call 
me sexist blame the Army not me) as they became more experienced the code 
became 
easier to follow. As they became became better programmers there were less 
logic 
problems. Now having said that most of the programs were  smallish and only a 
few were considered large so the smallish programs there was no excuse for 
logic 
issues or mangled code. My memory is foggy here as to goto's but I think the 
"rule" no standards if memory serves me that goto's were to be minimized as a 
result flow was easier to follow and frankly debugging was easier.

Ed

ps: We had one person who at the time he was drafted was working for IBM and he 
privately told me about some OS enhancements that when I first heard I couldn't 
wrap my head around as virtual (at least that I had never heard of) was a 
nightmare that I couldn't wrap my head around. After I got out of the Army (2 
years) IBM announced Virtual and I was able to ask some semi intelligent 
questions as my "preview" and the questions helped jump start by job.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Lloyd Fuller]

PFC = Private First Class.  An Army rank.  The Marines may also use it.


Lloyd


- Original Message 
From: Paul Gilmartin 
To: IBM-MAIN@bama.ua.edu
Sent: Mon, April 16, 2012 7:27:30 PM
Subject: Re: GO TO "cobol"

On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
>
>You could have the exact same result by placing a period
>after the "2000-exit".  Then the End-if is not needed.
>
>
> 
I sure am glad that COBOL attained its design objective
of being intelligible (intuitively? unambiguously?) to a
PFC-level programmer with only an understanding of
vernacular English.

(Is "PFC" a Navy rank?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Only if you consider a Marine to be in the Navy (Technically, they are under 
the department of the Navy). But you'll do that only if you don't mind losing 
some teeth. 

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Monday, April 16, 2012 6:27 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
> >
> >You could have the exact same result by placing a period
> >after the "2000-exit".  Then the End-if is not needed.
> >
> >
> > 
> I sure am glad that COBOL attained its design objective
> of being intelligible (intuitively? unambiguously?) to a
> PFC-level programmer with only an understanding of
> vernacular English.
> 
> (Is "PFC" a Navy rank?)
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Ed Gould]

On Apr 16, 2012, at 8:34 AM, McKown, John wrote:

SNIP-
Also remember that COBOL, at least originally, was supposed to be  
very English-like and so usable by people at the Army PFC level of  
training.


--
John McKown
Systems Engineer IV
IT


Hmmm... I was in the Army and we got PFC's from the programming  
school (AZ? its been 40 years so forgive me). We had two groups, one  
COBOL (batch processing) and one ASM group (essentially sysprogs).  
The ASM group was by far the best IMO. I was on call quite often and  
had to "fix" the cobol programs that went boom in the middle of the  
night. The COBOL people were semi useless in debugging and when I  
looked at the code they had produced (except for a few people) it was  
hopeless to understand. I spent more time trying to figure out the  
logic and compare what I was seeing in the dump. 1/3 the time I  
helped the programmer figure out where his problem was and supplying  
answers to his questions on what was in this field or that field.
What was interesting was that as the guys (no female programmers so  
don't call me sexist blame the Army not me) as they became more  
experienced the code became easier to follow. As they became became  
better programmers there were less logic problems. Now having said  
that most of the programs were  smallish and only a few were  
considered large so the smallish programs there was no excuse for  
logic issues or mangled code. My memory is foggy here as to goto's  
but I think the "rule" no standards if memory serves me that goto's  
were to be minimized as a result flow was easier to follow and  
frankly debugging was easier.


Ed

ps: We had one person who at the time he was drafted was working for  
IBM and he privately told me about some OS enhancements that when I  
first heard I couldn't wrap my head around as virtual (at least that  
I had never heard of) was a nightmare that I couldn't wrap my head  
around. After I got out of the Army (2 years) IBM announced Virtual  
and I was able to ask some semi intelligent questions as my "preview"  
and the questions helped jump start by job.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Mike Schwab]

On Mon, Apr 16, 2012 at 6:26 PM, Paul Gilmartin >
> (Is "PFC" a Navy rank?)
>
> -- gil

TLA for ARMY Private FIrst Class.
http://usmilitary.about.com/od/theorderlyroom/l/blenlrank.htm

Navy equivalent is a TLA SN for Seaman.
Be sure not to drop the first A and replace the second A with an E.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Paul Gilmartin]

On Mon, 16 Apr 2012 16:45:21 -0500, Matthew Stitt wrote:
>
>You could have the exact same result by placing a period
>after the "2000-exit".  Then the End-if is not needed.
>
>
> 
I sure am glad that COBOL attained its design objective
of being intelligible (intuitively? unambiguously?) to a
PFC-level programmer with only an understanding of
vernacular English.

(Is "PFC" a Navy rank?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Matthew Stitt]

If some-test-here-failed
 Set indicator-switch to true
 Go to 2000-exit
 End-if.

 If some-other-test-fails
 Set indicator-different-switch to true
 Go to 2000-exit
 End-if.

---

You could have the exact same result by placing a period
after the "2000-exit".  Then the End-if is not needed.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Impossible in my example case. The NEXT SENTENCE is used like an EXIT PARAGRAPH 
verb because the entire paragraph is a single sentence. This is needed to 
remove the requirement for a GOTO to a "name-EXIT." paragraph. It was to 
highlight how awkard the COBOL code becomes if the GOTO is totally eliminated. 
The awkardness is only slightly reduced if people use the END-verb, which I 
highly recommend for all verbs which have it. It specifically delimits the 
scope of the verb. Much like I alway use braces ( {} ) if when not absolutely 
necessary.

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Matthew Stitt
> Sent: Monday, April 16, 2012 4:29 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> Use of NEXT SENTENCE is as dangerous as GO TO.  Try using CONTINUE.
> 
> The former takes you to the next period;  the latter takes 
> you to the end 
> of the current conditional.  One missed period and 
> 
> --
> 
> I've seen many programs without a single period.  How they 
> work is beyond
> my comprehension.  Of course, a paragraph name does imply a period.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Matthew Stitt]

Use of NEXT SENTENCE is as dangerous as GO TO.  Try using CONTINUE.

The former takes you to the next period;  the latter takes you to the end 
of the current conditional.  One missed period and 

--

I've seen many programs without a single period.  How they work is beyond
my comprehension.  Of course, a paragraph name does imply a period.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Patrick Roehl]

I have many years' experience writing COBOL code and have used GO TO and
THRU only as a means of exiting a paragraph.  I frequently code paragraph
subroutines that perform a series of related edits, and would use them like
this:

 Perform 2000-Validate-Input thru 2000-exit.
*test resultant switch settings here... 


 2000-Validate-Input.

 If some-test-here-failed
 Set indicator-switch to true
 Go to 2000-exit
 End-if.

 If some-other-test-fails
 Set indicator-different-switch to true
 Go to 2000-exit
 End-if.

* Blah, blah, blah

* When you get here, all tests are good and action can be taken

 2000-exit.
 Exit.


The THRU clause is only to support an "exit paragraph" ability.  Because I
follow some rules with this technique, it has never caused me a problem.
The rules?  They are simple:

- Only "go to" the exit point for the current paragraph.  I never span.
This means that the "go to" statements are always pointed downward - the
same way my perform statements always point.

- I verify that this rule is observed by F GO WORD in ISPF (with comments
excluded).  Each time I find a GO, I then look for P'-' 8 to ensure that
the exit paragraph is the next paragraph.

I, too, believe that "thru" and "section" is a preference that can't be
persuaded in most people.  I personally hate to use sections and view them
as evil.  When forced to use sections, such as when performing an internal
sort, I just code unreferenced "dummy" sections around my input and output
sections.

It would be nice if an "exit paragraph" statement existed.  When it does,
I'll never need a THRU or GO TO again - and good riddance!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Coding standards here are ancient. There is the "all out-of-line PERFORMs must 
be of the form PERFORM name THRU name-EXIT ... END-PERFORM and all paragraphs 
must be followed by be followed by a "name-EXIT." paragraph with the single 
EXIT verb in it. Or at least, that is how every out-of-line PERFORM verbs are 
coded. Ancient, like most of our code. If code is updated, it is not 
modernized. 

John McKown 

Systems Engineer IV

IT

 

Administrative Services Group

 

HealthMarkets(r)

 

9151 Boulevard 26 * N. Richland Hills * TX 76010

(817) 255-3225 phone * 

john.mck...@healthmarkets.com * www.HealthMarkets.com

 

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Talman
> Sent: Monday, April 16, 2012 3:33 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> IBM Cobol provides the structure format:
> 
> I-P.
> READ FILE
> AT END
> * the at end stuff
> NOT AT END
> * the not at end stuff
> END-READ
> 
> IBM Mainframe Discussion List  wrote on 
> 04/16/2012 
> 08:28:10 AM:
> 
> > From: "McKown, John" 
> > 
> >PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
> > 
> > I-P.
> > READ FILE AT END
> >  SET CONDITION TO TRUE
> >  GO TO I-P-EXIT
> > END-READ
> > ...
> > I-P-EXIT.
> > EXIT.
> 
> 
> -
> The information contained in this communication (including any
> attachments hereto) is confidential and is intended solely for the
> personal and confidential use of the individual or entity to whom
> it is addressed. If the reader of this message is not the intended
> recipient or an agent responsible for delivering it to the intended
> recipient, you are hereby notified that you have received this
> communication in error and that any review, dissemination, copying,
> or unauthorized use of this information, or the taking of any
> action in reliance on the contents of this information is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by e-mail, and delete the original
> message. Thank you 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Kirk Talman]

IBM Mainframe Discussion List  wrote on 04/16/2012 
01:59:26 PM:

> From: "Gibney, Dave" 

> A dirty myth about COBOL is the belief the THRU is required and that
> SECTIONs are a good idea. Unless specifically required by SORT or 
> something, I never used either. It has been 20+ years since I did 
> much COBOL. Haven't had the pleasure of the newer constructs.

THROUGH is just stupid.  But I have used sections.  I think of it as a 
religious preference.

> As to the OP's belief about performance, structured programming has 
> never been about performance, it is about understandability.

yes

and maintainability

-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Kirk Talman]

IBM Mainframe Discussion List  wrote on 04/16/2012 
10:57:47 AM:

> From: Binyamin Dissen 

> The elimination of GOTOs was to save people time at the cost of CPU 
time.

?

> Obviously, if a procedure was called from several points ALTER GOTO 
would
> generate fewer instructions than perform.

The last time I looked at a PMAP, the Cobol compiler implements PERFORM 
exactly like an ALTERed GO TO, except that all addresses are stored in a 
table.

> But with GOTOless programming the logic is easier to read. There is no
> question about how you got somewhere.

 agreed

-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Kirk Talman]

Well said

IBM Mainframe Discussion List  wrote on 04/16/2012 
12:00:13 AM:

> From: Sam Siegel 
> 
> Typically GO TO statements can be avoided by having a good design.  A 
local
> GO TO here and there is not so bad.  The non-local GO TO statements can
> make long-term maintenance of a program problematic and expensive.


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Kirk Talman]

Use of NEXT SENTENCE is as dangerous as GO TO.  Try using CONTINUE.

The former takes you to the next period;  the latter takes you to the end 
of the current conditional.  One missed period and 

To replace nested IFs, try using EVALUATE - the most powerful case 
statement in any language (except structured assembler) according to a 
friend who does distributed apps.

IBM Mainframe Discussion List  wrote on 04/16/2012 
08:42:05 AM:

> From: "McKown, John" 
> To: IBM-MAIN@bama.ua.edu, 
> Date: 04/16/2012 08:46 AM
> Subject: Re: GO TO "cobol"
> Sent by: IBM Mainframe Discussion List 
> 
> What??? "monopolizes the CPU"??? GO TO was made a pariah by an 
> article by Edgar Dijkstra.
> 
> http://en.wikipedia.org/wiki/Considered_harmful
> 
> And, of course, management went stupid (again) and came up with "you
> cannot use the GOTO in any code at all". Which actually makes 
> some COBOL more complicated due to the requirement of nesting IF 
> statements within IF statements. And before the END-IF, that could 
> be very complicated. I've see old code like:
> 
> IF ... THEN
> ...
>IF ... THEN
>...
>ELSE
>NEXT SENTENCE
>...
>IF ... THEN
>...
>   IF ... THEN
>   ...
>   ELSE
>   NEXT SENTENCE 
>ELSE
>...
> .
> 
> Each internal IF had to have a corresponding ELSE with only NEXT 
> SENTENCE in it.
> 
> -- 
> John McKown 
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone * 
> john.mck...@healthmarkets.com * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential
> or proprietary information. If you are not the intended recipient, 
> please contact the sender by reply e-mail and destroy all copies of 
> the original message. HealthMarkets(r) is the brand name for 
> products underwritten and issued by the insurance subsidiaries of 
> HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-
> West National Life Insurance Company of TennesseeSM and The MEGA 
> Life and Health Insurance Company.SM
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson
> > Sent: Sunday, April 15, 2012 10:49 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: GO TO "cobol"
> > 
> > Hi All,
> > 
> > Apology for asking a basic question and Being Ignorant. We 
> > know that GO TO
> > statments are a big "NO" in many production sites and one of 
> > the reason
> > being it monopolizes the entire CPU. Are there any 
> > documentation explaining
> > about the  GO TO statements  which clearly describes how it 
> > effects the
> > System CPU and performances ?
> > 
> > Apology again if the question is not really sensible or else 
> > it requires
> > more information.
> > 
> > Jake
> > 
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> > 
> > 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Kirk Talman]

IBM Cobol provides the structure format:

I-P.
READ FILE
AT END
* the at end stuff
NOT AT END
* the not at end stuff
END-READ

IBM Mainframe Discussion List  wrote on 04/16/2012 
08:28:10 AM:

> From: "McKown, John" 
> 
>PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
> 
> I-P.
> READ FILE AT END
>  SET CONDITION TO TRUE
>  GO TO I-P-EXIT
> END-READ
> ...
> I-P-EXIT.
> EXIT.


-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On 16 Apr 2012 05:45:21 -0700, in bit.listserv.ibm-main you wrote:

>What??? "monopolizes the CPU"??? GO TO was made a pariah by an article by 
>Edgar Dijkstra.
>
>http://en.wikipedia.org/wiki/Considered_harmful
>
>And, of course, management went stupid (again) and came up with "you cannot 
>use the GOTO in any code at all". Which actually makes some COBOL more 
>complicated due to the requirement of nesting IF statements within IF 
>statements. And before the END-IF, that could be very complicated. I've see 
>old code like:
>
>IF ... THEN
>...
>   IF ... THEN
>   ...
>   ELSE
>   NEXT SENTENCE
>   ...
>   IF ... THEN
>   ...
>  IF ... THEN
>  ...
>  ELSE
>  NEXT SENTENCE 
>   ELSE
>   ...
>.
>
>Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in 
>it.

You are thinking of the 1974 standard which doesn't have IF  ...
END-IF.  Nesting becomes easier with the 1985 standard and when the IF
statement nesting becomes too complex you can move an IF ... END-IF
pair into a separate paragraph with little or no performance penalty
due to code movement and the simplified PERFORM code if you eliminate
GO TO statements.

Clark Morris 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Clark Morris]

On Tue, 17 Apr 2012 02:06:31 +1200, in bit.listserv.ibm-main Peter
Dashwood wrote:

I'll put most of my comments at the end and have included the postings
by Nomen Nescio and Peter Dashwood of New Zealand so that they go to
the listserv as well as the newsgroup.  Peter has been in the field
for many years and has mainframe experience including CICS.  I
disagree with him in some areas but he is an expert in COBOL so this
is a disagreement among those who know data processing and not one
where people are quoting airline magazines.  My comments apply mainly
to IBM z series COBOL because that is the one I know most and the only
one in current production that I have seen the code generation for
since the RCA 301 bit the dust decades ago.

See below

>Nomen Nescio wrote:
>> justmainfra...@gmail.com (Jake anderson) wrote:
>>
>>> Hi All,
>>>
>>> Apology for asking a basic question and Being Ignorant. We know that
>>> GO TO statments are a big "NO" in many production sites and one of
>>> the reason being it monopolizes the entire CPU.
>>
>> Nothing you can do from a COBOL program can monopolize the CPU or
>> even the OS in the z/OS environment.
>>
>>> Are there any documentation explaining about the  GO TO statements 
>>> which clearly describes how it  effects the System CPU and
>>> performances ?
>>
>> Avoiding GO TO is a religious belief and it is wrong. It is not
>> rooted in performance or other real considerations. GO TO is often
>> the best way to code in COBOL. You should not write C like a COBOL
>> programmer but you should also not write COBOL like a C programmer.
>> People should code idiomatically and not try to make everything look
>> like Pascal, C, etc. And let's be honest, by the time your program is
>> compiled all those structured verbs are really nothing more than
>> piles of GO TOs, usually 4 times as many as you would have generated
>> if you simply coded GO TO in the first place because of the extra
>> loops you have to code to be able to say you avoided GO TO.
>>
>> Blind obesance to Dijkstra's idiotic structured programming tenets
>> will get you nowhere in the real world except long wall clock times.
>> Do you really want to code according to the principles of a guy who
>> never delivered anything in his life but reams of paper and diatribes
>> about things he wasn't even involved in? He and his pals did more
>> damage to commercial programming than any other single thing I can
>> think of, maybe with the exception of the H1B program.
>>
>> The alternative to GO TO in COBOL is PERFORM which is much more
>> costly than GO TO and most often contributes to poor program design
>> by making everything a loop. Yes, most commercial processing is a big
>> loop, but it is not necessarily concentric circles of loops.
>> Structured programming assumes everything is algorithmic and consists
>> of concentric loops. This is simply not a valid assumption for
>> commercial COBOL code. Use the LIST option and compare the object
>> code from a small sample program you write in two different ways, one
>> using GO TO sensibly and one using PERFORM and avoiding GO TO
>> entirely. Consider how much overhead those extra 5 instructions will
>> make in a 5 or 10 million record batch run. Then consider how many
>> more loops you had to code to do things you should have handled with
>> GO TO like checking return codes from called routines, VSAM file
>> status, etc. A good program is a good program and branching is part
>> of life. If you can't write good COBOL with GO TO and PERFORM (very
>> sparingly) then yes, you should focus on academic arguments and FUD
>> to cover up the fact you have no idea what the compiler or OS are
>> doing (see your opening question).
>>
>> If being a mindless lemming or meme is considered a virtue where you
>> work and it wouldn't be the first place that was true, by all means
>> avoid GO
>> TO. It is often much safer to do the wrong thing that is now a
>> standard than to do the right thing that isn't popular with the
>> know-nothing generation.
>
>I really enjoyed this and it made me smile.
>
>Very well written.
>
>It made me remember (and God knows, I've been trying to forget it for many 
>years now... :-)) a seminar in London I attended where Michael Jackson (he 
>of "Jackson Structured Programming" fame, sadly, not the pop star (which 
>would have been much more entertaining and probably cost less...)) 
>vehemently evangelized the power of GOTO-less programming. The only trouble 
>was that anyone who looked at the tangled mess generated by his system would 
>simply be bewildered by it. I raised this point with him and he said it 
>didn't matter because that was generated code and nobody would be 
>maintaining it. Draw your own conclusions. (I can tell you that the code 
>generated from my own generators is not a tangled mess and, while it is 
>complex in places, I'm not ashamed to show it to people...AND, they CAN 
>alter it if they want to (although I don't recommend that))
>
>GO T

Re: GO TO "cobol"

[Tony Harminc]

On 16 April 2012 13:35, John Gilmore  wrote:
[...]
> I even object, but not much, to
>
> |.trvend   anop   ,
>
> I supply the missing-operand comma for anop, mexit, etc., only when I
> want to place a comment after it.

I've found that the risk of later copying (by me or someone else) of
such a code segment, and then putting in update markers toward the
right of the input field - typically in the mid to high 60s column
positions - makes it worth while to always put in the comma.

There are a very few IBM macros, but to my knowledge no assembler
statements, that have trouble with this, and they must be handled
individually.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Gerhard Postpischil]

On 4/16/2012 1:35 PM, John Gilmore wrote:

I even object, but not much, to

|.trvend   anop   ,

I supply the missing-operand comma for anop, mexit, etc., only when I
want to place a comment after it.

These, however, are details that are important only as they contribute
to coherence.


The comma is a result of a personal(?) idiosyncrasy. Since the 
late sixties, I have used columns 65-71 to indicate code changes 
(author,date); this practice permits detailed identification of 
modifications that may not be as obvious when provided as 
paragraph or program comments. Omitting the comma results in 
assembly errors.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Gibney, Dave]

A dirty myth about COBOL is the belief the THRU is required and that SECTIONs 
are a good idea. Unless specifically required by SORT or something, I never 
used either. It has been 20+ years since I did much COBOL. Haven't had the 
pleasure of the newer constructs.

As to the OP's belief about performance, structured programming has never been 
about performance, it is about understandability.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of McKown, John
> Sent: Monday, April 16, 2012 5:28 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> Our use of GO TO is generally restricted to usage such as:
> 
>PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
> 
> I-P.
> READ FILE AT END
>  SET CONDITION TO TRUE
>  GO TO I-P-EXIT
> END-READ
> ...
> I-P-EXIT.
> EXIT.
> 
> Otherwise, to avoid the GO TO, we'd need to do:
> 
> I-P.
> READ FILE AT END
>  SET CONDITION TO TRUE
> END-READ
> IF NOT CONDITION THEN
> ...
> END-IF.
> I-P-EXIT.
> EXIT.
> 
> Which I consider to be worse than the exit, so far as comprehension is
> concerned.
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone .
> john.mck...@healthmarkets.com . www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please contact
> the sender by reply e-mail and destroy all copies of the original message.
> HealthMarkets® is the brand name for products underwritten and issued by
> the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life
> Insurance Company®, Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
> 
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
> > Sent: Monday, April 16, 2012 5:40 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: SV: GO TO "cobol"
> >
> > An alternative is to have e g an 88-type LEAVE item that is
> > checked for every code-block including all iterations and selections.
> > (You set leave to true when wanting to do a "leave" type jump.)
> >
> >
> >
> > Regards,
> > Thomas Berg
> > ______________
> > Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
> >
> >
> >
> > > -Ursprungligt meddelande-
> > > Från: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] För
> > > Edward Jaffe
> > > Skickat: den 16 april 2012 08:15
> > > Till: IBM-MAIN@bama.ua.edu
> > > Ämne: Re: GO TO "cobol"
> > >
> > > On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:
> > > > For devotees of Jackson Structured programming, the GOTO
> > is a must for
> > > > POSIT and ADMIT processing. Otherwise it can be messy
> > avoiding a GOTO.
> > >
> > > The problem with GOTO is that the suitability of the target branch
> > > location is
> > > not enforced by the compiler according to any structured discipline.
> > >
> > > Premature terminations (posit/quit/admit) can almost always
> > be handled
> > > with
> > > LEAVE-type statements or immediate return from a subroutine. Some
> > > languages have
> > > SIGNAL, EXIT, etc. which can help provide structured premature
> > > termination for
> > > larger routines without resorting to the dreaded GOTO.
> > >
> > > --
> > > Edward E Jaffe
> > > Phoenix Software International, Inc
> > > 831 Parkview Drive North
> > > El Segundo, CA 90245
> > > 310-338-0400 x318
> > > edja...@phoenixsoftware.com
> > > http://www.phoenixsoftware.com/
> > >
> > >
> > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[John Gilmore]

I agree that there is more than one good way to do everything.
Gerhard's code is fine.  For a loop where it is invariant, I should
prefer to save and reuse n'&array; and I prefer the boolean assignment
statement and AIF

|&elements_exhausted setb (&i gt &ne)
| aif (&elements_exhausted).traversal_lend

to his single statement.

I even object, but not much, to

|.trvend   anop   ,

I supply the missing-operand comma for anop, mexit, etc., only when I
want to place a comment after it.

These, however, are details that are important only as they contribute
to coherence.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[John Gilmore]

If we're going to talk about these issues it will be useful to avoid
carelessness.

There may well be or have been an Edgar Dijkstra, but if so he has
been silent about GOTOs.

The Dijkstra of interest here was Edsger W. Dijkstra (1930-2002).

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Gerhard Postpischil]

On 4/16/2012 12:26 PM, John Gilmore wrote:

Suppose that I wish to do something to each of the elements of an
assembly-time array in turn.  In the macro language of the HLASM I
must write something like

|&ne   seta   n'&array
|&i  seta   0
|.traverse_loop anop
|&i  seta&i+1
|&elements_exhausted setb (&i gt&ne)
| aif   (&elements_exhausted).traverse_lend
|  .  .  .

"Must" you?   In this case I would prefer:

.* &i   seta0   *default*
.trvloop aif(&i ge n'&array).trvend
&i  seta&i+1
.  .  .
ago .trvloop
.trvend anop,

That's six statements instead of nine. I was raised in the era 
of six (ForTran) and eight character variables, and find those 
easier to read. I'd use &ne only for larger array sizes; for 
small ones the savings are not noticeable.


Whether or not code is aesthetically pleasing is very much a 
matter of nurture. With effective comments, the structure of 
code isn't all that critical, and discussions of GOTO versus 
GOTO-less programming are about as useful as religious arguments.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Staller, Allan]

The branch execution logic in modern (s/360 or newer. YES s/360 circa
1963) are among the most efficient in the processor. That still has not
changed.
Forget anyone ever told you that GO TO increases CPU overhead.


.. GO TO was made a pariah by an article by Edgar Dijkstra.

http://en.wikipedia.org/wiki/Considered_harmful

And, of course, management went stupid (again) and came up with "you
cannot use the GOTO in any code at all". Which actually makes some
COBOL more complicated due to the requirement of nesting IF statements
within IF statements. 



Just as in many other things, a good idea can be taken to an illogical
extreme or out of context.

In addition to avoiding GO TO's, Dykstra also proposed limiting each
"module" to "1 page or less of code", that being the upper limit 
of what could be "proven" to be correct code. ( I'll bet management
forgot about that one!).

BTW, I agree w/Dykstra. Maintaining a structured program is far easier
than spaghetti code. However, one page of code is a very small routine
and will result in excessive
overhead due to all of the module calls. (BTDTGTTS).

I haven't re-read Dykstra in many years, but I believe that he may have
left some loopholes.

All of that being said, sometimes a plain old "GO TO" is far easier to
decipher that if/then/else nested ad nauseum.
As with most things in this business, it depends!

Just my $0.02 (USD) worth.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[David Andrews]

On Mon, 2012-04-16 at 11:08 -0400, McKown, John wrote:
> Ah, imagine the joys of writing CICS code in LISP (Lots of Insipid,
> Silly Parentheses).

There are more parentheses in Java code than equivalent Clojure.  Just
sayin'.

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Embrace functional programming and eschew the historic procedural paradigm! You 
have nothing to lose but your chains! And maybe your mind.

There is no GOTO in any pure functional language that I've read up on 
(basically Haskell and Erlang). Ah, imagine the joys of writing CICS code in 
LISP (Lots of Insipid, Silly Parentheses).

John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Binyamin Dissen]

On Mon, 16 Apr 2012 09:30:47 -0500 Matthew Stitt 
wrote:

:>This topic I cannot resist...  Uggg...

:>Having learned COBOL in the mid 70's, the instructor taught that PERFORM was 
to be used only in situations where you wanted
:>to do a certain routine at several locations in the program.  The teaching 
was also about "straight line" programming.  Flow 
:>Charts were also part of the curriculum.

:>Having said that, I still use GO TO extensively, and have not kept up with 
the "modern" programming extensions and constructs.
:>I've had many instances in my career where a "structured" program has been 
"straight lined" with extremely dramatic performance
:>results.  Mostly I believe that knowing Assembler language and how the COBOL 
compiler would generate the assembler code version
:>of the program provided the reasons for my coding techniques.  I would write 
the program as close to what the assembler code
:>would be as possible.  This would usually provide some great performance at 
run time (and at compile time).

:>One example (out of several) was a program which normally took 4-6 hours to 
do its magic.  When I re-wrote it due to the necessity
:>of adding more functionality, I went ahead and "straight lined" it according 
to the logic of what the program was supposed to do.
:>When the re-write was finished, the new program took 20 minutes to run the 
first time it was in production.  I have several other
:>examples with these type of results.

The elimination of GOTOs was to save people time at the cost of CPU time.
Obviously, if a procedure was called from several points ALTER GOTO would
generate fewer instructions than perform.

But with GOTOless programming the logic is easier to read. There is no
question about how you got somewhere.

:>Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a 
perform.  Went to the Well in the early-mid 80's over that 
:>one with a bunch of certain "whiz-kids" who were trained under the good 
doctors premises.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[David Andrews]

On Mon, 2012-04-16 at 09:52 -0400, Joel C. Ewing wrote:
> One proposal many 
> years ago to totally eliminate the FORTRAN "GO TO" was to replace it 
> with a "COME FROM" statement.

Ah yes, an old chestnut: http://www.fortran.com/come_from.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Matthew Stitt]

This topic I cannot resist...  Uggg...

Having learned COBOL in the mid 70's, the instructor taught that PERFORM was to 
be used only in situations where you wanted
to do a certain routine at several locations in the program.  The teaching was 
also about "straight line" programming.  Flow 
Charts were also part of the curriculum.

Having said that, I still use GO TO extensively, and have not kept up with the 
"modern" programming extensions and constructs.
I've had many instances in my career where a "structured" program has been 
"straight lined" with extremely dramatic performance
results.  Mostly I believe that knowing Assembler language and how the COBOL 
compiler would generate the assembler code version
of the program provided the reasons for my coding techniques.  I would write 
the program as close to what the assembler code
would be as possible.  This would usually provide some great performance at run 
time (and at compile time).

One example (out of several) was a program which normally took 4-6 hours to do 
its magic.  When I re-wrote it due to the necessity
of adding more functionality, I went ahead and "straight lined" it according to 
the logic of what the program was supposed to do.
When the re-write was finished, the new program took 20 minutes to run the 
first time it was in production.  I have several other
examples with these type of results.

Also, CICS used to treat the "HANDLE CONDITION" API as a GO TO, not a perform.  
Went to the Well in the early-mid 80's over that 
one with a bunch of certain "whiz-kids" who were trained under the good doctors 
premises.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Joel C. Ewing]

And of course there were languages of the time like FORTRAN, which 
encouraged unconstrained use of "GO TO" and the creation of "spaghetti 
code".  FORTRAN at that point had very limited support for structured 
programming:  one very restrictive loop construct and a conditional 
branch which was essentially a three-way "GO TO".  There were even cases 
where the conventions being followed might require a "GO TO" to reach 
corrective additions which would then use a "GO TO" to resume the 
original statement stream, either to preserve statement number 
sequencing conventions, or to avoid resequencing the entire program deck 
when all cards had sequence numbers.


 I think more people interpreted Dijkstra's remarks as a complaint 
against the "unstructured" use of "GO TO" and the lack of language 
support for structured programming constructs that forced  frequent "GO 
TO" use, rather than an arbitrary total ban.  The complaint was 
primarily one about use of the "GO TO" degrading comprehension of the 
program structure, not about program performance.  Ultimately, all code 
is reduced to the Assembler or machine language level, where the 
machine-level equivalent of the "GO TO" is essential and unavoidable.


ACM SIGPLAN (Special Interest Group on Programming Languages) Notices 
tended to publish humor, especially near April 1.  One proposal many 
years ago to totally eliminate the FORTRAN "GO TO" was to replace it 
with a "COME FROM" statement.  This totally eliminated the confusion 
over whether any FORTRAN statement with a statement number might be the 
target of some unseen remote branch -- and replaced it with the even 
more confusing concept that every statement with a statement number 
might actually be a disguised branch to some remote "COME FROM" statement.

  JC Ewing


On 04/16/2012 07:42 AM, McKown, John wrote:

What??? "monopolizes the CPU"??? GO TO was made a pariah by an article by Edgar 
Dijkstra.

http://en.wikipedia.org/wiki/Considered_harmful

And, of course, management went stupid (again) and came up with "you cannot use the 
GOTO in any code at all". Which actually makes some COBOL more complicated due 
to the requirement of nesting IF statements within IF statements. And before the END-IF, 
that could be very complicated. I've see old code like:

IF ... THEN
...
IF ... THEN
...
ELSE
NEXT SENTENCE
...
IF ... THEN
...
   IF ... THEN
   ...
   ELSE
   NEXT SENTENCE
ELSE
...
.

Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it.




--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Yes, modern COBOL is much better. I don't use COBOL much, and other than the 
new END-verb constructs, don't do much. But you still need a PERFORM to loop. 
I.e. you cannot loop in the READ verb itself. Might be nice.
I guess you could:

PERFORM UNTIL EOF
   READ ...
  AT END
  SET EOF TO TRUE
  NOT AT END
  ...
   END-READ
END-PERFORM

I haven't looked recently, but we have a lot of old code. So we don't have much 
with the newer constructs.
 
--
John McKown 

Systems Engineer IV

IT

 

Administrative Services Group

 

HealthMarkets®

 

9151 Boulevard 26 . N. Richland Hills . TX 76010

(817) 255-3225 phone . 

john.mck...@healthmarkets.com . www.HealthMarkets.com

 

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bill Ashton
> Sent: Monday, April 16, 2012 8:36 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> John, the READ construct now is much easier with
> 
> READ FILE
> AT END
> Do stuff
> NOT AT END
> Do normal processing
> END-READ
> 
> This makes it really easy to keep the code tight and all 
> together. By using
> program switches, I have handled program start and end, abend, and
> processed 6 or 7 files with no (or very few) paragraphs, and 
> only a couple
> statements ending with periods.  It actually was fun to put 
> together and
> was easy to maintain. However, it would not always be this 
> streamlined for
> some large programs with lots of things going on.
> 
> Billy
> 
> On Mon, Apr 16, 2012 at 8:28 AM, McKown, John 
>  > wrote:
> 
> > Our use of GO TO is generally restricted to usage such as:
> >
> >   PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
> >
> > I-P.
> >READ FILE AT END
> > SET CONDITION TO TRUE
> > GO TO I-P-EXIT
> >END-READ
> > ...
> > I-P-EXIT.
> >EXIT.
> >
> > Otherwise, to avoid the GO TO, we'd need to do:
> >
> > I-P.
> >READ FILE AT END
> > SET CONDITION TO TRUE
> >END-READ
> >IF NOT CONDITION THEN
> > ...
> >END-IF.
> > I-P-EXIT.
> >EXIT.
> >
> > Which I consider to be worse than the exit, so far as 
> comprehension is
> > concerned.
> >
> > --
> > John McKown
> > Systems Engineer IV
> > IT
> >
> > Administrative Services Group
> >
> > HealthMarkets®
> >
> > 9151 Boulevard 26 . N. Richland Hills . TX 76010
> > (817) 255-3225 phone .
> > john.mck...@healthmarkets.com . 
> www.HealthMarkets.com<http://www.healthmarkets.com/>
> >
> > Confidentiality Notice: This e-mail message may contain 
> confidential or
> > proprietary information. If you are not the intended 
> recipient, please
> > contact the sender by reply e-mail and destroy all copies 
> of the original
> > message. HealthMarkets® is the brand name for products 
> underwritten and
> > issued by the insurance subsidiaries of HealthMarkets, Inc. 
> -The Chesapeake
> > Life Insurance Company®, Mid-West National Life Insurance Company of
> > TennesseeSM and The MEGA Life and Health Insurance Company.SM
> >
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
> > > Sent: Monday, April 16, 2012 5:40 AM
> > > To: IBM-MAIN@bama.ua.edu
> > > Subject: SV: GO TO "cobol"
> > >
> > > An alternative is to have e g an 88-type LEAVE item that is
> > > checked for every code-block including all iterations and 
> selections.
> > > (You set leave to true when wanting to do a "leave" type jump.)
> > >
> > >
> > >
> > > Regards,
> > > Thomas Berg
> > > __
> > > Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
> > >
> > >
> > >
> > > > -Ursprungligt meddelande-
> > > > Från: IBM Mainframe Discussion List
> > > [mailto

Re: GO TO "cobol"

[Bill Ashton]

John, the READ construct now is much easier with

READ FILE
AT END
Do stuff
NOT AT END
Do normal processing
END-READ

This makes it really easy to keep the code tight and all together. By using
program switches, I have handled program start and end, abend, and
processed 6 or 7 files with no (or very few) paragraphs, and only a couple
statements ending with periods.  It actually was fun to put together and
was easy to maintain. However, it would not always be this streamlined for
some large programs with lots of things going on.

Billy

On Mon, Apr 16, 2012 at 8:28 AM, McKown, John  wrote:

> Our use of GO TO is generally restricted to usage such as:
>
>   PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
>
> I-P.
>READ FILE AT END
> SET CONDITION TO TRUE
> GO TO I-P-EXIT
>END-READ
> ...
> I-P-EXIT.
>EXIT.
>
> Otherwise, to avoid the GO TO, we'd need to do:
>
> I-P.
>READ FILE AT END
> SET CONDITION TO TRUE
>END-READ
>IF NOT CONDITION THEN
> ...
>END-IF.
> I-P-EXIT.
>EXIT.
>
> Which I consider to be worse than the exit, so far as comprehension is
> concerned.
>
> --
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
> HealthMarkets®
>
> 9151 Boulevard 26 . N. Richland Hills . TX 76010
> (817) 255-3225 phone .
> john.mck...@healthmarkets.com . 
> www.HealthMarkets.com<http://www.healthmarkets.com/>
>
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the original
> message. HealthMarkets® is the brand name for products underwritten and
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
> Life Insurance Company®, Mid-West National Life Insurance Company of
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
>
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
> > Sent: Monday, April 16, 2012 5:40 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: SV: GO TO "cobol"
> >
> > An alternative is to have e g an 88-type LEAVE item that is
> > checked for every code-block including all iterations and selections.
> > (You set leave to true when wanting to do a "leave" type jump.)
> >
> >
> >
> > Regards,
> > Thomas Berg
> > __
> > Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
> >
> >
> >
> > > -Ursprungligt meddelande-
> > > Från: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@bama.ua.edu] För
> > > Edward Jaffe
> > > Skickat: den 16 april 2012 08:15
> > > Till: IBM-MAIN@bama.ua.edu
> > > Ämne: Re: GO TO "cobol"
> > >
> > > On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:
> > > > For devotees of Jackson Structured programming, the GOTO
> > is a must for
> > > > POSIT and ADMIT processing. Otherwise it can be messy
> > avoiding a GOTO.
> > >
> > > The problem with GOTO is that the suitability of the target branch
> > > location is
> > > not enforced by the compiler according to any structured discipline.
> > >
> > > Premature terminations (posit/quit/admit) can almost always
> > be handled
> > > with
> > > LEAVE-type statements or immediate return from a subroutine. Some
> > > languages have
> > > SIGNAL, EXIT, etc. which can help provide structured premature
> > > termination for
> > > larger routines without resorting to the dreaded GOTO.
> > >
> > > --
> > > Edward E Jaffe
> > > Phoenix Software International, Inc
> > > 831 Parkview Drive North
> > > El Segundo, CA 90245
> > > 310-338-0400 x318
> > > edja...@phoenixsoftware.com
> > > http://www.phoenixsoftware.com/
> > >
> > >
> > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Remember when COBOL was originally designed. We've learned a LOT since then. 
The only real looping verb is PERFORM. It has an WHILE condition test and an 
UNTIL condition test. And, in modern COBOLs, the phrases WITH TEST BEFORE or 
WITH TEST AFTER, to perform the test at the start of the loop (0 or more 
iterations, like while in C) or at the end of the loop (1 or more iteration, 
like do while in C). WITH TEST AFTER is the default. But the UNTIL is a 
condition test and cannot execute something which returns a TRUE/FALSE type 
value.

Also remember that COBOL, at least originally, was supposed to be very 
English-like and so usable by people at the Army PFC level of training. 

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin
> Sent: Monday, April 16, 2012 8:12 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: GO TO "cobol"
> 
> On Mon, 16 Apr 2012 07:28:10 -0500, McKown, John wrote:
> 
> >Our use of GO TO is generally restricted to usage such as:
> >
> >   PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
> >
> >I-P.
> >READ FILE AT END
> > SET CONDITION TO TRUE
> > GO TO I-P-EXIT
> >END-READ
> >...
> >I-P-EXIT.
> >EXIT.
> >
> >Otherwise, to avoid the GO TO, ...
> > 
> I don't know COBOL.  However any properly designed
> language should allow incorporating such a test in the
> loop control expression:
> 
> while read( ... ); do
> ...
> done
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Paul Gilmartin]

On Mon, 16 Apr 2012 07:28:10 -0500, McKown, John wrote:

>Our use of GO TO is generally restricted to usage such as:
>
>   PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.
>
>I-P.
>READ FILE AT END
> SET CONDITION TO TRUE
> GO TO I-P-EXIT
>END-READ
>...
>I-P-EXIT.
>EXIT.
>
>Otherwise, to avoid the GO TO, ...
> 
I don't know COBOL.  However any properly designed
language should allow incorporating such a test in the
loop control expression:

while read( ... ); do
...
done

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Paul Gilmartin]

On Sun, 15 Apr 2012 23:15:19 -0700, Edward Jaffe wrote:
>
>The problem with GOTO is that the suitability of the target branch location is
>not enforced by the compiler according to any structured discipline.
> 
"C" commits this offense.  Shame on C.

>Premature terminations (posit/quit/admit) can almost always be handled with
>LEAVE-type statements or immediate return from a subroutine. Some languages 
>have
>SIGNAL, EXIT, etc. which can help provide structured premature termination for
>larger routines without resorting to the dreaded GOTO.
>
Rexx is a nightmare here.  The LEAVE statement, even with a specified
target, won't exit a (nest of) procedure(s).  The SIGNAL statement
trashes the DO nesting at the target level.  Shame on Rexx.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

What??? "monopolizes the CPU"??? GO TO was made a pariah by an article by Edgar 
Dijkstra.

http://en.wikipedia.org/wiki/Considered_harmful

And, of course, management went stupid (again) and came up with "you cannot use 
the GOTO in any code at all". Which actually makes some COBOL more 
complicated due to the requirement of nesting IF statements within IF 
statements. And before the END-IF, that could be very complicated. I've see old 
code like:

IF ... THEN
...
   IF ... THEN
   ...
   ELSE
   NEXT SENTENCE
   ...
   IF ... THEN
   ...
  IF ... THEN
  ...
  ELSE
  NEXT SENTENCE 
   ELSE
   ...
.

Each internal IF had to have a corresponding ELSE with only NEXT SENTENCE in it.

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jake anderson
> Sent: Sunday, April 15, 2012 10:49 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: GO TO "cobol"
> 
> Hi All,
> 
> Apology for asking a basic question and Being Ignorant. We 
> know that GO TO
> statments are a big "NO" in many production sites and one of 
> the reason
> being it monopolizes the entire CPU. Are there any 
> documentation explaining
> about the  GO TO statements  which clearly describes how it  
> effects the
> System CPU and performances ?
> 
> Apology again if the question is not really sensible or else 
> it requires
> more information.
> 
> Jake
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[McKown, John]

Our use of GO TO is generally restricted to usage such as:

   PERFORM I-P THRU I-P-EXIT UNTIL CONDITION.

I-P.
READ FILE AT END
 SET CONDITION TO TRUE
 GO TO I-P-EXIT
END-READ
...
I-P-EXIT.
EXIT.

Otherwise, to avoid the GO TO, we'd need to do:

I-P.
READ FILE AT END
 SET CONDITION TO TRUE
END-READ
IF NOT CONDITION THEN
...
END-IF.
I-P-EXIT.
EXIT.

Which I consider to be worse than the exit, so far as comprehension is 
concerned.

-- 
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone . 
john.mck...@healthmarkets.com . www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg
> Sent: Monday, April 16, 2012 5:40 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: SV: GO TO "cobol"
> 
> An alternative is to have e g an 88-type LEAVE item that is 
> checked for every code-block including all iterations and selections. 
> (You set leave to true when wanting to do a "leave" type jump.)
> 
> 
> 
> Regards,
> Thomas Berg
> __
> Thomas Berg   Specialist   AM/DQS   SWEDBANK AB (publ)
> 
> 
> 
> > -Ursprungligt meddelande-
> > Från: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] För
> > Edward Jaffe
> > Skickat: den 16 april 2012 08:15
> > Till: IBM-MAIN@bama.ua.edu
> > Ämne: Re: GO TO "cobol"
> > 
> > On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:
> > > For devotees of Jackson Structured programming, the GOTO 
> is a must for
> > > POSIT and ADMIT processing. Otherwise it can be messy 
> avoiding a GOTO.
> > 
> > The problem with GOTO is that the suitability of the target branch
> > location is
> > not enforced by the compiler according to any structured discipline.
> > 
> > Premature terminations (posit/quit/admit) can almost always 
> be handled
> > with
> > LEAVE-type statements or immediate return from a subroutine. Some
> > languages have
> > SIGNAL, EXIT, etc. which can help provide structured premature
> > termination for
> > larger routines without resorting to the dreaded GOTO.
> > 
> > --
> > Edward E Jaffe
> > Phoenix Software International, Inc
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > 310-338-0400 x318
> > edja...@phoenixsoftware.com
> > http://www.phoenixsoftware.com/
> > 
> > 
> --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: GO TO "cobol"

[Edward Jaffe]

On 4/15/2012 10:31 PM, Wayne Bickerdike wrote:

For devotees of Jackson Structured programming, the GOTO is a must for
POSIT and ADMIT processing. Otherwise it can be messy avoiding a GOTO.


The problem with GOTO is that the suitability of the target branch location is 
not enforced by the compiler according to any structured discipline.


Premature terminations (posit/quit/admit) can almost always be handled with 
LEAVE-type statements or immediate return from a subroutine. Some languages have 
SIGNAL, EXIT, etc. which can help provide structured premature termination for 
larger routines without resorting to the dreaded GOTO.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN