Re: File Reorg - Cons

Based on my freeware http://hkrebs.dk/rgzpfmbrs.html (a very simple one - you 
can almost as easy write it yourself) here are some considerations:

 o Remember to consider timeout and reaction if a file is locked from an other 
process than the RGZ
 o Thinking strictly 'space used' the important parameter is deleted bytes, not 
deleted records. A RCDLEN(12) file should be allowed more deleted records than 
a RCDLEN(999) one. And the deletion percentage is of cause completely 
insignificant.
 o The relative record numbers *might* be of some importance. In my 20+ years 
in midranging after s/3 and CCP I have met one single file were the application 
used the RRN and copied it to a field in another semi-permanent file and some 
(very few) where files in QTEMP had to have the same RRN's at their 'master' in 
a permanent library.
 o Consider making a feature to automatically stop the process before 'off 
hours' ends. Unfortunately this has to be done at a 'per file' boundry. It 
would be nice if you discovered that a five hours rgz will not end before 
working day starts, that you could stop the processing of that file. I can't se 
how, other than a) End job abnormally or b) code a record by record move.
 o RGZ will lock the file for some (short or long) time. I have found no way 
(apart from the attempt in the point above) to be sure that this will cause no 
harm.

Henrik
http://hkrebs.dk


> date: Tue, 27 Apr 2004 20:04:31 -0700 (PDT)
> from: Mike Berman <mikeba777@xxxxxxxxx>
> subject: File Reorg - Cons
> 
> 
> 
> I noted alot of suspicion when I attempted to set up a file reorg process. 
> Just getting lists of those with large amounts of deleted records. Is there 
> some possible occurance that would be a detriment? I am of course referring 
> to off hours running.