Most excellent! ...and it's not even Friday! :-) On Tuesday, 03/27/2007 at 05:42 AST, David Boyes <[EMAIL PROTECTED]> wrote: > > OK, but don't forget you'll need to update the ACI modules in CP, too. > > 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.....??? > > > Write a interface for the existing CMS TCPIP clients to talk to a modern > > > IP stack in a Linux guest instead of the elderly Pascal one that's > > > shipped with VM TCPIP. > > That requires 2-way SENDs (SEND REPLY=YES) something I don't think AF_IUCV > > does. > > 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. > > APPC has a whole set of primitives not available in IUCV. Further, IUCV > > is a full duplex service, APPC is half duplex. Oh, and the lack of a > > documented interface might cause you some heartburn. :-) > > Half duplex can always be implemented over a full duplex medium (at least > according to Shannon, anyway) -- anything can be made dumber; it's smarter > that's hard. Also, APPC itself (or at least CPI-C) isn't that complicated, > really (after CMIP, *anything* is simple). If it can be done over SNA LUs, > it's certainly possible over IUCV -- wasn't that the Holy Grail when APPC > was going to take over the world versus this newfangled TCPIP thing? 8-) If you want to implement your own APPC-over-IUCV, sure, you could do that, but I think you're after APPC/VM interfaces in order to try to talk (e.g.) to SFS. 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. > The latter part would be a good thing to work on, though -- after all, what > really are you protecting by keeping SFS OCO and opaque these days? We've had this discussion before, but it's been a while. :-) There is no business value to IBM to spend money on opening up the APPC interface to SFS. Zero. It would cost us a lot of money (archeology, test, documentation) and give nothing back. It's less about intellectual property issues and more about wise investment. To top it all off, to use those interfaces you'd have to have a good working knowledge of the internal workings of the SFS server. IBM would have to give. What would IBM get in return? 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". Alan Altmark IBM ---------------------------------------------------------------------- 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
