yes, it should be adjusted
note: it actually is "file io backend not available (before 4.x this mostly means a GnuCOBOL compile-time configuration --without-db, afterwards it could also mean that the shared object for the backend configured at runtime for the specific file cannot be loaded)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
.. and just today Bruce pointed me to another case where you see status 91: if executing a fileio statement that isn't supported per the file's organization.
This can happen if you run a statement that isn't supported by the runtime but not catched by the compiler (previously REWRITE to LINE SEQUENTIAL, for example, which was only supported later; or DELETE on any SEQUENTIAL file [soon to be catched in 3.x also for RECORD SEQUENTIAL]) or '"more common" if an EXTFH call does this.
.. so maybe "file io backend not available [on OPEN/CLOSE], or if file io backend does not support the executed statement".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would therefore say that the short description that best fits all the actual case is the following:
Feature not available or File I-O feature not available
This will be fine for OPEN/CLOSE and also for REWRITE and also for DELETE.
The long description for the PG will be:
For OPEN and CLOSE: means File I-O backend not available (before 4.x his mostly
means a GnuCOBOL compile-time configuration –without-db, afterwards it
could also mean that the shared object for the backend configured at runtime
for the specific file cannot be loaded).
For REWRITE and for DELETE: means File I-O statement isn't supported per the file's organization. This can happen if you run a statement that isn't supported by the runtime but not catched by the compiler (previously REWRITE to LINE SEQUENTIAL, for example, which was only supported later; or DELETE on any SEQUENTIAL file [soon to be catched in 3.x also for RECORD SEQUENTIAL]) or '"more common" if an EXTFH call does this.
Last edit: Eugenio Di Lorenzo 2025-08-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest you have a word with the programmer that create that code block .
On 23/08/2025 21:56, Eugenio Di Lorenzo wrote:
I would therefore say that the short description that best fits all
the actual case is the following:
|Feature not available|
This will be fine for OPEN/CLOSE and also for REWRITE and also for DELETE.
The long description for the PG will be:
For OPEN and CLOSE: means File I-O backend not available (before 4.x
his mostly
means a GnuCOBOL compile-time configuration –without-db, afterwards it
could also mean that the shared object for the backend configured at
runtime
for the specific file cannot be loaded).
For REWRITE and for DELETE: means File I-O statement isn't supported
per the file's organization. This can happen if you run a statement
that isn't supported by the runtime but not catched by the compiler
(previously REWRITE to LINE SEQUENTIAL, for example, which was only
supported later; or DELETE on any SEQUENTIAL file [soon to be catched
in 3.x also for RECORD SEQUENTIAL]) or '"more common" if an EXTFH call
does this.
Status: closed Group: Programmer's Guide Created: Fri Aug 22, 2025 06:12 PM UTC by Eugenio Di Lorenzo Last Updated: Sat Aug 23, 2025 08:49 PM UTC Owner: nobody
FILE STATUS 91 is listed as "File not available."
May be it should be corrected to "Feature not available" on pages 112
and 113 of PG.
Our goal is obviously to improve the PG's content.
We often have to gather elements from different sources.
I suspect that sometimes the tone of my posts isn't as polite as it should be.
Forgive me, but my command of English is very basic.
What you write would be very nice and certainly the best solution.
Unfortunately, I don't know who the developers are, and so far their involvement in the compiler documentation has been rather limited.
However, the wording I used was taken from Simon's posts.
Therefore, I believe they should be accurate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the change you made to the PG.
Now the following part also remains to be modified (see also attached image):
91 File not available or Feature not available Or/And File io backend not available (before 4.x his mostly means a GnuCOBOL compile-time configuration –without-db, afterwards it could also mean that the shared object for the backend configured at runtime for the specific file cannot be loaded).
Which should be replaced entirely with the following text (that has been written by Simon):
For OPEN and CLOSE: means that the File I-O backend is not available (before 4.x his mostly means a GnuCOBOL compile-time configuration –without-db, afterwards it could also mean that the shared object for the backend configured at runtime for the specific file cannot be loaded).
For REWRITE and for DELETE: means that File I-O statement isn't supported for the file's organization. This can happen if you run a statement that isn't supported by the runtime but not caught by the compiler (previously REWRITE to LINE SEQUENTIAL, for example, which was only supported later; or DELETE on any SEQUENTIAL file (soon to be caught in 3.x also for RECORD SEQUENTIAL) or '"more common" if an EXTFH call does this.
Unfortunately, there's still an error that makes the documentation less clear.
The text I highlighted in the attached image needs to be deleted.
My instructions in the previous post were very precise.
Thank you very much for your patience, it's mutual patience, believe me.
Please do what you think is best and/or as best you can.
For me, too, this is the last message on this ticket.
yes, it should be adjusted
note: it actually is "file io backend not available (before 4.x this mostly means a GnuCOBOL compile-time configuration
--without-db, afterwards it could also mean that the shared object for the backend configured at runtime for the specific file cannot be loaded)Changed for Simon addendum.
You forgot to also change file status 91 at page 113.
And the description must be just:
File io backend not availablenot : File not available Or/And File io backend not available
please delete "File not available Or/And"
Last edit: Eugenio Di Lorenzo 2025-08-23
That the one that has changed unless you are looking at a different pg 113.
At Page 113 there is also:
WHEN 91 MOVE ’File Not Available ’ TO MSGthat needs to be changed but .... see next post.
Last edit: Eugenio Di Lorenzo 2025-08-23
.. and just today Bruce pointed me to another case where you see status 91: if executing a fileio statement that isn't supported per the file's organization.
This can happen if you run a statement that isn't supported by the runtime but not catched by the compiler (previously REWRITE to LINE SEQUENTIAL, for example, which was only supported later; or DELETE on any SEQUENTIAL file [soon to be catched in 3.x also for RECORD SEQUENTIAL]) or '"more common" if an EXTFH call does this.
.. so maybe "file io backend not available [on OPEN/CLOSE], or if file io backend does not support the executed statement".
I would therefore say that the short description that best fits all the actual case is the following:
Feature not availableorFile I-O feature not availableThis will be fine for OPEN/CLOSE and also for REWRITE and also for DELETE.
The long description for the PG will be:
For OPEN and CLOSE: means File I-O backend not available (before 4.x his mostly
means a GnuCOBOL compile-time configuration –without-db, afterwards it
could also mean that the shared object for the backend configured at runtime
for the specific file cannot be loaded).
For REWRITE and for DELETE: means File I-O statement isn't supported per the file's organization. This can happen if you run a statement that isn't supported by the runtime but not catched by the compiler (previously REWRITE to LINE SEQUENTIAL, for example, which was only supported later; or DELETE on any SEQUENTIAL file [soon to be catched in 3.x also for RECORD SEQUENTIAL]) or '"more common" if an EXTFH call does this.
Last edit: Eugenio Di Lorenzo 2025-08-23
I suggest you have a word with the programmer that create that code block .
On 23/08/2025 21:56, Eugenio Di Lorenzo wrote:
Related
Bugs:
#1140Our goal is obviously to improve the PG's content.
We often have to gather elements from different sources.
I suspect that sometimes the tone of my posts isn't as polite as it should be.
Forgive me, but my command of English is very basic.
What you write would be very nice and certainly the best solution.
Unfortunately, I don't know who the developers are, and so far their involvement in the compiler documentation has been rather limited.
However, the wording I used was taken from Simon's posts.
Therefore, I believe they should be accurate.
The copybook changed and using my one as the change was made to Feature not available.
Progs might want to cut and paste the code as against using the out of date one in the distribution copy if present!.
Last edit: Vincent (Bryan) Coen 2025-08-24
Thanks for the change you made to the PG.
Now the following part also remains to be modified (see also attached image):
91 File not available or Feature not available Or/And File io backend not available (before 4.x his mostly means a GnuCOBOL compile-time configuration –without-db, afterwards it could also mean that the shared object for the backend configured at runtime for the specific file cannot be loaded).
Which should be replaced entirely with the following text (that has been written by Simon):
For OPEN and CLOSE: means that the File I-O backend is not available (before 4.x his mostly means a GnuCOBOL compile-time configuration –without-db, afterwards it could also mean that the shared object for the backend configured at runtime for the specific file cannot be loaded).
For REWRITE and for DELETE: means that File I-O statement isn't supported for the file's organization. This can happen if you run a statement that isn't supported by the runtime but not caught by the compiler (previously REWRITE to LINE SEQUENTIAL, for example, which was only supported later; or DELETE on any SEQUENTIAL file (soon to be caught in 3.x also for RECORD SEQUENTIAL) or '"more common" if an EXTFH call does this.
Done for the last time.
Unfortunately, there's still an error that makes the documentation less clear.
The text I highlighted in the attached image needs to be deleted.
My instructions in the previous post were very precise.
Thank you very much for your patience, it's mutual patience, believe me.
Please do what you think is best and/or as best you can.
For me, too, this is the last message on this ticket.