Re: No record blocking on RCVF in CLP? -- MIDRANGE-L

Hi -

I'm sorry about the delay. We had problems at work Thursday and even though I'm a software person, not hardware, I only live a mile away, so I lost part of that evening dealing with a network switch that died and moving our Perle controller to a different switch so that our twinax printers could print invoices and barcodes so that we could deliver to our customers.

You're right about my not having a full understanding of this.  So I rely
on Simon Coulter, who wrote back March 2000
(http://archive.midrange.com/midrange-l/200003/msg01449.html):

   Specify the BlockingFactor on the OVRDBF command according
   to the effect you want to achieve:

   OVRDBF NBRRCDS(BlockingFactor) controls the number of records
   brought from DASD to main store.

   OVRDBF SEQONLY(*YES BlockingFactor) controls the number of
   records moved from main store to program storage (i.e., program
   record buffer).

While those two statements are correct in what they say, there are incorrect implications. The set of records referenced by NBRRCDS and the set of records referenced by SEQONLY are NOT NECESSARILY THE SAME RECORDS!

To not get into a long explanation ... NBRRCDS works on strictly a physical basis, reading in a chunk of disk, so it is always in RRN sequence and so far as I can tell, includes deleted records.

SEQONLY works on a logical basis, bringing from the various locations on the disk via the requested access method, the number of records requested.

If access is by key, if there is select/omit, or if there are deleted records, the record sets aren't the same.

   NBRRCDS can be used for both sequential and keyed I/O.  SEQONLY
   can only be used for sequential I/O.
Sequential I/O + NBRRCDS + SEQONLY = BlindingSpeed

I definitely DO NOT agree with that last statement. IMO, except in rare circumstances NBRRCDS and SEQONLY should NOT be mixed. If the record sets are identical, you're not really going to gain anything. If they aren't, it is more likely to HURT performance than to help because NBRRCDS will include records that are likely to be paged back out before they are needed.

In general terms, if you can use SEQONLY, use that and do not use NBRRCDS. Note: if the default number of records is okay and you are using RPG IV, you can use BLOCK(*YES) on the file specification and not need SEQONLY. You also can use BLOCK(*YES) (even in combination with SEQONLY) to convince the compiler to request record blocking on a file where it wouldn't ordinarily (such as an input file that uses SETLL or CHAIN).

Use NBRRCDS where SEQONLY doesn't work (such as a file opened for update) and where the records will be largely processed in RRN order without skipping records.

I don't believe I've misused the context with which this was posted, but
correct me if I have.

Based on Simon's statements, you were correct in what you were doing, but as I have indicated, I don't believe Simon's statements are fully correct.

> Why don't you post more of the program code.

Ask, and thou shalt receive...

Hmm .... I had the same experience as you. No matter what I did with the override, the RCVF insisted on a single record at a time. An RPGIV program, OTOH, was able to use record blocking with the same file and override.

It appears that the CL compiler puts something into the file access that forces no blocking. I couldn't find it documented though.

Since this request is from the program, not the database programs, that's why there is nothing in the job log about it.

This is a situation where you could just drop the SEQONLY (since it isn't doing any good), and since the file is unkeyed and shouldn't have any deleted records, it is warranted to use NBRRCDS to help performance.

There is nothing in the job that will tell you that the NBRRCDS is working. Unlikely SEQONLY, the ODP display will not show that multiple records are being retrieved because it is at a SLIC level, not at a program level.

Ken http://www.ke9nr.net/ Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.