|
A deleted record is not deleted, just marked as so (Ref the TAATOOL-command to 'undelete records'), so most of your processing is the same for the deleted records, except that the record will never reach your program. I do not like the 'reuse deleted' (you never know when you want to debug what has happened with the file-record history). If possibly - code the application so that you can close the file and reorganize it regulary. ---------- > Fra: Kris Vaidyanathan <krishnan@ozemail.com.au> > Til: MIDRANGE-L@midrange.com > Emne: Large Number of deleted records delaying EOF on a read? > Dato: 30. april 1999 03:53 > > As part of our Y2K changes we had to mirror 6digit versions and 8 digit > versions of some files. We set this up so that a trigger program would write > the records to a bucket file, and a never ending program would pick them up > and then process and pass them along to the mirror image file. Then delete > it form the bucket. The bucket file was unkeyed, so that FIFO processing > took place and updates stayed in sync. > > Curiously enough after a couple weeks the whole thing slowed down > drastically. After much monitoring and study we found that because of the > large number of deleted records in the bucket file, the never ending program > read a record, delete it, then read the next record, but would delay the EOF > indicator coming on. Basically the program just seemed to wade through empty > deleted records before noting that the file was empty. > > Once we re-organized the file all was well. So we set up regular, twice a > day re-org on the file and all seems Ok. > > Question is, does the AS400 have a problem here, ie difficulty in > recognizing EOF on file with large (we're talking very large) numbers of > deleted records? > krisV > ______________________________________ > THIS DOCUMENT IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. The information > contained in this document did represent the current view of Kris > Vaidyanathan on the issues discussed as of the date of publication. Because > Kris Vaidyanathan must respond to changes in reality, space time phenomena > and local subspace conditions, it should not be interpreted to be a > commitment on the part of Kris Vaidyanathan and Kris Vaidyanathan cannot > guarantee the accuracy of any information presented after the date of > publication..(this does not mean that I am an idiot.) > INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED 'AS IS' WITHOUT WARRANTY > OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE > IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > FREEDOM FROM INFRINGEMENT...(this sounds great. If you figure it out, do > tell me what it means) > The user assumes the entire risk as to the accuracy and the use of this > document. This document may be copied and distributed subject to the > following conditions: > 1. All text must be copied without modification and all pages must be > included > 2. All copies must contain Kris Vaidyanathan's copyright notice and any > other notices provided therein > 3. This document may not be distributed for profit or for cheap laughs. > > > > krishnan@ozemail.com.au > http://www.ozemail.com.au/~krishnan > > > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.