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 [email protected] with the message: INFO IBM-MAIN
