Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

I guess it depends on how you think of it.  I don't think of it the way it is 
stated that people think of it.  I think of it as "read each record in a file, 
processing each one."  Neither of those loops TRULY represent this


I think this is one reason why many languages go with the "for each" paradigm, 
with the details of reading the record and processing or terminating really 
hidden from the end user.  For example, in pseudo-code


foreach my-record in my-file

do

   [...]

end


the "foreach" process will read each record in my-file and invoke the code in 
the do...end block for each one.  Upon reaching the EOF condition it will 
return out of the foreach process.


The actual code behind this "foreach" could be either of the two methods below, 
but it doesn't really matter because you as an programmer making use of foreach 
never see it and don't care about it.


I don't see anything like this ever being implemented in COBOL, however.



From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Monday, August 15, 2016 1:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL 
Standard (and a Plea for Understanding)

I've never previously heard of a "loop and a half", so did some digging.

Eric S Roberts, you picked an oft-referenced person, Frank :-)

Here's an example of the discussion (not from Roberts, but referencing him):

"The problem with using goto isn't the keyword itself-rather, it's the use of 
goto in inappropriate places. The goto statement can be a useful tool in 
structuring program flow and can be used to write more expressive code than 
that resulting from other branching and iteration mechanisms. One such example 
isthe "loop-and-a-half" problem, as coined by Dijkstra. Here is the traditional 
flow of the loop-and-a-half problem in pseudocode: -

loop
read in a value
if value == sentinel then exit
process the value
end loop

The exit from the loop is accomplished only by the execution of the exit 
statement in the middle of the loop. This loop/exit/end loop cycle, however, 
can be quite disturbing to some people who, acting on the notion that all uses 
of goto are evil, would write this code as follows: -

read in a value
while value != sentinel
process the value
read in a value
end while

Unfortunately, as Eric S. Roberts of Stanford University points out, this 
second approach has two major drawbacks. First, it requires the duplication of 
the statement(s) required to read in a value. Any time you duplicate code, this 
results in an obvious maintenance problem in that any change to one statement 
must be made to the other. The second problem is more subtle and probably more 
damning. The key to writing solid code that's easy to understand, and therefore 
maintain, is to write code that reads in a natural manner. In any noncode 
description of what this code is attempting to do, one would describe the 
solution as follows: First, I need to read in a value. If that value is a 
sentinel, I stop. If not, I process that value and continue to the next value. 
Therefore, it's the code omitting the exit statement that's actually 
counterintuitive because that approach reverses the natural way of thinking 
about the problem. Now, let's look at some situations in which a goto statement 
can result in the best way to structure control flow."

Breezing over the "evil" (straw man technique, that was) we get to two major 
(alleged  by Roberts) drawbacks: "it requires the duplication of the 
statement(s) required to read in a value". No, it doesn't. Unless you are only 
interested in "snippets" rather than programs/systems.

Secondly, and that author was saving the best, more damning, for second, "The 
key to writing solid code that's easy to understand, and therefore maintain, is 
to write code that reads in a natural manner." Oh. Ah, they develop:

"In any noncode description of what this code is attempting to do, one would 
describe the solution as follows: First, I need to read in a value. If that 
value is a sentinel, I stop. If not, I process that value and continue to the 
next value."

And continues "Therefore, it's the code omitting the exit statement that's 
actually counterintuitive because that approach reverses the natural way of 
thinking about the problem."

Mmmm... snippets.

I'm a Mail Opening Operative. I arrive at my desk, there's a pile of mail, I 
open a letter, bin the envelope (it is against policy, but I save any 
nice-looking stamps for my cousin, who I think should collect stamps), see who 
it is addressed to (or if it is "advertising", which Mr Johnson deals with - 
I'm not allowed to throw any actual mail away

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

I've never previously heard of a "loop and a half", so did some digging.

Eric S Roberts, you picked an oft-referenced person, Frank :-)

Here's an example of the discussion (not from Roberts, but referencing him):

"The problem with using goto isn't the keyword itself-rather, it's the use of 
goto in inappropriate places. The goto statement can be a useful tool in 
structuring program flow and can be used to write more expressive code than 
that resulting from other branching and iteration mechanisms. One such example 
isthe "loop-and-a-half" problem, as coined by Dijkstra. Here is the traditional 
flow of the loop-and-a-half problem in pseudocode: -

loop
read in a value
if value == sentinel then exit
process the value
end loop

The exit from the loop is accomplished only by the execution of the exit 
statement in the middle of the loop. This loop/exit/end loop cycle, however, 
can be quite disturbing to some people who, acting on the notion that all uses 
of goto are evil, would write this code as follows: -

read in a value
while value != sentinel
process the value
read in a value
end while

