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 <[email protected]> wrote:
> On 11 January 2018 at 20:29, Miguel Soltero Diaz <[email protected]> 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
>
