ADSM-L

Re: Use of 3590J's and 3590K's in TSM

2006-03-07 13:43:02
Subject: Re: Use of 3590J's and 3590K's in TSM
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 7 Mar 2006 13:41:22 -0500
1) No.  There is no difference in the way TSM 5.1 and TSM 5.3 manage
3590 tapes.
2) We just throw 3590J's and 3590K's into the 3494 and check them in as
scratch to TSM.  Since the drives will read and write both types, TSM
doesn't care if you have mixed carts in the TSM pool.  It just writes
until it hits the physical end of tape.  No worries.
3) Correct.
4) Yes, any number of primary pools can be backed up to the same copy
pool.
5) We have had NO problems at all with the reliability of the 3590K's,
and we've had them for years.

(We have 2 3494's with identical setups; TSM on Windows 5.3, each
sharing a 3494 with a mainframe LPAR.)

If you want particular stgpools to be 3590K's, your current system of
pre-defining the cartridges will work fine.
But, if you are running short of slots, you probably need to be
replacing your ONSTIEe cartridges with the 3590K's.  
If you set MAXSCRATCH on your storage pool, you can have collocation,
but more than 1 client per cartridge.

For example (this is just an example):

If you have a library with only 100 slots available for storage, but 200
clients, you set maxscratch to 100.  
After TSM migrates 100 of the clients to cartridge, he starts doubling
up.
So you end up with 2 clients per cartridge.  You still get most of the
benefit of collocation, but in a controlled number of slots.
That may be what you have to do to solve your slot shortage.

And I would even think twice about creating the new disk and primary
storage pools.
Why not just add your 3590K's to the appropriate existing pool, and
gradually remove the J's as they get reclaimed and go empty?
You can gradually change out all your J"s with K's that way, with not
much work :>)

Hope that helps.
Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)






-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
John Kapturowski
Sent: Tuesday, March 07, 2006 11:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Use of 3590J's and 3590K's in TSM


 I've been reading the ADSM-L archives concerning 3590J and 3590K tapes
and still have some questions.  Below I will give some background
information on our system, but here are my questions.  We would also
appreciate any other advice anyone may have for us concerning this
issue,
or the way in which we have our processing set up for TSM.
My questions are:
1) Is TSM 5.3 different enough from version 5.1 that we should wait
until
we have upgraded to implement the use of the 3590K tapes?
2) From looking at the postings in ADSM-L, it looks to me that we could
add 3590Ks to our OFFSITE-POOL while still leaving the 3590J's in there.
(So that we could remove 3590J volumes from the offsite pool as they are
naturally emptied by reclamation.)  Is that true?
3) In order to get only a portion of our clients to have their data
stored
on 3590K's in primary storage, I will need to define a new dasd primary
storage pool and change these clients to use a copy group that
designates
this as their copy destination.  Then another primary tape storage pool
will need to be defined that will have the 3590K tapes defined to it.
Correct?
4) Can I have both the current "ONSITE-POOL" primary storage pool and
the
new primary storage pool use the same "OFFSITE-POOL" as their copy pool?
5) When reading postings on ADSM-L I saw several mentioning  that
3590K's
are problematic.  The postings were rather old, so perhaps they have
been
improved over the years.  We have found our J's to be quite reliable.
Can
we expect the K's to have the same reliability?

Here is the background information on our system:
- 3494 Magstar Robotic tape library with 3590 B drives
- TSM server runs on our zOS system and is Version 5, Release 1, Level
7.0
(plan to upgrade to TSM 5.3 within the next month or so)
- tapes used by TSM are predefined in the TSM tape pools (no scratch
tapes)
- All non-TSM applications that run on our z/OS system that need an
empty
tape use tapes that are defined as SCRATCH in the 3494 and the tapes
that
are defined to TSM are all in the 3494 as PRIVATE
-  All our tapes are currently 3590J's
- TSM storage pools are defined as follows:
      Storage              Device                 Estimated       Pct
Pct
       High     Low     Next Stora-
              Pool Name       Class Name       Capacity         Util
Migr
   Mig       Mig        ge Pool
      (MB)                                         Pct        Pct
              -----------                 ---------- ---------- -----
-----         ----         ---          -----------
            ARCHIVEPOOL     DISK                     500.6
0.0
      0.0          90         70
            BACKUPPOOL      DISK              262,973.7            0.0
0.0          90         70     ONSITE-POOL
            OFFSITE-POOL    3590         12,473,862.9          55.1

            ONSITE-POOL      3590         12,275,184.8          56.2
84.2
        90        70
            SPACEMGPOOL   DISK                         0.0
0.0
         0.0         90        70
 -  We don't currently use the ARCHIVEPOOL or the SPACEMGPOOL.
 - The "OFFSITE-POOl" is our copy storage pool.
 - Collocation is set to YES for our ONSITE-POOL
 - Collocation is set to NO for our OFFSITE-POOL
 - all our clients use copy groups that have a copy destination of
BACKUPPOOL
 - somewhere between 4AM and 6AM on weekday mornings we have an operator
run a script that has the following commands:
          query stg backuppool
          backup stg backuppool offsite-pool wait=yes maxpr=2
          backup stg onsite-pool offsite-pool wait=yes
          update stg backuppool highmig=0 lowmig=0
- Once the operator sees that there are no longer any active processes,
he
runs a second script that contains the following:
          update stg backuppool highmig=90 lowmig=70
          query process
          backup db type=full devclass=3590 wait=yes

Over the years our  use of TSM has grown considerably.  So now we are
planning to add some 3590K tapes to our mix.  We're thinking these will
be
especially useful for our OFFSITE-POOL, since that pool is not
collocated.
 We have many clients for which we store all of their data on a single
3590J tape, so we don't want to use 3590K tapes exclusively for our
collocated ONSITE-POOL.  However, there are a few servers for which we
are
storing a large amount of data that is collocated on 30-40 tapes for
each
server.  We would like to have the data for these servers put on the
3590K
volumes in a primary storage pool as well as in the copy storage pool.
One
of the considerations for this is that we are in need of ordering more
tapes, but  we are also getting low on the number of empty slots
available
in the 3494 library.

Thanks in advance for any information that may help us.


Barbara Andrews, Systems Software Specialist
++++++++++++++++++++++++++++++++++++++++
Western New York Regional Information Center
(716)821-7130
bandrews AT e1b DOT org

<Prev in Thread] Current Thread [Next in Thread>