If the processing of the ADD-FILE statement is abnormally terminated (e.g. in case of system crash or power failure), a zip container may be inconsistent. This inconsistency occurs because the directory containing the information about the container content has been overwritten.
The following mechanism enables the recovery of such corrupt containers: Before the processing of the first ADD-FILE statement, a copy of the container directory and the name of the container are saved in a backup file named as BS2ZIP.YYYY-MM-DD.HHMMSS.BAK. This file is deleted when the BS2ZIP application is normally terminated.
After abnormal termination the file is not deleted. The next time when the inconsistent container is opened, the system automatically searches for the corresponding backup file and restores the container in the state before the start of the last BS2ZIP session. However, the data added during that session still exist in the archive, but are not accessible. The repaired container is therefore bigger than the one before the crash. To remove those useless data, execute the REORGANIZE-ZIP-CONTAINER statement.
If several user IDs have access to the same container, the following constraint must be observered:
The backup file is always saved under the current user id. If the container is opened under a different user ID after the abnormal termination, the backup file cannot be found automatically. Therefore, the opening of the container open fails. In this case, the system administration has to locate the user ID of the backup file. The container then must be opened and restored under that user ID.