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 <[email protected]> on behalf of Bill Woodger <[email protected]> Sent: Friday, August 12, 2016 3:15 PM To: [email protected] 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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
