When an operating system is being designed, certain design goals and objectives are specified to limit complexity of the implementation. The Multics operating system includes a design objective that its code be viable for some service lifetime. Based on one limiting factor, this appears to be about 70 years from its date of first operation.
The actual service lifetime can be determined from choices made when implementing code for the operating system.
One such limiting choice is the method chosen for generating unique segment identifiers (segment UIDs).
Objectives of UIDs:
With these design objectives in mind, the getuid tag generation mechanism selects 36 bits from a Multics fixed bin(71) calendar clock value each time a Multics system is started (boot loaded). '''If the calendar clock mechanism has been set correctly each time the Multics site is booted''', the bootload calendar clock value represents a number monotonically greater than any prior clock reading on that system. If the 36-bit UID field is chosen judiciously from the 71 clock bits, it will represent a time range that can operate correctly over a 70 year service lifetime.
The following analysis describes how the current UID mechanism works, and how its actual service lifetime is determined.
File system (and other) Multics unique IDs are being generated by the program: getuid.alm
That routine reads the fixed bin(71) clock value into AQ, then uses the instruction:
lrs 15
to shift C(AQ) right 15 bit positions, and finally returns C(Q) as the 36-bit UID. The following example shows contents of A and Q registers (C(AQ)) loaded from the RCCL (Read Calendar Clock) instruction. The second line shows C(AQ) after the value has been shifted right 15 bit positions. Notice that the leftmost (most significant) bit remains in C(A) while slightly less-significant bits are now in C(Q) register, and bits representing about 32 milli-seconds of time range have been discarded (shifted right out of the Q register).
A Q
RCCL instruction loads C(AQ): 000000155260 405623206277
C(AQ) after right-shift of bits: 000000000001 552604056232
------------
UID Value
The service lifetime for this choice of UID generation and bit-length can be determined by feeding the appropriate calendar clock readings into the date_time_$format subroutine to get interpreted date/time values.
For the smallest (earliest) UID value of all zero bits (or (36)"0"b), the corresponding date_time_ value can be displayed using the call command:
call date_time_$format iso_date_time 100000000000000000b3 system_zone system_lang -out
-- Return from: date_time_$format -------
retValue 1972-05-10 03:56:53 pst
For the largest possible (latest) UID value of all one bits (or (36)"1"b), the corresponding date_time value is:
cl date_time_$format iso_date_time 177777777777700000b3 system_zone system_lang -out
-- Return from: date_time_$format -------
retValue 2043-09-17 15:53:47 pst
So the current UID implementation has a 70-year service lifetime which begins in May, 1972 and ends in September, 2043. After the 2043 date, generated UIDs will no longer be unique within the domain of that site's file system.
This shows that the Multics UID implementation method and length choice are one of the factors that limit "How long a Multics System can run."