RE: Single level store & record blocking on update files (was RE:Where is IBM?) -- MIDRANGE-L

From a systems integrity perspective, I would not recommend blocking updates. If you do not journal and the system crashes, a lot of transactions could be partially updated. The performance improvement rarely justifies the potential complications.

Also, don't confuse RPG record blocking with OS/400 record blocking!

The AS/400 CAN do "blocking" on updates ... it just does it behind the scenes at the OS/400 level.

See CRTPF, CRTLF, CHGPF, or OVRDBF parameter FRCRATIO whose help text reads:

Records to force a write (FRCRATIO) - Help

Specifies the number of insert, delete, or update
operations that can occur on records before those records
are forced into auxiliary (permanent) storage.  If this
physical file is being journaled, either a large number or
*NONE should be used.  *NONE may cause long
synchronization of the journal and physical files.  More
information on this parameter is in the CL Reference
  information in the AS/400 Information Center at
  http://www.ibm.com/as400/infocenter, Appendix A.  More
  information on journal management is in the Backup and
  Recovery book, SC41-5304.

  This parameter overrides the force-write ratio specified
  in the database file, in the program, or in other
  previously issued OVRDBF commands.

  *NONE
      There is no force write ratio; the system determines
      when the records are written to auxiliary storage.

  number-of-write-operations-before-force
      Specify the number of records.  If a physical file
      associated with this database file is recorded in a
      journal, specify a larger force-write ratio.

Most programmers are not aware of the parameter, because they don't really pay attention to the "additional parameters" that can be seen by pressing the F10 key on these commands.

This question REALLY exposes the differences between the System/36 and System/38 family trees that formed the roots of the AS/400.

The System/36 was a System/3 extension with SSP ... a small, informal OS that relied extensively on programmers to optimize an application. A good programmer could wring a LOT of performance out of the box.

The System/38 was built, from the ground up, in a totally different way. The CPF OS had some of that intelligence built in. The early performance problems in that system were frequently traced to the fact that that the OS didn't have the situational awareness required to make good performance decisions ... and S/38 programmers didn't think as "close to the metal" as they needed to. You could block records at the OS level for both input, update, and output since about release 2.0 of CPF, It never occurred to most newly minted S/38 programmers to do it!

This question certainly exposed the cultural differences among folks who have come up through one side of the family tree or the other.

John

John Myers
IBM Certified Specialist - IBM iSeries Technical Solutions Design
IBM Certified Specialist - Advisor for e-Business
Strategic Business Systems, Inc.
17 S. Franklin Turnpike, Ramsey, NJ 07446  USA
E-mail: mailto:jmyers@xxxxxxxxxx   Phone: +1 (201) EASY 400   x131
Web:    http://www.sbsusa.com      Fax:   +1 (201) 327-6984

Free Sports League Management - Powered by AS/400
     http://www.ScoreBook.com

Get and route intelligence from your IBM AS/400 web site - WebSurvey/400
     http://www.WebSurvey400.com

At 09:20 AM 4/24/2003, you wrote:

Also, consider the physical aspects of disk storage.  The S36 and its
predecessors required contiguous storage space for all files.  A file HAD to
exist as a single stream of bytes on the disk, making blocking MUCH simpler
to accomplish.

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

-----Original Message-----
From: Douglas Handy [mailto:dhandy1@xxxxxxxxxxxxx]
Sent: Wednesday, April 23, 2003 8:34 PM
To: Midrange Systems Technical Discussion
Subject: Re: Single level store & record blocking on update files (was
RE: Where is IBM?)

Dan,

>On the AS/400, there is no record blocking for update files, period.  I
fail to see why this is,
>especially in light of the AS/400's single level store.

I think this is only true when there is a unique access path, and the
suppression of record blocking is simply to force an immediate test for
duplicate keys.

Under SSP on the S/36, it could block them anyway and you didn't find out
about
the duplicates until the keysort when the file was closed.  (Remember those
nasty messages?)

I believe the 400 can block record updates, provided the physical and
associated
logicals do not have a unique access path.  In practice this means most
files
cannot be blocked for update.

Doug