Depends on what you mean by "error"...what's the message, and what tape
management system software is in use on z/OS?
With a 3494 attached to z/OS, any time a cart goes through the door, an I/O
interrupt is sent to each successive z/OS lpar. (In an order you can't
control).
That interrupt causes the invocation of the tape acceptance exit (which is
provided by your z/OS tape management software, but has to be customized a
bit locally). The exit is supposed to interrogate the tape management
system data base, and send back a return code.
I don't remember exactly what the return codes are, but the end result is
either
1) Yes, that is my tape - assign my category code to it, or
2) No, that is not my tape, give the next LPAR a crack at it.
If no LPAR accepts that tape, it remains in INSERT status (the "up for
grabs" category code). So it's still available for a CHECKIN by TSM.
So every time a 3592 goes through the door, you'll see a message on the z/OS
console to the effect that the tape exit has rejected that tape, on every
z/OS lpar.
(Likewise, when you put 3590's in through the door, you'll see a message on
the z/OS console to the effect that the tape exit on 1 LPAR has claimed the
tape, and the tape exit on the other LPAR's has rejected the tape.)
This is "working as designed".
If you are seeing something different, there may be something wrong with
your tape exit.
Your CE may have talked to someone who thinks you have a "new" 3494
replacement, which is the 3953. (The 3953 is a hybrid beast somewhat like
the mythical griffin, that had a the body of a lion and the head of an
eagle.)
It consists of a TS3500 (the library formerly known as 3584) with ALMS that
works on the open systems side like -- you guessed it, a 3584. Then the
3953 part is a rack full of equipment that emulates a 3494 and its library
manager, including the Escon controller. The 3593 talks to z/OS as a 3494,
but uses the robotics of the TS3500. In that configuration, yes the open
systems have to have their own partition, created with ALMS in the TS3500.
In that configuraiton, the TS3500/3584 side and the 3953 side are pretty
much ignorant of each other - you even still have 2 separate web
interfaces.
But: there are no "open systems partitions" on an real (old) 3494 - just
category codes.
W
On Tue, Feb 17, 2009 at 3:15 PM, Nick Laflamme <dplaflamme AT gmail DOT com>
wrote:
> We're seeing repeated errors on our z/OS console, too, from the tape
> acceptance exit (my wording; take it with a grain of salt), for each 3592
> volume we have checked into the ATL, too. For the moment, we've removed the
> 3592 volumes until we're ready to have TSM ask the 3494 for "its" tapes.
>
> Our IBM CE happened to be here today, so the z/OS guy asked the CE about
> the
> error message. Said CE placed a call or two and came back with a new theory
> that contradicts what seems to be the concensus here: according to him, we
> need to have an "OpenSys" partition besides the non-VTL partition and the
> VTL partition.
>
> Does this agree with anyone's experience, or did the CE perhaps reach
> someone who's more used to dealing with 3584s?
>
> Thanks again,
> Nick
>
> On Tue, Feb 17, 2009 at 12:25 PM, Thomas Denier <
> Thomas.Denier AT jeffersonhospital DOT org> wrote:
>
> > We have a 3494 shared between a VTS used by z/OS, a group of
> > native tape drives used by z/OS, and a TSM server with two types
> > of tape drives. Our experience matches that of other respondants;
> > a new 'partition' is really just a pair of previously unused
> > category numbers.
> >
> > We did have a little trouble with z/OS when we first migrated
> > TSM from z/OS to its current host (mainframe Linux). The z/OS
> > system has an exit routine that is called when a volume is
> > inserted into the 3494. The return code from the exit tells
> > z/OS whether to assign one of its own category codes to the
> > volume. We had to update the exit routine to get z/OS to stop
> > grabbing TSM volumes before TSM tried to check them in.
> >
>
|
