Re: AF_IUCV support
Hi, On Wed, 28 Mar 2007 22:32:23 -0400 David Boyes said: >> So how about if you make the calls to the ACI stubs nice CP exits so >> that we can dynamically load the modules that RACF (or someone else) >> supplies. > For what its worth, our home-brew SECURE system is implemented as a CPXLOADable IUCV System Service. The dynamic IUCV System Service code is a local CP modification, but wouldn't be needed if *RPI spoke to CP exits. In any event, CPXLOADable security code works. Well. Cheers, Arty -- 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
Re: AF_IUCV support
On Thursday, 03/29/2007 at 11:21 AST, Melissa Howland/Endicott/[EMAIL PROTECTED] wrote: > So one should be very cautious about replacing the sockets (or other PFS) > BPX1 routines in the BFS on CMS. For example, if you replace BPX1SOC, you > have just ripped all of the sockets support out from under your C servers > running on CMS (that is, you can't replace just one addressing family > easilyBPX1SOC is all of your sockets addressing families). Also, the > sockets PFS shares some BPX routines with the file PFS, so if you replace > BPX1RED (read), you've just ripped out your read() function for files, too. > > So please consider this option with great caution. Aye, there be dragons here. Or worse. "Abandon hope all ye who here enter" pops to mind. It is an effort not to be undertaken lightly as the Law of Unintended Consquences (previously known as "unpredictable results may occur") definitely applies. If you start ripping out (replacing) one CSL routine you will undboutedly find yourself replacing others: Open, Close, Read, Write are all related, expecting to find the same infrastructure in the background. IBM spent a lot of time & money writing those CSL routines, so it is only fair that if it was hard for us that it be hard for the next person, eh? :-) Alan Altmark z/VM Development IBM Endicott -- 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
Re: AF_IUCV support
Alan wrote: >>You can already do that for some of the clients/servers. The C-based >>programs all call LE sockets. LE calls BPX1SOC CSL routine. Feel free to >>write your own replacement that implements the transport of your choice. CSL routines are usually provided for one (or both) of 2 reasons: 1) to make them easily replaceable or 2) to make them easily callable from many languages. So while the fact that they are CSL routines makes the BPX1 interfaces replaceable in a sense, that is not why they are CSL routines and, therefore, they are not really written or documented with the intention that they be replaceable. They are CSL routines to allow them to be easily called from several languages. So one should be very cautious about replacing the sockets (or other PFS) BPX1 routines in the BFS on CMS. For example, if you replace BPX1SOC, you have just ripped all of the sockets support out from under your C servers running on CMS (that is, you can't replace just one addressing family easilyBPX1SOC is all of your sockets addressing families). Also, the sockets PFS shares some BPX routines with the file PFS, so if you replace BPX1RED (read), you've just ripped out your read() function for files, too. So please consider this option with great caution. (Oh, did I mention that I also own/support the CMS sockets support in my "spare time"? :) ) Melissa Howland z/VM and Linux on z/VM Development IBM Corporation Endicott, NY 13760 (607)429-3303, (from within IBM T/L 620-3303) Fax: (607)429-4192 (T/L 620-4192) -- 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
Re: AF_IUCV support
<[EMAIL PROTECTED]> wrote: > Now, for the rest of us in the dark, what we we do with that function? Alan wrote: >>Connect to *MSG or other system services. Or even CMS apps or other Linux >>servers without using IP. ISFC Collections (VM clusters) and distributed >>IUCV anyone? The current version of the AF_IUCV support available on developerWorks allows for local CONNECT's only (i.e., to guests on the same CP)...(this is consistent with the AF_IUCV support in CMS). So don't say "distributed IUCV" yet. Since this is my first append here, I should probably introduce myself :) . Many of you know me from my many years as a CMS developer (much of which my last name was Carlson, in case you're wondering :) ) I'm now leading a team of developers in Endicott that is working with the Linux team in Boeblingen, focusing on z/VM exploitation in Linux (we would be the "colleagues" that Alan referred to). Melissa Howland z/VM and Linux for S/390 Development IBM Endicott -- 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
Re: AF_IUCV support
> > And you're revamping an awful lot of CP internals at the moment to > > finish the 64-bit enablement. It's worth bringing up the idea at least. > > By all means. But even in a 64-bit world, much of CP (including the ACI) > runs in a 31-bit execution space with the flexiblity to map any page into > that 31-bit space. The parts of CP that manage the 31-bit space are, of > course, 64-bit, as are those that need to access possibly more than 2GB of > data are also 64-bit enabled. I was under the impression that that mapping approach was a temporary rest stop on the evolution, though. If there is still major restructuring to be done, then it'd be worth looking into some of the other general interface stuff (cf how SPXTAPE works, etc) at that point, or at least start poking at the concept. Using a "service access point" model would keep the services available for CMS but also make them easier to access in a pure hosting model. -- 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
Re: AF_IUCV support
>>> On Thu, Mar 29, 2007 at 12:35 AM, in message <[EMAIL PROTECTED]>, Marcy Cortes <[EMAIL PROTECTED]> wrote: -snip- > I think I started this whole long thread by asking what for? My > question is was more along the lines what would a *finanical services > firm* like mine or Rick's (who got so excited :) would do with this. You have to understand Rick. It's not that he works for a financial services firm. He's just a real geek when it comes to things that are technically cool. Which is one of the reasons I love him. :) Mark Post -- 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
Re: AF_IUCV support
On Mar 28, 2007, at 11:35 PM, Marcy Cortes wrote: I shouldn't complain... pam-modules are giving me more headaches than VM stuff ever will (the latest being pam_tally.so not liking large uid's) O_o A light bulb just went on in my head about something weird I was seeing a couple weeks ago. Thank you! Adam -- 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
Re: AF_IUCV support
Alan wrote: > It > is *not*, in fact, beyond the newbie because we have newbies who are > implementing z/VM for the first time and successfully adding ESMs of their > choice on those systems. I can tell you that my newbies (formerly z/OS guys) that I have working for me did not find it all that easy to add one to the current VM we are installing. And I wasn't all that able to answer their questions even having 20 years of VM experience but not that much ESM stuff (someone else always did it :).. Luckily Kitty and Fran at CA are great hand holders and know their stuff... But it sure could be made easier for the new folks. I shouldn't complain... pam-modules are giving me more headaches than VM stuff ever will (the latest being pam_tally.so not liking large uid's) I think I started this whole long thread by asking what for? My question is was more along the lines what would a *finanical services firm* like mine or Rick's (who got so excited :) would do with this. Here, anyway, it's more about what our vendors can provide to us or what we can do easily with rexx/pipelines/etc to enhance our productivity. We're too busy building/maintaining servers and answering audit/security to think of cool things like interfacing to VM's spool :) Marcy Cortes -- 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
Re: AF_IUCV support
On Wednesday, 03/28/2007 at 10:28 AST, David Boyes <[EMAIL PROTECTED]> wrote: > OK, OK -- Uncle. Good, because *my* arm was getting tired. :-) > And you're revamping an awful lot of CP internals at the moment to > finish the 64-bit enablement. It's worth bringing up the idea at least. By all means. But even in a 64-bit world, much of CP (including the ACI) runs in a 31-bit execution space with the flexiblity to map any page into that 31-bit space. The parts of CP that manage the 31-bit space are, of course, 64-bit, as are those that need to access possibly more than 2GB of data are also 64-bit enabled. > What's clear is that people can follow cookbook instructions. I would > seriously question if they could actually tell you what those steps do, > or understand how to fix it if it breaks. But, maybe that's unrealistic. > I'd certainly prefer to eliminate the incantations if they're avoidable. We are on the same wavelength here. ESM enablement is too complex at the moment. I have ideas on how to address it buried in a mason jar in a secret location in the back yard, but it all amounts to reducing the number of steps to a bare minimum and bringing sanity to those that remain. Alan Altmark z/VM Development IBM Endicott -- 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
Re: AF_IUCV support
> So how about if you make the calls to the ACI stubs nice CP exits so > that we can dynamically load the modules that RACF (or someone else) > supplies. This would be a pretty good start. I think one can now write exit code in C, right? That might be the way to do the "glue" bits to permit your extra optimizations. -- 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
Re: AF_IUCV support
> To have a common CP-resident ESM handler is certainly possible, but it > would change the CP ACI architecture, moving the interface to *RPI. That > is, IMO, too restrictive and prevents useful optimizations. OK, OK -- Uncle. I don't know if I agree with whether it would be too restrictive; there are certainly known working examples of similar architectures in other operating systems (Multics and TOPS-20, for example), and most of the other tasks you mentioned I can conceive of ways to do in user space, but we'll wait and see. > If we were starting anew, I might agree, but we're coming up on 30 years > and it is what it is. The money was spent. The milk was spilt. And the > water is under the bridge. And you're revamping an awful lot of CP internals at the moment to finish the 64-bit enablement. It's worth bringing up the idea at least. > It has a standard, David. It always has. You just don't like the > standard. Well, discontent has always been the mother of invention...8-) > It > is *not*, in fact, beyond the newbie because we have newbies who are > implementing z/VM for the first time and successfully adding ESMs of their > choice on those systems. What's clear is that people can follow cookbook instructions. I would seriously question if they could actually tell you what those steps do, or understand how to fix it if it breaks. But, maybe that's unrealistic. I'd certainly prefer to eliminate the incantations if they're avoidable. > > If it allows the existing CMS clients to connect to Linux in place of VM > > TCPIP, then it's what I want. > You can already do that for some of the clients/servers. The C-based > programs all call LE sockets. LE calls BPX1SOC CSL routine. Feel free to > write your own replacement that implements the transport of your choice. Yes. Found that, and it wasn't all that hard. Ugly, but not that hard. 8-) > As far as the Pascal programs go, I don't think the VMCF interface will > survive into the 22nd century. ;-) Well, that's a relief. -- 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
Re: AF_IUCV support
On Thursday, 03/29/2007 at 12:03 ZE2, Rob van der Heij <[EMAIL PROTECTED]> wrote: > So how about if you make the calls to the ACI stubs nice CP exits so > that we can dynamically load the modules that RACF (or someone else) > supplies. We could still have the *RPI as part of CP if an entry point > is associated with it to handle defined call-back from CP. The idea to enable ESM installation via CP exits is already under consideration. Alan Altmark z/VM Development IBM Endicott -- 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
Re: AF_IUCV support
On 3/28/07, Alan Altmark <[EMAIL PROTECTED]> wrote: I should point out that the *RPI service, while defined by CP, is really internal to the ACI. The internal calls CP makes to the ACI don't really care what happens to the data. It doesn't even have to communicate with the *RPI system service. In fact, without changes to the ACI, the *RPI So how about if you make the calls to the ACI stubs nice CP exits so that we can dynamically load the modules that RACF (or someone else) supplies. We could still have the *RPI as part of CP if an entry point is associated with it to handle defined call-back from CP. Rob -- 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
Re: AF_IUCV support
On Mar 28, 2007, at 4:20 PM, Alan Altmark wrote: (imagine how SETRACF INACTIVE works) Dude! I'm trying to *eat* here! Adam -- 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
Re: AF_IUCV support
On Wednesday, 03/28/2007 at 04:17 AST, David Boyes <[EMAIL PROTECTED]> wrote: > 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 should point out that the *RPI service, while defined by CP, is really internal to the ACI. The internal calls CP makes to the ACI don't really care what happens to the data. It doesn't even have to communicate with the *RPI system service. In fact, without changes to the ACI, the *RPI service is moribund. Nothing will ever reach it. Further, CP will immediately sever an attempt to connect to *RPI. Why? Because vanilla CP doesn't know how to talk to it. He just provides a data pipe. In recognition of this fact, all of the CP calls to the vanilla ACI will answer "DEFER". What all this means is that the design of the ACI is wide open. If you want to provide a set of ACI modules that work with your Linux guest, that's great. The data flows across *RPI do not necessarily have to match the ACI flows into and out of HCPRPIRA. It is the latter that are architected, not the former. You can even flow ASCII. :-) It is true that the Big Four ESMs all use a set of core services surrounding *RPI. The reason for that system service name is because it is tied by CP (outside of the ACI) to the ACI. The Big Four each have a set of CP-resident services, adding local caches, private notifications (imagine how SETRACF INACTIVE works), whatever their hearts desire. These services provide value, particularly cache management. So, the server that connects to *RPI is just one half of the equation. The CP-resident code is the gateway/translator between the proprietary ESM and the rest of CP. RACF, for example, can go into failsoft mode where it will happily annoy the operator with "Allow this?" messages to handle situations where the server is down. To have a common CP-resident ESM handler is certainly possible, but it would change the CP ACI architecture, moving the interface to *RPI. That is, IMO, too restrictive and prevents useful optimizations. > 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. If we were starting anew, I might agree, but we're coming up on 30 years and it is what it is. The money was spent. The milk was spilt. And the water is under the bridge. The ante for a z/VM ESM includes a CP piece and a server. > 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. It has a standard, David. It always has. You just don't like the standard. > 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. You moved the cheese are talking now about usability, not architecture. It is *not*, in fact, beyond the newbie because we have newbies who are implementing z/VM for the first time and successfully adding ESMs of their choice on those systems. But I wholeheartedly agree that the entire process could be made easier. I know that if I had it all to do over again, I'd definitely do some of it differently. > If it allows the existing CMS clients to connect to Linux in place of VM > TCPIP, then it's what I want. You can already do that for some of the clients/servers. The C-based programs all call LE sockets. LE calls BPX1SOC CSL routine. Feel free to write your own replacement that implements the transport of your choice. As far as the Pascal programs go, I don't think the VMCF interface will survive into the 22nd century. ;-) > 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. Remember that TCP *is* IUCV with metadata. Add TYPE=2WAY to AF_I
Re: AF_IUCV support
> > 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
Re: AF_IUCV support
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
Re: AF_IUCV support
> > 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 problemsnot 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 stackalmost 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: INF
Re: AF_IUCV support
>>> On Tue, Mar 27, 2007 at 8:18 PM, in message <[EMAIL PROTECTED]>, Dave Jones <[EMAIL PROTECTED]> wrote: -snip- > 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 problemsnot every problem with z/VM can or > should be solved by doing something on Linux. this is especially true > with adding new function to the VM TCP/IP stackalmost 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. -snip- Based on conversations I've had with various IBMers, I suspect your clients are going to be increasingly disappointed. Certain parts of IBM have discovered that for the various mainframe OSes they maintain, it's easier, cheaper, faster to develop something they want for more than one of their OSes _once_, on Linux, and then write OS-specific interfaces to it. Mark Post -- 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
Re: AF_IUCV support
Hi, everybody... David Boyes wrote: Now, for the rest of us in the dark, what we we do with that function? Marcy Cortes Some examples: 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 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.:-) 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 Implement APPC over IUCV to allow Linux to natively talk to SFS, so we can get a modern NFS server for CMS data. 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)? The list is pretty much open-ended. Now that someone has written a IUCV interface that the PTBs are willing to accept, we can get on with better VM integration. 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 problemsnot every problem with z/VM can or should be solved by doing something on Linux. this is especially true with adding new function to the VM TCP/IP stackalmost 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. Have a good one DJ -- 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 -- 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
Re: AF_IUCV support
> -Original Message- > From: Dave Jones [mailto:[EMAIL PROTECTED] > > Since IUCV is now "built-in" to both CMS and Linux, you could > develop cloning applications that used an IUCV connection to > set up cloned Linux guests IP and other parameters. > > Or have CMS and Linux applications share data and communicate > using IUCV; much simpler and faster than having to do an IP > network setup. I'm curious why you would prefer this solution for cloning over, say, not keeping IP network information on the Linux image at all and using DHCP with static leases, instead. ok r. -- 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
Re: AF_IUCV support
This appears to be reversed in 5.3. David Boyes wrote: Does that include the system management API stuff? I think that's still Sun RPC based. -- 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 -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007 -- 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
Re: AF_IUCV support
> > 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
Re: AF_IUCV support
Alan, et al, Could this be used for high-availability clustering and/or load balancing? It would be nice to use our ISFC (Distributed IUCV) CTC infrastructure to carry the heartbeat monitoring traffic etc. Potentially much simpler than defining CTC links between a bunch of penguins. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com “The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt” - Bertrand Russell
Re: AF_IUCV support
On Tuesday, 03/27/2007 at 04:51 AST, David Boyes <[EMAIL PROTECTED]> wrote: > 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. > 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. > 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. :-) > 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. Alan Altmark z/VM Development IBM Endicott -- 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
Re: AF_IUCV support
> Now all we need is for somebody to write up an IUCV function package for > ooRexx or Regina on Linux.:-) Not needed. Use the support for sockets, and supply AF_IUCV for the protocol family. You'll need to experiment with the hostent structure a bit, but it should work. I still like the streams model we developed better, but c'est la vie. This one is somebody else's problem to maintain...8-) -- 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
Re: AF_IUCV support
> Does that include the system management API stuff? I think that's still Sun RPC based. -- 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
Re: AF_IUCV support
> Now, for the rest of us in the dark, what we we do with that function? > Marcy Cortes Some examples: 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. 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. 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. Implement APPC over IUCV to allow Linux to natively talk to SFS, so we can get a modern NFS server for CMS data. Directly access VM spool data from Linux w/o going through I/O emulation with the virtual rdr/punch via *SPL. The list is pretty much open-ended. Now that someone has written a IUCV interface that the PTBs are willing to accept, we can get on with better VM integration. -- 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
Re: AF_IUCV support
On Tuesday, 03/27/2007 at 01:21 CST, Mark Post <[EMAIL PROTECTED]> wrote: > >>> On Tue, Mar 27, 2007 at 3:03 PM, in message > <[EMAIL PROTECTED]>, Alan > Altmark <[EMAIL PROTECTED]> wrote: > > On Tuesday, 03/27/2007 at 01:48 EST, Marcy Cortes > > <[EMAIL PROTECTED]> wrote: > >> Now, for the rest of us in the dark, what we we do with that function? > > > > Connect to *MSG or other system services. Or even CMS apps or other Linux > > servers without using IP. ISFC Collections (VM clusters) and distributed > > IUCV anyone? > > Does that include the system management API stuff? It includes the z/VM 5.3 System Management APIs, yes. The prior versions of SMAPI are TCP/IP (RPC) only. It is not, however, suitable for connecting to the VM TCP/IP stack a la CMS. For that, z/VM 5.3 includes an open-sourced AF_INET socket redirector for Linux, aka "vmsock". Alan Altmark z/VM Development IBM Endicott -- 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
Re: AF_IUCV support
You could also transfer data between VSE and Linux without having an IP stack in VSE. David Dave Jones wrote: Since IUCV is now "built-in" to both CMS and Linux, you could develop cloning applications that used an IUCV connection to set up cloned Linux guests IP and other parameters. Or have CMS and Linux applications share data and communicate using IUCV; much simpler and faster than having to do an IP network setup. Now all we need is for somebody to write up an IUCV function package for ooRexx or Regina on Linux.:-) DJ Marcy Cortes wrote: Now, for the rest of us in the dark, what we we do with that function? Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Richard Troth Sent: Tuesday, March 27, 2007 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] AF_IUCV support Alan Altmark said: So, I was walking down the street and looked in the storefront window. There, staring back at me, was AF_IUCV support in Linux. Thanks to my colleagues for building this support! As they say in the neck-o-the-woods I come from: YEEE-HAAA!!! -- R; -- 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 -- 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 -- 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
Re: AF_IUCV support
Since IUCV is now "built-in" to both CMS and Linux, you could develop cloning applications that used an IUCV connection to set up cloned Linux guests IP and other parameters. Or have CMS and Linux applications share data and communicate using IUCV; much simpler and faster than having to do an IP network setup. Now all we need is for somebody to write up an IUCV function package for ooRexx or Regina on Linux.:-) DJ Marcy Cortes wrote: Now, for the rest of us in the dark, what we we do with that function? Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Richard Troth Sent: Tuesday, March 27, 2007 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] AF_IUCV support Alan Altmark said: So, I was walking down the street and looked in the storefront window. There, staring back at me, was AF_IUCV support in Linux. Thanks to my colleagues for building this support! As they say in the neck-o-the-woods I come from: YEEE-HAAA!!! -- R; -- 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 -- 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
Re: AF_IUCV support
>>> On Tue, Mar 27, 2007 at 3:03 PM, in message <[EMAIL PROTECTED]>, Alan Altmark <[EMAIL PROTECTED]> wrote: > On Tuesday, 03/27/2007 at 01:48 EST, Marcy Cortes > <[EMAIL PROTECTED]> wrote: >> Now, for the rest of us in the dark, what we we do with that function? > > Connect to *MSG or other system services. Or even CMS apps or other Linux > servers without using IP. ISFC Collections (VM clusters) and distributed > IUCV anyone? Does that include the system management API stuff? Mark Post -- 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
Re: AF_IUCV support
Found it: http://www2.marist.edu/htbin/wlvtype?LINUX-VM.64920 back on 02/28. Mark Post >>> Mark Post 03/27/07 3:09 PM >>> >>> On Tue, Mar 27, 2007 at 2:08 PM, in message <[EMAIL PROTECTED]>, Alan Altmark <[EMAIL PROTECTED]> wrote: > So, I was walking down the street and looked in the storefront window. > There, staring back at me, was AF_IUCV support in Linux. Thanks to my > colleagues for building this support! Which storefront would this be; developerWorks? Mark Post -- 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
Re: AF_IUCV support
>>> On Tue, Mar 27, 2007 at 2:08 PM, in message <[EMAIL PROTECTED]>, Alan Altmark <[EMAIL PROTECTED]> wrote: > So, I was walking down the street and looked in the storefront window. > There, staring back at me, was AF_IUCV support in Linux. Thanks to my > colleagues for building this support! Which storefront would this be; developerWorks? Mark Post -- 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
Re: AF_IUCV support
On Tuesday, 03/27/2007 at 01:48 EST, Marcy Cortes <[EMAIL PROTECTED]> wrote: > Now, for the rest of us in the dark, what we we do with that function? Connect to *MSG or other system services. Or even CMS apps or other Linux servers without using IP. ISFC Collections (VM clusters) and distributed IUCV anyone? Alan Altmark z/VM Development IBM Endicott -- 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
Re: AF_IUCV support
Now, for the rest of us in the dark, what we we do with that function? Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Richard Troth Sent: Tuesday, March 27, 2007 11:22 AM To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] AF_IUCV support Alan Altmark said: > So, I was walking down the street and looked in the storefront window. > There, staring back at me, was AF_IUCV support in Linux. Thanks to my > colleagues for building this support! As they say in the neck-o-the-woods I come from: YEEE-HAAA!!! -- R; -- 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
Re: AF_IUCV support
Alan Altmark said: > So, I was walking down the street and looked in the storefront window. > There, staring back at me, was AF_IUCV support in Linux. Thanks to my > colleagues for building this support! As they say in the neck-o-the-woods I come from: YEEE-HAAA!!! -- R; -- 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
Re: AF_IUCV support
>>> On Tue, Mar 27, 2007 at 2:12 PM, in message <[EMAIL PROTECTED]>, Rich Smrcina <[EMAIL PROTECTED]> wrote: > I'm not sure if I want to know where you were shopping... :) Sounds like Second Life to me. Mark Post -- 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
Re: AF_IUCV support
I'm not sure if I want to know where you were shopping... :) Alan Altmark wrote: So, I was walking down the street and looked in the storefront window. There, staring back at me, was AF_IUCV support in Linux. Thanks to my colleagues for building this support! But contrary to the configuration information in the book, please use IUCV ANY sparingly. I would rather my Linux guests be restricted in their connectivity options. :-) Regards, Alan Alan Altmark Sr. Software Engineer IBM z/VM Development -- 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 -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007 -- 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