Unfortunately, as Eric S. Roberts of Stanford University points out, this 
second approach has two major drawbacks. First, it requires the duplication of 
the statement(s) required to read in a value. Any time you duplicate code, this 
results in an obvious maintenance problem in that any change to one statement 
must be made to the other. The second problem is more subtle and probably more 
damning. The key to writing solid code that's easy to understand, and therefore 
maintain, is to write code that reads in a natural manner. In any noncode 
description of what this code is attempting to do, one would describe the 
solution as follows: First, I need to read in a value. If that value is a 
sentinel, I stop. If not, I process that value and continue to the next value. 
Therefore, it's the code omitting the exit statement that's actually 
counterintuitive because that approach reverses the natural way of thinking 
about the problem. Now, let's look at some situations in which a goto statement 
can result in the best way to structure control flow."

Breezing over the "evil" (straw man technique, that was) we get to two major 
(alleged  by Roberts) drawbacks: "it requires the duplication of the 
statement(s) required to read in a value". No, it doesn't. Unless you are only 
interested in "snippets" rather than programs/systems.

Secondly, and that author was saving the best, more damning, for second, "The 
key to writing solid code that's easy to understand, and therefore maintain, is 
to write code that reads in a natural manner." Oh. Ah, they develop:

"In any noncode description of what this code is attempting to do, one would 
describe the solution as follows: First, I need to read in a value. If that 
value is a sentinel, I stop. If not, I process that value and continue to the 
next value."

And continues "Therefore, it's the code omitting the exit statement that's 
actually counterintuitive because that approach reverses the natural way of 
thinking about the problem."

Mmmm... snippets.

