[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] Re: bug: reserved word list differ from language l
From: |
Thomas Biehler |
Subject: |
Re: [open-cobol-list] Re: bug: reserved word list differ from language level specification |
Date: |
Mon Nov 10 09:58:03 2003 |
User-agent: |
KMail/1.4.3 |
On Friday 07 November 2003 23:16, Keisuke Nishida wrote:
> At Tue, 4 Nov 2003 11:50:57 +0100,
>
> Thomas Biehler wrote:
> > resword.cob:6: `FORMAT' reserved word, but not supported yet
> >
> > But "FORMAT" is reserved word in COBOL - 2002 Standard only.
>
> Right. We need to change the list of reserved words depending on
> the standard to use. For the moment, please remove the word from
> cobc/reserved.c for your convenience.
>
> Keisuke
>
Hi Keisuke,
thank's.
I have only two cases. ("FORMAT" and "OBJECT").
The work around solution is sufficing for me.
(I have had the same idea as you)
What do you think about inserting this (commited) bug
in the tracking system? (with low priority)
I think supporting some popular cobol-dialect's
would need a good concept for the necessary changes.
So a good solution needs time!
(a good concept, Compiler-Flag's, Configuration files ...)
The MF-COBOL - Compiler has some compiler-flags to
manipulate the reserved-word list at compilation time.
You can add reserved word's , delete reserved word's, make
reserved word's synonm ...
I have used this MF-COBOL feature for "COMP ==> COMP-5".
(Port: Power-PC --> Intel : Binary Big-Endian -> Little-Endian)
("Binary: "BIG-ENDIAN" / "NATIVE" is the open-cobol solution)
It has solved a well kown (Cobol) problem without any
programm changes! (very flexible!)
(Both platform's are further parallel in use !
= and only one version of sources / copy's is needed!)
I think such a feature would be usefull if you would port
from many plattform's (compiler) to open-cobol.
(I don't know how Micro-Focus has implemented this feature!)
But this is not feature request from me now!
My intention was only to show that a good
concept is (more) important than a fast solution!
thank's again and bye
Thomas