Good Morning Everybody. My point in asking about the source is that I'd really like to see pipes ported to other platform. It's far to important of an idea to let it die a slow death by being tied up with VM.
I wish I could do the port myself, and maybe if I saw the source I could hack out something. But, in reality I don't really have the skills needed. All I can do is promote and encourage others. VM is a great platform, but market forces will affect the business decisions need to be made. It's unfortunate, but reality. I can see the announcement tomorrow. IBM buys EMC to get VMWare so they can develop VM. Wouldn't make any sense, but often business decisions don't. enough of this.. My point... The crime here is that we shouldn't sit idle and let PIPE's life be dependent on VM. True it's current incarnage it's very tightly tied to the 390 platform, but I don't believe that it must be. Pipes is so much more than another case of an IBM wasted asset. To me, it really is a fundemental change in the programming paradigm that offers a very valuable alternative to our standard procedural approach. When a vm'r years ago I converted dozens of programs to pipes, cutting out thousands of lines of rexx and increasing performance and flexibility. It really is something special. My day job is as a data warehouse architect, and I see all of the commercial products implementing a stage like concept, but struggling continuously with the dataflow programming and the overhead of today's C based implementations. I'd give away my all of the my $200k+ etl products in a heartbeat if I could use PIPES. John has been insightful, smart, and dilligent enough to bring an old idea (of co-routines) to real, practicle life. But, it's such a shame to see it languishing locked inside bueauracrtic hell. I know that previous attempts to port have had mixed success, primarily due to a reliance on C and it's stack architecture limitations. Others have recognized the C stack limitations and worked dilligently over the last 5 years to overcome this by implementing a Python core that relies on co-routines (stackless.com) . Many are now baseing commercial products on the platform with stunning results - 10k fold higher throughput as compared to multi-threaded designs. But alas, it's still Python, an oo language and not a utility like pipes. But I believe stackless does provide the essential ingrediant needed for a successful PIPE port. Coroutines. Tasklets, greenlets, or whatever they call them over there. It's still a call/suspend architecture. What I'd like to see IBM do more than anything turn the source over to the open source foundation. So that others can take John's amazing creation and breath new life into it. So that I and millions others can be far more effective at solving our problems today and tomorrow. Cheers! Doug Little [EMAIL PROTECTED] Elgin, IL ----- Original Message ---- From: Rob van der Heij <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, January 21, 2008 4:21:48 PM Subject: Re: Source On Jan 21, 2008 5:55 PM, Marty Zimelis <[EMAIL PROTECTED]> wrote: > Shimon, > You are, of course, correct. However, the potential big resource > consumer is not the installation but the ongoing support. No one in > Endicott is sufficiently fluent in the internals of modern plumbing to > support it and bringing even a few people up to speed is, I believe, beyond > what upper management is willing to devote to Pipelines without, as I said > earlier, a compelling business case for doing so. Nobody will expect my view on this to be unbiased, so I will not even try ;-) There's a wealth of new cool stuff in the current version of CMS Pipelines. I tried to show some of that in my presentation last year: http://rvdheij.nl/Presentations/2007-V65.pdf If folks in Endicott would only exploit half of that, they already had their business case... This has nothing to do with whether CMS is strategic or not. One of the reasons z/VM works as a hypervisor is because it's highly programmable through CMS virtual machines (and because we have performance data). Obviously a 10-year old product does not address the new requirements we have today. But a lot of the new function in Pipes has been added because of these new requirements. There's even CMS Pipelines stuff that we can not have in the Runtime Library right now, but would be available the moment Endicott picks up the current level of Pipes. We can't take plastic pipes for granted at installations now, so I am forced to do plumbing with both hands on my back. I hate to waste my time like that. If there were serious concerns w.r.t. compatibility and testing, z/VM could provide a dual setup and have some service machines run old pipes. Those things have been done for years in IGS already. Sir Rob the Plumber
