× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi,

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
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 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.

Mike Amos (MrA)

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.