dps8m

11-16: 1110 entries, 594 online

11-19: 40 contributors, 86 stories, 22 sites.

11-29:

12-07:

01-06: 840 entries.

← Older revision Revision as of 17:54, 20 November 2022 (25 intermediate revisions by the same user not shown) Line 7: Line 7:   ! style="text-align: center; font-weight: bold; background-color:#CCDDEE;" | ... [More] Status   ! style="text-align: center; font-weight: bold; background-color:#CCDDEE;" | Status   ! style="text-align: center; font-weight: bold; background-color:#CCDDEE; width: 90px;" | Status Date   ! style="text-align: center; font-weight: bold; background-color:#CCDDEE; width: 90px;" | Status Date   + |-   + | style="text-align: center;" | MCR10128   + | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   + | style="font-weight: bold;" |  [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10128_v1.0.pdf Update master.ec with various fixes and features ]   + | style="text-align: center;" | MR12.8-1051   + | style="text-align: center;" | 2022-11-19   + |-   + | style="text-align: center;" | MCR10127   + | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   + | style="font-weight: bold;" |  [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10127_v1.1.pdf Update system_start_up.ec with various fixes and features ]   + | style="text-align: center;" | MR12.8-1050   + | style="text-align: center;" | 2022-11-19   + |-   + | style="text-align: center;" | MCR10126   + | style="text-align: center;" | [mailto:[email protected] Gary Dixon]   + | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10126_mbuild_2_v1.1.pdf mbuild Version 2.00 ]   + | style="text-align: center;" | MR12.8-1042, MR12.8-1043, MR12.8-1052   + | style="text-align: center;" | 2022-10-25   |-   |-   | style="text-align: center;" | MCR10125   | style="text-align: center;" | MCR10125   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10125_v1.0.pdf Remove mca_priv_$force_unlock Entry from mca_priv_ Gate ]     | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10125_v1.0.pdf Remove mca_priv_$force_unlock Entry from mca_priv_ Gate ]   − | style="text-align: center;" | In Review + | style="text-align: center;" | MR12.8-1041 − | style="text-align: center;" | 2022-09-05 + | style="text-align: center;" | 2022-10-04   |-   |-   | style="text-align: center;" | MCR10124   | style="text-align: center;" | MCR10124   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="text-align: center;" | [mailto:[email protected] Eric Swenson] − | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10124_v1.2.pdf Omnibus Documentation MCR for Minor Fixes ]   + | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10124_v1.7.pdf Omnibus Documentation MCR for Minor Fixes ]   − | style="text-align: center;" | MR12.8-1034, MR12.8-1035, MR12.8-1038 + | style="text-align: center;" | MR12.8-1034, MR12.8-1035, MR12.8-1038, MR12.8-1044, MR12.8-1045, MR12.8-1046, MR12.8-1047, MR12.8-1048, MR12.8-1049 − | style="text-align: center;" | 2022-09-06 + | style="text-align: center;" | 2022-10-29   |-   |-   | style="text-align: center;" | MCR10123   | style="text-align: center;" | MCR10123   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10123_v1.1.pdf Fix issue with meter_signal when invoked with -nfaults 2 ]     | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10123_v1.1.pdf Fix issue with meter_signal when invoked with -nfaults 2 ]   − | style="text-align: center;" | In Review + | style="text-align: center;" | MR12.8-1040 − | style="text-align: center;" | 2022-09-03 + | style="text-align: center;" | 2022-10-04   |-   |-   | style="text-align: center;" | MCR10122   | style="text-align: center;" | MCR10122   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="text-align: center;" | [mailto:[email protected] Eric Swenson]   | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10122.pdf Increase default process directory segment quota ]     | style="font-weight: bold;" | [https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10122.pdf Increase default process directory segment quota ]   − | style="text-align: center;" | In review + | style="text-align: center;" | MR12.8-1039 − | style="text-align: center;" | 2022-08-31 + | style="text-align: center;" | 2022-10-03   |-   |-   | style="text-align: center;" | MCR10121   | style="text-align: center;" | MCR10121 [Less]

