# Atomic Golf COBOL (IBM Enterprise COBOL)

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.

• I've read this twice and am still unclear on what the questions is. Could you add a "tl;dr" or equivalent? – dmckee Jun 14 '14 at 19:29
• @dmckee Thanks for trying. Is that any clearer? – Bill Woodger Jun 14 '14 at 23:20
• "Can I make use of these supported and documented features for Code Golf in COBOL without penalty for using them." Ah. I get it. See codegolf.stackexchange.com/questions/22469/… and codegolf.stackexchange.com/questions/607/find-the-factorial/… and codegolf.stackexchange.com/questions/23860/…. At least some answers depending on choosing a particular version of a language are well received. Frankly, few things on CodeGolf SE are matters of all-or-nothing, cut-n-dried policy. – dmckee Jun 14 '14 at 23:35
• I'm pretty sure that you'll find fortran 77 answers that depending on free-form input (a 1980s innovation not in any standard but supported by serveral compilers). – dmckee Jun 14 '14 at 23:36
• Thanks for the links. It is not the same thing as those. My source will look entirely different from the COBOL program that is being compiled, through the use of the abbreviations. These requires some set-up. The characters for the set-up would kill the benefits. The set-up is static, not specified at compile time, but I can change it (so will). – Bill Woodger Jun 14 '14 at 23:41
• My real source will be unix-style file-system, but my input exit will make it look like COBOL lines. This requires a program, but once written, it is part of the compiler (specified by compile option, which I can set as default). – Bill Woodger Jun 14 '14 at 23:43
• Some compile options produce useful effects. If I specify as a compile option, there is penalty NUMPROC(NOPDF),TRUNC(BIN) doesn't become worth it if I have to count them, so I will make them the default compile options. – Bill Woodger Jun 14 '14 at 23:45
• As far as I'm concerned as long as (a) the source is available for people to confirm your answers and (b) you don't answer old questions with your new compiler, feel free to do this. I also cannot imagine someone thinking that your compiler adds to your character count. – Kyle Kanos Jun 15 '14 at 2:15
• Plus the list of abbreviations has to be static. You may not change it for a particular task. Otherwise it would fall into the language-specific-for-the-task category. – Howard Jun 15 '14 at 7:02
• @KyleKanos Input is fixed-length 80 bytes. Give it more, or less, and the compile fails. So the exit has to take variable-length source and make it fixed, 80. Of the 80. Even without counting non-significant trailing blanks, there are a minimum of six and possibly 14 which don't affect the program, but are part of the source line. I tried a question on counting those differently before. – Bill Woodger Jun 15 '14 at 9:26
• @Howard so treat it as a language. OK. Compile options? I see they should be counted when changed, but in other languages they seem to to be "switches". +1 to the character count. NUMPROC(NOPFD) one option, +14 to the character count. Could I count +1 for each compiler option change, rather than could the whole lot? – Bill Woodger Jun 15 '14 at 9:31
• @BillWoodger: Yes, if you are doing strict COBOL & it requires 80 bytes per line, then those 80 bytes should count towards the total. However, if you are writing your own compiler/interpreter/parser for COBOL that does not have this byte requirement, then I see no reason to count the 80 bytes. – Kyle Kanos Jun 15 '14 at 14:29
• @KyleKanos I am not writing anything (except an "exit" which will take a variable-length line and just put the data into an 80-byte field starting from column eight). The exit, the abbreviations and the ability to change the default compiler options, are all existing, deliberate, and supported features of IBM's Enterprise COBOL :-) I just want to use those features for golfing, which is unlikely to be the original reason they were provided by IBM. – Bill Woodger Jun 15 '14 at 15:38