[open-cobol-list] CVS Update 20060221

[Roger While]

CVS Updated.
Snapshot tarball (aka prerelease) can be downloaded at
http://www.sim-basis.de/open-cobol-0.33.tar.gz
As usual, you should/must recompile all progs when
using CVS/prerelease.

Note to developers - A new file has been checked in :
libcob/codegen.h
This contains inlines that only have relevance to
the generated C code from codegen. It is included
automatically by libcob.h. (This may change as
we do not actually want this in the compiler and/or library)


Some major surgery here.
Details can be found in the ChangeLog file present
not only at the top level, but also in each of the
sub-directories (cobc, libcob, bin, tests, config).

Excerpts :

The relax-level-hierarchy is activated for -std=mvs,
ibm, bs2000 and mf.

IDENTIFICATION DIVISION is optional.

Allow multiple destination fields on MOVE CORRESPONDING.
(Although not part of the standard, MF and I believe mainframe have this)

In the ./configure --help output, put (OpenCOBOL) in the text
to distinguish OC options.

Fix yet again checking invalid 88 usage in EVALUATE.

Check that PROCEDURE USING params are in LINKAGE.

Check attempt to create executable when prog has
PROCEDURE USING.

Check for duplicate ENTRY names.

Implement (RFC from Sergey) CBL_ERROR_PROC.

Fixes (thanks to Sergey Kashyrin) for IBM, HP, Solaris
and MSVC ports.

Fix UNSTRING DELIMITED LOW-VALUE.
This meant that usage of regex had to be ripped out
as this cannot handle a null byte.

Implement environment variable COB_PRE_LOAD.
This can contain colon-seperated list of modules
(minus the extension) that will be loaded at
startup. Path names are not allowed. The module(s)
will be searched using the normal COB_LIBRARY_PATH.
No errors will be produced if the module cannot be found.
Simple example : (Note the problem of source != p-id
 is being looked at. This is just an example that works currently)
myprog.cob
PROGRAM-ID. myent.
cobc -m myprog.cob
Other program does a CALL "myent"
In this case we would need
export COB_PRE_LOAD=myprog
NOTE - There is work in progress to include
the source name as an entry point.

Optimizations for COMP(-5), BINARY, COMP-3 when
compiling using -std=mf,mvs,bs2000,ibm.

The configuration variable "relax-level-hierarchy" is activated
for -std=mf, mvs, ibm and bs2000.


Now the major change :
We have always been striving to get through as many
as possible of the Cobol85 tests.
One hurdle has been nested programs. (IC tests)
A further problem is that the nested program tests
also test EXTERNAL on the FD clause. (Why were
these not done seperately?)

Preliminary support for nested programs has been added.
NOTE - This is not complete. We still generate only one
C source file. This is not correct for non-contained programs.
eg.
PROGRAM-ID. P1.
...
PROGRAM-ID. P2.
...
END PROGRAM P2.
END PROGRAM P1.
PROGRAM-ID. P3.
...
END PROGRAM P3.

In this case, P2 is contained and P3 is non-contained.
P3 should be generated as a seperate module.

Support for EXTERNAL on the FD clause.
This had consequences due to the FILE STATUS clause.
FILE STATUS has been discussed on the list. As it
turns out, FILE STATUS is not part of  the underlying
file connector/descriptor. There should be an implicit local
(per module) file status. If FILE STATUS is specified, the
local file status will be copied to the specified destination.
Previously, OC had the file status as part of the file descriptor
which did not work with the Cobol85 tests.
Now OC generates a local file status field per module and
passes any defined FILE STATUS fields as a parameter
to all I/O calls.
Here's what one of the Cobol85 tests does
-You might like this :-)  and apparently it's legal
(stripped to bare essentials)
Prog A
..
FILE STATUS FLD1
FD EXTERNAL
WORKING-STORAGE.
01   FLD1
01   FLD2

I/O on file
CALL ProgB USING FLD1.
Check status
I/O on file
CALL ProgB USING FLD2.
Check status
etc.

Prog B.
FILE STATUS FLD3
FD EXTERNAL
LINKAGE SECTION     <------!!
01  FLD3                     <------!!
I/O on file

The above test makes it clear why the FILE STATUS
is not/cannot be directly tied to a file connector/descriptor.

So, we now get through a few more Cobol85 tests.
There only remains support for GLOBAL.
This is going to pose a similar problem like FILE STATUS
due to the USE GLOBAL clause. This means that
exception processing should not/cannot be tied to
a file connector/descriptor.

Roger