> > You know, we *could* work together, design and produce a unified CP > system > > service for security access that presented itself as a IUCV-based system > > service, you could ship it as the default ACI modules, and you/me/all > the > > ISV ESM vendors would never have to do that extra IPL to update the ACI > > modules ever again... 8-) > > Except that IBM and CA (for example) have already invested in the ACI. We > would give that work away because.....???
Thinking out loud here: I think you're conflating the CP interface and how the data passed through the interface is generated/consumed here. I'm concerned with the CP interface here, which is currently a tedious, complex, hard-to-maintain piece of code that requires an enormous amount of bucketing around in the CP source to understand and maintain. I'm arguing that it makes no sense to have multiple people invent that wheel separately; a clearly defined interface point that can be used by multiple tools w/o modification benefits everyone, and directly impacts the development cost of your tools and your environment in a positive manner -- crudely put, it makes it cheaper to support the really valuable bits: the management tools, which is where the real money is. I certainly don't expect you to give away the code that consumes this interface. That's where there's a real competitive difference between something like RACF and VM:Secure. It strikes me that for IBM as the OS developer it's counterproductive to have everyone re-implement the same function in several incompatible ways. That's like telling someone that they have to make their own garden hoses because the iron casting industry can't converge on a standard fitting. It's time to start making standard fittings for these CP functions, and this would be one place that has needed a standard for several decades now. This is particularly visible as the number of people with CMS experience decreases -- the SES incantations necessary to get an ESM functioning in a maintainable manner are frankly beyond the VM newbie. Even with services hand-holding -- which costs money to administer and provide -- this is a knot that needs cutting. > > Working on it. Note the "write an interface" comment. 8-) > > Ah, I misread what you write. You're talking about a CMS-Linux socket > gateway/proxy. Consider vmsock in Linux. It has what you really want. If it allows the existing CMS clients to connect to Linux in place of VM TCPIP, then it's what I want. > While APPC/VM is just IUCV with APPC bit turned on during > CONNECT, it introduces a whole 'nother set of verbs that aren't surfaced > in sockets (e.g. SEND vs. SEND_AND_PREP_TO_RECEIVE). You'd have to add a > bunch of ioctls to handle the semantic differences. Again, I think you're confusing the transport with the presentation here. The bit transport is IUCV. The presentation (marshalling/demarshalling/flow control/etc) is the verbs you're talking about. Different layers in the stack, and they could be independently implemented. That's what we did in the Linux-SNA implementation for APPC over 802.2. But, point taken. It wouldn't be very pretty. > FTP and NFS access have been sufficient. I think Linux has a user-space > file system driver, doesn't it? It could easily drive AF_IUCV requests to > a CMS-based NFS-like server. So it isn't as fast as direct access. I > would be surprised if it wasn't "fast enough". OK. Better yet, just replace the whole SFS lashup with Linux-based Lustre or GPFS file stores and use the CMS NFS client to work with that. It might be interesting to see if the NFS client code could be adapted to use IUCV rather than TCP...hmm. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
