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 customized service agreement. For more information about having this work done under a customized service agreement, refer to the following document:
IBMi Customized Services
https://www.ibm.com/support/pages/node/667765
The WRKF command can be used to display and manipulate the needed files.
You should do the following:
CREATE TABLE DUPELIB/MYTABLE (COL1 CHAR )
insert into dupelib/mytable values ('a'),('b')
CREATE INDEX DUPELIB/MYINDEX ON DUPELIB/MYTABLE (COL1)
4) Now let's restore the previous version:
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 customized service agreement. For more information about having this work done under a customized service agreement, refer to the following document:
IBMi Customized Services
https://www.ibm.com/support/pages/node/667765
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.
You can use the DSPDBR command on a physical file to see what logical file is attached to it.
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. IBMi Customized Services
This document provides information on how to request IBM i customized service, for assistance with items outside the scope of the SWMA agreement.
You can use the DSPDBR command on a physical file to see what logical file is attached to it.
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. IBMi Customized Services
This document provides information on how to request IBM i customized service, 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)
insert into dupelib/mytable values (1),(2)
CREATE INDEX DUPELIB/MYINDEX ON DUPELIB/MYTABLE (COL1)
COL1
1
2
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
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
a
b
4) Now let's restore the previous version:
RSTOBJ OBJ(*ALL)
SAVLIB(DUPELIB)
DEV(*SAVF)
SAVF(DUPELIB/SAVF)
MBROPT(*NEW)
ALWOBJDIF(*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
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
COL1
1
2
MYTABL0001:
COL1
a
b
COL1
a
b
IBM cannot make that decision for you.
[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"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
Was this topic helpful?
Document Information
Modified date:
20 March 2024
UID
nas8N1019409