-----Richard Sims wrote: ----- >One possible, but less likely cause could be a volume history set of >such size that it exceeds the "filesize" Unix Resource Limit under >which the TSM server was started: if yours is a large set, try >pruning and see if the problem goes away. Another possible cause is >the TSM server running out of file descriptors as it attempts to >open that external file: if low, boost that number for server >start.
The volume history file is around one megabyte. We create and fill one gigabyte scratch volumes in file device classes every night. I su'ed to root and executed a ulimit command. The limit for open files is 1024. The only ulimit command in the /etc/init.d/dsmserv script pertains to core file size, so the TSM server is presumably using the 1024 file limit. We have 5 pairs of mirrored recovery log volumes, 26 unmirrored database volumes, a maxsess option value of 120, and 9 tape drives. I have not been able to think of any plausible scenario that leads to crowding the open file limit. If we were hitting the open file limit I would expect to see write failures for a variety of files, not just the volume history file.
