Hi, Gary. Please see my comments below.... ----- Original Message ----- From: "Gary M. Dennis" <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU Subject: CMS Multi-tasking - How is it different from z/OS task management Date: Thu, 10 Jul 2008 17:13:50 -0500
> We are attempting to leverage z/VM CMS multi-tasking > capabilities for Windows® thread management. > Cool, I think you'll find that environment fun to work with... > 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. > I can certainly understand that....CMS multitasking support has very little, if anything, in common with the MVS multitasking approach. The CMS multitasking that was added (to CMS R6?) is modeled after the thread and process model found in OS/2. It also has some resemblance to the POSIX process and thread model, too, I believe. > 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 > CMS simulates the MVS WTO macro; and there might be something in that simulation that does not play nicely with the other parts of CMS multitasking support. CMS support for MVS application development hasn't been looked at in years, and I don't know if that support changed any because of multitasking. Consider replacing your WTO with equivalent CMS function. > 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? > If you have created these two threads so that they have the same dispatching class, then that may be the source of your problem. No two threads in a class are ever dispatched in parallel. That is to say, they are never in execution at the same time on different processors (CPUs). However, any thread can be preempted by or dispatched in parallel with any thread in a different class. See the section on Dispatching Classes in the CMS Application Multitasking document. BTW, when CMS is first IPL-ed in a virtual machine, it itself creates some threads that it uses internally to control it's processing. One of those threads is the command handler that processes commands input from the virtual console. Hope this helps. DJ > > --. .- .-. -.-- > > Gary Dennis > Mantissa Corporation
