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:[EMAIL PROTECTED] On Behalf Of John Kapturowski Sent: Tuesday, March 07, 2006 11:39 AM To: ADSM-L@VM.MARIST.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 [EMAIL PROTECTED]