I'm a Mail Opening Operative. I arrive at my desk, there's a pile of mail, I 
open a letter, bin the envelope (it is against policy, but I save any 
nice-looking stamps for my cousin, who I think should collect stamps), see who 
it is addressed to (or if it is "advertising", which Mr Johnson deals with - 
I'm not allowed to throw any actual mail away) and then put it in the correct 
pigeon-hole. Then I pick up the next letter, and repeat the process. When there 
is no more mail, I count each bundle, put elastic bands around each bundle,  
and pass them to the delivery boy (if he's bothered to turn up on time, he's 
always with the girls in the punch room). I fill out a sheet of statistics, 
stamp it (Mr Johnson is terribly upset if I forget that). Lately, it was my own 
idea, and Mr Johnson was *very* pleased at my initiative, I have some 
pre-written pieces of paper to make it extremely clear who each packet is for. 
I'm sure *that boy* doesn't even appreciate it. Then it is on to internal mail, 
until the second post arrives in the early afternoon...

Now, one day, I turn up - *AND THERE ARE NO LETTERS WAITING*. I'm all of a 
flummox, and dial Mr Johnson immediately. He never likes being disturbed this 
early, but this was really *IMPORTANT*.

 That was character-acting, that was. Or 
character writing.

Now, which of the above two "snippets" is reflective of Mail Opening?  The one 
where you actually start the work of the loop, and exit the loop in a 
completely normal way, or the one where you do a bit of "priming", and realise 
there is nothing to process, so Mr Johnson needs to know?

Snippets.

I found this (different author, also refers to Roberts), as well, I suppose a 
variant of a loop-and-a-half to process "an array, which shows how it would be 
written with a GOTO:

i = low_value
loop:
   

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

Exception processing, while a good idea in my opinion, is one of those things 
from the 20xx COBOL standards that I have decided to not as IBM to implement.  
The COBOL standard implementation seems to be quite lacking.  There seems no 
way to "wrap" code that might throw an exception inside a block any smaller 
than the program level.  User-defined exceptions are always non-fatal and don't 
even need to be "caught", so it appears to me that an invoking program would 
ignore one by default.  I'd love to be proved wrong.


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Sunday, August 14, 2016 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL 
Standard (and a Plea for Understanding)

Keeping it COBOL, there is some masterful documentation relating to the 
probable conceptual origin of try/catch (COBOL's DECLARATIVES) *

However, there are bits of the concept which were left out:

"A declarative procedure can be performed from a nondeclarative procedure.

A nondeclarative procedure can be performed from a declarative procedure.

A declarative procedure can be referenced in a GO TO statement in a declarative 
procedure.

A nondeclarative procedure can be referenced in a GO TO statement in a 
declarative procedure.

You can include a statement that executes a previously called USE procedure 
that is still in control. However, to avoid an infinite loop, you must be sure 
there is an eventual exit at the bottom.

The declarative procedure is exited when the last statement in the procedure is 
executed."




* this statement may include an assumption with which others disagree

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

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

Keeping it COBOL, there is some masterful documentation relating to the 
probable conceptual origin of try/catch (COBOL's DECLARATIVES) *

However, there are bits of the concept which were left out:

"A declarative procedure can be performed from a nondeclarative procedure.

A nondeclarative procedure can be performed from a declarative procedure.

A declarative procedure can be referenced in a GO TO statement in a declarative 
procedure.

A nondeclarative procedure can be referenced in a GO TO statement in a 
declarative procedure.

You can include a statement that executes a previously called USE procedure 
that is still in control. However, to avoid an infinite loop, you must be sure 
there is an eventual exit at the bottom.

The declarative procedure is exited when the last statement in the procedure is 
executed."




* this statement may include an assumption with which others disagree

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[David Crayford]

On 14/08/2016 2:57 AM, Paul Gilmartin wrote:

On Sat, 13 Aug 2016 09:02:28 -0500, Bill Woodger wrote:

This can be rewritten as

while (true)
read value
if (value == sentinel) break;
process value


Yet I prefer expression-oriented languages that allow constructs such as:

while read value && [ value != sentinel ]; do
 process value
 done


I prefer object-oriented languages that support exceptions with 
constructs such as:


try
{
FooInputFileinput( indsn );
BarOutputFileoutput( outdsn );
while  ( input.read() )
{
// do something
}
}
catch  (exception  &e )
{
cout  <<"Error: "  << e.what();
}

Of course, exceptions are just like gotos but used judiciously can make 
code much easier to read and write.



But, yes, if the condition is a little more complicated, it's better to 
encapsulate
it in a function.  Legibility should be the deciding concern: which constructs
impels fewer saccades by the reader?

-- gil

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



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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Paul Gilmartin]

On Sat, 13 Aug 2016 09:02:28 -0500, Bill Woodger wrote:
>
>This can be rewritten as
>
>while (true)
>read value
>if (value == sentinel) break;
>process value
>
Yet I prefer expression-oriented languages that allow constructs such as:

while read value && [ value != sentinel ]; do
process value
done

But, yes, if the condition is a little more complicated, it's better to 
encapsulate
it in a function.  Legibility should be the deciding concern: which constructs
impels fewer saccades by the reader?

-- gil

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

And now we have a 21-year-old academic paper, the author ruffled by critique of 
a previous published item on switching their course from using Pascal to using 
C and teaching an "intuitive" use of a "goto". M... "teaching an intuitive" 
doesn't work, does it. "Letting the students do what they 'feel' is the right 
thing, rather than teaching anything". That's better. Let's apply that to 
mathematics, other sciences, (human) languages and even history and geography.

OK, what is it that is "intuitive"? 
Get-out-of-trouble-quickly-and-move-on-to-the-next-issue. Apply until 
end-of-program. Anoint program as "working".

What is not intuitive to the new CS attendee is "design" when it comes to 
programming. Design is not about language constructs. Implementation is about 
language constructs. You can provide an implementation of a program without 
design (do it intuitively, or by rote application of constructs). In those 
cases it will only be a "structured" program (assuming that means something 
beyond rote) by coincidence and only up to the point when the same (or a 
similarly tutored) programmer changes it.

A new term to me is "loop and a half". So I search-engined. Ironically I found 
this (ironic because it references Roberts, I'm not going to follow the link 
yet, but I wonder...):

" Loop and a Half

You are writing a Process All Items loop.

How do you structure the loop when the number of items in the collection isn't 
known in advance and the items are provided one-at-a-time?

For example, you might be reading values from the keyboard or from a file. In 
general, you are processing all items until a sentinel is reached. The sentinel 
may be end-of-file, a valid value for the type of data being read, or an 
exception.

The loop requires priming to read/get the first value, a loop guard to test for 
the sentinel, and another read/get inside the loop. This leads to duplicate 
code for the read/get and makes the loop body harder to understand since it 
turns a read-and-process loop into a process-and-read loop.

Therefore, use a while-true loop with a break in the loop body to avoid 
duplicate code and to match your intuition that the loop is a read-and-process 
loop.

For example, consider pseudocode for a sentinel loop:

read value
while (value != sentinel)
process value
read value

This can be rewritten as

while (true)
read value
if (value == sentinel) break;
process value

Although the break is essentially a goto and thus violates a canon of 
structured programming, it results in code that it easier to develop Roberts. 
Because there is no code duplication the code should be easier to maintain and 
easier to understand"

"because there is no code duplication" is the key, well...

execute a-procedure-that-yields-the-value
while (value != sentinel)
process value
execute a-procedure-that-yields-the-value

Isn't that at least part of what procedures are for? Even better:

execute 
a-procedure-that-yields-the-value-and-ensures-things-are-also-OK-like-at-least-one-value-is-present
while (value != sentinel)
process value
execute a-procedure-that-yields-the-value

procedure: 
a-procedure-that-yields-the-value-and-ensures-things-are-also-OK-like-at-least-one-value-is-present
execute a-procedure-that-yields-the-value
hey-let's-do-some-checking-for-things-that-should-halt-the-processing

Where's the "duplicated code"? It's where it should be. Now why do you need the 
GO TO?

I think most languages have procedures in one way or another, don't they?

Now if you want that control with the "ephemeral", then you have to set a flag 
when the ephemeral occurs, and if that is not possible (like when a while of a 
read results in a boolean in a loop control), then, err by repeating the 
test, repeating the code, or by making things more complex.

 PROCESS-MY-FILE.
 PERFORM UNTIL EXIT
 READ MY-FILE 
  INTO MY-RECORD
 AT END
 IF RECORD-COUNT GREATER THAN ZERO
 EXIT PERFORM
 ELSE 
 tell the world we're in a mess
 END-IF
 NOT AT END
 PERFORM PROCESS-MY-RECORD
 END-READ
 ADD 1 TO RECORD-COUNT
 END-PERFORM.

And I like files with "headers". And if they have headers, I want to check that 
the first is a header, and there is only one header, and have a trailer, and 
count the records, and check that the file is in sequence (if it need be) 
either uniquely or not, and I don't want all that stuff to mess up the look of 
the "process a file loop". And I can do all that without a GO TO, and whether 
the GO TO is disguised or not.

And if that is the loop for "advanced" cases, why don't I use the same loop for 
all cases, so whether the file is complex or not, the loop "looks" the same, 
there is nothing new or different to "understand".

---

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

Basically, any "loop and a half" problem.  That is, one where you first have to 
first check something that you can't know the result of ahead of time (such as, 
obviously, "will my next read return a record or will it return and end of file 
condition?).  It doesn't have to be I/O, though certainly that is the most 
common.


Just just found a wonderful (because it agrees with my thoughts, of course!) 
paper on this issue here:

http://cis-linux1.temple.edu/~giorgio/cis71/software/roberts/documents/loopexit.txt.


I think that calling it an "infinite loop" is unfortunate, because "of course 
we don't want to create infinite loops; we'd be stuck inside them!).  This is 
why I chose to use the term "unbounded loop" instead, though I suppose 
unbounded also implies that the loop never terminates.  So PERFORM UNTIL EXIT 
is quite reasonable, since it better suggests what its really doing.  (and 
perhaps I should change to that rather than PERFORM UNBOUNDED").  Honestly, 
LOOP UNTIL EXIT would be better, but I understand why they didn't feel the need 
for a new keyword when PERFORM was already there.  FWIW, PERFORM FOREVER is my 
least favorite of the suggested syntaxes for such a thing.


As for "true binary" numbers, at the very least it makes interacting with CICS, 
system APIs (LE, etc.), and calls to other languages (C, Java) more obvious.  
Some APIs even call for a 1 byte binary value, and that is even more difficult 
in COBOL, even IBM COBOL with "comp-5"!


I'm also, in general, against the TRUNC(OPT) option which is neither true 
binary nor "true decimal", and thus seems to me to be even more unpredictable.


For what its worth, I am all for true decimal data types holding truncating at 
the "decimal level", if you will.  Essentially, I think that decimal variables 
should be used to hold money values and other things like that, while binary 
variables should be used for general counting, subscripts, and any case where 
it is actually required (as shown above).  And binary floating point should 
never be used.  :-)  Decimal floating point might be OK, but I don't know 
enough about it to really say for sure.


Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 12, 2016 3:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL 
Standard (and a Plea for Understanding)

