RE: chain problem

There's a section in the ILE RPG Programmer's Guide in Chapter 17 that
describes how the compiler decides to block.  

<snip>
Record Blocking and Unblocking
By default, the RPG compiler unblocks input records and blocks output
records to
improve run-time performance in SEQ or DISK files when the following
conditions
are met:
1. The file is program-described or, if externally described, it has only
one record
format.
2. The keyword RECNO is not used in the file-description specification.
Note: If RECNO is used, the ILE RPG compiler will not allow record blocking.
However, if the file is an input file and RECNO is used, Data
Management may still block records if fast sequential access is set. This
means that updated records might not be seen right away.
3. One of the following is true:
a. The file is an output file.
b. If the file is a combined file, then it is an array or table file.
c. The file is an input-only file; it is not a record-address file or
processed by a
record-address file; and uses only the OPEN, CLOSE FEOD, and READ file
operations. (In other words, the following file operations are not allowed:
READE, READPE, SETGT, SETLL, and CHAIN.)
The RPG compiler generates object program code to block and unblock records
for
all SEQ or DISK files that satisfy the above conditions. Certain OS/400
system
restrictions may prevent blocking and unblocking. In those cases,
performance is
not improved.
You can explicitly request record blocking by specifying the keyword
BLOCK(*YES) on the file-description specification for the file. The only
difference
between the default record blocking and user-requested record blocking is
that
when BLOCK(*YES) is specified for input files, then the operations SETLL,
SETGT
and CHAIN can be used with the input file (see condition 3c on page 309
above)
and blocking will still occur. If the BLOCK keyword is not specified and
these
operations are used, no record blocking will occur.
You can also prevent the default blocking of records by specifying the
keyword
BLOCK(*NO) on the file-description specification. If BLOCK(*NO) is
specified,
then no record blocking is done by the compiler, nor by data management. If
the
keyword BLOCK is not specified, then default blocking occurs as described
above.
The input/output and device-specific feedback of the file information data
structure are not updated after each read or write (except for the RRN and
Key
information on block reads) for files in which the records are blocked and
unblocked by the RPG compiler. The feedback area is updated each time a
block of
records is transferred. (For further details on the file information data
structure see
the WebSphere Development Studio: ILE RPG Reference.)
You can obtain valid updated feedback information by preventing the file
from
being blocked and unblocked. Use one of the following ways to prevent
blocking:
-- Specify BLOCK(*NO) on the file description specification.
-- At run time, use the CL command OVRDBF (Override with Database File) with
SEQONLY(*NO) specified.
<snip>

You'd really have to look at the compile listing to determine if the
compiler decided to block or not..... 

For myself, I've always preferred the FEOD solution, since it explicitly
instructs the program to flush the buffers.  

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



-----Original Message-----
From: RPower@xxxxxxxxxx [mailto:RPower@xxxxxxxxxx]
Sent: Friday, August 13, 2004 9:30 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: chain problem


Interesting.  When I changed the pgm I was working on to use the Except 
statement I saw the records right away.  Well, it will probably raise it's 
ugly head in the future then.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
Tel: 709-576-8132
Email: rpower@xxxxxxxxxx
Website: http://www.stjohns.ca/
___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. - 
Sir Winston Churchill




"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
13/08/2004 10:58 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: chain problem






Ron,

The EXCEPT opcode is subject to the same buffering issues....  By default,
RPG prefers to buffer IO for better performance.  There are many potential
ways to solve this problem with uncommitted writes, whether by eliminating
record blocking, using FEOD to force data to DASD, or commitment control
with a final COMMIT following your transaction.  It's most important to
understand what the real problem is.... 

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



-----Original Message-----
From: RPower@xxxxxxxxxx [mailto:RPower@xxxxxxxxxx]
Sent: Friday, August 13, 2004 6:48 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: chain problem


The Except statement puts the records out immediately as well.  I had 
similar problem once before.  Although some might consider the Except 
statement archaic for this purpose but it gets the job done easily <g>.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
Tel: 709-576-8132
Email: rpower@xxxxxxxxxx
Website: http://www.stjohns.ca/
___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. - 
Sir Winston Churchill




Ken Sims <mdrg4136@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
13/08/2004 12:26 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
rpg400-l@xxxxxxxxxxxx
cc

Subject
Re: chain problem







>The CHAIN is probably failing because the write was buffered.
>
>You can either try a FEOD (force end of data) after the WRITE to force 
the
>record to disk or change the file's force-write ratio to something 
smaller
>(like 1).  Either use CHGPF FRCRATIO(1) or OVRDBF  FRCRATIO(1)

Don't use FRCRATIO(1).  That forces the program to wait until the data is 
actually written to the disk.

Use OVRDBF SEQONLY(*NO) or block(*no) on the F-spec if you're in RPG 
IV.  If you're using RPG III and don't want to use OVRDBF, you can code 
the 
file as update/add and have some dummy operations to keep the compiler 
happy.  Any of these methods will eliminate program buffering so that the 
data is immediately available, but still allow the operating system to 
write it to the hard drive asynchronously.

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

--
This is the RPG programming on the AS400 / 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 OutBound email has been scanned for Viruses
--
This is the RPG programming on the AS400 / 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 AS400 / 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 OutBound email has been scanned for Viruses
--
This is the RPG programming on the AS400 / 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.