Multics should warn if it is running on an old DPS 8/M simulator

[David Rosenberg]

The DPS 8/M simulator has had bugs (and the newest version may well have bugs that haven't been detected yet). In general, newer versions have improvements of various kinds: bug fixes, performance enhancements, code simplification, etc. We want to encourage people running Multics on a DPS 8/M simulator to use the latest version of the simulator - or to be warned that they are running an earlier version. As of R3.0.0 the DPS 8/M simulator has PROM fields describing the type of the simulator release (Alpha release, Beta release, Release candidate, Development release, General release, or Unknown Release type) in byte 144 (octal)), the release version (consisting of the four fields, major release number in bytes 120-122 (octal), minor release number in bytes 123-125 (octal), patch number in bytes 126-130 (octal), and iteration number in bytes 131-133 (octal)), and the most recent commit included in the current build of the simulator (formatted as YYYY‑MM‑DD in bytes 106‑117 (octal)).

If the simulator is not a general release or is an earlier version of the simulator than the latest known version of the simulator when the currently running version of Multics was released, or the commit date in bytes 106‑117 (octal) is earlier than the commit date in the latest known version of the simulator when the currently running version of Multics was released, Multics should warn the user during the Multics boot process. It should be possible for the user to continue running on that simulator, if he chooses to - but he should be made aware that he is running on an older version of the simulator.

[Eric Swenson]

I’m not sure if we should be that rigid in picking the version/ship date that we want to allow without a warning prompt. I think at Multics release team, we should be able to pick any simulator release we know works well. Yes, MR12.8 would pick R3.0.0 now. But we shouldn’t be constrained in the future to pick the simulator release version that is available at the time the Multics release is cut.

[David Rosenberg]

I inadvertently omitted an important point in my description of the problem.

Byte 74 (octal) is the layout_version number. It is the first thing to be checked. If it is NUL, then none of the other fields discussed in the description are populated. Only if byte 74 is non-NUL, can the other fields described in this report be compared to anything.

I expect that valid values in the layout_version number field will be the ASCII characters 1-9, A-Z, and a-z. (I certainly hope we don't need more than 61 versions of the PROM layout.)

[David Rosenberg]

In view of Eric's comment above, the Multics software could be written so that it applied filters to the simulator version. A warning would be issued if any of the filter tests failed. I suggest the following filter tests.

1. Byte 74 (octal) = the layout_version number, should not be NUL and should be at least some <team defined minimum>
2. Byte 144 (octal) = the Release Type character, should be in a <team defined list of valid release types> or maybe should not be in a <team defined list of invalid release types>
3. Bytes 106‑117 (octal) = the most recent commit date, should be greater than or equal to <team defined minimum commit date>.
4. Since the release number consists of four separate fields, the test on the first three fields would have to proceed from left to right, testing that the value in a field was at least some team defined minimum. If it was EQUAL to that minimum, proceed to check the next field to the right. If it is GREATER than the minimum, then ignore fields to its right. I'm not sure whether the rightmost field (the iteration number) should be treated the same way or not. Maybe it should, or maybe any non-zero iteration number should fail the filter test. I would expect Development, Alpha, Beta, and Release Candidate releases to have non-zero iteration numbers, but General Releases should have a zero iteration number.

[Eric Swenson]

​https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10137-v1.4.pdf

[Eric Swenson]

​https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10137-v1.5.pdf

Installed with MR12.8-1063.