Reorganizing a very large file

[Gregory S. Dilbeck]

Need help in reorganinzing a very large file, I'm fairly new to the AS/400
Working at a local hospital with a model 320, System uses HBOC
software and currently os/400 vr31 ( I believe) System is reporting to
reorg the file at 36 hours. From what I've understood from the manuals
once it starts to reorganize a file it has to continue until it finishes.
Is there a way to reorganize the file (for say 3 hours a night) and then
continue on? Please reply either here or at email address.
Thanks in advance.

--
___________________________________________________________

Gregory S. Dilbeck
Jackson State Community College, Jackson Tennessee. USA
Internet : gsd...@orion.jscc.cc.tn.us

___________________________________________________________

[David L Dunfield]

>--
>___________________________________________________________

>___________________________________________________________

I don't know of any way to do this without running the whole reorg.
You may be able to remove logical file members of files built over the
physical to be reorged, then add the members back after the reorg.
This may save some time but probably not enough.

You also may want to examine the physical file to see if reuse of
deleted records could work. You must be sure your softeware is not
dependent on record arrival sequence before you use this option.

[bur...@epix.net]

> Need help in reorganinzing a very large file, I'm fairly new to the AS/400
> Working at a local hospital with a model 320, System uses HBOC
> software and currently os/400 vr31 ( I believe) System is reporting to
> reorg the file at 36 hours. From what I've understood from the manuals
> once it starts to reorganize a file it has to continue until it finishes.
> Is there a way to reorganize the file (for say 3 hours a night) and then
> continue on? Please reply either here or at email address.
> Thanks in advance.
>

Try copying the file to another location, then renaming the original file to
another name, then renaming the newly copied file to the original name. It
might be more cumbersome, put if it abends, you're not out of business...
Might have problems with logical files, but then you could rebuild them if you
had to.

Ed Buratti
bur...@epix.net

[Jeff Jewett]

I had a similar situation recently. You will not be able to do a
partial reorg because the first thing that happens is that all
access paths get blasted. I would experiment with:
1. RMVLFM (of all logicals over the file)
2. Reorg the file (this is now the fast part)
3. Analyze all LF's to determine how best to add the members back
so that access paths will be implicitly shared, hence reducing the
amount of time needed.
4. If the time is still not acceptable I would play with the
SETOBJACC command (for the logical having member added).

Jeff_...@S2K.COM

gsd...@orion.jscc.cc.tn.us (Gregory S. Dilbeck) wrote:

>Need help in reorganinzing a very large file, I'm fairly new to the AS/400
>Working at a local hospital with a model 320, System uses HBOC
>software and currently os/400 vr31 ( I believe) System is reporting to
>reorg the file at 36 hours. From what I've understood from the manuals
>once it starts to reorganize a file it has to continue until it finishes.
>Is there a way to reorganize the file (for say 3 hours a night) and then
>continue on? Please reply either here or at email address.
>Thanks in advance.

>--

[Kevin Kaneko]

Gregory S. Dilbeck wrote:
>
> Need help in reorganinzing a very large file, I'm fairly new to the AS/400
> Working at a local hospital with a model 320, System uses HBOC
> software and currently os/400 vr31 ( I believe) System is reporting to
> reorg the file at 36 hours. From what I've understood from the manuals
> once it starts to reorganize a file it has to continue until it finishes.
> Is there a way to reorganize the file (for say 3 hours a night) and then
> continue on? Please reply either here or at email address.
> Thanks in advance.
>
> --
> ___________________________________________________________
>
> Gregory S. Dilbeck
> Jackson State Community College, Jackson Tennessee. USA
> Internet : gsd...@orion.jscc.cc.tn.us
>
> ___________________________________________________________

36hrs to reorge one file?!? Yuck!

You might try (after saving the library with ACCESS PATHS *yes) Copying the file to someplace else(don't copy the
deleted records) then doing CLRPFM on it(the original file) and copying the file back. You can always restore quickly
if you have to (since you saved the ACCESS paths)plus you will have the added (real) benefit of getting back more space
than had you run a RGZPFM (the extra space will be apparent in the logicals).

Arich Henneman
Valley Memorial Hospital

[Kevin Kaneko]

[mcp...@ibm.net]

In <4le008$s...@oolong.memphis.edu>, gsd...@orion.jscc.cc.tn.us (Gregory S. Dilbeck) writes:
>Need help in reorganinzing a very large file, I'm fairly new to the AS/400
>Working at a local hospital with a model 320, System uses HBOC
>software and currently os/400 vr31 ( I believe) System is reporting to
>reorg the file at 36 hours. From what I've understood from the manuals
>once it starts to reorganize a file it has to continue until it finishes.
>Is there a way to reorganize the file (for say 3 hours a night) and then
>continue on? Please reply either here or at email address.
>Thanks in advance.
>
>
>
>--
>___________________________________________________________
>
>Gregory S. Dilbeck
>Jackson State Community College, Jackson Tennessee. USA
>Internet : gsd...@orion.jscc.cc.tn.us
>
>___________________________________________________________
>

No, there is no way to stop the file reorganzation without damaging the file.
The most common reason to reorganize a file is to compress out deleted records.
However, you can change the file to reuse deleted records.

[Matt Sargent]

bur...@epix.net wrote:

>Try copying the file to another location, then renaming the original file to
>another name, then renaming the newly copied file to the original name. It
>might be more cumbersome, put if it abends, you're not out of business...
>Might have problems with logical files, but then you could rebuild them if you
>had to.

There's no "might" about it. The logicals will remain attached to the
original file. As soon as the new file is renamed, any programs that
reference the physical file will be using the new file, while any
programs that reference a logical file will be using the old file,
which, needless to say, is bad news. The easiest way is simply to back
up the file *and* its access paths prior to the re-org.

I've had good luck re-orging large files by first removing the members
from all associated logicals. After the re-org finishes, I submit a
separate job for each logical file to add back the logical member.
This allows me do perform as many simultaneous access rebuilds as the
process will handle.

_____________________________________________________________________
"But there must be something more to death than surfing all the time"
- Dar Williams