IBM Support

Fixing Duplicate Files in QUSRSYS

Troubleshooting


Problem

This document describes basic steps used to clean up duplicate files or files with extensions in QUSRSYS or any other library. This process may not work for all files and is a general practice.

Resolving The Problem

The following is a list of things to do to fix or clean up duplicate files without restoring QUSRSYS. It is recommended to have a good backup of QUSRSYS before starting cleanup. It is possible that restricted state may be needed to ensure there are no locks on the files in QUSRSYS when removing duplicate files.

Note: This issue is user induced when someone has performed a RSTLIB with ALWOBJDIF(*ALL) specified. The user must determine the best method for cleaning up the duplicate files. Involving IBM in this requires a consulting or RTS Hourly Billable Support agreement. For more information about having this work done under a RTS Hourly Billable Support agreement, refer to the following document:

IBM Power: Remote Technical Support (RTS) Hourly Billable Support for IBM i

The WRKF command can be used to display and manipulate the needed files.

You should do the following:

1.Make a list of the logical files and what physical files they point to.
2.Look at the physical files and determine which ones have data. Make a note of those files.
3.If you have a good logical file pointing to a good physical file, there is no need to do anything.
4.If you have a good logical file pointing to a wrong physical file, you should do the following:

o If the wrong physical file contains the data, delete the correct named file, and rename the wrong file to the correct file name (the logical file will follow the rename).

o If the correct physical contains the data, type CLRPFM on the wrong file. Then copy the file of the correct physical file to the wrong physical file with the CPYF command. Delete the correct physical file, and rename the wrong physical file to the correct physical file name.
5.If you have a wrong logical file pointing to a good physical file, make a backup of a good logical file, delete the correctly named logical file, rename the wrong logical file to the correct name, and correct the description.
6.If you have a wrong logical file pointing to a wrong physical file, delete both files.
This takes time because you must chart out what the problems are.

Run the DSPDBR command against a physical file to view all logical files that depend on it.
Run the DSPFD command against a logical file and search for the 'Based on file and Library' to determined the based on physical file.


Notes: 
1. If there are duplicates of QAOK* files in QUSRSYS, refer to document -QMSF Jobs Fail with a CPI9A9C Errors with QAOK* Files 
2. IBM Power: Remote Technical Support (RTS) Hourly Billable Support for IBM i
This document provides information on how to request IBM i billable support, for assistance with items outside the scope of the SWMA agreement.
 
 
What is a good physical file? What is a good logical file ?
 
IBM cannot make that decision for you.
 
Here's a simple example of why the customer needs to make that decision:
 
1) create a table and index
 
CREATE TABLE DUPELIB/MYTABLE (COL1 INT )       
insert into dupelib/mytable values (1),(2)   
CREATE INDEX DUPELIB/MYINDEX ON DUPELIB/MYTABLE (COL1) 
 
         COL1    
            1    
            2    
 
2) save that table and index
 
SAVOBJ OBJ(MYTABLE MYINDEX) LIB(DUPELIB) DEV(*SAVF) SAVF(DUPELIB/SAVF) 
 
3) drop that table and index
 
DROP INDEX DUPELIB/MYINDEX
DROP TABLE DUPELIB/MYTABLE  
 
4) create a table and index with the same name but different column attributes

CREATE TABLE DUPELIB/MYTABLE (COL1 CHAR )                 
insert into dupelib/mytable values ('a'),('b')            
CREATE INDEX DUPELIB/MYINDEX ON DUPELIB/MYTABLE (COL1) 
         COL1 
           a   
           b     

4) Now let's restore the previous version:
RSTOBJ OBJ(*ALL)          
       SAVLIB(DUPELIB)    
       DEV(*SAVF)         
       SAVF(DUPELIB/SAVF) 
       MBROPT(*NEW)       
       ALWOBJDIF(*ALL)    
 
5) This is the result:
 
MYINDEX     *FILE       LF                                               
MYINDE0001  *FILE       LF          Old name MYINDEX in DUPELIB owned by KTRISKO
MYTABLE     *FILE       PF-DTA                                           
MYTABL0001  *FILE       PF-DTA      Old name MYTABLE in DUPELIB owned by KTRISKO
 
? Which one is which?   Which one is the 'good physical file' ?
 
MYTABLE:
 COL1  
    1  
    2  
 
MYTABL0001:
 COL1 
  a   
  b   
 
IBM cannot make that decision for you.
 
 

[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z000000cwp6AAA","label":"Save Restore"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]

Historical Number

N1019409

Document Information

Modified date:
08 July 2026

UID

nas8N1019409