> 1. Does IUCV infrastructure overhead specifically associated with number > of > connections become prohibitive at some well known point?
There is a limit to the maximum number of connections (a parm on the IUCV statement in the directory entry; I think the max value for that parm is 64K, but check your docs -- I don't have manuals with me at the moment). > 2. Has anyone had experience with an application having a high IUCV > connection count like this? If so, what was that experience? Probably the best example I know of for an application that uses a lot of IUCV connections is the VM TCPIP stack (yes, I know there is a lot of VMCF too, but it also uses IUCV.). It seems to be fairly stable and scales well. At a past employer, we had a few applications that regularly had several thousand IUCV connections open and active simultaneously with no connection state related problems. The key problem with performance tuning for those applications was supplying sufficient virtual storage to provide suitable buffers for the connections, and the need to dispatch each endpoint every time you needed to send and respond to a message. Those two things were a lot bigger hit than the IUCV connection and session management processing. Something also to think about is the additional hit of dispatching and routing messages between VM images if you are planning on permitting distributed IUCV (a good idea). That's going to mean some additional work needed from CP to do ISFC, or asking CP to dispatch TSAF or AVS or IPGATE to get the message frame over to the other system. That can be significant.
