× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.