User manual

Miscellaneous Notes

Miscellaneous notes

Do not set SYSGEN MULTIPROCESSING = 4

Do not set SYSGEN parameter MULTIPROCESSING to 4. OpenVMS VAX 7.3 and possibly some

earlier versions have a known problem manifesting itself when the system is booted with

MULTIPROCESSING set to 4. The problem is unrelated to VAX MP and manifests itself even on a

regular uniprocessor SIMH. One manifestation of the problem is system crash triggered when a

disk is dismounted, often resulting also in volume’s home block being wiped out and total disk

data loss.

Always use MULTIPROCESSING = 2 for multiprocessor execution or MULTIPROCESSING = 3 or 0

for uniprocessor execution.

Use of DZ multiplexor

If you have a system disk with SYSGEN parameter MULTIPROCESSING set to 2 and want to boot

it on regular uniprocessor SIMH VAX simulator version 3.7.x or earlier, disable DZ multiplexor

device using SIMH console command “set dz disable” or, if you leave it enabled, do not try

actually using DZ device.

Older versions of SIMH VAX incorrectly define DZ interrupt level. This will case OpenVMS to

crash if a use of DZ use is attempted when MULTIPROCESSING is set to 2, once the device

actually fields an interrupt to the processor. The problem is fixed both in VAX MP and regular

uniprocessor SIMH version 3.9 and late 3.8-2 builds, which are safe to interchange system disk

images with VAX MP. If you want to use VAX MP disk image with early 3.8 SIMH VAX or earlier

versions, make sure either to disable DZ or boot with MULTIPROCESSING set to 0 or 3. The

problem is specific to DZ and does not affect VH multiplexor. It is safe to boot OpenVMS disk

image with MULTIPROCESSING=2 on older SIMH VAX versions that have VH, but not DZ

configured.

Using VMware, VirtualBox and other virtual environments

VAX MP can be executed under VMware and similar virtualization hypervisors running on top of

host operating system, however this configuration is not recommended since hypervisor will be

unable to effectively propagate VAX MP threads priority settings and dynamic priority changes

to the host system and thus host system in combination with the hypervisor will be unable to

schedule VAX MP virtual processors properly. This may result in losses of CPU resources to

unnecessary lock-holder busy-waits and other spin-waits and thus lower overall performance

and scalability of the system, slowdown of critical operations and poorer interactive response

compared to VAX MP execution directly on the host system. Furthermore, SMP hypervisors

introduce overhead related to virtual processor synchronization and thus total overhead will be

higher when running VAX MP inside the hypervisor than directly on the host system.