I need to increase the speed of I/O routines associated with ILE C
record I/O. The information here is a composite of postings I've done
elsewhere.

Hi, the first section is MI specific and the second section ILE C
specific.

In the past I used MI programming fairly often; however, the past
several years, with C/400 and then ILE-C, I have had no need to use
anything other than the provided APIs and MI calls supported directly
via ILE-C. Today, however, I need to speed up our read/write - esp.
reads - for record IO. I know that the IBM FTP program does reads much
faster than the provided record IO interfaces because FTP reads and
sends the file twice as fast as I can read it. I have tried every
reasonable combination of _Rreadx, read() and fread() that I can think
of using both native and IFS interfaces and compiler options.

Here are a few MI specific questions:

1. Has anyone found MI calls to the IO functions, QSYS/QGETDBx, etc.
be
safely done using in user state at security level 50?

2. Does anyone have any experience regarding faster record IO methods
such as use of RPG, MI or any ideas?

3. Accessing the system table to make the calls is not a problem for
me,
but I have not been able to find documentation for the IO control
block/file control block/other control block definitions needed to
set
up the IO.

ILE C section:
I have tried every reasonable combination of record and stream reads/
writes using _Rreadx, read() and fread() via native and IFS file
systems both with and without the IFSIO compiler options. The best
read time that I can
achieve, using _Rreadn with blocking, is 2x slower that the native
FTP, read and transfer, of the same 306MB file; therefore, the read
must be on the order of 4x slower than the read that IBM is doing ILE-
C. IBM FTP is using _Rreadn with blocking since I see the following on
the stack: _Rreadn, __reads, QDBGETM. At first glance, this appears to
be the same as the call sequence via _Rreadn using ILE-C; however,
looking at the stack my invoking module only calls __reads and
QDBGETM. On examining the ILE-C headers, I find that _Rreadn is
actually implemented as a macro that invokes __reads directly.
Enabling the call path to _Rreadn, __reads, QDBGETM by disabling the
macro makes little or no difference. The ILE-C header files define the
_Rreadn function so the call is allowed via a public interface.

Also, investigating the ILE-C header files leads me to conclude that
the __DFT and __NO_LOCK are not the only record locking bits provided
in the full IBM implementation AND I suspect that record locking is
always taking place with ILE-C, even when not needed due to higher
order locks applied to the file and member. I conclude this since the
delays are the same in my test code for any locking combination. The
difference between __DFT and __NO_LOCK relating to the holding of
locks after the read when the file is opened for update and does NOT
appear to relate to record read locking.

1. Does anyone know of a way to significantly speed up the read (and/
or write) operation?

2. Does anyone know where I can find complete documentation for either
the __reads or _Rreadn call/macro interfaces?

3. Does anyone know where I can find additional record locking
information specific to __reads or _Rreadn?

4. Does anyone have an explanation for why the IBM FTP blocked read
via QDBGETM is so much faster than the comparable ILE-C blocked read
via QDBGETM? I have not tried this with RPG as I have not touched RPG
for
about 15 years and the RPG interface looked to run the same as the ILE-
C interface.