If you do not have experience with threaded CMS application development, I suggest you read anything but the balance of of this email.
I have an application that runs under CMS and consists of three distinct layers. 1. The top layer is some virtualized x86 OS. 2. The middle layer performs x86 to z translation 3. The base layer is everything else. That includes code fragment storage, aging, retrieval, statistics collection/ push using IUCV, etc. Layer two has been developed in such a way that, without layer three, it simply translates a code fragments to z architecture code, executes that code, then discards the translated fragment. It detects the interface stub for layer three and, if that is present, it takes advantage of the capabilities including prior translation reuse. Layer 3 is multithreaded and is the cause/source of the problem. Whether layer 3 is run with layers 1 and 2 or in standalone test mode the results are the same. First the environment: VM 4.3 Number of processors: 2 Virtual CPUs (from 2 to 6 .. See note below) Now the application from 10,000 feet: Layer three consists of a parent thread that creates 4 additional threads. Each thread is created in a dispatch class that is unique. Routines are not shared between threads. Upon entry into each routine, the preamble is destroyed and restored on exit to trap any potential inadvertent share. Critical fields shared between threads are protected by a compare and swap spin lock. Part of the testing consists of pushing 1WAY IUCV messages from each connected client every 20 milliseconds. The VM directory for each of 4 machines (one server and three clients) defines the machine as an XC mode machine with: CPU 00 BASE CPU 01 As each thread is created it requests either BASE or ANY CPU affinity. BASE affinity is reserved for the parent and IUCV message handler threads . ANY is used for all other threads . Each affinity request receives a normal return code. All this works beautifully for days and millions of messages UNTIL the number of virtual CPUs defined exceed the number of real CPUs assigned to the VM image. When this takes place, everything comes unstuck. By everything I mean everything in CMS. Stack overflow (03FF abend), free storage management failure, all of it. The multitasking application dev guide states that to the extent possible, dispatch classes are assigned to vCPUs and further states that the max number of vCPUs that may be utilized is equal to the number of dispatch classes. Whether the vCPUs are defined in the user directory entry OR they are created dynamically using the CPU Create CMS function, the results are the same. My questions) 1. Has anyone had a similar experience? 2. Is this a known issue with 4.3? Or in more current releases? 3. Although this seems to be telling me no to go there, I¹ve tried but cannot find anything that says ³You¹ll shoot your eye out , kid.² if you define more virtual CPUs than real processors. Anyone know of such a restriction? 4. Is it possible that CMS kernel services don¹t tolerate a situation where the number of virtual CPUs exceeds ³real² processors? Thanks in advance for any insight you might have on this behavior. --. .- .-. -.-- Gary Dennis Mantissa Corporation
