|
The cache/buffering I suggested in the earlier message is in the single level storage of the OS and any cache in the disk controller. The program will still write the record to FILE2, but if the program then immediately retrieves the same record from FILE2, it should still be in memory, thus eliminating the wait to retrieve the record from disk. For a large file as is being discussed, this can be a large performance improvement. Steve Morrison Beacon Insurance 940-720-4672 -----Original Message----- From: Dan Bale [mailto:dbale@xxxxxxxxxxxxx] Sent: Thursday, October 14, 2004 2:20 PM To: Midrange Systems Technical Discussion Subject: RE: Setting parms in CL for PF There is no caching/blocking on an update file on the AS/400. This nice feature was left behind on the S/36. Does *every* record in FILE2 get updated *only once* by this process? If so, you might want to make FILE2 input-only, and write to a new, third output-only file (that starts out as an empty duplicate of FILE2) that will replace FILE2 after the app finishes. That way, everything gets blocked. With the volume you're talking, I would strongly suggest that you look at the feasibility of using SQL to accomplish the task. hth, db > -----Original Message----- > From: midrange-l-bounces@xxxxxxxxxxxx / Steve Morrison > Sent: Thursday, October 14, 2004 2:42 PM > > James, > > I'll assume that this program reads FILE1 and chains to FILE2 to > update it. > > The first thing I'd do is try to index or sort FILE1 so that it's in > the same basic order as FILE2. This will allow the system to cache the > reads/updates to FILE2. This change shouldn't require changing the > update program. > > A couple of questions: > Are there multiple updates in FILE1 for records in FILE2, or is there > only one update in FILE1 for any record in FILE2? > > Are the updates changing fields that are used in an index over FILE2? > > Steve Morrison > Beacon Insurance > 940-720-4672 > > -----Original Message----- > From: James R. Newman, CDP [mailto:newman400@xxxxxxxxxxx] > Sent: Thursday, October 14, 2004 11:32 AM > To: Midrange L > Subject: Setting parms in CL for PF > > I've got a 9406-600 running V5R2 and have to run a large update job > about once a month. File1 is a sequential, non-keyed PF containing > about 18 million records of updated "current" information. File2 is a > keyed PF "master" with 18 million+ records that will be updated from > File1. File2 has 1 logical. > > A friend suggested changing some of the OVRDBF parms to help > processing go faster, such as FRCRATIO and NBRRCDS. Any suggestions > on how to set these parms? For that matter, any suggestions on how to > speed up the update process? TIA. > > James R. Newman, CDP -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.