Re: [CMS-PIPELINES] Fwd: CALLPIPE ends (-3)

[Hobart Spitz]

Mike;

I'm not sure what you are trying to do exactly.  If you are trying write a
dual mode program or if any reader gets the idea to do so, please
reconsider.

Unless something has changed since the last time I was on CMS, writing a
program that is supposed to work when invoked under CMS and as a Pipe
stage, has an issue.  REXX programs invoked as FUNCTIONs or SUBROUTINEs
will be completing inaccessible when the program run as a stage.  In
addition, COMMAND invocations must use the CMS pipe stage.

I was sorely disappointed when I wrote a stage that invoked my usual
external routines, only to find out that that all came up 40-Routine not
found.  I had to create copies of file type REXX, in addition to the ones I
had, type EXEC.  I neve did that again

So any dual mode program would be under similar limitations.

You have all been advised.

On Wed, 10 Aug 2022, 18:55 Mike Harding,  wrote:

> A common approach, which I frequently use
> /* */
> Parse source . . . . . . env .
> ...
> If env='?' then Parse value 'CallPipe *:' with pcmd pout
> Else Parse value 'PIPE Cons' with pcmd pout
> ...
> pcmd  '|'pout
>
> mike.hard...@kyndryl.com
> z/VM systems support for Kyndryl
> WWVM support
> mikehard...@mindless.com
>

>

Re: [CMS-PIPELINES] Where is the documentation for the IUCV stages?

[Hobart Spitz]

Are you familiar with PipeServ?  It's a pre-written server that does things
like logging, remote commands, timers, scheduling, etc.

Whether it's useful to you as an example, or as a way to do what you want,
it might be worth a look.  One large bank I worked at is using it to
trigger timed ftps.  I've also used it at other sites for smaller projects.



OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Fri, Jun 24, 2022 at 3:07 PM Donald Russell 
wrote:

> Did you look at vmclient and vmclisten?
>
> I use those for execs (client side) to talk to service ids (listen side)
> the server side does a set smsg iucv then sits in pipe vmclisten receive
>
> I use the built in vmcparm structure to build the record and use send/sendr
> as appropriate.
>
>
>
> On Fri, Jun 24, 2022 at 08:58 Dave Jones  wrote:
>
> > Hello, all.
> >
> > I am trying to write a simple Rexx client that communicates to another
> > user id using IUCV. I can't seem to find the documentation for the
> > iucvclient, and iucvlisten stages? Did I miss something here?
> >
> > Many thanks and have a great weekend.
> >
> > DJ
> >
> > --
> > BEST REGARDS
> >
> >DAVE JONES   IBM Z CHAMPION [1]
> > Managing Director for zSystems Support, zLinux, and Cloud
> > ++1 281.578.7544 (Cell)
> > Web: www.itconline.com [2]
> > 18502 Purdy Ct. Houston, TX  77084  USA
> >
> >
> >
> > Links:
> > --
> > [1]
> >
> >
> https://www.credly.com/badges/7c92e732-8ab1-4470-98c6-251c33506d69/public_url
> > [2] http://www.itconline.com/
> >
>

Re: [CMS-PIPELINES] IF stage

[Hobart Spitz]

Yes, it's very old.  It's the z/OS version.

Can anyone share the if callpipe code?



OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, May 5, 2022 at 8:59 PM Donald Russell  wrote:

