If you see data when viewing a LF but not when view the PF, it means that the LF is attached to a different file.
Do a DSPFD of the LF and it will show you what PF it is attached too.
You should also check the PF to see in there are any LF attached to it.

You may be able to just delete the PF and move the PF that is attached to the LF back into the library where it belongs.

-----------------
Or the file is really there but you cannot see it -- don't have authority to it.

Do dspfd on the logical that will indicate the physical file and the library.
If the logicals are native logicals..created with CRTLF (not SQL create view) .. then you cannot delete the physical without deleting the logicals first.

Phil

----------------
Generally, interactive SQL is good at sniffing these out -- the fields in error will show ++++ instead of a value but you've got to do a manual scan of the records -- hope it's not a long file.
Select * from myfile

Phil


=======

Another option to find the bad data is to do a CPYF to a new file.
It should crash when it hits the bad data..
Then you can find out how many records it copied and go back the the original file and look at the records that come after that point.
You should be able to see the ones with bad data. Generally they will be all together.
Now you can try to update the the bad values with SQL.
If that does not work, you can use multiple CPYF statements to build a good file omitting the bad records.
First copy from rcde #1 to the Rcd number fo the last good record.
Next do CPYF *Add selecting from Rcd# (1st one after the last bad record) to *END
Now either buld new LF over the new file, of do another CPYF from youy new file to repalce the corrupt one.
If you do this porcess be sure no updates are being done while you are fixing as you may lose those records.
------------
Try CMPPFM to compare the member of the file with the bad records to the one without the bad records.
Phil

-----------------------

This has worked well for us in the past:
To recover as many undamaged records as possible, do the following:


1 On the IBM® OS/400® or IBM® i5/OS? command line, type the following:

OVRDBF FILE(x) SEQONLY(*YES 1)

Press the Enter key. The OVRDBF command ensures that the file to be
copied is processed sequentially, one record at a time.


2 On the OS/400 or i5/OS command line, type the following:

CPYF FROMFILE(liba/x) TOFILE(QTEMP/x) CRTFILE(*YES) FROMRCD(1)
ERRLVL(999) COMPRESS(*YES)

Press the Enter key.

Notes:
a Save QTEMP/x to a SAVF or tape as a backup in case QTEMP is lost.
b If there are problems with the copied from file, consider
manually creating the file that you are going to copy to. For
example, the CPYF command would use CRTFILE(*NO) rather than
CRTFILE(*YES). In addition, the SQL statement CREATE TABLE could
also be used.


3 On the OS/400 or i5/OS command line, type the following:

DLTF liba/x

If the file cannot be deleted because of logical files, rename the
original file to another name in the same library. Press the Enter
key.


4 On the OS/400 or i5/OS command line, type the following:

MOVOBJ OBJ(QTEMP/x) OBJTYPE(*FILE) TOLIB(liba)

Press the Enter key. If the original had logical files, rebuild the
same logicals over the new copy of the file.


5 Did you RENAME the original file in step 3? If NO, then STOP. You
do not need to do step 5. If you did rename the file during step 3,
on the OS/400 or i5/OS command line type the following:

DLTF liba/all_logicals_over_renamed_physical and DLTF
liba/renamed_physical

The CPYF command creates a new copy of the file that contains all of
the records that could be accessed. The damaged records are noted in
the job log. The value indicated for the ERRLVL parameter should be
considered a threshold value to be set by the user to indicate how
many damaged records of data are to be tolerated before replacement
from a backup copy is deemed necessary. Exceeding this threshold
limit terminates the CPYF command.

After the CPYF command has completed, the user should compare the
total number of records found in the new version of the file with
that of the old. If this value is the same for both files, there
appears to have been no loss of data. If this value is found to
differ between the two files, it might be necessary to recover those
records missing from the new version of the file through data entry,
backups, and so on.

If it is necessary that the file be processed as a direct file, the
deleted records must also be copied to the new file. This is
accomplished by changing the value of the COMPRESS parameter to *NO.

The CPYF command uses the parameter FROMRCD(1) to avoid possible damage in
the access path.

Note: There may be other things that need to be added back to physical
file, such as triggers and constraints.

www-912.ibm.com/8625680A007CA5C6/1AC66549A21402188625680B0002037E/5C3BA74EFCD591AE862565C2007CEE45

Voodoo
-------------------------------------

Please complete the following information:

REGISTER / LOG-IN TO DISCUSS

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Submit your e-mail address below to continue

E-mail: 

E-mail: 

Handle:   

Password: 

Forgot Password?

Create Handle: 

Your handle identifies you in ITKnowledgeExchange. Max 30 char.

Create Password: 

Confirm Password: 

Yes, I agree to the IT Knowledge Exchange  Terms and Conditions.

hidden modal window