>Did anyone come across this issue, we have a scheduled back that starts >nat 6am, and usually ends by 9. I just logged on to check on other processes >and noticed that the schedule is still running but the byte count is not >changing: >Primary Pool UNIX_TAPEPOOL, Copy Pool DRM_TAPE_- > POOL, Files Backed Up: 2179, Bytes Backed Up: > > 3,930,293,749, Unreadable Files: 0, Unreadable > > Bytes: 0. Current Physical File (bytes): > > 3,122,565,063 > >I issued a 'can pr' command and was prompted that the cancel is already >pending! >Thus, I can't cancel it. I hate to just bounce the TSM server without knowing >what might have caused this error! any help is appreciated!
The presence of a prior cancel indicates another chef in the kitchen, as indicated in another response. (You should find out who, and what compelled them to try to cancel a storage pool backup, of all things. Check your server Activity Log for indications of who, when. Maybe signs of pre-emption?) But the cancel did not "take", and that can be an indication of something fouled. Your query output does not reflect input-output volumes, which would appear at the bottom of that query response: - If they were there but not included in the posting: The obvious first thing to do is a Query Volume F=D on the input and output volumes to determine when I/O last occurred. Examine any operating system error log you have, which may reflect issues with media or hardware. Have your operator check both drives to assure they are active, with those volumes in them. And, of course, a 3 GB file takes some time to copy, and TSM doesn't like to fulfill Cancels until such a unit of work is complete. - If there were no volumes in the response: This would indicate that TSM thinks it has performed the initial aspects of the cancel. It may well be the 4.2 defect as indicated in the prior response. Check also that TSM is not waiting for a problematic volume dismount (have the operator check the drive, or perform an 'mtlib' or like query, for the volumes as reflected in Activity Log still being mounted). Richard Sims, BU