> Sounds like you have a very old version of pipe. I’ve been using the if
> stage at least since vm 6.4 and probably earlier.
>
> What does pipe query version show?
>
>
>
> On Thu, May 5, 2022 at 18:56 Hobart Spitz  wrote:
>
> > I guess I wasn't clear.  I'm not looking for the specs if, I'm looking
> for
> > the if stage:
> >
> > ...
> > | el: if locate 1
> >
> > |pad 10 -
> >
> > | el:
> >
> > |pad 10 ===
> >
> > | el:
> > ...
> >
> >
> > The if stage is not available on the version of pipes that i'm using.
> >
> > OREXXMan
> > Q: What do you call the residence of the ungulate with the largest
> antlers?
> > A: A moose pad.
> > :-D
> > Would you rather pass data in move mode (*nix piping) or locate mode
> > (Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
> > with more than a dozen filters, while Pipelines specifications are
> commonly
> > over 100s of stages, and 1000s of stages are not uncommon.
> > REXX is the new C.
> >
> >
> > On Thu, May 5, 2022 at 8:39 PM Rich Smrcina  wrote:
> >
> > > If is part of spec, and it is well described in the CMS Pipelines
> > > Reference.
> > >
> > > Sent from my iPad
> > >
> > > > On May 5, 2022, at 8:37 PM, Hobart Spitz  wrote:
> > > >
> > > > Long ago, in a far away galaxy, I saw a callpipe for the IF stage.
> > > >
> > > > Could I trouble someone to post that code?
> > > >
> > > > Thanks!
> > > >
> > > >
> > > > OREXXMan
> > > > Q: What do you call the residence of the ungulate with the largest
> > > antlers?
> > > > A: A moose pad.
> > > > :-D
> > > > Would you rather pass data in move mode (*nix piping) or locate mode
> > > > (Pipes) or via disk (JCL)?  Why do you think you rarely see *nix
> > commands
> > > > with more than a dozen filters, while Pipelines specifications are
> > > commonly
> > > > over 100s of stages, and 1000s of stages are not uncommon.
> > > > REXX is the new C.
> > >
> >
>

Re: [CMS-PIPELINES] IF stage

[Hobart Spitz]

I guess I wasn't clear.  I'm not looking for the specs if, I'm looking for
the if stage:

...
| el: if locate 1

|pad 10 -

| el:

|pad 10 ===

| el:
...


The if stage is not available on the version of pipes that i'm using.

OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.


On Thu, May 5, 2022 at 8:39 PM Rich Smrcina  wrote:

> If is part of spec, and it is well described in the CMS Pipelines
> Reference.
>
> Sent from my iPad
>
> > On May 5, 2022, at 8:37 PM, Hobart Spitz  wrote:
> >
> > Long ago, in a far away galaxy, I saw a callpipe for the IF stage.
> >
> > Could I trouble someone to post that code?
> >
> > Thanks!
> >
> >
> > OREXXMan
> > Q: What do you call the residence of the ungulate with the largest
> antlers?
> > A: A moose pad.
> > :-D
> > Would you rather pass data in move mode (*nix piping) or locate mode
> > (Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
> > with more than a dozen filters, while Pipelines specifications are
> commonly
> > over 100s of stages, and 1000s of stages are not uncommon.
> > REXX is the new C.
>

[CMS-PIPELINES] IF stage

[Hobart Spitz]

Long ago, in a far away galaxy, I saw a callpipe for the IF stage.

Could I trouble someone to post that code?

Thanks!


OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

[CMS-PIPELINES] Piping under ISPF

[Hobart Spitz]

Cross posted to IBM-MAIN, TSO REXX, and Pipelines.

 The ISPF stacking character can be set to "|", but TSO tries to execute
the passed stack data after each command.  If that could be disabled, data
could be passed from program to program, providing a stack based piping
capability.
Does anyone know how to disable stack data being executed?
Could it be a viable requirement candidate to have two command
delimiters, one that executed the stack and one that didn't?

Thanks!!

OREXXMan
Would you rather pass data in move mode (*nix piping) or locate mode
(Pipes) or via disk (JCL)?  Why do you think you rarely see *nix commands
with more than a dozen filters, while Pipelines specifications are commonly
over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.

[CMS-PIPELINES] Comparison of UNIX piping, Pipelines (and JOB) ALU usage.

[Hobart Spitz]

Cross posted to IBM-MAIN and CMSTSO-Pipelines lists.

Overview:

   1. An ALU (Arithmetic Logical Unit) load estimation shows CMS/TSO
   Pipelines is orders of magnitude more ALU efficient than UNIX piping.
   2. UNIX piping is significantly better than JCL step-to-step data
   passing and, consequently, Pipelines is also better.  (P>U, U>J, therefore
   P>J.)
   3. It will take a lot of pressure to get TSO Pipes or BatchPipes into
   the z/OS base.
   4. Customers will only bring pressure if they have good reason, for
   example, by using BatchPipes, which includes TSO Pipes..
   5. Installing BatchPipes is one way to experience Pipelines and the
   benefits of BatchPipes fittings in JCL
   6. A few successful pilot programs might break the ice and make this
   "piping-on-steroids" tool available to all z/OS users.

Details::

Below is the output from a program estimating the ALU usage of Pipes versus
that of UNIX command piping.  I chose to estimate the number of characters
reaching the ALU (Arithmetic Logical Unit)  because the measure might be
less affected by hard to account for factors, like system load, instruction
pipelining, out of order execution, and caching behavior.  If there were
just a few referenced fields in a record and they were close to each other,
only one or two cache lines might need to be loaded in Pipes.  Conversely,
if there were many referenced fields and they were widely spread around the
record, more cache lines might need to be loaded.

Comparison of UNIX piping vs. CMS/TSO Pipelines based on
estimated characters reaching ALU.
Fraction of bytes used by average Pipes stage: 0.25
UNIX piping ALU usage / Pipelines ALU usage
+---++++
|   |__ Record Sizes __|
|Stages | 25 |250 |   2500 |
+---++++
|10 | 55 |134 |157 |
|   100 |548 |   1342 |   1570 |
|  1000 |   5479 |  13423 |  15699 |
+---++++
Note:  UNIX performance drops with both more stages and longer records.
Working set size was not taken into account.
Accounting for working set size would involve 64K*Stages for UNIX.
That would increase the Pipes advantage even further.


0.007000 elapsed seconds.


Note that both increasing the number of stages and increasing the logical
record length independently improved Pipelines performance.  This is not
surprising as, in UNIX, data must be copied from the input buffer to the
output buffer at each and every stage.  In Pipelines, such copying rarely
occurs and only referenced data need reach the ALU.  File size has no
significant bearing on this calculation.  As noted, taking working set size
into account probably would show even better numbers for Pipelines.

These calculations are guesstimations.  That they show an
orders-of-magnitude difference means that exact numbers are not important.
What is important is that a 100 fold or 1000 fold improvements are
possible.  Here is a snippet showing the basics.  The rest was formatting.:

...
/* Est. Bytes used (10%) + changed rcds (10%) + delayed rcds (5%).*/
PipesBytesUsedFract = 0.25
/* In other words, fraction of file bytes that actually enter ALU.*/
...
/* Estimate number of bytes per record that are used by the ALU.  */
/* Account for UNIX DBCS, UNIX stage write, and Pipes structures. */
UNIX:
  return LR.iLR * Stages * 2 * 2


Pipes:
  /* Parm pointer (4) + #Record descriptor (8)*/
  return LR.iLR * PipesBytesUsedFract + 12
...


Consider the cell in the middle row and the middle column (1342).  If a
process ran for an hour with heavy UNIX piping, it could take as little as
2 seconds (3600/1342=1.937) using Pipes.  (If it was I/O bound, it might
take longer.)  On the other hand, what takes multiple UNIX piping commands
might be just a single Pipe command.  Real world testing would be best.
That said, ALU usage is tied to working set size, cache load and
CPU usage.  (CPU usage includes the whole instruction pipeline.  ALU is
just the final stage, which operates mostly in parallel with the rest of
the instruction pipeline.)  Further, this might explain why IBM suddenly
added multiple additional cache levels at the same time they were pushing
UNIX and C.

If you could get the Flash on your baseball team, wouldn't you have him
running bases?  (Hmmm.  I've never liked the names BatchPipes and
BatchPipesWorks.  It's as if someone wanted to doom the products by giving
them awful names.  How about FlashBatch and FlashPipes?)

These huge numbers might explain some of the IBM resistance to Pipes in the
z/OS base.  Major revenue leveling could be a valid concern (but a windfall
for customers).  Realistically, it would depend on the rate of adoption and
reimplementation to Pipes, and could be mitigated by appropriate marketing
efforts to attract new customers.  Could there be a legal argument that,
since hardware revenue growth would be reduced and/or global warming
mitigated, making Ba

Re: [CMS-PIPELINES] PIPElines vs. *nix

[Hobart Spitz]

Gil, I know you mean well.

Your first two points are addressed by one answer:  The goal in the test is
to compare the efficiency of record-oriented piping versus
character-by-character piping.

In the first case, bypassing the *nix piping mechanism defeats the goal of
the test.

In the second case, cat can't finish until wc starts reading the last 4k
(or so) characters at the very end of the data.  With 170 M of data, that
means that the timing would be off by very much less than 0.01%, which
greatly exceeds normal variation.  Further, the timings were reported to me
in more detail than I believe time reports.  Therefore, it was probably not
the time output that gave 75 secs.  I just choose to use the only total
time that was reported to me.

Finally, I got confused and assumed that the original PIPElines case was
abbreviated or there was a typo.  I incorrectly added the $ cms and
quotes.  That is entirely on me.  It should have just read:

PIPE < /home/../m170file.data | count bytes | cons


I've heard of PIPElines with 10K-15K (mostly generated) stages.  Depending
on the topology, such a thing would be impossibly slow with
character-by-character piping.  And that's assuming you could even do
deterministic multi-stream piping the way PIPElines does.

Think of the difference between *nix piping and PIPElines piping this way:
Your have a dinner party with a dozen guests.

Under *nix piping, you pass each and every string bean, corn kernel, and
pea to the plate of the person next to you, one-at-a-time, and only one
vegetable can move at a time.  If you even finished such a dinner, you
would never get anyone to show up at another.  And we haven't even
considered the cache-flooding implications.

Under PIPElines piping, whole plates of vegetables get passed around in the
familiar way.  The serving utensil the "cache loader".  Vegetables that you
don't want just stay in the serving bowl (slow memory or disk).

Bon appetit.  :-)

I hope this helps.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jun 13, 2018 at 10:07 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2018-06-13, at 07:18:40, Hobart Spitz wrote:
>
> > Cross posted to CMSTSO Pipelines and IBM-MAIN
> >
> > Someone shared with me a performance comparison between Pipelines vs.
> > native *nix commands, both on OPENVM.
> >
> > Under the OPENVM shell, this command ran 75 secs. with a 170M file in
> BFS:
> >
> > $ time cat m170file.data | wc -b
> >
> The "cat" is superfluous.  Why not just:
> > $ time   wc -b  m170file.data
>
> In fact, you were timing "cat", not "wc".
>
> > This command, also under OPENVM shell with the same file, ran 9 secs.:
> >
> > $ cms 'PIPE < /home/../m170file.data | count bytes | cons'
> >
> Won't Pipelines respect a path relative to current working directory?
> If not, shame on Pipelines.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

[CMS-PIPELINES] PIPElines vs. *nix

[Hobart Spitz]

Cross posted to CMSTSO Pipelines and IBM-MAIN

Someone shared with me a performance comparison between Pipelines vs.
native *nix commands, both on OPENVM.

Under the OPENVM shell, this command ran 75 secs. with a 170M file in BFS:

$ time cat m170file.data | wc -b


This command, also under OPENVM shell with the same file, ran 9 secs.:

$ cms 'PIPE < /home/../m170file.data | count bytes | cons'

Unfortunately, the person who sent this to me wasn't in a position to spent
any more time or resources on this, so I invite any one inclined to run a
similar comparison and post the results.

You may need something like this to avoid an abend depending on your system:

$ cms 'pipe filedesc 0 | count bytes | cons' < m170.data


Under OPENMVS, e.g., try something like:

$ tso 'PIPE < /home/../m170file.data | count bytes | cons

(Caution, I have not used OPENMVS/USS, so the syntax could be wrong.)

MVSers who don't have PIPElines, and VMers who want to, can try comparing
*nix equivalents to REXX using LINEIN() if you have it, or EXECIO * if you
don't.  This will tell us if Pipelines' design is a bigger contributor to
efficiency, or if it is the superiority of record-orientation vs.
character-orientation.

I recommend using RITA to get stage level statistics.  I suspect that
scanning for CR/LF is more expensive than counting bytes in PIPElines,
while the cost might be similar in *nix.

Some variations you may want to try:

   - Count lines and/or words.
   - Try different mainframe *nix version.
   - Add more filters.
   - Add filters that drop and/or add records.
   - Add some filters that change records.
   - Use file(s) already in the CMS/MVS file systems.  The 

Re: [CMS-PIPELINES] getting the RC from third party commands

[Hobart Spitz]

Would I be wrong to say a sipping CALLPIPE in a loop might be a good
generalized solution for issuing multiple commands, and keeping the return
codes and messages properly timed?

...
do while RC("peekto") = 0

"callpipe (end ?) *: | take 1 | c: command | *: ? c: | *.1:"

end
...


If I'm not mistaken, each input command record is not consumed until the
messages, followed by the RC on the secondary out, have been consumed.  If
you need to respond to the RC, then you can invoke the callpipe one record
at a time.


OREXXMan
JCL is the buggy whip of 21st century computing.
We want TSO Pipes NOW!

On Thu, Jan 11, 2018 at 4:33 PM, Rob van der Heij  wrote:

> On 11 January 2018 at 20:29, Miguel Soltero Diaz  wrote:
>
>
> > Most of the code is REXX. I thought we could use PIPES to do the work.
> >
>
> Yes, you could. I most certainly would. Maybe a bit ambitious as your first
> real project with CMS Pipelines.
>
> What the trivial examples did not show you is that "command" takes a stream
> of commands to issue. That makes sense when you generate the commands from
> another source.
>
> For each command issued, the return code is written to the secondary
> output, then the command response is written to the primary output. The
> reason for your pipeline stall is that the "fanin" expects to read primary
> input first, then secondary input. If you really just wanted to merge the
> two, you could "faninany" (and get the return code first) or you "buffer"
> the command response and put the return code after it (but that only makes
> sense when you just issue one command).
>
> What I would probably do is to use the return code of the VMSECURE command
> to track which commands failed, so that you can review them, or correct
> them, or whatever makes sense. I've done things like that when running
> commands on a group of Linux guests and sometimes those things would fail
> for unexpected reasons to be explored.
>
> Sir Rob the Plumber
>

Re: [CMS-PIPELINES] GLOBALV

[Hobart Spitz]

How about something like:

"pipe command GLOBALV SELECT SQL/DS GET DBNAME var1 var2 | hole | append
literal dbname var1 vart2 ... | split | varfetch | " ?

OREXXMan
JCL is the buggy whip of 21st century computing.
We want TSO Pipes NOW!

On Thu, Dec 21, 2017 at 12:03 PM, Rob van der Heij 
wrote:

> The GET stores the value in a REXX variable, but there is nothing to pick
> it up and put it into the pipe.
>
> On Thu, 21 Dec 2017 at 18:00, Gentry, Steve <
> steve.gen...@westernsouthernlife.com> wrote:
>
> > I'm not understanding something.
> > Why does this work: GLOBALV SELECT SQL/DS LIST
> >
> > And this doesn't:  GLOBALV SELECT SQL/DS GET DBNAME  (DBNAME IS
> valid.)
> >
> >
> > -Original Message-
> > From: CMSTSO Pipelines Discussion List [mailto:CMS-PIPELINES@VM.
> MARIST.EDU]
> > On Behalf Of Michael Harding
> > Sent: Thursday, December 21, 2017 10:47 AM
> > To: CMS-PIPELINES@VM.MARIST.EDU
> > Subject: Re: GLOBALV
> >
> > Or...
> > 'PIPE command GLOBALV SELECT $$RDRLIS LIST | ... '  and locate or pick
> the
> > item(s) of interest.
> >
> > --
> > Mike Harding
> > /sp
> >
> >
> > CMSTSO Pipelines Discussion List  wrote on
> > 12/21/2017 07:31:37 AM:
> >
> > > From: Rob van der Heij 
> > > To: CMS-PIPELINES@VM.MARIST.EDU
> > > Date: 12/21/2017 07:31 AM
> > > Subject: Re: GLOBALV
> > > Sent by: CMSTSO Pipelines Discussion List
> > > 
> > >
> > > Steve,
> > >
> > > Not really. CMS does not provide a native interface for CMS Pipelines
> > > to exploit.
> > >
> > > You can do things with "command" like this:
> > >   'PIPE command GLOBALV SELECT $$RDRLIS STACK RDATETYP | append stack
> > | ...'
> > >
> > > If you write a REXX filter, the value() function may be useful to do
> > > what you need.
> > >
> > > Rob
> > >
> > >
> > > On 21 December 2017 at 16:24, Gentry, Steve <
> > > steve.gen...@westernsouthernlife.com> wrote:
> > >
> > > > Hi.  Is it possible to issue the GLOBALV   command from pipes?  Or is
> > > > there a STAGE to retrieve the info?
> > > > I've tried a number of combination of commands with no luck.  Those
> > > > include  "| CMS GLOBALV . . . ." ,  "| CP GLOBALV . . . ." ,  "|
> > COMMAND
> > > > GLOBALV . . . . "  and a couple of things with SPEC.
> > > > I could just read the file in a pipe and get what I want but prefer
> > > > not
> > to.
> > > > Thanks,
> > > > Steve
> > > >
> > >
> >
>

