This is the reason why Tivoli has poured a ton of money into code quality in the past year that only showed up in recent months with the improved quality and timeliness of patch fixes. We will see with 5.1 if they have the cycle fixed. I can tell you this. You would definitely not be happy if you were using NetBackup. Code and quality are impossible to put in the same sentence for them, but they too are recognizing the importance of quality to the customers. Their sales folks even acknowledge TSM as a strong competitor now. This is good for both Tivoli and Veritas. Now that competition has been successfully achieved, the engineering staff sloppiness has to end, otherwise you do not have a job.
-----Original Message----- From: Thomas Denier [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 4:34 PM To: [EMAIL PROTECTED] Subject: Re: Large file system on HP-UX We finally got our problem resolved. Tivoli support recommended that we upgrade the client from 4.1.2.0 to 4.1.3.0 or 4.2.1.15 to get the fix for APAR IC29368. Tivoli support expected this to get the backup to run. Earlier ADSM-L postings indicated that the fix would cause the client to produce an accurate error message when it failed. I was not particularly surprised when it turned out that ADSM-L was right and Tivoli support was wrong. The error message from the 4.1.3.0 client confirmed that we were short of memory. Tivoli support quoted an estimate of 300 bytes per file from the developers. On this basis we increased the maximum data segment size to a gigabyte. We were able to get a successful backup with this amount of memory. We ran backups with the incrbydate option after some of the failures. We thought this would give us acceptable backup coverage until we got the problem resolved. We were wrong. When the 4.1.3.0 client ran out of memory it still generated a message reporting a successful incremental backup of the large file system. The subsequent backup with the incrbydate option behaved as if there really had been a successful backup, skipping all files with change dates prior to the end of the failed backup. The 4.1.2.0 also displayed the message reporting a successful incremental backup in conjunction with the incorrect 'User abort' message. I strongly suspect that this led to the same problem with the subsequent use of the incrbydate option, but I have not been able to prove it. The memory shortage would have been an inconvenience but not a data integrity problem if the incrbydate option had worked. In actual fact, we ended up with a major data integrity exposure because of Tivoli's sloppy quality control.
