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

[John Myers - MM <jmyersmm@xxxxxxxxxx>]

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