Re: [CMS-PIPELINES] split between a number and a letter

[Hobart Spitz]

... tokenize! verify!verify...
No pipe on my phone.
One verify for alphas, one for numerics.
Maybe a bit more detail would help.

On Nov 2, 2017 1:01 PM, "Glenn Knickerbocker"  wrote:

> To pick out PTF numbers from freeform text, I'm splitting on anything
> that's not alphanumeric and then looking for U as the first character,
> etc.  I just had a problem where somebody accidentally ran the APAR and
> PTF numbers together into PI86281UI51100, so I didn't find the PTF
> number.  My code *should* be short-lived, and I could SPLIT BEFORE ANYOF
> 'OPU' to handle our current APAR and PTF prefixes, but we all know how
> many decades later we fall into those traps.  Am I overlooking some
> simple way (short of resorting to PATTERN) to split before a letter that
> follows a number?
>
> ¬R
>

Re: [CMS-PIPELINES] MOVIE XMASGIFT - Pipedemo - Web Edition

[Hobart Spitz]

Very nice.  I didn't know a web version existed.

I would ask myself what is the goal and target audience of the video:  If
the answer is an introduction for novices (which I doubt), then you might
want shoot for more basics and simpler examples.

Concerning the demo, is there some way, perhaps optionally, to slow down or
pace it so that you can see the records flow from stage to stage?

On Thu, Aug 24, 2017 at 11:06 AM, Rob van der Heij 
wrote:

> Just the movie of a gift right now...
>
> I am looking for feedback from my fellow plumbers to determine whether
> there is value in properly wrapping the package and making it available.
>
> See https://wordpress.com/post/rvdheij.wordpress.com/324 or
> https://youtu.be/AUsCdmjlaSU
>
> Sir Rob the Plumber
>



--
OREXXMan

Re: [CMS-PIPELINES] Convert continuation character

[Hobart Spitz]

pipe < input | i1: if pick 72 <> / / | spec 1-* 1  /+/ 72 | i1: | > output

On Wed, May 17, 2017 at 8:54 AM, Davis, Larry (National VM Capability) <
larry.dav...@dxc.com> wrote:

> In an IOCP file Column 72 usually has an arbitrary character to represent
> that the next line is a continuation of this line.
>
> How can I use a Pipe to Change every line that has Something other than a
> blank or Null in Column 72 to what I want to use as a continuation
> character like a '+' or '*'.
>
> I started to think I could use a blank between the delimiters in the
> LOCATE stage but this just puts a + in column 72 and makes every line a
> continuation.
>
> '| o1:  LOCATE 72 / /',
> '| i1:   FANINANY ',
> .
> .
> .
> '?  O1:  SPECS 1-71 1 /+/ n 73-* n'
>
> Any suggestions from the pipers
>
>
>
> Larry Davis
> DXC Technology, National Mainframe z/VM team
> T +1.813.394.4240
> larry.dav...@dxc.com
>



--
OREXXMan

Re: [CMS-PIPELINES] Pipethink and filtering. CP QUERY PATHS 0-FFFF

[Hobart Spitz]

Correction:


/*--
-
   c100: j800:
+--+   ++   +-+   +-+ +-+   ++   +---+
++   +---+
|cp|-->|drop|-->|p|-->|specs|>|J|-->|pick|-->|...|
-->|sort|-->|...|
+--+   ++   |i|   +-+ |u|   ++   +---+
++   +---+
|c|   |x|
|k|   ++   ++   +-+   |t|
| |-->|pick|-->|pick|-->|specs|-->|a|
+-+   ++   ++   +-+   +-+

---*/

"pipe (end ? name querypath listerr)",
  "?   cp   query path  ",
  "|   drop last 1  ", /* No Legend line. */
  "| c100: pick w1 == /Device/  ",
  "|   specsw2-4 1.25   ",
  "| j800: juxtapose",
  "|   pick w3 \== /ONLINE/ ",
  "|    ", /* Do some processing here. */
  "|   sort f1  ", /* Back to original order.  */
  "|    ", /* More processing  */

  "? c100:  ",
  "|   pick w1 \== /Online/ ",
  "|   pick w2 \== /Available/ ",
  "|   specsrecno 1.8 right  1-* nf",
  "| j800:  ",

On Thu, Mar 23, 2017 at 3:04 PM, Hobart Spitz  wrote:

