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