RE: Local File Record Blocking

Chuck, I use that OVRDBF method for most cases when blocking in an attempt to maximize blocking. In this case I wasn't concerned about the blocking size, just that it did block output. However, I did add in using the OVRDBF command to set the blocking size and it didn't make a difference. Of course I tested that before this other statement by you sank in:

" If the data has a unique keyed access path defined, that is one cause for the run-time request for blocking to be overridden"

That's the issue and I should have known better. I have explicitly made sure we don't define any large volume tables with a primary key for this very reason. In this case, the error file isn't high volume and did end up with a primary key in its definition.

Thanks,

Kurt Anderson
Sr. Programmer/Analyst - Application Development, Service Delivery Platform

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, May 04, 2015 6:16 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Local File Record Blocking

On 04-May-2015 16:00 -0500, Kurt Anderson wrote:

I have the following file defined in a procedure:
dcl-f InvErrP Usage( *Output ) Qualified Static;

I was looking at the job using this file and I noticed it's not
blocking the output.

Member/ Record File I/O ----Open--- Relative
File Library Device Format Type Count Opt Shr-Nbr Record
INVERRP TA9LIB INVERRP INVERRF PHY 1215 O NO 1215

Sure, in this case it's not exactly a high volume file, but I feel I
might learn something here. I then modified the above InvErrP
declaration to include Block(*Yes), but it didn't help.

The specification is merely a request for record blocking; the capability at run-time is effectively /negotiated/, so the actual effect for run-time may be the same as BLOCK(*NO), irrespective the request for blocking have been made at compile-time.

I also have another procedure with the same file defined locally as
input.
dcl-f InvErrP Qualified UsrOpn; This procedure calls
the one with the static output file define telling it to close the
file before this one opens the file.

Is having two separate entries doing something to the automatic
blocking detection in the RPG compiler? Or is there something else I'm
missing?

If the data has a unique keyed access path defined, that is one cause for the run-time request for blocking to be overridden; the Data Management negotiates a buffer size of one record for the interface to the program for its write\output requests. I seem to recall a couple other things negotiate similarly; perhaps one is insert triggers.?

Then there is this past conversation [link to a message, not the thread, but hopefully directly to the most pertinent] that might bring back memories; that the Override To Database File (OVRDBF) might be required to ensure blocking will be used, if there is a keyed access path [of a logical file] that is over the data but not sharing the physical keyed access path:
<http://archive.midrange.com/rpg400-l/201006/msg00204.html>

I was referencing this page (sorry no ibm.biz link):
<http://www.ibm.com/support/knowledgecenter/SSZND2_6.0.0/com.ibm.etool
s.iseries.pgmgd.doc/c0925076290.htm>
This link of course talks about the program as a whole and globally
defined files so I don't know how to apply this to a program using
local files. Because in my case the two declarations of InvErrP are
completely separate access paths so one being input and the other
being output shouldn't prevent the two of them from blocking.

Thanks for your input. I'm on IBM i 7.2.

I would expect the same [type of] message in the compile listing for procedure-level files as for program-level declared files, about whether the blocking was valid for and defaulted at compile-time; the presumption of course, that the compile-time file-references match those at run-time, in order that those notifications maintain meaning.