> At first blush, I think this is a job for JUXTAPOSE.
>
> Assuming you're working with something like this:
>
> Device 0192, Status ONLINE
>  CHPIDs to Device 0192 (PIM)  : 11 12 1A 22 30 40
>   Physically Available (PAM)  : +  +  +  +  +  +
>   Online   (LPM)  : -  -  +  +  +  -
>   Offline by Authorized User  : +  -  -  -  -  -
>   Offline by Control Unit : -  +  -  -  -  +
>Legend + Yes - No
>
>
> I would try:
>
> /*--
> -
>c100:   j800:
> +--+   ++   +-+   +-+   +-+   ++   +---+   ++
> +---+
> |cp|-->|drop|-->|p|-->|specs|-->|J|-->|pick|-->|...|-->|sort|
> -->|...|
> +--+   ++   |i|   +-+   |u|   ++   +---+   ++
> +---+
> |c| |x|
> |k|   ++   ++   |t|
> | |-->|pick|-->|pick|-->|a|
> +-+   ++   ++   +-+
> 
> ---*/
>
> "pipe (end ? name querypath listerr)",
>   "?   cp   query path  ",
>   "|   drop last 1  ", /* No Legend line. */
>   "| c100: pick w1 == /Device/  ",
>   "|   specsw2-4 1.25  recno 26.8 right  x05 n ",
>   "| j800: juxtapose",
>   "|   pick w3 \== /ONLINE/ ",
>   "|    ", /* Do some processing here. */
>   "|   sort f1  ", /* Back to original order.  */
>   "|    ", /* More processing  */
>
>   "? c100:  ",
>   "|   pick w1 \== /Online/ ",
>   "|   pick w2 \== /Available/ ",
>   "| j800:  ",
>
> RECNO ensures that all records return to their positions within the group.
>
> The output from JUXT will look something like this:
>
> 0291, Status ONLINE1*tab*CHPIDs to Device 0291
> 0291, Status ONLINE2*tab*Offline by Authorized User
> 0291, Status ONLINE3*tab*Offline by Control Unit
>
>
>
>
> On Thu, Mar 23, 2017 at 1:33 PM, Stanislawski, Shawn (National VM
> Capability)  wrote:
>
>> Been working on developing my Pipethink, but this scenario has me
>> stumbling.
>>
>> Taking "CP QUERY PATHS 0-" and filtering so that only those with
>> potential problems (those who are NOT:  "status ONLINE"  AND  "show a '+'
>> for every CHPID") get output to console.
>> The more I poke at this, the more complex it gets.
>>
>> "CP QUERY PATHS" , according to the HELP file:
>> - Each output has from 5 up to and including 12 records/lines total.
>> - Each of the potential lines is a known template, and the first four are
>> always present and always the first four.
>> - The only

Re: [CMS-PIPELINES] Pipethink and filtering. CP QUERY PATHS 0-FFFF

[Hobart Spitz]

At first blush, I think this is a job for JUXTAPOSE.

Assuming you're working with something like this:

Device 0192, Status ONLINE
 CHPIDs to Device 0192 (PIM)  : 11 12 1A 22 30 40
  Physically Available (PAM)  : +  +  +  +  +  +
  Online   (LPM)  : -  -  +  +  +  -
  Offline by Authorized User  : +  -  -  -  -  -
  Offline by Control Unit : -  +  -  -  -  +
   Legend + Yes - No


I would try:

/*---
   c100:   j800:
+--+   ++   +-+   +-+   +-+   ++   +---+   ++
+---+
|cp|-->|drop|-->|p|-->|specs|-->|J|-->|pick|-->|...|-->|sort|
-->|...|
+--+   ++   |i|   +-+   |u|   ++   +---+   ++
+---+
|c| |x|
|k|   ++   ++   |t|
| |-->|pick|-->|pick|-->|a|
+-+   ++   ++   +-+
---*/

"pipe (end ? name querypath listerr)",
  "?   cp   query path  ",
  "|   drop last 1  ", /* No Legend line. */
  "| c100: pick w1 == /Device/  ",
  "|   specsw2-4 1.25  recno 26.8 right  x05 n ",
  "| j800: juxtapose",
  "|   pick w3 \== /ONLINE/ ",
  "|    ", /* Do some processing here. */
  "|   sort f1  ", /* Back to original order.  */
  "|    ", /* More processing  */

  "? c100:  ",
  "|   pick w1 \== /Online/ ",
  "|   pick w2 \== /Available/ ",
  "| j800:  ",

RECNO ensures that all records return to their positions within the group.

The output from JUXT will look something like this:

0291, Status ONLINE1*tab*CHPIDs to Device 0291
0291, Status ONLINE2*tab*Offline by Authorized User
0291, Status ONLINE3*tab*Offline by Control Unit




On Thu, Mar 23, 2017 at 1:33 PM, Stanislawski, Shawn (National VM
Capability)  wrote:

> Been working on developing my Pipethink, but this scenario has me
> stumbling.
>
> Taking "CP QUERY PATHS 0-" and filtering so that only those with
> potential problems (those who are NOT:  "status ONLINE"  AND  "show a '+'
> for every CHPID") get output to console.
> The more I poke at this, the more complex it gets.
>
> "CP QUERY PATHS" , according to the HELP file:
> - Each output has from 5 up to and including 12 records/lines total.
> - Each of the potential lines is a known template, and the first four are
> always present and always the first four.
> - The only record I don't really care about is the "Legend", which is
> always the last record in each output.
> - In the first record of each output, the "Status " could have 1 of 8
> conditions for "".
> - Records/lines 3-11 (inclusive) could contain either a "+" or "-" for
> each CHPID (up to 8 total).
>
> If I'm just starting out by 'PIPE CP QUERY PATHS 0-', then I get a
> QUERY PATHS output for each device successively.
>
> The first problem is:
> How can I keep these successive outputs in order, but still work with each
> output as a group when the number of records in the individual outputs is
> variable?
>
> My first thought is to use JOIN so I can then filter the groups of records
> based on criteria.  But I only know with certainty the first and last
> records of each output group, the number of records is variable in each
> group, and there doesn't seem to be any easy way to otherwise distinguish
> one group from the next.
> If the JOIN stage could accept a from-label and a to-label that would
> solve the issue, so a user-made stage could be one solution.  But I feel
> like there's got to be a better solution using just the built-in stages...
>
> I've found an imperfect solution by reducing the outputs to just their
> first 4 lines using an ALL stage and then a "JOIN 3".
> I know BETWEEN/INSIDE would be better, but no idea how I'd JOIN in that
> case...  I'm really trying to avoid a "JOIN *".
>
> Any thoughts?
>
> --Shawn S.
>



--
OREXXMan

Re: [CMS-PIPELINES] Capture rexx output with both CP and CMS commands

[Hobart Spitz]

Offer, et al:

If some of your users can tolerate some changes, and the CP command of CMS
is already used in many of the other places, consider something like the
following:

CP EXEC:

/* REXX- Trap CP output for CMS stage. */
"pipe cp" arg(1) "| cons"
return RC


In addition to simplicity, this allow users to control which commands
should be trapped, and in which environments the output should be trapped.

On Tue, Nov 29, 2016 at 8:49 AM, Offer Baruch  wrote:

> Thank you all for your help.
>
> At the end STARMSG *MSGALL did the trick without the CPCONIO or VMCONIO
> parameters...
> Everything works perfectly now.
>
> Thanks again!
> Offer Baruch
>
> On Tue, Nov 29, 2016 at 2:48 PM, Rod Furey  wrote:
>
> > 
> > But you would be better off to modify your tools to make it more suitable
> > for usage in a pipe (and not prompt for input or things like that).
> >
> > Rob
> > 
> >
> > To emphasise what Rob says: we discovered long ago that a rewrite paid
> > dividends and very quickly paid back the development investment.
> >
> > I have fond memories of the time the Pipelines forum contributors helped
> > someone out and we got an exec's running time down from hours to
> > sub-minute.
> >
> > I realise it may not be possible for you to get a rewrite organised but
> > it's something to think about for the future.
> >
> > Rod
> >
>



--
OREXXMan

Re: [CMS-PIPELINES] Capture rexx output with both CP and CMS commands

[Hobart Spitz]

Sounds a bit painful.  Should there be a builtin stage to do this?

On Mon, Nov 28, 2016 at 2:16 PM, Rob van der Heij 
wrote:

> > I am trying to capture the output of a Rexx exec. the Rexx contains both
> > CMS and CP commands...
> > I would like to capture this output into a stem variable...
>
> If the program is asking CP to write the response directly to the
> terminal, then
> the only option I see is routing all console output through IUCV back (with
> SET CPCONIO IUCV). In theory you could have a pipeline set up to receive
> that
> with STARMSG as long as you can figure out when to stop listening. Or you
> can
> run the program somewhere else and use SCIF to intercept through console
> output.
>
> Rob
>



--
OREXXMan

Re: [CMS-PIPELINES] Pipes future

[Hobart Spitz]

Can anyone share plans to expand pipes support on z/OS?  Could it ever
become part of the z/OS base?

On Sat, Nov 12, 2016 at 5:02 PM, Rob van der Heij 
wrote:

> On 12 November 2016, Paul Gilmartin wrote:
>
> > > * Functionally similar to the latest Runtime Library from Marist
> >
> > "Similar" is frightening.  Will there be incompatibilities?
> > I've depended on WARP which is somehow deprecated.  I might
> > try to be more Pipethinkful if there were examples or guidelines
> > on replacing WARP.  That seems to be left as an exercise for the
> > student.
>
> I obviously did not want to worry someone. "Similar" is as close to
> "the same" as you can get. My standards for accuracy may be a bit
> to strict. The biggest difference is probably the default style,
> but if that never bothered you before, it does not need now.
>
> I am not aware that WARP would be a bad thing. There's ways to
> abuse it, and it's not meant for plumbers who can't solder their
> fittings. Share you're challenge with me off-line and we can see
> what needs to be demonstrated. Always interested in ideas.
>
> Rob van der Heij
> z/VM Development - CMS Pipelines
>



--
OREXXMan

Re: [CMS-PIPELINES] Browse, Experimental device driver

[Hobart Spitz]

I use BROWSE often.  At the risk of throwing a monkey wrench into the
works, I'll add a few comments.

First, BROWSE hangs on a disconnected machine.  When I think there is a
chance of, that I use a wrapper that chooses between CONS and BROWSE based
on the connectedness of the current user machine.  The part that gets
tricky is when CC (honor ASCII carriage control in column 1) is coded.  You
don't want overstrikes going to the console twice, nor do you want
underscores displayed on a separate line, so there is extra code for that.
 (Why use CC on a non-printer?  To get underscores and some color.  Try it.)

Second, it would be great if BROWSE would honor CMS WINDOWS configurations
and display like other CMS WINDOWS "aware" software.

Third, it would be nice if there were some way to configure the PF and
other action keys, and to have it exit due to an external event, esp. a
DELAY expiration.  Thus you could have auto-refresh of a display, and have
key actions other than those that are already hardcoded.

Fourth, the FIND/REPEAT function is severely limited, in two ways.  It is
strictly case sensitive, and there is no indication, by highlighting and/or
cursor positioning, of the location on the screen where the FIND stopped,
or why (found or EOF e.g.).  This makes it less than ideal for end-user
applications.

The point, in essence, is that BROWSE is a useful, valuable stage that is
worthy of various enhancements, and which would be even better with them.
Unlike the XEDIT stage, the entire file does not have to be read into guest
storage, and display starts as soon as the first screen is filled up.  I
think BROWSE deserves to be upgraded from an experimental stage to a
regular stage

On Sun, Oct 30, 2016 at 7:33 PM,  wrote:

> As Pipelines touches almost everything VM/CMS I assume following
> question is appropriate within this list, albeit it is somewhat
> related to 3270 emulations too.
>
> Until this weekend I assumed the display from
>
> > pipe(sep !)xrange 40-ff!fblock 16!term
>
> and
>
> > pipe(sep !)xrange 40-ff!fblock 16!brw
>
> would look similar on any single display. Alas it depends which
> TN3270 emulation I use there are considerable differences on many
> codepoints (the colours are not a problem). The options and
> attributes I tried did not help too much.
>
> Question: how may I ensure the browse stage to use the same
> codepage like Xedit or fullcreen cms on every 3270?
>
> Up to now I used BRW with the attribute 06X to get yellow letters
> on black background, and with 'X' a for sure nonexistent
> programmed symbol set assuming this would enforce the default.
> Wrong, a better 3270 emulation displayed nothing but PROG753 and
> blocked.
>
> Addendum to the above question: How may I ensure yellow on black
> (or if not possible a default setting) without _for sure not_
> blocking any terminal?
>
> Regarding colours, I assumed BRW without attributes uses defaults
> for highlighting, colour and PSS, but BRW (00 displays in a
> different colour on one screen. From the description: Use X'00' to
> select the default attribute value depending on the terminal.
>
> To make it non-ambiguous and clear: my problem is the difference
> between display of special characters between Xedit or Type or
> PIPE...!term on the one hand and PIPE...!BRW otherwise. Quite
> possible you observe no difference as I did until yesterday. The
> difference between one terminal or 3270 emulator to others is
> another subject.
>
> Ciao.Mike
> --
> www.Ok.de - die kostenlose E-Mail Adresse
>



--
OREXXMan

[CMS-PIPELINES] BROWSE stage under FullScreen CMS

[Hobart Spitz]

Hello all;

Does anyone know of a way to convince the BROWSE stage to use the VSCREEN
width of the current window?

Making the VSCREEN wider than the physical screen allows left/right
scrolling of CONSOLE output, but not with BROWSE.

Thanks in advance.

--
OREXXMan

Re: [CMS-PIPELINES] About DELAY after SET TIMEZONE

[Hobart Spitz]

I think that if you clearly document the distinction, then I would think
that different behaviors for +hh:mm versus hh:mm would make sense.

An alternative/additional solution, possibly too much trouble, would be to
add a timezone to the time specification:  E.g.  10:30-EST, 18:15-CDT,
etc.  Why too much trouble?  No all countries change clocks on the same day.

I'm not sure how often this comes up, or why, so that might have a
bearing.  If it's more than just clock changes in fall and spring, that
would matter.

Good luck.

On Fri, Apr 8, 2016 at 5:31 AM, Rob van der Heij 
wrote:

> I did not want to bother the rest of the IBMVM list with this, but I could
> use some votes on what we expect DELAY to do after a SET TIMEZONE was
> issued.
> No promises, but any comments on this?
>
> I understand we want future delays started after the SET TIMEZONE to be
> done
> with the new timezone. The book says 'the specified time is reached' so it
> seems appropriate to correct the working.
>
> But what about the pop that is pending. I am tempted to distinguish
> between an
> interval (with a "+") and a time of day. So +7200 waits for 2 hours,
> whether
> clocks changed or not. But I know some plumbers compute it either way.
>
> Sir Rob the Plumber
> z/VM Development - CMS Pipelines
>



--
OREXXMan

Re: [CMS-PIPELINES] PIPFRE122E Insufficient free storage

[Hobart Spitz]

Did you not read the part about sigl?

I actually use "... name" UsedName"."ExecType".'LineNo()"...", where
LineNo() is

LineNo: return sigl

I know enough about the internals of REXX and Pipes that there might be
issues with getting the line number and/or changing sigl.


On Fri, Feb 26, 2016 at 2:25 PM, Kris Buelens 
wrote:

> Execs often use ùmore than 1 PIPE command, so a default name will not be
> much help.
>
> And, I hope your REXX code does use the default TRACE N, and not TRACE O.
> With TRACE N all commands ending with a negative return code are traced.
> PIPE does a very good job in producing negative return codes for syntax
> errors and alike.
>
>
> Kris Buelens,
>  --- freelance z/VM consultant, Belgium ---
> -------
>
> 2016-02-26 16:33 GMT+01:00 Hobart Spitz :
>
> > Would it be feasible to default NAME to something like
> > UsedName.ExecType.sigl for Rexx programs?   UsedName could be word 6 of
> > PARSE SOURCE and ExecType could be word 4.  sigl would be the setting
> from
> > the last CALL/function invocation.
> >
> > I something like this, and i never have a question where to look when
> doing
> > diagnosis.
> >
> > On Tue, Feb 16, 2016 at 4:34 PM, Glenn Knickerbocker 
> > wrote:
> >
> > > On 2/14/2016 12:55 AM, Paul Gilmartin wrote:
> > > > addpipe MINE | > 'FILE'I ft fm
> > > > ... other stuff, perhaps involving other pipes ...
> > > > select output MINE
> > > > sever  output
> > >
> > > I'd read the output to make sure the file is read to completion.  Also,
> > > I'm not sure if this is still true, but when the alternate input was
> > > added to >MDSK, if it wasn't initally connected, >MDSK didn't notice
> and
> > > would sometimes wait forever for EOF on the unconnected or even
> > > undefined stream, so I have stages that connect and read the alternate
> > > output just to make sure the file is closed, like so:
> > >
> > >   'addstream both MINE'
> > >   ...
> > > 'addpipe (end /) *.out.MINE: | a: > FILE'i ft fm '/ a: |
> *.in.MINE:'
> > > ...
> > > 'select both MINE'
> > > 'sever output'
> > > 'peekto'
> > >
> > > ¬R
> > >
> >
> >
> >
> > --
> > OREXXMan
> >
>



-- 
OREXXMan

Re: [CMS-PIPELINES] PIPFRE122E Insufficient free storage

[Hobart Spitz]

Would it be feasible to default NAME to something like
UsedName.ExecType.sigl for Rexx programs?   UsedName could be word 6 of
PARSE SOURCE and ExecType could be word 4.  sigl would be the setting from
the last CALL/function invocation.

I something like this, and i never have a question where to look when doing
diagnosis.

On Tue, Feb 16, 2016 at 4:34 PM, Glenn Knickerbocker 
wrote:

> On 2/14/2016 12:55 AM, Paul Gilmartin wrote:
> > addpipe MINE | > 'FILE'I ft fm
> > ... other stuff, perhaps involving other pipes ...
> > select output MINE
> > sever  output
>
> I'd read the output to make sure the file is read to completion.  Also,
> I'm not sure if this is still true, but when the alternate input was
> added to >MDSK, if it wasn't initally connected, >MDSK didn't notice and
> would sometimes wait forever for EOF on the unconnected or even
> undefined stream, so I have stages that connect and read the alternate
> output just to make sure the file is closed, like so:
>
>   'addstream both MINE'
>   ...
> 'addpipe (end /) *.out.MINE: | a: > FILE'i ft fm '/ a: | *.in.MINE:'
> ...
> 'select both MINE'
> 'sever output'
> 'peekto'
>
> ¬R
>



-- 
OREXXMan

Re: [CMS-PIPELINES] printonly eof does not by itself force a run-out cycle

[Hobart Spitz]

Agreed.  As I said, these were off-the-cuff comments.

I wasn't thinking about porting between a real 407 and pipes.  I was
thinking about keeping consistent with the model architecture being
emulated for the sake of the humans who have to understand 407E, a
non-trivial task.

"Simply resisting change" was also not my point.  If it were me, I would
want to know that any impact of a change would add a significant capability
that did not already exist, and which could not otherwise be achieved.  In
this case, adding SELECT SECOND would seem to be a tolerable work-around,
versus a number of broken pipes where the knowledgeable people are long
gone..  Also with 6.4 having updated pipes means that there may not be an
easy fallback when a bunch of things go wrong all at once.

I, too, am a purist that prefers clean, consistent, and easy-to-use
interfaces.  If costs vs. benefits justifies a change, then I'm behind you
110%.

Have a good weekend.

On Fri, Feb 19, 2016 at 8:40 AM, Rob van der Heij 
wrote:

> > Two off-the-cuff comments:
> >
> > I'm really rusty on the interaction between the various 407E features.  I
> > think it's possible that this is consistent with the actual 407.
>
> We don't have that many people exchange programs between their real 407 and
> the CMS Pipelines code ;-)
>
> > Second, there may be breakage if you "fix" this.  There may be pipes out
> > there that are using this behaviour, either intentionally or
> inadvertently,
> > which might produce different results if this is changed.
>
> Yes, that is a concern with anything that gets fixed. There are quite a few
> cases where we can't go back and change things the way we want because too
> much water went through the pipeline. We do care about compatibility.
>
> This particular issue shows even in the book - the example with that option
> just did not work. If your plumbing relies on options not doing what they
> are
> supposed to do, then maybe your pipe will break. I tend to challenge people
> to explain me what about the erroneous behaviour was so desireable.
>
> Simply resisting change does not work. Plumbers tell me that not fixing
> bugs
> and not adding new function for two decades is not good either ;-)
>
> Sir Rob the Plumber
>



--
OREXXMan

Re: [CMS-PIPELINES] printonly eof does not by itself force a run-out cycle

[Hobart Spitz]

Rob;

Two off-the-cuff comments:

I'm really rusty on the interaction between the various 407E features.  I
think it's possible that this is consistent with the actual 407.

Second, there may be breakage if you "fix" this.  There may be pipes out
there that are using this behaviour, either intentionally or inadvertently,
which might produce different results if this is changed.

Just my two cents.



On Wed, Feb 10, 2016 at 6:50 AM, Rob van der Heij 
wrote:

> > That is, if you specify neither SELECT SECOND nor an EOF item, the
> > run-out cycle is suppressed, even if PRINTONLY EOF is specified.
> >
> > One circumvention is to specify EOF without further specification items.
>
> It's not just EOF - happens with any break level. Just can't believe that I
> have missed this feature. There's several pipes that I need to revisit once
> we have this corrected.
>
> Sir Rob the Plumber
>



--
OREXXMan

Re: [CMS-PIPELINES] How would I approach this?

[Hobart Spitz]

Have you considered something like:

pipe < input.file | join x05 | specs a: f1 . b: substr 8-14 of f2 . 1-* 1
print a+b 8-14 r | > output.file

We combine the records pairwise as two fields, making them easier to
process, and then we do what we want on the compound record.

I hope this helps.

On Thu, Jan 28, 2016 at 5:22 PM, Bob Cronin  wrote:

> Hello specs fans,
>
> I have two records, like so:
>
> nnn
> CCCmmm
>
> where nnn is a right justified integer and mmm is either that, or
> blanks (which should be considered the equivalent of zero). C is an
> arbitrary character.
>
> I want to emit the just the second record, with the mmm replaced with
> the sum of nnn and mmm (or left alone if nnn is zero).
>
> I am trying to do this with specs, but am getting nowhere.
> --
> bc
>



--
OREXXMan

Re: [CMS-PIPELINES] Funny finding

[Hobart Spitz]

I personally would prefer a stage option rather than a configuration option.

If a new module expected one behavior and a legacy, reused module,
especially a user stage, expected the other, there might be an unresolvable
conflict between the two approaches.

On Mon, Jan 4, 2016 at 11:47 AM, John P. Hartmann 
wrote:

> Looking back, I think I made the wrong call 25 years ago.  If case 3
> were to produce a null record, the output would always contain at least
> as many records as the input.
>
> Stripping to create a null input record to subvert split dropping the
> record when nothing is left is a cop-out.  And it is more difficult to
> anticipate in the general case of split.
>
> Too late to change, I suppose, though a configuration variable might be
> a way out.
>
> On 01/04/2016 04:06 PM, Rob Van der Heij wrote:
>
>>
>> I can answer this one -
>>>
>>
>> I am impressed if you could without trying it. But indeed it is working as
>> documented. Reading the usage notes, it looks like I was confused in the
>> past to make The Piper clarify things ;-)
>>
>> #1 - LITERAL puts a null record in, split does nothing (no blanks)
>>> resulting in 1 null record to count
>>> #2 - same as #1 (LITERAL expects one blank before the intended string; no
>>> string so null record)
>>> #3 - One blank added as literal, split strips it off, resulting in zero
>>> records
>>>
>>
>> The STRLITERAL now helps to take away doubts about #1 and #2. Much of this
>> is driven by the need to remain compatible with things that were done 30
>> years ago. With null records, some of the concepts get a bit hard to
>> explain. Quite often, it does not really matter.
>>
>> Rob
>>
>> ---
>> Rob van der Heij
>> z/VM Development, CMS Pipelines
>> Tenzij hierboven anders aangegeven: / Unless stated otherwise above:
>> IBM Nederland B.V.
>> Gevestigd te Amsterdam
>> Inschrijving Handelsregister Amsterdam Nr. 33054214
>>
>>


