A few weeks ago I started studying COBOL with GnuCOBOL, and I'm quite excited.
I extend a big thank to everybody here.
To take it with me while on the way, I choosed the Android version, available already in Termux.
By now, almost everything went fine, but one of my programs failed with indexed files.
Indexed files on gnucobol for Termux were originally provided with vbisam, and empty .dat and .idx files were created with open optional.
By the advice of @sf-mensch, I could change the driver to --with-db, with the result of failure 91 to create the indexed file, and no file created.
The same cobol program ran flawlesly on Debian linux with libdb.
To tackle the problem, I made a similar c program, that was able to either build and query the indexed file both on linux and on android.
It should be mentioned, that libdb on my Linux is v5., while on termux is 18.1.
I'll share here both my c and cobol programs, and [a link to my question on stackoverflow] (https://stackoverflow.com/questions/78730695/gnucobol-failing-to-open-create-an-indexed-file/78763195) . Here is my bug report on github for the gnucobol package there .
I'd appreciate any help.
with your instructive support i was able to fix this problem and run my program on termux.
my fix was submitted to the termux packages repository and i'll work with them untill it will be accepted and published.
however, part of my patch is not termux related, and i'd kindly ask you to apply to original gnucobol repo. here it is . most of the fix is cross compiling related, and the configure file itself may an should be regenerated in your sandbox.
my work was based on gnucobol 3.2 as per your recommendation.
with many kudos, alex
Using open i-o on a file that does not exist yet may well NOT create a new file.
As a standard for all my code I use this code block :
open i-o file-1
if file-1-fs not = zeros
close file-1
open output file-1
if file-1-fs not = zeros *> JIC
display "error opening file-1 - status " file-1-fs
goback
end-if
close file-1
open i-o file-1.
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you vincent.
i tried your code with the same 91 filestatus. @sf-mensch has also suggested to try i-o, and output on failure.
your solution works perfectly on linux, as mine does, but both fail on termux.
i have to mention, the optional select attribute did the good job on linux before i tried your solution.
please note that successfuly opening an inexistent file with optional gave status 05, so simon suggested to test for fs(1,1) = zero.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why the "optional" ?
I would eliminate "optional" (I have never understood the purpose of "optional")
Then use Vince's technique.
You may also consider changing RANDOM to DYNAMIC
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT optional STUDENT-DB ASSIGN TO 'students'
ORGANIZATION IS INDEXED
ACCESS IS RANDOM
RECORD KEY IS DB-STUDENT-ID
FILE STATUS IS FS.
open i-o file-1
if file-1-fs not = zeros
close file-1
open output file-1
if file-1-fs not = zeros *> JIC
display "error opening file-1 - status " file-1-fs
goback
end-if
close file-1
open i-o file-1.
Last edit: Ralph Linkletter 2024-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
maybe there is a libcob4 or libdb way to display the full path of the file to open.
this should be important, as status 91 is related to file permissions. https://ibmmainframes.com/about17687.html
Last edit: alex bodnaru 2024-07-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As noted before: 9x is "implementor specific" and 91 in GnuCOBOL means "not available" (disabled at compile time).
To get the full path "as used by libcob" just comment out the declaratives + io status, the runtime will then abort and output the filename.
And as also noted: try to update to GnuCOBOL 3.2 in any case.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem DECLARATIVES provide a way for exception handling outside of COBOL2002 exceptions (and since COBOL2002 also for those).
If a file has neither an entry in DECLARATIVES nor the file status coded, then the runtime will abort on any fatal io status (and output the paths as it uses it).
Your program has an io status, but no declaratives, so if you want to test that, then just comment out the FILE STATUS IS FS (keeping the following period, of course).
Good to know. Thanks for the info Simon, this is how we used to do it, never check file-status or even have it, and if the I/O had an error, then GnuCOBOL would abend with all the information you need to correct the issue. Of course using idcam files we did use status if doing updates and dynamic reads.... or other things....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Different "standards" :-)
After every I-O statement a check is made of the status code defined in the Select Clause.
A status code '68' being raised should "wait" for the lock event to clear (or time out.)
It should not abend per a Declarative section.
Status code 02, 10, 22, 23 should be processed as events.
To trap an I-O event a status code clause in the select and
a query of the status code after the I-O statement is a "standard" I am familiar with .
Just saying
There is COBOL and then there is COBOL
Last edit: Ralph Linkletter 2024-07-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you don't have to believe me, I can obviously be always wrong, you can also have a look at the documentation and of course just have a look at libcob and you will quite likely find COB_STATUS_91_NOT_AVAILABLE...
note: you may remember status 30, that's a permanent error with no more specific reason
OPTIONAL files are quite useful because then an OPEN I-O (or EXTEND) will create the file only if it doesn't exist (you can of course do the same by manually checking for io status 35), it does not try to recreate it if it is considered to be broken or have missing rights or similar and will run into declaratives / file io exception handling if there is another issue while still providing the program with the knowledge by either io status 00 or 05
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For an ISAM file an open of EXTEND (via optional) doesn't seem germane. Sees more like a QSAM (sequential file access) convention. But what do I know ?
Regarding 91 you are correct it was 30 - I believe you :-) My mistake.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have never programmed for Android but - have you checked the privledges for the folder you are trying to create a file in ?
Another is to try and touch a non existant file in same folder i.e., touch fred
Then check it created an empty file.
In this I am clutching at straws a bit as I did not think Andriod uses owner settings for folders / files etc but could be wrong as I seem to recall Android is based on a Linux kernel but again could be wrong.
Regarding path - yes you can specify a full path and file name but running it under a terminal program that you set to being in the correct folder before running the program should be more than enough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
indeed i do suspect the system is prependinding some directory i cant't write to.
i did also try to give a hard coded path to the file name.
about the write permission, it should allegedly be the same location of the program i've just saved and compiled.
with some libdb or libcob4 insight i could see what is the true path to the file is and why is it that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, i began exploring the termux package builder in order to switch to version 3.2 and find things to patch, as at least some xml includes are missing in this release too.
now i see the previous package had even a patch related to a hardcoded '/tmp' string, things that for sure will not work in termux. however, termux does set $TMPDIR correctly.
hope for good news later today.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the various opinions expressed on 'optional', ilustrate it's some newer syntactic sugar.
my experience weights nothing, but it seems to me it worked properly as far as i tried it.
file status of opening an unexistent file is 05, while for opening an existent one was 00.
more finegrained control on the file conditions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
status of building:
by now i could build gnucobol-3.2 for android.
the only thing i had to disable altogether is help2man invokation of cobc --help, because the linker in the binary is not present in the building environment, which is only cross compiling.
i'll recheck this later with the staticly build cobc.
funnily, the indexed files support is disabled in cobcrun -info, and i'll have to look where it happens.
next report in a short time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
configure: Checks for Berkeley DB ...
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
configure: WARNING: cannot run test program while cross-compiling
configure: db.h reports version "cross"
configure: WARNING: Matching BDB version (>=4.1) assumed
checking for db_version in -ldb... yes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it's probably a problem with configure of gc32 that probably misidentifies db-18.*
but after further reading, since 6.0.21, db became agpl, thus limiting linked products too.
so, i'll take your previous advice to pack an older version and provide it as an alternative.
you've mentioned db-6.0.19.
however, it seems debian is embracing db-5.3.28.
what would you suggest?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A few weeks ago I started studying COBOL with GnuCOBOL, and I'm quite excited.
I extend a big thank to everybody here.
To take it with me while on the way, I choosed the Android version, available already in Termux.
By now, almost everything went fine, but one of my programs failed with indexed files.
Indexed files on gnucobol for Termux were originally provided with vbisam, and empty .dat and .idx files were created with open optional.
By the advice of @sf-mensch, I could change the driver to --with-db, with the result of failure 91 to create the indexed file, and no file created.
The same cobol program ran flawlesly on Debian linux with libdb.
To tackle the problem, I made a similar c program, that was able to either build and query the indexed file both on linux and on android.
It should be mentioned, that libdb on my Linux is v5., while on termux is 18.1.
I'll share here both my c and cobol programs, and [a link to my question on stackoverflow] (https://stackoverflow.com/questions/78730695/gnucobol-failing-to-open-create-an-indexed-file/78763195) .
Here is my bug report on github for the gnucobol package there .
I'd appreciate any help.
with your instructive support i was able to fix this problem and run my program on termux.
my fix was submitted to the termux packages repository and i'll work with them untill it will be accepted and published.
however, part of my patch is not termux related, and i'd kindly ask you to apply to original gnucobol repo. here it is . most of the fix is cross compiling related, and the configure file itself may an should be regenerated in your sandbox.
my work was based on gnucobol 3.2 as per your recommendation.
with many kudos, alex
Last edit: alex bodnaru 2024-07-26
Using open i-o on a file that does not exist yet may well NOT create a new file.
As a standard for all my code I use this code block :
thank you vincent.
i tried your code with the same 91 filestatus.
@sf-mensch has also suggested to try i-o, and output on failure.
your solution works perfectly on linux, as mine does, but both fail on termux.
i have to mention, the optional select attribute did the good job on linux before i tried your solution.
please note that successfuly opening an inexistent file with optional gave status 05, so simon suggested to test for fs(1,1) = zero.
Why the "optional" ?
I would eliminate "optional" (I have never understood the purpose of "optional")
Then use Vince's technique.
You may also consider changing RANDOM to DYNAMIC
Last edit: Ralph Linkletter 2024-07-18
maybe there is a libcob4 or libdb way to display the full path of the file to open.
this should be important, as status 91 is related to file permissions.
https://ibmmainframes.com/about17687.html
Last edit: alex bodnaru 2024-07-22
As noted before: 9x is "implementor specific" and 91 in GnuCOBOL means "not available" (disabled at compile time).
To get the full path "as used by libcob" just comment out the declaratives + io status, the runtime will then abort and output the filename.
And as also noted: try to update to GnuCOBOL 3.2 in any case.
pardon my deep ignorance, whad do you mean by declaratives?
No problem
DECLARATIVESprovide a way for exception handling outside of COBOL2002 exceptions (and since COBOL2002 also for those).If a file has neither an entry in
DECLARATIVESnor thefile statuscoded, then the runtime will abort on any fatal io status (and output the paths as it uses it).Your program has an io status, but no declaratives, so if you want to test that, then just comment out the
FILE STATUS IS FS(keeping the following period, of course).To learn more about this COBOL feature, have a look at https://gnucobol.sourceforge.io/HTML/gnucobpg.html#DECLARATIVES .
Good to know. Thanks for the info Simon, this is how we used to do it, never check file-status or even have it, and if the I/O had an error, then GnuCOBOL would abend with all the information you need to correct the issue. Of course using idcam files we did use status if doing updates and dynamic reads.... or other things....
Different "standards" :-)
After every I-O statement a check is made of the status code defined in the Select Clause.
A status code '68' being raised should "wait" for the lock event to clear (or time out.)
It should not abend per a Declarative section.
Status code 02, 10, 22, 23 should be processed as events.
To trap an I-O event a status code clause in the select and
a query of the status code after the I-O statement is a "standard" I am familiar with .
Just saying
There is COBOL and then there is COBOL
Last edit: Ralph Linkletter 2024-07-28
As I recall from testing IDCAMS with GnuCOBOL '91' is a catch all for ISAM file operation status codes.
I had to hunt around for less than obvious causes.
Again "optional" is and oddity to me.
Bruce
you don't have to believe me, I can obviously be always wrong, you can also have a look at the documentation and of course just have a look at libcob and you will quite likely find
COB_STATUS_91_NOT_AVAILABLE...note: you may remember status 30, that's a permanent error with no more specific reason
OPTIONALfiles are quite useful because then anOPEN I-O(orEXTEND) will create the file only if it doesn't exist (you can of course do the same by manually checking for io status 35), it does not try to recreate it if it is considered to be broken or have missing rights or similar and will run into declaratives / file io exception handling if there is another issue while still providing the program with the knowledge by either io status 00 or 05For an ISAM file an open of EXTEND (via optional) doesn't seem germane. Sees more like a QSAM (sequential file access) convention. But what do I know ?
Regarding 91 you are correct it was 30 - I believe you :-) My mistake.
Ralph
I have never programmed for Android but - have you checked the privledges for the folder you are trying to create a file in ?
Another is to try and touch a non existant file in same folder i.e., touch fred
Then check it created an empty file.
In this I am clutching at straws a bit as I did not think Andriod uses owner settings for folders / files etc but could be wrong as I seem to recall Android is based on a Linux kernel but again could be wrong.
Regarding path - yes you can specify a full path and file name but running it under a terminal program that you set to being in the correct folder before running the program should be more than enough.
indeed i do suspect the system is prependinding some directory i cant't write to.
i did also try to give a hard coded path to the file name.
about the write permission, it should allegedly be the same location of the program i've just saved and compiled.
with some libdb or libcob4 insight i could see what is the true path to the file is and why is it that.
i have a feeling it's about temporary files.
ok, i began exploring the termux package builder in order to switch to version 3.2 and find things to patch, as at least some xml includes are missing in this release too.
now i see the previous package had even a patch related to a hardcoded '/tmp' string, things that for sure will not work in termux. however, termux does set $TMPDIR correctly.
hope for good news later today.
the various opinions expressed on 'optional', ilustrate it's some newer syntactic sugar.
my experience weights nothing, but it seems to me it worked properly as far as i tried it.
file status of opening an unexistent file is 05, while for opening an existent one was 00.
more finegrained control on the file conditions.
status of building:
by now i could build gnucobol-3.2 for android.
the only thing i had to disable altogether is help2man invokation of cobc --help, because the linker in the binary is not present in the building environment, which is only cross compiling.
i'll recheck this later with the staticly build cobc.
funnily, the indexed files support is disabled in cobcrun -info, and i'll have to look where it happens.
next report in a short time.
configure seems to tackle with bdb
configure: Checks for Berkeley DB ...
checking db.h usability... yes
checking db.h presence... yes
checking for db.h... yes
configure: WARNING: cannot run test program while cross-compiling
configure: db.h reports version "cross"
configure: WARNING: Matching BDB version (>=4.1) assumed
checking for db_version in -ldb... yes
Can you please send config.log? That would help (may not be needed, so if it is hard then skip that).
Related note: if you build from a tarball then it is enough to 'touch bin/cobcrun.1 cobc/cobc.1' after applying patches to not need help2man.
the log is huge but maybe all the build output may be copied from gh.
can you see this, simon?
it contains a cat of config.log i purposely added.
https://github.com/alexbodn/termux-packages/actions/runs/10027228388/job/27712596439
i could also download the logs.
the build environment cannot run programs it builds, because the linker of android being hardcoded in the programs.
it's probably a problem with configure of gc32 that probably misidentifies db-18.*
but after further reading, since 6.0.21, db became agpl, thus limiting linked products too.
so, i'll take your previous advice to pack an older version and provide it as an alternative.
you've mentioned db-6.0.19.
however, it seems debian is embracing db-5.3.28.
what would you suggest?