Stefan,
You cannot rely on "completed" from query event to indicate a successful
backup.
You need to trap and alert on error messages as well.
John
Stefan Holzwarth <[EMAIL PROTECTED]> on 06/22/2001 10:41:27 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: John Naylor/HAV/SSEG)
Subject: AW: Disk pool size vs large file
**********************************************************************
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy plc.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission.
Scottish Hydro-Electric and Southern Electric are trading names of
Scottish and Southern Energy Group.
**********************************************************************
We use TSM 3.7.3.8 @MVS with several 3590-tapes shared with OS390.
Our biggest files are 30GB (Exchange) and normally went direct to tape
by setting a sizelimit to the diskstorage pool.
What happened last week was an incredible short backuptime of the exchange
node
without any error. Looking through the dsmsched.log I found :
06/21/2001 02:33:46 ANS1312E Server media mount not possible
(due to no tape free at this moment?)
The TSM Client skipped the file and finished with the following summary:
06/21/2001 02:33:46 --- SCHEDULEREC STATUS BEGIN
06/21/2001 02:33:46 Total number of objects inspected: 8,565
06/21/2001 02:33:46 Total number of objects backed up: 246
06/21/2001 02:33:46 Total number of objects updated: 0
06/21/2001 02:33:46 Total number of objects rebound: 0
06/21/2001 02:33:46 Total number of objects deleted: 0
06/21/2001 02:33:46 Total number of objects expired: 26
06/21/2001 02:33:46 Total number of objects failed: 0
06/21/2001 02:33:46 Total number of bytes transferred: 138.73 MB
06/21/2001 02:33:46 Data transfer time: 74.62 sec
06/21/2001 02:33:46 Network data transfer rate: 1,903.68 KB/sec
06/21/2001 02:33:46 Aggregate data transfer rate: 1,067.74 KB/sec
06/21/2001 02:33:46 Objects compressed by: 0%
06/21/2001 02:33:46 Elapsed processing time: 00:02:13
06/21/2001 02:33:46 --- SCHEDULEREC STATUS END
The eventlog shows no exception for this schedule.
IBM's comment: "Works as designed"
Now I consider to do the backup of large files to the primary storagepool on
disk, because its very difficult to detect this error. (error.log shows no
errors)
With Regards, Stefan Holzwarth
> -----Ursprüngliche Nachricht-----
> Von: Sam Schrage [mailto:[EMAIL PROTECTED]]
> Gesendet am: Donnerstag, 21. Juni 2001 20:15
> An: [EMAIL PROTECTED]
> Betreff: Disk pool size vs large file
>
> I have a 56GB disk pool with the next pool to tape. I have a
> user, DB2
> Admin, that wants to back up a 125GB DB2 backup. What's the
> best way to
> handle this one user? If he/she backs up the file will it
> crash the system
> because it's bigger that the diskpool, or will it go right to tape?
>
> Sam Schrage
> TRW Systems
> [EMAIL PROTECTED]
>
