[open-cobol-list] COBOL, literals, tabs, and other special characters

[Bill Klein]

(Follow-on to another thread),
  I just thought that I would talk a little about using tabs (LF, CR, and
other "special" characters) within COBOL literals.

Up thru the '85 Standard, "official" COBOL *only* knew about "fixed length"
source lines.  (Often with the end of the B-margin being at column 72 - but
this wasn't required - and some/most compilers allowed for "stuff" in
columns 73-80 of an 80-byte card image line).

This meant that having tabs, CR, LF or "any old junk" within a COBOL
alphanumeric literal caused (in theory) NO problem.  If it was after an
opening quote mark and before column 72 (or the R-margin - wherever that
was) then it was "data and part of the literal".

When Unix, PC, and other "similar" systems started using text editors with
"line sequential type" data including COBOL source code, this became a
problem. All (that I know) of PC and Unix compilers that CLAIM to conform to
the '85 Standard have some (usually NOT default) compiler option that will
"ignore" the natural CR/LF type method of ending COBOL source code but will
actually process 80-byte (or 72-byte or whatever "fixed" length) source code
line that is specified.  When running in this "mode" one can still (easily)
have tabs, CR, LF, etc within alphanumeric literals.  However, there are NO
"native" text editors that can work with such files. (Most - not all -
compilers that support this option also provide an editor that understands
such lines.)

The next "development" with COBOL source code was the introduction of "free
form" source code.  In its simplest (PC or Unix) variations, this simply
treats a COBOL source line as everything between the "begging of the line"
and the CR/LF (or other O/S line sequential termination sequence).  For some
such compilers column 7 was still the "magical" continuation (and debug and
page eject) column - while in others this was moved to column 1 and to still
others, you could use either of these. 

HOWEVER, with these compilers trying to include tab, CR, LF, etc characters
within alphanumeric literals simply did not (does not) work.  

The next "enhancements" were the introduction of "hex-literal" format
alphanumeric literals. This would allow you to specify X"05" X"0A" etc for
some of these "special" characters without running into "line sequential"
limitations.

With the other "enhancement" of literal concatenation, this solved many
problems, e.g.
   "ABC" & X"05" & "XYZ"
would be treated (mostly) like a single alphanumeric literal with a tab in
the middle.

However, there are some (obscure) rules about COPY/REPLACING REPLACE that
made this NOT the final answer.

At the same time, a "better" free form reference format was introduced in
the '02 Standard.  Two things are different with this:
  1) There is a new alphanumeric literal continuation method so that instead
of:
        "ABC
     -  "XYZ"  *> with the dash in column 7
 you can now code (in fixed or free form reference format)
        "ABC"-
        "XYZ"
and not have to worry about either the R-margin or column 7.

  2)  In the '02 Standard for free form reference format (BUT NOT FOR FIXED
Form Reference Format) the implementer is allowed to PROHIBIT certain
characters (such as tab, cr, lf) from being legal in alphanumeric literals.

   * * * *

It is worth noting that some (not all) PC/Unix COBOL compilers have a
compile-time option/switch that controls the handling of tabs within source
code.  This is usually separate from other options for handling tabs within
line sequential files on I/O (sometimes different options for Read than
Write)

   * * * * *

I don't know who (if anyone) cares about any/all of this, but I did think a
"bit of history" would show that this IS an issue that both the Standard and
various vendors have dealt with - and not all in the same way!!!