status 48 when attempting to WRITE a record to OPEN EXTEND / ORGANIZATION INDEXED

[Anonymous]

Hi,

I'm playing around with GNU COBOL 3.0-rc1 on a linux box.
With a ORGANIZATION SEQUENTIAL file OPEN EXTEND, WRITE, CLOSE works lik described in tutorials and manual.
However, if it is a ORGANIZATION INDEXED file that I OPEN EXTEND, the WRITE will fail with status 48.
(libcob: WRITE not allowed, file not open for output)
Only OPEN OUTPUT works.
But I'd really like to append records to the database. I don't want to read and write the complete db every time.

Is there a workaround or a fix for that problem?

* (...)
 ENVIRONMENT DIVISION.
 INPUT-OUTPUT SECTION.
 FILE-CONTROL.
      SELECT OPTIONAL PHONE-FILE
                 ASSIGN TO "phonebook"
                 ORGANIZATION IS INDEXED
                 RECORD KEY IS PHONE-INDEX
                 ACCESS MODE IS DYNAMIC.

   DATA DIVISION.
   FILE SECTION.
   FD PHONE-FILE LABEL RECORDS ARE STANDARD.
   01 PHONE-RECORD.
       03 PHONE-INDEX PIC 9(8).
* (....)
 PROCEDURE DIVISION.
* (....)
 OPEN EXTEND PHONE-FILE.
 WRITE PHONE-RECORD
        INVALID KEY
            PERFORM DUP-HANDLING.
 CLOSE PHONE-FILE.
* (...) 

[Anonymous]

Thanks for this writing. Just sorted error 48 - write not allowed, buy changing "OPEN INPUT" to OPEN EXTEND.

[Simon Sobisch]

Hi Anonymous and welcome to GnuCOBOL.

in COBOL WRITE isn't allowed with ACCESS MODE IS DYNAMIC and OPEN EXTEND. Either change your program to use ACCESS MODE IS SEQUENTIAL or (more likely reasonable) to OPEN INPUT-OUTPUT which allows you to use ACCESS MODE DYNAMIC.

Simon

BTW: anonymous post are put in a moderation que which means it will stay there from 1 minute to several days (whenever a mod looks for these), very rarely would be falsely deleted (normally re-posted when recognized) and needs someone to check + set to "ok". All these issues are magically gone when posting registered (and it helps to create answers based on knowledge of older posts from the same topic starter).

[Stephan Lahl]

Hi,

thank you for this answer. I misread the documentation. Opening in I/O mode solved the problem, just as you say. Thank you very much!

[Vincent (Bryan) Coen]

For open EXTEND to work file MUST exist and then works as advertised.

If it does NOT exist it will not create the file.

I seem to remember reporting this a long time ago but nothing happened.
Every other compiler I have worked with over many years it does, at least as far as my memory goes.

Just another wee funny with GC.

[Simon Sobisch]

@Vince: OPEN EXTEND + SELECT OPTIONAL = create file if not existing
Where do you see an issue?

[Vincent (Bryan) Coen]

Re posted as o/p from thunderbird does not appear here on SF:

I do not use the 'OPTIONAL' flag as the file is never optional and this mode is not often used by me in any apps...

it is always required. However the file will need to be created on first usage of the application/program.

This application (that is currently in update + testing mode) which uses three files.

Now the mode for these are not locked but consist of 2 using sequential and 1 is ISAM.

It is quite possible that al,l may well go to be ISAM.

The program uses the current ISAM file and one sequential to load up internal tables and at the programs end, then over writes existing file with content of the table having been sorted.
Both of these tables use the 'indexed by' on one key so I have to do manual sorts as against using the SORT verb as it complains about trying to sort tables that have a index present and these indexes are only used for one of their fields, i.e., the primary (or only) key.

The primary file is sequential that is in the following states for open:
1. As output extend (if used to add new data) and as just output if an error condition occurs then is closed before being opened again as extend.

1. For update / amending existing records as I/O.
   This is another reason why I may well change it to ISAM but during testing just using SEQ.

Any amendments that are done, causes the file to be sorted. creating a .BAK file as SEQ and this more for back up and also for if the file is to be migrated to another platform / compiler etc.

Program is a pilots flight log book that caters for PPL, Mil, Instructor and commercial licenses.

It will be placed on SF after I complete testing and manual/docs etc although I have been using it since 1986 with MF workbench but can no longer access the data and cannot recompile using MF Vis Cobol with its very limited 2,200 lines of procedure div (including comments) but still outside that limit with the comments removed - I have a simple program that strips out '*>' using CC1 thru 3 after PROCEDURE DIV is found and yes caters for more programs in the source file.

[Simon Sobisch]

I've read your post twice but I fail to see the actual bug report. Can you please post a minimal sample that shows "another wee funny with GC"? (I suggest to use the bug tracker for this)

[Vincent (Bryan) Coen]

I reported the problem with OPEN EXTEND on a non existing file some years ago to Roger and as for the other and this was my fault in NOT reading the GC PG when trying to use OPEN xyz REVERSED and compiler did NOT report it as unimplemented so only found the problem when testing. IT should report ALL unimplemented features at least as a warning display and on listing if in use.

Got round it by sorting the file DESCENDING key and no have no idea how one would create a fileio.c driver update to support reversed mode on a SEQ or LS file but does seem to indicate a fair amount of work :)

[Simon Sobisch]

I reported the problem with OPEN EXTEND on a non existing file some years ago to Roger

This is fixed in GnuCOBOL 1.1 and 2+ isn't it?

and as for the other and this was my fault in NOT reading the GC PG when trying to use OPEN xyz REVERSED and compiler did NOT report it as unimplemented so only found the problem when testing. IT should report ALL unimplemented features at least as a warning display and on listing if in use.

Agreed, it should. At least 3.0rc-1 warned about this item being obsolete, with [r2761] it now warns OPEN REVERSED (and OPEN WITH NO REWIND) as unimplemented.

Got round it by sorting the file DESCENDING key and no have no idea how one would create a fileio.c driver update to support reversed mode on a SEQ or LS file but does seem to indicate a fair amount of work :)

Should acutally be possible by positioning the file after OPEN and after each READ (+ return EOF if the file cannot be repositioned in front). You could use the CBL_ file routines to implement it with 1.1+ but I've created [feature-requests:#343] to track the actual feature. Note: IBM only does OPEN REVERSE on tape storage, otherwise ignores it and returns 07 on READ, therefore this may would result in multiple configurations...

[Vincent (Bryan) Coen]

OK, I am a wee bit late on the follow up:

Regarding the last paragraph content, a Tape unit processes in sequentual form always and therefore matches in operation (without any multi reel bits) exactly the same as a
organisation sequential (or even line sequential at a push).

Therefore it is logical that OPEN REVERSED should work for this file format.

Continuing on this topic is is also logical to support READ PREVIOUS.. for both OPEN INPUT and INPUT REVERSED as per original standard specs.

The fact that tape units (or even cartridge units) are rarer than hens teeth has nothing to do with it as there is a lot of existing code that uses the REVERSED procedures even if the site has moved over to DASD if only to reduce system sizes and storage realiability in diverse environments as tape has to be seriousy tempature and humidity controlled - far more than say the CPU and other main sub systems.

In a nut shell - READ PREVIOUS should be availble and possibly OPEN REVERSED where the READ REVERSED then cancels out or operation is 'reversed' , i.e., forwards - cant remember what happens on this scenario.