I stand by the statement that the 3494 volume claiming is working as
designed.

I have a 3494 which for the last 6 years is used concurrently by:
multiple non-shared os/390 lpars
two disparate as/400 systems
multiple rs/6k servers
2 TSM systems

Yes, it is up to the 'host software' to maintain category limits.   In
every one of these 'host' environments, the 'host software' is a
combination of system or product software and user written code.  None of
these systems uses a pure search technique, there's always some user code
to help each system 'know' what its' valid tapes are.  In some it's just a
little harder to find the user code.  I further use a different volser
range for each platform to aid in more generic user code.  I don't see any
way that a robotic tape server able to hook up to a plethora of platforms
and software could be expected to isolate categories.  Also think of error
conditions.  There is no way in for the 3494 to move or recategorize
tapes.  Those commands must come from attached hosts.

OK, this is all a learning curve.  Been there did that.   But I think it
works.

my .02

Al Barth




"Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03/19/02 03:03 PM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: 3494 Volume Stealing


Actually, Nick we think there really is a bug.  I saw something similar
once
on Netbackup.  Essentially, the 3494 inventory count got off from the
actual
number of entries presented in the SEARCH=YES type CHECKIN equivalent in
NetBackup.  After we ran a full offline inventory of the library the
problem
went away for a week or two and would come back.  Eventually, we got a LM
code level that apparently fixed the corruption problem.  Have not seen it
for a long time.