Like Mecki, we have standardized our server and client installs so the
/usr/lpp/adsm... are separate filesystems and are included in rootvg;  we
then run mksysb nightly, so in case of disaster, the machine is quickly
re-built to the point where ADSM can be started.

For what you ask, out tape librarian previously had run dsmlabel, without
deleting the drive.  Once we got to v3, they use the internal label command
for everything.  They intermixed tapes between v2 and v3, indiscriminately
and never complained about this kind of problem;  the only time they got in
trouble was when they used checkout/checkin with older 3590 tapes, written
at the old density... needed to be instructed on checkin as read-only, so
ADSM would not try to open for output, even when using for input to a MOVE
DATA or reclamation process. We use 3590 & 3575 tapes -- if that makes any
difference, I don't know.


Regards,
Don France

Technical Architect, P.A.C.E.
San Jose, CA
mailto:dfrance AT pacbell DOT net
PACE - http://www.pacepros.com
Bus-Ph:   (408) 257-3037




> -----Original Message-----
> From: Purdon, James [mailto:james_purdon AT MERCK DOT COM]
> Sent: Monday, January 03, 2000 7:53 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Difference between dsmlabel and internal "label volume"
> commands
>
>
> Hi,
>    As part of our daily operations procedure, we perform a
> cpio-based backup
> of the ADSM volume history and device configuration files to a scratch
> volume which we check out of ADSM.  Lately this particular
> procedure has
> started to fail, apparently during tape positioning. In all cases the
> failure has been traced to a volume labeled using the internal "label
> volume" command as opposed to the older, external "dsmlabel" command.
>
>    Because we are a fairly old ADSM installation, we have
> evolved volume
> labeling and check in procedures using the external dsmlabel
> command.  While
> we would like to move to using the internal "label volume"
> command because
> it would greatly simply the existing script (which has to
> delete a drive
> from ADSM in order to give it to dsmlabel and then redifine it after
> dsmlabel is complete), as long as it produces tapes that are
> not identical
> to those produced by dsmlabel, we are stuck using the older external
> command.
>
>    Has anyone else noticed this problem?  Does anyone else
> perform tape
> backups of the ADSM volume history and device cofiguration
> files?   If so,
> what mechanism do you deploy?
>
> Jim
>