Perhaps you can suggest a use for it beyond a file-processing loop.

It may be an "across the Pond" type of thing, FILE STATUS is de rigueur (I 
think that means they use it in France as well)? With FILE STATUS you don't 
have to AT-END-set-a-flag, you have a "flag" set for you (100% accurate, and 
nothing extra to code) which you can use (for a value of "10") as your 
termination condition. FILE STATUS used for all files, individual field for 
each file, and field checked after each IO. (You do seem to have far greater a 
scope of what is possible in your COBOL programs for you to implement than is 
normally seen "over here").

Despite what Micro Focus thinks, COBOL does not control traffic lights (except 
perhaps in one town somewhere, and that is not using Enterprise COBOL). My 
thoughts on "do forever" are that its use would be "monitoring" where there are 
many and varied states that could occur, singly or in combination, and when 
whatever it is that is significant occurs, you need to stop monitoring and act.

OK, with COBOL you may have "press X, Y, Z or Space" each for a particular 
operation, and you may want to have your program sitting there waiting to act, 
but not in Enterprise COBOL (you'd be waiting a long time).

How would you use a "do forever" in another case? You can't be asking for it 
for just one minor situation, and with the coincidence of where it would 
previously have required a GO TO to break out of the loop, there is now a hand 
"EXIT PERFORM" to identically replace the GO TO.

At some point prior to the 2002 Standard (now superseded by 2014) the influence 
of non-Mainframe COBOLs began to outweigh the influence of Mainframe COBOLs. 
There is much that is new that is just not worth the effort to apply to 
Enterprise COBOL.

FUNCTIONs were bad enough (and they date from 1989). Why do I say that:

IF FUNCTION something ( somefunctionparameter ) EQUAL TO 7
do some stuff
END-IF

some other lines of code
abend occurs here

Now, for my "abend occurs here" I want to know the result of the FUNCTION 
something. I look at the code, and discover that the result has been 
overwritten by something else (it is in complier-managed storage) in "some 
other lines of code".

Although there is a dozen-pages-long table of IBM Ext

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Edward Gould]

