Overview - Batch processing: zOS COBOL vs GnuCOBOL

I can't speak about the efficiency or the scalablity or "benchmarking performance" between zOS COBOL and GnuCOBOL.

I just don't know.

From an application programmer's point of view though, these are the differences that I know of:

INPUT-OUTPUT SECTION : FILE-CONTROL

This is the one place where you probably need to make changes.

This is a snippet I copied from one of the programs I wrote a while back:

       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT PSAPFile
      *     ASSIGN TO PSAPFILE
      *     ORGANIZATION IS SEQUENTIAL
           ASSIGN TO "../data/psap.dat.txt"
           ORGANIZATION IS LINE SEQUENTIAL
           FILE STATUS IS WS-PSAPFile-Status.

This would compile and run using GnuCOBOL.

If I copied this program to a zOS Mainframe, I would uncomment the first ASSIGN and ORGANIZATION lines and comment the next two and that would run on the Mainframe.

But, the ASSIGN statement is "hardcoded". If the file needed to be changed, the program would have to be updated then re-compiled.

Here is a "better, more recent version":

       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT PSAPFile
      *     ASSIGN TO PSAPFILE
      *     ORGANIZATION IS SEQUENTIAL
           ASSIGN TO QIPSAPFILE
           ORGANIZATION IS LINE SEQUENTIAL
           FILE STATUS IS WS-PSAPFile-Status.

ASSIGN statement

From the GnuCOBOL documentation:

For example, given ASSIGN TO "DATAFILE", the actual
  file name will be
 1. the value of environment variable 'DD_DATAFILE' or
 2. the value of environment variable 'dd_DATAFILE' or
 3. the value of environment variable 'DATAFILE' or
 4. the literal "DATAFILE"

So, under GNU/Linux, bash shell

export DD_QIPSAPFILE='../data/psap.dat.txt'

./myprog

However, you cannot name it the same as the SELECT variable as that will be an error.

On the Mainframe, you can "get around this" by prefixing the ASSIGN variable with "DA-S-" (or other versions of this) and the compiler will parse just the last part and use that for the JCL.

ORGANIZATION statement

The other change that must be made for sequential files using GnuCOBOL is the addition of the keyword "LINE"

• Mainframe:

ORGANIZATION IS SEQUENTIAL

• GnuCOBOL

ORGANIZATION IS LINE SEQUENTIAL

This is because on the Mainframe, most files are a fixed length so there isn't a "LF" or "CRLF" at the end of each line.

For sequential input files, the "LINE" keyword tells GnuCOBOL to examine the record, look for the line ending and strip that off before trying to process the record.

For sequential output files, The "LINE" keyword tells GnuCOBOL to append a line feed character at the end of each record before it writes it out.