> > Write applications that talk to CP basic services (like *RPI) in Linux, > > allowing one to do things like write authentication servers that talk to > > PAM and let CP do remote password authentication against AD or Kerberos. > > 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-) > > 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-) > > Implement APPC over IUCV to allow Linux to natively talk to SFS, so we > > can get a modern NFS server for CMS data. > > 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-) 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? It's not like you're encouraging CMS workload or enhancing SFS or anything like that ... > > Directly access VM spool data from Linux w/o going through I/O emulation > > with the virtual rdr/punch via *SPL. > > Also depends on 2-way SENDs. See above. Some assembly required in all cases above. At least we're past the "what will get accepted" stage and we can start fixing things like the 2way send thing noted above. ---------------------------------------------------------------------- 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
