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 <
|
