Re: Synch/Asynch was Re: Expensive op codes -- RPG400-L

There are two dimensions - blocking/non-blocking and synchronous/asynchronous.
Blocking/non-blocking relates to how many logical records are transferred at
once and pertains to logical I/O.
Synch/asynch relates to whether process (job) has to wait for disk operation to
complete and pertains to physical I/O.

Chain, Reade, Readpe are non-blocking and synch
Update, Delete are non-blocking but asynch (unless file is journalled without
commitment control, in which case they are synch)
READ, READP opcodes, Straight output type are both blocking and asynch (unless
program processes data faster than system is able to prefetch data from disk, in
which case they can become synch).

Rules of thumb are:
     - do as much blocking as possible/reasonable (high ratio of logical to
physical I/Os)
     - try to eliminate synch I/Os

Best regards
    Alexei Pytel


John P Carr <jpcarr@tredegar.com> on 10/19/99 07:44:41 PM

Please respond to RPG400-L@midrange.com

To:   RPG400-L <RPG400-L@midrange.com>
cc:
Subject:  Synch/Asynch was Re: Expensive op codes





---------------------------------------------------------------
>  1) Functionally, one way READE works differently is that the data does
not
> populate the input fields if the key is not equal.  Code has to be
> generated for that.

Now that's interesting. It sounds like an explanation of why READE is
faster.

>
> 2)  When the EOF indicator comes on, this is considered an "error"
> condition to that opcode.  I/O error conditions tend to be expensive.

Hmm. That's true. What we don't know from Dave's test is how many "level
breaks" there were. If the key was equal for all million+ records, would the
time be comparable to the READ/compare?
---------------------------------------

Ok,

Synchronous opcodes;  Chain, Reade, Readpe, Update, Delete

The READE has to read the index,  For each key index entry (which itself had
to be brought into memory from DASD - ie DB page faults),
It has go to the DASD  to ask for one record with address such and such(ie
another possible DB page fault) and bring it into memory.
Many times the next index entry's data space is nowhere's near the last one.

So,  No blocking. Single record retreive on DB page fault.

Record being asked for is loaded 1 at a time from memory to the Program's
ODP work space.
No blocking again.

Many more object lock/seizes.

The above opcodes will still be Synchronous even if previously overridden
with a ORVDBF.
-------

Asynchronous functions   READ, READP opcodes, Straight output type (ie O in
Fspec)

The READ(for input only) doesn't concern itself with having to read the
Index Object for what it wants,   It goes straight to the data space.
Reading the data space consecutively.    Blocking is used.  The default size
used to be 4K, (as seen on a compiler message QRG7086 ?).
If a SETLL, SETGT is present in the code you won't see the message and the
system won't do it for you automatically.   You have to do
a OVRDBF  Filez    SEQONLY(*YES 200) NBRRCDS( 2000)   type of command first.


Blocking happens twice.  Once when bringing blocks of data from DASD(upon DB
page fault) into the file's memory space, and
the second time when moving blocks of records from memory to the program's
own  ODP for a particular job.

Much more efficient

Often less locks/seizes.

But notice the Synchronous is single record from DASD(upon DB Page fault if
needed),   AND from memory to the
particular job's ODP(remember the old PAG?).

And the Asyschronous is blocked BOTH times.
--

NBRRCDS =  Block move from DASD to the "in memory file buffer"

SEQONLY(*YES xxx) where xxx is a number  =   Block from the "in memory file
buffer" to the
individual program's ODP variable buffer

David Morris said;  You could probably
>> get similar results between READ and READE if you specify BLOCK(*YES)
>> and do your SETLL against another file that shares the access path of the

>> file that you READE against.

The reason for this is the same as the reason for an old John Sears story
about a client reading a big file for update,
( Synchronous).   In order not to have DB page faults for each and every
record,   They used a "Lead Dog" concept.
Thats where you have a Lead program which is also running at the same time.
It has the same file opened for Straight Input.
(Asysnchonous)  with blocking, nbrrcds, etc.    It reads BIG BLOCKS of data
into memory.   The second (Update) program
NEVER gets a DB Page Fault and have to wait on the DASD.   The records it
wants are ALWAYS already in memory.   The two program communicate
via Data Queues.  The update program tells the Lead Dog program where it is
in the file and the Lead Dog program reads
the next  xxxx records.    Moral: Have something bring the records into
storage for you in BIG CHUNKS.

Neat huh?

There is still one trivial (sorta)  "Synchronous/Asynchronous" thingy you
can do for "All out Performance"

Give you a real life example.    I work on a 3rd party manufacturing package
who's Product Master File has (ready ?)
over 700 fields & 3000 reclen.   Let say I am reading this file for
Update(using the UPDATE statement).  Full Procedural and externally defined.

 Every time I do a READ,   OS/400 does 700 individual moves.  It moves field
by field into my variables. (Synchonous-ish) from the ODP.

But,
Now if I just Program Defined it,    and had an externally defined D/S  and
used a READ with the data structure's name
in the Result Field,    OS/400 moves all the fields(Asychronous-ish) as one
block move into the structure.
I still can reference each field,  and do an UPDATE with the D/S in the
Result field OS/400 does just one move out.

FASTER per I/O

That's why I was supprised when no one but me got excited when Hans asked
"Hey,  would you like to use the
Result field D/S thing with Externally Defined Files ? "       I said  "Well
Ya" ,    for this reason.

Any way I have rambled long enough,  Just thought you'd enjoy it.

John Carr
EdgeTech

BTW,   I do teach a "Application Performance Programming Class"
www.400school.com








+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---