Frank,
I am confused. When we converted from 3480 to 3490's, there was no
problems at all. We used the old 3480 tapes that we had as input and
did not worry about what tape it called in, ie, whether it was a new
3490 or an old 3480 tape. As far as the filling tapes were concerned,
ADSM seemed to know that this was in 3480 format and started another
tape. We then at our leasure started to replace the old 3480 tapes with
3490s using move datas, or just waited for the normal expiration process
to create empty tapes and then replace them as they become available.
We had no problems in the conversion. Let me know if this helped.
Dave Larimer
>----------
>From: Frank Rehor[SMTP:Frank.Rehor AT CLOROX DOT COM]
>Sent: Monday, June 02, 1997 7:55 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Tape conversion from 3480 to 3490
>
>Jerry,
>
>I posted a similar question about 6 weeks ago and got no response. We were
>planning the same conversion and I got the same info from STK. I pursued the
>issue with IBM but could get no definitive answer. IBM thought that the
>conversion might work with only changing the tape status to READONLY (your
>comment below incorrectly says READWRITE), but they couldn't guarantee it. To
>be
>safe I built, on paper, an entire scenario of what to do, based on the RTA,
>if
>after the conversion ADSM still asked for a mount of an existing tape on a
>3480
>device.
>
>Fortunately, as I had hoped, the conversion worked with only needing to issue
>the Update Vol command. In our case we have 4 different device classes so I
>issued the command once for each class:
>
>Upd vol * access=readonly whereaccess=readwrite wheredev=devname
>
>Don't make the mistake I made when I first tested this and left off the
>'wheredev=devname' thinking I would get all of them at one time. I not only
>changed the access of my tapes but also of my Storage Pools!
>
>After the conversion I tested ADSM by issuing a MOVE DATA to see where it
>would
>ask for the input tape to be mounted. It mounted on a new 3490.
>
>I don't know what you are using to zap your MVS catalog(s), but we have
>Catalog
>Solution from Softworks and it worked like a charm.
>
>I would be happy to answer any other questions that you might have. Feel
>free
>to phone. Good luck.
>
>Frank Rehor
>The Clorox Services Company
>frank.rehor AT clorox DOT com
>(510) 847 4814
>
>______________________________ Reply Separator
>_________________________________
>Subject: Tape conversion from 3480 to 3490
>Author: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> at Internet
>Date: 5/30/97 3:32 PM
>
>
>Date: May 30, 1997 Time: 1:44 PM
>From: Jerry Lawson
> The Hartford Insurance Group
> (860) 547-2960 jlawson AT thehartford DOT com
>
>We are finally going to convert our 3480 Tape devices to 3490 - Actually STK
>9490 drives in our STK 4400 Silo. The conversion will be done over the July
>4 holiday - we are hopping there aren't any fireworks. At this time, the
>plan seems to be to replace ALL of the drives at one time, and then ZAP the
>catalog to update all of the device types accordingly. Since the 9490 drives
>will read either 18 track (3480) or 36 track (3490) format, most everything
>should be transparent (or is it "fat dumb and happy"?)
>
>For ADSM there seems to be 2 areas of concern. First are the tapes in
>"filling" status. One thing you can't do with a 18 track tape is open it for
>"MOD" on a 36 track drive. So, we will go in with an Update Volume command,
>and change the status of all tapes in "filling" status to an access mode of
>READWRITE. We have about 100 tapes in this status at any time, so if the
>tapes hang around for a time without being returned to scratch, we can always
>do MOVE DATA commands to free them up.
>
>The second area seems to be not an issue, but I want to be more certain of
>it. The DEVCLASS statements have a device type of "S", which is our esoteric
>description of a 3480 device type. As I said before, we will change our IO
>Gen so that "S" is now a 3490 device. It would seem, then, that for the rest
>of the tapes in our pool, I do not have to do anything - they will be
>readable on the 9490 drives, and new tapes will be written at the higher
>density - 36 track - since that is now the default.
>
>Has anyone else had this experience? Our STK rep (who is good on hardware
>but hopeless on software) pointed out an info item from IBMLink
>(RTA000065483) that talks about someone who went through this, but had
>trouble since they used a generic definition of 3480, and then did not change
>it. When ADSM went to mount the existing tapes, MVS went looking for a 3480
>device (surprise!). The suggested plan of attack was to use the UPDATE
>DEVCLASS to change the devtype to SYS3480R, which will then cause the tape to
>be mounted on either a 3480 or 3490, depending on what's available. HOWEVER,
>the RTA answer then goes on to tell the customer to set up a NEW device class
>for the 3490E drives, and use it for all new tapes created, and of course
>then migrate the old tapes to the new pool. The problem is that this
>customer had 10 tapes - I currently have 6600. I just did a migration 6
>months ago, before I turned on the copypool features, and had about 2600
>tapes - it took us what seemed like forever to do the migration (about 2
>months) - so I do not want to go there again if I can avoid it.
>
>It would look to me as though we should not have to do the migration - as I
>mentioned earlier, the use of esoteric "S", and the fact that ADSM does not
>catalog its tapes, as I interpret it, means that ADSM will act appropriately
>here. I do not care if my pool has a mix of 3480 and 3490 tapes in it, since
>we return all tapes to scratch (TMS) and do not reuse them.
>
>Has anyone else been through this scenario?
>
>Jerry Lawson
>jlawson AT thehartford DOT com
>
|
