I think we might be confusing several issues: 1) there are dedicated tapes
to an OS host that can only be shared between the users on that hosts using
software locks, 2) there are "shared tape" software mechanisms (tape
managers) that allow different OS to share tapes using software locks, and
3) there are hardware locks that assign a tape to an OS.
1 - software locks: How the OS allows its users to share a tape (i.e., a
software lock of some sort to allocate it to a user) once the tape is known
to the hosts (JCL, tso allocate, JES3, current mt(?)). The tape must be
assigned to the OS and only one user can use it at a time. This can be
extended with a global resource manager (GRS) or a software tape manager
that must be running on ALL hosts that can access the tapes.
2 - hardware locks: How different OS share a physcial drive through the
zSeries 3480/3490/3590 hardware assign/unassign ccw's (which is like
reserve/release on a disk volume). This is the mechanism for assigning a
drive with the "shared tape feature" to the OS. The ccw assign command asks
for the latch to be set on the hardware. If the device is available, not
other host can ask for the drive until it is unassigned; if the device is
assigned to another OS, then the ccw fails. This is at vary online or
attach ... assign time. No special tape management software need be
running.
(the hardware latch is similar to the reserve/release on dasd - as long as
a GRS type software manager is running on ALL hosts to communicate the
software locks (enqueues), then they can be virtually eliminated. As long
as one system is not running in the GRS ring, then reserve/release provides
protection for the life of the reserve. In MVS, today, with GRS, about the
only reserver still issued is for VTOC update on dasd - SYSVTOC enq).
The shared tape notion I'm talking about is the hardware lock type as
implemented on 3480/3490/3590 with the "shared" feature.
Anyway, good point, John. Using insmod, you can't add a tape. You've have
to delete the module and add any old tapes plus the new one as it is
written today.
One of the problems with the mt approach is that mt refers to the linux
/dev/node structure, mapping the device addresses in order of occurrence to
the /dev/*ibm* devices. And you would want to keep mt sufficiently generic
to work with other platforms. However, exterior to Linux, things are
handled by zSeries subchannel address and its insmod that associates the
zSeries device address with the Linux /dev/node concept.
So, what do you do? Modify tape390 module to handle the assign/unassign at
insmod/delmod time for the duration of the time the tape is needed, or take
ownership of mt to associate the device node with the zSeries subchannel
address, or provide some other mechanism that passes to tape390 which tapes
to assign and unassign?
And I understand the devfs as implemented in zSeries may be going away with
emphasis on UUID or VOLSER, neither of which apply to a zSeries tape. I
liked the /dev/dasd/address approach or /dev/tape/address approach for
zSeries (I was an early advocate of it in this forum), but I've stuck to
using software table lookups of /proc tables to make the association
between linux device node and zSeries device address since devfs is on its
way out. I appreciate Boeblingen's effort to put it in, but it does not
seem to be a long term solution.
The basic problem is that 2400/.../3480/3490/3590 tapes and ESCON
subchannels do not easily fit into the Linux notion of what devices ought
to do.
Regards, Jim
Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs
t/l 543-4021, 408-463-4021, [EMAIL PROTECTED]
*** Grace Happens ***
"Fargusson.Alan"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
tb.ca.gov> cc:
Sent by: Linux on Subject: Re: Linux390 + VM + Tape 3490
390 Port
<[EMAIL PROTECTED]
IST.EDU>
06/12/2003 04:57
PM
Please respond to
Linux on 390 Port
In batch it happens at the allocate, which I think is at start of job in
JES3, and start of step in JES2.
In TSO you do an allocate command, although I doubt many people do this.
Usually they write some JCL, and submit it.
I think an allocate command would be the best way to do this in Linux,
since it would be about the same as TSO. I think that the mt command is
not the right place to do this though.
-----Original Message-----
From: John Summerfield [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2003 4:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Linux390 + VM + Tape 3490
On Thu, 12 Jun 2003, Jim Sibley wrote:
> John,
>
> "insmod tape390 tape=xxx,xxx" - only list the tapes you want to use are
> specified. Obviously, putting them in the zipl.conf would lock them for
the
> duration of the IPL - not good for shared tapes.
Having loaded tape390 once, can you then load it again to get another
tape?
Having the mt command handle locking/releasing looks good to me, coupled
with the driver spitting the dummy if you try to do anything to an
unreserved tape except reserve it, or detach it.
"mt attach" sounds good to me too. On systems where attach/detach don't
apply, the operations should give no error or warning.
I can imagine this functionality applying in other environments (such as
vmware), and it seems to me ideal for the semantics to be the same.
> However you look at it, the solution requires the person using the
machine
> to take overt acton to obtain the drive and it must be locked until he is
> ready to release it. And it needs to take into account the fact that
other
> OS (non-linux) may also use the same drive.
I'm not keen on the idea of it being done at driver-load time.
> In this case, I think it behooves Linux to comply with the rules already
in
> place for shared tapes in an installation and follow the rules for the
> device as defined in the hardware specs.
When does it happen in OS/390?
--
Cheers
John.
Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