> On Aug 12, 2016, at 4:15 PM, Bill Woodger  wrote:
> 
> Perhaps you can suggest a use for it beyond a file-processing loop. 
> 
> It may be an "across the Pond" type of thing, FILE STATUS is de rigueur (I 
> think that means they use it in France as well)? With FILE STATUS you don't 
> have to AT-END-set-a-flag, you have a "flag" set for you (100% accurate, and 
> nothing extra to code) which you can use (for a value of "10") as your 
> termination condition. FILE STATUS used for all files, individual field for 
> each file, and field checked after each IO. (You do seem to have far greater 
> a scope of what is possible in your COBOL programs for you to implement than 
> is normally seen "over here").


Bill:

In one shop I worked they had never heard of it so no use there.

Ed

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

Perhaps you can suggest a use for it beyond a file-processing loop. 

It may be an "across the Pond" type of thing, FILE STATUS is de rigueur (I 
think that means they use it in France as well)? With FILE STATUS you don't 
have to AT-END-set-a-flag, you have a "flag" set for you (100% accurate, and 
nothing extra to code) which you can use (for a value of "10") as your 
termination condition. FILE STATUS used for all files, individual field for 
each file, and field checked after each IO. (You do seem to have far greater a 
scope of what is possible in your COBOL programs for you to implement than is 
normally seen "over here").

Despite what Micro Focus thinks, COBOL does not control traffic lights (except 
perhaps in one town somewhere, and that is not using Enterprise COBOL). My 
thoughts on "do forever" are that its use would be "monitoring" where there are 
many and varied states that could occur, singly or in combination, and when 
whatever it is that is significant occurs, you need to stop monitoring and act. 

OK, with COBOL you may have "press X, Y, Z or Space" each for a particular 
operation, and you may want to have your program sitting there waiting to act, 
but not in Enterprise COBOL (you'd be waiting a long time).

How would you use a "do forever" in another case? You can't be asking for it 
for just one minor situation, and with the coincidence of where it would 
previously have required a GO TO to break out of the loop, there is now a hand 
"EXIT PERFORM" to identically replace the GO TO.

At some point prior to the 2002 Standard (now superseded by 2014) the influence 
of non-Mainframe COBOLs began to outweigh the influence of Mainframe COBOLs. 
There is much that is new that is just not worth the effort to apply to 
Enterprise COBOL. 

FUNCTIONs were bad enough (and they date from 1989). Why do I say that:

IF FUNCTION something ( somefunctionparameter ) EQUAL TO 7
do some stuff
END-IF

some other lines of code
abend occurs here

Now, for my "abend occurs here" I want to know the result of the FUNCTION 
something. I look at the code, and discover that the result has been 
overwritten by something else (it is in complier-managed storage) in "some 
other lines of code". 

Although there is a dozen-pages-long table of IBM Extensions, the vast majority 
are deviations rather than things which are radically new. UNBOUNDED you have 
mentioned. VOLATILE. DBCS and friends. XML. JSON. It's not a vast hive of 
activity, but what there is is, to me, useful new functionality (yes, UNBOUNDED 
doesn't fit so well in that).

Yes, a one-byte binary would be useful simply to aid the manipulation of bits 
in COBOL. But "true native binary"? What does that mean in COBOL (the release 
from decimal maxima and minima)? It means less description (this can hold a 
value up to 99 vs this can hold a value up to 32,767, are you dumb or 
something, it's an integer - no it's not, it's a description of how many boxes 
you can store on a pallete) and more CPU used.

In Mainframe COBOL it is possible to have two things simultaneously - running 
fast, and still being able to read the programs. Neither are for free (you have 
to code, you can undo both, readily, with bad code).

Whilst Mainframe charging-structures exist, those are my two methods to 
evaluate new things. Not that anyone asks me.

If Mainframe charge-structures ceased to exist, and perhaps if you managed to 
somehow reliably squeeze extra hours into the day for each major 
implementation, then toss whatever fancy crap you like into Mainframe COBOL. 
First thing I'd want would be maxima and minima for numeric fields. Entirely 
the opposite of "native binary". But I don't want that now. For now I'll check 
the values when they need to be checked.

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

I did not post the attachment to the listserv.


From: IBM Mainframe Discussion List  on behalf of 
Gibney, Dave 
Sent: Friday, August 12, 2016 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL 
Standard (and a Plea for Understanding)

The listserv deletes ALL attachments

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Friday, August 12, 2016 10:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From
> the COBOL Standard (and a Plea for Understanding)
>
> On Fri, Aug 12, 2016 at 12:16 PM, Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
>
> > I've now attached a PDF version.  If that's not acceptable you'll have
> > to give me more of a hit what would be preferred.
> >
>
> Thanks. PDF is great.
>
>
>
> >
> >
> > As for your example
> >
> > 1) Try it and see if you like the results.
> >
> > 2) I hate the WS prefix.  Just my preference!
> >
>
> Each to his own, within company standards of course :-)
>
>
> --
> Klein bottle for rent -- inquire within.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Gibney, Dave]

