Isn't assuming a optimally packed dataset a dangerous assumption OR at least unrealistic? (Just as assuming that one does not repack may also be dangerous and/or unrealistic:-) ). Some shops, I know have the luxury of being able to go down for hours and do maintenance. That's great. Some do not. For our shop to repack 1 dataset, would require over 15 HOURS of down time. We simply can't afford to do this. When 100% uptime is required (we are 24x7), how do you repack the set & maintain availability? ENHANCEMENT REQUEST I would love for Alfredo to enhance Adager to repack a dataset and allow it to be available for use! ;-). END ENHANCMENT REQUEST I will 'never' be able to repack the set. So....over time, after removing data no longer required, then there will then be no fundamental difference between a forward chain read & a reverse chain read. Correct? Not Correct? > -----Original Message----- > From: Lee Gunter [SMTP:[log in to unmask]] > Sent: Friday, September 05, 1997 12:52 PM > To: [log in to unmask] > Subject: Re[2]: [HP3000-L] Image Inefficient? > > Image will allow you to begin at end-of-chain and read the chain in > reverse (DBGET-mode 6, I think). The inefficiency referred to is > probably due to the way records are retrieved from disk. Image > retrieves blocks of data in increments of 4096 bytes (2048 > half-words). > Assuming the chain you're reading is optimally packed - i.e., all > blocks contiguous - the prefetch characteristics cause the blocks to > be > read forward and will read 1-to-n contiguous entries of the chain into > memory, reducing the number of I/O's required to retrieve all the > records. A reverse chained read doesn't cause the blocks to be read > "backward"; therefore, this will usually incur more disk I/O's to > retrieve all the chain entries. > > Typically, a reverse chained read is most useful for applications > needing data which are typically stored in a sequence for which the > most recently added entry/entries are required. > > I hope this helps (and is essentially accurate :-). > > Lee Gunter > Regence Blue Cross Blue Shield of Oregon / Regence HMO Oregon > > mailto:[log in to unmask] > > voice...503-375-4498 > fax.....503-375-4401 > ========================================================== > The opinions expressed, here, are mine and mine alone, and do not > necessarily reflect those of my employer. > > > ______________________________ Reply Separator > _________________________________ > Subject: Re: [HP3000-L] Image Inefficient? > Author: "Michael A. Dobies" <[log in to unmask]> at ~INTERNET > Date: 9/5/97 8:35 AM > > > Don't you have to go to the endof chain, before you can go backwards? > > Michael Dobies > > -----Original Message----- > From: Gary Groves [SMTP:[log in to unmask]] > Sent: Friday, September 05, 1997 7:49 AM > To: [log in to unmask] > Subject: Image Inefficient? > > I need to create a new Image dataset. I want to retrieve the records > in > reverse date order (LIFO). I was going to do a backwards chain read. > Someone told me that a reverse chain read was not efficient. > > For other design reasons, I've decided to use a composite Omnidex key, > but I'm curious if the above is true. If so, Why? > > Gary Groves > > Kwestions, Kwalms, Kweries, Komments....Kall! > > > http://www.superstar.com > http://www.netlinksat.com > http://www.uvsg.com