CHGPF FRCRATIO(1)

[Guest.Visitor]

Can someone explaint this to me? I have a program A that has a physical file defined as OUTPUT only and writes a record to it. Program A then calls program B which then calls program C. Program C attempts to read the record written by Program A but the record does not exist. I knew the problem would be solved by a CHGPF FRCRATIO(1) or OVRDBF FRCRATIO(1) or FEOD but why must I do this? Is this problem somehow a "feature" of OS/400? Proactively, when do I need to use use FRCRATIO(1) and when can I trust that OS/400 will handle the write for me on a timely basis? Thanks... Chris Ringer WHITTMAN-HART, INC.

[Guest.Visitor]

On Tuesday, December 09, 1997, 08:31 AM, Chris Ringer wrote: Can someone explaint this to me? I have a program A that has a physical file defined as OUTPUT only and writes a record to it. Program A then calls program B which then calls program C. Program C attempts to read the record written by Program A but the record does not exist. I knew the problem would be solved by a CHGPF FRCRATIO(1) or OVRDBF FRCRATIO(1) or FEOD but why must I do this? Is this problem somehow a "feature" of OS/400? Proactively, when do I need to use use FRCRATIO(1) and when can I trust that OS/400 will handle the write for me on a timely basis? Thanks... Chris Ringer WHITTMAN-HART, INC. <hr>Chris, we had this topic explored recently somewhere here in these forums. You may want to search thru the threads for FRCRATIO. What was found out is: * If your file is NOT at FRCRATIO=1, the OS chooses when to fix updates to disk, that is disk-io will be optimized. * Exception: files with unique key will reflect changes immediately. Keep in mind that changing to FRCRATIO=1 will have a severe performance impact, as disk-io requests are very slow (as opposed to cpu-cycles) and waiting for every single record update to be written to DASD will take a lot of wait time. Choose wisely, where you need (non-unique!) records to be seen instantely by other programs. That a record is not to be seen instantly does not mean you risk data loss if the job crashes, because as long as the machine is running, job buffers will be written to disk even after the job has terminated. Only in case of a machine crash, there might be a risk of loosing data. File buffers will also be written when you close the file. If you need to, you can specify FRCRATIO on the OVRDBF command. Regards, Martin.

[Guest.Visitor]

The thread i mentioned is at <a target=_new > href="http://www.midrangecomputing.com/scripts/webboard.dll/read4209/F2">http:/ /www.midrangecomputing.com/scripts/webboard.dll/read4209/F2</a> Regards, Martin.

[Guest.Visitor]

Thanks for the help. For the one offending job, I ended up doing an OVRDBF FRCRATIO(1) before opening the file. My file does not have unique keys. Incidentally, I did do a search for FRCRATIO after selecting EVERY conference and nothing was found. Try it. Chris Ringer...

[Guest.Visitor]

On Tuesday, December 09, 1997, 01:02 PM, Chris Ringer wrote: Incidentally, I did do a search for FRCRATIO after selecting EVERY conference and nothing was found. Try it. Chris Ringer... The thread is entitled 'Records unavailable for access' and is in the AS/400 Programming Section (amongst the October 97 postings). Although Martin has explained in a few sentences what took 25 postings back then, there are a few alternative methods to using FRCRATIO suggested.