Re: Holding Console
Thanks for the replies. No, I'm not going into VM to muck around there, home mortage, college loans to pay...can afford to loose job. Well when OP1 (using PROP) is in hold mode then command submitted to the Operator from else where won't get executed until the hold is cleared. Get a message back saying something like there is console input waiting and nothing get thru until the hold is cleared. No longer important because we found a work around but still of interest. Alan Altmark [EMAIL PROTECTED] 7/18/2008 4:47 PM On Friday, 07/18/2008 at 03:48 EDT, Howard Rifkind [EMAIL PROTECTED] wrote: Does anyone know of a way to tell if a users console is being held 'HOLDING' at the bottom right of the screen. I would like to find this out from an exec procedure. The general answer is no unless you are willing to risk looking in CP control blocks as Ronald suggests. Can you explain why this is important? Perhaps there is another solution to your problem that doesn't require knowing that information. Alan Altmark z/VM Development IBM Endicott _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Holding Console
On OP1: CP TERM HOLD OFF (turns of HOLDING and just uses ...MORE) And: CP TERM MORE 0 0 if you want the screen to clear immediately without a ...MORE Scott Rohling On Mon, Jul 21, 2008 at 9:09 AM, Howard Rifkind [EMAIL PROTECTED] wrote: Thanks for the replies. No, I'm not going into VM to muck around there, home mortage, college loans to pay...can afford to loose job. Well when OP1 (using PROP) is in hold mode then command submitted to the Operator from else where won't get executed until the hold is cleared. Get a message back saying something like there is console input waiting and nothing get thru until the hold is cleared. No longer important because we found a work around but still of interest. Alan Altmark [EMAIL PROTECTED] 7/18/2008 4:47 PM On Friday, 07/18/2008 at 03:48 EDT, Howard Rifkind [EMAIL PROTECTED] wrote: Does anyone know of a way to tell if a users console is being held 'HOLDING' at the bottom right of the screen. I would like to find this out from an exec procedure. The general answer is no unless you are willing to risk looking in CP control blocks as Ronald suggests. Can you explain why this is important? Perhaps there is another solution to your problem that doesn't require knowing that information. Alan Altmark z/VM Development IBM Endicott _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash.
Re: Holding Console
On Mon, Jul 21, 2008 at 5:09 PM, Howard Rifkind [EMAIL PROTECTED] wrote: Well when OP1 (using PROP) is in hold mode then command submitted to the Operator from else where won't get executed until the hold is cleared. Get a message back saying something like there is console input waiting and nothing get thru until the hold is cleared. But PROP should run disconnected and you must route the relevant messages to the logical operator. Then there may still be a problem that the logical operator fails to clear the screen and does not see new messages, but it does not prevent PROP from doing the right things. Rob
Re: Holding Console
Oh, but now you shed some extra light. You write: something like there is console input waiting This is not really related to TERM HOLD OFF or MORE x y It means someone sent a console command to the user, and the user didn't read it yet. In case of PROP it means CMS didn't read it yet, often a signal that CMS is really sick. Unless you use CP SEND and send consecutive commands too quickly. Do not code 'CP SEND xyz command1' 'CP SEND xyz command2' 'CP SEND xyz command3' But 'CP SEND xyz command1' 'CP SLEEP 1 SEC' 'CP SEND xyz command2' 'CP SLEEP 1 SEC' 'CP SEND xyz command3' Furthermore: to send commands to a PROP running user, one should not use CP SEND, but MESSAGE: CP M OPERATOR CMD command If memory serves well, the only command PROP accepts at its console is STOP. 2008/7/21 Howard Rifkind [EMAIL PROTECTED]: Thanks for the replies. No, I'm not going into VM to muck around there, home mortage, college loans to pay...can afford to loose job. Well when OP1 (using PROP) is in hold mode then command submitted to the Operator from else where won't get executed until the hold is cleared. Get a message back saying something like there is console input waiting and nothing get thru until the hold is cleared. No longer important because we found a work around but still of interest. Alan Altmark [EMAIL PROTECTED] 7/18/2008 4:47 PM On Friday, 07/18/2008 at 03:48 EDT, Howard Rifkind [EMAIL PROTECTED] wrote: Does anyone know of a way to tell if a users console is being held 'HOLDING' at the bottom right of the screen. I would like to find this out from an exec procedure. The general answer is no unless you are willing to risk looking in CP control blocks as Ronald suggests. Can you explain why this is important? Perhaps there is another solution to your problem that doesn't require knowing that information. Alan Altmark z/VM Development IBM Endicott _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- Kris Buelens, IBM Belgium, VM customer support
Re: Holding Console
On Monday, 07/21/2008 at 11:11 EDT, Howard Rifkind [EMAIL PROTECTED] wrote: Thanks for the replies. No, I'm not going into VM to muck around there, home mortage, college loans to pay...can afford to loose job. Well when OP1 (using PROP) is in hold mode then command submitted to the Operator from else where won't get executed until the hold is cleared. Get a message back saying something like there is console input waiting and nothing get thru until the hold is cleared. No longer important because we found a work around but still of interest. This is a bit confusing, Howard. PROP is running in OPERATOR, started by OPERATOR's PROFILE EXEC and it should be running disconnected (in fact, that should be the setting in SYSTEM CONFIG). The logical operator should be OP1, logged on and monitored by wetware (people). And to issue commands to OPERATOR, use MSG, not SEND. You want OPERATOR to pick up the command and process it through the RTABLE. If you use SEND, it's like typing on the console and the only interesting command is STOP. Alan Altmark z/VM Development IBM Endicott
Re: Holding Console
On Monday, 07/21/2008 at 11:35 EDT, Kris Buelens [EMAIL PROTECTED] wrote: Oh, but now you shed some extra light. You write: something like there is console input waiting This is not really related to TERM HOLD OFF or MORE x y It means someone sent a console command to the user, and the user didn't read it yet. In case of PROP it means CMS didn't read it yet, often a signal that CMS is really sick. Unless you use CP SEND and send consecutive commands too quickly. Do not code 'CP SEND xyz command1' 'CP SEND xyz command2' 'CP SEND xyz command3' But 'CP SEND xyz command1' 'CP SLEEP 1 SEC' 'CP SEND xyz command2' 'CP SLEEP 1 SEC' 'CP SEND xyz command3' This introduces a two problems, Kris. First, it takes a minimum of 2 seconds to issue those commands. What if you have 20 commands to issue? (You grow old waiting for the exec to run.) Second, you're assuming that the prior command will be read by the guest within 1 second. What if it isn't? Instead, you should react to RC=68 from the SEND. IF you get RC 68, then wait 1 second and try again. Feel free to do that several times. Or you may back off on the time. Wait 1 second, then 2, then 4, If the SEND doesn't work within a reasonable amount of time then abandon the sequence and declare defeat. But this way the exec will run as quickly as possible, yet be tolerant of a sluggish guest. Alan Altmark z/VM Development IBM Endicott
Re: Holding Console
I know Alan (as you probably know), but I wanted to keep things simple. Now my turn to throw stones (or pebbles) - ain't it about time CP SLEEP allows shorter periods than 1 second? (PIPE DELAY can be used to sleep shorter) - CP SEND uses the same RC to signal almost all problems it can get - So scanning the message text then ? HELP CP SEND (ERRORS doesn't even tell which errrors can cause RC 68 here's a list from one of my execs (but there might be more) RECEIVER IS NOT DISCONNECTED RECEIVER HAS NOT AUTHORIZED SENDER RECEIVER HAS NO VIRTUAL CONSOLE RECEIVER HAS CONSOLE INPUT WAITING And, I think chances are high that one needs a short while anyhow: when I issue CP SEND, CP has to dispatch the target machine so it can eat the command just sent before my user sends the next command. Is CP SEND that clever? 2008/7/21 Alan Altmark [EMAIL PROTECTED]: On Monday, 07/21/2008 at 11:35 EDT, Kris Buelens [EMAIL PROTECTED] wrote: Oh, but now you shed some extra light. You write: something like there is console input waiting This is not really related to TERM HOLD OFF or MORE x y It means someone sent a console command to the user, and the user didn't read it yet. In case of PROP it means CMS didn't read it yet, often a signal that CMS is really sick. Unless you use CP SEND and send consecutive commands too quickly. Do not code 'CP SEND xyz command1' 'CP SEND xyz command2' 'CP SEND xyz command3' But 'CP SEND xyz command1' 'CP SLEEP 1 SEC' 'CP SEND xyz command2' 'CP SLEEP 1 SEC' 'CP SEND xyz command3' This introduces a two problems, Kris. First, it takes a minimum of 2 seconds to issue those commands. What if you have 20 commands to issue? (You grow old waiting for the exec to run.) Second, you're assuming that the prior command will be read by the guest within 1 second. What if it isn't? Instead, you should react to RC=68 from the SEND. IF you get RC 68, then wait 1 second and try again. Feel free to do that several times. Or you may back off on the time. Wait 1 second, then 2, then 4, If the SEND doesn't work within a reasonable amount of time then abandon the sequence and declare defeat. But this way the exec will run as quickly as possible, yet be tolerant of a sluggish guest. Alan Altmark z/VM Development IBM Endicott -- Kris Buelens, IBM Belgium, VM customer support
Re: Holding Console
On Monday, 07/21/2008 at 12:36 EDT, Kris Buelens [EMAIL PROTECTED] wrote: I know Alan (as you probably know), but I wanted to keep things simple. Now my turn to throw stones (or pebbles) - ain't it about time CP SLEEP allows shorter periods than 1 second? (PIPE DELAY can be used to sleep shorter) Since PIPE DELAY can sleep for a shorter time, why update SLEEP? Remember, too, that SLEEP stops the virtual machine. Interrupt handlers won't run. Nothing. So, particularly if you have something like WAKEUP trapping messages, SLEEP is a bad idea (however convenient). - CP SEND uses the same RC to signal almost all problems it can get - So scanning the message text then ? Yes. That's unfortunate, but that's the way it is and I don't expect it will change. HELP CP SEND (ERRORS doesn't even tell which errrors can cause RC 68 here's a list from one of my execs (but there might be more) RECEIVER IS NOT DISCONNECTED RECEIVER HAS NOT AUTHORIZED SENDER RECEIVER HAS NO VIRTUAL CONSOLE RECEIVER HAS CONSOLE INPUT WAITING I see them on my system. And, I think chances are high that one needs a short while anyhow: when I issue CP SEND, CP has to dispatch the target machine so it can eat the command just sent before my user sends the next command. Is CP SEND that clever? There is actually a lot of time between commands. Remember, the thing that finishes fast is the DIAGNOSE 8. You still have to go through the return logic to the exec, interpret the next phrase, call the CMS command interpreter, and execute the next DIAGNOSE 8. That is plenty of time for the other guest to run. When your guest issues a DIAGNOSE, it comes to a stop. To get you restarted again, you have to be scheduled and dispatched yourself. Alan Altmark z/VM Development IBM Endicott
Re: Holding Console
Though we already concluded the OP was on the wrong track, it is not hard to write a pipeline stage that retries the CP SEND command a few times with minimal delay when the recipient is in CF. But since you don't get the output, it is not really suitable for reliable communication. Rob
Re: Holding Console
Howard, You can look at the RDEVSFLG field in the RDEV block. It is pointed to via VMDRTEM field in the user's VMDBK. See http://www.vm.ibm.com/pubs/cp530/VMDBK.HTML and http://www.vm.ibm.com/pubs/cp530/RDEV.HTML Ronald van der Laan
Re: Holding Console
On Friday, 07/18/2008 at 03:48 EDT, Howard Rifkind [EMAIL PROTECTED] wrote: Does anyone know of a way to tell if a users console is being held 'HOLDING' at the bottom right of the screen. I would like to find this out from an exec procedure. The general answer is no unless you are willing to risk looking in CP control blocks as Ronald suggests. Can you explain why this is important? Perhaps there is another solution to your problem that doesn't require knowing that information. Alan Altmark z/VM Development IBM Endicott
