We recently ran into an odd problem restoring files to an HP-UX 11.0 system with 4.1.2.0 client software. The TSM server is at 4.2.1.9 and runs under OS/390. We received the following error messages:
05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT': file exceeds user or system file limit 05/05/02 12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT': file exceeds user or system file limit We discovered that each of the restored files was 2,147,483,136 bytes long. The dsmsched.log entries for the backups of the files were still around, and showed a length of 2,147,483,647 bytes for each of the files, which is 511 bytes more than the length of each of the restored files. The original length turns out to be 2**31-1. The HP-UX administrator contacted HP, who had him check a variety of system settings. After reviewing the settings HP was adamant that there was nothing in the system configuration to prevent TSM from writing files of the original length. The restore process had one unusual feature. When the files were backed up /db/tjfrev6 and /db/tjfserv6 were file systems. When the files were restored /db/tjfrev6 and /db/tjfserv6 were ordinary directories within the /db file system. The loss of 511 bytes had no visible effect on the application that used the files. This is not quite as surprising as it sounds. The application treats each of its database files as a collection of 2048 byte blocks. The original length would have included 2047 bytes that did not fit into a block. Even though we dodged the bullet in this case, we are worried about running into this problem in the future. Is this a known problem?