--
OREXXMan

Re: [CMS-PIPELINES] Adding 3270 Color attributes to output

[Hobart Spitz]

If your requirements are simple, BROWSE CC can produce a few colors, ans
you get scroll and find builtin.
On Nov 6, 2015 11:26 AM, "John P. Hartmann"  wrote:

> Depends on which type of colour you want.  See OVERSTR/BUILDSCR and QDI
> XEDIT (building a data stream using character attributes).
>
> On 11/06/2015 05:06 PM, Davis, Larry (National VM Capability) wrote:
>
>> Is there a recommended way to add color attributes to data formatting in
>> pipelines on 3270 screens?
>>
>> I want to output data to the screen and change the color from green to
>> yellow or to red depending on the information or status
>>
>>
>>
>> Larry Davis,
>> VM Capability
>>
>>

Re: [CMS-PIPELINES] Conditional reblocking. Or something like that.

[Hobart Spitz]

You could use some thing like:
PIPE (END ?) < ... | F: FANINANY | L: STRFIND /DA/ | S1: SPECS 1-1071 1
SELECT OUTPUT 1 1072-* 1 | > ...
? S1: | F:
? L: | S2: SPECS 1-1114 1 SELECT OUTPUT 1 1115-* 1 | F:
? S2: | F:

If you don't like shunts, IF can used at S1, and S2.

