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
