bug-gnucobol
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-GnuCOBOL] Support for


From: Michael Potter
Subject: Re: [Bug-GnuCOBOL] Support for
Date: Mon, 2 Jul 2018 18:58:49 -0400

I am going to write a quick and dirty preprocessor to drop the "DATE FORMAT YY" thing and get the code to compile.

Just thinking about it....

I would suspect that in order for this to work the option has to affect if statements that are comparing dates:

that is:
05  X-YEAR   PIC X(2)  DATE FORMAT YY VALUE '95'.
05  Y-YEAR   PIC X(2)  DATE FORMAT YY VALUE '10'.

If   X-YEAR < Y-YEAR
then
   display 'year 95 is before year 10'
else
   display 'year 10 is before year 95'
end-if

I would expect that if this option is actually doing something useful we would see:

year 95 is before year 10

The trick to finding those in code is what happens on group level compares.






On Mon, Jul 2, 2018 at 5:42 PM Simon Sobisch <address@hidden> wrote:

Am 02.07.2018 um 21:04 schrieb Michael Potter:
>
> I have the following code that originated on an IBM mainframe:
>
>        CBL DATEPROC(FLAG),YEARWINDOW(-90)
>        ID DIVISION.
>        PROGRAM-ID.   SOMEPROG.
> ...
>        01  X-CURRENT-DATE-68.
>            05  X-MONTH                 PIC X(2).
>            05  FILLER                  PIC X VALUE '/'.
>            05  X-DAY1                  PIC X(2).
>            05  FILLER                  PIC X VALUE '/'.
>            05  X-YEAR                  PIC X(2)  DATE FORMAT YY.
>
> GnuCOBOL gives this compile message on the X-YEAR line:
>
> SOMEPROG.cbl: 31: error: syntax error, unexpected DATE, expecting
> EXTERNAL or EXTERNAL-FORM or GLOBAL or IDENTIFIED
> SOMEPROG.cbl: 31: error: 'FORMAT' is a reserved word, but isn't supported
>
> What are my options to get this to compile cleanly ...

The second easiest option is to simply drop the "DATE FORMAT YY" part.
This is something a preprocessor can easily do.
The easiest option to get a clean compile is hacking GnuCOBOL to accept
and flag this option as "ignored". I could do this within a day and it
is likely a good thing in general.

Any opinions about doing this?

> ...and run with the same effect as what it ran on the mainframe?


That is the most interesting point.

As long as the program actually using only "windowed" dates (which
assumes "19" for all 90-99 values and "20" for anything else) ignoring
this option doesn't lead to any issues.
But the reason that "millennium language extensions" were used in the
code is likely that this isn't the case (*or* the code was just
"flagged" this way for later inspection).

Note: IBM actually says on
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/concepts/cpmle31.htm:

> The windowing feature is **not intended** for long-term use. It can
extend the useful life of applications as a **start** toward a long-term
solution that can be *implemented later*.

Therefore I'd really suggest to inspect the usages of the referenced
fields and change the dates to "expanded date fields".

>
> I have 3,574 occurrences of this error in the code.
>
> I can write a script to make automated changes to the code.
>
> I would consider sponsoring an update to GnuCOBOL to handle this syntax.
>
> IBM has some documentation here:
> https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/ref/rlddemle.htm
>

Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]