gnubol: Re: FW: RCF - SC26-9046-03 - LRM (Special-Names format error)

[x@wins.uva.nl]

Dear Bill,

I've seen your message on the GNU list.  I am still in theprocess of
trying to reproduce the error that I remembered from thepast.  I did
some renovation project, and of course in the preprocessor i wiped out
all the ARE/IS and more stuff.  After that, the preprocessor was adapted
to have more options for wiping out such issues less rigorously.  Still I
remember that when the code was tested on the new platform, that there was
an ARE missing in the SYMBOLIC CHARACTERS clause.  Here's what I've done:

 * tried to find the code
 * composed an example and asked various ppl to compile it on their
   mainframes
 * compile examples myself.

Sofar, I have not yet found the example (it was trivial to add the
ARE, and I forgot about the entire thing until the GNU discussion
triggered it).  I've found a few SYMBOLICs in my database of code,
but it doesnt ring a bell.  Maybe the target compiler was a VS COBOL II
compiler, and a friend of mine is now checking whether this compiler can
be recovered from tape.  This will take some time.  When compiling on
various machines I found out that indeed you can remove it.  It does
compile without IS/ARE using the Cobol/390 compiler I just heard.
And its also not there in the manual.  See p 90 (SC26-9046-03).

I missed the  page XVII-43, Item 22.  Very good of you!  Thanks!
Since my focus is not so much standards, but more products (I only
deal with exisiting source code), I sometimes look at the standard,
but not often.  I guess that from a developers point of view it makes
sense to adhere as much as possible to it.  Of course, when there is
nothing available other than the standard (think of CHILL) I use such
documents to recover grammars from.

About your readers comment form [for theother readers: Bill mailed this
error inthe manual to IBM].  I never send them emails, because I do not
like their statement:

    In sending information to IBM, you grant IBM a non-exclusive
    right to use or distribute the information in any way it believes
    appropriate without incurring any obligation to you.

And because I had to send them emails every day.

The same error is copied in the COBOL/390 manual.  The more serious
error in that diagram is that the ordering of the clauses is immaterial.
Im not sure whether this is in the standard, but its in the products
i know.  Maybe they inform the reader about this issue somewhere inthe
accompanying text.  Anyways, in our generated diagrams we use the double
|| to express this.  Or in the BNF:  a||b means a b | b a.

Here's a diagram that is in accord with compiling source code:

special-names-paragraph-clauses

 _______________________________________________________ 
|                                                       |
| >>_________________________________________________>< |
|     ||  |  <__________________   |             ||     |
|     ||  |____alphabet-clause__|__|             ||     |
|     ||_________________________________________||     |
|     ||  |  <_____________________________   |  ||     |
|     ||  |____symbolic-characters-clause__|__|  ||     |
|     ||_________________________________________||     |
|     ||  |  <_______________   |                ||     |
|     ||  |____class-clause__|__|                ||     |
|     ||_________________________________________||     |
|     ||  |__currency-sign-clause__|             ||     |
|     ||_________________________________________||     |
|         |__decimal-point-clause__|                    |
|_______________________________________________________|

we put the defintiions of the various sorts in a few diagrams for
clarity's sake.  We will repair the ARE|IS issue in the grammar browser
as soon as I hear about the real behaviour of the VS COBOL II compiler.
So thanks!

Related issues with IS:

I found some notes on IS.  Maybe they are helpful.

A = B OR IS C AND IS D

accepted by OS/VS COBOL but not by VS COBOL II.

Non native speakers:

some people write NOT IS on locations where IS NOT is assumed.  OS/VS COBOL
removes IS inthe lexical phase, so no worries there, but as soon as his is
migrated to MF COBOL the code breaks down.

as a side remark on non native speakers and interaction with
preprocessors: GREATER THEN is often used in COBOL programs. reason
that this parses: THEN is lexxed out.  THAN is optional, so it parses.
What about that?  :) Since we are not generating object code, but
generating renovated source code again, we have to deal with all these
kinds of issues.  We have to be able to parse them, and only when the
customer wants it, we change such code.  Often this is not the case.

So cases like Matthew Vanecek assume that can happen, do happen (WHEN ->
IS in EVALUATE).  Mostly not on purpose, but since people are not fluent
in English.

  --XX

I saw a dragon in the toilet.
And it kissed me.
And the next day i saw him again.
The end.


--
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.