> Let me reiterate that comment as I understand it, because I think it's
> possible to interpret the scope of what you mean by, "Core VM
function" in
> different ways - and it's a definition that we need to agree upon if
we're
> to have a fruitful discussion.
>
> In my view, the, "Core VM Function" that IBM has to buy into is the
> provision of an API in CP that allows the creation of an RDEV of any
kind
> ("take, "any" with a pinch of salt - hopefully it could be architeched
to
> do, "any" in principle but maybe limited for practical/business
reasons to
> (say) tape and DASD on its first outing) together with the supporting
API
> that allows communication between the created RDEV and a Service
Virtual
> Machine. Again, I cite *CCS as the conceptual model.
While I'd love to see something like this (and in fact, it's probably
necessary to do something like this to implement the remote tape server
item I mentioned), I've been told that I shouldn't prescribe how I want
IBM to do something, but to describe completely and accurately WHAT I
want them to do and let them figure out how they want to go about it,
preferably with them discussing it in the open and getting feedback on
their proposed implementation BEFORE they go off and code it.
I think I mean "core VM function" to be something I expect IBM to
deliver within CP without requiring additional user-space add-ons and
gewgaws. In the case of the CKD emulation, experience with the emulated
FBA disks indicates that the function is too complex to deploy in user
space and still actually be fast enough to be usable. Tape performance
(again judging by the tape server performance in the VSE remote tape
implementation) is less critical, and would be well served by a user
space implementation.
> Personally, I DO NOT see (and, if I read you correctly, neither do
you)
> the provision of the server code that drives this API as part of the
"Core
> VM Function" that IBM needs to buy into. While I can see that IBM
might
> well wish to take advantage of the API and deliver function that is
based
> on the API I am also certain that there are entrepreneurs across the
whole
> spectrum from Open-Sourcers to Proprietary OCOers who would gladly
grab
> the opportunity to provide all kinds of arcane and esoteric device
support
> base upon the aforesaid, "Core VM Function".
In the case of the emulated tape and disk devices, I do expect IBM to
provide usable implementations as part of the base product. If IBM
chooses to implement a general-purpose RDEV simulation intercept
interface as part of that, terrific -- I'll owe John and the CP wonks
much beer when I next see them. I'm less concerned about whether it's
completely generic if I can define my SCSI devices and have them work
where I'd lose the Z box entirely if I was forced to have FICON-attached
devices in order to have the system work at all.
Basically, I don't want to have to spend a lot of time having people
rewrite application and OS code to deal with the commonplace devices
that most shops already have in place and that reflect the current state
of practice in most data centers. I don't want to have to have the
argument with people who point out (and rightly so) that the mainframe
has to have these "special" devices because it can't take advantage of
pre-existing investments.
To do those two things, I need ECKD emulation and 34xx/35xx tape
emulation over SCSI to complete the EDEV emulation in VM. If it's
implemented by sending little clones of Alan out with every copy of CP
to play Maxwell's Daemon (separating the SCSI bits from the emulated
bits) with the translation process, so be it -- this wouldn't be
optimal, but let's get it working and then we'll optimize.
-- db
