ticket summary component version milestone type owner status created _changetime _description _reporter 8 ISOLTS executes pas2 test harness incorrectly. General defect Eric Swenson new 2017-01-12T17:07:11Z 2026-10-11T17:54:26Z "Running the pas2 exec command 'hdump' produces an infinite listing of history resister values. " charles.unix.pro@… 35 Finish support for passwords up to 32 characters in length General MR12.6e defect Eric Swenson new 2017-02-11T07:19:09Z 2026-10-13T16:20:11Z While the PNT software appears to support passwords greater than 8 characters in length, passwords are currently limited to 8 characters -- probably because the answering service doesn't support passwords greater than this length. In this day and age, limiting passwords to 8 characters provides laughable security. Since 32-character passwords appear to be supported at the PNT level, we should investigate what it would take to enable passwords of up to 32 characters. Eric Swenson 36 pcref does not ken .cds segments Tools defect Eric Swenson new 2017-02-11T07:23:39Z 2019-05-22T03:15:41Z "As part of the Y2K and time-zone issues, the pcref tool was used to locate references to decode_clock_value_$date_time. prcef relies on data gathered by crossref, which analyzes compiled/assembled segments to locate references to entry points. However, .cds segments are not known to crorssref, has the compiled cds segments are not part of the built code; only their output is. The entry decode_clock_value_$date_time parameter zone was changed from char (3) to char (4); due to pcref not searching the CDS segments, the change was not propagated to those segments. Searching the Multics source reveals: bound_pl1_.1.s.archive/pl1_version.cds dcl decode_clock_value_$date_time entry (fixed bin (71), fixed bin, fixed bin, fixed bin, fixed bin, fixed bin, fixed bin, fixed bin (71), fixed bin, char (3), fixed bin (35)); This is the only date_time reference that I can locate in the .cds segments." canthony 41 Add exec_com to >tools for bootstrapping PL/1 compiler Tools MR12.6e defect Eric Swenson new 2017-02-12T05:03:46Z 2017-02-12T05:03:46Z As part of fixing the cat_op issue with the PL/1 compiler, we decided to resume bootstrapping the compiler with each new compiler release. As part of doing this for version 33f (MR12.6f) of the PL/1 compiler, I created an exec_com (bootstrap_compiler.ec/.absin). We decided it might be a good idea to install it. Eric Swenson 79 configure.ini script shipped with QuickStart has ill effects if run a second time General MR12.6f defect Eric Swenson new 2017-08-11T05:46:11Z 2017-08-11T05:46:11Z configure.ini script is really sad. It needs to get replaced. Eric Swenson 11 ISOLTS misses test opportunity Documentation enhancement Eric Swenson new 2017-02-05T18:38:17Z 2026-10-11T17:57:18Z "The ISOLTS process includes instructing the operator to ""depress the initialize and clear push button"", but fails to verify that memory was actually cleared. Failure of the operator is clear memory will result in incorrect test behavior, so it is reasonable for ISOLTS to verify that memory was cleared. Failure of memory being cleared if the button was pressed would be indicative of a configuration or hardware failure, so it is reasonable that ISOLTS verify that was memory was cleared when the opportunity presents itself. Before loading the PFT tests into the test segment, ISOLTS should check that the test segment is indeed set to all zeros, and if not, report that memory was not zero, indicating operator error, CPU malfunction or SCU malfunction. Additionally, it should zero the memory before proceeding with the tests. " anonymous 26 Update clok card to support contemporary time zones Hardcore MR12.5 MR12.9 defect Eric Swenson assigned 2017-02-11T06:50:07Z 2026-10-13T16:19:56Z Bring the configuration deck 'clok' card time zone list up to contemporary usage. -- Charles Eric Swenson 69 Invoking trace_stack in admin mode crashes Multics Answering Service MR12.6e MR12.9 defect Eric Swenson new 2017-03-19T18:04:29Z 2026-10-10T16:18:35Z "If you invoke the ""trace_stack"" (""ts"") command from admin mode, the system crashes when Initializer runs out of stack. It recurses trying to report a ""null pointer"" exception, getting another ""null pointer"" exception in the condition handler." Eric Swenson 75 'lst' loops endlessly when encountering broken archive segment Standard Library MR12.6e MR12.9 defect Eric Swenson assigned 2017-05-15T22:59:57Z 2026-10-13T17:21:00Z "lst -ac >ldd>unb>o>bound_lisp_library_.archive ac 59 >ldd>unb>o>bound_lisp_library_.archive ac_comp bound_lisp_library_.bind ac_comp display_lisp_object_segment ac_comp lisp_backquote_ ac_comp lisp_defmacro_ ac_comp lisp_defstruct_ ac_comp lisp_defun_ ac_comp lisp_destructuring_let_ ac_comp lisp_editor_ ac_comp lisp_format_ ac_comp lisp_gfile_ ac_comp lisp_gfn_ ac_comp lisp_loop_ ac_comp lisp_macro_macros_ Format error encountered in archive segment. (reading archive) ac_comp bound_lisp_library_.bind ac_comp display_lisp_object_segment ac_comp lisp_backquote_ ac_comp lisp_defmacro_ ac_comp lisp_defstruct_ ... repeats endlessly .... " charles.unix.pro@… 156 Multics should fail to boot if 6601 console is not connected to IMU Hardcore MR12.6f MR12.9 defect Eric Swenson assigned 2019-03-30T05:07:57Z 2026-10-13T19:47:53Z "Multics misbehaves if a 6601 console is defined on an IOM that is not specified as model IMU. It should detect this and prevent booting with this config. In this (improper) config, console I/o doesn’t work. Real 6601s were only connected to IMUs " Eric Swenson 157 Specify a config deck with a model 6601 console attached to a non-IMU IOM causes BCE to lockup Hardcore MR12.5 MR12.9 defect Eric Swenson assigned 2019-03-30T05:08:50Z 2026-10-13T19:48:15Z "If ocdcm_.pl1 sees that the operators console is a model 6601, it assumes that the IOM model is IMU and becomes incapable of accepting console input. The config deck code that parses the opc model number should verify that the IOM that a 6601 console is attached to is a IMU model. This situation would not arise in actual hardware as the 6601 would not work with an IOM; however operator error in editing the config deck could cause this situation, and it leaves the disk unbootable. " canthony 411 info_seg.gi.info still references obsolete validate_info_seg (vis) Documentation MR12.8 MR12.9 defect Gary Dixon assigned 2026-09-24T00:29:39Z 2026-09-24T03:44:39Z "The first Notes section says: {{{ Notes: Type ""help vis"" for information on the validate_info_seg command, which checks for proper info seg syntax and names. }}} It also uses validate_info_seg in an example: {{{ Follow the date with two spaces and the long (and short, if any) name of the module being described; for example, 1985-10-10 validate_info_seg, vis 1985-09-23 ioa_ }}} " Eric Swenson 412 Bugs identified in archive.pl1 Standard Library MR12.9 MR12.9 defect Eric Swenson new 2026-09-25T19:32:19Z 2026-09-25T19:32:19Z "The archive command has several bugs that destroy user data or leave the user with unintended access, and several that print misleading messages or leak storage. Numbers 1-19 below are part of a single numbering for a total of 36 identified bugs across the archive programs (archive.pl1, archive_util_.pl1, archive_.pl1, archive_aux_.pl1, and update_handler_.pl1). Line numbers are from MR12.8 and indicate the start of the problem area. Item 6 below is not a bug but documented behavior missing from archive.info; other errors in archive.info are listed below but are in addition to the numbered bugs. I have a tests.archive test kit which has an exec_com for each item marked ""Test"" which prints the expected behavior and then runs commands. In the examples below, t_ok.archive holds two components, alpha and beta, and seed.txt is any small text segment. Bug 1: an archive that exists but cannot be read is treated as missing, line 460 For the replace and append keys (r, rd, a, ca, ...), any failure of initiate_file_ on the archive, not only ""entry not found"", is taken to mean that the archive does not exist. The command then tries to create a new archive, gets ""name duplication"", and calls nd_handler_, which asks whether to delete the existing archive. Answering yes replaces the whole archive with one holding only the new components. sa t_ok.archive w ac r t_ok beta archive: Name duplication. Do you want to delete the old segment ...>t_ok.archive? Expected: the error from initiate_file_ (here ""No read permission on entry"") is reported, and no query is asked. Test: bug01.ec. Bug 2: updating a protected archive deletes the user's own ACL entry instead of restoring it, lines 672 and 717 When the user lacks w on the archive, the command asks whether to update it, gives the user's process group ID (e.g. Person.Project.a) rw, and afterwards deletes that ACL entry. If an entry for that exact name already existed, it is overwritten and then deleted. sa t_ok.archive r sa t_ok.archive r Person.Project.a answer yes ac r t_ok beta list_acl t_ok.archive (the Person.Project.a entry is gone) Expected: the ACL is the same after the update as before it. Test: bug02.ec. Bug 3: forced access is left on a protected archive after a failure or an interruption, lines 702 and 792 The ACL entry added in bug 2 is removed only on the successful path. After a record quota overflow, or if the command is interrupted and the user releases, the user is left with rw on the archive: list_acl DIR>t_rqo3.archive rw Person.Project.a r Person.Project.* Expected: the original access is restored on every path. Test: bug03.ec (needs an empty directory with a 60-record quota). Bug 4: after a record quota overflow, the saved copy of the updated archive is misreported and then destroyed, line 705 When an update fails for lack of quota, the updated archive, built in the process directory as archive_temp_.archive, is renamed to the archive's name and the user is told where to find it. If that name is already taken in the process directory (e.g. by a copy saved by an earlier failure), the rename fails, the message names [pd]>temp.archive, which does not exist, and the segment remains the command's temporary. The next update in the process truncates it to 0 records, destroying the only updated copy; its bit count is left unchanged, so it then lists as a format error. ac r DIR>t_rqo c2 archive: Record quota overflow. Archive DIR>t_rqo.archive not updated. A copy of the updated archive can be found in [pd]>t_rqo.archive ac r DIR>t_rqo c3 archive: Record quota overflow. Archive DIR>t_rqo.archive not updated. A copy of the updated archive can be found in [pd]>temp.archive ac r t_ok beta status [pd]>archive_temp_.archive (records used: 0) ac t [pd]>archive_temp_ archive: Format error in [pd]>archive_temp_.archive Expected: the message names the segment that holds the copy, and the copy survives later archive commands. Tests: bug04.ec, bug04d.ec (need an empty directory with a 60-record quota). Bug 5: extracting with force over a link deletes the link's target instead of the link, line 855 When the destination entry exists and is a link, x and xd ask (through nd_handler_) whether to unlink it, while a similar copy -force's behavior unlinks it with the message ""Name duplication. Unlinking the old link ... (Target ... exists.)""; in each case the target is not touched. xf and xdf instead call the command's own delete_seg, which chases the link and deletes its target (which may be anywhere in the hierarchy), then create a new segment through the link in the target's directory. No segment is created in the working directory, the target loses its other names and its ACL, and no message is printed. add_name keep>alpha keepname link keep>alpha alpha ac xf t_ok alpha status alpha (still a link) status keep>alpha -names (keepname is gone) Expected: as the MPM says, an existing entry is handled by the copy command's duplicate name convention: the link is unlinked, as by copy -force, and the component is extracted in the working directory. Test: bug05.ec (also runs copy -force and ac x over a link for comparison). 6: Not a bug: deleting a linked source after rd, ud or ad deletes the link's target, which archive.info does not say When a source named on the command line is a link, the deletion requested by rd, ud or ad deletes the segment the link points to, not the link. This is documented in the MPM (Commands, archive, Notes: ""For segment deletions after replacement requests, if the specified component name was a link to a segment, the segment linked to is deleted. The link is not unlinked.""), but archive.info says nothing about it, and the behavior is unexpected: a segment elsewhere in the hierarchy, possibly with other names, is deleted, and the link is left pointing to nothing. Expected: archive.info includes the MPM's statement. Bug 7: component names longer than 32 characters are truncated for table and delete, line 535 For t, tl, tb, tlb, d and cd, a component name argument is assigned to a 32-character variable without a length check, so a longer name matches the component named with its first 32 characters. ac d deletes a component that was not named: ac d t_longname abcdefghijklmnopqrstuvwxyz0123456789 (deletes abcdefghijklmnopqrstuvwxyz012345) Expected: ""Entry name too long"", as the other keys already report through expand_pathname_, and nothing is deleted. Test: bug07.ec. Bug 8: a global extract-and-delete can remove a component that was not extracted, line 835 In xd with no component names, if creating the segment for a component fails (e.g. a directory of that name exists), whether the component is kept in the archive depends on a stray word of storage (see bug 9). In practice it is deleted from the archive without being extracted: create_dir beta ac xd t_ok archive: This operation is not allowed for a directory. ...>beta archive: All components of ...>t_ok.archive have been deleted. Expected: a component that was not extracted stays in the archive. Test: bug08.ec. Bug 9: a failed extraction with no component names writes outside the argument array, line 835 In the same case as bug 8, and for x with no names when a segment cannot be created (e.g. no append permission), the command reads and writes element 0 of the argument array (nonglobal (i) with i = 0), which does not exist, overwriting a word of the stack frame before the array. Found by inspection; exercised by bug08.ec. Bug 10: a global delete-type update of more than 102 components creates, and leaks, a segment for each further component, line 990 The list of source segments to delete is kept on the stack; when it fills, it is moved to a segment in the process directory. The test for ""full"" does not check whether the list has already been moved, so for every component after the 102nd a new segment is created and the list copied into it; only the last is deleted. A global rd of a 110-component archive leaves 7 unnamed segments in [pd]. Test: bug10.ec. Bug 11: the global update messages name the archive's directory instead of the working directory, line 778 The source segments for a global update come from the working directory, but the messages name the directory containing the archive: cwd work ac u bug11; no components were updated in archive ...>bug11>t_ok.archive archive: Archive ...>t_ok.archive contains the latest versions; no components were updated from ...>bug11. Expected: both name the working directory (...>bug11>work). Test: bug11.ec. Bug 12: with the copy keys, messages name the original archive, which is unchanged, lines 760 and 769 For cr and its variants, the message for a component added to the archive names the original archive rather than the new copy in the working directory. The ""Archive segment overflow"" message has the same error. cwd work ac cr work>gamma appended to ...>bug12>t_ok.archive Expected: ""appended to ...>bug12>work>t_ok.archive"", the archive that was changed. Test: bug12.ec. Bug 13: an archive overflow while copying leaves an incomplete new archive, line 1087 If a copy key (cr, ca, cd, ...) runs out of room while copying components into the new archive in the working directory, the command stops and leaves the partial archive, with a bit count of 0. Expected: no partial archive is left. Found by inspection (needs an archive near the maximum segment length). Bug 14: segments are left initiated on error paths, lines 851, 975, 1021 and 1030 When a source's bit count is inconsistent with its length, and when adding a source would overflow the archive, the source segment is not terminated. When xf replaces an existing destination entry, the segment returned by the first hcs_$make_seg is not terminated. Found by inspection. Bug 15: a global replace sets a flag through a stale index, line 935 If the archive itself matches a component name in a global replace, the command sets flags (i) using the index of the last named component, which in the global case is stale and points into the deletion list. Found by inspection. Bug 16: an error from fs_util_$get_max_length is ignored when a new archive is created, line 1120 The code tests code instead of error after the call. Found by inspection. Bug 17: an unexpected error from archive_util_$first_element is ignored, line 473 If the archive's status cannot be obtained, first_element returns a system error code, which the command treats as success. Found by inspection. Bug 18: the archive is not terminated when the command stops on an early error, line 467 When the archive's mode or maximum length cannot be obtained, the command returns directly (goto RETURN) instead of through its cleanup. Found by inspection. Bug 19: word counts are computed with 17-bit precision, lines 816, 1008 and 1078 divide (..., 17, 0) is used for component word counts, which can exceed 131,071 for large components. No failure was seen on MR12.8, because the values are held in full words. Found by inspection. Errors in archive.info paths is described only for table and delete operations; it is also the source or destination segment for append, replace, update and extract. tlb is said to suppress ""the time portion of dates""; it suppresses the title and column headings, as the MPM says. ca: ""appending components to a copy of the new archive segment"" should be ""a copy of the archive segment""; cud: ""copies, update, and deletes"" should be ""copies, updates, and deletes"". x, xf: the MPM's statement that an existing entry is handled by the copy command's duplicate name convention is missing. Notes: the MPM's statement about linked sources (item 6) is missing, as is any mention that the copy operations cannot be used on an archive in the working directory, or of what happens after a record quota overflow. " Jim Lippard 413 Bugs identified in archive_util_.pl1 Standard Library MR12.9 MR12.9 defect Eric Swenson new 2026-09-25T19:35:03Z 2026-09-25T19:35:03Z "archive_util_ accepts archives that archive_ rejects, so the archive command and the archive_ subroutine disagree about what an archive is: the command lists and processes damaged archives that the subroutine calls format errors. It also has precision and declaration errors. Numbers 20–27 are part of a single numbering across the archive programs; line numbers are those of the MR12.8 source. The crafted archives named below are in the test kit (tests.archive), with an exec_com for each item marked ""Test"". Bug 20: headers beginning with the obsolete archive_data_$header_begin are accepted, line 71 A header may begin with either archive_data_$ident or the obsolete archive_data_$header_begin. archive_ accepts only archive_data_$ident. An archive whose first header uses the obsolete string lists without error: ac tl t_obsolete (lists alpha and beta) Expected: ""Format error"", as from archive_. (No archive using the obsolete string is known to exist.) Test: bug20.ec. Bug 21: the header fence (archive_data_$fence) is not checked, line 71 A header whose fence is damaged is accepted: ac tl t_nofence (lists alpha and beta; beta's fence is damaged) Expected: alpha is listed, then ""Format error"", as from archive_. Test: bug21.ec. Bug 22: the bit count field is not validated, lines 61 and 121 The bit count field is converted with cv_dec_ with no check, so a field that is not a number is taken as some value (possibly 0), and the scan continues at the wrong place, possibly treating component data as the next header: ac tl t_badbc alpha 09/22/26 1639.0 r w 09/22/26 1630.0 x beta ... Expected: ""Format error""; the field must be digits (left or right justified, as archive_ allows), and the component must lie within the archive. Test: bug22.ec. Bug 23: an archive whose bit count is not a whole number of words is accepted until its end, line 92 The archive's length is rounded up to a whole word, so its components are listed or processed before a format error is reported at the end: ac tl t_unaligned (t_ok plus one character) alpha ... beta ... archive: Format error in ...>t_unaligned.archive Expected: ""Format error"" at the start, with nothing listed or processed. Test: bug23.ec. Bug 24: a header that extends past the end of the archive is read, line 69 When 1 to 24 words remain after a component, the next header is read partly beyond the archive's bit count. Normally this produces a format error anyway. Found by inspection. Bug 25: offsets are computed with 17-bit precision, lines 36 and 61 Word offsets and the archive length are held as fixed bin (17) and computed with divide (..., 17, 0), limiting them to 131,071 words, while a segment can be 262,144 words. An offset derived from a corrupt bit count can also wrap around the segment, since it is not checked against the archive length before a pointer is formed. No failure was seen in tests on MR12.8 with archives over 128K words. Found by inspection. Bug 26: first_disected returns component outputs along with an error code, line 112 On a status error or an empty archive, the segment pointer, name and bit count outputs are filled from whatever the header pointer addresses. Expected: outputs cleared whenever the code is nonzero. Found by inspection. Bug 27: incorrect declarations, lines 34, 40, 103 and 135 hcs_$status_mins is declared with fixed bin (17) type and code arguments (actual: fixed bin (2) and fixed bin (35)); the error code parameters are fixed bin (17), though a full error_table_ code can be returned in them when the archive's status cannot be obtained; cv_dec_ is declared as a subroutine rather than a function. Found by inspection." Jim Lippard 421 ">doc>privileged should be included in default ""info"" search paths." Documentation MR12.8 MR12.9 defect Eric Swenson new 2026-10-03T21:23:28Z 2026-10-10T15:23:03Z "Because the default linker search paths include a broad set of Multics software, tools, commands, and administrative programs and scripts, there seems to be a general consensus that >doc>privileged (which documents many of the programs in the >tools directory) should be included in the default ""info"" search paths. The current default linker search paths are shown below. {{{ psp linker linker -initiated_segments -referencing_dir -working_dir system_library_standard system_library_unbundled system_library_1 system_library_tools system_library_network system_library_auth_maint }}} The current default info search paths are shown below. {{{ psp info info >doc>iml_info >doc>info >doc>aml_info }}} I recommend adding >doc>privileged after >doc>info in the default info search paths shown above. One could argue that since >standard_library_network is included in the default linker search paths, its info segment directory should also be included in the default info search paths: >doc>net I am not sure there is general consensus on this point, however. " Gary Dixon 422 ftp_dialup_ logs garbage for logout type upon ftp hangup Answering Service MR12.9 MR12.9 defect Eric Swenson new 2026-10-08T16:09:38Z 2026-10-08T16:20:14Z "When an FTP user hangs up, ftp_dialup_ receives a hangup event message. This message is binary. It is included in the LOGOUT AS log message as binary and therefore a log message like this results: {{{ 0830 as LOGOUT Swenson.SysAdmin.a int sty.sftp_01 0: 1 $0.08 (\400\000\000\002) }}} dialup_, which handles non-FTP, interactive logins and logouts, also logs an AS message upon hangup, but changes the 4-character logout type to ""hngp"" so that the message looks like: {{{ 0830 as LOGOUT Swenson.SysAdmin.a int d.h000 0: 1 $0.08 (hngp) }}} ftp_dialup_ should get updated to do as dialup_ does in this case, and set the logout type to ""hgnp""." Eric Swenson 424 cv_ptr_$terminate can cause termination of segment being initiated by segno Standard Library MR12.6e MR12.9 defect Gary Dixon accepted 2026-10-10T21:19:14Z 2026-10-10T21:20:58Z "If a program like area_status is invoked to display status information about the system free area, it can unintentionally terminate that segment by calling cv_ptr_$terminate as documented. Documentation says callers of cv_ptr_ should call cv_ptr_$terminate to remove a null reference name from count associated with the segment. But if such callers gave a segment number as input to cv_ptr_, the new cv_ptr_ does not initiate that segment with a null reference name (since it is already known to the process). It just returns a pointer to the segment. When the caller subsequently calls cv_ptr_$terminate for an outer-ring segment, a reference name will be removed from the segment. If the segment's null reference counter drops to zero, the segment will be made unknown to the process. A worst-case example: {{{ call cv_ptr_ [call get_system_free_area_ -out -return] -out -code -out -- Return from: cv_ptr_ ------- code02 OK retValue 247|0 r 14:02 0.150 17 call cv_ptr_$terminate 247|0 Fatal error. Process has terminated. Improper access on user's linkage segment. New process created. }}} This problem can occur more in a less-expected manner by invoking a command which calls cv_ptr_ with an input VIRTUAL_PTR string. {{{ area_status [call get_system_free_area_ -out -return] Busy Free Blocks 86 5 Words 66052 112 194932 words of virgin storage in 1 components. Zero on free in effect. Fatal error. Process has terminated. Improper access on user's linkage segment. New process created. }}} I think the old cv_ptr_ had this same problem. For callers of the new cv_ptr_$details entry point, the details returned to the caller along with the pointer indicate when cv_ptr_$terminate should not be called when the segment pointed to is: an inner-ring segment, or was already known to the process. But the cv_ptr_ interface has no way of knowing when it should or should not call cv_ptr_$terminate. I think the cv_ptr_ interface should always initiate an outer-ring segment with a null reference name, whether or not is was already known to the process. That way, the null reference name counter can be decremented without causing the segment to be made unknown to the process. " Gary Dixon 243 Dates with 2-digit year values after 2029 are assumed to be in the 20th century (e.g, 1930). General MR12.7 MR12.9 enhancement Eric Swenson new 2021-09-15T19:31:44Z 2026-10-11T05:03:08Z "The Y2K change for interpreting 2-digit year numbers will have problems for years later than 2129. A date like 30-12-18 would be interpreted as 1930-12-18 according to algorithm used in the current convert_date_to_binary_ code. It may be appropriate to interpret years before 1960 (the year of early Multics design papers) as being in the 21 century, rather than in the 20th century. The current code treats all 2-digit years < 30 as being in 21st century (e.g., 2125), and years in range 30 to 99 as being in the 20th century (e.g., 1950). The following example shows where the breakpoint lies in the current code: {{{ clock ^yc-^my-^dm 30-10-12 30-10-12 r 11:55 0.059 0 level 2 clock iso_date [clock ^yc-^my-^dm 30-10-12] 1930-10-12 r 11:55 0.377 0 level 2 clock ^yc-^my-^dm 29-10-15 29-09-15 r 11:56 0.054 0 level 2 clock iso_date [clock ^yc-^my-^dm] 2029-09-15 r 11:56 0.345 0 level 2 }}} " Gary Dixon 420 system_info_ entry points are poorly declared in both source and documentation. Administration MR12.6e No Milestore defect Eric Swenson new 2026-09-27T00:06:02Z 2026-09-27T00:07:25Z "The system_info_.pl1 source program does not declare the parameters expected by each of its external entry points. A few have their parameters declared fully; others declare some of the parameters but not all of them; and most of the entry points declare none of the expected parameters. The following except lines from system_info_.pl1 show this problem. {{{ installation_id: entry; sysid: entry; version_id: entry; session: entry; titles: entry; users: entry; timeup: entry; next_shutdown: entry; last_shutdown: entry; rates: prices: entry; rates_rs: prices_rs: entry (rs_number); device_rates: device_prices: entry (ndev, devp); device_rates_rs: device_prices_rs: entry (rs_number, ndev, devp); abs_limits: entry; default_absentee_queue: entry; abs_prices: entry; abs_prices_rs: entry (rs_number); io_prices: entry; io_prices_rs: entry (rs_number); abs_chn: entry (ev, pid); next_shift_change: entry (curshft, shftime, newshft, starttime); shift_table: entry (stt); request_chn: entry; access_ceiling: entry (access_ceiling); log_threshold: entry; level_names: entry; category_names: entry; ARPANET_host_number: entry; resource_price: entry (a_price_name, a_price, a_code); resource_price_rs: entry (rs_number, a_price_name, a_price, a_code); rs_name: entry (rs_number, rs_name, a_code); rs_number: entry (rs_name, rs_number, a_code); max_rs_number: entry (rs_count); trusted_path_flags: entry (stp); }}} Note that some of these entry points appear in the MPM Subroutines writeup for system_info_ with parameters fully specified. Other entry points are missing from the manual, but are fully declared in the system_info_.info segment. And most of the entry points have parameter attributes declarations in the >sss>pl1.dcl segment. However, while all of these entry points are retained by bound_info_rtns_.bind, some are not declared in MPM Subroutines writeup or the system_info_.info segment. The system_info_.pl1 code enables setting undeclared output values by treating then as command arguments. It calls cu_$arg_ptr to locate the char(*) argument, and sets its output value using the cu_-provided pointer and length. This practice may have stemmed from limitations of the v1pl1 compiler, but those have long since disappeared from Multics. - Code in system_info_.pl1 should be updated to declare all parameters for every external entry point, and to use those declarations to return output data to the caller. - Information in system_info_.info should be made fully consistent with the declared parameters, and provide documentation for all system_info_ external entry points. - All system_info_$XXX entry points listed in >sss>pl1.dcl should be removed. Some are incorrect, and none will be needed if the actual parameters are declared in the PL/I source program. The PL/I compiler will provide argument descriptors for these parameters. Until this issue is corrected, the user should refer to the MPM Subroutines or system_info_.info segment for correct calling sequence expected for each entry point. When this ticket is closed, all entry points should be properly declared in the source. The display_entry_point_dcl (depd) command and Emacs pl1dcl keystroke will provide correct documentation for each parameter. " Gary Dixon 127 Error: out_of_bounds at e_lap_|424 (>system_library_unbundled>bound_multics_emacs_) Unbundled Library defect Eric Swenson new 2018-07-07T13:29:52Z 2022-09-04T04:33:46Z "Error: out_of_bounds at e_lap_|424 (>system_library_unbundled>bound_multics_emacs_) referencing lisp.lists.!BBBKMQmMgXXwzW|776000 (in process dir) Attempt to access beyond end of segment Error: out_of_bounds at e_lap_|424 (>system_library_unbundled>bound_multics_emacs_) referencing lisp.lists.!BBBKMQmMgXXwzW|776000 (in process dir) Attempt to access beyond end of segment. r Trn.SysEng:>user_dir_dir>SysEng>Trn 09:23 07/07/18 0.171 1 level 2,16 probe Condition out_of_bounds raised at Block at lisp|34163|35014 (level 9). sk 15 command_processor_ 14 abbrev_processor 13 release_stack 12 unclaimed_signal 11 wall 10 any_other.2 9 Block at lisp|34163 out_of_bounds 8 lisp 7 >unb>bound_multics_emacs_ (alm) 6 emacs 5 emacs 4 command_processor_ 3 abbrev_processor 2 listen_ 1 initialize_process_ Emacs crash when using PgUp/PgDn" Trn 152 Scavenger not deleting orphan entries. Hardcore defect Eric Swenson new 2019-03-16T20:52:19Z 2026-10-13T19:41:14Z "My system has been salvaged and scavenged, but still contains VTOC entries that are orphans (not reachable from "">"") display_vtoce rpv 3 VTOCE ""process_dir_dir"" (Directory), vtocx 3 on pvtx 1 (rpv) UID: 505737623552, msl: 205, csl: 0, records: 0 Quota received (S D) (131071 131071) Time-record product (D) 1.5e-5 page-seconds updated at 2017-10-12 10:38:10.063360 pst. Created 2017-10-12 10:38:01.805824 pst Never dumped Used 2017-10-12 10:38:01.805824 pst Modified 2017-10-12 10:38:01.805824 pst ON: OFF: deciduous per_process nqsw master_dir nid ncd dnzp damaged synchronized fm_damaged fm_checksum_valid Access Class: system_low vtoc_pathname rpv 3 vtoc_pathname: Entry not found. Cannot completely convert uid path Pvtx 1 vtocx 3 = >-NOT-LISTED- " canthony 198 MRDS retrieve display is ill-formatted Tools defect Eric Swenson new 2020-01-29T03:52:00Z 2025-02-08T19:05:33Z "[http://ringzero.wikidot.com/wiki:cac-2020-01-28] Observed by Kazuhisa Shimizu {{{ cd db cwd db edm domain: char_12 char(12), char_5 char(5); attribute: name char_12, emp_num char_5, comp char_5; relation: Employee (name emp_num* comp), Comp_mgr (comp* emp_num); . w foo.cmdb q create_mrds_db foo Pers_Info -list edm dom: a bit; /* simplest possible database */ rel: b(a*); . w x.cmdb q cmdb x small -list create_mrds_dm_include Pers_Info -based mrds_call open Pers_Info eu mrds_call store 1 Employee name1 123 comp1 mrds_call retrieve 6 1 ""-range (e Employee) -select e"" -all }}} {{{ Values are: \000\000\000\000r_dir_dir>SysAdmin>Repair>db>Pers_Info.db \c \c exclusive_update \400\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000 \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000 \000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000 \c\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\ \c000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0 \c00\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00 \c0\000\000\000\000\000 name1 123 comp1 (END) }}} The ""\000"" seem to be in error. " charles.unix.pro@… 206 "plio2 fails to initialze fsb.iocb_p for ""get string"" construct." Hardcore defect Eric Swenson new 2020-04-17T01:30:10Z 2020-04-17T01:30:10Z "A pl1 program containing a line like: {{{ get string (translate (dottedaddr, "","", ""."")) list (fields); }}} was observed to work correctly but sometimes crash with a command fault in the plio2_ library. It was hypothesised that the random nature of the crashes pointed to an unitiailized stack variable. A version of the program that would fill the stack was fixed values was generated, experimentation showed that the plio2_ library was indeed using an uninitialized operand for a LPRP instruction, and if the two high bits in the uninitailzed operand were set, a command fault would occur (as per the LPRP instruction specification). It was observed that if the instruction did not fault, the plio2 library would return the correct result; it seemed somewhat odd that an accessing an unitiialized variable would return correct results. Investigation of the plio2_ source revealed the line: {{{ iocbp = ps.fsbp -> fsb.iocb_p; }}} The code was making a local copy of the variable, but not using it. The variable in question is a pointer to an iocb block for the file being operated on. For the case of ""get string"", there is no actual file; the fsb buffer pointer and length are set to the string being read from, and as the buffer is already full, iox is never invoked. Thus the local copy of iocb_p is never dereferenced, and the plio2 code works for get string. The plio2 code that sets up the fsb for ""get string"" operations was located and code to initialize the iocb was added. This resulted in code using ""get string"" to run without falling prey to random command faults. {{{ cpa base \cd_int; Comparison finished: 1 difference, 1 line. }}} " charles.unix.pro@… 222 save_dir_info mishandles names for branches saved in the .dir_info file Tools defect Eric Swenson new 2021-05-03T16:33:30Z 2021-05-03T16:33:30Z "The save_dir_info command (tool) has problems saving names of branches in a directory. The name count is mis-handled. For example, in the sseg internal procedure: {{{ sseg: proc; ec = 0; xxp = addr (seg_rec.brstat); call hcs_$status_long (dirname, en, 0, xxp, null, ec); if ec ^= 0 then return; }}} But later in that internal procedure, the data returned by hcs_$status_long is referenced using point '''p''' instead of pointer '''xxp'''. {{{ seg_rec.n_names = fixed (p -> branches.nname, 16); tp = addr (seg_rec.names); do j = 1 to seg_rec.n_names; tp -> names (j) = nptr -> names (j+k-1); end; next_xp = addr (seg_rec.end_seg_rec); seg_rec.fnext = rel (next_xp); oldxp = xp; xp = next_xp; end sseg; }}} Similar problems occur in internal procedures sdir and slink. This is an internal administrative tool which is seldom used (after the new storage system code gained stability). So it's not surprising these bugs have not been noticed. USERS of this tool should beware. Perhaps this tool (though documented in MPM Commands and in help files) should be moved to the obsolete library? " Gary Dixon 244 What????? Answering Service defect Eric Swenson new 2021-09-19T17:08:02Z 2021-09-19T17:08:02Z "Found in init_sst.pl1 ``` 355 if (scs$controller_data (i).online | scs$controller_data (i).offline) & base = 0 356 then begin; /* we found our bootload controller */ ``` How can you be running at all if the low memory controller is offline? This is equivalent to the ""Branch If Power Off"" instruction." canthony 246 "exercise_disk lacks test size control and ""progress bar""" Answering Service defect Eric Swenson new 2021-09-29T19:38:46Z 2021-09-29T19:38:46Z "exercise_disk's random test takes six and a half hours to run; it has no progress indication, nor a method for doing a shorter test. Add a ""-loops"" parameter to limit the size of the test. Add a ""progress bar"" during the test so as to allow an estimated time to completion. {{{ [pwd]>exercise_disk d501 cac -loops 10000 exercise_disk: Device type is d501 pack serial no. is cac exercise_disk: exercise_disk will destroy all data on this pack ! exercise_disk: Do You Wish To Continue? yes exercise_disk: Requesting mount of volume cac. exercise_disk: Begin random test on dskb_01 (d501) @ 1121.1 0%.........10%.........20%.........30%.........40%.........50%.........60%..... \c....70%.........80%.........90%.........100% exercise_disk: Testing Completed for dskb_01 (d501). Test Summary: Number of Sectors Written 5000 Number of Sectors Read 5000 }}} (Strictly speaking, ""-loops"" is a misnomer here; it actually sets the number of reads and writes, of which there are four for every loop.) " canthony 256 Multics allows a config deck with non-distinct SCU ports for multiple CPUs Hardcore MR12.5 defect Eric Swenson new 2021-11-03T01:42:27Z 2021-11-03T01:42:37Z "If you author a config deck with, say: {{{ cpu a 7 on dps8 70. 8. cpu b 7 off dps8 70. 8. }}} Multics doesn't warn you. If you then try to add the cpu designated as ""off"" in the config deck, Multics hangs." Eric Swenson 275 Transient failure Administration defect Eric Swenson new 2021-12-31T05:17:30Z 2021-12-31T05:17:30Z "{{{ eor -pch -raw fnp.6670.pol.32.h3 enter_output_request: Entry not found. Entry will not be submitted (>user_dir_dir>SysAdmin>Repair>5~fnp.6670.pol.32.h3). 0 requests in punch queue 3. r 21:03 0.157 3 ls fnp.6670.pol.32.h3 Segments = 1, Lengths = 3. r w 3 fnp.6670.pol.32.h3 r 21:13 0.067 0 eor -pch -raw fnp.6670.pol.32.h3 1 request submitted; 0 already in punch queue 3. r 21:14 0.084 0 }}}" canthony 279 PL/I generates incorrect code for divide operation specifying truncate or floor of quotient Administration defect Eric Swenson new 2022-02-20T22:43:36Z 2022-02-20T23:39:56Z "I am trying to implement an algorithm that wants the integer part of a division result, using float dec(59) data variables for dividend, divisor and quotient. The PL/I compiler generates code that ALWAYS rounds up the quotient, no matter what builtin functions surround the divide operation. {{{ bad_divide: proc(); dcl (dividend, divisor, product, quotient, quotient_t, quotient_f, quotient_d) float dec(59); dcl (divide, floor, trunc) builtin; dcl ioa_ entry() options(variable); divisor = 8.; dividend = 8.0779356694631608874161005084957309918536338955163955688476e+058; quotient = dividend / divisor; product = divisor * quotient; if product > dividend then call ioa_( ""quotient of divide was rounded up.""); dividend = 8.0779356694631608874161005084957309918536338955163955688476e+058; quotient_t = trunc( dividend / divisor ); product = divisor * quotient_t; if product > dividend then call ioa_( ""quotient using trunc was rounded up.""); dividend = 8.0779356694631608874161005084957309918536338955163955688476e+058; quotient_f = floor( dividend / divisor ); product = divisor * quotient_f; if product > dividend then call ioa_( ""quotient using floor was rounded up.""); dividend = 8.0779356694631608874161005084957309918536338955163955688476e+058; quotient_d = divide( dividend, divisor, 59 ); product = divisor * quotient_d; if product > dividend then call ioa_( ""quotient using divide was rounded up.""); end bad_divide; }}} Results from the bad_divide program prove that the quotient is being rounded up, because the divisor * quotient value is greater than the dividend. {{{ bad_divide quotient of divide was rounded up. quotient using trunc was rounded up. quotient using floor was rounded up. quotient using divide was rounded up. }}} In each case, the PL/I compiler generates code which does the divide operation, and is followed by an MVN to move the temporary result WITH ROUNDING to the quotient variable. It then calls whatever built-in function was specified to process this rounded-up result. Code for the simplest division (without a surrounding built-in function) is shown below. {{{ STATEMENT 1 ON LINE 11 quotient = dividend / divisor; 000104 aa 100 100 227 500 dv3d (pr),(pr),(pr) 000105 aa 6 00120 00 0075 desc9fl pr6|80,61 divisor 000106 aa 6 00100 00 0075 desc9fl pr6|64,61 dividend 000107 aa 6 00260 00 0077 desc9fl pr6|176,63 000110 aa 000 300 300 500 mvn (pr),(pr),round 000111 aa 6 00260 00 0077 desc9fl pr6|176,63 000112 aa 6 00160 00 0075 desc9fl pr6|112,61 quotient }}} Use of eis_tester shows that the dv3d instruction is generating the expected quotient with two fractional places added to the end to accommodate possible rounding. But the compiler ALWAYS adds a mvn instruction with ,round specified instead of conditionally doing the rounding unless suppressed by use of a trunc or floor built-in function. The following eis_tester script shows the dv3d instruction and its result. {{{ bad_divide_et_script 02/20/22 1431.5 pst Sun inst dv3d -nt ""divide using 3 arguments"" -mf1 ar -mf2 ar -mf3 ar; desc 1 -sd f -nn 61; /* float dec(59) divisor */ desc 2 -sd f -nn 61; /* float dec(59) dividend */ desc 3 -sd f -nn 63; /* float dec(61) quotient */ data 1 ""+"" (58) ""0"" ""8"" 000; /* divisor = 8.0 */ data 2 ""+80779356694631608874161005084957309918536338955163955688476"" 000; /* dividend = 8.0779356694631608874161005084957309918536338955163955688476e+058 */ data 3 ""+10097419586828951109270125635619663739817042369395494461060"" 000; /* quotient = 1.0097419586828951109270125635619663739817042369395494461060e+058 */ }}} Results of this script are shown below: {{{ eis_tester bad_divide_et_script -long ET TEST 1 (dv3d) Test Description: divide using 3 arguments Eis instruction: ( 354|4000 ) Ind Desc. - - - -- - - - 100100227500 100010000075 200020000075 300030000077 Pointer Registers: ( 354|20 ) pr0 - pr3 77777|1 361|1770 362|1760 363|1750 pr4 - pr7 77777|1 77777|1 77777|1 77777|1 Test Indicators: ( 354|111 ) 000000000200 This test will take 0 page faults. data field 1 ( 361|2000 ) 053060060060 060060060060 060060060060 060060060060 060060060060 060060060060 060060060060 060060060060 Previous line repeated 1 time. 060060060060 060060060060 060060060070 000 data field 2 ( 362|2000 ) 053070060067 067071063065 066066071064 066063061066 060070070067 064061066061 060060065060 070064071065 067063060071 071061070065 063066063063 070071065065 061066063071 065065066070 070064067066 000 data field 3 ( 363|2000 ) Result data field initialized to all zero bits. test data ( 354|23776 ) xxxxxxxxxxxx xxxxxxxxxxxx 053061060060 071067064061 071065070066 070062070071 065061061060 071062067060 061062065066 063065066061 071066066063 067063071070 061067060064 062063066071 063071065064 071064064066 061060066060 000xxxxxxxxx xxxxxxxxxxxx xxx Data resulting from test ( 1 - dv3d ) is incorrect. result data ( 363|1776 ) xxxxxxxxxxxx xxxxxxxxxxxx 053061060060 071067064061 071065070066 070062070071 065061061060 071062067060 061062065066 063065066061 071066066063 067063071070 061067060064 062063066071 063071065064 071064064066 061060065071 065060376xxx xxxxxxxxxxxx xxx *** TEST NOTES: divide using 3 arguments *** }}} Note that the result data represents the value: {{{ +1009741958682895110927012563561966373981704236939549446105950e-02 }}} If the trunc built-in was permitted to remove the fractional digits before rounding, this correct integer value would be obtained: {{{ +10097419586828951109270125635619663739817042369395494461059 }}} " Gary Dixon 285 input_history (ih) improperly handles input lines longer than the screen width General defect Eric Swenson new 2022-07-25T18:26:22Z 2022-07-25T18:26:22Z "With video system enabled and input_history command attached (as shown in pat output below)... {{{ pat user_terminal_ tc_io_ -login_channel stream_input_output error_output syn_ user_i/o -inh close get_line get_chars user_output syn_ user_i/o -inh close get_line get_chars user_input syn_ user_i/o -inh close put_chars user_i/o window_io_ user_terminal_ -first_line 1 -n_lines 77 -first_column 1 -n_columns 131 stream_input_output Video }}} the terminal setup is as follows: {{{ stty -all Type: VT102_132C_78L Modes: more_mode=scroll,more,ll=131,pl=77,^vertsp,can,erkl,esc,^rawo,^red,^ctl_char,^edited Erase: #, Kill: @ Frame_begin: \000, Frame_end: \000 Delays: vert_nl 0, horz_nl 0.500, const_tab 0, var_tab 0.000, backspace 0, vt_ff 0 output suspend: \023; output resume: \021 }}} When operating in this environment, a typed input line longer that the screen width is split into two input lines, as shown by the following command and its output. {{{ string ...5....1 ...5....2 ...5....3 ...5....4 ...5....5 ...5....6 ...5....7 ...5....8 ...5....9 ...5....0 ...5....1 ...5....2 ...5 \c....3 ...5....4 ...5....1 ...5....2 ...5....3 ...5....4 ...5....5 ...5....6 ...5....7 ...5....8 ...5....9 ...5....0 ...5....1 ...5....2 . r 11:11 0.136 0 Segment 5....3 not found. r 11:11 0.073 0 }}} In the exact same video environment but with input_history detached, the long command input line is handled properly: {{{ ih detach r 11:12 0.053 0 string ...5....1 ...5....2 ...5....3 ...5....4 ...5....5 ...5....6 ...5....7 ...5....8 ...5....9 ...5....0 ...5....1 ...5....2 ...5 \c....3 ...5....4 ...5....1 ...5....2 ...5....3 ...5....4 ...5....5 ...5....6 ...5....7 ...5....8 ...5....9 ...5....0 ...5....1 ...5....2 ...5....3 . \c..5....4 r 11:12 0.139 0 }}} " Gary Dixon 306 Multi-cpu configs don't properly update ASTE for prds on non-boot CPUs Hardcore defect Eric Swenson new 2023-05-01T17:02:39Z 2023-05-01T17:04:08Z "On GHM, I was researching length of prds (per-processor) segments. The config deck shows 2 cpus running. {{{ pcd cpu cpu a 7 on dps8 70. 8. cpu b 6 on dps8 70. 8. cpu c 5 off dps8 70. 8. cpu d 4 off dps8 70. 8. cpu e 3 off dps8 70. 8. cpu f 2 off dps8 70. 8. r 09:53 0.083 3 }}} But lengths reported for these prds files show a positive length only for the bootload CPU A. {{{ ls >sl1>*.prds Segments = 6, Lengths = 9. 9 cpu_A.prds 0 cpu_B.prds 0 cpu_C.prds 0 cpu_D.prds 0 cpu_E.prds 0 cpu_F.prds r 09:51 0.152 4 }}} Does this mean that when 2nd thru nth CPU is added, the dynamic CPU adding code does not properly update the ASTE for these prds file to reflect length of these segments (whose pages must be wired in memory)? I have not investigated this bug, but only entered it to record this anomaly. I was investigating bug #170 when I discovered this anomaly. " Gary Dixon 322 dump_segment -as ELEMENT fails to parse ELEMENT with negative array index Tools MR12.8 defect Eric Swenson new 2023-10-15T15:07:17Z 2023-10-15T15:07:17Z "The problem is illustrated by the following dump_segment (ds) command: {{{ ds 247|17240 -as ect_header.count""(-1)"" 017240 dump_segment: Code 18. Parsing structure ect_header.count(-1). }}} The full ect_header structure is properly displayed, including the count(-1) array element. {{{ dump_segment 234 -as stack_header.ect_ptr 000000 ect_ptr = 247|17240 [pd]>!BBBKXGGNBpjnQH.area.linker r 08:02 0.208 0 level 2 dump_segment 247|17240 -as ect_header 017240 ect_header @ 247|17240 ect_areap = 247|17170 [pd]>!BBBKXGGNBpjnQH.area.linker, ect_area_size = 1044, count (-1) = 0, count (0) = 39, count (1) = 38, count (2) = 1, count (3) through count (5) = 0 entry_list_ptrs (1) @ 247|17252 firstp = 247|17416 [pd]>!BBBKXGGNBpjnQH.area.linker, lastp = 247|20442 [pd]>!BBBKXGGNBpjnQH.area.linker entry_list_ptrs (2) @ 247|17256 firstp = 247|20406 [pd]>!BBBKXGGNBpjnQH.area.linker, lastp = 247|20406 [pd]>!BBBKXGGNBpjnQH.area.linker entry_list_ptrs (3) @ 247|17262 firstp = null, lastp = null entry_list_ptrs (4) @ 247|17266 firstp = null, lastp = null entry_list_ptrs (5) @ 247|17272 firstp = null, lastp = null meters @ 247|17276 total_wakeups = 1, total_wait_wakeups = 1, total_call_wakeups = 0, ittes_tossed = 1 seed = 4 flags @ 247|17303 mask_call_count = 0 OFF: call_priority, wakeup_control_points ecit_ptr = 247|17314 [pd]>!BBBKXGGNBpjnQH.area.linker, ecit_lth = 64, r_offset = 190230, r_factor = 10766514273, last_fast_channel_events = ""000000000000""b3 r 08:03 0.252 0 level 2 }}} Because dump_segment -as uses display services of the probe command, I suspect probe also has this difficulty. Because the analyze_multics (azm) request display (d) uses the dump_segment_ display capabilities, I suspect azm display request also has this problem. " Gary Dixon 335 PL/I addbitno builtin function generates incorrect code Standard Library MR12.8 defect Eric Swenson new 2024-03-04T03:01:26Z 2024-03-04T03:01:26Z "Code generated by the addbitno function fails to load the pointer to be adjusted before adding a bit offset. The assembler listing for a statement using addbitno is shown below. {{{ else P_arg_info.address = addbitno ( P_arg_info.address, P_arg_info.array_extent.element_offset * (P_arg_info.element.selected - P_arg_info.array_extent.lbound) ); 007737 aa 3 00104 3521 20 epp2 pr3|68,* P_arg_info.address 007740 aa 3 00114 3361 00 lcq pr3|76 P_arg_info.selected 007741 aa 000044 7770 00 llr 36 007742 aa 000044 7330 00 lrs 36 007743 aa 3 00107 0331 00 adl pr3|71 P_arg_info.lbound 007744 aa 000000 5330 00 negl 0 007745 aa 6 00100 7571 00 staq pr6|64 007746 aa 3 00111 2361 00 ldq pr3|73 P_arg_info.element_offset 007747 aa 6 00100 3521 00 epp2 pr6|64 007750 aa 0 00671 7001 00 tsx0 pr0|441 mpfx2 007751 aa 2 00000 5035 06 abd pr2|0,ql 007752 aa 3 00104 2521 00 spri2 pr3|68 P_arg_info.address }}} Notice that pr2 gets loaded by the first instruction, but later gets reused by the multiply operation in the second argument to the addbitno function. It never gets reloaded, so an address associated with the multiple gets stored into the P_arg_info.address value. An avoidance for this problem is shown below. The avoidance moves calculation of the bit offset into a separate statement stored in a new variable. This variable is then used as the bit offset addition in the addbitno builtin. {{{ 2121 dcl bit_offset fixed bin(24); ... else do; STATEMENT 1 ON LINE 2145 bit_offset = P_arg_info.array_extent.element_offset * (P_arg_info.element.selected - P_arg_info.array_extent.lbound); 007737 aa 3 00114 3361 00 lcq pr3|76 P_arg_info.selected 007740 aa 000044 7770 00 llr 36 007741 aa 000044 7330 00 lrs 36 007742 aa 3 00107 0331 00 adl pr3|71 P_arg_info.lbound 007743 aa 000000 5330 00 negl 0 007744 aa 6 00102 7571 00 staq pr6|66 007745 aa 3 00111 2361 00 ldq pr3|73 P_arg_info.element_offset 007746 aa 6 00102 3521 00 epp2 pr6|66 007747 aa 0 00671 7001 00 tsx0 pr0|441 mpfx2 007750 aa 6 00100 7561 00 stq pr6|64 bit_offset STATEMENT 1 ON LINE 2147 P_arg_info.address = addbitno ( P_arg_info.address, bit_offset ); 007751 aa 3 00104 3521 20 epp2 pr3|68,* P_arg_info.address 007752 aa 2 00000 5035 06 abd pr2|0,ql 007753 aa 3 00104 2521 00 spri2 pr3|68 P_arg_info.address STATEMENT 1 ON LINE 2148 end; }}} " Gary Dixon 338 The PL1 charno built-in function incorrectly evaluates a multi-element argument General MR12.8 defect Eric Swenson new 2024-08-16T07:13:32Z 2024-08-16T07:13:32Z "The following test program demonstrates several problems in handling of any multi-element or complicated argument given to the PL1 charno built-in function. charno is documented in the pl1.new_features.info segment as follows: The charno, bitno, wordno, and segno functions: These builtins extract information from pointers, and are defined as follows: C = charno (P); P must be a scalar pointer value. The result, C, is a real fixed binary of precision (21, 0), containing the zero origined character address of P [relative to baseptr(P) ]. However, the following test program demonstrates a significant failure in the compiler's handling of the argument to the charno built-in function. Arguments such as: charno( stmt.P ) charno( stmt.last_tokenP -> token.P ) are mishandled by the compiler in some unknown fashion. {{{ test_charno.pl1 08/15/24 2355.8 pdt Thu test_charno: proc(); dcl my_statement char(42) init( ""positional pos(1) ctl(-name -nm) required;"" ) int static options(constant); dcl semi_colon char(1) defined(my_statement) pos(42); dcl 1 auto_stmt aligned like stmt; dcl 1 (token1, token2) aligned like token; dcl (P1, P2) ptr, (n1, n2) fixed bin(21); dcl ioa_ entry() options(variable); dcl 1 stmt aligned based (stmtP), 2 P ptr unal, 2 L fixed bin(18), 2 first_tokenP ptr unal, 2 last_tokenP ptr unal, stmtStr char(stmt.L) based (stmt.P), stmtP ptr; dcl 1 token aligned based (tokenP), 2 P ptr unal, 2 L fixed bin(21), tokenP ptr, tokenStr char(token.L) based(token.P); tokenP = addr(token1); unspec(token) = ""0""b; token.P = addr(my_statement); token.L = 1; stmtP = addr(auto_stmt); unspec(stmt) = ""0""b; stmt.P = addr(my_statement); stmt.L = 1; stmt.first_tokenP = tokenP; tokenP = addr(token2); unspec(token) = ""0""b; token.P = addr(semi_colon); token.L = length(semi_colon); stmt.last_tokenP = tokenP; stmt.L = charno( stmt.last_tokenP -> token.P ) + stmt.last_tokenP -> token.L - charno( stmt.P ); call ioa_( ""First, tried to set stmt.L using the statement: stmt.L = charno( stmt.last_tokenP -> token.P ) + stmt.last_tokenP -> token.L - charno( stmt.P );"" ); call ioa_( ""^/Expect stmt.L to equal: 42 (000000000052)"" ); call ioa_( ""^19t Got: ^11d (^w)"", stmt.L, stmt.L ); /* ---------- */ call ioa_( ""^2/Second, tried to break down clauses in the expression."" ); call ioa_( "" A: n1 = charno( stmt.last_tokenP -> token.P );"" ); n1 = charno( stmt.last_tokenP -> token.P ); call ioa_( ""^19t Got: ^11d (^w)"", n1, n1 ); call ioa_( "" B: n2 = charno( stmt.P );"" ); n2 = charno( stmt.P ); call ioa_( ""^19t Got: ^11d (^w)"", n2, n2 ); call ioa_( "" stmt.L = n1 + stmt.last_tokenP -> token.L - n2;"" ); stmt.L = n1 + stmt.last_tokenP -> token.L - n2; call ioa_( ""^19t Got: ^11d (^w)"", stmt.L, stmt.L ); /* ---------- */ call ioa_( ""^2/Third, tried to remove pointer indirection from the """"A"""" charno argument."" ); call ioa_( "" A: P1 = stmt.last_tokenP -> token.P; n1 = charno( P1 );"" ); P1 = stmt.last_tokenP -> token.P; n1 = charno( P1 ); call ioa_( ""^19t Got: ^11d (^w)"", n1, n1 ); call ioa_( "" B: n2 = charno( stmt.P );"" ); n2 = charno( stmt.P ); call ioa_( ""^19t Got: ^11d (^w)"", n2, n2 ); call ioa_( "" stmt.L = n1 + stmt.last_tokenP -> token.L - n2;"" ); stmt.L = n1 + stmt.last_tokenP -> token.L - n2; call ioa_( ""^19t Got: ^11d (^w)"", stmt.L, stmt.L ); /* ---------- */ call ioa_( ""^2/Fourth, tried to remove structure element from """"B"""" charno argument."" ); call ioa_( "" A: P1 = stmt.last_tokenP -> token.P; n1 = charno( P1 );"" ); P1 = stmt.last_tokenP -> token.P; n1 = charno( P1 ); call ioa_( ""^19t Got: ^11d (^w)"", n1, n1 ); call ioa_( "" B: P2 = stmt.P; n2 = charno( P2 );"" ); P2 = stmt.P; n2 = charno( P2 ); call ioa_( ""^19t Got: ^11d (^w)"", n2, n2 ); call ioa_( "" stmt.L = n1 + stmt.last_tokenP -> token.L - n2;"" ); stmt.L = n1 + stmt.last_tokenP -> token.L - n2; call ioa_( ""^19t Got: ^11d (^w)"", stmt.L, stmt.L ); call ioa_( ""^2/Display of the entire stmtStr now works OK. stmtStr: """"^a"""";"", stmtStr ); call ioa_( ""^2/Thus, the charno built-in function appears to have argument processing problems."" ); end test_charno; }}} Results of running this program demonstrate that expected values were obtained only when a single scalar pointer was passed as the argument to charno. Attempting to pass a scaler pointer element of a containing structure did not work. {{{ test_charno First, tried to set stmt.L using the statement: stmt.L = charno( stmt.last_tokenP -> token.P ) + stmt.last_tokenP -> token.L - charno( stmt.P ); Expect stmt.L to equal: 42 (000000000052) Got: 9663676427 (110000000013) Second, tried to break down clauses in the expression. A: n1 = charno( stmt.last_tokenP -> token.P ); Got: 9741008906 (110447000012) B: n2 = charno( stmt.P ); Got: 77332480 (000447000000) stmt.L = n1 + stmt.last_tokenP -> token.L - n2; Got: 9663676427 (110000000013) Third, tried to remove pointer indirection from the ""A"" charno argument. A: P1 = stmt.last_tokenP -> token.P; n1 = charno( P1 ); Got: 41 (000000000051) B: n2 = charno( stmt.P ); Got: 77332480 (000447000000) stmt.L = n1 + stmt.last_tokenP -> token.L - n2; Got: -77332438 (777331000052) Fourth, tried to remove structure element from ""B"" charno argument. A: P1 = stmt.last_tokenP -> token.P; n1 = charno( P1 ); Got: 41 (000000000051) B: P2 = stmt.P; n2 = charno( P2 ); Got: 0 (000000000000) stmt.L = n1 + stmt.last_tokenP -> token.L - n2; Got: 42 (000000000052) Display of the entire stmtStr now works OK. stmtStr: ""positional pos(1) ctl(-name -nm) required;""; Thus, the charno built-in function appears to have argument processing problems. r 00:10 0.270 0 }}} " Gary Dixon 351 Emacs crashes with video invoked when requested Emacs line length exceeds Multics video line length. General MR12.8 defect Eric Swenson assigned 2025-03-03T21:20:35Z 2025-03-04T16:48:13Z "1. `stty -ttp vt102` 2. `wdc invoke` 3. `emacs -ll 104 >udd>Ring0>JJohnson>speed>instr_speed.pl1` 4. Hold down Control-N (scrollng down line by line). Once it scrolls to the line containing the ^L character, Emacs will crash: {{{ Error: emacs error by e_pl1_$signal_io_error|14573 (>system_library_unbundled>bound_multics_emacs_) The request was not within the boundaries of the requesting window. Emacs encou \cntered an error. Error from window_$<