Which is faster to reorganize a PF?

[gregmonay]

Hello all,

I have some PF with million of records and need to be reorganized because we have done some cleanup and deleted considerably large number of records. This is to maximize the space we have considering that we are already running out of disk space.

One thing is that some PF have 10 or more LF's attached to it.

I was just thinking if it is better to delete first all the LF and then reorganize the PF and re-create the LF's or just do a reorganize on the PF and all the LF will just be updated?

Thanks in advance.

Greg

[MichaelCatalani]

Re: Which is faster to reorganize a PF?

Your mileage may vary, but its typically faster to much faster if you delete the logicals before re-organzing. You can just remove the logical file members instead of deleting the logical itself, and then simply add the member back when you're done.

[gregmonay]

Re: Which is faster to reorganize a PF?

Thanks Michael for the quick reply. What will be the difference when i delete the logical file member instead of deleting the logical file?
I have done some reorganization in the past by deleting the LF's and recreating them when reorganization is finished but i also want to try this deleting only the logical file member. How do i do this?

Thanks,
Greg

[kitvb1]

Re: Which is faster to reorganize a PF?

Would not setting access path maintenance (MAINT) to *REBLD or *DLY, (and resetting it after the RGZPFM is finished), be faster (and maybe easier)? I am not sure.

If you remove members or delete files, this limits you to doing this during off-hours (or ensuring that dependent programs are not executed during the RGZPFM). Also, how do you re-create the LF afterwards, as there may be a LVLCHK issue involved.

[gregmonay]

Re: Which is faster to reorganize a PF?

Hi Kit,
Thanks for your reply. Yes, we are planning to do this during off-hours.
Btw what do you mean when you say LVLCHK issues? Will there be any problem when a logical is recreated even though there are no changes in the structure in the logical? I have tested deleting a logical file of a pf and reorganizing that file then re-created the lf. When i ran the programs using this lf, there seems to be no issues.
Thanks,
Greg

[kitvb1]

Re: Which is faster to reorganize a PF?

Did you re-create the LF by using CRTLF? If so, I would imagine that the object signature would be different to that stored in the program which would then result in a level check error.

This may be of use to you.

http://www.code400.com/forum/showthread.php?p=31028#post31028

[Mercury]

Re: Which is faster to reorganize a PF?

Kit,
AFAIK recreating exactly the same LF using CRTLF doesn't impact on the program signature nor file/format lvl.

[kitvb1]

Re: Which is faster to reorganize a PF?

Thanks Phillipe,

I didn't know that. (It also explains why Michael would suggest it).

[tomholden]

Re: Which is faster to reorganize a PF?

Kit,
AFAIK recreating exactly the same LF using CRTLF doesn't impact on the program signature nor file/format lvl.

true that! also you could benchmark the speed of using CPYF to compress the deleted records out. CPYF the data from the existing file, then CPYF the data back into the original file with MBROPT(*REPLACE) (providing you don't have triggers on the table!) if you are journaling the file or have triggers on the file the end journaling and disable the triggers prior to the reorg.

[DeadManWalks]

Re: Which is faster to reorganize a PF?

in the mean time, change the PF to resuse deleted records. Instant savings.

[MichaelCatalani]

Re: Which is faster to reorganize a PF?

There are two reasons I prefer removing the members;

1) I dont have to worry about the recompile process, especially if someone has decided to modify some LF source on me. The last thing I want is to automate a process, only to get phone calls starting at 4am in the morning that all the programs are erroring out on level checks because someone modified some source without recompiling the object.

2) If you have a formal change management process, the crtlf command may be locked down to where you cant use them in an automated process, or the change management process itself does not ( and really, should not) allow a recompile outside of the change management processs.

[gregmonay]

Re: Which is faster to reorganize a PF?

Thanks everyone for all your ideas.
@Michael
I will try what you have suggested. Definitely we dont have any changes on the LF source thus we just have to recreate the same LF. Our LF usually have only one member although they were compiled with MAXMBRS = *NOMAX.

Just a question, How do i do the process?
Will this be like
1. RMVM from logical file
2. RGZPFM physical file
3. ADDLFM to logical file

Also additional question, when I add a logical file member, does the name need to be same as the lf name? will there be issues if I change the member name other than the lf name?


Thanks,
Greg

[MichaelCatalani]

Re: Which is faster to reorganize a PF?

Thanks everyone for all your ideas.

Just a question, How do i do the process?
Will this be like
1. RMVM from logical file
2. RGZPFM physical file
3. ADDLFM to logical file

Hi Greg. Yes. If your lf's only have a single member, and they are always named the file name, then this is all you would have to do. Naming the members the same as the file name is the default value on the CRTLF command. ( *FILE on MBR parameter)

If you have files with multiple members, then you would need to create a process to extract the member information for each logical and store it somewhere. Then you can use that info to recreate all the members with that information after the RGZPFM.

Also additional question, when I add a logical file member,
does the name need to be same as the lf name? will there be issues if I change the member name other than the lf name?

It doesnt have to. If none of your applications explicitely deal with member names, then it shouldnt matter. A program will open the first member by default.

Where it would matter is if the member name is explicitely used in an application somewhere. Typically, this is the case when dealing with a file with multiple members. If the file only has a single member, then the member name is probably not explicitely used anywhere. Just to be safe though, I would probably keep the member names the same as they were, which is likely the name of the file.

[gregmonay]

Re: Which is faster to reorganize a PF?

Thanks a lot Michael.
I think the programs we are using do not explicitly deal with member names. But i will be using the default as it is the safest way.

Regards,
Greg