|
and that's why I was trying to
>>avoid a second read,
In some _extreme_ cases that might be
> worth it, but if these two reads are
going to occur at nearly the same time,
> (pgm a reads, does a couple things, > calls pgm b, pgm b reads) then you've > got a _really_ good chance that the > row is still in memory so the "read" > isn't going to cost much at all.Yes, exactly. A moment's experimentation will show that the file's I/O buffer is shared between program 1 and 2 (use the DUMP opcode) but that RPG won't do the mapping from the I/O buffer to the fields unless an I/O operation code is executed. So there's a fabulously large chance that the record will remain in memory.
Consider such pathological coupling
> of programs seriously before you do
it -- you're making is much more
> difficult to reuse Pgm B since anything
that calls it must now know how it works.
Always good advice. Especially since practically nobody I know uses shared ODPs. Those in conjunction with RETURN (not LR) make RPG applications face-contortingly fast. The trade off as always is that one needs to pay careful attention to ALL the programs in the application and not think of life one source member at a time.
--buck
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
