I have many files in my data that are Micro FOCUS COBOL IDXFORMAT(4) and IDXFORMAT(1). I have one client that is using IDXFORMAT(8). I would like all of my clients on the IDXFORMAT(8) because they need to keep history, the more the better. What ISAM would work, once I write programs to port all the MF data to Flat ASCII files, and then another set to re-index them.
And Where would I find this ISAM to download?
Still working on how to deal with the other continuation Bug when using std=mf or std-mfstrict, but
going to try moving a small group of programs and not have them in FIXED Format COBOL syntax which is what MicroFOCUS uses.
Also, as a NOTE Micro FOCUS COBOL was sold to ROCKETSOFTWARE today. I received the announcements. I know they are going to make it subscription service to use the MF COBOL Compiler and RTS. Currently, you can pay the annual support fee, and you get support and access to the new versions. but you can choose to not pay support, and still use the software. I just know they are going to pull that as every other software vendor is doing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's a difficult question.
You need to select an index format that exists in MF and is GnuCOBOL compatible ?
GnuCOBOL wise the choices are
BDB (Berkley)
VBISAM
VISAM
Here is the list of MF IDXFORMAT(s):
SET IDXFORMAT "An integer" representing the type to use.
0 System-specific default (for this COBOL system, same as 3).
1 C-ISAM format.
2 Micro Focus Level II format.
3 Micro Focus indexed file format.
4 An optimized form of Micro Focus indexed file format, for fast duplicate key handling.
5 Btrieve with ANSI.
6 Btrieve without ANSI.
7 RLIO format indexed files.
8 Large indexed.
10 Reserved.
11 Mainframe print file format.
12-13 Reserved.
14 Heap file.
15 ESDS.
Few, if any of the MF formats are compatible with GnuCOBOL.
Chuck H did successfully support C-ISAM with some Gnu variant.
Best to converse with Chuck for his insights.
You may want to consider using EXTFH which can provide a degree of independence from the ISAM vendor you select.
Realistically BDB is probably the best choice.
However BDB has some licensing restrictions that concerns many users of GnuCOBOL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you want to have an ISAM file handler that works perfectly with GnuCOBOL 3.2 (including record locking for multi-user applications) and does not require any license fees then you can use VBISAM 2.1.1.
You can find a current version here in my post:
I think that Simon should weigh in on this discussion. If my memory is correct I recall Simon mentioning that VBISAM 2.1.1 was built using the COBOL-IT source code and as such may have some license issues.
So my advice would be to wait for clarification from Simon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a note to COBOL-IT: they did some changes to VBISAM which was for some time their primary ISAM handler. That doesn't change anything to the license - you are free to use it and even distribute binaries based on this.
The upcoming V-ISAM (this year!) won't be based on any version that COBOL-IT touched - but this is because of the Copyright, not because of the license.
Files generated with any version of VBISAM are expected to be usable with V-ISAM as well, "current" versions of V-ISAM/VBISAM are - as well as the non-free D-ISAM - able to handle C-ISAM compatible files - for MF that is IDXFORMAT"1" - newer versions aren't portable.
There may be some external libraries that can handle other MF formats as well, that also include an EXTFH compatible interface (I am not aware of a free software for that) - in this case you could use the EXTFH interface. You also could use MF's EXTFH interface from GnuCOBOL and then use all of their formats - but that means you need MF installed and licensed as well.
During a migration period, you could also let MF operate with GnuCOBOL's EXTFH interface (and therefore use whatever GnuCOBOL is configured for from there) - or use an external libraries' EXTFH interface in both GC and MF.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have many files in my data that are Micro FOCUS COBOL IDXFORMAT(4) and IDXFORMAT(1). I have one client that is using IDXFORMAT(8). I would like all of my clients on the IDXFORMAT(8) because they need to keep history, the more the better. What ISAM would work, once I write programs to port all the MF data to Flat ASCII files, and then another set to re-index them.
And Where would I find this ISAM to download?
Still working on how to deal with the other continuation Bug when using std=mf or std-mfstrict, but
going to try moving a small group of programs and not have them in FIXED Format COBOL syntax which is what MicroFOCUS uses.
Also, as a NOTE Micro FOCUS COBOL was sold to ROCKETSOFTWARE today. I received the announcements. I know they are going to make it subscription service to use the MF COBOL Compiler and RTS. Currently, you can pay the annual support fee, and you get support and access to the new versions. but you can choose to not pay support, and still use the software. I just know they are going to pull that as every other software vendor is doing.
That's a difficult question.
You need to select an index format that exists in MF and is GnuCOBOL compatible ?
GnuCOBOL wise the choices are
BDB (Berkley)
VBISAM
VISAM
Here is the list of MF IDXFORMAT(s):
SET IDXFORMAT "An integer" representing the type to use.
0 System-specific default (for this COBOL system, same as 3).
1 C-ISAM format.
2 Micro Focus Level II format.
3 Micro Focus indexed file format.
4 An optimized form of Micro Focus indexed file format, for fast duplicate key handling.
5 Btrieve with ANSI.
6 Btrieve without ANSI.
7 RLIO format indexed files.
8 Large indexed.
10 Reserved.
11 Mainframe print file format.
12-13 Reserved.
14 Heap file.
15 ESDS.
Few, if any of the MF formats are compatible with GnuCOBOL.
Chuck H did successfully support C-ISAM with some Gnu variant.
Best to converse with Chuck for his insights.
You may want to consider using EXTFH which can provide a degree of independence from the ISAM vendor you select.
Realistically BDB is probably the best choice.
However BDB has some licensing restrictions that concerns many users of GnuCOBOL.
If you want to have an ISAM file handler that works perfectly with GnuCOBOL 3.2 (including record locking for multi-user applications) and does not require any license fees then you can use VBISAM 2.1.1.
You can find a current version here in my post:
https://sourceforge.net/p/gnucobol/discussion/cobol/thread/49d76dc54e/#1a3c
Otherwise if you do not care about licensing restrictions you can use BDB, as Ralph said.
Klaus,
I think that Simon should weigh in on this discussion. If my memory is correct I recall Simon mentioning that VBISAM 2.1.1 was built using the COBOL-IT source code and as such may have some license issues.
So my advice would be to wait for clarification from Simon.
Just a note to COBOL-IT: they did some changes to VBISAM which was for some time their primary ISAM handler. That doesn't change anything to the license - you are free to use it and even distribute binaries based on this.
The upcoming V-ISAM (this year!) won't be based on any version that COBOL-IT touched - but this is because of the Copyright, not because of the license.
Files generated with any version of VBISAM are expected to be usable with V-ISAM as well, "current" versions of V-ISAM/VBISAM are - as well as the non-free D-ISAM - able to handle C-ISAM compatible files - for MF that is
IDXFORMAT"1"- newer versions aren't portable.There may be some external libraries that can handle other MF formats as well, that also include an EXTFH compatible interface (I am not aware of a free software for that) - in this case you could use the EXTFH interface. You also could use MF's EXTFH interface from GnuCOBOL and then use all of their formats - but that means you need MF installed and licensed as well.
During a migration period, you could also let MF operate with GnuCOBOL's EXTFH interface (and therefore use whatever GnuCOBOL is configured for from there) - or use an external libraries' EXTFH interface in both GC and MF.