Re: REXX EXEC - Trapping console messages w/SCIF
On Wed, 28 Feb 2007 10:28:07 -0600, Dave Hansen [EMAIL PROTECTED] wrote: Hello group, I found out SCIF changes things. I logon and I normally don't get an y traffic until I send something to the other virtual machine I am a secondary console for and then I get a response. Without SCIF I can get my messag e in REXX by issuing a command and then doing a PULL. However with SCIF I get a VM READ as I watch the message being returned while I am tracing the exec. I have used wakeup before and then it captures the 'activity' by return code. I could spool my console and close it, but then I probably won't be able to trap the spoolid. Yes, I could set something unique in the spool name or type. But this probably isn't the best solution. Any ideas? Thank you, Dave H. = You said, I could spool my console and close it, but then I probably won't be able to trap the spoolid. Actually, that's quite simple (bits extracted from a larger EXEC): /* Sample output from CP SPOOL CONSOLE CLOSE TO * KEEP RDR FILE 5953 SENT FROM ACKERMAN CON WAS 5953 RECS 0227 CPY 001 T HOLD */ 'PIPE cp SPOOL CONSOLE CLOSE TO * KEEP', '|append literal ', '|var spooldesc' parse var spooldesc 'FILE' spid . 'RECS' recs . 'EXEC RECEIVE' spid ofile '(REPLACE'
REXX EXEC - Trapping console messages w/SCIF
Hello group, I found out SCIF changes things. I logon and I normally don't get any traffic until I send something to the other virtual machine I am a secondary console for and then I get a response. Without SCIF I can get my message in REXX by issuing a command and then doing a PULL. However with SCIF I get a VM READ as I watch the message being returned while I am tracing the exec. I have used wakeup before and then it captures the 'activity' by return code. I could spool my console and close it, but then I probably won't be able to trap the spoolid. Yes, I could set something unique in the spool name or type. But this probably isn't the best solution. Any ideas? Thank you, Dave H.
Re: REXX EXEC - Trapping console messages w/SCIF
SCIF comes in as asynchronous CP data. You can use the PIPE STARMSG stage, and the delay stage. you can play around with the following sorts of things: 'PIPE (Endchar \)', 'STARMSG CP SEND CP TCPIP Q T ', '| CONSOLE', '\', 'LITERAL +2', '| DELAY', '| PIPESTOP' This traps the results of the command sent to TCPIP within two seconds. OF course there are some more elaborate schemes with pipes if you wanted to end the wait sooner. See the help for PIPE PIPESTOP. It has an example of trapping RSCS output, works similar although it is of a different type. David -Original Message- From: The IBM z/VM Operating System on behalf of Dave Hansen Sent: Wed 2/28/2007 11:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] REXX EXEC - Trapping console messages w/SCIF Hello group, I found out SCIF changes things. I logon and I normally don't get any traffic until I send something to the other virtual machine I am a secondary console for and then I get a response. Without SCIF I can get my message in REXX by issuing a command and then doing a PULL. However with SCIF I get a VM READ as I watch the message being returned while I am tracing the exec. I have used wakeup before and then it captures the 'activity' by return code. I could spool my console and close it, but then I probably won't be able to trap the spoolid. Yes, I could set something unique in the spool name or type. But this probably isn't the best solution. Any ideas? Thank you, Dave H.
Re: REXX EXEC - Trapping console messages w/SCIF
You need to issue WAKEUP +0 (IUCVMSG before you send the command to the primary machine. Then in your REXX exec, loop on WAKEUP +xx (IUCVMSG while rc=5 At the end, issue WALEUP RESET The hard thing is knowing when the primary machine has fisched sending its response (i.e. having a value for +nn) You can also use PIPE STARMSG as alternative to WAKEUP. 2007/2/28, Dave Hansen [EMAIL PROTECTED]: Hello group, I found out SCIF changes things. I logon and I normally don't get any traffic until I send something to the other virtual machine I am a secondary console for and then I get a response. Without SCIF I can get my message in REXX by issuing a command and then doing a PULL. However with SCIF I get a VM READ as I watch the message being returned while I am tracing the exec. I have used wakeup before and then it captures the 'activity' by return code. I could spool my console and close it, but then I probably won't be able to trap the spoolid. Yes, I could set something unique in the spool name or type. But this probably isn't the best solution. Any ideas? Thank you, Dave H. -- Kris Buelens, IBM Belgium, VM customer support
Re: REXX EXEC - Trapping console messages w/SCIF
Hello, I am still having trouble with my SCIF exec. Here it is: /* rexx */ trace r 'set msg iucv' 'pipe (endchar \)', '|starmsg CP Q MUDLAKE', '| console', '\', 'literal +2', '| delay', '| pipestop' parse upper pull input '-' var if var = 'dsc' then nop else do say 'mudlake not logged on' exit 1369 end 'set msg on' Here is it in action: 12:46:27 jimmy 12:46:27 3 *-* 'set msg iucv' 12:46:27 set msg iucv 12:46:27 4 *-* 'pipe (endchar \)','|starmsg CP Q MUDLAKE','| console','\',' literal + 12:46:27 2','| delay','| pipestop' 12:46:27 pipe (endchar \) |starmsg CP Q MUDLAKE | console \ litera l +2 | de 12:46:27 lay | pipestop 12:46:27 00: MUDLAKE - DSC 12:46:29 11 *-* parse upper pull input '-' var If I change the delay to 4 seconds the DSC message always has the same time as the pipestop. The delay is how long before the parse is executed. The book says when pipestop reads an input record, it ends the stages. Am I ending the stages? It looks like the DSC message isn't PULLable because I get placed in a VM READ. Some SCIF stuff: 12:52:09 cp send cp mudlake q secuser 12:52:09 MUDLAKE : SECONDARY USER LNXADMIN IS LOGGED ON 12:52:09 Ready; T=0.01/0.01 12:52:09 12:52:11 id 12:52:11 LNXADMIN AT ZVM3 VIA *02/28/07 12:52:11 CST WEDNESDAY 12:52:11 Ready; T=0.01/0.01 12:52:11 Thanks in advance, Dave H.
Re: REXX EXEC - Trapping console messages w/SCIF
parse upper pull input '-' var results in a vm read 'cause the cms stack is empty. You didn't place any data in the stack. I think you should use the VAR stage, not mess with the CMS stack. But if you insist you can use the PIPE STACK stage to place piped output into the CMS stack. CP Q MUDLAKE is not being handled by your console stage. It is from the CP command you issued on your STARMSG stage directed to CP, but it is not output in the pipe output stream. Only data captured by STARMSG will be output in the pipe stream. You could alter the pipe to use the VAR stage to place the piped data into a variable. /**/ 'CP SET MSG IUCV' 'PIPE (Endchar \)', 'STARMSG CP SEND CP TCPIP Q USERID', '| VAR CPOUT ', '\', 'LITERAL +2', '| DELAY', '| PIPESTOP' say 'cpout:' cpout exit ... getem cpout: 0008TCPIP TCPIP : TCPIPAT EGESSEB1 Ready; T=0.01/0.01 14:32:51 -Original Message- From: The IBM z/VM Operating System on behalf of Dave Hansen Sent: Wed 2/28/2007 1:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] REXX EXEC - Trapping console messages w/SCIF Hello, I am still having trouble with my SCIF exec. Here it is: /* rexx */ trace r 'set msg iucv' 'pipe (endchar \)', '|starmsg CP Q MUDLAKE', '| console', '\', 'literal +2', '| delay', '| pipestop' parse upper pull input '-' var if var = 'dsc' then nop else do say 'mudlake not logged on' exit 1369 end 'set msg on' Here is it in action: 12:46:27 jimmy 12:46:27 3 *-* 'set msg iucv' 12:46:27 set msg iucv 12:46:27 4 *-* 'pipe (endchar \)','|starmsg CP Q MUDLAKE','| console','\',' literal + 12:46:27 2','| delay','| pipestop' 12:46:27 pipe (endchar \) |starmsg CP Q MUDLAKE | console \ litera l +2 | de 12:46:27 lay | pipestop 12:46:27 00: MUDLAKE - DSC 12:46:29 11 *-* parse upper pull input '-' var If I change the delay to 4 seconds the DSC message always has the same time as the pipestop. The delay is how long before the parse is executed. The book says when pipestop reads an input record, it ends the stages. Am I ending the stages? It looks like the DSC message isn't PULLable because I get placed in a VM READ. Some SCIF stuff: 12:52:09 cp send cp mudlake q secuser 12:52:09 MUDLAKE : SECONDARY USER LNXADMIN IS LOGGED ON 12:52:09 Ready; T=0.01/0.01 12:52:09 12:52:11 id 12:52:11 LNXADMIN AT ZVM3 VIA *02/28/07 12:52:11 CST WEDNESDAY 12:52:11 Ready; T=0.01/0.01 12:52:11 Thanks in advance, Dave H.
Re: REXX EXEC - Trapping console messages w/SCIF
David and Kris, Thank you for your help. I trap to a stem and I'm back to figuring out my 'logic'. It's been a while since a wrote a pipe. I saw they can still be written in EXEC2. Maybe VMFOPT still works too. Thanks again, Dave H. Hennepin County
Re: REXX EXEC - Trapping console messages w/SCIF
2007/2/28, Dave Hansen [EMAIL PROTECTED]: David and Kris, Thank you for your help. I trap to a stem and I'm back to figuring out my 'logic'. It's been a while since a wrote a pipe. I saw they can still be written in EXEC2. Maybe VMFOPT still works too. Thanks again, Dave H. Hennepin County TRACE a = STRING OF Writing in B = CONCAT OF a BLANK EXEC2, c = STRING OF isn't that D = CONCAT OF B BLANK c BLANK something of TYPE D the past? (or something like that, my EXEC2 isn't as good anymore as 20 years ago). -- Kris Buelens, IBM Belgium, VM customer support
