I was also going to reply to Eloy's note but ran out of time last week. Hoping to not tread on NetRexx Pipelines (and glad to hear that René and Jeff are continuing Ed's work), I must point out that it is possible to have Hartmann-style plumbing /natively/ on other platforms. I proved (for myself and to satisfy my own requirements) that a pair of POSIX pipes flowing in opposite directions provides a connector. Then relying on the dispatcher of the host operating system, multi-stream pipelines, with properly bounded (out of band, not embedded in the data) records, the central features of CMS/TSO Pipelines, can be achieved.
Doing it with POSIX constrains things to a POSIX environment. But POSIX is now so broadly implemented (Linux, USS, AIX, Solaris, HP-UX, *BSD, MacOS/Darwin, others) that seems like not a hardship. What was once called Unix is no longer an operating system but is a standard. So doing pipelines for POSIX means an implementation _less constrained_ than CMS or TSO. Launching the stages as individual processes (not merely threads) makes them fully independent (not needing to share a single address space). It's even _less constrained_ than NetRexx Pipelines (no requirement for the JVM), but can inter-operate with NetRexx (and therefore with NR Pipes). The hard part, and where I got stuck, is parsing a pipeline spec. These stages do not connect with mere shell speak. There are TWO file descriptors for each connection. One flows forward, carrying either data (one record at a time) or metadata (as requested by the consumer). The other flows backwards, controlling when it can and cannot consume or peek. Where a shared memory segment is viable, things might flow faster, but the starting point is just a pair ofpipe() calls. Think outside the box. That's just the beginning. This works. If someone could lend a hand with the parser, the project might actually go somewhere. In case it's not already obvious, such an implementation does not have its own dispatcher. John and Rob, who know the internals of the original implementation, can probably enumerate how that will impact the result. I agree it is a compromise, but also say that it is another point of being _less constrained_, because CMS Pipelines regularly runs afoul of other "dispatchers" in CMS land. Anyone interested? -- R; <>< On 1/24/22 08:00, René Jansen wrote: > I am still baffled by the mores on this list. Please remember that imitation > is still the sincerest form of flattery. > > Statements like these cast a bleak future for the Pipelines concept, give all > the so-called modernization efforts and Rexx-bashing IBM is up to. (Which was > not even denied). > We, the NetRexx Pipelines team (which is Jeff and I at the moment, although > we can use extra heavyweights like you and Rob), are still interested in a > testset for Pipelines, if it is obtainable anywhere without using RSCS. I > might be interested in the new BITNET but I don’t have the time - NetRexx > 4.02 will be out today, with even more Pipelines compatibility. > > Of course CMS and Java are different contexts. We have, on the foundation of > Ed Tomlinson’s work, implemented something that can do multistage pipelines, > and executes very many of the examples verbatim as per the documentation. One > of the main reasons not everything can be implemented is that for many > concepts there is no equivalent. For other aspects, like multitasking, it > offers the opportunity for better performance (Multitasking in CMS is meh, > and not in Pipelines). It also opens up the possibilities for slight > differences, of which I am trying to get examples from the accusing side, but > cannot seem to get. The known differences are documented in a PDF, with a > color(colour) coded legenda of what is available where. And yes, writing > stages in Rexx can be done, although it is Net-Rexx at the moment. (But fast!) > There is a CMS like shell, the NetRexx Workspace, where pipelines are typed > in on the command line to work like in VM. > > For the slight differences, I will point out the performance gains on a > modern multiprocessor like the one in our phones. And the multi die of > platforms it runs on. And we run on USS - while the Share requirement for > Pipelines in TSO seems to have branched to Fishkill. > > So for Eloy who is thinking he will miss Pipelines, Dave Jones gave a > perfectly valid suggestion. I am slightly disappointed. Not angry, but > disappointed. > > Best regards, > > René. > > >> On 23 Jan 2022, at 13:03, John P. Hartmann <[email protected]> wrote: >> >> I'm afraid you are sunk. >> >> Anything else is just a toy. None have been validated against the pipelines >> regression reference. None performs or scales. >> >> If your withdrawal is too painful, there is the z/PDT. >> >> On 1/19/22 18:37, Eloy Rodríguez Barrio wrote: >>> Our management has decided to discontinue our zOS mainframe where we had >>> CMS/TSO Pipelines installed in TSO. We will move our applications to Linux >>> servers but I will definitely miss CMS/TSO Pipelines because I have been >>> using it for more than 20 years. >>> By any chance would anyone know whether there would be a similar tool in >>> Linux/Unix ? Because our managed services converted a rather simple pipe >>> containing +-20 stages into a perl program of 90 lines and it took them >>> weeks before getting the expected results! >>> Thank you
