__group__ ticket summary component version type owner status created _changetime _description _reporter 8 ISOLTS executes pas2 test harness incorrectly. General defect Eric Swenson new 2017-01-12T17:07:11Z 2017-01-12T17:07:11Z "Running the pas2 exec command 'hdump' produces an infinite listing of history resister values. " charles.unix.pro@… 26 Update clok card to support contemporary time zones Hardcore defect Eric Swenson new 2017-02-11T06:50:07Z 2017-02-11T06:50:15Z Bring the configuration deck 'clok' card time zone list up to contemporary usage. -- Charles 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 11 ISOLTS misses test opportunity Documentation enhancement Eric Swenson new 2017-02-05T18:38:17Z 2020-04-03T22:56:11Z "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 72 Self-destructive Salvage Behavior General defect Eric Swenson new 2017-04-05T21:18:06Z 2017-12-23T00:21:54Z "I once did a crash dump but did not do an esd afterwards. The volume was rebooted with rpvs, but the volume was badly damaged. I observed that the 'copy dump' step ran before the salvage completed and I hypothesis that this contributed to the poor state of the volume after salvaging. I see no reason why the 'copy dump' step should not wait for the salvage to complete. The data being copied is in the dump partition and should be completely untouched by the salvager; the copy operation will be adding segments to volume, and that should wait until salvaging is complete to avoid further damage to the volume. " charles.unix.pro@… 104 The behavior of the backup_dump does not match documentation w.r.t. '-nohold' Hardcore defect Eric Swenson new 2018-02-04T23:06:54Z 2018-02-04T23:06:54Z "The backup utilities are documented as unloading tapes by default, but do not. complete_dump.info, backup_dump.info, catchup_dump.info: {{{ -nohold rewinds and unloads the hierarchy dump tape or tapes at the end of the current dump pass. This is the default. }}} start_dump.info: {{{ -nohold rewinds and unloads the hierarchy dump tape or tapes at the end of the current dump pass. This is the default for all hierarchy dump modes except incremental. }}} {{{ bk_ss_.cds:       2 holdsw bit (1), /* ON => do not unmount tape when done */ bk_ss_.cds: bk_static.holdsw = ""0""b; }}}  bk_arg_reader_: {{{                else if op = ""hold"" then bk_ss_$holdsw = ""1""b; /* do not dismount */                else if op = ""nohold"" then bk_ss_$holdsw = """"b; /* dismount, default */ }}} then in start_dump.pl1, after 'examine_arguments:' (the ""join"" for complete_dump, catchup_dump, start_dump): {{{           bk_ss_$holdsw = ""1""b; }}} ""-nohold"" is also the documented behavior for 'retreive' and 'reload', but I have not tested the actual behavior. retrieve.info, reload.info: {{{ The following defaults are in effect for the reloader and retriever before any backup commands are given; they are not, however, reset to these values at the start of each backup command, except as noted below. -all -noquota -error_of -primary -map -reload -nodebug -setlvid -nohold -trim }}} " anonymous MR12.5 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 MR12.5 391 exec_com &condition_info_ptr parameter is mis-described. Documentation MR12.5 defect Eric Swenson new 2026-06-19T00:03:58Z 2026-06-19T15:28:31Z "The exec_com (version 2) program language includes a set of features which enable the program to establish an on-unit to handle one or more conditions that might occur while the program is executing. {{{ &on active_function_error &begin &set status_code &+ &[status_code_name &condition_name &condition_info_ptr] &print Condition &condition_name occurred to report event &print &"" "" at location &condition_info_ptr &print &"" "" with status code named: &(status_code) &goto EXIT &end string [path <><>] &label EXIT &quit }}} The &condition_info_ptr parameter is documented to expand to a virtual pointer (|) locating a condition_info structure describing the condition being handled. This description is wrong. &condition_info_ptr actually locates a condition_info_header structure that begins the specific data structure associated with the signaled condition named &condition_name. For example, the data structure associated with a command_error or active_function_error condition is called com_af_error_info. It is declared as shown below. {{{ /* BEGIN INCLUDE FILE com_af_error_info.incl.pl1 April 81 BIM */ /* format: style2 */ /* info structures for command error and active function error */ /* The include file condition_info_header must be included to */ /* use this file */ dcl com_af_error_info_ptr pointer; dcl 1 com_af_error_info aligned based (com_af_error_info_ptr), 2 header aligned like condition_info_header, 2 name_ptr ptr, 2 name_lth fixed bin, 2 errmess_ptr ptr, 2 errmess_lth fixed bin (21), 2 max_errmess_lth fixed bin (21), 2 print_sw bit (1); dcl com_af_error_info_version_3 internal static options (constant) init (3); /* END INCLUDE FILE com_af_error_info */ /* BEGIN INCLUDE FILE condition_info_header.incl.pl1 BIM 1981 */ /* format: style2 */ dcl condition_info_header_ptr pointer; dcl 1 condition_info_header based (condition_info_header_ptr) aligned, 2 length fixed bin, /* length in words of this structure */ 2 version fixed bin, /* version number of this structure */ 2 action_flags aligned, /* tell handler how to proceed */ 3 cant_restart bit (1) unaligned, /* caller doesn't ever want to be returned to */ 3 default_restart bit (1) unaligned, /* caller can be returned to with no further action */ 3 quiet_restart bit (1) unaligned, /* return, and print no message */ 3 support_signal bit (1) unaligned, /* treat this signal as if the signalling procedure had the support bit set */ /* if the signalling procedure had the support bit set, do the same for its caller */ 3 pad bit (32) unaligned, 2 info_string char (256) varying, /* may contain printable message */ 2 status_code fixed bin (35); /* if^=0, code interpretable by com_err_ */ /* END INCLUDE FILE condition_info_header.incl.pl1 */ }}} The value displayed by the &condition_info_ptr parameter is associated with a condition_info structure only in the sense that condition_info.info_ptr holds the value reported by that parameter. Executing an exec_com program with the statements above correctly reports the value stored in com_af_error_info.status_code. {{{ ec test_status Condition active_function_error occurred to report event at location 234|14716 with a status_code named: error_table_$bad_path r 16:54 0.192 7 level 2 }}} This documentation error should eventually be corrected. Meanwhile, this ticket can warn users about the documentation flaw in the Multics Commands and Active Functions (AG92-06B) page 3-322 where the &condition_info_ptr parameter is described. " gary.c.dixon@… MR12.5 392 compare_entry_names tool has several problems. Standard Library MR12.5 defect Eric Swenson new 2026-06-20T18:18:56Z 2026-06-20T18:18:56Z "PROBLEM 1: The compare_entry_names tool is documented to compare the names on two file system entries. {{{ help compare_entry_names -all >doc>info>compare_entry_names.info (14 lines in info) 1986-01-28 compare_entry_names, cen Syntax as a command: cen path1 path2 Function: compares the names on two entries in the storage system and prints information about the differences. Arguments: path1 is the pathname of the first entry. You can't use the star convention. path2 is the pathname of the second entry. You can use the equal convention. }}} However, because it chases links when locating the two ""entries"", it fails to compare names on a branch with names on a link to that branch that is located in a different directory. Instead, it compares unique IDs of the two entries and complains they are the same segment. The function it is actually performing should be called compare_branch_names. To correct this problem: A) calls to hcs_$status_long should pass a NO_CHASE argument value; and B) the code should check if either entry is a Link before comparing unique IDs of the two branches. If either is a Link, then it must skip unique ID comparison because Link entries do not have a unique ID. PROBLEM 2: Because of a well-known flaw in the design of the hcs_$status_ and hcs_$status_long interfaces, the names on the target entry may be allocated in an extension component of an extensible area, and therefore may not be addressable by the calling program. From status_structures.incl.pl1, the declaration for the name array returned by these two subroutines is declared as shown below. In declaring status_entry_names, the array is located by combining the baseptr of the FIRST component segment of the extensible area with a relative offset of the allocated array within SOME component segment of the extensible area. But the caller cannot tell which component holds the name array. That is the flaw. {{{ dcl 1 status_branch aligned based (status_ptr), 2 short aligned, 3 type fixed bin (2) unaligned unsigned, /* seg, dir, or link */ 3 nnames fixed bin (16) unaligned unsigned, /* number of names */ 3 names_relp bit (18) unaligned, /* see entry_names dcl */ ... dcl status_entry_names (status_branch.nnames) character (32) aligned based (pointer (status_area_ptr, status_branch.names_relp)); }}} compare_entry_names uses the area provided by get_system_free_area_ which is an extensible area. Therefore, it is susceptible to this problem. One possible solution is to use a non-extensible automatic area sufficiently large to hold the name array allocations. For example, an area of 17000 words is large enough to hold two 1000-entry name arrays, and would occupy only 17 pages of stack storage. PROBLEM 3: compare_entry_names tries to rejoin the directory and entryname portions of a pathname back together by just separating the two names with a greater-than (>) character. For example: {{{ call ioa_ (""^/Names unique to ^a>^a"", dname1, ename1); }}} This method fails for entries in the root (>) directory. It should be joining the two portions using the pathname_ subroutine." Gary Dixon MR12.5 405 Update >t>crossref.ec to include new >ldd>net library Tools MR12.5 defect Eric Swenson accepted 2026-08-31T16:34:03Z 2026-08-31T16:34:19Z "The crossref exec_com generates cross references of the Multics libraries. Now that the new network library has been added to the release, this exec_com needs to include this library in its ""total"" cross reference." Eric Swenson MR12.5 265 cref_analyze_ gives superfluous errors for non-object segments Tools MR12.5 defect Eric Swenson new 2021-12-04T18:59:04Z 2023-05-01T17:46:59Z "If you attempt to produce a crossref, you get lots of spurious errors from cref_analyze_ for every non-object segment it encounters (e.g. exec_coms, data files, etc.). The error messages look like: {{{ cref_analyze_: There is an internal inconsistency in the segment. volume_sys_vols.dump is non-object. }}} These should probably just be surpressed, as these are not really errors and muddy up the output so that real errors are obscured." Eric Swenson MR12.5 272 Crank runs give warnings about missing PDTs Administration MR12.5 issue Eric Swenson accepted 2021-12-24T17:25:53Z 2023-05-01T17:47:23Z "When you run the crank on a newly-coldbooted system, you get the following warnings: {{{ pdt_copy: Entry not found. Operator.pdt pdt_copy: Entry not found. HFED.pdt pdt_copy: Entry not found. Terminals.pdt compute_bill: Entry not found. Operator.pdt compute_bill: Entry not found. HFED.pdt compute_bill: Entry not found. Terminals.pdt update_pdts_from_reqfile: Entry not found. Operator.pdt update_pdts_from_reqfile: Entry not found. HFED.pdt update_pdts_from_reqfile: Entry not found. Terminals.pdt }}} These are not fatal, and probably even reasonable. It probably makes sense to NOT install the Operator, HFED, and Terminals projects automatically. However, if we agree that this is true, it might be nice to update the crank to not provide these warnings (or not). This ticket is here so that we can decide. " Eric Swenson MR12.6e 35 Finish support for passwords up to 32 characters in length General MR12.6e defect Eric Swenson new 2017-02-11T07:19:09Z 2017-02-11T07:20:44Z 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 MR12.6e 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 MR12.6e 69 Invoking trace_stack in admin mode crashes Multics Tools MR12.6e defect Eric Swenson new 2017-03-19T18:04:29Z 2021-12-28T23:12:26Z "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 MR12.6e 75 'lst' loops endlessly when encountering broken archive segment Standard Library MR12.6e defect Eric Swenson new 2017-05-15T22:59:57Z 2021-12-28T23:58:44Z "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@… MR12.6e 346 Several ipc_ entry points are not documented Documentation MR12.6e defect Eric Swenson new 2025-01-16T16:27:23Z 2025-01-16T16:27:23Z "[MTB-749;https://multicians.org/mtbs/mtb749.html] documents several ipc_ entry points which were apparently implemented in 1986 or later, but not included in >doc>info>ipc_.info. These include: {{{ pcref ipc_$create_event_channel References to ipc_$create_event_channel: (bound_ipc_ in HARDCORE) login_server_.pl1, mowse_io_.pl1, tc_io_.pl1, tty_.pl1, ws_packet_dispatcher_.pl1, ws_packet_receiver_.pl1 r 23:20 0.123 0 pcref ipc_$run_event_calls References to ipc_$run_event_calls: (bound_ipc_ in HARDCORE) wkp_signal_handler_.pl1 }}} Comparing the full list of ipc_ entry points retained in bound_ipc_: {{{ segname: bound_ipc_ symb|0 bind_map symb|0 symbol_table segnames: ipc_ convert_ipc_code_ text|3 block text|51 convert_ipc_code_ text|5 create_ev_chn text|7 create_event_channel (doc missing) text|11 cutoff text|13 decl_ev_call_chn (doc missing) text|15 decl_ev_wait_chn text|17 decl_event_call_chn text|21 delete_ev_chn text|23 drain_chn text|25 mask_ev_calls text|27 read_ev_chn text|31 reassign_call_channels (doc missing) text|33 reconnect text|35 reset_ev_call_chn (doc missing) text|37 run_event_calls (doc missing) text|41 set_call_prior text|43 set_wait_prior text|45 unmask_ev_calls text|47 wait_for_an_event }}} with the entry points documented in the info segment: {{{ Entry points in ipc_: ipc_$block ipc_$delete_ev_chn ipc_$set_call_prior ipc_$create_ev_chn ipc_$drain_chn ipc_$set_wait_prior ipc_$cutoff ipc_$mask_ev_calls ipc_$unmask_ev_calls ipc_$decl_event_call_chn ipc_$read_ev_chn ipc_$decl_ev_wait_chn ipc_$reconnect }}} " Gary Dixon MR12.6e 403 Add ipc_$read_ev_chn to pl1.dcl Tools MR12.6e defect Gary Dixon accepted 2026-08-31T01:43:52Z 2026-08-31T16:09:42Z "All of the external entry points of ipc_ are included in pl1.dcl (because they are all referenced via the ipc_.alm transfer vector) except for: ipc_$run_event_calls ipc_$read_ev_chn Because $run_event_calls entry point is only expected to be called by the wkp_signal_handler_, one could argue there is no need to include its declaration in the pl1.dcl segment. But if so, then why is its entry point documented in ipc_.info? Perhaps it should not be so documented. ipc_$read_ev_chn is definitely designed for use by IPC users, and therefore should be declared in pl1.dcl. This ticket recommends that repair. " Gary Dixon MR12.6e 406 Make fast event-wait channels easier to poll Administration MR12.6e enhancement Gary Dixon accepted 2026-09-01T15:22:33Z 2026-09-01T20:10:53Z "The Inter-Process Communication (IPC) facility provides 4 types of event channels for notifying a process of an external event: fast event-wait, (regular) event-wait, event-call and async event-call channel types. The caller of ipc_$create_event_channel selects one of these types when creating a new channel. - An event-wait channel receives events that are recorded as having occurred. The process owning the channel is awakened if it called ipc_$block to wait for an event on that channel. Or the owning process can call ipc_$read_ev_chn to check if the channel has received an event. An event_wait_info structure is returned to the caller by both of these subroutines. - A fast event-wait channel operates like a regular event-wait channel, but has no event record associated with each event. Instead there is one bit, the **fast event bit** which gets set to record that one or more events have been reported on that channel. Both ipc_$block and ipc_$read_ev_chn check and clear this bit when they report occurrence of the fast event-wait. It is one of 36 event bits stored in ipc_data_$fast_channel_events external static variable of the Event Channel Table (ECT). The other two types are the event-call channel, and async event-call channel. Neither of these two types factor into this discussion. For a fast event-wait channel, there should be some way to return a pointer to fast_event_bit. That would permit the owner of a channel to rapidly check if an event had been reported while his process had been blocked (preempted for quantum run-out, or waiting for a timer to expire, or perhaps calling ipc_$block directly to wait for other event-wait channels). This would allow the owner to poll event status directly. - If the owner found the fast_event_bit = ""1""b, the bit could be cleared (set to ""0""b) and the owner could then respond to the event (processing an pending inputs or outputs). - If the owner found the fast_event_bit = ""0""b, it would not necessarily mean the event had not received a wake-up. It might be that his process had not blocked in the past, so notification of the event might not have moved from the system-wide Interprocess Transmission Table (ITT) into the owner's Event Channel Table (ECT). To be sure no event had occurred, the owner could: Call ipc_$read_ev_chn to have IPS call its internal copy_itt_messages which moves data from the ITT into the ECT, and also updates fast event channel bits in ipc_data_$fast_channel_events bit array. The flag returned by ipc_$read_ev_chn would tell the owner definitely whether his channel's fast_event_bit had received a wake-up. Note that cost of checking and clearing the fast_event_bit is significantly less than the cost of calling ipc_$read_ev_chn. Depending upon the owner's non-polling activity, he might often find posting of that bit due to other blocking of his process; and thereby avoid the overhead of the ips_$read_ev_chn call. Therefore, this ticket requests an enhancement to ips_$create_event_channel to return a pointer to the fast_event_bit associated with a new fast event-wait channel as one of its output values. ----------- The input to ipc_$create_event_channel is a data structure. {{{ dcl 1 ipc_create_arg_structure aligned based (ipc_create_arg_structure_ptr), 2 version char (8) unaligned init(ipc_create_arg_structure_v1), 2 channel_type fixed bin, /* See constants below. */ 2 pad1 fixed bin, 2 call_entry variable entry (ptr), /* For event call channels -- who to call. */ 2 call_data_ptr ptr, /* For event call channels -- something to tell them. */ 2 call_priority fixed bin (17), /* For event call channels -- who's first? */ 2 pad5 fixed bin, ipc_create_arg_structure_ptr ptr; }}} When creating either regular or fast event-wait channel, only version and channel_type elements are referenced. The other elements relate to event-call channel creation. So my suggestion is to make use of the call_data_ptr element when creating a fast event-wait channel by having ipc_$create_event_channel make it point to the fast_event_bit associated with the newly-created channel. This could be done by adding two structures designed to create event-wait channels. {{{ dcl 1 ipc_create_wait_event aligned automatic, 2 version char (8) unaligned init(ipc_create_arg_structure_v1), 2 channel_type fixed bin init(WAIT_EVENT_CHANNEL_TYPE), 2 pad1 fixed bin, 2 pad2 variable entry (ptr), 2 pad3 ptr, 2 pad4 fixed bin, 2 pad5 fixed bin; dcl 1 ipc_create_fast_event aligned automatic, 2 version char (8) unaligned init(ipc_create_arg_structure_v1), 2 channel_type fixed bin init(FAST_EVENT_CHANNEL_TYPE), 2 pad1 fixed bin, 2 pad2 variable entry (ptr), 2 event_bit_ptr ptr init(null()), /* For fast event wait channels */ /* -- output ptr which locates fast_event_bit */ 2 pad4 fixed bin, 2 pad5 fixed bin, fast_event_bit bit(1) unaligned based (ipc_create_fast_event.event_bit_ptr); }}} ---------- In the current ipc_create_arg.incl.pl1, the existing ipc_create_arg_structure is declared: {{{ dcl 1 ipc_create_arg_structure aligned based (ipc_create_arg_structure_ptr), 2 version char (8) unaligned, /* From above. */ 2 channel_type fixed bin, /* See constants below. */ 2 call_entry variable entry (ptr), /* For event call channels -- who to call. */ 2 call_data_ptr ptr, /* For event call channels -- something to tell them. */ 2 call_priority fixed bin (17); /* For event call channels -- who's first? */ }}} The pad1 and pad5 elements are missing, but the gap between channel_type and call_entry still exists, because the entry data type must be aligned on an even-word boundary; and the pad5 word does exist because the entire structure is aligned on a double-word boundary and is an even number of words in length. Coding standards require that all space within a public structure be explicitly declared. So I have added the pad1 and pad5 elements to represent this hidden space in my proposal above." Gary Dixon MR12.6e 358 initiate command fails to handle allocation error from hcs_$status_ Administration MR12.6e defect Eric Swenson new 2025-04-10T13:41:24Z 2025-04-10T13:41:24Z "An hcs_$status_ call in initiate.pl1 can report an error_table_$notalloc error when it successfully allocates storage in an extensible area. Symptoms seen are shown in the com_err_ messages below. {{{ azm: ec event_channel_table.azmec initiate: Allocation could not be performed. Unable to get names of >udd>m>gd>w>ect>token initiate: Allocation could not be performed. Unable to get names of >udd>m>gd>w>ect>bit_string }}} In ect.azmec are two calls the initiate commands to ensure the uninstalled tools are found by the exec_com. {{{ e initiate &ec_dir>token -force -all &- - Needs new token command/AF used by this exec_com e initiate &ec_dir>bit_string -force -all &- - Needs new bit_string command/AF used by this exec_com }}} Since the error refers to failure to allocate names, I presume that code implementing the -all control argument is causing the problem. In initiate.pl1, -all turns on all_sw. Since we are supplying a full pathname to initiate command, the affected code is shown below. {{{ if ^got_path then do; call expand_pathname_ (arg, dn, en, code); if code ^= 0 then do; call com_err_ (code, ""initiate"", ""^a"", arg); return; end; got_path = ""1""b; if all_sw then do; got_refname = ""1""b; area_ptr = get_system_free_area_ (); on condition (cleanup) call clean_up; call hcs_$status_ (dn, en, fixed (chase_sw, 1), addr (branch_status), area_ptr, code); if code ^= 0 then do; call com_err_ (code, ""initiate"", ""Unable to get names of ^a^[>^]^a"", dn, dn ^= "">"", en); return; end; }}} Notice the”Unable to get names of …” error. The status code is error_table_$notalloc. From error_table_.alm: {{{ ec notalloc,, (Allocation could not be performed.) }}} The hcs_$status_ gate entry transfers to status_$status_ with an area_ptr set to the system free area for the user ring of the calling process. status_.pl1 references the error_table_$notalloc code in only one place: {{{ on area call fatal_error (error_table_$noalloc); if n_names_to_allocate > 0 then do; if have_s_permission then allocate return_names in (return_area) set (return_names_ptr); else n_names_to_allocate = 0; /* if no status, we have no name structure to copy */ end; if pathname_length_to_allocate > 0 then allocate return_pathname in (return_area) set (return_pathname_ptr); if return_names_ptr ^= null | return_pathname_ptr ^= null then do; if (return_names_ptr ^= null & baseno (return_names_ptr) ^= baseno (return_area_ptr)) | (return_pathname_ptr ^= null & baseno (return_pathname_ptr) ^= baseno (return_area_ptr)) then call fatal_error (error_table_$notalloc); }}} This code checks that both return_names_ptr and return_pathname_ptr are non-null and point to an allocation space in the first extent of the possibly extensible area pointer they were passed. {{{ 1 branch_status aligned, /* automatic: hcs_$status uses a pointer */ 2 type bit(2) unaligned, /* type of entry: link, segment, dir */ 2 number_names bit(16) unaligned, /* unused by directory_status_ */ 2 names_rel_pointer bit(18) unaligned,/* unused by directory_status_ */ ... }}} If the allocations were done in one of the additional extents of that area, then the allocated names array is returned as an offset value from the base of the return_area_ptr, but the allocated space is in a different segment (extent) than the first extent of that area. This is a limitation of the data return protocol of hcs_$status. The only way to avoid the problem is to pass in a non-extensible area which has enough space to hold the names array. For example, space for 100 segment names requires 3200 characters of storage (or 800 words). initiate.pl1 could create a 1-page area in its stack frame to hold this storage (rather than using the system free area). {{{ dcl area area (1024); call hcs_$status_ (dn, en, fixed (chase_sw,1), addr (branch_status), addr(area), code); }}} By using an automatic area, the cleanup condition handler is no longer necessary, because the area is abandoned when the initiate command returns to its caller. Initialization of the area is performed by the prologue code of the initiate entry point (the same code that pushes the stack frame and initializes other automatic variables). " Gary Dixon MR12.6e 360 ring0_get_ declares Multics status code parameter incorrectly Administration MR12.6e defect Gary Dixon accepted 2025-04-19T14:10:11Z 2026-09-01T19:58:08Z "The ring0_get_ subroutine was written in 1976 before Multics status code arguments were upgraded from a fixed bin aligned integer to a fixed bin(35) aligned encoding of a packed pointer. ring0_get_'s code parameter has never been upgraded from: dcl code fixed bin; to: dcl code fixed bin(35); Therefore, display_entrypoint_dcl (depd) and the emacs pl1dcl function return information about its entrypoint calling sequences ending with an incorrect code parameter declaration. It would be nice if this program's code argument declaration was changed to correct this problem. Meanwhile, programs declaring these entrypoints can manually change the declaration of the code argument to fixed bin(35). Storage for both fixed bin aligned and fixed bin(35) aligned values is the same size. This saves the programmer from having to declare an old_style_code variable to prevent the PL1 compiler from passing the normal code variable (fixed bin(35)) by value rather than by reference. " Gary Dixon MR12.6f 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 MR12.6f 156 Multics should fail to boot if 6601 console is not connected to IMU Hardcore MR12.6f defect Eric Swenson new 2019-03-30T05:07:57Z 2019-03-30T05:07:57Z "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 MR12.6f 188 Write up library maintenance and release-related processes for current Multics work Documentation MR12.6f task Eric Swenson new 2019-09-09T16:47:23Z 2019-09-09T16:47:23Z We should have some documentation in place to describe our Multics library maintenance and the processes for creating new releases. This should include any discussion of pnotices and software licenses, as well as conventions, rules, procedures, tools, etc. used in creating new releases. Eric Swenson MR12.6f 80 ALM crashes on syntax error Tools MR12.6f defect Eric Swenson new 2017-08-23T03:53:15Z 2023-05-01T17:45:48Z "pr crash1.alm crash1.alm 08/22/17 1950.2 pst Tue dec foo foo: end r 19:50 0.052 11 alm crash1 ALM 8.14 Error: illegal_procedure condition by decevl_$|572 (>system_library_standard>bound_alm_) referencing any_to_any_|1224 (>system_library_1>bound_library_wired_|46576) r 19:50 0.109 1 level 2 " charles.unix.pro@… MR12.6f 88 Document FIRST_TTY_BUF_PAGEX, dn355 DCWs, and IO page tables Documentation MR12.6f defect Eric Swenson new 2017-12-23T00:26:58Z 2017-12-23T04:02:37Z "In debugging ibm 3227 support in the emulator, a lot of time was wasted not understanding what the value of FIRST_TTY_BUF_PAGEX (dn355_data.incl.pl1) represented, what the value of tty_buf.absorig was used for, and how dn355 (and others) use DCWs passed through mailboxes and interpreted not by the IOM but by the FNP. It would be good to add some comments in dn355_data.incl.pl1 to document FIRST_TTY_BUF_PAGEX and in tty_buf.cds to document tty_buf.absorig. In the logic that uses tty_buf.absorig in computing addresses for DCWs passed through mailboxes to the FNP, some documentation would be helpful." Eric Swenson MR12.6f 101 When reloading a volume with the same name as a mounted volume rldr_check_pvol_ and rldr_input_ report inappropriate messages Hardcore MR12.6f defect Eric Swenson new 2018-01-18T23:18:38Z 2018-01-18T23:18:38Z "If you boot a system with a d451 RPV, and reload an rpv to a 3381 io drive, you see the following messages: {{{ 1512.9 RCP: Mounted copy of Storage System volume rpv on dska_00a for user I/O. 1512.9 RCP: Mounted IO volume on dska_00b for user I/O. 1512.9 RCP: Mounted IO volume on dska_00c for user I/O. rldr_check_pvol_: Reload may overflow volume rldr_check_pvol_: Disk label requires 27006 records; Volog label requires 29950 records on pv rpv rldr_check_pvol_: Reload may overflow vtoc rldr_check_pvol_: Disk label requires 13505 vtoce; Volog label requires 14974 vtoce on pv rpv reload_volume: Initialized physical volume rpv does not match online logical image. Do you wish to proceed M-> [auto-input] yes }}} These are not really appropriate messages. Of course the rpv-to-be-reloaded does not (necessarily) match the rpv that is mounted. But we shouldn't be comparing these two. The reload works perfectly fine, but the messages are wrong. Also, a little later in the reload, you see: {{{ rldr_input_: Please get the following input volumes : V01 reload_volume: Begin reload of volume rpv at 1512.9 Mounting tape V01 for reading 1512.9 RCP: Attached tapa_01 for Initializer.SysDaemon.z 1512.9 RCP: Note (tapa_01) - V01,sys 1512.9 RCP: Using Reel V01 on tapa_01 for Initializer.SysDaemon.z Mounted Multics volume ""V01"" (recorded at 800 BPI), on device tapa_01 rldr_input_: Warning - new disk type for rpv 1513.2 RCP: Detached tapa_01 from Initializer.SysDaemon.z rldr_input_: reloaded from input volume V01 112 records of 28 directories and 3323 records of 251 segments on pv rpv reload_volume: End reload of volume rpv at 1513.2 reload_volume: Reloaded on volume rpv 112 records of 28 directories and 3323 records of 251 segments and 0 null vtoces }}} The message: ""rldr_input_: Warning - new disk type for rpv"" is also not correct. We don't really care that the foreign system rpv is not of the same disk type as the system on which we're performing the reload. These messages should be suppressed when the reload is done to volumes that were init_vol'ed with ""-copy"". Not sure if that information is around by the time the reload happens though." Eric Swenson MR12.6f 107 AG93-05A documentation inaccuracies/omissions Documentation MR12.6f defect Eric Swenson new 2018-04-22T17:55:35Z 2023-07-10T23:37:25Z "Documentation for window_ is inaccurate/incomplete in the following ways: Page 3-264, GET CHARS OPERATION states: ""This operation returns exactly one character, unechoed, regardless of the size of the caller's buffer."" This is incorrect since window_io_iox_$get_chars echoes typed characters by default. This section also fails to explain that echoing can be controlled by the undocumented printer_on/printer_off CONTROL OPERATION. Missing printer_on/printer_off CONTROL OPERATION: The documentation for window_io_iox_$control fails to describe the printer_on and printer_off commands which enable or disable echoing of typed characters when window_io_iox_$get_chars is used. The documentation for these commands should describe them as needing no extra data to be passed to the control call (i.e., pass null ())." jcooperddtd@… MR12.6f 136 Error when exiting FAST subsystem Unbundled Library MR12.6f defect Eric Swenson new 2018-08-20T13:31:01Z 2019-05-26T00:02:48Z "At exit, the FAST subsystem throws an error which might be unexpected at logout. You can confirm this by logging in via the FAST process overseer (ex: login user -po >unb>fst_process_overseer_) and logging out: Error: finish condition by logout$|623 (>system_library_standard>bound_as_requests_) The issue does not present itself when executing FAST from your login process. DFAST, the related DTSS simulation, >unb>dfast_process_overseer_ pworks correctly. The issue does not affect the functionality of the FAST system." Trn MR12.6f 221 display_ttt with -of control argument is supposed to output ttf in formation that cv_ttf will accept Tools MR12.6f defect Eric Swenson new 2021-03-08T23:10:19Z 2021-03-08T23:10:19Z "The display_ttt command supports an -of control argument that writes the TTT to a file in TTF format. It is supposed to generate a TTF source file that is acceptable to cv_ttf. Instead, the resulting TTF cannot be compiled with cv_ttf. It gets this error message: {{{ display_ttt -of my_ttf.ttf r 15:07 4.471 44 cv_ttf my_ttf.ttf FATAL ERROR 37, SEVERITY 3 IN LINE 2868 Repetition factors nested too deep. SOURCE: initial_string: (111077) ESC ""z0"" CR ESC ""z1"" CR ESC ""z2"" CR ESC ""z3"" CR ESC ""z4"" \c CR ESC ""z5"" CR ESC ""z6"" CR ESC ""z7"" CR ESC ""z8"" CR ESC ""z9"" CR ESC ""z:"" CR ESC ""z;"" CR ESC ""z<"" CR ESC ""z="" CR ESC ""z>"" CR ESC "" \cz?"" CR ESC ""z@"" 177 ESC ""zA"" 177 ESC ""zB"" 177 ESC ""zC"" 177 ESC ""zD"" 177 ESC ""zE"" 177 ESC ""zF"" 177 ESC ""zG"" 177 ESC ""zH"" 1 \c77 ESC ""zI"" 177 ESC ""zJ"" 177 ESC ""zK"" 177 ESC ""zL"" 177 ESC ""zM"" 177 ESC ""zN"" 177 ESC ""zO"" 177 ESC ""zP"" CR ESC ""zQ"" CR ESC \c ""zR"" CR ESC ""zS"" CR ESC ""zT"" CR ESC ""zU"" CR ESC ""zV"" CR ESC ""zW"" CR ESC ""zX"" CR ESC ""zY"" CR ESC ""zZ"" CR ESC ""z["" CR ESC ""z\"" CR \cESC ""z]"" CR ESC ""z^"" CR ESC ""z_"" CR ESC ""z`"" 177 ESC ""za"" 177 ESC ""zb"" 177 ESC ""zc"" 177 ESC ""zd"" 177 ESC ""ze"" 177 ESC ""zf"" \c177 ESC ""zg"" 177 ESC ""zh"" 177 ESC ""zi"" 177 ESC ""zj"" 177 ESC ""zk"" 177 ESC ""zl"" 177 ESC ""zm"" 177 ESC ""zn"" 177 ESC ""zo"" 177 \c ESC ""A10"" RS ESC Y ESC 0 CR ESC 1 (13) <(10) ESC 1>; cv_ttf: Translation failed. r 15:07 12.752 431 }}} " john ata MR12.6f 226 reload_system_release of 12.7LDD_STANDARD produces an error file Hardcore MR12.6f defect Eric Swenson new 2021-06-15T02:37:46Z 2021-06-15T22:58:00Z "When reloading from 12.7LDD_STANDARD tape, a reload error file was created. The console shows: {{{ Input tape label: M-> 12.7LDD_STANDARD Mounting tape 12.7LDD_STANDARD for reading 1627.7 RCP: Attached tapa_02 for Initializer.SysDaemon.z 1627.7 RCP: Note (tapa_02) - 12.7LDD_STANDARD,sys CONSOLE: ALERT 1627.7 RCP: Mount Reel 12.7LDD_STANDARD without ring on tapa_02 for Initializer.SysDaemon.z attachTape selected unit 2 TAPE: unit is read only Mounted Multics volume ""12.7LDD_STANDARD"" (recorded at 800 BPI), on device tapa_02 Error file attached to file "">reload_dir>reload.06/14/21.1629.ef"". End of reel encountered. }}} The actual .ef file cannot be displayed until system is fully up in ring 4. I had to force SysAdmin.* access, adjust bit count on the .ef file, to display its contents. {{{ cwd >reload_dir r 16:58 0.033 10 ls -dtcm Segments = 2, Lengths = 26. 06/14/21 16:29 r w 0 reload.06/14/21.1629.ef 04/01/17 21:14 25 !BBBKLLcGDZxdbN.reload.map Multisegment-files = 2, Lengths = 704. 06/14/21 16:34 365 !BBBKQCGZjnDFJm.reload.map 04/01/17 21:30 339 !BBBKLLcGGZmxpj.reload.map r 17:10 0.053 0 sa **.ef rw *.SysAdmin r 17:01 0.034 0 abc reload.06/14/21.1629.ef -ch r 17:12 0.013 0 pr **.ef reload.06/14/21.1629.ef 06/14/21 1712.4 mst Mon hcs_$list_dir_fast: Allocation could not be performed. >library_dir_dir>include backup_load_dir_list: Allocation could not be performed. >library_dir_dir>inclu \cde r 17:12 0.030 0 }}} A quick comparison between GHM >ldd>include and the same directory on the reloaded system shows segment count and total records used in >ldd>incl on GHM versus my just-upgraded system are identical. I have no idea what might be causing the Allocation failure. What is hcs_$list_dir_fast? This problem deserves more investigation. " Gary Dixon MR12.6f 129 Add binary table to >doc>info>ascii_table.gi.info Documentation MR12.6f enhancement Eric Swenson new 2018-07-10T03:21:45Z 2023-05-01T17:46:28Z "Update ASCII chart to include the binary representation: 00 01 10 11 00000 NUL SP @ ` 00001 SOH ! A a 00010 STX "" B b 00011 ETX # C c 00100 EOT $ D d 00101 ENQ % E e 00110 ACK & F f 00111 BEL ' G g 01000 BS ( H h 01001 TAB ) I i 01010 LF * J j 01011 VT + K k 01100 FF , L l 01101 CR - M m 01110 SO . N n 01111 SI / O o 10000 DLE 0 P p 10001 DC1 1 Q q 10010 DC2 2 R r 10011 DC3 3 S s 10100 DC4 4 T t 10101 NAK 5 U u 10110 SYN 6 V v 10111 ETB 7 W w 11000 CAN 8 X x 11001 EM 9 Y y 11010 SUB : Z z 11011 ESC ; [ { 11100 FS < \ | 11101 GS = ] } 11110 RS > ^ ~ 11111 US ? _ DEL See http://m.trnsz.com:61800/doc/info/ascii_table.gi.info (if formatting here fails)" Trn MR12.6f 131 read_mail (rdm) enhancement for brief header display mode Unbundled Library MR12.6f enhancement Eric Swenson new 2018-07-15T03:29:58Z 2018-07-15T03:29:58Z "rdm would be greatly enhanced with an equivalent of Emacs rmail-header-format brief-formatting-mode. Modern internet header bloat makes handling intersystem Mail in rdm less than friendly. As rdm already support the ""-lghe"" control argument (long header), I propose that only a subset of important headers, ala rmail brief-formatting-mode be the default, and the full header can be displayed only if specifically requested. Other alternative implementations are possible and the proposal likely merits further discussion." Trn MR12.7 243 Dates with 2-digit year values after 2129 are assumed to be in the 20th century (e.g, 1930). General MR12.7 enhancement Eric Swenson new 2021-09-15T19:31:44Z 2023-09-05T08:29:46Z "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 MR12.7 248 mbuild should handle compiler pl1_macro -target L68 control argument. Tools MR12.7 enhancement Eric Swenson new 2021-10-06T18:05:39Z 2021-10-06T18:05:39Z "The mbuild subsystem should accept a build script source statement like: {{{ source: pc.pl1.pmac REPLACE compiler: pmac -target L68 -call ""pl1 -ot""; }}} which requests compiling macros in the source file for the L68 CPU type; then calling the pl1 compiler to process the result. Right now, mbuild '''compile''' request fails to accept the -target control argument; and its '''read''' request ignores the -target XXX specification, and improperly handles the -call QUOTED_STRING. It treats each components as a separate token. The parsed tokens are: -call ""pl1 -ot"" Also, the '''compile''' request should be able to insert its optional control args (-list and -table) into the operand of the quoted -call control arg, if either/both of those options are given in the compile line. More specifically, that means the request: ''' `compile **.pmac -list -table` ''' should process the source statement above by generating the following command line: {{{ pl1_macro pc.pl1 -target L68 -call ""pl1 -ot -list -table"" }}} Right now, either the read or analyze request ignores the -target option in the source line, and the compile request produces the following output: {{{ mbuild: comp **.pmac -list -table mbuild (compile): COMPILE structure not found. **.pmac mbuild: }}} Eliminating use of the star convention to identify the segment to be compiled still produces errors: {{{ mbuild: comp pc.pl1.pmac -list -table ---------- pmac pc.pl1.pmac -call ""pl1 -ot"" -list List not yet implemented. pl1_macro 2.0 SEVERITY 2 ERROR ON LINE 6 %target used without use of -target control arg. L68 assumed. SOURCE: %if %target (L68) %then pl1_macro: Errors in macro processing; output segment may be suspect. mbuild (compile): Compile did not produce an object segment. COMPILE: pc.pl1.pmac mbuild: }}} pl1_macro does not support -list or -table (unless these are manually inserted into the operand of its -call control argument. The compile request would have to learn to do that. And the -target L68 control (from the build script file) was ignored by read, and therefore not present in the command line invoking pl1_macro. " Gary Dixon MR12.7 286 mbuild should detect when segments in install directory match components in archives Tools MR12.7 defect Gary Dixon assigned 2022-08-03T01:15:12Z 2023-04-30T18:27:36Z "If, in order to fix a compilation bug, you extract a source program from a source archive, fix the bug, and then reinvoke mbuild, it doesn't notice that there exists a segment (modified in this case) in the install directory that matches a component in the source archive. The ""compile"" request works fine -- and compiles the standalone segment, but the source archive is not updated. The bad source (in the archive) is installed. If you later delete the install directory, the fixes you made are lost. Recommend that mbuild warn if there exists a standalone segment in the source archive that matches a component in a source (or object) archive." Eric Swenson MR12.7 308 """help ls"" hangs mid output" General MR12.7 defect Eric Swenson new 2023-07-25T12:20:09Z 2023-07-25T12:20:09Z "I tried on linux x86_64 and MacOS (Intel) with a fresh download and after I log in as user Repair and change the password, ""help ls"" works until displaying -name, -nm print names column. then hangs (Ctrl-C works). Other help output works correctly." olf@… MR12.7 292 Add support to help and help_ to use -referencing_dir to locate info segments Tools MR12.7 enhancement Gary Dixon assigned 2022-10-07T16:18:12Z 2022-10-08T14:19:12Z "Since the info search path already supports -referencing_dir and this is included in the default search path, it might be nice to add the following feature: if ""help foo"" is invoked, and foo is a program found in the search rules, but in a non-standard library, and if -referencing_dir is present in the info search paths, then look for a ""foo.info"" segment in the same directory where ""foo"" is found." Eric Swenson MR12.8 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 MR12.8 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 MR12.8 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 MR12.8 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_$<