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.