TechTip: Buffering--Friend or Foe?

[donald.tully@att.net]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
When adding records in a program and the Record Address Type is blank, then compiler writes out to an optimized buffer because it is told to ignore keys. When adding records in a program and the Record Address Type is K, then compiler automatically switches to non buffered. This is done because we are processing by keys. DO NOT USE FRCRATIO(1). I see some applications shipped from vendors with files set up using FRCRATIO(1). This causes a tremendous hit needless hit on performance. For example a CPYF taking 35 times longer to copy than when FRCRATIO(*NONE). This is a huge hit caused by programmer not knowing the correct solution.

---

Code

[M.Savino]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Sounds like FEOD is a much lower overhead solution than Open/Close or changing FRCRATIO to one. Next time I'll definitely use that technique. I tested the UNIQUE keyword on the DDS and this does seem to force every Write out of the Buffer. When I debug a Write Loop, every Record is immediately visible doing a DSPPFM. But if the file is Not UNIQUE, merely specifiying the Address Type as Keyed for an output file, does not force the record out of the Buffer. I tested this is Debug as well, and the records were not immediately visible. Thanks, Mike

[dmjae2004@yahoo.com]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
On V5R2 and later FEOD has an optional extender. This will indicate unwritten buffers must be made available to the database, but not necessarily be written to disk. Hence lowers the performance overheads of FEOD. If you are looking at blocking considerations then the following link Blocking, Sequential Only, and the Effect on a Program may be helpful.