#517 Support for Micro Focus' COBRTxxx status codes

[Xavier Del Campo Romero]

Micro Focus (from now on, MF) define a list of run-time error codes that are typically returned by their CBL_* set of functions. These error codes are labeled from COBRT000 up to COBRT255.
MF define their error codes as 2-byte I/O status codes starting with '9', as per ISO COBOL (see §9.1.13.11 "Implementor-defined condition with unsuccessful completion"), and exceptionally use the full 8-bit range for the second byte, rather than relying on alphanumerical values as done by ISO COBOL.

An example from their documentation shows how to interpret the status codes for their I/O functions (more specifically, the example calls CBL_DELETE_FILE).

However, GnuCOBOL is apparently unaware of these implementor-defined return values defined by MF. For example, whereas MF explicitly defines COBRT013 ("File not found") as a possible return value for CBL_DELETE_FILE, GnuCOBOL's implementation of CBL_DELETE_FILE returns -1 on a missing parameter, and returns 128 if unlink(2) fails, regardless the actual reason behind the failure. The rest of CBL_* functions, as implemented by GnuCOBOL, do not follow these return values defined by MF, either.

Therefore, this seems like a deviation from the specifications as published by MF. Whether this should be considered a bug or a feature is up to GnuCOBOL, so I would like to read your rationale on this topic.

Best regards,
Xavi (Symas Corporation)

[Simon Sobisch]

We do have two different things here:

1. io-status: depending on the COBOL standard and vendor/product version you have a different set; GnuCOBOL returns ISO 2026 codes
2. runtime library callable functions like CBL_xyz: depending on the vendor/product version you have, the behaviour is slightly differently (especially how file and folder names are interpreted) and the return codes differ much more

For 1: we need a patch that allows dialect specific return codes; trunk has an implementation but that needs to be rewritten (we may could use the testcase) - see [feature-requests:#348].
This is a real issue for ports as you need to adjust the programs' value checks (making them portable is relative easy - but again that means a "recompile alone" is not enough - a state that we want to reach more and more).

For 2: I think we're more near to ACUCOBOL-GT concerning the return codes than MF, but in an ideal world we'd also have a dialect flag in cob_module for and check the current active module's dialect to return the expected code. But on the other hand, we get good away with "non-zero means an error" alone so far.

Patches welcome :-)