I thought I'd do a follow up on this problem for anyone who might be interested and who may have a similar setup to the one we do. I was fairly confident that VM:Operator wasn't to blame for the problem but contacted CA anyway since the only error codes we ever got were from VM:Operator. After CA and I discounted him as the culprit I decided to focus on TCPIP as I always thought he was to blame. After reading through both the Planning and Configuration manual and the User's Guide I zeroed in on the POOLSIZE part of the PROFILE TCPIP. After issuing the NETSTAT POOLSIZE command I noticed that the system was trying to use SmallDataBuffer which we had set to zero in the #Alloc column. I say the system was trying to use it only because there was a "1" in the Permit Size column. This was without anyone being logged on via TELNET. At any rate, setting the #Alloc to 10 on my test system seems to have fixed the problem. Logging on multiple users via TELNET and issuing NETSTAT POOLSIZE shows that the numbers in all the other columns do indeed change depending on the number of remote logons I have. For any production machines the #Alloc will be set to 100 as they have many more users. This was never a problem on our 43XX or 9221 systems nor our PC Server based P/390s but for some reason, the Integrated Servers we have are a rather sensitive lot. Either that or PCOMM is more sensitive than Communications Manager/2 but my money is still on TCPIP. One day I hope to be able to work on more modern systems but for now I'm stuck trying to support unsupported hardware and software.
Karl Severson
Raytheon Company
El Segundo, California
