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.

Hello Bruce!

Friday July 15 2022 02:35, Bruce Axtens wrote to All:

> 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.

Good programming is all about flexability - if for nothing else to reduce
un-necessary changes - SO

Support all three formats !

Vincent

On Thu, 14 Jul 2022 18:35:11 -0700 (PDT), Bruce Axtens <bruce.axtens@gmail.com> 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.

Teaching fixed format more or less forces readable indentation etc. Free format allows for statements with long variable names or
with references to be on a single line. It also allows for worse readability.

Having said that: Maintainable code is much more than fixed or free format, it has to do with properly naming variables and.or
paragraph/section names.

So: there is no "best" or right vs wrong. I would personally not go past the line length which the editor used would show, I'd want
the lines in full view, whether, 80, 132, 300 or whatever line length. When using ISPF the "standard" might be less than when using
Visual Code. Screen windowing or line wrapping don't make thngs easier.

Teach proper coding and naming conventions - much more important than line length.

On Saturday, 16 July 2022 at 10:03:28 pm UTC+8, Joe wrote:
> Teach proper coding and naming conventions - much more important than line length.

That's a very helpful comment. Thank you.

-- Bruce

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*...

Hello Bruce!

Friday July 15 2022 02:35, Bruce Axtens wrote to All:

> 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.

Had a chance to re-read your post and have to totally disagree with your
comments regarding Fixed format program training.

Other than programs on IBM kit that mostly still use fixed format and that
is more of having to use PDS, PDSE storage which is usually fixed format
all other compilers such as Micro Focus and GNU (cobol) use all including
free and variable (basically same as free).

Every program I have written, updated migrated over has been in Free format
- it is so much easier to write and follow which is more important when
having to do any code updates.

I have only one program that has remained in fixed format and that is a
decision table processor but only because no one has asked for it to be so
or allow to work with free format.

I have to assume it has very few users :)

As I use it rarely as modern programming style removes the need for it.

While there is a large percentage of Cobol code still running on mainframes
there is a lot new applications written in MF and GNU Cobol today and I
know I have in excess of 1 million lines of code as free format (no I have
not counted it all) but there is a large number of sites and programmers
using the later around the world as it is a free compiler as issued under
the FSF (Free Software Foundation).

> 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.

You have to remember that the only reason for fixed format which was
created because the input form was for 80 column punched cards from the 60
- 80's. Heck even for paper tape input it would support all formats.

For modern IBM Cobol compilers they also support extended for which allows
252 characters where cc8 extends Area B to cc 252.

There may be compilers that fully support the free format as I have not
checked all all of the available compilers for zOS not what are available
for *nix (or Linux) under zOS.

Yes, your petition must therefore fail.

Vincent

On Thu, 28 Jul 2022 13:12:58 +0100, "Vincent Coen" <VBCoen@gmail.com> wrote:

>For modern IBM Cobol compilers they also support extended for which allows
>252 characters where cc8 extends Area B to cc 252.
>
>There may be compilers that fully support the free format as I have not
>checked all all of the available compilers for zOS not what are available
>for *nix (or Linux) under zOS.
>
>
>Yes, your petition must therefore fail.
>
>Vincent
>
I checked the Enterprise Cobol 6.4 z/OS 2022 manuals, I have not been able to find anything to suggest other than 80 max length. The
SRCFORMAT(EXTEND) is not available.

Hello Joe!

Saturday July 30 2022 10:05, Joe wrote to All:

> On Thu, 28 Jul 2022 13:12:58 +0100, "Vincent Coen" <VBCoen@gmail.com>
> wrote:

>> For modern IBM Cobol compilers they also support extended for which
>> allows 252 characters where cc8 extends Area B to cc 252.
>>
>> There may be compilers that fully support the free format as I have
>> not checked all all of the available compilers for zOS not what are
>> available for *nix (or Linux) under zOS.
>>
>>
>> Yes, your petition must therefore fail.
>>
>> Vincent
>>
> I checked the Enterprise Cobol 6.4 z/OS 2022 manuals, I have not been
> able to find anything to suggest other than 80 max length.
> The SRCFORMAT(EXTEND) is not available.

I verified the information having gone on to the IBM documentation website
and looked at a current compiler but I have now forgotten the exact version
and type but it might not have been a 'Enterprise' version.

The extended format was clearly specified and shown but I did not check
out what CDF or other, steering line is required to activate it.

.. Just had another look and found
SC28-3117-00 IBM COBOL for Linux on x86 1.1

I have not looked further.

As more and more Cobol programming is carried out on micro based platforms
I will stand by my comments regarding Free format is more common now as
many compilers if not most, support that format and most programmers I know
(ditto sites) use it as standard. It is a lot easier to use and allows you
to indent as long as you want although that said I personally limit it to
130 chars but it is not cast in stone as my editor will go to 255 chars but
my screen and eyes is happier with below 150 and my indents are 6, 15 and
then by 9 onwards.

Vincent