RE: Large Number of deleted records delaying EOF on a read?

Without changing to something else, for example, DataQs. I'd try
changing your programs to 'user controlled' open and close of this file.
Close it once a day and execute the RGZPFM command using QCMDEXC. The
open the file again and you off and running.

Ken Slaugh
Senior Programmer/System Analyst
AS/400 Professional Network Administrator/MSE
Specialist - Client Access/400
Chouinard & Myhre, Inc.

> -----Original Message-----
> From: Kris Vaidyanathan [SMTP:krishnan@ozemail.com.au]
> Sent: Thursday, April 29, 1999 6:53 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Large Number of deleted records delaying EOF on a read?
> 
> 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
+---