Open alexbodn opened 1 month ago
*>this is my offending program
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT STUDENT-DB ASSIGN TO 'students'
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
*>ACCESS MODE IS SEQUENTIAL
RECORD KEY IS DB-STUDENT-ID
FILE STATUS IS FS.
DATA DIVISION.
FILE SECTION.
FD STUDENT-DB.
01 DB-STUDENT.
05 DB-STUDENT-ID PIC 9(5).
05 DB-NAME PIC A(25).
05 DB-CLASS PIC X(3).
WORKING-STORAGE SECTION.
01 FS PIC X(2).
PROCEDURE DIVISION.
OPEN i-o STUDENT-DB.
DISPLAY "FS open : "FS END-DISPLAY.
move 1000 TO DB-STUDENT-ID.
move 'Tim' TO DB-NAME.
move '10' TO DB-CLASS.
DISPLAY 'DB-STUDENT-ID : 'DB-STUDENT-ID END-DISPLAY.
DISPLAY 'DB-NAME : 'DB-NAME END-DISPLAY.
DISPLAY 'DB-CLASS : 'DB-CLASS END-DISPLAY.
DISPLAY 'DB-STUDENT : 'DB-STUDENT END-DISPLAY.
WRITE DB-STUDENT END-WRITE.
DISPLAY "FS write : "FS END-DISPLAY.
CLOSE STUDENT-DB.
DISPLAY "FS close : "FS END-DISPLAY.
STOP RUN.
Could you provide all the steps to reproduce the issue?
According to the related StackOverflow question that should be cobc -d -free -Wall -Wextra -Wadditional -xj index-create.cbl
.
Expected "working" output would then be:
FS open : 05
DB-STUDENT-ID : 01000
DB-NAME : Tim
DB-CLASS : 10
DB-STUDENT : 01000Tim 10
FS write : 00
FS close : 00
I think that's rooted in the gnucobol package being built with VBISAM as dependency instead of BDB. As the later is the default envrionment for GnuCOBOL since two decades and the backend that's commonly used in distributions (including in MSYS2 ;-) it is likely useful to switch that.
[Warning note: this would make all püreviously created indexed files on Termux not readable anymore after the package update :-/ ]
@alexbodn: you may want to try doing an explicit OPEN EXTEND STUDENT-DB. IF FS (1:1) NOT = "0" OPEN OUTPUT STUDENT-DB.
which may or may not work.
I get the following output in termux and it matches with your expected result.
$ cobc -d -free -Wall -Wextra -Wadditional -xj index-create.cbl
FS open : 35
DB-STUDENT-ID : 01000
DB-NAME : Tim
DB-CLASS : 10
DB-STUDENT : 01000Tim 10
FS write : 48
FS close : 42
Expected would be status "00" or "05" then only "00" and I think that should be the case if the BDB backend is used.
@alexbodn: you may want to try doing an explicit
OPEN EXTEND STUDENT-DB. IF FS (1:1) NOT = "0" OPEN OUTPUT STUDENT-DB.
which may or may not work.
@GitMensch i retried your suggestion with the same unfortunate result.
Thanks for the test, that means that either the GnuCOBOL version in the distro or (more likely) the VBISAM version doesn't work well with Termux.
While this is hopefully not an issue with the upcoming update to that library (late this year), it seems that the most reasonable option is to change the gnucobol package in termux to use libdb instead of livbisam then.
@xtkoba: Did you chose libvbisam on purpose over libdb?
As the recipe in termux does not define a test/check target, did someone executed make checkall
to verify if the libvbisam version works better (or at all with Indedex-sequential files) than the libdb one?
xtkoba is not active in GitHub for many months. You can try to rebuild the package with required changes and test it.
xtkoba is not active in GitHub for many months. You can try to rebuild the package with required changes and test it.
That would likely go to @alexbodn for now. Alex, could you try to build the package per wiki? Maybe you can also include a "make check" after the build and save the resulting tests/testsuite.log.
The next step would be to then adjust the package locally to swap libvbisam to libdb and drop --with-vbisam by --with-db and see what the different result in testsuite.log is.
If we see that's better (and your program pass with that version) then we could update the package definition.
my first attempt to install the docker image ruined my vm computer, and i'm still trying to regain control on it. i'll check another way to do it.
i'll check another way to do it.
You could fork this repository, enable CI, add your required changes and let CI do the work for you.
i'll check another way to do it.
You could fork this repository, enable CI, add your required changes and let CI do the work for you.
I hoped for such a solution, thank you. So i'll have to make the changes to the gnucobol package recipe and save the changes? But where will the new deb be?
But where will the new deb be?
In CI artifacts. You have to enable the GitHub Actions and run the "packages" workflow with proper inputs - branch name and gnucobol in package name.
thank you @Biswa96 , indeed the build was successful after my first attempt to patch. the program is attempting to open a bdb file in the same location, but it doesn't and gives an error related with missing write permissions. good @GitMensch i could patch the configure parameters and put --with-db instead of --with-vbisam. now no files get created, and the fs code is 91 at opening the file. this starting point seems better.
small progress:
a little program i wrote in c and built on termux with packaged libdb, does properly access, and eventually create, a bdb file in the current directory.
i could patch the configure parameters and put --with-db instead of --with-vbisam. now no files get created, and the fs code is 91 at opening the file. this starting point seems better.
There's something wrong - status 91 is "not available" (= built without INDEXED support, which should not happen when if you don't use --without-db
).
Checking the CI runs I see that BDB is used, so there shouldn't be a status 91.
For some reasons it builds GnuCOBOL 3.1.2 - I highly suggest to move to GnuCOBOL 3.2 instead (full backward-compatibility down to GC 2.2) which likely should allow to drop the configure patch as well,
i could patch the configure parameters and put --with-db instead of --with-vbisam. now no files get created, and the fs code is 91 at opening the file. this starting point seems better.
There's something wrong - status 91 is "not available" (= built without INDEXED support, which should not happen when if you don't use
--without-db
).
the original package was 3.1.2, configured --with -vbisam --without-db. status was 30/35, with .dat and .idx created. inverting these switches, with 3.1.2 yet, got status 91.
Checking the CI runs I see that BDB is used, so there shouldn't be a status 91.
For some reasons it builds GnuCOBOL 3.1.2 - I highly suggest to move to GnuCOBOL 3.2 instead (full backward-compatibility down to GC 2.2) which likely should allow to drop the configure patch as well,
working on 3.2, but didn't seem to recognize libdb. but the result is disabling indexed handling altogether.
i fixed this issue and intend to pull request. thank you for your collaboration and support.
Problem description
a program meant to write to an indexed file fails to do so under termux. it does work as expected under arm64 linux, while the index backend happens to be bdb. i'll attach the program, naturally.
What steps will reproduce the bug?
build the program i include and run the executable under termux and elsewhere, say linux.
What is the expected behavior?
writing data to the indexed file.
System information