IBM i Global

Hi,

To be honest I never compared the size of PF and LF's but this sounds like a "bug".

I would delete the LF and create it again but that's not an answer to your question.

Fact is that there's no RCLLFM command, neither do I see any option on the CRTLF/CHGLF command :-)

Hi,

It seems to remind me about the Reorganize Physical File Member command not rebuilding access path as the command says not to build it. The size of the logical file could go up if the RGZPFM is not rebuilding access paths and it just accumulate it.

Is it possible to run RGZPFM with RDBACCPTH(*YES) and see the results?

Rohit Chauhan

I can try that but I don't know if it will help since the file contains 0 deleted records.

I'll post the result once I have it.

Rohit Chauhan 

The RGZPFM command completed in no time and the LF is the same size

2 thoughts...try deleting a record if you can...i.e - add a test record then delete...then try the reorg with the rebuild as previously mentioned...OR try changing the Maint Flag for the LF via this doc Speeding Up the Access Path Rebuild Operation

I would also be curious to see if the index / LF is marked as being invalid etc before or after the above....

Dear Magne

When you ran RGZPFM with RDBACCPTH(*YES) as suggested, did you look at the job log in detail to make sure there is no error message (such as one that says LF is in use) when RGZPFM finished?    RDBACCPTH(*YES) requires an exclusive lock on each LF to be rebuilt.  If the LF is used by another job, LF rebuild cannot happen and an error message is put in the job log to indicate this situation.  You need to always check the job log after RGZPFM finishes.    

Another possibility is that the LF is damaged and marked as invalid. You check on this by running the command EDTRBDAP to see if that particular LF appears in its screen as being damaged/invalid or not. If so, you can force the rebuild from EDTRBDAP screen,   

Using the EDTRBDAP Command to Rebuild Invalid Access Paths at https://www.ibm.com/support/pages/using-edtrbdap-command-rebuild-invalid-access-paths          

Rich Malloy

I followed the information from your link and made ready these commands to be executed in order:

CHGLF FILE(LIB1/LFFILE1) MAINT(*REBLD) RECOVER(*NO)
EDTRBDAP

   - The file did not show up in EDTRBDAP
CHGQRYA DEGREE(*MAX)
OPNDBF FILE(LIB1/LFFILE1) option(*ALL)

  - This command completed really quickly.

Before and after these commands I checked the "Access path valid" value and it was *YES all the time.

The result after this is that the LF now is at size:  614.400

So it worked :-) The size is down and most likely normal :-)

Thank you very much for all your input!

Best regards

Magne Stamnes

Satid S

I did not check the job log after each RGZ job. I monitor jobs using ACS "Table Reorg".

But I will check the joblogs in the future when I run RGZPFM.

Thanks for the tips!

Best regards

Magne Stamnes

Dear Magne

>>>> I did not check the job log after each RGZ job. I monitor jobs using ACS "Table Reorg". <<<<

You can run RGZPFM (or any CL commands) from ACS's Run SQL Script session but you need to start each CL line with 'CL:' and end each command line with the typical semicolon.  Once any CL command finishes in Run SQL Script session, you can check the job log (of AZDASOINIT server job that serves your session) by selecting View --> Job Log from the menu bar as shown below. 

Doing a RGZPFM ALWCANCEL(*YES) meaning "while active" and expecting a rebuild of the access path is a bit contradictory.

Even the RGZPFM is not guaranteed to free up space when there's some activity, so for a LF I guess this is even more complex.

Just to add , you can view the status for any reorg with tables aswell as looking at QDBR jobs : 
https://www.ibm.com/support/pages/viewing-status-rgzpfm-through-ibm-i-access-client-solutions 

and this is a helpful tutorial on some deeper information on REORGs : https://www.ibm.com/support/pages/rgzpfm-options-and-comparison

Last comment to add to Paul's advice: 
Doing a RGZPFM ALWCANCEL(*YES) meaning "while active" and expecting a rebuild of the access path is a bit contradictory.

Even the RGZPFM is not guaranteed to free up space when there's some activity, so for a LF I guess this is even more complex.

One will eventually require a  Exclusive lock to release the data space after the ONLINE / RAGGED reorg happened. 

HTH

Thank you all for your valuable input.

I found one more file where the LF was much bigger than the PF and I tried the same method on this file. It did not work because the LF was locked.

So this is not a permanent fix that works every time.

A possible solution is to create a CL that performs these steps and run the CL in QSTRUP or right after production sytems is stopped, during backups.

Anyway: Thanks a lot for your input :-)

Best regards

Magne Stamnes

I consulted my mentor on this issue. 

Few things to consider / look at : 

1. is this a Joined logical file ? (look at the definition if you can on this - it will then explain the discrepancy)
2. check on how this is keyed , LFs you can have multiple keys that could increase size. (also consider if someone altered the Access Path Size too). 
3. check if this is really a LF and not a Index (SQL object). Explore this in GUI rather to determine it easier. 

HTH