I finally succeed to install Gnucobol 3.2 with GMP, PDCurses, VBIsam, db-18.1.40 etc. Also my C programm, that is combined with the cobol programm, is being compiled now without errors using MINGW.
But after starting my Cobol Programm first time this error message comes:
make # Build the GnuCOBOL compiler
make check # Test the GnuCOBOL build
make test # Run NIST COBOL 85 test suite
make install # Prepare Install format
make distmingw # Prepare default binary folders
Gnucobol still can not read my old C-ISAM files.
Is there a solution for GC 3.2 or should I wait for GC 4?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
V*ISAM will only handle MF's IDXFORMAT"1" files - the others are not actually C-ISAM files
GnuCOBOL may need to be adjusted (you have a source build, so you can do that) if the index file is not named FILE.idx and/or the data file is not named FILE.dat (=they both have their suffix) [just edit fileio.c as needed, then recompile - if needed]
without a patch V*ISAM does not correctly handle variable-length files - but MF's IDXFORMAT"1" forbids that completely, so that should not be an issue
V*ISAM does not handle KEYCOMPRESS - if you've used that on the MF side, then you need to unload/load them without it
you need a quite new version of VBISAM (or V-ISAM with renamed files after install) to be able read MF's C-ISAM files
@chaat has the most recent experience with V*ISAM on MinGW builds with reading MF's IDXFORMAT"1" files and may be able to help more if the points above are clear.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you still have the compiler that creatd the program that processed this data file ?
If you do then create a simple program to read the ISAM file and create a sequential one where all binary fields are tranlated to display (PIC 9(10).99 etc) on the output file and use that as input to a GC program.
Any fields that are X or A can be transferred as they are using X or A.
This is the normal way to do it - IF you have access to the original Cobol compiler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a binary available for Windows which includes VISAM-2.2, it is build on the GNUCOBOL 3.2 release with a few fixes I've been working on with Simon. I used as a starting point the VISAM-2.2 source from Ron Norman's website. I did have to make some changes to 6 modules in VISAM as well as the FILEIO.C module in GNUCOBOL to get this to work as well as it does with the testsuite included in GNUCOBOL. It is still failing with EXTFH using VISAM, but other than that it passes the rest of the tests.
Ron Norman is in the process of testing my changes and making improvements to the VISAM 2.2 source code. However he is traveling and indicated that he will not be working on this until March. I will also be traveling from the United States to Portugal for 3 months starting on Feb 14. I may have some time in the evenings to work on this from Portugal but it would be limited as this is a vacation.
A note of caution, in addition to the issues that Simon mentions above, my experience with some initial performance testing is that VISAM is much slower than Berkeley DB. This is most likely due to VISAM having no buffering or caching, at least from my limited analysis on the source code.
ps... my version does have a fix for variable length records so that should now work. Also record locking code does execute but it has NOT been tested using separate processes.
I will monitor this discussion, you can also reach out to me via direct messaging and I can try to help. For the next two weeks my availability will be limited.
If you execute "cobcrun --info" it will display the build components. This binary also includes GCSORT and COBWORX debugger.
have fun...
Chuck Haatvedt
Last edit: Chuck Haatvedt 2024-02-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-02-10
Hi Simon,
VISAM will only handle MF's IDXFORMAT"1" files - the others are not actually C-ISAM files
GnuCOBOL may need to be adjusted (you have a source build, so you can do that) if the index file is not named FILE.idx and/or the data file is not named FILE.dat (=they both have their suffix) [just edit fileio.c as needed, then recompile - if needed]
without a patch VISAM does not correctly handle variable-length files - but MF's IDXFORMAT"1" forbids that completely, so that should not be an issue
V*ISAM does not handle KEYCOMPRESS - if you've used that on the MF side, then you need to unload/load them without it
you need a quite new version of VBISAM (or V-ISAM with renamed files after install) to be able read MF's C-ISAM files
1) Thanks for this information. Right now I do not know weather all points are considered. I am not the Cobol Programmer and I need some time to find out e.g. the Point about compressed keys.
2) Maybe lets start to modify the libcob/fileio.c. If I am dare, im not sure where to make the changing. It Would be great if you do the changing.
3) My VBISAM version is 2.0.1 Is it new enough?
I have time! Du not hurry :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2024-02-10
Hi Chuck,
I want to thank you also very much. Maybe it is too early for C-ISAM right now. Think about to buy C-ISAM licence of IBM. Has anybody experience with it together with GC 3.2?
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) Yesterday I made two changes to the "fileio.c."
Relaced ... "%s.dat", filename); to ... "%s", filename);
This were in two lines (The reason was, that my data files have no extension).
After "configure" there was a problem in "make test". "make test" hangs at something like 209.
2) I am not 100 % sure how to test the binary win version of Chuck. Just replace the folders in "c:\mingw\msys\gnucobol-3.2_win" ? Or is there more to do?
3) Good to read that Chuck could add the variable length of VBISAM lines.
Right now, I would be happy to get the Cobol/C-ISAM project runnig, but if I am honest, it has enough time.
Our cobol program runs good on a very old but maintained Linux system.
I can see that there are many activities to improve C-ISAM with gnucobol. I keep an eye on the project an continue later.
What do you think?
Best regards
Ludger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
for my Windows version, just create a folder with any name, for example, GNUCOBOL.
Then extract GNUCOBOL-X32-VISAM.7z to that folder. Then change directory to that folder and execute the following command
set_env.cmd
This should set up the cobol compile with its temporary environment variables.
then change directory to your working directory and issue the following command to ensure that the gnucobol compiler environment is setup correctly...
cobcrun --info
that should work..
ps i'm online in SKYPE now.
chuck.haatvedt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In addition I have to say that the C-ISAM files are very old. Maybe 30 years or older.
This makes it quite likely that they are really C-ISAM files (MF's IDXFORMAT"1"), so there's hope you can quite easily read them using any of the ISAM handlers (you possibly need a recent V*ISAM, but the one from Chuck should be fine).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The data files are now in the "c:\FUJCBL\" folder.
Now I am getting this error message:
$ ./BDBMAKE.exe
BDB0004 fop_read_meta: C:\FUJCBL\FEB_12_CISAM: unexpected file type or format
BDB0004 fop_read_meta: C:\FUJCBL\FEB_12_CISAM: unexpected file type or format
CWH5VSAM OPEN FAILED RC=:30
CWH5VSAM WRITE FAILED RC=:48
What do you say?
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@sf-mensch
This file was built for Chuck (CWH. . .)
Chuck needed code to build and process C-ISAM as well BDB
The code I sent to ludger creates a C-ISAM (MF IDXFORMAT"1") file
Micro Focus permits compiler options to be specified via $SET statements
See the first line of the program I sent.
$SET IDXFORMAT"1" QUAL DEFAULTBYTE"00" ANS85 NOTRUNC ODOSLIDE
Notice the IDXFORMAT"1" in the compiler directives
Chuck used files created by this program to vet the C-ISAM support in VISAM.
I have an idea.
Perhaps ludger can provide a file from his test of existing C-ISAM files.
If there is a small C-ISAM file including the .IDX that luger could send to me?
I can then determine if it is a MF IDXFORMAT"1" file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes example of Ralph is possibly for BDB and not for VBISAM. Do you have a similar sample for C-ISAM/VBISAM? It seams to be a simple error. Maybe my binaries are not correct.
Best regards
Ludger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, libcob (the GnuCOBOL runtime) outputs an error received from the BDB library - this only happens if the GnuCOBOL runtime is configured to use BDB which "sees" a file that isn't in BDB format.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I finally succeed to install Gnucobol 3.2 with GMP, PDCurses, VBIsam, db-18.1.40 etc. Also my C programm, that is combined with the cobol programm, is being compiled now without errors using MINGW.
But after starting my Cobol Programm first time this error message comes:
libcob: Fehler: Permanenter Dateifehler (status = 30) for file A10DAT ('../dat1/ASTAMM' => ..\dat1\ASTAMM)
I expect it has something to do, that Gnucobol 3.2 can not read the C-ISAM files.
To get C-ISAM files able to read, I did this:
confirgure VBISAM with:
./configure --prefix=/mingw --enable-cisamcompat
make
make check
make install
Then I configured and installed the Gnucompile 3.2 again with:
./configure --prefix=/mingw -–with-vbisam --disable-rpath
make # Build the GnuCOBOL compiler
make check # Test the GnuCOBOL build
make test # Run NIST COBOL 85 test suite
make install # Prepare Install format
make distmingw # Prepare default binary folders
Gnucobol still can not read my old C-ISAM files.
Is there a solution for GC 3.2 or should I wait for GC 4?
In general:
@chaat has the most recent experience with V*ISAM on MinGW builds with reading MF's IDXFORMAT"1" files and may be able to help more if the points above are clear.
Do you still have the compiler that creatd the program that processed this data file ?
If you do then create a simple program to read the ISAM file and create a sequential one where all binary fields are tranlated to display (PIC 9(10).99 etc) on the output file and use that as input to a GC program.
Any fields that are X or A can be transferred as they are using X or A.
This is the normal way to do it - IF you have access to the original Cobol compiler.
Ludger,
I have a binary available for Windows which includes VISAM-2.2, it is build on the GNUCOBOL 3.2 release with a few fixes I've been working on with Simon. I used as a starting point the VISAM-2.2 source from Ron Norman's website. I did have to make some changes to 6 modules in VISAM as well as the FILEIO.C module in GNUCOBOL to get this to work as well as it does with the testsuite included in GNUCOBOL. It is still failing with EXTFH using VISAM, but other than that it passes the rest of the tests.
Ron Norman is in the process of testing my changes and making improvements to the VISAM 2.2 source code. However he is traveling and indicated that he will not be working on this until March. I will also be traveling from the United States to Portugal for 3 months starting on Feb 14. I may have some time in the evenings to work on this from Portugal but it would be limited as this is a vacation.
my windows binary is here
https://www.dropbox.com/scl/fi/smn04hfzcro701mayti97/GNUCOBOL-X32-VISAM.7z?rlkey=w08niz0cry4q0txt6exp21aon&dl=0
A note of caution, in addition to the issues that Simon mentions above, my experience with some initial performance testing is that VISAM is much slower than Berkeley DB. This is most likely due to VISAM having no buffering or caching, at least from my limited analysis on the source code.
ps... my version does have a fix for variable length records so that should now work. Also record locking code does execute but it has NOT been tested using separate processes.
I will monitor this discussion, you can also reach out to me via direct messaging and I can try to help. For the next two weeks my availability will be limited.
If you execute "cobcrun --info" it will display the build components. This binary also includes GCSORT and COBWORX debugger.
have fun...
Last edit: Chuck Haatvedt 2024-02-09
just a quick note, I fixed the link in my previous post...
Hi there,
Yes I can see, it is not easy with C-ISAM. Maybe just have to change the name of ASTAMM to ASTAMM.dat (also in Cobol Code).
But today I am very busy. Hope to have enough time at the weekend.
Thank you all until now!
Don't change anything in your code or on the disk - just change libcob/fileio.c.
Hm, I likely include the changes to search for both and make the creation configurable soon, so you don't need to adjust the code in the future.
Hi Simon,
Perfect! That is a good solution.
Thanks
Hi Simon,
1) Thanks for this information. Right now I do not know weather all points are considered. I am not the Cobol Programmer and I need some time to find out e.g. the Point about compressed keys.
2) Maybe lets start to modify the libcob/fileio.c. If I am dare, im not sure where to make the changing. It Would be great if you do the changing.
3) My VBISAM version is 2.0.1 Is it new enough?
I have time! Du not hurry :-)
Hi Chuck,
I want to thank you also very much. Maybe it is too early for C-ISAM right now. Think about to buy C-ISAM licence of IBM. Has anybody experience with it together with GC 3.2?
Best regards
I've not used C-ISAM from IBM, I don't know if it is still marketed. However there are some other options to consider as well.
D-ISAM https://www.isam.ca/
The following may require a small EXTFH program but that should be pretty easy to do.
C-TREE-rtg https://www.faircom.com/products/c-treertg
Chuck Haatvedt
Hello Chuck,
Hello Simon,
Hello Vincent,
Yes I am a little bit undecided what to do.
1) Yesterday I made two changes to the "fileio.c."
Relaced ... "%s.dat", filename); to ... "%s", filename);
This were in two lines (The reason was, that my data files have no extension).
After "configure" there was a problem in "make test". "make test" hangs at something like 209.
2) I am not 100 % sure how to test the binary win version of Chuck. Just replace the folders in "c:\mingw\msys\gnucobol-3.2_win" ? Or is there more to do?
3) Good to read that Chuck could add the variable length of VBISAM lines.
Right now, I would be happy to get the Cobol/C-ISAM project runnig, but if I am honest, it has enough time.
Our cobol program runs good on a very old but maintained Linux system.
I can see that there are many activities to improve C-ISAM with gnucobol. I keep an eye on the project an continue later.
What do you think?
Best regards
Ludger
Ludger,
for my Windows version, just create a folder with any name, for example, GNUCOBOL.
Then extract GNUCOBOL-X32-VISAM.7z to that folder. Then change directory to that folder and execute the following command
set_env.cmd
This should set up the cobol compile with its temporary environment variables.
then change directory to your working directory and issue the following command to ensure that the gnucobol compiler environment is setup correctly...
cobcrun --info
that should work..
ps i'm online in SKYPE now.
chuck.haatvedt
Hi Chuck,
your binary is running. Thanks for instructions.
After compiling my project again, the error message is the same as the old one.
ludger@DESKTOP-JBN6R62 /c/mingw/u0/pro
$ ./AUFTRAG1.exe
libcob: Fehler: Permanenter Dateifehler (status = 30) for file A10DAT ('c:' => c:\mingw\u0\dat1\ASTAMM)
This is the cobol code of the ASTAMM file:
What do you think?
Hi Chuck,
I still think about this easy error. Simon said that ASTAMM is just a data file. C-Isam is only reposible für IDX Files.
Maybe something went wrong at the installation of your binary version.
"cobcrun --info" runs but the statistic could also be of my old GC 3.2.
There was a Windows security message during set the "set_env.cmd" command.
How to find out your binary runs?
Attached are a test program to create a C-ISAM file
The C-ISAM file(s) I created with MF IDXFORMAT"1"
I would run your existing test with an OPEN INPUT on the files I have provided.
These files worked with Chuck's COBC and runtime.
You obviously need to change the folder name in your existing test case.
See if you can open the files I sent with a status code of "00"
Last edit: Ralph Linkletter 2024-02-11
Hi Ralph,
Your files has been copied to the data directory. I renamed them to:
ASTAMM.idx
ASTAMM
I did not change the cobol code.
Now the error message is different to the old one.
$ ./AUFTRAG1.exe
BDB0004 fop_read_meta: c:\mingw\u0\dat1\ASTAMM: unexpected file type or format
libcob: Fehler: Permanenter Dateifehler (status = 30) for file A10DAT ('c:' => c:\mingw\u0\dat1\ASTAMM)
Seams that the path is not the problem now!
In addition I have to say that the C-ISAM files are very old. Maybe 30 years or older.
This makes it quite likely that they are really C-ISAM files (MF's IDXFORMAT"1"), so there's hope you can quite easily read them using any of the ISAM handlers (you possibly need a recent V*ISAM, but the one from Chuck should be fine).
Hi Ralph again,
Excuse. I did not see the file BDBMAKE.COB.
The data files are now in the "c:\FUJCBL\" folder.
Now I am getting this error message:
$ ./BDBMAKE.exe
BDB0004 fop_read_meta: C:\FUJCBL\FEB_12_CISAM: unexpected file type or format
BDB0004 fop_read_meta: C:\FUJCBL\FEB_12_CISAM: unexpected file type or format
CWH5VSAM OPEN FAILED RC=:30
CWH5VSAM WRITE FAILED RC=:48
What do you say?
Best regards
Given the BDB error message asking with the BDB reference fop_read_meta - that's obviously a build that uses BDB, not any ISAM library.
If you build it on your own pass --with-vbisam to your configure line.
@sf-mensch
This file was built for Chuck (CWH. . .)
Chuck needed code to build and process C-ISAM as well BDB
The code I sent to ludger creates a C-ISAM (MF IDXFORMAT"1") file
Micro Focus permits compiler options to be specified via $SET statements
See the first line of the program I sent.
Notice the IDXFORMAT"1" in the compiler directives
Chuck used files created by this program to vet the C-ISAM support in VISAM.
I have an idea.
Perhaps ludger can provide a file from his test of existing C-ISAM files.
If there is a small C-ISAM file including the .IDX that luger could send to me?
I can then determine if it is a MF IDXFORMAT"1" file.
Hi Simon,
Yes example of Ralph is possibly for BDB and not for VBISAM. Do you have a similar sample for C-ISAM/VBISAM? It seams to be a simple error. Maybe my binaries are not correct.
Best regards
Ludger
No, libcob (the GnuCOBOL runtime) outputs an error received from the BDB library - this only happens if the GnuCOBOL runtime is configured to use BDB which "sees" a file that isn't in BDB format.
Hi Simon,
yes I added Chucks libray again and get this concrun --info:
Is it correct?
Thanks!
And now the attachment ;-)