5) We have been using K's for 3 1/2 years, many are 3 years old and we
have nothing more than the normal amount of bad tapes, about 6-8 per
year. (4000 tapes currently)
I may be missing something, but where do you tell TSM what type of tape
you are using? What would happen if you just started adding K's? I may
need to add J's just to see...
Andy Huebner
-----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 10:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] 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
This e-mail (including any attachments) is confidential and may be legally
privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using, copying
or distributing the information in this e-mail or its attachments. If you have
received this e-mail in error, please notify the sender immediately by return
e-mail and delete all copies of this message and any attachments.
Thank you.
|
