Hi Richard:
- yes, this particular node goes directly to tape, colocated.
Nothing looks out of wack. Just to be sure I'm doing a move data on the volume now
Volume 000224 in use by node RSCWS.
SHOW VOLUMEUSAGE completed.
tsm: BACKUP>q vol 000224 f=d
Volume Name: 000224
Storage Pool Name: AIX3590BACK
Device Class Name: 3494ATAPE
Estimated Capacity (MB): 12,666.7
Pct Util: 61.2
Volume Status: Filling
Access: Read/Write
Pct. Reclaimable Space: 41.8
Scratch Volume?: Yes
In Error State?: No
Number of Writable Sides: 1
Number of Times Mounted: 881
Write Pass Number: 1
Approx. Date Last Written: 10/08/00 06:17:06
Approx. Date Last Read: 10/10/00 17:35:22
Date Became Pending:
Number of Write Errors: 0
Number of Read Errors: 0
Volume Location:
Last Update by (administrator):
Last Update Date/Time: 10/03/99 19:30:37
dsmerror entry:
10/11/00 13:58:52 cuPing: Out of sequence verb: verb: 61
10/11/00 13:58:52 sessOpen: Session state transition error, sessState: sSigned
On.
10/11/00 13:58:52 sessOpen: Transitioning: sSignedOn state ===> sTRANSERR stat
e
10/11/00 13:58:52 ANS1312E Server media mount not possible
>>> [EMAIL PROTECTED] 10/11/00 01:46PM >>>
>10/11/00 12:50:04 ANR0406I Session 7978 started for node RSCWS (AIX) =
> (Tcp/Ip 129.10.199.10(40421)).
>10/11/00 12:50:09 ANR0406I Session 7979 started for node RSCWS (AIX) =
> (Tcp/Ip 129.10.199.10(40423)).
>10/11/00 12:50:10 ANR0403I Session 7979 ended for node RSCWS (AIX).
>10/11/00 12:50:11 ANR0480W Session 7978 for node RSCWS (AIX) terminated =
> - connection with client severed.
>
>
>>> [EMAIL PROTECTED] 10/11/00 11:33AM >>>
>>ANS1312E Server media mount not possible
Larry - That's very interesting...no indication of even trying to mount a
volume. Apparently, the server immediately knew that it could not
satisfy the request: there was no timeout as indicated in the ANS1312E
message description, and MOUNTWait could not be the issue since its unit of
measurement is minutes, and the rejection here was in seconds.
You didn't say, but I'll assume that you are set up to back up directly
to tape. I'll also assume the common collocation choice of "by node". In
that case the server would want to append the new data to the end of the
tape that it was last filling for that node. Perhaps that volume is in a
peculiar state - not bad enough to cause the server to go use a new scratch
or, if no scratches left, the end of any other tape. See if you can determine
what that tape was, from the prior successful backup for that node reflected
in the Activity Log or queries, and then do a Query Volume F=D to see what
it's state is; and also check that it is still in the library.
If you are backing up to an intermediate disk storage pool, check its
status and capacity.
Beyond that, see if there is any dsmerror log with further indications.
Richard Sims, BU
