This post is related to a post that I will make to the MI group.
I have need to speed up our record IO - esp. reads - and 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
1. Does anyone know of a way to significantly speed up the read (and/ or
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 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