The listserv deletes ALL attachments

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John McKown
> Sent: Friday, August 12, 2016 10:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From
> the COBOL Standard (and a Plea for Understanding)
> 
> On Fri, Aug 12, 2016 at 12:16 PM, Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
> 
> > I've now attached a PDF version.  If that's not acceptable you'll have
> > to give me more of a hit what would be preferred.
> >
> 
> ​Thanks. PDF is great. 
> 
> 
> 
> >
> >
> > As for your example
> >
> > 1) Try it and see if you like the results.
> >
> > 2) I hate the WS prefix.  Just my preference!
> >
> 
> ​Each to his own, within company standards of course :-)​
> 
> 
> --
> Klein bottle for rent -- inquire within.
> 
> Maranatha! <><
> John McKown
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[John McKown]

On Fri, Aug 12, 2016 at 12:16 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> I've now attached a PDF version.  If that's not acceptable you'll have to
> give me more of a hit what would be preferred.
>

​Thanks. PDF is great. ​



>
>
> As for your example
>
> 1) Try it and see if you like the results.
>
> 2) I hate the WS prefix.  Just my preference!
>

​Each to his own, within company standards of course :-)​


-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

I've now attached a PDF version.  If that's not acceptable you'll have to give 
me more of a hit what would be preferred.


As for your example

1) Try it and see if you like the results.

2) I hate the WS prefix.  Just my preference!


From: IBM Mainframe Discussion List  on behalf of 
John McKown 
Sent: Friday, August 12, 2016 6:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL 
Standard (and a Plea for Understanding)

On Thu, Aug 11, 2016 at 7:07 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Because I apparently have nothing better to do I have written a probably
> too long document detailing why I believe that Enterprise COBOL should
> support an extension to COBOL to support a native syntax for unbounded
> loops.  See my document attached to the follow COBOL Cafe Forum post:
>
>
> https://www.ibm.com/developerworks/community/
IBM developerWorks : IBM developerWorks : 
Community<https://www.ibm.com/developerworks/community/>
www.ibm.com
developerWorks; Community. Learn from and share with the experts in the 
developerWorks community.


> forums/html/topic?id=8cb11f10-03c9-4b82-9123-ba5ebc2240ff&ps=25
>
>
First the complaint: Really, a MS Word docx file? I would request, in any
future such posting, that you use something more "agnostic".

I like the syntax. The functionality is easy to emulate in normal IBM
Enterprise COBOL:

011410 01  WS-TRUE-FALSE   PIC X VALUE SPACE.
011420 88 WS-TRUE  VALUE SPACE.
011430 88 WS-FALSE VALUE ZERO.
011440 88 WS-FOREVER   VALUE ZERO.
011500 PROCEDURE DIVISION.
011510 START-UP.
011520 PERFORM UNTIL WS-FALSE
011530DISPLAY 'HELLO, SAILOR!' UPON SYSOUT
011531EXIT PERFORM
011540 END-PERFORM
011550 .


WS-FALSE is always FALSE, so this is an unbounded. As you can see, I also
made a WS-FOREVER (which could have simply been FOREVER). I could also have
created a WS-EXIT. I have an "inbred" tendency to make Working Storage
"transient" variable names start with WS- (Linkage Section names start LS-,
Local Storage name start LCL-).


--
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

With regard to using READ AT END / NOT AT END, I use it quite often, and I 
believe it can be safe IF you DON'T include the FILE STATUS clause in the 
SELECT statement.  This causes (for NON-VSAM file) an abend if there is an I/O 
error, which in my mind is perfectly acceptable.  YMMV.

I've required IBM support something similar for VSAM processing, and while they 
agreed to it years ago they have yet to implement it.  So in any case where you 
specify FILE STATUS I agree that you should not use [NOT] AT END (and [NOT] 
INVALID KEY), but rather you should check the associated FILE STATUS field.


