> > 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 >
That is one argument for making plastic pipe the official distributed version. When a problem is reported to IBM, there would be no doubt as to whether the version of pipes is official. (Is your WinXP authentic or not?) It is precisely the rogue nature of plastic pipes (no offense intended, Mr. Hartmann) that has kept many VM shops from installing it. What if, for example, Marist were to pull the plug (don't laugh, the plug was pulled once before) on the runtime library and nobody else stepped forward to fill the gap? I cannot, in good conscience, recommend building anything critical using software that is not officially supported to my management. I also cannot look at everything being written in the shop to determine if it is critical and, if so, if it uses the outdated, but officially supported version of pipelines. Nor can I support the idea of creating a new committee to do the oversight. The justification is, and always has been, that the new version contains a slew of features that can make programming easier and more versatile for the entire user base. That is the same for any programming language. Features are added because someone needed them. Once built, others can profit from them. Do you want people to justify each new feature that is included in plastic pipes? As far as I am concerned, the ball was dropped when a wall was built between the two versions of Pipelines. This is reminiscent of the way the ball was dropped on the C family of programming languages on VM. The TPF community had built workable solutions to the problems of source and version control on VM. Along comes the C language in TPF and suddenly, we could no longer do TPF development entirely on VM because TPF used features that were not available in the obsolete version of C on VM. Faced with the inevitable, shops moved, at great expense to themselves, to doing all of their compiles and load building to MVS. At a SHARE in San Francisco, an IBM V.P. asked me what it would take to get us (USAir, at the time) to move back to VM. "Would having a current C Compiler be sufficient?, I was asked. I had to bite my tongue to keep the expletives out of my answer. I said, in essence, the we had already spent $2 million to develop a non-VM replacement and were not about to spend another dime moving back to the platform we had just been forced to abandon. I said that if they implemenmted it immediately, during that SHARE, that they would be about four years late. Come to think of it, being forced to move to MVS to get a current C compiler was responsible, in part, for the bad times and eventual bankruptcy of the airline. :-) Regards, Richard Schuh
