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
|
