In the "NEWS" file I found only these few lines about EXTFH.
file handling: include support for a callable EXTFH interface also provided
by several compilers including Micro Focus
This allows users to insert an external file handler while retaining
all the normal COBOL I/O functions with a possible callback to libcob.
To have the compiled program call yourfh() for file I/O use: cobc -fcallfh=yourfh
In turn yourfh() may call EXTFH() to use I/O functions from GnuCOBOL.
The external file handler can also be directly invoked from COBOL, too,
using CALL "EXTFH".
Note: Not each flag contained in the FCD3 is handled already
Support for the EXTFH has been greatly enhanched and now includes support
for FH--FCD and FH--KEYDEF, fixed use of different attributes and changing
pointers and now supports - for 32-bit builds - an internal conversion
between FCD2 and FCD3 for cases where existing programs are coded with FCD2
From Microfocus documentation:
Chapter 10: Callable File Handler (ExtFH)
The Callable File Handler, ExtFH, is a loadable file handling subsystem with an open architecture. This means it can be used independently with a variety of programming languages, enabling you to create powerful file processing tools, as well as sophisticated database applications.
This chapter describes the call interface to the file handler and the special features available.
10.1 Overview
The Callable File Handler (ExtFH) enables programs to perform complex file operations that are not usually directly supported by your language syntax.
Using the interface described in this chapter, you can access ExtFH directly from your program using your language's calling convention. All input and output can be performed without language dependent I/O syntax.
The Callable File Handler provides many benefits, such as:
Fast platform-independent file handling.
Access to COBOL files by non-COBOL languages.
Mixed-language file handling on common files.
Record locking.
Data compression.
You can use the call interface to create sophisticated applications, for example, file conversion programs, file reorganization utilities and file restoration utilities are all possible uses. You could even write your own database management system using the Callable File Handler.
You can write your own file handler and run it in place of ExtFH, as long as it conforms to the call interface defined in this chapter.
I found various technical explanations on how to use EXTFH but my question is the following.
For what purpose could/should I use EXTFH into a GnuCOBOL program?
What features/possibilities does EXTFH add to the GnuCOBOL developer ?
I have already searched in this forum and on the web for a clear explanation but I was unable to understand the real usefulness of EXTFH for a COBOL developer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EXTFH is not an application "tool".
Rather it is a "tool" for creating a "pipe" between disparate I-O system interfacing or creating utilities where file characteristics (record length, keypos, data set name (file name) . . .) are not known until execution.
For instance I use EXTFH to implement IDCAMS, a file utility.
IDCAMS specifies dataset characteristics as control cards.
The sort exit routines E15 (present a record to sort) and E35 (receive a record from sort) might be examples that are more common place.
I have also used EXTFH with Micro Focus during the time frame where MF had not implemented WRITE AFTER ADVANCING correctly.
The Faircom CTree-RTG product implements a robust ISAM / VSAM file sharing service via COBOL programs compiled with EXTFH. All ISAM I-O is vectored to the CTree file sharing mechanism. The interface is the EXTFH service as represented by the FCD parameters.
The Micro Focus ISAM support relies upon EXTFH, enabling a file sharing service
Hope this helps.
Ralph
Last edit: Ralph Linkletter 2024-06-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As noted by Ralph, a COBOL programmer may use that to adjust file attributes at runtime (then using an EXTFH program in COBOL to adjust the parameters before doing the callback into the COBOL runtime). You can use the extfh copybook that is distributed with GnuCOBOL for that.
Instead of the callback you can also do the fileo as your own implementation, for example calling sql libraries or REST or ...)
You can also implement your own statistics, logging, checking for consistency between files, ...).
To be correct one would say that EXTFH is primarily an API for file io. And as it is kind of an industry standard you can use the same EXTFH programs also in several COBOL runtimes (even without any special linking).
It also allows to use libcob's fileio from ACUCUBOL/MicroFocus/IBM COBOL/... and vice versa (which of course needs a license). This can also help during migration phases.
Thx to you both.
What I'm trying to understand is not a technical definition of EXTFH but a functional explanation of what a real use of EXTFH can be done by a GnuCOBOL developer.
What can I do with a CALL EXTFX xxxxx that I can't already do with the standard GnuCOBOL verbs OPEN, READ, WRITE etc...
What I have understood so far I will summarize in the following points.
Can you tell me if I understood correctly?
Example 1.
Write a GnuCOBOL program that accepts as parameters: file type (sequential, relative indexed etc ...), number and length of keys, both the primary and any alternative keys.
This GnuCOBOL program, always the same, will be able to create various types of files (sequential, relative, indexed ) with a primary key that can be 5 bytes or 20 or 30 bytes long, with a record length of 100 bytes or 1000 bytes etc etc .. simply by accepting parameters with one or many ACCEPT statements ... with as an example an open output and a close.
Example 2.
Allow a Microfocus COBOL (or AcuCOBOL or RM Cobol or Realia COBOL ...) program to read an indexed file that was created with a GnuCOBOL program that used BDB or VB-ISAM.
Example 3a.
Conversely, read from the GnuCOBOL program an indexed file created by a Microfocus COBOL program with its proprietary system for example IDX4.
Example 3b.
Conversely, read from the GnuCOBOL program an indexed file created by a Reaia COBOL program with its proprietary Realia index system.
@ Simon: I didn't quite understand what you mean when you say: You can also implement your own statistics, logging, checking for consistency between files, ...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
statistics :
Each I-O operation can record the number of times a read, write, delete, open - any file I-O statement. You could record the start of the call to EXTFH, the return from EXTFH - even the before and after image of the record processed.
I implement recording stats from the file activity I have implemented in my EXTFH services.
The intent to provide operation reporting performance / consumption.
Example 2. - thru 3B would require that EXTFH be available in the non Gnu environment.
EXTFH also enable the du jour languages to have ISAM / VSAM available.
Ralph
Last edit: Ralph Linkletter 2024-06-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
statistics :
Each I-O operation can record the number of times a read, write, delete, open - any file I-O statement. You could record the start of the call to EXTFH, the return from EXTFH - even the before and after image of the record processed.
I implement recording stats from the file activity I have implemented in my EXTFH services.
The intent to provide operation reporting performance / consumption.
ok but we don't need to have EXTFH to implement usage statistics for I-O operations.
We can do it even without EXTFH, creating a "statistic file" and using normal I-O verbs..
What is the advantage of using EXTFH to store I-O statistics ?
.
Example 2. - thru 3B would require that EXTFH be available in the non Gnu environment.
Ok Do you mean that therefore EXTFH must be available in the Microfocus environment (I see that it is available), AcuCobol, Realia COBOL etc ... correct?
Consequently it does not affect GnuCOBOL's EXTFH...
.
EXTFH also enable the du jour languages to have ISAM / VSAM available.
This means that I could read from a Python or Visual Basic program etc etc ... an indexed file written with the GnuCOBOL program using BDB or VB-ISAM. correct ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you use EXTFH you can gather the statistics and only need to recompile the program - no change in them needed at all!
create EXTFH module "myiostats.cbl" that uses the "xfhfcd3.cpy" for its LINKAGE and to get the 88 values, which only counts the statistics and possibly write them out when a CLOSE was requested; filter in that program as you like (for example for the filename, filetype, ...) before adding to the statistics; end with CALL "EXTFH" USING fcd-record to let libcob do the actual file io; compile with with cobc -c myiostats.cbl
compile your programs with an additional -fcallfh=myiostats myiostats.o to route all io through them
Consequently it does not affect GnuCOBOL's EXTFH...
To use EXTFH in any COBOL environment that needs to provide an option like GnuCOBOL has with -fcallfh or MF with its CALLFH directive (GC supports that when included in source files as well). So this part is a "yes".
To be able to call another COBOL's EXTFH entry point from a GnuCOBOL module to allow the io be routed to that, this environment also needs this entry point and a way to call it directly or via a "to GnuCOBOL foreign" COBOL module that calls into that.
So this part means that you can only use it from a GnuCOBOL module if there's some way to access it.
This means that I could read from a Python or Visual Basic program etc etc ... an indexed file written with the GnuCOBOL program using BDB or VB-ISAM. correct ?
Yes. As along as you use the applicable structure to call into EXTFH (the C structure is part of libcob/common.h).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the "NEWS" file I found only these few lines about EXTFH.
From Microfocus documentation:
Chapter 10: Callable File Handler (ExtFH)
The Callable File Handler, ExtFH, is a loadable file handling subsystem with an open architecture. This means it can be used independently with a variety of programming languages, enabling you to create powerful file processing tools, as well as sophisticated database applications.
This chapter describes the call interface to the file handler and the special features available.
10.1 Overview
The Callable File Handler (ExtFH) enables programs to perform complex file operations that are not usually directly supported by your language syntax.
Using the interface described in this chapter, you can access ExtFH directly from your program using your language's calling convention. All input and output can be performed without language dependent I/O syntax.
The Callable File Handler provides many benefits, such as:
Fast platform-independent file handling.
Access to COBOL files by non-COBOL languages.
Mixed-language file handling on common files.
Record locking.
Data compression.
You can use the call interface to create sophisticated applications, for example, file conversion programs, file reorganization utilities and file restoration utilities are all possible uses. You could even write your own database management system using the Callable File Handler.
You can write your own file handler and run it in place of ExtFH, as long as it conforms to the call interface defined in this chapter.
I found various technical explanations on how to use EXTFH but my question is the following.
For what purpose could/should I use EXTFH into a GnuCOBOL program?
What features/possibilities does EXTFH add to the GnuCOBOL developer ?
I have already searched in this forum and on the web for a clear explanation but I was unable to understand the real usefulness of EXTFH for a COBOL developer.
EXTFH is not an application "tool".
Rather it is a "tool" for creating a "pipe" between disparate I-O system interfacing or creating utilities where file characteristics (record length, keypos, data set name (file name) . . .) are not known until execution.
For instance I use EXTFH to implement IDCAMS, a file utility.
IDCAMS specifies dataset characteristics as control cards.
The sort exit routines E15 (present a record to sort) and E35 (receive a record from sort) might be examples that are more common place.
I have also used EXTFH with Micro Focus during the time frame where MF had not implemented WRITE AFTER ADVANCING correctly.
The Faircom CTree-RTG product implements a robust ISAM / VSAM file sharing service via COBOL programs compiled with EXTFH. All ISAM I-O is vectored to the CTree file sharing mechanism. The interface is the EXTFH service as represented by the FCD parameters.
The Micro Focus ISAM support relies upon EXTFH, enabling a file sharing service
Hope this helps.
Ralph
Last edit: Ralph Linkletter 2024-06-09
As noted by Ralph, a COBOL programmer may use that to adjust file attributes at runtime (then using an EXTFH program in COBOL to adjust the parameters before doing the callback into the COBOL runtime). You can use the extfh copybook that is distributed with GnuCOBOL for that.
Instead of the callback you can also do the fileo as your own implementation, for example calling sql libraries or REST or ...)
You can also implement your own statistics, logging, checking for consistency between files, ...).
To be correct one would say that EXTFH is primarily an API for file io. And as it is kind of an industry standard you can use the same EXTFH programs also in several COBOL runtimes (even without any special linking).
It also allows to use libcob's fileio from ACUCUBOL/MicroFocus/IBM COBOL/... and vice versa (which of course needs a license). This can also help during migration phases.
Thx to you both.
What I'm trying to understand is not a technical definition of EXTFH but a functional explanation of what a real use of EXTFH can be done by a GnuCOBOL developer.
What can I do with a
CALL EXTFX xxxxxthat I can't already do with the standard GnuCOBOL verbs OPEN, READ, WRITE etc...What I have understood so far I will summarize in the following points.
Can you tell me if I understood correctly?
Example 1.
Write a GnuCOBOL program that accepts as parameters: file type (sequential, relative indexed etc ...), number and length of keys, both the primary and any alternative keys.
This GnuCOBOL program, always the same, will be able to create various types of files (sequential, relative, indexed ) with a primary key that can be 5 bytes or 20 or 30 bytes long, with a record length of 100 bytes or 1000 bytes etc etc .. simply by accepting parameters with one or many ACCEPT statements ... with as an example an open output and a close.
Example 2.
Allow a Microfocus COBOL (or AcuCOBOL or RM Cobol or Realia COBOL ...) program to read an indexed file that was created with a GnuCOBOL program that used BDB or VB-ISAM.
Example 3a.
Conversely, read from the GnuCOBOL program an indexed file created by a Microfocus COBOL program with its proprietary system for example IDX4.
Example 3b.
Conversely, read from the GnuCOBOL program an indexed file created by a Reaia COBOL program with its proprietary Realia index system.
@ Simon: I didn't quite understand what you mean when you say:
You can also implement your own statistics, logging, checking for consistency between files, ...).
statistics :
Each I-O operation can record the number of times a read, write, delete, open - any file I-O statement. You could record the start of the call to EXTFH, the return from EXTFH - even the before and after image of the record processed.
I implement recording stats from the file activity I have implemented in my EXTFH services.
The intent to provide operation reporting performance / consumption.
Example 2. - thru 3B would require that EXTFH be available in the non Gnu environment.
EXTFH also enable the du jour languages to have ISAM / VSAM available.
Ralph
Last edit: Ralph Linkletter 2024-06-09
ok but we don't need to have EXTFH to implement usage statistics for I-O operations.
We can do it even without EXTFH, creating a "statistic file" and using normal I-O verbs..
What is the advantage of using EXTFH to store I-O statistics ?
.
Ok Do you mean that therefore EXTFH must be available in the Microfocus environment (I see that it is available), AcuCobol, Realia COBOL etc ... correct?
Consequently it does not affect GnuCOBOL's EXTFH...
.
This means that I could read from a Python or Visual Basic program etc etc ... an indexed file written with the GnuCOBOL program using BDB or VB-ISAM. correct ?
If you use EXTFH you can gather the statistics and only need to recompile the program - no change in them needed at all!
LINKAGEand to get the 88 values, which only counts the statistics and possibly write them out when a CLOSE was requested; filter in that program as you like (for example for the filename, filetype, ...) before adding to the statistics; end withCALL "EXTFH" USING fcd-recordto let libcob do the actual file io; compile with withcobc -c myiostats.cbl-fcallfh=myiostats myiostats.oto route all io through themTo use EXTFH in any COBOL environment that needs to provide an option like GnuCOBOL has with
-fcallfhor MF with itsCALLFHdirective (GC supports that when included in source files as well). So this part is a "yes".To be able to call another COBOL's EXTFH entry point from a GnuCOBOL module to allow the io be routed to that, this environment also needs this entry point and a way to call it directly or via a "to GnuCOBOL foreign" COBOL module that calls into that.
So this part means that you can only use it from a GnuCOBOL module if there's some way to access it.
Yes. As along as you use the applicable structure to call into EXTFH (the C structure is part of libcob/common.h).