User manual

Miscellaneous Notes

driver has hard maximum limit of 30 seconds hardcoded. RECNXINTERVAL can be set to any

practical value.

These guidelines apply regardless of whether any simulator-based cluster node is running in

multiprocessor or uniprocessor mode.

Volume shadowing

We strongly caution against the use of host-based volume shadowing in OpenVMS 7.2 and 7.3.

Shadowing code has severe bugs that were introduced in OpenVMS VAX 7.2 and are present in

7.3 and may also be present in service patches for OpenVMS VAX 7.1 (but not in base OpenVMS

7.1). These VAX-specific bugs (OpenVMS Alpha is not affected) are in volume shadowing code

source module [SYS.SRC]WBM_RTNS.C that makes multiple read references to system time cell

(EXE$GQ_SYSTIME) not properly protecting these references by HWCLK spinlock. These bugs

can lead to data corruption and system crashes. The opportunity for these bugs to be triggered

occurs on each overflow of low 32-bit word containing system time and carry over into high 32-

bit word, which happens approximately every 6 minutes.

These bugs can be triggered even on a uniprocessor system, including both simulator and real

silicon VAXen, but are more likely to show up on a multiprocessor system, and are even more

likely to show up when OpenVMS is executed on a simulator running on a modern host machine

with weaker memory consistency model than silicon VAX.

It might be possible to provide a static patch or dynamic patch for correction of these bugs in a

subsequent release of VAX MP. However for now we strongly suggest to avoid using volume

shadowing when running OpenVMS VAX 7.2 or 7.3. If you need data redundancy, rely on host

based functions such as RAID and/or SAN and host based multi-pathing.

Disk data integrity

OpenVMS does not provide proper means of flushing disk cache. OpenVMS VAX system services,

including SYS$FLUSH and non-cached disk QIOs, do not implement an explicit fence causing disk-

level flush command to be emitted. MSCP protocol provides FLUSH command, but it is not

called by OpenVMS VAX itself and is not exposed to higher levels of application software.

VMS assumes instead that any disk write completed at QIO level had been physically committed

to disk – not just disk controller and controller’s cache, but actual persistent storage on the hard

WBM_RTNS is not the only VMS module that accesses EXE$GQ_SYSTTIME in unprotected fashion. Although most

references to EXE$GQ_SYSTTIME in VMS code had been converted to READ_SYSTIME macro that acquires proper

spinlock for reading EXE$GQ_SYSTIME, some secondary routines still do use unguarded direct access to

EXE$GQ_SYSTIME. Luckily most of these remaining accesses are relatively benign, such as in accounting code, and

at worst can distort accounting data. However WMB_RTNS.C makes a non-benign use of unprotected access to

system time cell. Another system component that is making potentially harmful use of unprotected access is

SYS$NUMTIM system service, which gets dyn-patched by VSMP tool to correct the problem.