> > 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. > Or simply have CP do the talking to the authenticating servers > directly...no need to invoke another O/S simply to implement this > function....
If I thought that was doable in any reasonable amount of time, I might agree. At the moment, given the a) limited CMS/CP development staff and b) timeframe when I need that function, I'd rather Endicott concentrate on providing enablement to interface with already existing tools than try to reinvent the entire wheel. It doesn't make sense to reimplement something as complex as PAM or Kerberos, especially if you're going to have to commit parallel development resources to keep up with the literally ten to twenty times the amount of resources the open-source community can bring to bear on solving the problem, not the symptom, by interfacing with the existing Linux-based code. If we're told we need to pick our battles carefully in terms of where we ask IBM to put development resources, this is one where it's a no brainer -- spend the resources on making it possible to adapt the existing implementations efficiently and securely, *not* reinventing the wheel. > > Write terminal multiplexing services that can map SSH connections to > > linemode virtual machine consoles so that we can finally do a decent SSH > > server for CMS. > Or simply have an SSH server for CMS.....:-) If the problem becomes mapping the Linux pty interface library to *CCS sessions, then we get that SSH function much more quickly, and it becomes more likely that we will continue to have that function at a current and useful level. > > 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. > Or simply have IBM upgrade the native VM TCP/IP stack to support the > needed features...no need ion have yet another O/S installed on VM to do > such things.... See above. There are very few ways that the VM TCP stack is unique, and most of those are artifacts of its genesis. It's getting harder and harder to justify that uniqueness as the CMS investment continues to decrease/evaporate. Again, use the development dollars to enable, not try to outimplement the open-source community. You can't win. > > Directly access VM spool data from Linux w/o going through I/O emulation > > with the virtual rdr/punch via *SPL. > To solve what existing problem? Why does Linux need to access the CP > spool, other than as a producer of spool data (prt, pun)? To implement transformation services for other guests (think VSE or TPF) that are spool-enabled. To provide printing and data transport services that benefit from implied queueing. To interoperate with existing systems. > Yes, I am playing devil's advocate here, but I am concerned that we are > letting the fact that Linux now runs on z/VM color our approaches to > solving these types of problems....not every problem with z/VM can or > should be solved by doing something on Linux. True. On the other hand, rewriting a working application -- especially something complex like authentication or encryption code -- for intellectual purity reasons is just wasted effort, especially if the application can be incrementally improved by contributing adaptation code. Look at the #ifdefs in the OpenSSH source tree to enable support for VMS if you want to see an example of successful adaptation. > this is especially true > with adding new function to the VM TCP/IP stack....almost all of the > clients I work with want to see IBM add new functionality to the VM > stack (e.g., better support for IPv6) by simply updating the existing > TCP/IP code; they do not want to have to purchase and install another > o/s (here Linux) simply to get some functions that should be provided in > the base. That's a question of policy, not problem solving methodology -- note key word in your statement: "purchase". If IBM were to elect to support a non-commercial Linux distribution for embedded function use -- leave the WAS and DB/2 and other commercial workloads to the commercial distributions -- then this becomes a non-issue. Wrt to the TCP stack, I don't think anyone really cares HOW the function is done if it "just works" and they can get their work done. (One could make a good argument that the existing TCP stack IS a separate microkernel OS -- it just happens to be supplied with VM. The TCPIP stack virtual machine is pretty much a black box from the outside once that TCPIP module starts up.) The above policy issue is a political, not a technical problem. ---------------------------------------------------------------------- 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
