Re: gnubol: IBM flags nested conditionals as error (RC=8) butrecovers OK

[RKRayhawk@aol.com]

In a message dated 12/6/99 8:29:16 AM EST, TIMJOSLING@prodigy.net writes:

<< 00007                procedure division.
    000008                p1.
    000009                    add 1 to
 a                                                             5
    000010                       size error
    000011      1                   display 'size error 1'
    000012      1                   add 1 to
 b                                                       6
    000013      1                not size error
    000014      2                   display "not size error 2"
    000015      2             .
    000016                    display "end program".
    000017                    exit program.
    000018
 
      12  IGYPS2112-E   The "ADD" verb did not have a matching scope 
terminator.
 A scope terminator was inserted on line 16.  The
                      execution results may not be correct.
  >>


Tim, thanks for testing in a manner that includes the long draggons AND the 
simple two deep cases.   In the quoted portion of your simpler test case, we 
can see the insertion point, by the line numbers; but what do you recon that 
means for the bind point issue?  Did the NOT ON SIZE ERROR bind in or bind 
out? The bind point would however be of interest only under the most unusual 
circumstances!

This is obviously a powerful parsing algorithm. No signs of laziness here.

Because of the insertion point the diagnostic claims one assumes the inner 
clause is binding inward. 

For the sake of those not familiar with the IBM mainframe environments let me 
highlight two parts of Tim's post. In the title he notes RC=8, and the 
message tag itself contains a dash-E;
" IGYPS2112-E ....". 

To the programmer then this is not a successful compile.  The compiler does 
'recover' successfully as Tim points out.  So this is not a display of a tool 
providing an 'extension'.
(life is complex though, there might be ways to get the compiler to notgo to 
such a high error diagnostic level on this).

Nearly every shop would outlaw a level 8 RC going to production. So in a 
sense this code would be unlikely to see execution. As the verbage in the 
message suggests, the compiler may well be going through code generation 
anyway. Which looks vaguely like the general idea I suggest that even when we 
find outright errors in code we should flip commutable error switches but 
still hand semantics as much as we can so that it can do it's checking too 
(to get as much from each compile as possible). 

Yet the mainframe product vendor's motivation is probably broader than that.  
In addition to possibly, under coersive parms, handling this as an 
'extension' they may wish to allow folks to force code into execution 
generally, no matter what diagnostics occur (actually Severe error can simply 
halt the compiler in some cases). That is actually a different kind of 
requirement. I don't think that we need to be able to do that. The IBM 
products are aggressive because some of their customers just won't listen to 
reason.

This is just one sampling, but I think it is indicating to _not_ _accept_ the 
inner conditional. It is simply indicating a compiler that stays on its feet.

This example clearly demonstrates that I was wrong in many of my posts on 
this subject. The statements are not being accepted by IGYCRTL et al. Where 
they bind is not important (that would, apparently, only be relevant to 
forced execution).

There has been other comments about the earlier IBM products not having NOT 
variations on conditional clauses. That clarification further weakens a need 
for any kind of extension here and actually isolates the Micro Focus 
extension (in the sense that apparently it was not mimickery of a any 
mainframe compiler behaviour). Thus that looks like a contained portion of 
the code base. It is not that either vendor is more important. It is just 
that we do not have multiple segments of the code base accepting these things 
and displaying different semantics.

Tim would be the one to further clarify the parametric environment, and 
whether any further exercise would be needed in that sense. But I think this 
is showing a normal compiler run rejects the nested condtional, on this 
vendor's product. Thus here atleast, we do not have a code base that 
motivates accepting the syntax. But we certainly do see competitive 
robustness in the parser. (It is not only on its feet, but it is describing 
the insertion point for the phantom implicit termination).

Thanks for the follow through Tim, and others who have tested these.

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.