Hi Dan
Thanks for the e-mail.
When the reclamation process is kicked off for the copy storage pool,
all volumes that are reclaimed become updated with a status of "empty"
but they are still defined to the copy storage pool.
My script finds all "empty" volumes and does an "update volume ...
access=readwrite" which then causes ADSM to delete all references to
these volumes. i.e. at this point, ADSM doesn't even know these tapes
exist.
These "empty" volumes are then physically returned to the "scratch pool"
(which is where all scratch tapes are actually kept). Scratch tapes are
then checked into the library on a daily basis using the "label libvol"
command. I specify the "overwrite=yes" option just in case someone
decides to swap bar code labels between tapes (OK, I may be
over-paranoid here!).
As regards Craig's note concerning the "8778W Scratch vol ...." error
message, I did check for this but unfortunately no such error messages
were ever generated.
I prefer to label new tapes rather than just checkin tapes unlabelled
just in case the library is unable to read the bar code label and has to
resort to reading the label of the tape itself.
So, I'm still at a loss to see why this problem occurs (albeit quite
rarely). The plot thickens...
Regards
Phil
Phil Chissell
National Power plc
Windmill Hill Business Park
Whitehill Way
Swindon
Wilts. SN5 6PB
UK
Tel: +44 (0)1793 894237
Fax: +44 (0)1793 894230
MailTo:Phil.Chissell AT natpower DOT com
> -----Original Message-----
> From: Dan Giles [SMTP:Dan_Giles AT MANULIFE DOT COM]
> Sent: Thursday, July 16, 1998 2:06 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Private/Scratch library tapes
>
> *** WARNING ***
>
> This is an Internet mail message from outside National Power.
> If you answer the message, take care that sensitive
> information is not disclosed to third parties.
>
> If the message has attachments that could be executable
> programs, these MUST be checked for viruses. To do this,
> file the attachment to the PC (using FAP) and then use the
> Infrastructure virus checker (under Desk Management) to scan the
> appropriate device.
>
> Original message follows:-
>
> Hi Phil.
>
> With the information I have so far, this is the theory that I have.
> (Feel free
> to disprove by example.)
>
> Every now and then, one of the old returned tapes is not 101% empty,
> but perhaps
> will have just a couple of files or a piece of a file. That is, it may
> show 0.0%
> utilization, but is not empty. When you check them in as scratch, they
> get set
> as scratch. (Relabelling is irrelevant, it is that you are following
> the same
> procedure for both new and old tapes.)
>
> When ADSM grabs this tape as a scratch tape, it checks the database
> and,
> according to the database, there is data on this tape and it gets
> remarked as
> private. Craig sent a note a couple of days ago asking if there were
> any "8778W
> Scratch vol ... changed to Private Status to prevent re-access"
> messages in the
> activity log. Did you check this?
> Even if the volume is empty, you still may get this. When stg pool
> tapes are
> returned and checked in, you need to update the status of that volume
> to
> readonly or readwrite before ADSM returns the volume to scratch. After
> the
> checkin, if you do a "q vol" on the returned volumes, do you get a
> reply other
> than "no match found"? Thinking about it now, I would suspect that
> this is
> probably the case. If it is, you can simply add an "upd vol vol_name
> acc=readon"
> command after the checkin command. If it's not an old data volume,
> you'll just
> get a "volume not defined in a storage pool" message.
>
> I've had to develop smit and pearl scripts, and use a small database,
> to handle
> the processing and return of off-site tapes (database and stg pool)
> and scratch
> tapes. Returned database tapes and scratch tapes can be checked in as
> scratch.
> Old tapes have to be checked in as private and then have their status
> reset from
> offsite.
>
> We are currently still on enhanced adsm 2.1.5.12 and using the acsls
> tape
> library manager. New scratch tapes are automatically labelled when
> they get
> checked in and adsm sees that there is no label on them. (So there is
> no need to
> issue an actual label command.) I should certainly check that this
> will remain
> the case with V3! You may also want to varify that your additional
> label command
> is actually required, or set overwrite to "no" so that only brand new
> volumes
> are labelled.
>
> I hope I have at least come close to giving you some answers relavent
> to your
> situation.
>
>
>
>
>
> From: Phil Chissell <phil.chissell AT NATPOWER DOT COM> on 07/16/98 09:33 AM
> GMT
>
> Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc: (bcc: ADSM)
> Subject: Re: Private/Scratch library tapes
>
>
>
>
> Dan
> I do relabel the volumes when I check in the scratch tapes. The
> thinking behind this was that the scratch tapes could either be ones
> that have been reclaimed or else new virgin tapes which won't have
> been
> labelled. To keep the "checkin" script consistent we elected to
> relabel
> all "checkin" tapes. I realise there will be an overhead with
> labelling
> pre-labelled tapes but this surely would be minimal.
> I be interested to hear your comments on this...
> Regards
> Phil
> Phil Chissell
> National Power plc
> Windmill Hill Business Park
> Whitehill Way
> Swindon
> Wilts. SN5 6PB
> UK
> Tel: +44 (0)1793 894237
> Fax: +44 (0)1793 894230
> MailTo:Phil.Chissell AT natpower DOT com
>
> > -----Original Message-----
> > From: Dan Giles [SMTP:Dan_Giles AT MANULIFE DOT COM]
> > Sent: Wednesday, July 15, 1998 5:58 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Private/Scratch library tapes
> >
> > *** WARNING ***
> >
> > This is an Internet mail message from outside National Power.
> > If you answer the message, take care that sensitive
> > information is not disclosed to third parties.
> >
> > If the message has attachments that could be executable
> > programs, these MUST be checked for viruses. To do this,
> > file the attachment to the PC (using FAP) and then use the
> > Infrastructure virus checker (under Desk Management) to scan the
> > appropriate device.
> >
> > Original message follows:-
> >
> > Hmmm. Are you saying that when you return the tapes from offsite,
> you
> > relabel
> > them? I have a couple of ideas if this is the case.
> >
> > Let me know.
> >
> >
> >
> >
> > From: Phil Chissell <phil.chissell AT NATPOWER DOT COM> on 07/14/98 05:50
> PM
> > GMT
> >
> > Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> >
> > To: ADSM-L AT VM.MARIST DOT EDU
> > cc: (bcc: ADSM)
> > Subject: Re: Private/Scratch library tapes
> >
> >
> >
> >
> > The scenario is as follows:-
> > (1) Everyday ADSM does a backup stgpool command
> > (2) The backup stgpool tape(s) are checked out using a "checkout
> > libvol ... checklabel=yes" command and an "update volume ...
> > access=offsite" command
> > (3) ADSM kicks off an "audit library ... checklabel=barcode"
> > process
> > (4) The tape is ejected and taken offsite and a scratch tape is
> > put
> > into the eject port
> > (5) ADSM issues a "label libvol ... checkin=scratch
> > labelsource=barcode overwrite=yes" command to checkin the scratch
> tape
> > (which may or may not already be labelled)
> > (6) ADSM kicks off an "audit library ...
> > checklabel=barcode"
> > process
> > (7) Once a week, the offsite tapes are reclaimed and the above
> > process re-iterates.
> > Now the problem is that (very) infrequently, a tape appears in the
> > output of a "query libvol" command as being a private tape when it
> is
> > not a member of any storage pools nor is used as a database backup
> > tape.
> > This tape then needs to be remarked as being scratch by issuing a
> > "update libvol ... status=scratch" command
> > That's about the size of it!
> > Regards
> > Phil
> > Phil Chissell
> > National Power plc
> > Windmill Hill Business Park
> > Whitehill Way
> > Swindon
> > Wilts. SN5 6PB
> > UK
> > Tel: +44 (0)1793 894237
> > Fax: +44 (0)1793 894230
> > MailTo:Phil.Chissell AT natpower DOT com
> >
> > > stuff deleted <
|
