RE: Local File Record Blocking -- RPG400-L

Correct. We don't typically use unique indexes. Of course with a Primary Key you're stuck with it being unique (vs a keyed physical file not requiring that the key is unique).

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

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Tuesday, May 05, 2015 10:45 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Local File Record Blocking

Kurt,

Defining the table without a primary key doesn't help if you end defining a unique logical or unique index over the physical.

Regardless of where the unique key is, the DB has to disable RPG blocking in order to enforce it.

Charles

On Tue, May 5, 2015 at 10:06 AM, Kurt Anderson <Kurt.Anderson@xxxxxxxxxxxx>
wrote:

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.eto
ol 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.

--
Regards, Chuck

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.