History of VSE dispatching
Ingolf24 120000DRN3 Visits (4364)
Today I want to talk about the history of VSE dispatching. End of the 70's, when VSE got to a 12 partition system, a new dispatching algorithm was introduced. It was based on 4 byte bit strings and a translation table.
There was a 4 byte string for VSE partitions (in z/OS terms regions) - the Partition Selection String (PSS) and for each partition a 4 byte Task Selection String (TSS). With a 4 byte string (full word) you have 32 bits that can be used as dispatching indicator, one PSS bit for each partition and one TSS bit for each VSE task of a partition. Therefore you can have up to 32 VSE tasks within a partition - one maintask and up to 31 subtasks. If the corresponding bit is on, the partition/task is ready-to-run.
With the TRT (Translate and Test) instruction, the PSS and the translation table you got the offset into a partition address table (in priority order) of the highest priority partition ready-to-run, with the TSS, the highest priority VSE task ready-to-run. This kind of dispatching was very effective for 12 partitions, with up to 223 user tasks (plus 32 system tasks = 255 tasks).
In the mid 80's I started with a more partition prototype, just by extending the PSS bit strings and the partition control block structures in the Supervisor. Because of the storage constraints and control block structures I got up to one hundred partitions to run. I still have the Supervisor listing in my locker - a pack of paper, about 50 centimeters high. I looked into something more dynamic and expandable, without impacting existing applications.
To keep the dispatching structure I had to use the 4 byte PSS, that is I could extend the number of partitions to 32 - one system partition holding all the system tasks and up to 31 partitions for applications.
That wasn't enough. Therefore I had to introduce an additional level of dispatching, the (dynamic) class - the Class Partition Selection String (CPSS), again a 4 byte string. I had to keep the old 12 partitions - the so called static partitions, because of compatibility reasons and added dynamic classes. Each class can hold up to 32 partitions. That is the dispatcher selected first the highest priority static partition or dynamic class, for dynamic classes the highest priority dynamic partition and finally the highest priority task of the static/dynamic partition.
With dynamic partitions you can define up to 212 partitions (200 dynamic + 12 static). Dynamic partitions were introduced in 1990 with VSE/ESA Version 1. The work for multiprocessing started and it showed that bit strings were no longer practical. Therefore I introduced queues with ready-to-run elements (control blocks) - with pointers to the next ready-to-run elements - for both partitions and tasks. In multiprocessor environments each CPU run through the dispatcher and compete for ready to run elements (partitions). The three level dispatching was no longer required for dynamic partitions. If a ready-to-run partition was selected, the dispatcher looked for the highest priority task in the task queue of that partition. At conferences in the mid 90's I always showed a demo about our multiprocessor support. Attendees were impressed about the speed, when I added a second CPU. Therefore we called the new dispatcher Turbo Dispatcher. It was introduced with VSE/ESA 2.1 in 1994. Because of a few incompatibilities and a minor performance impact, we kept the old dispatcher (with the bit strings).
With the port of CICS Transaction Server and infrastructure changes we had to discontinue the support of the old dispatcher in 1999 with VSE/ESA 2.4. Since then the Turbo Dispatcher is the only dispatcher in the VSE system.
The latest dispatcher changes came with z/VSE 4.2 in 2008. Now up to 512 VSE tasks can be used. We also introduced CPU balancing, where the dispatcher only activates additional CPUs, that are required to run the workload.