Re: New Product Announcement - Reorg without locking files

I imagine that the marketing will need to include some certified benchmarks. Here is size of file, how many records coded for deletion, how long did it take to do the reorg by this or that method, with how many other users trying to access the file while this was going on, how much of that time involved the file being locked, how much disk space or other overhead was involved, oh and what version of OS/400 and BPCS was this done on. Then the end customer site can pick the best reorg by their file statistics.

I am assuming that this just handles the IBM reorg. There is also a BPCS soft coding of record-id as being active vs. coded for deletion, in which the reorg supplied by BPCS does not in fact get rid of all of the soft coded "deleted" records, for all files ... some files they get, some they do not get.

Irrespective of how much time is saved in the actual reorg, all BPCS sites need to expend some time researching what files need additional work at our respective BPCS versions to get the removal of deleted records that neither the BPCS reorg nor the IBM reorg get rid of, then developing our software to take care of that.

There may be a market for someone to have figured all that out for a particular version of BPCS, with combination of what applications the customer is using, and sell a package of programs to fill the void.

So, instead of waiting for the system lock to extricate deleted records, we
have to wait for a logical path to be rebuilt.  (Which happens during a reorg
anyway). Also we need additional space and resources available for the
journaling aspect to be viable, and when exactly does the journaling stop?

In other words you haven't figured out how to do a reorg without locking the
file, just a way to trade in the time to other places.

-
Al Macintyre (macwheel99@sigecom.net via Eudora)
Al's thoughts http://radio.weblogs.com/0107846/
See Al at http://www.ryze.com/go/Al9Mac
Cure cancer. http://members.ud.com/about/