Re: Externalizing Data Access - Reducing Disk I/O

Oh yeah, forgot to mention that if you're not doing I/O to/from a data
structure in RPG, then once the DB moves the data into the program's
buffer, the i-spec fields are populated one at a time.

So by not doing the repeated chains, you can at the very least save
the overhead of the field by field moves.

HTH,
Charles

On Thu, Apr 23, 2009 at 10:34 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Note that you aren't really incurring extra disk I/O.

On the initial chain, the system must page the record in from disk.
As long as that page remains in memory, the system will not re-read it
from disk on subsequent chains.  Actually, given the single level
store, the data doesn't theoretically exist on the disk for it to
read!

However, the record data is still copies from the DB page in memory to
the in memory buffers of the RPG program.  So you can get a
performance boost by not chaining repeatedly; but not as big a boost
as you might expect.  In fact, I seem to recall that in certain cases,
the system will skip the copy to the program buffer if the data hasn't
changed.

I'm a little confused by your statement, "My hope (and coding) was
that the subprocedure retained knowledge of existing record in memory,
and prevent the additional chain, but that doesn't appear to be the
case."

The code you posted seems to check if it's going to be chaining for
the same record, are you saying it's not working?

HTH,
Charles

On Thu, Apr 23, 2009 at 9:57 AM, Johnson, Brian (EU)
<Brian.Johnson@xxxxxxxxxxxxxxxxxxx> wrote:

We're developing some RPG modules (bundled into a service program) that
have externalized access to some data files.  Due to some of the data
layout, I have a concern of excessive data I/O.

We have a procedure that returns the size array attribute for an
article.  The code itself works great.  My concern is where we
repeatedly call the procedure with the same incoming parameter, and the
procedure constantly chains the same record over and over again.  My
hope (and coding) was that the subprocedure retained knowledge of
existing record in memory, and prevent the additional chain, but that
doesn't appear to be the case.

Is there anything else I can do to reduce unneeded disk I/O?

Thanks,
Brian

Example:

(INVOKES EXPORTED PROCEDURE)
C                   eval      TmpSizeA =
GetStyleSizeA(%subst(InArt:1:8))


 ****************************
 * Procedure - GetStyleSizeA
 ****************************
 * Returns Style Size Array Code

P GetStyleSizeA   b                   export

 * Input Parameters
D GetStyleSizeA   pi             3
D  InStyle                      11    const

D OutMaat         s              3

 * Only chain record if not already active (Reduces Disk I/O)
C                   if        arnrmb <> InStyle

C                   eval      OutMaat = *Blanks
C     InStyle       chain(n)  coarmbl0
C                   if        %found(coarmbl0)
C                   eval      OutMaat = maatmb
C                   endif

C                   endif

 * Return size array code
C                   return    OutMaat

P                 e



This message and any attached documents contain information which may be confidential, legally protected or exempt from disclosure under applicable law. These materials are intended only for the use of the intended recipient. If you are not the intended recipient of this transmission you are hereby notified that any use, distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. If you have received this communication in error, please immediately notify the sender and delete the message from your system and destroy any print-outs and copies.  Polo Ralph Lauren reserves the right to record and monitor email communications through its networks for the purposes of eliminating potential viruses, blocking unsolicited emails, filtering out illegal or offensive content, and for investigating and detecting any unauthorized use of its systems as well as ensuring its effective operation. The!
 content of this email is not legally binding unless explicitly confirmed by letter. Please note that it is your responsibility to scan this message for viruses.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.