CMS Multitasking Considerations

CMS Multitasking introduces the concepts of processes and threads. Every program executes within a thread of a process. Some resources are associated with the thread; they have thread scope. Others have process scope; anything the applies to the entire CMS is in session scope.

A thread is created by a issuing the appropriate call to CMS MT. A process is created by running a command that is linked with the VMSTART routine from the CMS MT object library. The process that runs the CMS command interpreter is called the Commands process; there is exactly one such process at any time.

Thread Safe

While CMS Pipelines' internal data structure is thread safe, many built-in programs expose or use interfaces that are not known to be thread safe. In fact, most CMS functions have session scope.

• The CMS and COMMAND drivers are modified in 1.1.12/0007 to run in one thread at a time (still supporting recursions). That is, the stages will refuse to run concurrently on multiple threads. The exposure is not the PIPE command itself as that is serialised by CMS, but setting up and maintaining the various interfaces to trap standard output.

• Other stages that use undocumented interfaces include the following. These are thread safe as long as you are running on a virtual UP or all threads are in the same dispatch class, that is, they are created with the flag vm_pro_my_class set and do not change their dispatch class subsequently.
  • Fast access to minidisk files by MDSKFAST, which is what > selects for files that are specified with a mode letter. Use e.g., >SFS instead, even for minidisk files.
  • Access to the REXX variable pool uses a branch entry.
  • AFTFST uses a branch entry and the function is not available by CMSCALL.

Structures in Thread Scope

• CMS Abend recovery and the command entered at the VM Read after the abend run in the failing process. A new process is created at the next command end.

• Running a PL/I or C program (or possibly just using the Language Environment) causes the current commands process to be terminated at end-of-command. Thus, the next command runs in a new process.

Thus, as of 1.1.12/0008, thread 1 of the commands process is treated as running in process 0 so that anything thread specific remains in place after MT cleanup. This is a truly ugly hack.

Virtual MP

The short version: Don't bother.

When CMS MT initialises itself and finds more than one processor, it allocates a page for the prefix storage area of each additional processor and sets the address of this page into the prefix register. A copy of NUCON is moved to this prefix, but the new PSWs point into CMS MT code, which is written in PL/X and thus is OCO for most of us; but the point is that it uses different interrupt handlers from the IPL processor. It is not documented to what extent this copy of NUCON is maintained, but it would appear that it has no SUBCOM chain.

The IPL processor continues using a prefix of 0, unlike other multitasking System/360 operating systems.

CMSCALL (probably any SVC) causes the thread to migrate to the IPL processor. Once there, it will not switch processor unless it suspends itself and is resumed on a different processor. Even if you cheat and branch directly to the PIPE nucleus extension, it will obtain storage and immediately migrate to the IPL processor.

I have not been able to cajole any pipeline code to run on the non-IPL processor (and it is not for want of trying); even getting a simple assembler program to run on the other processor is a bit of a challenge. And as soon as you write to the console you're back on the IPL processor.