ADSM-L

Re: Using new tapes

1998-03-06 11:44:46
Subject: Re: Using new tapes
From: Bill Colwell <bcolwell AT DRAPER DOT COM>
Date: Fri, 6 Mar 1998 11:44:46 -0500
In <295401AFA48ED011B0D200805F3132850155F9AD AT mifen-comm07.maritz DOT com>, on
03/06/98
   at 09:16 AM, "Smith, Richard" <smithrr AT MARITZ DOT COM> said:

>ADSMer's,

>        I could really use some help... First the specifics

>Server: OS/390 V3R1
>Clients: NT 4.0, 3.5.1, Novell 4.x, Sun Solaris, UNIX

>        We just switch the type of tape we are using.  We were using 3490
>tapes, and now we are using 3490E tapes.  Last night was the first night
>using them, and I see a couple of problems.  First, I believe 3490E tapes
>are supposed to be able to hold approximately 2 GB per cart. However,
>looking at the tapes we used last night, there are only three carts that
>come near or over 2 GB.  Most of the tapes show an estimated capacity
>somewhere between 800 - 900 MB.  There are some that are higher, and some
>lower.  We also noticed that ADSM seemed to use a new tape for every
>process.  It looked like it would write just a little data on the tape, and
>when a new process started, it grabbed a new tape.

>        I guess these are my questions:

>1.  How do we let ADSM know the tapes should hold approximately 2 GB each?

I have started using extended length tapes also.  I didn't tell ADSM
anything at all about the new tapes.  I just defined the the volumes into
the same storage pool as the single length tapes, same devclass of course.
For the old tapes, the average full tape contains  491 Mb, for the new 952
Mb. The maximum on an old tape is 946 Mb, and for the new 1960 Mb.
Your numbers are in the ballpark.  Remember, the idea that a 3490E can hold
2 Gb comes from marketing people!  On rare occasions, when the data
compresses really well, it will, but on average you will get much less than
2 Gb.

>2.  Why is ADSM using a new tape each process instead of writing until the
>tape is full?

I have just started testing V3R1 and I saw some strange volume selection
too. I think there is a bug in the server.  I encourage you to call it in to
IBM!

>        Thanks in advance for any help!!

>Thanks,
>Rick Smith
>Maritz, Inc.
>Storage & Security Administration
>smithrr AT maritz DOT com
>(314) 827-1584

--
-----------------------------------------------------------
-----------------------------------------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma
bcolwell AT draper DOT com
-----------------------------------------------------------
=========================================================================
<Prev in Thread] Current Thread [Next in Thread>