OpenVMX V0.7-10

OVMX V0.7-10 Release Notes

Generated by tools/gen_release_notes.py from the merged history since V0.7-9 (21 commits). Do not hand-edit this file -- re-run the tool against the release tag instead.

Highlights

• V0.7-9 could crash a real VAX; V0.7-10 fixes it. In 3 of the 8 visitor orders of the cluster demo's V0.7-9 gate, a real VAX running OpenVMS V7.3 bugchecked with INVEXCEPTN. After joining, OVMX asked an older member for its clusterwide logical-name database (the 0b/05 request) before that member was ready to answer, while it was still early in its own startup. OVMX now waits for a member to be ready, as a real VAX does. A member is ready when its PARAMS say so, or when it sends its own startup query. That rule comes from 54 real database requests. In a lab run of the same topology that had crashed, OVMX held the request for 63.7 s while the VAX started up, then made it 0.79 s after the VAX's query, with 0 bugchecks (vms-f4e).
• Cluster transitions: a member's answer to a logical-name database request is no longer mistaken for a membership-record acknowledgement. While OVMX coordinated a transition, that mistake could count an acknowledgement nobody sent (vms-6e3 follow-up).
• Lock-tree adoption in the lock manager. When a lock tree is handed to OVMX, the engine now creates a real master-side lock for each lock a holder reports, under the right parent resource. A cross-node conversion now converts the lock its handle names rather than looking it up by name (vms-14fd). OVMX does not yet take part in a hand-over on the wire. See the known open items.
• Nothing runs as substrate root after startup. STARTUP and the startup process give up root once startup is done. Powering off is an executive service that needs CMKRNL. The acceptance battery's root audit counts 0 root processes (vms-137e).
• Process identity: $CREPRC gives a process its identity when it creates it. SETIDENT is accepted only while a process is being logged in (vms-a2c). On NetBSD the executive no longer creates a process row from an ioctl (vms-6ed).
• TCP/IP network configuration needs OPER, as on VMS. A refused SET ROUTE or SET INTERFACE returns %SYSTEM-E-NOPRIV and changes nothing (vms-ec6).
• HW_NAME has one source: $GETSYI, F$GETSYI and SHOW CPU all report the executive's hardware model (vms-21be).

Known open items

• The 0b/05 database request names transfer connection 0. Real requests name a connection (19 of 19 in the capture corpus). This is recorded with its evidence but not fixed in this release (vms-9045).
• The cluster demo does not pass its visitor gate yet. This release's pre-tag gate ran 8 visitor orders. One order (page-order) still bugchecked the demo's real VAX, with LOCKMGRERR rather than INVEXCEPTN; the cause is under investigation (vms-c55). In 5 other orders the cluster reached three members, but the VAX stopped at %RMS-E-FNF during its startup and never offered Username:. One order reached CN=3 with every node usable.
• Clusterwide logical names are not sent from OVMX yet. A local change to a clusterwide table is refused with SS$_UNSUPPORTED while other members exist (vms-94a follow-up).
• Lock-tree remastering on the wire: OVMX does not yet parse a real hand-over or send the closing op-0x14 message, because two of its fields are not yet grounded (vms-380). Each adoption that goes unreported is counted.
• A former master does not yet answer "not master here" (the 0xf7 reply). Three lab designs have not produced one on real VAXes (vms-657).

Features

• cut: V0.7-10 -- a real VAX no longer bugchecks when OVMX pulls the clusterwide logical-name database (vms-f4e) (#1705)
• vms-761: untrack build.build.log and build.cfg.log (committed by accident in a711195) and ignore them (#1694)
• vms-9045: the 0b/05 database request names transfer connection 0 where 19 of 19 real requests name a connection (evidence) (#1704)
• vms-21be: HW_NAME has one source -- $GETSYI, F$GETSYI and SHOW CPU read exec_hw_model() (#1688)
• vms-f4e: no 0b/05 database pull from a member not yet ready (a real VAX bugchecked INVEXCEPTN in the V0.7-9 demo gate) (#1702)
• vms-aaf: roadmap-block gate passes a stale PR branch; a hand-edit or a drifted main still reds (#1703)
• vms-6ed: the NetBSD executive creates no row on an ioctl; guest harnesses run their tools under a creator (#1698)
• release notes: correct V0.7-9 (highlights source + what the tag ships); notes come from the tagged SHA, gated in release.yml (#1697)
• cluster-web-demo gate: a DCL prompt after the VMS NUL fill is a DCL prompt (#1699)
• register: OVMX founding a cluster real VAXes join is done (vms-d52c, #1667; labd52c run 3 CN=3) (#1696)
• vms-ec6: TCP/IP network configuration needs OPER, as measured on VMS; a refused SET ROUTE/INTERFACE is %SYSTEM-E-NOPRIV and records nothing (#1700)
• releasing.md: the cut checklist -- the demo visitor gate runs on the frozen build BEFORE the tag (0 VAX bugchecks), green by the tagged SHA, notes from the tagged SHA (#1701)
• roadmap: reconcile after V0.7-9 (#1695)
• vms-a2c: SETIDENT only while a process is being logged in -- $CREPRC gives a process its identity at creation (#1686)
• vms-14fd: the engine ADOPTS a remastered tree -- real RSBs, real LKBs, real lock ids, and no 0x14 (#1692)
• vms-50d RA6: one op-0x14 cell named, five predictions falsified, and the rest of the frame shown to be stale buffer (#1693)
• vms-657: run 4 and park (0xf7 not elicited under 3 pre-registered designs) (#1690)
• vms-6e3: the coordinator takes only 0x81 answers as transition acks (the post-admission "no edge" event was a 0x8b/0x05) (#1687)
• vms-50d RA5: remaster handles named against SDA truth (#1691)
• vms-657: f7 oracle runs 2 and 3 (no 0xf7 yet; why, and the next arm) (#1689)
• vms-137e: nothing runs as substrate root after startup -- STARTUP and the startup process leave root; the executive powers off (#1678)