Atomic Golf COBOL (IBM Enterprise COBOL)

Question

Just to make it clear, Atomic Golf COBOL will not be a competitive golfing language. The longer the shortest answer (80+, the longer the better) the more possible to get close, however, COBOL is very largely hand-coded (little "magic" available). Over the last four months, there are two questions I was considering for the introduction of AG COBOL. Then a short answer came in on one of those.

COBOL traditionally has fixed-length source records. I want to use standard features of IBM Enterprise COBOL to allow actual source (before the compiler sees it) to be variable in length.

Enterprise COBOL allows for specifying abbreviations for language elements. I want to use those abbreviations, and use different abbreviations for the same element where necessary.

Enterprise COBOL allows a new set of default compiler options to be established.

For all of the above, the Golfed COBOL program will be compiled in an identical manner to any ordinary COBOL program. The method of compile is unchanged, the stat

Can I make use of these supported and documented features for Code Golf in COBOL without penalty for using them.

An example:

A B 10 C

This is a line of code, not a program. It says PERFORM a-paragraph-of-this-name 10 TIMES.

My source will be A B 10 C followed by a newline.

My compiler exit will read that source line, and put it in column 8 of a fixed-length 80-byte area, and return that as a source line to the compiler.

The compiler will then process the abbreviations, and treat the line as:

PERFORM B 10 TIMES

The compile listing of the source will be the A B 10 C, the compile listing relating to the processed code will know only about the PERFORM B 10 TIMES, due to the translation of the abbreviations.

The is some amount of work to set this up, probably more to document it (so others can use/verify it).

I don't want to do all that if someone just comes along and says "ah, but, you've got a 30-thousand character 'file' the compiler is using, you have to count that as well".

It is all standard Enterprise COBOL stuff, used for the purpose intended (to allow different names for language elements, to allow different default options, to allow programmatic preparation of source files), just so happens that if I apply it all I've got COBOL as a, somewhat limited, golfing language.

If it is "no", I want to know before doing it, rather than after :-)

---

I've been thinking of this for a while. Something of it first saw the light of day in a LinkedIn discussion in October 2012, but I've been thinking about it for a while to win that one-off bet and retire on the proceeds (COBOL beats some-other-language at shortness).

Before crossing the Is and dotting the Ts and actually doing the whole thing, I'd like to know if it would be valid in its entirety, or in any part or parts.

1. Compile Options

Default compiler options are defined in a file. I can change (a copy) of the defaults, and so never have to specify compile options.

So not extra count for compile options, yes?

2. Abbreviations

Enterprise COBOL supports abbreviations of language elements (see here for an example and some explanation, https://codegolf.stackexchange.com/a/31640/16411).

Using abbreviations customised for a particular task I can get Golf to a minimum lengths - with a "standard" Golf table, I'd lose out if a task required something that didn't fit in one character, even though there may be "spare" one-character values available.

So, specifying abbreviations for each task is OK, yes?

3. COBOL has fixed-length lines of 80 characters (uses punched cards, so no messing possible).

I want to mess with that (time that old card-reader went anyway, we can always emulate it).

Enterprise COBOL supports a few compiler "exits" (source lines, output, errors messages, like that). This means I can take a "source" and format it to what COBOL expects.

The compiler exits can be written in COBOL. I can read a file of variable-length records and "format" the source to that required for the compiler itself.

This way, there is an "overhead" to each line, which is an extra four bytes (supplied by the IO system). Would this overhead be counted in the length? It would be the equivalent of the newline at the end of a line.

If it is, I could try to use HFS (Hierarchical File System) which is a unix-style file system. I'm not sure I have authority to "mount" HFS, if not, would a Proof of Concept for the method be OK: working compiler exit; code compiling for HFS under Enterprise COBOL; same code compiled under GNU COBOL and running stand-alone under Linux?

As well as the extreme, but valid, application of what the compiler supports, I will of course abuse the compiler with the code, but that's the nature of Golf, isn't it?

Here's an example program, extracted from the compile listing (some formatting applied):

PP 5655-S71 IBM Enterprise COBOL for z/OS  4.1.0               CBLNAM01
  LineID  PL SL  ----+-*A-1-B--+----2----+----3----+----4----+----5----
  000001                A B C"Hello, World!" 

==000001==> IGYPS0001-W A blank was missing before character """ in 
                        column 13.  A blank was assumed. 

==000001==> IGYPS2145-E A period was required.  A period was assumed 
before "E". 

==000001==> IGYSC1082-E A period was required.  A period was assumed 
before "END OF PROGRAM". 

 Count   Cross-reference of verbs        References 

1        STOP . . . . . . . . . . . . .  1 

The only verb used in the program is STOP (abbreviated to C) and the listing shows reference to the unabbreviated verb. A B is an abbreviation of two words, PROCEDURE and DIVISION.

The program crashes after producing the literal (on the Operator's console, so don't try this at home).

20 Characters, instead of counting as 80, or 72, or 27 or 24.