Lucy,
sounds like you may already have this in hand, but for info...
CBRUXENT works in conjunction with the REJECT statements in the DFRMM
parameters (EDGRMMxx), but I don't know how TMS achieves the same
functionality.
We have had issues in the past where tapes appeared in the TCDB for the
wrong systems, but using the date that the entries appeared in the TCDB we
were able to detect the 2 causes for this :
1) Ops were entering cartridges just at the time that an LPAR was being
shutdown for an IPL. DFRMM was inactive and Automation was giving an
incorrect response to the message that DFRMM was inactive. Changing
automation fixed this.
2) Duplicate entries in DEVSUPxx for 2 Plexes. Changing DEVSUPxx to ensure
that the entries were unique for each Plex resolved this.
DFRMM did not have the tapes defined, nor were they eligible in the
scratch pool range, so in both cases the tapes weren't usable but 'lost'
in the 3494.
The most recent 'funny' we had only a few weeks ago was where CBRUXENT was
not being driven at insert time, but the effect of this was different to
what you descrive in that cartridges were stuck in insert. This was caused
by entering cartridges when the drives were offline to all LPARs and re-
enabling the exit resolved it, but even cartridges entered after the
drives were subsequently brought online (but before the exits were re-
enabled) were still not causing the exit to be driven.
We now have 3494s shared by up to 4 z/os Sysplexes and AIX and the TCDB on
each only has the tapes owned by that Sysplex which I think is what you
are aiming to see.
Regards,
Steve O.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
