On Sat, 7 Jan 2023 23:48:50 -0600, Hobart Spitz wrote: >On Sat, Jan 7, 2023 at 8:10 PM Paul Gilmartin < >0000042bfe9c879d-dmarc-requ...@listserv.ua.edu> 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 > > .... To quote/paraphrase Melinda Varian, "Most people do >a lot with single stream pipes before they ever need multi-stream piping." > Yet multi-stream pipes motivated me to convert from WAKEUP to Pipelies.
>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 > I looked at the doc. Targeted to z/OS 2.1; late 20th Century. Seems functionally stabilized, or have I missed something. >least, IBM should offer the TSO Pipe command as a separate offering. > IBM ignores broad customer interest. >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. > My go-to is "sed" for regular expressions. Haven't tried PCRE. >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, > RC = BPXWDYN( 'alloc rtddn(MyDD) path(...) ...' ) > ... this should read it and convert it to EBCDIC. > >*"zPipe < ddname=unixinfl | split '0d0a'x | call translate '"**EBCDIC"' | >stack" * > Little need to convert. For better or worse, z/OS UNIX is EBCDIC-based. Better for communicating with z/OS; worse for communicating with the real world. The z/OS line terminator is '15'x/ And z/OS provides the splendid "iconv" for conversion among numerous CCSIDs. Don't re-invent the wheel <https://www.ibm.com/docs/en/zos/2.5.0?topic=scd-iconv-convert-characters-from-one-code-set-another>. >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. > It's an antique shortcoming that MVS lacked a concept of a standard message stream. Many utilities use SYSTERM; others such as IEBGENER use SYSPRINT. >> 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. > This sounds like antique Windows fake pipes. In that era, a Windows partisan told me, "Of course Windows has pipes. The first stage just writes a temp file and the following stage reads and deletes it." Here;s a filter to read lines from such as a logging stream and prefix each with a number and a timestamp. I don't forsee such in zPipes. (In Batchpipes?) /* Rexx Timestamp input lines. */ signal on novalue do L = 1 S = linein( '/dev/fd/0' ) if stream( '/dev/fd/0', 'S' )<>'READY' then leave L call lineout '/dev/fd/1', L time( 'L' ) S end L -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
