Sorry for the little excitement,
I have found a "mysterious" configuration error for that node:
The number of mount points was 0. It seems I accidentally changed the option
during an update of the clientpassword with the web gui.
Under normal conditions the client should wait until its mount wait time is
over.
How this is reported I don't know..., maybe the described problem still
exists.
With regards, Stefan Holzwarth
> -----Ursprüngliche Nachricht-----
> Von: Jeff Bach [mailto:jdbach AT WAL-MART DOT COM]
> Gesendet am: Montag, 25. Juni 2001 16:27
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: Disk pool size vs large file
>
> Stefan,
>
> How can I find out it this will effect me
> when converting
> using Informix and Exchange servers on AIX 4.1.3?
>
> ADSM SUPPORT PEOPLE,
>
> How do we find out about all of these
> "FEATURES" of design
> that cause ADSM to break?
>
> Jeff Bach
> Home Office Open Systems Engineering
> Wal-Mart Stores, Inc.
>
> WAL-MART CONFIDENTIAL
>
>
> -----Original Message-----
> From: France, Don G (Pace) [SMTP:don.france-eds AT EDS DOT COM]
> Sent: Saturday, June 23, 2001 3:17 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Disk pool size vs large file
>
> Inspect your server activity log; there's probably
> better info,
> there --
> like a tape mount request that didn't get satisfied within the
> "mount wait"
> time on the device class of the storage pool your
> management-class/copy-group points to. I've seen
> this happen where
> the
> max-scratch was set too low, or the TDP node name was
> trying to use
> multiple
> mount-points (when the node was registered for less than the
> request)...
> WAD.
>
> Also, most backup agents (via the API) have gotten
> smart enough to
> send the
> estimated "glob" size, which can easily be used to
> send the data to
> the
> nextstg pool (usually, tape). We set max-size on
> most disk pools,
> and we
> use scratch tapes in the tape library (maxscr=9999,
> rather than
> pre-defined
> volumes which cause mount request time-outs), so any
> file or "glob"
> greater
> than max-size goes to the nextstg pool.
>
> Don France
> EDS Infrastructure Engineering
> San Jose, CA
> mailto:dfrance AT pacbell DOT net
> PACE - http://www.pacepros.com
> Bus-Ph: (408) 257-3037
>
>
>
>
> -----Original Message-----
> From: Stefan Holzwarth
> [mailto:stefan.holzwarth AT ZENTRALE.ADAC DOT DE]
> Sent: Friday, June 22, 2001 2:41 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: AW: Disk pool size vs large file
>
>
> 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:sam.schrage AT TRW DOT COM]
> > Gesendet am: Donnerstag, 21. Juni 2001 20:15
> > An: ADSM-L AT VM.MARIST DOT EDU
> > 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
> > sam.schrage AT trw DOT com
> >
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the individual or entity to
> whom they are addressed. If you have received this email
> in error destroy it immediately.
> **********************************************************************
>
|
