Moving from 3590 B11s to 3494 & B1As

MailSaveOptions: 2
Logo: StdNotesLtr17
Sign: 0
Encrypt: 0
DefaultMailSaveOptions: 2
FormName:
SwipeFrom: Craig Bell/Tucson/IBM @ IBMUS
Classification:
Importance: 2
SenderTag:
ExpandPersonalGroups: 0
ValidationTesting: 0oldfrom: Craig Bell/Tucson/IBM
tmpAction:
$UpdatedBy: CN=Craig Bell/OU=Tucson/O=IBM

    CN=D03NM019/OU=03/OU=M/O=IBM

    CN=D03AU036/OU=03/OU=G/O=IBM


The key to moving libraries without moving data is in the device class.  That
is the switch that ties a storagepool to the library.  (See the DEF STGPOOL and
DEF DEVC commands, and you'll understand.)  The data on tapes "reside" in a
storage pool, while the cartridges "reside" in a library.  You can change the
library without changing the data, and you can  do this by updating the
DEVCLASS's library= parm to point to the new 3494 library.  You'll also have to
make sure that the barcode label you put on the cartridge is IDENTICAL to the
label on the tape.  (If not, ADSM will reject the mount of that tape in the
3494.)  Define your new 3494 & 3590 drives, update the devclass to point to the
new 3494 library (and reset the mountlimit to the number of 3590s in the 3494),
and then check the cartridges out of the B11 scsi library and check them into
the 3494.  Nothing else has to change.

The only hitch I can see is if you currently have multiple devclasses going to
multiple B11s.  To follow my directions, you would need to update each
devclass, and the sum of all devclass' mountlimits cannot exceed the number of
drives in the library.  Because of that last part, you definitely want to
migrate your users into one storage pool and use one devclass only.  And to do
that you WILL need to move data.

Craig Bell

PS.  The following is basically correct except that I don't see how a user
could restore data from the tapes transferred, or checked-into, the 3494
without changing the devclass' library pointer as I explained above.  Just
because the tape is IN one library vs. another doesn't mean the storagepool
knows what library its data is in.  It goes to the devclass to resolve its
location.

        When we migrated to our 3494, here are the steps I followed (as
     best as I can recall from 16 mos ago).  Although we've got 3490e, 3590
     shouldn't be any different except for the ATL scratch category.

     1. setup ATL (hardware, software, drivers, etc)
     2. Define ATL to ADSM (library, stgpools, drives, etc)
     3. Setup new migration path in ADSM (copygroups, nextpool)
        * don't forget to activate policies as needed.
     4. Tapes in Manlib (standalone drives) had been explicity defined.
     5. Update vols access=unavailable.
     6. Put tape in ATL
     7. Checkin libv  status=priv
     8. Update vol acc=reado.
     9. As tapes became empty:
          Checkout libv llll xxxxxx
          Delete vol xxxxxx
        -- put tape back in atl
          Checkin libv llll xxxxxx stat=scr

     The stgpool for the atl has a large maxscratch pool.  Thinking back,
     it wasn't really a big nightmare as most of our clients DON'T restore.