TechTip: Buffering--Friend or Foe?

[MCWebsite.Staff]

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
** This thread discusses the Content article: TechTip: Buffering--Friend or Foe? **
0

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
1. I believe some problems I had with duplicate write errors were caused by buffering. We have Internet apps that call AS/400 CL programs, which in turn call RPG programs that add records to files opened as U with Add. If the dreaded "second-click-on-the-OK-button" on the Internet app happens, or possibly in other scenarios, the RPG program attempts to write the record that is already there, even though it first does a CHAIN to see if the record already exists. 2. I solved the above problem (I hope!) by putting FEOD after the UPDATE or WRITE. That stands for "Force End Of Data", and allows you to flush the buffer in this case without needing to have the file itself with a FRCRATIO = 1.

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Mike, I'm surprised you didn't mention the FEOD op-code which forces changes to disk. Kinda like doing a close followed by an open on the file. FYI: a FEOD on a spool file closes the current spool file and opens a new one. I've found that handy prior to IBM adding the STAPLE keyword. Also note that FEOD has less overhead than a full-fledge CLOSE followed by an OPEN. Charles Wilt

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
I've had the problem occur on update was well, if program A opens file as input, calls program B to do update (external I/O module), returns, then calls another program C which opens file as input as well, calls same program B to do update, some times (about .05 % of the time) the second call will step on updates done by the first program. VERY difficult to debug. If you use FEOD, be sure to use the operation extender (N), will flush from buffer and make available but not have the same performance hit. Example:

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
... that this system can't manage records held in a buffer. The S/36 handled this automatically! I.e., a program would be able to find a record that was in the buffer on the S/36. Not sure if such a request forced the buffer to be written to disk to effect the read/chain but, by gosh, I didn't have to worry that a chain would fail cuz it wasn't actually on the hard drive. What happened to single-level store? Shouldn't this be considered a huge data integrity problem? Also, *I think* that if a file has a unique key defined for any of its access paths, that file cannot be buffered for output. Someone please confirm or correct.

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Yes, specifying UNIQUE forces record to disk immediately. I blame this problem on the programmer really. We're so conditioned to seeing "*RNF7086 002 RPG handles blocking for the file." at the bottom of a compile that we simply ignore the warning. Well, not me anyway. :-) Chris

[dmjae2004@yahoo.com]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Yes, specifying UNIQUE forces record to disk immediately. I dont believe this is 100% accurate. UNIQUE forces the program record buffer to the Database SLS address in memory). I dont believe it needs to force this to disk. I dont agree with the suggestion to use FORCERATIO. It will work but performance will be heavily penalized. My preference would be to use OVRDBF SEQONLY(*NO). The objective is to get the record update into the database layer, not necessarily to disk. Acccording to the IBM site updates are always immediate. If they were not that could create data integrity problems. IBM on Blocking

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Dave400, You could be right, I'm not sure. I do know this: The access path is maintained immediately as changes are made. UNIQUE prohibits record blocking for that file in the RPG program. Chris

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
In the program where I had the problem, there was a CHAIN, and a WRITE was performed only if the CHAIN was unsuccessful. How could I get a duplicate write, unless the first WRITE was still buffered?

---

Code

[Guest.Visitor]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Maybe the PF is multi-membered and the LF is not over all the PF members? I can tell you that for a given member in a PF or LF, UNIQUE guarantees that the key specified cannot be duplicated. Chris

[David Abramowitz]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
A unique key in the LF does not mean that you won't get a duplicate key error for a different LF or the PF. Here's an example: I have a PF uniquely keyed by Vendor number. Off of this is an LF, uniquely keyed by Social Security Number, consisting of a subset of the PF. During maintenance on the PF, a user adds a new vendor code, but a social security number and code that creates a duplicate on the LF. After a CHAIN, a record not found condition occurs, but upon execution, the WRITE will generate a duplicate key error! Very tricky, this database management stuff. Dave

[dmjae2004@yahoo.com]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Disclaimer: I am not an RPG Programmer As David pointed out your program is assuming there is only one unique index. There may be other unique indices based on different fields (or combination of fields). Also your program is assuming there is no other concurrent programs who may also create duplicate data. If there are concurrent programs then there is a window where the record could be added by another program between your call to CHAIN and the WRITE. Also is it possible the record you tried to CHAIN could be locked by another program ?

[David Abramowitz]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
What I'm saying, is that the buffer may have nothing to do with it. Check out the index of the physical file, from which your logical is derived. Also check out the indices of other logical files associated with the same physical. Dave

[Colin Grierson]

TechTip: Buffering--Friend or Foe?

** This thread discusses the article: TechTip: Buffering--Friend or Foe? **
Do not use the FRCRATIO parameter. This article seems to be based on an incolplete understanding of the situation: When records are buffered there are three stages. 1) A record is written to the buffer 2) The buffer is passed to OS/400 3) OS/400 writes the data to disk The records are avialable to other applications once step 2 has occured. But the 'force ratio' option controls step 3 - writing to disk. If you set FRCRATIO(1), as the article sugests, you will force step 2 to occur, but you also force a write to disk for every record - which is unnecessary and can cause a severe performance hit. To force step 2, two good ways are to use OVRDBF SEQONLY(*NO), or define a keyed input operation on the file in your program (Even if it is not used.) Creating a unique key on the file works, but is not sensible if the only purpose is to make records available to other applications. FRCRATIO is obsolete now. It's purpose was to enable you to guarantee you would not lose data if the system crashed. Journaling was not available then. Now it is MUCH better to use journaling to protect against lost data. Colin

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

---

Code