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

2018-01-12 Thread Miguel Soltero Diaz
thanks guys for your helpful comments. I did struggle with this for a while. Certainly I need to read more... :) This has been highly edifying for myself. Thanks again

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

2018-01-11 Thread Alan Altmark
-PIPELINES] getting the RC from third party commands Whether the OP really needs to include asynchronous messages from a service machine or not in the command output, this is a valid scenario that should be addressed in general and examples in the relevant book; think, e.g., DIRMAINT.

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

2018-01-11 Thread John P. Hartmann
Whether the OP really needs to include asynchronous messages from a service machine or not in the command output, this is a valid scenario that should be addressed in general and examples in the relevant book; think, e.g., DIRMAINT.

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

2018-01-11 Thread Rob van der Heij
On 11 January 2018 at 22:57, Hobart Spitz wrote: > 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? You could, but it probably does not give you much beyond a RE

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

2018-01-11 Thread Rob van der Heij
On 11 January 2018 at 23:34, Michael Harding wrote: > No, the command and cms stages are documented to write all command output > before writing the return code to the secondary stream, which is easily > verified. > The stall occurs because command was stuck writing the return code before > it po

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

2018-01-11 Thread Michael Harding
No, the command and cms stages are documented to write all command output before writing the return code to the secondary stream, which is easily verified. The stall occurs because command was stuck writing the return code before it posted eof on its primary. A simple elastic stage on the second st

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

2018-01-11 Thread 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 n

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

2018-01-11 Thread Rob van der Heij
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 "co

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

2018-01-11 Thread Miguel Soltero Diaz
Thanks Glen, the last one is at least getting me the rc. I just need to add it now to the REPT Thank you ...

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

2018-01-11 Thread Miguel Soltero Diaz
thanks Alan, my reticence to follow your advice is because I see it only for one command only. Here is what we need. We want to verify access for a number of users. ranging from just a few to all users with access to the LPAR. that include service IDs too.. Access will be verified in a number o

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

2018-01-11 Thread Alan Altmark
On Thursday, 01/11/2018 at 06:00 GMT, Miguel Soltero Diaz wrote: > Thank you guys for your efforts. > > Alan, I tried using !STARMSG *MSG', > and the response was sent to console. > That is why I used STARTMSG *MSGALL. > That way at least the response is sent to the REPT. > > Michael, > I am foll

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

2018-01-11 Thread Miguel Soltero Diaz
Forgot to append the DUMP that is showing every time I execute it.. These are the ones for the last two times I have executed it Pipeline stall 11 Jan 2018 09:40:46 5785-RAC CMS Pipelines level 1.1.12 sublevel 14 ("000E"x) From z/VM 6.4.

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

2018-01-11 Thread Miguel Soltero Diaz
Thank you guys for your efforts. Alan, I tried using !STARMSG *MSG', and the response was sent to console. That is why I used STARTMSG *MSGALL. That way at least the response is sent to the REPT. Michael, I am following your advice, and I am not able to past SPECS. Here is VMSECURE when I iss

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

2018-01-10 Thread Alan Altmark
On Wednesday, 01/10/2018 at 10:30 GMT, Miguel Soltero Diaz wrote: > hello guys, > I am trying to execute a VMSECURE command and capture the return code of that > command. So far, I am able to get the results from the command but not the rc. > Is there a way to capture the rc from that command?

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

2018-01-10 Thread Glenn Knickerbocker
On 1/10/2018 5:28 PM, Miguel Soltero Diaz wrote: > When the command is executed I get > whatever results from the command and ... > Ready(00024); T=0.01/0.01 14:18:19 Wait, when and where do you get that? In your output file? Typed to the console when you run your exec? Typed to the console w

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

2018-01-10 Thread Michael Harding
Why not just run the VMSECURE module from the COMMAND stage? It knows how to communicate with the VMSECURE machine, displays the messages and sets the return code, both of which COMMAND will capture. For example... 'pipe (stagesep ! endchar ?)', ' Var vmcmd', /* assumed to be "vmsedure" *

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

2018-01-10 Thread Miguel Soltero Diaz
hello guys, I am trying to execute a VMSECURE command and capture the return code of that command. So far, I am able to get the results from the command but not the rc. Is there a way to capture the rc from that command? is this something I should be talking to CA instead? This is the way I am ex