Re: New Tape units
See imbedded comments ... -Original Message- Hal Merritt We are being told that the library system is 100% SMS controlled. We have had robots in the past, but had never heard this as a requirement. It this your experience? The ATL and 'tapes' are SMS managed the datasets on the 'tapes' are not. We intend to rework all of what little tape processing we have to exploit the new units. Does anyone have some thoughts for a migration plan? Depends on what you want to do. Stack datasets on tape for efficient use of tapes? Minimize tapes sent offsite? Reduce mounts? Etc. If your current tapes can be used in the ATL you may just be able to insert them an use as is. Did you have to invent some processing, such as off site tape ejects? You will probably want to look at OAM exits CBRUXENT and CBRUXVNL at a minimum. RMM may supply samples. RMM probably has a process for autoeject of tapes going offsite (probably an optional piece or RMM exit) Any other things we should be aware of? Do you still have stand-alone drives? Mucking around with unlabeled (i.e. non-barcoded) tapes is a bit of a hassle but does work OK. What is your volume of inserts/ejects. If fairly large you can configure an internal 'wall' for bulk eject/insert (60-90 at a time) instead of using the hole in the door (10 at a time). You will probably have DR concerns if you don't have an ATL there too. See DFSMS OAM PISA for Tape Libraries (SC35-0427-02 at z/OS 1.4 level) There may be a relevant RedBook too. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New Tape units
Porowski, Ken wrote: See imbedded comments ... -Original Message- Hal Merritt [...] You will probably want to look at OAM exits CBRUXENT and CBRUXVNL at a minimum. RMM may supply samples. RMM probably has a process for autoeject of tapes going offsite (probably an optional piece or RMM exit) Exits fro RMM are already in base z/OS libraries. RMM code also. IMHO there is no reason to change the exits. [...] Do you still have stand-alone drives? Mucking around with unlabeled (i.e. non-barcoded) tapes is a bit of a hassle but does work OK. What is your volume of inserts/ejects. If fairly large you can configure an internal 'wall' for bulk eject/insert (60-90 at a time) instead of using the hole in the door (10 at a time). The hole, CIOS (Convenient I/O Station) can have capacity of 10 or 30 cartridges. It depends on the order. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New Tape units
We use ZARA so had to supply our own. Depending on what the 'supplied' exits do you may or may not want to modify them. YMMV but it would make sense to understand what they are coded to do or not do. I forgot about the 30 CIOS option, It wasn't appropriate for our environment when we installed. We were using the bulk station and at one time were ejecting 400-500 tapes a day and a similar number of inserts (about half the usable slots for our 3490's). Not recommended but it worked for us at the time. We are now down to 10-20 after upgrading to 3592's. We used to have trouble with the 3490-F1A's but most of that was due to our dirty/old tapes. Ken Porowski -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, January 04, 2006 10:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: [IBM-MAIN] New Tape units Porowski, Ken wrote: See imbedded comments ... -Original Message- Hal Merritt [...] You will probably want to look at OAM exits CBRUXENT and CBRUXVNL at a minimum. RMM may supply samples. RMM probably has a process for autoeject of tapes going offsite (probably an optional piece or RMM exit) Exits fro RMM are already in base z/OS libraries. RMM code also. IMHO there is no reason to change the exits. [...] Do you still have stand-alone drives? Mucking around with unlabeled (i.e. non-barcoded) tapes is a bit of a hassle but does work OK. What is your volume of inserts/ejects. If fairly large you can configure an internal 'wall' for bulk eject/insert (60-90 at a time) instead of using the hole in the door (10 at a time). The hole, CIOS (Convenient I/O Station) can have capacity of 10 or 30 cartridges. It depends on the order. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
New Tape units
Our year end 'sweet deal' from IBM was a tape 'robot'. The IBM 3494 system. We don't do near enough tape processing to justify the VTS. Two robots, actually, one for our production site and one for the BR site. This system is to replace our two antique 3490 ACL units and two aged 3590 ACL units. Wanna buy some tape drives, cheap? ;-) We are using DFSrmm as our tape control software. All tapes are strictly for backup. No input tape allowed. And we don't plan to change that. The next phase is to leverage the two robots to do each others offsite backups. We are being told that the library system is 100% SMS controlled. We have had robots in the past, but had never heard this as a requirement. It this your experience? We intend to rework all of what little tape processing we have to exploit the new units. Does anyone have some thoughts for a migration plan? Did you have to invent some processing, such as off site tape ejects? Any other things we should be aware of? Thanks, the very best of the new year to all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
