On Sat, Jan 7, 2023 at 8:10 PM Paul Gilmartin < [email protected]> wrote:
> On Fri, 6 Jan 2023 15:33:44 -0600, Hobart Spitz wrote: > > > >https://www.cbttape.org/updates.htm > > > > > https://docs.google.com/presentation/d/1C7htK9I4rL-4pUZcdhfeA4-IY2Kjxm-HJQ4fuljMs3I/edit?usp=sharing > > > Glancing at that, I see no mention of "connector", a feature of CMS > Pipelines that > I used, for example in a FANINANY stage. Does zPipes have a similar > facility > with a different name? > At this time *: is a synonym for STACK, because the function is the same in zPipe. I think a FANINANY stage will never be in zPipe, due to the design. zPipe is not meant to be a replacement for Pipelines, rather a stepping stone to it. To quote/paraphrase Melinda Varian, "Most people do a lot with single stream pipes before they ever need multi-stream piping." If people really understood what the BatchPipes PIPE command does, it would be a complete no-brainer to get BatchPipes just for the PIPE command, even if they never used all the extra stuff that comes along. At the very least, IBM should offer the TSO Pipe command as a separate offering. > > Some programmers will have existing z/OS UNIX filters that they'd prefer > not to > refactor as zPipes. I agree. I think that writing simple stages, like h*ead, tail, cat,* etc., in REXX using the stack as shown might be easy, for people who want the flexibility to go either way. Head and tail in REXX might perform better, since you are just dropping pointers. > Does zPipes provide a UNIX interface. I suppose that could > be achieved with Rexx plumbing, connecting stdin to input connector; > stdout and > stderr to output connectors 0 and 1 (CMS Pipelines jargon) and SYSCALL > spawn. > I haven't worked with USS to any real extent, so I can't say for sure. That said, if you can allocate it to a DD, this should read it and convert it to EBCDIC. *"zPipe < ddname=unixinfl | split '0d0a'x | call translate '"**EBCDIC"' | stack" * That is, assuming I have the right hex code for CRLF, and you set the variable EBCDIC to map ASCII as the second parameter to the REXX TRANSLATE() function. When you provide two parameters to TRANSLATE(), the third is assumed to be 256 characters, 00-FF. (See the code for the zPipe CALL stage.) As it stands now there is only one input and one output stream in zPipe. I don't know how to think about handling stdout and stderr. REXX has its own mechanism for error messages. I think it might start something like this: *EBCDIC = left('00'x || " " || '05'x, 32)" !""#$&'()*+,-./0123456789"* ... In other words, you list all the ASCII characters in their numeric order. I left a bunch of blanks where I don't know the equivalents off the top of my head. > > Could such a stage operate concurrently with other stages? Difficult in > CMS > because of the CMS single processor single address space paradigm; > restrictions not afflicting z/OS. > There is no concurrency built into zPipe. Each stage is invoked only once, and processes the stack in its entirety, queueing the output to the bottom of the stack. If you could write a loop that repeatedly issued zPipe to read from a USS file, you *might *be able to get that to work, but I'm really sticking my neck out on that one. The file (UNIX pipe?) would have to be written to by a separate asynchronous process. It would be a bit of a kludge. Paul, thanks for the great questions!! Let me know if there is anything else I can do to help. > -- > gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
