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
|
