#742 wrong data behaviour with GnuCOBOL & c-tree DB via EXTFH
Hi GnuCOBOL team,
regarding to this general issue in the helping area: https://sourceforge.net/p/gnucobol/discussion/help/thread/152d5ca8d4/ we did some deeper tests and found some problems with c-tree and GnuCOBOL. It seems that the file operations are working correct at all.
In a testcase a couple of steps are done by program eevballes.cbl.
- WRITE of 3 data records (but the last is with rollback, so first result should be 2 records after this step.
- DELETE of data record 1
- REWRITE (and change) of data record 2.
A second program eevbread2.cbl is reading the file again and showing the content of the data file.
First probelm is that the rollback is not working (but this could be because this is not implemented at all into the GnuCOBOL compiler, I guess).
Second problem is that the DELETE is not working
Third problem is that the REWRITE is not working correct
Please use the compile_bdb.sh to see the result with BDB and also attached is the script for make it compilable in general with c-tree (compile_ctree.sh)
The expected output of the reading program eevbread2 is:
00 002222Keyboard 004440 10
With c-tree and GnuCOBOL it is:
00 001111Monitor 001110 00 002222Printer 002220 00 003333Mouse 003330 10
With BDB and GnuCOBOL it is:
00 002222Keyboard 004440 00 003333Mouse 003330 10
As you can see the DELETE and REWRITE is working with BDB (not the ROLLBACK) , but with c-tree no other operation than WRITE or READ is working correct.
We also send this testcase to FairCom and ask them where to find the error, the adressed some issues to GnuCOBOL in the past and it seems to Faircom that not everything is working correct in the EXTFH so far (some topics were optional file and open input) and these issue imaybe still in their court.
I'm not sure how we could help getting a solution, maybe organization of a test version of c-tree for you could be a possibility!?
Kind regards
Sebastian Steinweg
Easirun Europa GmbH
See Programmers Guide section 7.8.37 - ROLLBACK and 7.8.8 - COMMIT.
They are NOT doing what you are expecting !
On 25/06/2021 14:21, Sebastian Steinweg wrote:
Related
Bugs: #742
Thanks you for your response.
ok, as I wrote ROLLBACK and COMMIT is maybe not fully implemented or not implemented the way we expected.
In our view this is one topic.
The other topic is REWRITE and DELETE, which should work as well with any other EXTFH.
On 25/06/2021 16:24, Sebastian Steinweg wrote:
I have not used GC EXTFH but have used CBL-FILE-OPEN, -READ, WRITE etc
but that was for very special purposes in my contrib programs cobxref
last nested program printcbl and this program taken from my other
contrib program of same name.
This processes will not help for your application requirements !
Other wise REWRITE, DELETE etc work well using standard ISAM files
using BDB and the other optional libraries but BDB is the only one I
personally use as the program sources are always supplied for any one to
download.
Vincent
Hello Vincent,
The issue is working with Faircom c-tree and not BerkleyDB.
c-tree works correctly with Micro Focus, Acucobol, RM/COBOL, COBOL-IT and NETCOBOL.
However not with GnuCOBOL.
The engineers at Faircom have informed us that the problem lies in the incorrect implementation of EXTFH.
It is of course possible that it works with ISAM and perhaps the implementation of BerkleyDB is such that it is not dependent on the EXTFH.
Any file system that is expecting the documented EXTFH behaviour will in our opinion not work correctly with GnuCOBOL.
Who manages the EXTFH implementaion for GnuCOBOL?
Kind regards
Sebastian
cc: @Simon
I seem to recall Ron Norman BUT I could be wrong simon I assume you know ?
I have not used EXTFH so do not have the knowledge to help you.
Also it is possible that the way it works in v4 is NOT the same as in earler versions of the compiler such as v3...
Again, I will pass on this for others to help you.
Last edit: Vincent (Bryan) Coen 2021-08-13
@ssteinweg can you please recheck with either 3.2 preview-1 or 3.2 dev? There were several changes on this in the lasts months and I think that's fixed.