On 15/07/2022 13:35, Bruce Axtens wrote:
Straw poll time: fixed or free-form?
My contention is that new students of COBOL will more likely to end up in work environments where they are maintaining and extending existing code than where they are writing new code. The discipline of fixed form is indeed a burden but a necessary one
if we are to adequately prepare students for the real world.
I accept that there's no pleasing everyone. When it was just me running the cobol track, I could do what I wanted. Now there are others involved who have come in pursuing their own vision for the cobol track. I want to be able to give good reasons for
pursuing fixed-form even if my petition ultimately fails.
-- Bruce.
Hi Bruce,
I'm afraid I can't support your petition because I moved to free-form in
the 1980s with Fujitsu, when I switched from Micro Focus.
As far as I'm concerned there is no comparison between free and fixed
formats. Free is absolutely better.
Obviously, the majority of the COBOL still being used today is for IBM mainframes and they never had a free form facility, remaining entrenched
in the old Hollerith 80 column punched card format (as far as I know;
haven't worked in that environment since the mid 1980s... ). It's kind
of quaint really... :-)
Although I have not written a complete COBOL compiler, I have worked on modifying some (Burroughs and CDC), and for some of the migration tools
I developed in this century (transforming COBOL-85 to OO COBOL,
generating SQL in load modules and DAL objects for RDBs, etc.), it was necessary to parse COBOL source. Obviously, enforcing fixed-format makes
the parsing much easier, but it also makes the tool much less flexible.
For me, writing support for free format COBOL is a superset that also encompasses fixed-format code. If you can parse free format, the same
code will certainly parse fixed-format.
It really comes down to using modern string handling and regular
expressions to detect and analyze words (and symbols) among spaces. My
parser does have a list of COBOL reserved words which it loads into
memory when it is first invoked. (There are around 700 of them if I
remember correctly...).
In this day and age it seems a bit primitive to be stuck with fields
having to start in a specific position on an input form, when rich
capabilities exist in NON-COBOL languages to deal with strings,
serializing, converting to JSON or XML, parsing COBOL (or any other
Language) source or, indeed, ANY text containing keywords, using Regexes
and string manipulation libraries.
The tricky parts are where you come to continuations (which may or may
not conform to the COBOL rules for hyphens), and the old code that used comments beyond column 72 to document maintenance or similar, but these
are edge cases which are easily dealt with. I suck up input lines until
I have a complete COBOL construct in memory, then deal with it according
to the Keyword and context. (A "construct" is terminated by another
major Keyword or a full stop...) Writing this stuff is actually fun :-)
It is hard to make an argument that Free Format is too hard to support;
it simply isn't.
As far as training goes, there is no reason why they can't use the same
80 column card forms that we used in the 1960s. BUT, they can also be
aware that COBOL CAN be Free Format... Like I said, Free Format is a
"superset" of the old fixed format.
Any decent COBOL compiler SHOULD provide fixed AND free format support,
and any decent tool that has to work with COBOL should support BOTH modes.
Cheers,
Pete.
--
I used to write *COBOL*; now I can do *anything*...
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)