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
