RE: [open-cobol-list] Re: OC issues - number 4

[Bill Klein]

In order to support CR or CRLF within alphanumeric literals, there must be
NO lines alphanumeric literals and "line end" before the R-margin.

In such cases, you would "assume" that an opening quotation mark without a
closing quotation mark before the R-margin is ALWAYS a "continued" line.  An
error message would be issued with no continuation mark in column 7 of the
next line (and an opening quotation mark as the first non-blank charcter).

The CR would count as "one byte of data" within the literal.

If you had something like

   Value " ~ ".  *> where the "~" was a CR or CRLF

then this would be a SINGLE line of data and the line would "end" with the
CRLF *after* the closing quotation mark.

  ***

How much in "demand" this would be on the workstation or in OC, I don't know
- but it is what the '85 Standard requires.

NOTE:
  With the '02 Standard and as a "common extension" before that), one can
code

   X"0A"   *> or equivalent hex-literal

but this IS not valid in the '85 Standard.

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of Roger While
> Sent: Friday, January 20, 2006 4:59 AM
> To: Bill Klein
> Cc: address@hidden; address@hidden
> Subject: RE: [open-cobol-list] Re: OC issues - number 4
> 
> Yes, A, B and C sound OK.
> Working on a fix for this. (To column 72)
> I don't think D is possible. How would you code it
> in the source ?
> 
> Roger
> 
> >I think that the way I would suggest this be solved is:
> >
> >A) "define" where the R-margin is (probably after column 72 
> or after column
> >80 - each is used by some existing compilers)
> >
> >B) If a LF (CRLF, whatever) appears OUTSIDE an alphanumeric 
> literal, then
> >just treat it as the "end of source line".
> >
> >C) If a LF (CRLF, whatever) appears "within" an alphanumeric 
> literal, then
> >"logically" pad the line with enough spaces to the R-Margin.
> >
> >D) There should be a compile-time (maybe run-time?) switch 
> to allow ANSI
> >conforming behavior where a CR or  LF *within* an 
> alphanumeric literal is
> >treated as DATA.  (This should be for "fixed form reference 
> format" only).
> >
> >   ***
> >
> >Does this sound reasonable? Possible?
> >
> > > -----Original Message-----
> > > From: address@hidden
> > > [mailto:address@hidden On
> > > Behalf Of Sergey Kashyrin
> > > Sent: Thursday, January 19, 2006 7:24 PM
> > > To: Roger While
> > > Cc: address@hidden
> > > Subject: [open-cobol-list] Re: OC issues - number 4
> > >
> > > Roger,
> > >
> > > I've checked on OMVS subsystem on Mainframe (where the cobol
> > > source is not in a RECFM=F RECLEN=80)
> > > but the same format as on any unix (LF separated lines),
> > > and the test passed even there are no spaces at the end !
> > > It also passed on Microfocus and Fujitsu (not free format !)
> > >
> > > It seems to me that if "fixed" format for Cobol is used,
> > > compiler is padding with / assuming spaces up to 72-nd
> > > position anyway.
> > >
> > > So I suspect OC is wrong in this case.
> > > Once again, I'm noway a Cobol guru and don't know those
> > > details. Are there any formal descriptions of the rules ?
> > >
> > > BTW I might think to try to put OC on mainframe but currently
> > > libgmp is holding.
> > >
> > > Regards,
> > > Sergey
> > >
> > >
> > > ----- Original Message -----
> > > From: "Sergey Kashyrin" <address@hidden>
> > > To: "Roger While" <address@hidden>
> > > Cc: <address@hidden>
> > > Sent: Wednesday, January 18, 2006 3:23 PM
> > > Subject: [open-cobol-list] Re: OC issues - number 4
> > >
> > >
> > > > Roger,
> > > >
> > > > Yes, adding spaces helps.
> > > > Initially it's a mainframe programs and mainframe has a
> > > fixed record format, so original program has those spaces.
> > > > They've probably been stripped when transfering from mainframe.
> > > > But as a matter of fact both Fujitsu and Microfocus are
> > > accepting that.
> > > >
> > > > Regards,
> > > > Sergey.
> > > >
> > > > ----- Original Message -----
> > > > From: "Roger While" <address@hidden>
> > > > To: <address@hidden>
> > > > Cc: <address@hidden>
> > > > Sent: Wednesday, January 18, 2006 2:37 PM
> > > > Subject: Re: OC issues - number 4
> > > >
> > > >
> > > >> Let me guess - The line with the VALUE is immediately
> > > >> terminated after the apostrophe with a new-line
> > > >> and/or the following line is also terminated with a new-line
> > > >> immediately after the apostrophe.
> > > >> (At least BOTH are true when doing copy/paste from the post).
> > > >>
> > > >> This is then invalid.
> > > >> ie. The apostrophes would concatanate and be interpreted as
> > > >> one occurrence as per Cobol rules.
> > > >>
> > > >> Roger
> > > >>
> > > >>
> > > >>        IDENTIFICATION DIVISION.
> > > >>        PROGRAM-ID. ztest INITIAL.
> > > >>        ENVIRONMENT DIVISION.
> > > >>        DATA DIVISION.
> > > >>        WORKING-STORAGE SECTION.
> > > >>        01 A.
> > > >>                10  FILLER              PIC X(78) VALUE '
> > > >>       -        '
> > > >>       -        '      '.
> > > >>        PROCEDURE DIVISION.
> > > >>            DISPLAY 'A=' A ';'.
> > > >>            GOBACK.
> > > >>
> > > >>
> > > >> Roger
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep 
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  
> DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&;
> dat=121642
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>