Or you can use DECLARATIVES!


As for the "religious" titles for my sections, that was just a bit of whimsy.  
Hope I did not offend anyone!

Frank


From: IBM Mainframe Discussion List  on behalf of 
Bill Woodger 
Sent: Friday, August 12, 2016 12:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL 
Standard (and a Plea for Understanding)

I may have to reply initially with a thesis on "Not using FILE STATUS 
considered harmful - and AT END even without NOT AT END is a worse pain" (I'll 
leave the sub-tiles for later).

 PROCESS-MY-FILE.
 PERFORM UNTIL EXIT
 READ MY-FILE
  INTO MY-RECORD
 AT END
 EXIT PERFORM
 NOT AT END
 PERFORM PROCESS-MY-RECORD
 END-READ
 END-PERFORM.

What happens here if something "goes wrong with the file", something not quite 
bad enough to kill the program, but something bad enough to get a non-zero FILE 
STATUS?

You get a Big Fat Loop.

AT END and it's brother are "ephemeral". Beyond the END-READ they do not exist.

The point about a "priming read" is not so much that you have to have two 
READs, it is that you have two READs where there is a simple distinction (first 
vs not-first) which is highly useful and which doesn't bog-up your other plain 
ordinary file-processing logic. Empty file - is that OK? "Header processing"? 
Do you want to jam those into AT END/NOT AT END?

OK, you don't always need those - but does that drive you to having different 
constructs for processing a file? With the priming-read, the processing of a 
record is only entered - when there is a record. With the "read a record other 
than logically the last thing" there's always code to skip out "just in case" 
the end-of-file happens (it pretty much always happens, and potentially at 
least, always does happen).

Unfortunately I don't have time to read more now. I have to say that the 
religious jargon is entirely unknown to me, but I think if I just treat it as a 
"progression", I'll be on the right track? I'm not going to look up religious 
words on the internet for any nuance, just to be able to understand this better 
- so if there is more meaning to their use than "progression", please let me 
know :-)

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

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[John McKown]

On Thu, Aug 11, 2016 at 7:07 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> Because I apparently have nothing better to do I have written a probably
> too long document detailing why I believe that Enterprise COBOL should
> support an extension to COBOL to support a native syntax for unbounded
> loops.  See my document attached to the follow COBOL Cafe Forum post:
>
>
> https://www.ibm.com/developerworks/community/
> forums/html/topic?id=8cb11f10-03c9-4b82-9123-ba5ebc2240ff&ps=25
>
>
​First the complaint: Really, a MS Word docx file? I would request, in any
future such posting, that you use something more "agnostic". ​

​I like the syntax. The functionality is easy to emulate in normal IBM
Enterprise COBOL:

011410 01  WS-TRUE-FALSE   PIC X VALUE SPACE.
011420 88 WS-TRUE  VALUE SPACE.
011430 88 WS-FALSE VALUE ZERO.
011440 88 WS-FOREVER   VALUE ZERO.
011500 PROCEDURE DIVISION.
011510 START-UP.
011520 PERFORM UNTIL WS-FALSE
011530DISPLAY 'HELLO, SAILOR!' UPON SYSOUT
011531EXIT PERFORM
011540 END-PERFORM
011550 .
​

​WS-FALSE is always FALSE, so this is an unbounded. As you can see, I also
made a WS-FOREVER (which could have simply been FOREVER). I could also have
created a WS-EXIT. I have an "inbred" tendency to make Working Storage
"transient" variable names start with WS- (Linkage Section names start LS-,
Local Storage name start LCL-).​


-- 
Klein bottle for rent -- inquire within.

Maranatha! <><
John McKown

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

I use the Archive for posting, and the google groups web interface for viewing 
(having been informed that using the google groups for posting does not get 
those posts sent to the main list). Having seen some random Re: posts start a 
"new" topic, I have deliberately not been pre-pending a "Re: ".

I'm a little surprised that google groups (to my view of how it is presented) 
sorts this out and gmail, which Im fairly sure is also from google, does not :-)

I'm now pre-pending the "Re: " so if anyone can still see me dropping litter, 
please let me know.

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Elardus Engelbrecht]

Bill Woodger wrote:

>Thanks David, I only use the "google groups" access to the list, so didn't 
>know this was happening :-)

>Am I the only culprit? Wow. I feel like I've been littering in the break room.

No, you're not alone. It depends on what you and others are using to post 
something. For myself I use IBM-MAIN web-page to post something.

Others have 'AW:' or '[EXTERNAL]:' or similar things prefixed automatically in 
their e-mail headers. not much you can do, unless you can override it.

Groete / Greetings
Elardus Engelbrecht

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

Thanks David, I only use the "google groups" access to the list, so didn't know 
this was happening :-)

