FWRITE SECTION.
MOVE 01 TO NUMKEY. MOVE "01" TO NUMDES.
WRITE FTEST-REC; INVALID KEY DISPLAY "ERROR".
I have also a section that reads sequentially the file showing all records.
The problem is that if I run the program simultaneously in two windows two records area created althought the file status always returns a valid code (00).
When I do not close the program, the sequential access only shows one record, but if I close the program and run it again, it shows two records with the same primary key.
Any ideas?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, how are the locks managed? Seems that process A writes key 0001, thinks everything is ok. Process B writes key '0001' (using it's own view of the reality of the state of the file) and thinks it's ok. But maybe it isn't when compared to the disk file (which now has 3 processes that need to manage their own view of state. Gets tricky, especially with buffers and delayed flushes to disk.
Would need to see more code, Anon, to get a better understanding.
Or, there is a bug, and it needs to be fixed.
Cheers,
Blue
Last edit: Brian Tiffin 2021-02-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe there to be a bug.
I animated ENQPROB after having inserted a key of 01.
Suspended the animation after the write above
Then ran ENQPROB2
Same file, same locking parameters (I, like ANON , did several combinations of locking criteria - all failed
ENQPROB2 opened the file just fine but failed to find the 01 record written above.
The rts then crapped out even though there was file status code immediately there after.
Attached is a screen shot of disparate processes accessing the same file and using the same key. The 2 test programs are attached.
Depending on the O/S and the ISAM library used the data has not yet seen the media.
I.e., using Linux file io is buffered and when you have lots of RAM heavily so and it can take up to a minutes before it is written out (depending on data size).
So 2 process writing to the same empty file will not have gottem to the drive and highly unlikely at the same time and here even a few millsecs is enough.
This condition does not apply to reading as the buffer space will be used to load in a lot of the data in a file or even all of it depending on the file data and type.
Therefore your test for output will never be a suitable test as a primary output will be to RAM and therefore file status will be good. Now if there is no free space on the drive things can get interesting :)
Some of these issues an also occur under Windows 10 pro 20H2 etc and no I have not tried it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-02-15
would COMMIT work after the write. I haven't tested GnuCOBOL's commit
Excuse the miss. It was discussed a while back, and not mentioned here...
There is an environment setting. COB_SYNC, can be set to Y or P for paranoid.
Would you mind trying some runs with COB_SYNC=P ./prog or =Y?
Performance could take a double order of magnitude hit. Yeah, possibly in the hundreds, as it'll fsync after each write. ;-) That might be ok for a few writes and safer locks, but not for bulk loads or high traffic areas.
Might improve things for this problem, but will slow down disk writes, considerably..
Cheers,
Blue
Last edit: Brian Tiffin 2021-02-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-02-15
Hi Brian, thanks for replying.
Please find attached the code. I tried several combinations of lock mode without any luck.
Again check what buffering is set up as it may well have file buffering set beyond a second, i.e., Win 10 Pro. No I don't know just a guess as it has at its core a linux like kernel.
So I am led to beleave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you test FS-TEST after the WRITE (drop the invalid key clause)
?? write FTEST-REC; invalid key go to SWRITE-30. (what is the ";")
IF FS-FTEST not = zeroes
DISPLAY 'FSFTEST not zero=:" FS-FTEST
IF FS_FTEST = '99'
DISPLAY 'FSFTEST RECORD LOCKED'
END-IF
IF FS_FTEST = '02'
DISPLAY 'FSFTEST DETECTED DUPLICATE KEY (alternate index)"
END-IF
END-IF
FS-FTEST = 22, 23, 02 should be handled as normal ISAM / VSAM status codes.
Can you test for file status 99
99 Record Locked - Record access failed
Seems like a deadly embrace.
After you close the file is there a duplicate key in the index - or is there only a single index entry ?
Status code 68 also suspect but might be sequential access only.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all
I am using GNUCobol 3.1-dev.0.
I wrote a program that allows read and write of an indexed file like this:
SELECT FTEST ASSIGN TO "FTEST"
ORGANIZATION INDEXED
ACCESS DYNAMIC
RECORD KEY NUMKEY
LOCK MODE MANUAL
FILE STATUS FS-FTEST.
FD FTEST.
01 FTEST-REC.
03 NUMKEY PIC 99.
03 NUMDES PIC X(10).
FWRITE SECTION.
MOVE 01 TO NUMKEY. MOVE "01" TO NUMDES.
WRITE FTEST-REC; INVALID KEY DISPLAY "ERROR".
I have also a section that reads sequentially the file showing all records.
The problem is that if I run the program simultaneously in two windows two records area created althought the file status always returns a valid code (00).
When I do not close the program, the sequential access only shows one record, but if I close the program and run it again, it shows two records with the same primary key.
Any ideas?
Hmm, how are the locks managed? Seems that process A writes key 0001, thinks everything is ok. Process B writes key '0001' (using it's own view of the reality of the state of the file) and thinks it's ok. But maybe it isn't when compared to the disk file (which now has 3 processes that need to manage their own view of state. Gets tricky, especially with buffers and delayed flushes to disk.
Would need to see more code, Anon, to get a better understanding.
Or, there is a bug, and it needs to be fixed.
Cheers,
Blue
Last edit: Brian Tiffin 2021-02-15
I believe there to be a bug.
I animated ENQPROB after having inserted a key of 01.
Suspended the animation after the write above
Then ran ENQPROB2
Same file, same locking parameters (I, like ANON , did several combinations of locking criteria - all failed
ENQPROB2 opened the file just fine but failed to find the 01 record written above.
The rts then crapped out even though there was file status code immediately there after.
Attached is a screen shot of disparate processes accessing the same file and using the same key. The 2 test programs are attached.
Ralph
Depending on the O/S and the ISAM library used the data has not yet seen the media.
I.e., using Linux file io is buffered and when you have lots of RAM heavily so and it can take up to a minutes before it is written out (depending on data size).
So 2 process writing to the same empty file will not have gottem to the drive and highly unlikely at the same time and here even a few millsecs is enough.
This condition does not apply to reading as the buffer space will be used to load in a lot of the data in a file or even all of it depending on the file data and type.
Therefore your test for output will never be a suitable test as a primary output will be to RAM and therefore file status will be good. Now if there is no free space on the drive things can get interesting :)
Some of these issues an also occur under Windows 10 pro 20H2 etc and no I have not tried it.
would COMMIT work after the write. I haven't tested GnuCOBOL's commit
https://supportline.microfocus.com/documentation/acucorpproducts/docs/v6_online_doc/gtman3/gt3685.htm
Would need to test, and on fail, trace some libcob C source code.
Excuse the delay in seeing this in the moderator queue.
Blue
Excuse the miss. It was discussed a while back, and not mentioned here...
There is an environment setting.
COB_SYNC, can be set to Y or P for paranoid.Would you mind trying some runs with
COB_SYNC=P ./progor=Y?Performance could take a double order of magnitude hit. Yeah, possibly in the hundreds, as it'll
fsyncafter each write. ;-) That might be ok for a few writes and safer locks, but not for bulk loads or high traffic areas.Might improve things for this problem, but will slow down disk writes, considerably..
Cheers,
Blue
Last edit: Brian Tiffin 2021-02-26
Hi Brian, thanks for replying.
Please find attached the code. I tried several combinations of lock mode without any luck.
Vincent, I'm trying on a Windows system.
Again check what buffering is set up as it may well have file buffering set beyond a second, i.e., Win 10 Pro. No I don't know just a guess as it has at its core a linux like kernel.
So I am led to beleave
Can you test FS-TEST after the WRITE (drop the invalid key clause)
?? write FTEST-REC; invalid key go to SWRITE-30. (what is the ";")
IF FS-FTEST not = zeroes
DISPLAY 'FSFTEST not zero=:" FS-FTEST
IF FS_FTEST = '99'
DISPLAY 'FSFTEST RECORD LOCKED'
END-IF
IF FS_FTEST = '02'
DISPLAY 'FSFTEST DETECTED DUPLICATE KEY (alternate index)"
END-IF
END-IF
FS-FTEST = 22, 23, 02 should be handled as normal ISAM / VSAM status codes.
Can you test for file status 99
99 Record Locked - Record access failed
Seems like a deadly embrace.
After you close the file is there a duplicate key in the index - or is there only a single index entry ?
Status code 68 also suspect but might be sequential access only.