On Wednesday, 08/27/2008 at 12:09 EDT, "Gary M. Dennis" <[EMAIL PROTECTED]> wrote: > I have included below item 6 from the thread origin and a snippet from John > Baker's response. > > Maybe I should have placed more emphasis on item 6. The server machine is > going to be updating the buffer areas in all the connected client machines. > > Therefore, he server machine needs to know immediately when one of the > guests is quiescent or logged off. IUCV will inform the server when a > connection is severed. The guest machines can set in indicator in an area > monitored by the server to indicate that they have begun a normal closedown > *but* the "fall-off_the page" case is when a machine is logged off and the > server attempts to access the buffers in a machine that no longer exists. > > John made a good argument for temporary IUCV connections. In that case the > best way to make a determination on the active state a diagnose that issues > a query command for the user in question?
I don't understand why you want to use temporary connections. 1. Guest logs on and CMSIUCV CONNECTs to the server 2. The server is aware of the guest's existence. 3. Messages pass back and forth. 4. If the server goes down, the guest will be informed and can periodically try to re-establish communications with the server. 5. If the guest is terminating, it can CMSIUCV SEVER with USERDTA= filled in to indicate a "normal" termination. 6. If the guest just logs off, the sever will be done by CP with no data in the IPUSER field. 7. If you're in the middle of an IUCV SEND or RECEIVE when an IUCV connection is terminated, the issuer will get an error response. 8. If the server goes to sleep, there is a limit on the number of messages that can be queued by each guest. It is called the Message Limit (MSGLIM) and can be set in the directory and/or the applications themselves. 9. If one of the communications partners doesn't want to receive messages, it can issue IUCV QUIESCE and then RESUME when ready. You mention an "area" that is monitored by the server. That sounds like shared memory. When we wrote GCS back in 1983 (wow - was it really that long ago?!?), we used a combination of IUCV (*SIGNAL system service) and shared memory. Your server will need to clean up any trash left by one of the guests if it logs off at "just the wrong time". IUCV can handle hundreds of connections with no problem. APPC/VM (APPCVM macro) is a variant of IUCV and is used by DB2 and SFS. These applications handle thousands of connections. You do not want to issue DIAGNOSE instructions unnecessarily as they serialize the entire virtual machine. That is, the virutal CPUs stop for the duration of the command or diagnose. IUCV instructions, however, are handled at the virtual CPU level. If you have a multithreaded application with multiple virtual CPUs, each CPU can handle IUCV instructions separately. An individual CPU runs the IUCV "instruction", and the other CPUs continue to do whatever they want. Alan Altmark z/VM Development IBM Endicott