I even thought it funty (google Mr Gum and Billy William the Third) when 
sometimes there is a topic when some variant of re: appears in isolation.

Am I the only culprit? Wow. I feel like I've been littering in the break room.

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

Re: COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[David Crayford]

For some reason every time you reply to a post it spins off a new thread 
on my mail reader - gmail. It seems to be due to the fact that there is 
no Re: prefix in the subject line.



On 12/08/2016 2:09 PM, Bill Woodger wrote:

I may have to reply initially with a thesis on "Not using FILE STATUS considered 
harmful - and AT END even without NOT AT END is a worse pain" (I'll leave the 
sub-tiles for later).

  PROCESS-MY-FILE.
  PERFORM UNTIL EXIT
  READ MY-FILE
   INTO MY-RECORD
  AT END
  EXIT PERFORM
  NOT AT END
  PERFORM PROCESS-MY-RECORD
  END-READ
  END-PERFORM.

What happens here if something "goes wrong with the file", something not quite 
bad enough to kill the program, but something bad enough to get a non-zero FILE STATUS?

You get a Big Fat Loop.

AT END and it's brother are "ephemeral". Beyond the END-READ they do not exist.

The point about a "priming read" is not so much that you have to have two READs, it is 
that you have two READs where there is a simple distinction (first vs not-first) which is highly 
useful and which doesn't bog-up your other plain ordinary file-processing logic. Empty file - is 
that OK? "Header processing"? Do you want to jam those into AT END/NOT AT END?

OK, you don't always need those - but does that drive you to having different constructs for 
processing a file? With the priming-read, the processing of a record is only entered - when there 
is a record. With the "read a record other than logically the last thing" there's always 
code to skip out "just in case" the end-of-file happens (it pretty much always happens, 
and potentially at least, always does happen).

Unfortunately I don't have time to read more now. I have to say that the religious jargon is 
entirely unknown to me, but I think if I just treat it as a "progression", I'll be on the 
right track? I'm not going to look up religious words on the internet for any nuance, just to be 
able to understand this better - so if there is more meaning to their use than 
"progression", please let me know :-)

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


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

COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Bill Woodger]

I may have to reply initially with a thesis on "Not using FILE STATUS 
considered harmful - and AT END even without NOT AT END is a worse pain" (I'll 
leave the sub-tiles for later).

 PROCESS-MY-FILE.
 PERFORM UNTIL EXIT
 READ MY-FILE 
  INTO MY-RECORD
 AT END
 EXIT PERFORM
 NOT AT END
 PERFORM PROCESS-MY-RECORD
 END-READ
 END-PERFORM.

What happens here if something "goes wrong with the file", something not quite 
bad enough to kill the program, but something bad enough to get a non-zero FILE 
STATUS?

You get a Big Fat Loop.

AT END and it's brother are "ephemeral". Beyond the END-READ they do not exist. 

The point about a "priming read" is not so much that you have to have two 
READs, it is that you have two READs where there is a simple distinction (first 
vs not-first) which is highly useful and which doesn't bog-up your other plain 
ordinary file-processing logic. Empty file - is that OK? "Header processing"? 
Do you want to jam those into AT END/NOT AT END?

OK, you don't always need those - but does that drive you to having different 
constructs for processing a file? With the priming-read, the processing of a 
record is only entered - when there is a record. With the "read a record other 
than logically the last thing" there's always code to skip out "just in case" 
the end-of-file happens (it pretty much always happens, and potentially at 
least, always does happen).

Unfortunately I don't have time to read more now. I have to say that the 
religious jargon is entirely unknown to me, but I think if I just treat it as a 
"progression", I'll be on the right track? I'm not going to look up religious 
words on the internet for any nuance, just to be able to understand this better 
- so if there is more meaning to their use than "progression", please let me 
know :-)

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

COBOL Unbounded Loops: A Diatribe On Their Omission From the COBOL Standard (and a Plea for Understanding)

[Frank Swarbrick]

Because I apparently have nothing better to do I have written a probably too 
long document detailing why I believe that Enterprise COBOL should support an 
extension to COBOL to support a native syntax for unbounded loops.  See my 
document attached to the follow COBOL Cafe Forum post:


https://www.ibm.com/developerworks/community/forums/html/topic?id=8cb11f10-03c9-4b82-9123-ba5ebc2240ff&ps=25

Compiler Cafe:COBOL Cafe:COBOL Unbounded Loops: A Diatribe On Their Omission 
From the COBOL Standard (and a Plea for Understanding) - COBOL Cafe Forum 

www.ibm.com
developerWorks forums allow community members to ask and answer questions on 
technical topics. You can search forum titles, topics, open questions, and 
answered questions.  You can easily see the forums that you own, are a member 
of, and are following.



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