RE: [open-cobol-list] Small Cobol changes for MVS compatibility

[Bill Klein]

Some comments on this (and its relationship to what should and should not
happen when MVS compatibility is on versus what should happen when "ANSI"
('85 Standard) conformance is on.

See below: 

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of David Korn
> Sent: Sunday, November 14, 2004 11:26 PM
> To: address@hidden
> Cc: address@hidden; address@hidden
> Subject: [open-cobol-list] Small Cobol changes for MVS compatibility
> 
> 
> We found and made the following changes to OpenCobol to get code
> from MVS to compile on Linux. 
> 
> 1.    Lines like TITLE. 'string' are ignored by adding
>               "TITLE" |
>       after
>               "AUTHOR" |
>       in pplex.l.
> 

When TITLE (or anything else) appears after the Author PARAGRAPH header,
then it is treated as a COMMENT-ENTRY.  This is ANSI Standard (but is
OBSOLETE in the '85 Standard - and the '85 Standard requires an option for
OBSOLETE flagging.  I don't know if that is included yet).

The TITLE statement - which may appear ANYWHERE (including before the
Identification Division header) in all IBM COBOL's from VS COBOL II on, is
an extension (requiring extension flagging).  It "use" and syntax is
described at:

 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR20/8.1.20 

when MVS "compatibility" is turned on *AND* a "listing" is produced, that
page tells you what it should do.

NOTE WELL:
  IBM does have some extensions related to the comment-entries in the ID
Division. See:
 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR20/APPENDIX
1.1 

which says (in part),

"An optional separator period following PROGRAM-ID, AUTHOR, INSTALLATION,
DATE-WRITTEN, and SECURITY paragraph headers. [Standard COBOL 85 requires a
period   following each of these paragraph headers.]"

the "older" REMARKS paragraph is also "accepted" but that is only because it
is treated as a "comment-entry" to the other paragraphs.

Finally, there is a BIG difference (with IBM COBOL's) as to whether the word
"COPY" appears in the A-margin or the B-Margin within the Identification
Division.  If it appears in the A-margin, then it is treated as a COPY
statement - but if it appears in the B-margin it is treated as part of the
comment-entry.



> 2.    The IBM Compiler treats
>               COMPUTE X EQUAL ...
>       as
>               COMPUTE X '=' ...
>       so I changed
>               arithmetic_x_list '=' expr
>       to
>               arithmetic_x_list equal expr
>       and added
>               equal:  '=' | EQUAL;
>       to parser.y.
> 

Treating "equal" as synonymous with "=" in the COMPUTE statement as an IBM
extension (see reference above) and should be flagged when extension
flagging is turned on.

> 3.    The rule for COPY .. REPLACE was not correct.  Referring to
>       the IBM Cobol definition for the REPLACING clause we discovered
>       that IBM defines that  when evaluating pseudo-text leading and
>       trailing blanks are ignored (but not imbedded blanks).
> 
>       EXAMPLE:
>               COPY RBDK3736 REPLACING == S3736: == BY == W9810 ==.
>       where RBDK3736 contains,
>               05 S3736:-DTE-CRTE-FLE-MPS PIC 9(08).
>       results in
>               05  W9810 -DTE-CRTE-FLE-MPS PIC 9(08).
>       NOT
>               05  W9810-DTE-CRTE-FLE-MPS PIC 9(08).
> 
>       To fix this we changed the line
>               "=="                    { BEGIN PSEUDO_STATE; 
> return EQEQ; }
>               "=="                    { BEGIN COPY_STATE; 
> return EQEQ; }
>       in ppplex.l  to
>               "=="[ ]*                { BEGIN PSEUDO_STATE; 
> return EQEQ;
>               [ ]*"=="                { BEGIN COPY_STATE; 
> return EQEQ; }
> 

Treating an "embedded" space as a separator that MUST be copied is part of
the ANSI'85 Standard.  If OpenCOBOL wasn't doing this for all dialects, it
should.  However, it is important to remember that a single space matches
multiple spaces - as far as REPLACING goes.  It is also important to note
that a "comma" or a "period" is ONLY a separator (for replacing rules
specifying text-words) when followed be a space with is considered PART of
the original separator.  On the other hand, a "colon" or left or right
parenthesis is a separator for text-words - even if NOT followed by a space.

FYI, '85 Standard, page XII-3, GR(5b)
 "For purposes of matching, each occurrence of a separator comma,
semi-colon, or space in pseudo-text-l or in the library text is considered
to be a single space. Each sequence of one or more space separators is
considered to be a single space."

then on page XII-5, GR(10) states,
  "When copying text words of pseudo-text-2 into the source program,
additional spaces may be introduced only between text words where there
already exists a space (including the assumed space between source lines)."

  ***

Let me know if you need any additional information on any of these comments.

> 
> Let me know whether these changes or ok.
> 
> David Korn
> address@hidden
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>