Either an aborted DDM application has left the file in an inconsistent state or a non-DDM application has changed the file. The local VSAM file system resynchronizes the file-change date and time if it can get write access to the file, unless a higher severity condition prevents it from doing so. Re-synchronizing the date and time corrects only this particular file-damaged condition, but the file may still be damaged. To verify that the file is not damaged, use DDMCopyFile or DDMUnLoadFileFirst with AccessFlags=DDM_BYPDMG|DDM_RTNINA and inspect the result.
The file-change date and time recorded by the VSAM API for the base file is not the same as the base file's file-change date and time that was recorded as an attribute of the index file. Either an aborted DDM application has left the file in an inconsistent state or a non-DDM application has replaced a base file or an index file without replacing all of the files in the file object. The local VSAM file system does not resynchronize the file-change date and time.
Both of the above conditions can exist at the same time for the same index file, causing two FILDMGRM reply messages to be returned, one for SVRCOD=4 followed by one for SVRCOD=16.