gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Compiler modifications


From: Roger While
Subject: Re: [open-cobol-list] Compiler modifications
Date: Thu, 08 Jun 2006 09:06:30 +0200


Thank you very much for adding my name on the THANKS file. Unfortunately,
there is a spelling misteak :-) in my name, the correct spelling is
"Gouget".

Oops, sorry, corrected.


Roger, being myself a developer, I fully understand your motivations and the
very professional attitude you and others have regarding this great
compiler. So now I am left with 2 choices:
1) Apply my diffs to every new OC release so as to support my customer's
code as-is. It runs fine and the customer is very happy with the results.
2) Modify my customer's code (about 40 READ PREVIOUS (with a changed logic),
600 READ NEXT (with a changed logic), and many many comments), and test and
validate the mods. I won't be paid more for doing that :-(.

I still think that especially the EOF mod (2 lines!!!) could have been
incorporated as a "feature".


Well, as stated before, the program logic is wrong.
In fact you would be forced to change the logic
using any other compiler.
What you could do (and I probably would accept) is
to make it dependent on an environment variable
eg. COB_OLD_EOF
In fileio.c this can be set up in routine cob_init_fileio.
Having said that, I think you will need to hold a count
of consecutive EOF returns. More than 2 must be
an error and would indicate a problem with the program.
It would also prevent infinite EOF loops.


I intend to use the "Berkeley DB Concurrent Data Store" to provide at least
a crude form of locking which would be enough for my application. I thought
about implementing that as LOCK MODE AUTOMATIC, for indexed files. In that
case, a read lock is acquired automatically on each record got by READ,
which is released when doing another READ or closing the file. The UNLOCK
statement will do nothing. A WRITE on a locked record waits until the lock
is released. I expect to use the current DB version, which will be ifdefed,
so as to still continue to support DB V1.86. Do you think that those
semantics are compatible with COBOL? Any suggestions before I start?

The starting point here is the LOCK MODE clause
in the SELECT statement.
This is currently marked as pending in the parser.
The rules here can be got from the online MF documentation.
Go to www.microfocus.com, click on
Suppport/Product Dcoumentation, Select one of
the Server Express links, On the left side open the
Language Reference, then
Environment Div/Input-Output Sec/File Control entry.

The various lock modes and their effects are
described there (also when the LOCK clause is not present)

Roger







reply via email to

[Prev in Thread] Current Thread [Next in Thread]