On OS/390 it depends on the tape management system. If you're running
DFSMSrmm, then just specify the REJECT ANYUSE(...) for the volser 'range'
that is non-OS/390 in your EDGRMMxx parmlib member. If you are using any of
the CA alternatives (TLMS, CA-1) then you will have to modify the sample
CBRUXENT OAM user exit to reject any non-OS/390 volsers. Make sure that this
exit is running on ALL systems/LPARS that share the 3494 library. The 3494
will notify each system/LPAR that is up and running. The exit may be on 2
out of 3, but that 3rd system could still accept the non-OS/390 tapes.
Speaking from experience on that one!

On the TSM server, we have a server script file that runs the checkin libv
command with the volrange option for only those TSM tape volsers.

As for OS/400....last time I looked there was no tape management support
available. Maybe OEM software venders..?

We share a 3494 between OS/390 and an AIX TSM server. Since moving to
DFSMSrmm, we haven't had a single occurance of the systems accepting the
others' tapes.

Bill Boyer
DSS, Inc.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Seay, Paul
Sent: Monday, November 26, 2001 8:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Sharing the 3494 with OS/390 and AS/400


In the case of OS/390 you are running the OAM task which has an exit that
may help.

Every system gets notification of a volume when it is inserted that is
registered to the 3494, even an open systems lmcpd system.  The OS/390
system is the only one that responds unfortunately.  It sets the category of
the tape based on whether the exit says to accept the tape or not.  For
OS/390 we implemented the exit and ignore tapes not for it by volser range.
Sorry, that does not help in TSM or AS/400.

What we desperately need from 3494 development is a lmcpd connection task
delivered for each platform that we can invoke a script from.  Then, we can
write the script in whatever tool we want.  That way you could dynamically
checkin under TSM and under an AS/400 do whatever it needs such as give the
tape a category via the mtlib command.

I believe that TSM will only label tapes that are in its categories already
or the FF00 category (insert), so you can make it skip the OS/390 tapes by
using the OAM exit.  I know TSM will not relabel that already has a valid
TSM label on it.  This is to prevent destroying tapes that have valid data.

If I could spend enough time to tinker around with C, I would write the code
for this task.  It is relatively simple.  And, essentially, you do not need
to run it but in one place because every host gets notified for all inserts.
And, by the way, the library represents the list of tapes in insert status
every time a host opens the interface to the library.



-----Original Message-----
From: Bazuin R. (Ronald) [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 26, 2001 7:55 AM
To: [EMAIL PROTECTED]
Subject: Sharing the 3494 with OS/390 and AS/400


Hi *SM-ers,

We are going to share an 3494 library with three hosts; TSM, OS/390 and
OS/400. Therefor we will use different labelcategories to ensure we don't
use eachothers tapes. But in TSM, i think, it is easy for us to label tapes
wich belongs to one of the other hosts. That is not wat you want, but it is
possible. Therefor I like to know if it is possible to set somewhere
something like an mask so we are not able to label those tapes, even when we
not use the 'volrange' option.

Thank in advance,

Ronald Bazuin
System Engineer
Amev I&P - Networks
(Amev is an member of the Fortis-group)
Netherlands



***************************DISCLAIMER***********************************
Deze e-mail is uitsluitend bestemd voor de geadresseerde(n).
Verstrekking aan en gebruik door anderen is niet toegestaan.
Fortis sluit iedere aansprakelijkheid uit die voortvloeit uit
electronische verzending.

This e-mail is intended exclusively for the addressee(s), and may
not be passed on to, or made available for use by any person
other than the addressee(s).
Fortis rules out any and every liability resulting from any
electronic transmission.
************************************************************************

Reply via email to