Add a Table of Contents ← Older revision Revision as of 16:21, 30 November 2022 Line 1: Line 1:   +   +   +   While the DPS8M development team has been running Multics on the simulator for several ... [More] years now, and those of us with long-running systems have enjoyed long periods of up-time, you should take care to not store anything of value on your Multics system unless you also have that data backed up somewhere else.   While the DPS8M development team has been running Multics on the simulator for several years now, and those of us with long-running systems have enjoyed long periods of up-time, you should take care to not store anything of value on your Multics system unless you also have that data backed up somewhere else.       '''Warning:''' We have experienced simulator crashes where the contents of the Multics storage system is damaged. Salvaging the storage system allows Multics to be rebooted, but any data written in the bootload prior to the crash may be lost.  Please see the following sections for recommendations to ensure the safety and integrity of your Multics storage system.   '''Warning:''' We have experienced simulator crashes where the contents of the Multics storage system is damaged. Salvaging the storage system allows Multics to be rebooted, but any data written in the bootload prior to the crash may be lost.  Please see the following sections for recommendations to ensure the safety and integrity of your Multics storage system.   +   + __TOC__       == Run with DIRW Configuration Setting ==   == Run with DIRW Configuration Setting == [Less]

‎Useful Links ← Older revision Revision as of 16:26, 30 November 2022 Line 15: Line 15:   * [[Getting Started]]   * [[Getting Started]]   * [[Stability of the System]]   * [[Stability of the System]]   + ... [More] ** [[Design Limitations:  How Long can Multics Run?]]   * [[Multics Release Info]]   * [[Multics Release Info]]   * [[Using Multics]]   * [[Using Multics]] [Less]

Multics service lifetime - one limiting factor New pageWhen 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 ... [More] that its code by viable for its expected service lifetime: about 70 years from its date of first operation. The actual serviceable 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 these UIDs: * Provide a unique tag which can be assigned to a file system entry (segment, directory, or link) to separate that entry from all others stored in the file system running on a given Multics site. * To ensure uniqueness, the set of tags will be monotonically increasing in numeric value. Each new tag will have a larger numeric value than its predecessors. * Maximum tag length (size of storage needed to hold a tag) will be chosen to permit the tag generation mechanism to operate for the expected 70 year service lifetime of Multics. 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 span the 70 year expected service lifetime of the operating system. 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. 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 meets the goal of a 70-year service lifetime for Multics starting in May, 1972 and ending in September, 2043. After the 2043 date, generated UIDs will no longer be unique within the domain of that site's file system. Therefore, the Multics UID method and length choice are one of the factors which limit "How long a Multics System can run." [Less]

← Older revision Revision as of 18:33, 30 November 2022 (2 intermediate revisions by the same user not shown) Line 1: Line 1: − When an operating system is being designed, certain design goals and objectives ... [More] are specified to limit complexity of the implementation.  The Multics operating system includes a design objective that its code by viable for its expected service lifetime: about 70 years from its date of first operation.  The actual serviceable lifetime can be determined from choices made when implementing code for the operating system. + 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 by viable for some service lifetime.  Based on one limiting factor, this appears to be about 70 years from its date of first operation.        − One such limiting choice is the method chosen for generating unique segment identifiers (segment UIDs).  Objectives of these UIDs: + 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:   * Provide a unique tag which can be assigned to a file system entry (segment, directory, or link) to separate that entry from all others stored in the file system running on a given Multics site.   * Provide a unique tag which can be assigned to a file system entry (segment, directory, or link) to separate that entry from all others stored in the file system running on a given Multics site.   * To ensure uniqueness, the set of tags will be monotonically increasing in numeric value.  Each new tag will have a larger numeric value than its predecessors.   * To ensure uniqueness, the set of tags will be monotonically increasing in numeric value.  Each new tag will have a larger numeric value than its predecessors.   * Maximum tag length (size of storage needed to hold a tag) will be chosen to permit the tag generation mechanism to operate for the expected 70 year service lifetime of Multics.   * Maximum tag length (size of storage needed to hold a tag) will be chosen to permit the tag generation mechanism to operate for the expected 70 year service lifetime of Multics.     − 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 span the 70 year expected service lifetime of the operating system. +     + 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.   +     +     + ==== Method for Generating UIDs ====       File system (and other) Multics unique IDs are being generated by the program:  getuid.alm     File system (and other) Multics unique IDs are being generated by the program:  getuid.alm   Line 15: Line 25:          lrs 15          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. + 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).             Line 24: Line 34:                                                          UID Value                                                           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. +     + ==== Service Lifetime for getuid Method ====   +     + 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:   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: Line 42: Line 55:     retValue            2043-09-17 15:53:47 pst      retValue            2043-09-17 15:53:47 pst      − So the current UID implementation meets the goal of a 70-year service lifetime for Multics starting in May, 1972 and ending in September, 2043. After the 2043 date, generated UIDs will no longer be unique within the domain of that site's file system.  Therefore, the Multics UID method and length choice are one of the factors which limit "How long a Multics System can run." + 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 how the Multics UID implementation method and length choice became are one of the factors which limit "How long a Multics System can run." [Less]