Well, I don't know if this helps, but:
 I know one site that uses ADSM.ON for the onsite tapes, and ADSM.OFF for
the offsite tapes.
That way all the tapes have the same HLQ for ACF2 purposes, but there is
still enough info for CA-1, at least, to tell the pools apart for vaulting.
Don't know if that would help wtih your STK setup.

It would be easier  if the "prefix" supported in the devclass could be more
than 8 characters....


> -----Original Message-----
> From: Dana Mitchell; [SMTP:Dana.Mitchell AT ING-DM DOT COM]
> Sent: Thursday, October 14, 1999 2:31 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: OS/390 ADSM server vs. Control-T
>
> Wanda,
>
> Thanks for the reply.  The way you described using device classes is how I
> am doing it now: I have one device class for onsite tapes and one class
> for
> offsite tapes.
>
>  The problems I am running into with this approach is that I also use the
> dataset prefix to influence STK to use either 9490 or 9840 drives.  Also
> we
> have situations where ADSM still thinks there are drives available based
> on
> the device class'es 'mount limit' not really being an accurate
> representation of actual hardware available.
>
> I am in the process of setting up a new server and would prefer to use one
> device class per device type (STK 9490 and 9840).  I was hoping that ADSM
> would be better behaved when the device class 'mount limit' reflects the
> actual number of drives available, allowing the ADSM server to preempt
> mounts based on process etc.
>
> I am curious, do most other OS/390 server installations use multiple
> device
> classes to utilize multiple dataset prefixes or one class per device type?
> What I would really like is to have pool name or some other identifier
> inserted in the dataset name then we could leave all the ADSM tapes with
> one HLQ....
>
>
> Dana