#348 add compiler configuration to use a different set of i-o status

[Simon Sobisch]

Most i-o status values defined in COBOL-85 are used by all compilers but some compilers raise i/o-status according to COBOL-74 (either in general or with a given flag). COBOL 2002 added more i-o status values and different vendors used other values before (for example the file/record locking).

As a program should only use one set of status values I suggest to add a flag to the cob_module structure defining "special status handling" (0 = GnuCOBOL default [includes older modules]) and in the runtime depending on that flag raise a different status value (in case of runtime error: output both).

The new flag should be a compiler configuration flags ("lax-include" would specify "default", strict would set whatever is appropriate as the compiler default for this std).

[Simon Sobisch]

Rechecked MF: file status codes also depend on the compile time and depend on the FILETYPE directive which is also included in the DIALECT directives.

Other than that there's an option to have the status code value be set at runtime, for this compilation with the COBFSTATCONV directive is needed in which case the environment variable COBFSTATCONV is searched (RM specifies RM/COBOL file status values).

Additional to this there's another option to set that via the file configuration CONVERTSTATUS(seems to apply only if compiled with COBFSTATCONV) to one of:

The name of the program to be called. Three such programs are built into the product:

• rmstat The rmstat program emulates status values returned by RM/COBOL.
• hoststat The hoststat program emulates status values returned by IBM Mainframe COBOL compilers.
• msstat The msstat program emulates status values returned by Microsoft COBOL V2.

Those "programs" seem to be just linked into the MF runtime and may also be written in COBOL.

In newer MF versions they seem to be automatically called (no matter of compile directives) when the file configuration INTEROP is set.

[Simon Sobisch]

More insights from https://www.microfocus.com/documentation/object-cobol/oc41books/fhstat.htm (describes a different case, but helps to get the picture of the implementation):

1 there is an entry somewhere in the module which (of the shipped) io status to use [would be a dialect configuration option in the GnuCOBOL case, auto-enabling -fio-stats=something]
2 at runtime this can be overridden per file/filetype/folder via configuration [I think trunk currently has file type and assign name; resulting path can not be configured yet], either to one of the standard ones, or to another one
3 if any conversion is active: at the end of each io statement (and possibly also file routines if those match per path) the conversion routine is called
4 the conversion routine can be one of the three above, or a self defined one, a sample shown in the docs helps to see that the FCD is passed to the program (so it knows about the status and the command, also knows about the file flags):

      *****************MODULE XFHCONV.CBL****************
      * This module is used to convert file statuses to 
      * different values from those supplied by the 
      * Callable File Handler ExtFH. The code below can 
      * be used as a basis for customized conversion 
      * routines.
      *************************************************** 
       linkage section.
       01 fcd-parameter.
           copy "xfhfcd.cpy".

       procedure division using fcd-parameter.
      * Example of status conversion; converting status
      * 9/90 to 8/9.
           evaluate fcd-status-key1
            when 9
               evaluate fcd-binary
               when 90
                  move 8 to status-key-1
                  move 9 to status-key-2
               end evaluate
           end evaluate
           exit program.

For this to work correctly there's obviously the need to internally always use the "extended" 9/xxx codes.

In theory we could write those three routines in COBOL, then either place them into extras (so compiled and available at runtime) or directly compile and link them, for example in a new libcob_iostats, or include them in fileio.c directly as C functions.

[Simon Sobisch]

Related: current implementation in trunk with [r4250] and [r4251], currently passed via the general dialect, so would be currently -fstandard-define=something - but I guess this will change also more than just the file status - we could move this to be read from something else, maybe also a different enum.
So far the handling of this variable at runtime is not at a single place - moving it that way with a translation table (function) using FCD3 as LINKAGE would then also allow writing an own conversion (for example to ACUCOBOL), if there's an override option at runtime this could also be tweaked and used without changing GnuCOBOL.