Re: [GnuCOBOL 3.1-rc1] testsuite: 697 719 760 761 failed, 751 752 753 754 755 passed unexpectedly

[Simon Sobisch]

Am 01.10.2020 um 07:12 schrieb Sergio Santoro:
> Hello,
> I installed, in 2014, a RHEL 6.5 64-bit linux VM with opencobol 2.0 and
> IBM Informix C-ISAM 7.26.FC3 for migration from IBM AIX with COBOL
> MICRO-FOCUS and Informix C-ISAM. Now we need, to update the OS, to make
> a new machine. I have installed a new VM with CENTOS 8. I have installed
> IBM Informix C-ISAM 7.26.FC3 and I am trying to install GnuCOBOL 3.1-rc1.

Hi Sergio, thanks for sharing the background of this project and welcome
back to GnuCOBOL (it is good that you update, OpenCOBOL 2.0 is quite
outdated).
That's an interesting project and it is good to know that C-ISAM _is_ used.
Note: as IBM doesn't provide a test environment or at least a C-ISAM
version to test against, this version is very rarely tested. It is coded
in accordance to the public available documentation, which obviously
worked fine, but you may want to check for compile warnings during
`make` and send warnings from libcob/fileio.c (if there are any) to this
list.
The question "does it work" should be answered by the testsuite as
normally (discussion of the results below), that is what its for.
In your CISAM case I highly suggest to verify that `make check` (NIST85
test suite) is run, it should end with no "diff" shown, see
tests/cobol85/README for details on this.

> Running "make test" I received a series of "passed unexpectedly" which
> are reported in the attached testsuite.log.

this file should be all we need to debug the issue, thanks.

To allow references I'll copy the "extended summary" shown there below.


Failed tests:
GnuCOBOL 3.1-rc1 test suite: GnuCOBOL Tests test groups:

 NUM: FILE-NAME:LINE     TEST-GROUP-NAME
      KEYWORDS

 697: run_file.at:340    OUTPUT on INDEXED file to missing directory
      runfile open assign

This is a minor issue in fileio.c and also happens with different (but
not all) indexed handlers.
It should be solved, hopefully in 3.1 RC2 which is available "very soon
TM", but is unlikely to be an issue for your migration.
As seen in the detailed failures the consequence of this issue is that
you get a permanent file error "35" instead of "30", so you likely can
ignore this.

 719: run_file.at:2522   INDEXED file variable length record
      runfile write start read

This is another minor issue for environments that need to emulate
SUPPRESS key but return status 02 for "(re-)write identical alternate
key" (C-ISAM, old VB-ISAM).
In this case the REWRITE is done with a suppressed key (normally
ignored), it expects a status of "00" but gets a "02" instead. I'll
finish my testcase adjustements here and then create a bug report.

This should not influence your migration as OC 2.0 has no support for
SUPPRESS WHEN at all; it would only influence new programs that use this
feature.

 760: run_file.at:6019   INDEXED partial keys
      runfile
 761: run_file.at:6166   INDEXED undeclared keys
      runfile

Those are features not available in C-ISAM (as far as I know). They will
likely work (with performance penalty) in the upcoming GnuCOBOL 4 (with
an extra file), but as you did not (could not) use those features omn
OpenCOBOL, there is no problem for your migration project. Just don't
use this in new programs after your migration.


Unexpected passes:
GnuCOBOL 3.1-rc1 test suite: GnuCOBOL Tests test groups:

 NUM: FILE-NAME:LINE     TEST-GROUP-NAME
      KEYWORDS

 751: run_file.at:5279   INDEXED file with LOCK MODE EXCLUSIVE
      runfile
 752: run_file.at:5356   INDEXED file with OPEN WITH LOCK
      runfile
 753: run_file.at:5432   INDEXED file with SHARING NO
      runfile
 754: run_file.at:5509   INDEXED file with SHARING READ ONLY
      runfile
 755: run_file.at:5593   INDEXED file with blocked lock
      runfile

Those are: unexpected passes, I _guess_ they'll also pass with D-ISAM
(haven't checked in a while), the testsuite should be adjusted some day
to expect those as passes with C-ISAM (and D-ISAM).
They'd fail when using the BDB interface and likely also when using (at
least the last official version of) VB-ISAM [it is expected that they
will pass with its nex official release].

What does this mean for you? You know that it can even do more in this
area than other INDEXED handlers - no problem :-)

> I would need help figuring out the nature of the error and if I made any
> mistakes by running the configure script
> ./configure CFLAGS = "- I / usr / local / include" LDFLAGS = "- L / usr
> / local / lib" --with-cisam --libdir = "/ usr / local / lib"
> --includedir = "/ usr / local / include "LIBS =" - ldl "

The CFLAGS is wrong (should be CPPFLAGS), otherwise it is fine I _think_
a more simple configure should lead to the same results, you may test
those below that and use the simplest one, in case everything is as
expected:

configure --with-cisam \
        CPPLAGS="-I/usr/local/include" LDFLAGS="- L/usr/local/lib"

or even

configure --with-cisam


In any case: If you have a support contract for C-ISAM (or at least a
good contact person) I suggest to contact IBM, asking to "open-source"
C-ISAM, allowing it to be of more use. Background: some years ago they
considered this as the commercial interest is not so high any more and
switched the person responsible for that software more than once, the
last note I got from them was "not now", but this must have been years ago.

If it is accessible we can also test GnuCOBOL + C-ISAM in general.

> Thanks Sergio Santoro

Looking forward to get an update,
Simon