ADSM-L

Re: 3590-B1A/E1A

1999-08-22 19:36:22
Subject: Re: 3590-B1A/E1A
From: Simon Watson <simon.s.watson AT SHELL.COM DOT BN>
Date: Mon, 23 Aug 1999 07:36:22 +0800
I think if you mark all the B formatted tapes as ReadOnly then you
should be fine.  The DB won't keep track of the tape format as this is
completely independant.  Just add a few more tapes to each pool so
there is room to add new data and Reclamation or Move jobs on the old
tapes should do the rest for you.

Regards,
Simon
----------
| From: jbassi /  mime, , , jbassi AT GLORYWORKS DOT COM
| From: jbassi /  mime, , , jbassi AT GLORYWORKS DOT COM
| To: ADSM-L /  mime, , , ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: 3590-B1A/E1A
| Date: Saturday, 21 August, 1999 10:57PM
|
| > All scratch tapes will automatically be relabeled
| > and rewritten as 3590E format after the next PENDING/EMPTY cycle.
|
| Are you sure this is how it works?  I thought that when an old 3590
| B-series tape went back to scratch it wouldn't be formatted the next
| time it was needed because it had already been formatted.
|
| If you are correct in how this works, then ADSM must maintain a list of
| 3590B tapes and 3590E tapes in the DB to know which tapes have already
| been reformatted with the 256 track format.
|
| My team will be performing this transition for a customer in the next
| couple of days.  Has anybody else been through this who could comment?
|
|
| Joshua S. Bassi
| Storage Management Team Lead
| AIX / ADSM Certified Specialist
| Dickens Services Group
| (404) 386-9848
| jbassi AT gloryworks DOT com
| www.TeamDSG.com
|
| -----Original Message-----
| From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
| Sheelagh Treweek
| Sent: Friday, August 20, 1999 7:04 AM
| To: ADSM-L AT VM.MARIST DOT EDU
| Subject: Re: 3590-B1A/E1A
|
|
| Hi,
|
| We have just completed this exercise, replacing 10 3590s with 3590Es
| in a 3494.  Try and organise it so that you stop writing, upgrade the
| drives and then start writing again.  Otherwise, maybe upgrade one,
| introduce a temporary storage hierarchy and get some confidence using
| it solely with a few dedicated tapes.  I think it is too complex to
| run a mixed production environment of 3590/3590Es.
|
| The microcode you need is D0IC_533.  ADSM server needed is 3.1.2.40.
| We have Atape 4.4.0.0; atldd 4.0.1.0.  We have a shared 3494 and one
| adsm server is 4.3.2 and one 4.2.1.  All are fine.  The 3494 Library
| Manager code needs a specific version - I haven't got a note of that.
| The LM and first drive is the only change that needs the 3494 offline;
| subsequent drive updates and "teach" can be done on the fly.
|
| Replacing tapes can be a gradual movement.  All filling tapes must be
| marked READONLY.  All scratch tapes will automatically be relabelled
| and rewritten as 3590E format after the next PENDING/EMPTY cycle.
| PRIVATE tapes must be marked READONLY and when they have gone through
| PENDING/EMPTY must be set back to READWRITE and then they too get
| relabelled completely automatically.  You could make a script to do
| this.
|
| FILLING ones should be emtied first with MOVE DATA.  Later you can do
| MOVE DATA or reclamation on the rest to gradually move the contents of
| existing tapes, as is convenient.
|
| I am waiting to hear about whether the ADSM DB contains information
| about 3590/3590E.  We had a curious problem a few weeks ago which I
| submitted as a PMR, but have spent several weeks convincing them that
| the 3494 *is* working (and not broken for several weeks!); the problem
| really was that I believed the ADSM DB wrongly thought 3 3590E private
| (and formerly scratch) tapes were in fact 3590s but I can't prove it.
| It refused to mount them unless they were READONLY ...  which leads me
| to believe there must be a flag in there somewhere but it's not
| visible to me!  It was only these 3 tapes though and happened when we
| were in validation phase, so hopefully it wouldn't impact on you.
|
| Hope this helps.
| Regards, Sheelagh
| ------------------------------------------------------------------------
| Sheelagh Treweek                   Email: sheelagh.treweek AT oucs.ox.ac DOT 
uk
| Oxford University Computing Services           Tel:   +44 (0)1865 273205
| 13 Banbury Road, Oxford, OX2 6NN, UK           Fax:   +44 (0)1865 273275
| ------------------------------------------------------------------------
|
|
|
|
| >MIME-Version: 1.0
| >Content-MD5: HAzXfNhX471guRuvJ5GjaA==
| >Date: Wed, 18 Aug 1999 13:52:12 +0200
| >From: Eckhard Trinkaus <trinkaus AT HRZ.UNI-MARBURG DOT DE>
| >Subject: 3590-B1A/E1A
| >To: ADSM-L AT VM.MARIST DOT EDU
| >
| >Hello,
| >
| >we are considering an upgrade of our 3590-B1A tape units (installed in a
| 3494)
| >to 3590-E1A units.
| >
| >- We would like to share any experiences from sites which did sich an
| upgrade.
| >
| >- What is the best way to replace tapes written by B1A units by tapes
| >  written by the upgraded units ?
| >
| >- Does the ADSM data base contain any information on the type of 3590 unit
| used
| >  to write to the volume?
| >
| >Thanks in advance,
| >With kind regards / Mit freundlichen Gruessen
| >Eckhard Trinkaus
| >
| >********************************************************
| >Eckhard Trinkaus
| >Hochschulrechenzentrum der Philipps-Universitaet Marburg
| >Hans-Meerwein-Strasse D35032 Marburg/Lahn
| >Bundesrepublik Deutschland
| >Tel.:  +49 6421 2821554 / Fax: +49 6421 2826994
| >Email: trinkaus AT hrz.uni-marburg DOT de
| >********************************************************
|
<Prev in Thread] Current Thread [Next in Thread>