Is it possible to reorganize a very big transaction in one night?

Tags:
Application development
AS/400
AS/400 jobs
Backup and Recovery
CLP
DataCenter
IBM DB2
Printing
RPG
RPGLE
Security
I want to reorganize a very big transaction file in day end process and it cannot finish within 1 night. The problem is RGZPFM command lock that file ,so the day after , user cannot use that file because it is locked. Do you have any ideas to help me?

Answer Wiki

Thanks. We'll let you know when a new response is added.

Unfortunately there is nothing you can do about the RGZPFM command locking the file. Is it possible to reorganize the file only on a weekend where you might have a larger amount of time for it to finish?

One other thing you might want to check. Do a DSPFD on the file and see if the reuse deleted records parameter is set to Yes. If your file’s deleted record count is about the same every day, this will allow new records to fill the space left by the deleted records so the file size will not build so fast. If you reset this I would recommended doing a RGZPFM at least once after setting it.

==========================================================

First, if you’re at V5R3, you can use RGZPFM ALWCANCEL{*YES) to reduce locking time to a minimum. Unfortunately, that’s not very useful since you probably won’t be able to predict when the required locks will be attempted — near the end of the process. If the locks can’t be set, there is no space recovered. Further, if you want space to be recovered, the file needs to have journaling started before the reorg; journaling can be ended after. (Finally, if the file contains BLOBs that partially or entirely get stored in the auxiliary are, the auxiliary space space won’t be recovered with ALWCANCEL(*YES) no matter what.

Note that the journaling takes up space for all of the entries remaining in the file. However, this is mostly offset by the lack of the usual copy made by ALWCANCEL(*NO).

Second, if this is a “transaction file”, why is reorg being done at all? Is this a one-time shot or part of a regular process? Once transactions are applied, the file should be emptied. Unless this again is a one-time shot where an uncharacteristically large number of transactions was handled, the file probably shouldn’t be reorg’d. Leave the allocation in place and set REUSEDLT(*YES)

But the problem is stated as the reorg taking a long time, and that indicates that the ‘transactions’ haven’t been cleared and areas of deleted spaces exist. It isn’t making a lot of sense. Why are some records deleted but not all?

I’d go with the suggestion to use CPYF to copy the records out, then CPYF MBROPT(*REPLACE) to get them back in to a fresh ‘transaction’ file. An actual reorg doesn’t seem to fit this case. Of course, the ‘case’ isn’t very clear.

Tom

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Ronjensen
    You could set the file up to reuse the space taken by deleted records, so there would be no use for Reorganize, or you could copy out the records to another file, then clear the original file and copy the records back. The user could then be in the file.
    0 pointsBadges:
    report
  • Machsite
    How big is big? And what is your nighttime window?
    0 pointsBadges:
    report
  • SevaSergey
    iTera (that recently merged with Vision Solutions) has a product Reorganize While Active. It allows to minimize downtime during file reorganization. Look for details here: http://www.iterainc.com/solutions/reorgwhileactive.html
    0 pointsBadges:
    report
  • Nick01
    Save/restore doesn't take the deleted records. Also RGZPFM in V5R3 allows it to be cancelled. It does have several constraints but the most important is the file needs to be journalled and that takes space. I haven't tested if you only need to journal the file when reorging or not.
    0 pointsBadges:
    report
  • Ashnirody
    This may be a feasible solution. Divide the data among many members. Reorganizing a member will take much less time than the whole file. You will need a logical across all members to access the data from all members.
    100 pointsBadges:
    report
  • JDWWms
    I think we may be getting to technical for the users actual needs. If he has time to save and restore the file (which was part of an earlier question) then if the space is available a CPYF, to a work file and copy back (*REPLACE) will reorg the file, remove (by default) deleted records and put the records in the desired sequence (use a logical to do the first copy if necessary) if desired. If the sequence isn't important and space is the only concern then reuse deleted records will take care of the space issue.
    0 pointsBadges:
    report
  • DanTheDane
    If logical files exists on your physical file (transaction file), delete the logical files, then reorganize the physical, and rebuild the logicals.
    2,555 pointsBadges:
    report
  • JewelJose
    Your best option would be a combination of two actions if you are V5R3 or above. Use the new Allow Cancel (ALWCANCEL *YES) in RGZPFM. Also change the PF to re-use deleted records (REUSEDLT *YES). Re-use deleted only if you are NOT processing the file in arrival sequence (in other words, by RRN).
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following