If you need to preserve record order you'll need to work a little harder.

However, a REXX filter might be simpler and more maintainable.

Interesting puzzle.
Do they need to be written to two separate files?

-Original Message-
From: CMSTSO Pipelines Discussion List [mailto:CMS-PIPELINES@VM.MARIST.EDU]
On Behalf Of Mark Boonie
Sent: Wednesday, May 06, 2015 3:50 PM
To: CMS-PIPELINES@VM.MARIST.EDU
Subject: Conditional reblocking. Or something like that.

I have a file that I'd like to reblock based on the first two characters of
each record:  if the first two characters are 'DA' then write 1071 bytes,
but for any other combination of characters I need to write 4111 bytes.  I
don't need a working solution, just a pointer in the right direction.
Thanks.

- mb

Re: [CMS-PIPELINES] misleading message from ALL with null string

[Hobart Spitz]

I found this is my drafts folder.  Sorry to post it 18 months late, but I
think this still has value.

---

For what it's worth, I think the real issue is with the hex string syntax
not allowing the specification of a null string.

In order to support any user string, including a null string, I had to
write PipStr(), which checked for a null string, and if null, returned
"//".  Otherwise It returned "x"c2x(Str) .  It was used in a lot of
places.  It was a bit annoying to change a lot of code just for that.

Perhaps hex strings could have an optional delimiter, which would also
allow embedded blanks (like REXX) for readability and consistancy:

x// = null string.
x/f1f2f3/ = "123"
x/f1 f2 f3/ = same
On Sep 24, 2013 6:10 PM, "Glenn Knickerbocker"  wrote:

> I tend not to use ALL much and build my own cascades instead, and I
> hadn't run into this message before:
>
> > PIPRIC064E Hexadecimal data missing after /.
> > PIPMSG003I ... Issued from stage 1 of pipeline 1.
> > PIPMSG001I ... Running "all (/word/ & //)".
> > PIPRIC192I ... Scan at position 12; previous data "(/word/ & //".
>
> "Hexadecimal" was puzzling here and sent me to the syntax diagram
> looking for special cases involving hex strings.  I finally realized it
> really just meant "Data missing"--the string would be converted to hex
> in the generated subroutine pipeline, so the null string would have
> caused this message if that were run:
>
>*.input.0:
>   !locate XA6969984
>   !locate X
>   !*.output.0:
>
> The doc for ALL doesn't mention that null strings aren't allowed.  Sure
> would be nice if they were just used as-is instead of failing.  Even
> nicer if they were skipped--my own execs are full of code like this:
>
>   If word = '' then locate = ''
>   Else locate = '| locate x' || c2x(word)
>
> Nicest of all if they caused alternatives to be skipped as well, so that:
>
>   all /word/ & // & (/more/ ! //)
>
> worked out to just:
>
>*.input.0:
>   !locate XA6969984
>   !*.output.0:
>
> ¬R
>

Re: [CMS-PIPELINES] CMS PIPE Help

[Hobart Spitz]

If you can dig up a copy of the Pipelines Tutorial, that's a good place for
novices to start.  I believe it was put out by the Redbooks organization
and is long out of print.  It has an orange cover.

On Thu, Oct 9, 2014 at 9:20 AM, Rob van der Heij  wrote:

> Another start is to start with the papers from Melinda Varian.
> http://vm.marist.edu/~pipeline/#MWV
> Get a copy of the Author's Edition
> http://vm.marist.edu/~pipeline/pipeline.pdf (drop me a note if you can't
> download it) and probably also of the PIPELINE HELPLIB for quick reference.
>
> And practice, lots of practice. Identify a task that is currently taking a
> lot of your time, then use CMS Pipelines to resolve it. And be thrilled by
> how fast and easy it is. Invest the time gained by that to learn more
> Pipelines. Feel free to ask here when you get stuck.
>
> I still find something new in CMS Pipelines almost every day, but
> eventually you take the benefits for granted and can't find time to blog
> about each cool trick. http://rvdheij.wordpress.com/
>
> Sir Rob the Plumber
>
> On 9 October 2014 13:54, Beard, Rick  wrote:
>
> > Thanks Kris.
> >
> > -Original Message-
> > From: CMSTSO Pipelines Discussion List [mailto:
> CMS-PIPELINES@VM.MARIST.EDU]
> > On Behalf Of Kris Buelens
> > Sent: Thursday, October 09, 2014 7:42 AM
> > To: CMS-PIPELINES@VM.MARIST.EDU
> > Subject: Re: [CMS-PIPELINES] CMS PIPE Help
> >
> > Our Pipe "Telecourse" ?
> > http://www.vm.ibm.com/download/packages/descript.cgi?TCVM2
> >
> > it is a selfstudy with exercises, in HTML format.  There is an advanced
> > REXX too:
> > http://www.vm.ibm.com/download/packages/descript.cgi?TCVM1
> >
> >
> > Kris Buelens,
> >  --- freelance z/VM consultant, Belgium ---
> > ---
> >
> > 2014-10-09 13:32 GMT+02:00 Beard, Rick :
> >
> > > Anyone know where a good place to start to learn CMS PIPEING?  I've
> > > only been working with z/VM for about a year, but I need to learn how
> > > it can interact with REXX.
> > >
> > > Thanks,
> > >
> > > Rick
> > >
> >
>



--
OREXXMan

Re: [CMS-PIPELINES] variable length fields

[Hobart Spitz]

Steve;

You are very welcome,

Two additional comments:

1 - Have you tried the SQLSELECT stage?  It does the same kind of
formatting you asked for.

2 - Disregard the "implied strip" explanation.  It does not apply in your
case.  A substr of a substr would be required.


On Tue, Aug 26, 2014 at 4:42 PM, Gentry, Steve <
steve.gen...@westernsouthernlife.com> wrote:

> Thanks.  I didn't know you could do that with SPECS. SPECS would seem to
> be a good topic at a VM conference or workshop.
> "You can do a lot of things with SPECS"  (paraphrasing Forrest Gump).
> Steve
>
> -Original Message-
> From: CMSTSO Pipelines Discussion List [mailto:CMS-PIPELINES@VM.MARIST.EDU]
> On Behalf Of Hobart Spitz
> Sent: Tuesday, August 26, 2014 4:37 PM
> To: CMS-PIPELINES@VM.MARIST.EDU
> Subject: Re: variable length fields
>
> How about something like
>
> ... | specs substr 5-* of w1 1 substr 3-* of w2 15.10 right | ...
>
> ?
>
> w2 does an implicit strip...
>
>
> On Tue, Aug 26, 2014 at 12:46 PM, Gentry, Steve <
> steve.gen...@westernsouthernlife.com> wrote:
>
> > I've run a db2 select within a pipe and I get two words back.   Both
> words
> > have a length field in front of it, in hex.  The length of the length
> > field in the first word is 4 bytes long. The length of the length
> > field for the second word is 2 bytes long.
> > So, this is sort of how it looks:
> > """"THIS_IS_FIELD_A  ""13000
> > """"THIS_IS_FIELD_B  ""4577
> >
> > Word 2 is a  numeric field.
> > I want the output to look like this and because word 2 is numeric, I
> > want to right justify it.
> > THIS_IS_FIELD_A 13000
> > THIS_IS_FILED_B4577
> >
> > I can do a SPLIT but because the  two length fields are 4 and 2  , I
> > can't do a SPECS  5-*  1 ( or SPECS 3-* 1 ).  Then there is the issue
> > of JOINing them and getting the formatting (see above) correct.  I
> > don't really care about the length fields (unless, of course, it helps
> > with the overall solution).
> > I can do this by writing a REXX STAGE but I prefer to do it all in PIPES.
> > I'm sure it can be done in pipes and probably with specs but I can't
> > come up with a solution.
> > Does anybody have a suggestion?
> > Thanks,
> > Steve
> >
>
>
>
> --
> OREXXMan
>



--
OREXXMan

Re: [CMS-PIPELINES] variable length fields

[Hobart Spitz]

How about something like

... | specs substr 5-* of w1 1 substr 3-* of w2 15.10 right | ...

?

w2 does an implicit strip...


On Tue, Aug 26, 2014 at 12:46 PM, Gentry, Steve <
steve.gen...@westernsouthernlife.com> wrote:

> I've run a db2 select within a pipe and I get two words back.   Both words
> have a length field in front of it, in hex.  The length of the length field
> in the first word is 4 bytes long. The length of the length field for the
> second word is 2 bytes long.
> So, this is sort of how it looks:
> THIS_IS_FIELD_A  ""13000
> THIS_IS_FIELD_B  ""4577
>
> Word 2 is a  numeric field.
> I want the output to look like this and because word 2 is numeric, I want
> to right justify it.
> THIS_IS_FIELD_A 13000
> THIS_IS_FILED_B4577
>
> I can do a SPLIT but because the  two length fields are 4 and 2  , I can't
> do a SPECS  5-*  1 ( or SPECS 3-* 1 ).  Then there is the issue of JOINing
> them and getting the formatting (see above) correct.  I don't really care
> about the length fields (unless, of course, it helps with the overall
> solution).
> I can do this by writing a REXX STAGE but I prefer to do it all in PIPES.
> I'm sure it can be done in pipes and probably with specs but I can't come
> up with a solution.
> Does anybody have a suggestion?
> Thanks,
> Steve
>



