$setsourceformat"free"*>cobc-x-freetestio.cblidentificationdivision.program-id.testio.environmentdivision.configurationsection.input-outputsection.file-control.selectfdmyfileassignto"myfile"organizationindexedaccessdynamiclockmodeautomaticwithlockonrecordrecordkeyfdmyfile-keyfilestatusmyfile-status.datadivision.filesection.fdfdmyfile.1fdmyfile-keypic9(8).working-storagesection.1myfile-statuspicxx.1wss-eofpic9value0.88eofvalue1whensettofalse0.proceduredivision.openoutputfdmyfilemove1tofdmyfile-keywritefdmyfile-keymove2tofdmyfile-keywritefdmyfile-keymove3tofdmyfile-keywritefdmyfile-keymove4tofdmyfile-keywritefdmyfile-keymove5tofdmyfile-keywritefdmyfile-keymove6tofdmyfile-keywritefdmyfile-keymove7tofdmyfile-keywritefdmyfile-keyclosefdmyfileopeni-ofdmyfilemove0tofdmyfile-keystartfdmyfilekey>=fdmyfile-keyend-startreadfdmyfilenextend-readdisplayfdmyfile-key*>1readfdmyfilenextend-readdisplayfdmyfile-key*>2readfdmyfilenextend-readdisplayfdmyfile-key*>3readfdmyfilenextend-readdisplayfdmyfile-key*>4call"subtestio"seteoftofalseperformuntileofreadfdmyfilenextatendseteoftotruenotatenddisplayfdmyfile-keyend-readend-performclosefdmyfilegoback.program-id.subtestio.environmentdivision.input-outputsection.file-control.selectfdmyfileassignto"myfile"organizationindexedaccessdynamiclockmodeautomaticwithlockonrecordrecordkeyfdmyfile-keyfilestatusmyfile-status.datadivision.filesection.fdfdmyfile.1fdmyfile-keypic9(8).working-storagesection.1myfile-statuspicxx.proceduredivision.openi-ofdmyfiledisplay"myfile-status in subtestio - open file : "myfile-statusmove10tofdmyfile-keywritefdmyfile-keydisplay"myfile-status in subtestio - write in file : "myfile-statusclosefdmyfiledisplay"myfile-status in subtestio - close file : "myfile-statusgoback.endprogramsubtestio.endprogramtestio.
It reads 4 records in an indexed file, then calls another program writing in this file a record whose key is greater than all keys and continues to read the file.
Here is the result under MF Cobol:
Under gnucobol, the added record (key 10) is ignored. To display it, I have to close the file when the program returns from 'subtestio', reopen it and start reading again.
I add two small programs testio2 and testio3.
testio2 creates a file, adds records (for simulations), closes, opens again and waits for the operator to press Enter.
In the meantime, another operator starts testio3 that adds 2 records to the file and quits. Then the first operator decides to press enter to read the complete file. Only records 1 to 7 are displayed.
Under MF , you see all 10 records.
The records are not lost. They are stored somewhere and only to be seen when the data file is closed and reopened.
Is it possible to get under Gnucobol the same behaviour as under MF ?
It reads 4 records in an indexed file, then calls another program
writing in this file a record whose key is greater than all keys and
continues to read the file.
Here is the result under MF Cobol:
Under gnucobol, the added record (key 10) is ignored. To display it, I
have to close the file when the program returns from 'subtestio',
reopen it and start reading again.
I add two small programs testio2 and testio3.
testio2 creates a file, adds records (for simulations), closes, opens
again and waits for the operator to press Enter.
In the meantime, another operator starts testio3 that adds 2 records
to the file and quits. Then the first operator decides to press enter
to read the complete file. Only records 1 to 7 are displayed.
Under MF , you see all 10 records.
The records are not lost. They are stored somewhere and only to be
seen when the data file is closed and reopened.
Is it possible to get under Gnucobol the same behaviour as under MF ?
That is correct! When you close the file an reopen it, the records are there.
More astonishing : I added testio4.cbl
Run testio4 and wait. In another console run testio3 to add records 10, 11, 12.
Now try to read key 10 from program testio4 : it is not found. Works well when compiled from MF.
Very strange!
No you are missing it, closing the file in prog 1 allows it to be read correctly by prog2.
This of course does depend on the ISAM lib you are using but I have found from many years of experience to close a file when process is complete and if needed to open it again at the correct point.
I do not trust any file or record locking as that also varies between ISAM libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MF by default implements an extensive file sharing mechanism.
I know the ISAM variants used by GnuCOBOL are less robust than those from MF.
C-Tree-RTG (proprietary from Faircom.com) offers transparent EXTFH compatibility with very sophisticated record level sharing. Faircom has indicated that their ISAM / VSAM sharing mechanism is available for GnuCOBOL.
Micro Focus wise:
Fileshare as a compiler option has been deprecated - the invocation of record level sharing is now implemented as below:
Comments:
This directive is included for compatibility with earlier file-sharing products. When writing new programs you should use the locking syntax rather than this directive.
If any ISAM / VSAM record locking / unlocking . . . is used in the COBOL program the MF file sharing facility is initiated.
Fileshare Guide
Fileshare is a client/server system designed to provide more efficient processing of data files that are accessed concurrently, across a network, by a large number of users.
In addition, Fileshare offers features that are not available with the base COBOL file handler including transaction processing and rollforward recovery logging.
Last edit: Ralph Linkletter 2024-05-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I notice something strange with an indexed file:
Here a a small program called testio:
It reads 4 records in an indexed file, then calls another program writing in this file a record whose key is greater than all keys and continues to read the file.
Here is the result under MF Cobol:
and under gnucobol :
Under gnucobol, the added record (key 10) is ignored. To display it, I have to close the file when the program returns from 'subtestio', reopen it and start reading again.
I add two small programs testio2 and testio3.
testio2 creates a file, adds records (for simulations), closes, opens again and waits for the operator to press Enter.
In the meantime, another operator starts testio3 that adds 2 records to the file and quits. Then the first operator decides to press enter to read the complete file. Only records 1 to 7 are displayed.
Under MF , you see all 10 records.
The records are not lost. They are stored somewhere and only to be seen when the data file is closed and reopened.
Is it possible to get under Gnucobol the same behaviour as under MF ?
Regards.
Using v3.2 final on a Mageia v9 X64 system AND changing your source in
read fdmyfile next end-read display fdmyfile-key >4
close fdmyfile > New line
call "subtestio"
I get :
[vince@applewood tmp]$ cobc -x test1.cbl
[vince@applewood tmp]$ ./test1
00000001
00000002
00000003
00000004
myfile-status in subtestio - open file : 00
myfile-status in subtestio - write in file : 00
myfile-status in subtestio - close file : 00
00000001
00000002
00000003
00000004
00000005
00000006
00000007
00000010
Correct ?
On 28/05/2024 17:09, Alain REYMOND wrote:
That is correct! When you close the file an reopen it, the records are there.
More astonishing : I added testio4.cbl
Run testio4 and wait. In another console run testio3 to add records 10, 11, 12.
Now try to read key 10 from program testio4 : it is not found. Works well when compiled from MF.
Very strange!
OK, found : DB_HOME has to be set to the directory where the files are positioned. Not very intuitive, but it works.
Regards
On 28/05/2024 20:39, Alain REYMOND wrote:
Sorry, had forgotten that one :(
No you are missing it, closing the file in prog 1 allows it to be read correctly by prog2.
This of course does depend on the ISAM lib you are using but I have found from many years of experience to close a file when process is complete and if needed to open it again at the correct point.
I do not trust any file or record locking as that also varies between ISAM libraries.
MF by default implements an extensive file sharing mechanism.
I know the ISAM variants used by GnuCOBOL are less robust than those from MF.
C-Tree-RTG (proprietary from Faircom.com) offers transparent EXTFH compatibility with very sophisticated record level sharing. Faircom has indicated that their ISAM / VSAM sharing mechanism is available for GnuCOBOL.
Micro Focus wise:
Fileshare as a compiler option has been deprecated - the invocation of record level sharing is now implemented as below:
Comments:
This directive is included for compatibility with earlier file-sharing products. When writing new programs you should use the locking syntax rather than this directive.
If any ISAM / VSAM record locking / unlocking . . . is used in the COBOL program the MF file sharing facility is initiated.
Fileshare Guide
Fileshare is a client/server system designed to provide more efficient processing of data files that are accessed concurrently, across a network, by a large number of users.
In addition, Fileshare offers features that are not available with the base COBOL file handler including transaction processing and rollforward recovery logging.
Last edit: Ralph Linkletter 2024-05-29