RGZPFM(Reorganize Physical File Mbr )

[dcutaia]

Hello,

I have created this program to remove deleted records from my I5 system. When I run it the RGZPFM doesn't remove the deleted records even through the program has exclusive control over the files.

DAC
/* REMOVE DELETED RECORDS FROM THE I5 */
PGM

DCLF FILE(EMCFDEL) OPNID(DEL)
DCL VAR(&MBFILE) TYPE(*CHAR) LEN(10) VALUE(' ')
DCL VAR(&MBLIB) TYPE(*CHAR) LEN(10) VALUE(' ')

ReadRec:
RCVF OPNID(DEL)
MONMSG MSGID(CPF0864) EXEC(GOTO CMDLBL(EndPgm))
CHGVAR VAR(&MBFILE) VALUE(&DEL_MBFILE)
CHGVAR VAR(&MBLIB) VALUE(&DEL_MBLIB)
RGZPFM FILE(&MBLIB/&MBFILE) RBDACCPTH(*OPTIMIZE) +
ALWCANCEL(*YES) LOCK(*EXCL)
MONMSG MSGID(CPF0000)
GOTO CMDLBL(READREC)

EndPgm:
ENDPGM

[Scott Klement]

Re: RGZPFM(Reorganize Physical File Mbr )

I just tried your RGZPFM and I had no trouble... it removed the deleted records without problems.

Can you tell me how to get the same result you're getting?

[DeadManWalks]

Re: RGZPFM(Reorganize Physical File Mbr )

I have not tested this, but I am curious if the Table says to keep deleted records, would the RgzPfm would not remove them?
Or is the file you are looking at in a lib different form the one the program ran over?

[tomholden]

Re: RGZPFM(Reorganize Physical File Mbr )

even if the table/PF is set to REUSEDLT(*YES) a RGZPFM would remove the deleted records. i would suspect that either a) the file in question the job could not obtain a *EXCL (since he's using MONMSG CPF0000 unless you look at the job log you'll never know) or b) the program is looking at a different file than the expected file.

[kitvb1]

Re: RGZPFM(Reorganize Physical File Mbr )

I have not tested this, and have no machine handy to check it, so I would tend to agree with Tom.

You could use RGZPFOCT. http://www.code400.com/forum/showthr...light=rgzpfpct.
This checks for locks before attempting the RGZPFM which saves a lot of time if waiting for a lock to release.

** edit ** the command is RGZPFPCT

[MichaelCatalani]

Re: RGZPFM(Reorganize Physical File Mbr )

It could also be an authority issue, as that MonMsg would hide that as well. Print out the joblog around the call message and see what it tells you.