--
OREXXMan

Re: [CMS-PIPELINES] PipeServ Fix Request

[Hobart Spitz]

The CP stage in question is used to send command output back to the
original sender.  PipeServ does not protect the CP stage from
command output lines (think REXX TRACE I, e.g.) that are longer than CP can
hande.

The most likely fix is a SPILL 255 or similar, but my attempts to position
it have not met with success.

I'm sure there is someone very smart out there who has developed a fix.


On Thu, May 15, 2014 at 4:00 PM, Bruce Hayden  wrote:

> The help for the cp stage states:
>
> "cp" terminates with an error message if a command is  longer  than  the
>  240
> bytes supported by CP.
>
> Since 240 bytes is all that CP supports via diag 8, there is no fix
> possible in pipelines.
>
> Or maybe I didn't understand your problem with pipeserv?
>
>
> On Thu, May 15, 2014 at 3:03 PM, Hobart Spitz  wrote:
>
> > If anyone has a fix for this problem, which causes PipeServ to stop
> > replying when long output lines are issued, could you post it to the
> list?
> >
> >
> > Thanks.
> >
> >
> > PIPCOM062E Command length 263 too long for CP.
> >
> > PIPMSG004I ... Issued from stage 3 of pipeline 7 name "pipsrv03".
> >
> > PIPMSG001I ... Running "cp".
> >
> >
> >
> > --
> > OREXXMan
> >
>
>
>
> --
> Bruce Hayden
> z/VM and Linux on System z ATS
> IBM, Endicott, NY
>



--
OREXXMan

[CMS-PIPELINES] PipeServ Fix Request

[Hobart Spitz]

If anyone has a fix for this problem, which causes PipeServ to stop
replying when long output lines are issued, could you post it to the list?


Thanks.


PIPCOM062E Command length 263 too long for CP.

PIPMSG004I ... Issued from stage 3 of pipeline 7 name "pipsrv03".

PIPMSG001I ... Running "cp".



--
OREXXMan

[CMS-PIPELINES] REXX Symposia 2014 & 2015

[Hobart Spitz]

Posted to multiple lists.

The 2014 REXX Symposium, in Memphis TN, has just concluded.  While most
were from the U.S.A., some attendees connected remotely from the U.K. and
Australia and others attended in person from as far away as Holland and
Austria.  It was a great learning experience for REXX users: The schedule
can be seen at http://rexxla.org/events/2014/schedule.html.

The 2015 Symposium is scheduled for March 30 to April 3, 2015, in Vienna
Austria.

List members may want to pay particular attention as OOREXX for z/OS is
getting attention again.  You may want to follow developments and/or to
share your organization's requirements.

You can keep informed and/or participate in one or more of these ways:

   - Check www.rexxla.org from time to time.
   - Put a reminder in your calendar to check
   http://rexxla.org/events/symposium.html starting Feb. 1 2015.
   - Subscribe to the REXXLA list via NABBLE.
   - Get involved as a contributing developer.
   - Join REXXLA at www.rexxla.org.  Membership is $24 (students $12).

OOREXX is an object oriented super-set of REXX.

--
OREXXMan

Re: [CMS-PIPELINES] SPEC with multiple IFs.

[Hobart Spitz]

Mike said:
> I think this is one of those cases where specs requires that a string
be
> delimited specifically with double quotes.

I'm tempted to say that there is no such thing, but I've learned that such
statements are risky.  If there is, I'd like to know for sure; if not, we
owe it to the list to get the correct answer.

That said, I would go back to the original, and run it with TRACE I, and
repost the results with a mono-spaced font.  Perhaps there is are two
single quotes that look like a double quote, or vice versa, e.g..




On Thu, Apr 24, 2014 at 9:24 PM, Frank M. Ramaekers
wrote:

> Yes, double-quotes did the trick.   Never would have guessed.
>
> Frank M. Ramaekers Jr.
>
> > -Original Message-
> > From: CMSTSO Pipelines Discussion List [mailto:CMS-
> > pipeli...@vm.marist.edu] On Behalf Of Michael Harding
> > Sent: Thursday, April 24, 2014 4:29 PM
> > To: CMS-PIPELINES@VM.MARIST.EDU
> > Subject: Re: [CMS-PIPELINES] SPEC with multiple IFs.
> >
> > I think this is one of those cases where specs requires that a string
> be
> > delimited specifically with double quotes.
> >
> > --
> > Mike Harding
> > z/VM System Support
> >
> > mhard...@us.ibm.com
> > mikehard...@mindless.com
> > (925) 926-3179 (w)
> > (925) 323-2070 (c)
> > /sp
> >
> >
> > CMSTSO Pipelines Discussion List  wrote
> on
> > 04/24/2014 01:40:29 PM:
> >
> > > From: "Frank M. Ramaekers" 
> > > To: CMS-PIPELINES@vm.marist.edu
> > > Date: 04/24/2014 01:41 PM
> > > Subject: Re: SPEC with multiple IFs.
> > > Sent by: CMSTSO Pipelines Discussion List
> > > 
> > >
> > > After correcting the missing comma and using ELSEIF, it ends with a
> > cryptic:
> > >
> > >
> > >
> > >   "|  SPEC /UAGLOBE/ 1.8 1-* NW RECNO FROM" X2D(F800) "D2X NW.4
> > > RIGHT a: 6.3 .",
> > >
> > >   "IF a==/MOD/ THEN",
> >
> > >
> > > "/C/ NW",
> >
> > >
> > >   "ELSEIF a==/MVS/ THEN",
> >
> > >
> > > "/C/ NW",
> >
> > >
> > >   "ELSE",
> >
> > >
> > > "/R/ NW",
> >
> > >
> > >   "ENDIF",
> >
> > >
> > > PIPYAC1434E Parse error in state 137, unexpected O_MULT at offset 3:
> > > "/MOD/ THEN /C/ NW ELSEIF a==/MVS/ THEN /C/ NW ELSE /R/ NW ENDI
> > >
> > > F".
> >
> > >
> > > PIPMSG003I ... Issued from stage 2 of pipeline 11.
> >
> > >
> > > PIPMSG001I ... Running "SPEC /UAGLOBE/ 1.8 1-* NW RECNO FROM 63488
> > D2X
> > > NW.".
> > >
> > > PIPYAC1435I Expecting T_IDLETTER T_NUMBER T_QSTRING T_IDENT
> > T_ID_CHAR
> > > T_CTR T_DOT T_DOTDOT T_CTRARRAY S_LP O_PLUS O_NOT F_FIRST F_EO
> > >
> > > F F_BREAK F_C2D F_C2F F_X2D F_X2F F_STRING F_AVERAGE F_VARIANCE
> > > F_NUMBER F_EXACT F_SQRT F_STDDEV F_STDERRMEA
> > >
> > > PIPSPE192I ... Scan at position 69; previous data "OM 63488 D2X NW.4
> > > RIGHT a: 6.3 . IF a==/".
> > >
> > >
> > >
> > > Frank M. Ramaekers Jr.
> > >
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > >
> > > > From: CMSTSO Pipelines Discussion List [mailto:CMS-
> > >
> > > > pipeli...@vm.marist.edu] On Behalf Of Kris Buelens
> > >
> > > > Sent: Thursday, April 24, 2014 3:24 PM
> > >
> > > > To: CMS-PIPELINES@VM.MARIST.EDU
> > >
> > > > Subject: Re: [CMS-PIPELINES] SPEC with multiple IFs.
> > >
> > > >
> > >
> > > > I don't know if that will help: PIPE alos has ean ELSEIF
> > >
> > > >
> > >
> > > >   "ELSEIF a==/MVS/ THEN",
> > >
> > > >   "/C/ NW",
> > >
> > > >
> > >
> > > >
> > >
> > > > Kris Buelens,
> > >
> > > >  --- freelance z/VM consultant, Belgium ---
> > >
> > > >
> 
> > > > ---
> > >
> > > >
> > >
> > > >
> > >
> > > > 2014-04-24 22:19 GMT+02:00 Joe Parker  > > mailto:jgp4...@hotmail.com> >:
> > >
> > > >
> > >
> > > > > Well, it's been quite a few years since I wrote any pipe code,
> > but
> > >
> > > > > could it be there's a comma missing in the first line?
> > >
> > > > >
> > >
> > > > > > Date: Thu, 24 Apr 2014 15:13:22 -0500
> > >
> > > > > > From: framaek...@ailife.com 
> > >
> > > > > > Subject: SPEC with multiple IFs.
> > >
> > > > > > To: CMS-PIPELINES@VM.MARIST.EDU
> > 
> > >
> > > > > >
> > >
> > > > > > I can't seem to find information on what could be wrong with
> this:
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > > "|  SPEC // 1.8 1-* NW RECNO FROM" X2D(F800) "D2X NW.4
> > RIGHT a:
> > >
> > > > > > 6.3 ."
> > >
> > > > > >
> > >
> > > > > >   "IF a==/MOD/ THEN",
> > >
> > > > > >
> > >
> > > > > > "/C/ NW",
> > >
> > > > > >
> > >
> > > > > >   "ELSE",
> > >
> > > > > >
> > >
> > > > > > "IF a==/MVS/ THEN",
> > >
> > > > > >
> > >
> > > > > >   "/C/ NW",
> > >
> > > > > >
> > >
> > > > > > "ELSE",
> > >
> > > > > >
> > >
> > > > > >   "/R/ NW",
> > >
> > > > > >
> > >
> > > > > > "ENDIF",
> > >
> >

Re: [CMS-PIPELINES] FW: Suggestion: Null Strings

[Hobart Spitz]

Trying again, without the formatting.

(John, not sure if you got this.)

As we know, to embed a value that could include any character we use “…
x”c2x(UserInput)”…”.



If the value could also be an null string, it’s a bit harder.


“… x”PipStr(UserInput)”…”

...



PipStr:  if arg(1) == “” then return “//” else return “x”c2x(arg(1))



