Re: IBM Compilers (was RE: gnubol: How do we parse this language,anyway?

[RKRayhawk@aol.com]

In a message dated 12/4/99 4:17:11 PM EST, wmklein@ix.netcom.com writes:

<< 
 A big note needs to be made here about the *OLD* OS/VS COBOL and DOS/VS COBOL
 compilers.  These products are '74 compilers that have been out of service
 for a LONG time now.  UNFORTUNATELY, there is still a relatively big code
 base out there that still uses them.  Also, unfortunately, these compilers
 have an INCREDIBLY large number of "undocumented extensions" (code that
 works, that programs rely on, but that IBM doesn't/never did support).  I
 can't recommend strongly enough to NOT get into the business of trying to
 support these.  The good news (at least for the conditional statement
 question) is that they support NONE of the '85 Standard "enhancements".
 
   ***
 
 Does this help?
 
 Bill Klein
   wmklein <at> ix.netcom.com>
  >>


Bill's breadth of knowledge is definitely awesome. As a footnote let me say 
that 'though the COBOL '74 product did not have the COBOL '85 things, the 
product had vendor extensions. 
Regrettably it included some NOT alternatives to conditional clauses. The 
regress parm in later compilers would the later compilers to see that stuff 
the 'old' way. Early versions of these later compilers were not actually 
COBOL '85; and when you left the regress parm off, as far as I understand, 
the NOT clauses died (if present anyway). Leap froggers never saw this: most 
shops were leap froggers. Later compilers had COBOL '85 syntax support for 
NOT alternatives. Leap froggers met a number of collision points when 
ultimately moving to the later compilers because numerous IBM extensions did 
not get further support. But if they did not go through the early version 
un-regressed, potentially they never knew the old NOTs would be different 
from the new NOTs.

I am confident that any old NOTs changed semantically at a point prior to 
this GNU project if the code went to new compilers unregressed. There are 
probably few. But the general phenomenon of the smaller vendor mimmicking the 
larger vendor probably suggest that some of the mainframe COBOL '74 code, 
which insists upon surviving, may actually have artifacts of this shell game. 
The fact that by the very nature of the language elements we are interested 
in here, we are dealing typically with exceptions within exceptions, there 
are probably few problems.

Depending upon our decision we may have some MF code port over and change to 
either an error or a changed semantic. If mainframe stuff arrives on this 
tool with any of its probably few incidents of this, it might well have gone 
through a flip-flop already.

Let me pull a quote out of context here to get to a slightly different angle

Again from William M. Klein
<<
NOTE: These compilers (as well as VS COBOL II) can be run with the CMPR2
compiler option.  I would suggest NOT testing with that (even though some
sites still use it) because this put the compiler in ANS'74 mode - instead of
ANS'85 mode. (This isn't its official definition, but BASICALLY is what it
does.)
>>

I do agree with his point, it is the un-regressed behavior of the compilers 
that is more important for our decision (although using them in regressed 
mode might reveal what the original NOTs did).  But for the sake of clarity. 
Some of the multi-mode compilers survive as supported products into the next 
millenium, ... for a while. A few people believe that a shop trying that is 
about to contribute to a major expansion of demand for techincal laborers. 
But the presence of code in that form is important. This project might 
deliver something in 2000, and some code on mainframe might actually still be 
the 'extended' COBOL '74 (by measn of a regressed compilation on a later 
product). I don't think that argues for any difference in our decision on the 
semantics of the nested conditionals; we just need to be able to help people 
understand what is happening to them if they move to this compiler from that 
older mainframe compilers ... then we become the lilly pad that the toads 
leap to. Which is okay as long as they know what is happening.  The incidence 
of the NOT clauses is probably small, and there can be much bigger code 
changes to make if these shops got into other vendor extensions, so the worst 
case senarios actually involve major code review requirements to come across.

But one small point that may help clarify this, and I ask for broad comment 
if there are those who see it clearly in their documentation.  I am not sure 
that all the COBOL for this-and-that
products allow the regress parm (COMPR2/NOCMPR2). There may be a clear end 
date for support of the set of products that can regress (if the regress 
feature is not in all of the really current compilers).

Bob Rayhawk

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.