This doesn't completely answer your question, but I was told that because the people writing Multitasking CMS were limited in how much of CMS they were allowed to change, that most traditional system calls are scheduled to the base CPU. Therefore, providing multiple CPUs can actually degrade performance.
Mark Gillis -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Gary M. Dennis Sent: Friday, 11 July 2008 8:14 AM To: IBMVM@LISTSERV.UARK.EDU Subject: CMS Multi-tasking - How is it different from z/OS task management We are attempting to leverage z/VM CMS multi-tasking capabilities for Windows® thread management. We have substantial z/OS experience with regard to task management and serialization so what we are experiencing in a CMS environment doesn¹t fit what we had anticipated. Our test was conducted on a virtual machine for which two CPU¹s are defined. The test program contains CSECTS MAIN and THREAD1. The program is invoked under CMS. CSECT MAIN process 1. Initialization 2. Call VM thread create (referencing THREAD1 CSECT) from within MAIN CSECT in order to create THREAD1 process in a different class (new-Class specified on thread create call). 3. Issue WTO repeatedly THREAD1 CSECT process 1. Initialization 2. Issue WTO repeatedly What we expected: Interspersed WTO's from both MAIN and THREAD1 threads What we get: THREAD1 WTOs only. We thought MAIN, being in a separate class (and therefore eligible to be assigned to different CPUs) would dispatch (and both issue WTOs) but this did not happen. In z/OS the fact that the WTO was issued would provide sufficient dispatch latency for another task to get a time slice. Additional observations: 1. If line write is substituted for WTO in MAIN and THREAD1 there is no observed difference. 2. The program works as expected IF yield is called within the WTO loops in MAIN and THREAD1. Why should yield have to be called? Any thread wizards out there? --. .- .-. -.-- Gary Dennis Mantissa Corporation