My suggestion to address this has some possible solutions:



· Support null hex strings:
   x/1234ff/, where / is limited to special characters (perhaps), and which
could also allow REXX style blanks:  x/12 34 ff/

  and/or x1234ff[x], where the trailing x is optional unless the string
is null,
  or just allow x by itself to be a null string.

· Support a var string specification:
   “locate var Fred [tracking]”, which avoids converting something to hex,
just to convert it back, and, with tracking, allows, the value
to vary as records are processed.


I think any of these could be fit into the existing syntax without conflict.


Avoiding the redundant conversion may be more compelling, if harder.



Just my two cents.


-- 
OREXXMan

[CMS-PIPELINES] Fwd: FW: Suggestion: Null Strings

[Hobart Spitz]

(John, not sure if you got this.)

As we know, to embed a value that could include any character we use “…
x”c2x(UserInput)”…”.



If the value could also be an null string, it’s a bit harder.



*PipStr:  if arg(1) == “” then return “//” else return “x”c2x(arg(1))*



My suggestion has some possible solutions:



· Support null hex strings:
*   x/1234ff/*, where / is limited to special characters (perhaps), and
which could also allow REXX style blanks:  *x/12 34 ff/*
  and/or *x1234ff[x]*, where the trailing x is optional unless the
string is null,
  or just allow *x* by itself to be a null string.

· Support a var string specification:
*   “locate var Fred [tracking]”*, which avoids converting something to
hex, just to convert it back, and, with *tracking*, allows, the
value to vary as records are processed.

Avoiding the redundant conversion may be more compelling, if harder.



I think any of these could be fit into the existing syntax without conflict.



Just my two cents.



-- 
OREXXMan

Re: [CMS-PIPELINES] FTP REXX

[Hobart Spitz]

ker()  , /* Post-processor*/
>xlata2e   , /* tranlate ASCII-EBCDIC?
> */
>'| s:' ftp 'DETECT0'  , /* John - How did I even come up with
> this?? */
>'| *.out.0:', /* output data
> */
>tabla2e  , /* translate table input?
>  */
>'\ m:'   , /* output data
> */
>'| count bytes', /* waits till EoF*/
>'| var n'  , /* save byte count
>   */
>'| i:'  , /* close gate to stop
> pipe   */
>'\ s:'  , /* John (fanout of sorts??) output to detect no more
> output */
>'| i:'  , /* close gate to stop
> pipe   */
> copies('\ m:', /* postprocessed output copy */
> ...
>...
>
> At the very top of the entire Rexx stage/program:
>
> if Arg(1) = 'DETECT0' Then Call DETECT_NOMORE_OUTPUT
>
> A hokie (but heck, I'm an Okie from Oklahoma) sub-routine at the end of
> the program:
>
> /**/
> /* Detect_NoMore_Output: If no more outputting, possibly from a   */
> /*   TAKE nnn stage downstream or something, then Sever input and end.*/
> /**/
> DETECT_NOMORE_OUTPUT:
>  Do Forever
>   'CALLPIPE *: | TAKE 1 | *:', /* An arbitrary choice to
> pause briefly */
>   'PEEKTO RECORD'  , /*   after 10K
> records and use a PEEKTO */
>   If rc ¬= 0 Then Leave
>   'STREAMSTATE OUTPUT 0'
>   If WORDPOS(rc,'-4 12') > 0 Then Do
>'SEVER INPUT'
>'CALLPIPE LITERAL Output Disconnected| *.OUTPUT.1:'
>Leave
>   End
>  End
>  Exit
>
> Other than those two changes, made a year and a half ago, I have used
> FTP_REXX thousands of times now, reading and filtering/manipulating
> countless hundreds of millions of MVS records by now, with no other
> modifications since.
>
> Keep in mind that I had no interest in trying to read any pages/data from
> external (to our company) sites.
>
> I wanted very specifically a solution to the way I was FTPing HUGE MVS
> datasets to VM, waiting for the entire file to be transferred, before I
> could even begin to start using built-in stages or writing Rexx/pipe stages
> to process the data.
>
> For my purpose, I have been a happy camper with FTP_REXX, which definitely
> makes my life easier...
>
> John
>
>
> -Original Message-
> From: CMSTSO Pipelines Discussion List [mailto:CMS-PIPELINES@VM.MARIST.EDU]
> On Behalf Of Hobart Spitz
> Sent: Sunday, July 07, 2013 9:18 AM
> To: CMS-PIPELINES@VM.MARIST.EDU
> Subject: Re: FTP REXX
>
> John;
>
> Thanks.  This is great info.  Is there any chance you could upload or post
> the change for a disconnected output stream (and anything else you think is
> useful)?
>
> Thanks.
>
> - Hobart
>
>
> On Sun, Jul 7, 2013 at 10:24 AM, Larson, John E. 
> wrote:
>
> > I put out a similar query about a year ago, and was told that this was
> > very workable.
> >
> > I took me 1-2 weeks (difficult to find time) to make some minor
> > internal changes that were required to make it work in our specific
> > environment with our unique firewalls and such.
> >
> > But now that I have it working I love it and wanted this for a long time.
> >
> > No longer to I have to transfer 10 - 100 million record files from MVS
> > to VM (using a full pack mod 9 available to me) so that I can then run
> > my pipe filter against the file to extract the thousand or whatever
> records.
> >
> > Simply 'PIPE FTP host mvs_dsn | filter | > final file b'
> >
> > And a real beauty is I don't have to bother with FILEAID or other jobs
> > if I just want the first thousand records for analysis, simply 'PIPE
> > FTP host mvs_dsn '| TAKE 1000 | ...
> > However, I seem to recall that I had to trace the FTP rexx code and
> > make a change to make it exit when it detected the output stream
> > wasn't connected any longer ... pretty sure I had to do this...
> >
> > And yes, I use it in a multi-stream pipe and have one instance pulling
> > a DSN from one MVS system and another instance running simultaneously
> > pulling a DSN from a separate MVS system, merging and processing the
> > two DSNs as one, with filters, I was SO HAPPY when this was suddenly
> working.
> >
> > I do so much MVS --> VM FTP work in the course of a work day that I
> > wished for an FTP rexx stage for some years, finally dove into the one
> > I'm sure you're referring to and have been enjoying it ever since.
> >
> > John
> >
> >
> > -Original Message-
> > From: CMSTSO Pipelines Discussion List
> > [mailto:CMS-PIPELINES@VM.MARIST.EDU]
> > On Behalf Of Hobart Spitz
> > Sent: Sunday, July 07, 2013 4:46 AM
> > To: CMS-PIPELINES@VM.MARIST.EDU
> > Subject: FTP REXX
> >
> > Does anyone know the status of FTP REXX?  It's marked as new on the
> > Pipes web page, but the doc and change history dates are more than 10
> years old.
> >
> > Is anyone using it?  Does anyone know if it still works?
> >
> > Can FTP REXX run under PipeServ?  Can multiple instances run
> > successfully at the same time?
> >
> > I'd be happy to get educated guesses in the absence of firm answers.
> >
> > Thanks all.
> >
> > --
> > OREXXMan
> >
>
>
>
> --
> OREXXMan
>



-- 
OREXXMan

Re: [CMS-PIPELINES] FTP REXX

[Hobart Spitz]

John;

Thanks.  This is great info.  Is there any chance you could upload or post
the change for a disconnected output stream (and anything else you think is
useful)?

Thanks.

- Hobart


On Sun, Jul 7, 2013 at 10:24 AM, Larson, John E.  wrote:

> I put out a similar query about a year ago, and was told that this was
> very workable.
>
> I took me 1-2 weeks (difficult to find time) to make some minor internal
> changes that were required to make it work in our specific environment with
> our unique firewalls and such.
>
> But now that I have it working I love it and wanted this for a long time.
>
> No longer to I have to transfer 10 - 100 million record files from MVS to
> VM (using a full pack mod 9 available to me) so that I can then run my pipe
> filter against the file to extract the thousand or whatever records.
>
> Simply 'PIPE FTP host mvs_dsn | filter | > final file b'
>
> And a real beauty is I don't have to bother with FILEAID or other jobs if
> I just want the first thousand records for analysis, simply 'PIPE FTP host
> mvs_dsn '| TAKE 1000 | ...
> However, I seem to recall that I had to trace the FTP rexx code and make a
> change to make it exit when it detected the output stream wasn't connected
> any longer ... pretty sure I had to do this...
>
> And yes, I use it in a multi-stream pipe and have one instance pulling a
> DSN from one MVS system and another instance running simultaneously pulling
> a DSN from a separate MVS system, merging and processing the two DSNs as
> one, with filters, I was SO HAPPY when this was suddenly working.
>
> I do so much MVS --> VM FTP work in the course of a work day that I wished
> for an FTP rexx stage for some years, finally dove into the one I'm sure
> you're referring to and have been enjoying it ever since.
>
> John
>
>
> -Original Message-
> From: CMSTSO Pipelines Discussion List [mailto:CMS-PIPELINES@VM.MARIST.EDU]
> On Behalf Of Hobart Spitz
> Sent: Sunday, July 07, 2013 4:46 AM
> To: CMS-PIPELINES@VM.MARIST.EDU
> Subject: FTP REXX
>
> Does anyone know the status of FTP REXX?  It's marked as new on the Pipes
> web page, but the doc and change history dates are more than 10 years old.
>
> Is anyone using it?  Does anyone know if it still works?
>
> Can FTP REXX run under PipeServ?  Can multiple instances run successfully
> at the same time?
>
> I'd be happy to get educated guesses in the absence of firm answers.
>
> Thanks all.
>
> --
> OREXXMan
>



--
OREXXMan

[CMS-PIPELINES] FTP REXX

[Hobart Spitz]

Does anyone know the status of FTP REXX?  It's marked as new on the Pipes
web page, but the doc and change history dates are more than 10 years old.

Is anyone using it?  Does anyone know if it still works?

Can FTP REXX run under PipeServ?  Can multiple instances run successfully
at the same time?

I'd be happy to get educated guesses in the absence of firm answers.

Thanks all.

--
OREXXMan