09/23/87 Satellite_6M Known errors in the current release of Satellite_6M. # Associated TR's Description 57 phx18766 The TR says that 1 too many characters are created when a character is decompressed. Assuming this is true, it comes from a mis-interpretation of the RBF spec. That is, apparently the compression count includes the character that was compressed, whereas, I assumed it did not. The fix is to change line 769 in rbf_.pl1 to set the compression_count to 1, and change line 778 to use compression_count - 1, rather than compression_count. 56 phx17349 The network_request command (in l6_tran_$parser) should not check for 11 arguments, since there may legally be more than 11. In trying to be user friendly, I miscounted the maximum number of arguments. 52 phx16410 The 6M PAD command implements a feature which allows the definition of a "rotary group" of x25 subchannels for use by the PAD. The TRANX command does not implement this rotary feature, but it should. The documentation should make this clear, and it should be changed in the next release to do the rotary connect. 51 The nr command and the l6_tran_overseer_ should allow transfer of Multics multi-segment files. These are currently rejected by a status check which finds them to be directories. 49 phx15902 This TR describes one problem with sending multiple files from Multics to the L6. I do not have this problem at CISL, however, when I transfer multiple files they all get concatenated into the first file. 48 phx15897 There seems to be some problem with the configuration specified in the TR which causes the DPS6 to hang when Multics tries to initiate a connection to it. This does not occur at any other site, and it is not known if it occurs here with MOD400 Rel. 3.0. As reported, this also occurs with Rel. 3.0. No other site has this problem, so it must still be something to do with the configuration. 47 phx15893 The 6M PAD will not interrupt a partial input line with pending output. This is because of the way ATD works, and the fact that the terminal connection is really handled in a half-duplex fashion. 46 phx15894 The 6M PAD outputs a LF character when it forwards a long line due to exceeding the packet character count. This is probably caused by the interaction between the PAD and ATD. The PAD puts up a read that terminates either with a CR or on character count. If it terminates on character count, ATD outputs a LF gratuitously. The other problem associated with this is if the DPS6 line and character editing characters are used, they can only affect the untransmitted portion of the input line. Thus if you type a long line, part of which is forwarded, and then type @ to delete the line, only the untransmitted portion will be deleted. 45 phx15932 The PAD can run in a swap pool, but not if it is being used through RNP. If these are to be run together, make sure the PAD is not in the swap pool. 43 phx15770 In order for the PAD to correctly handle escape sequences which may be sent at line speed (e.g from a function key), it buffers up things that start with ESC until it gets another character. This causes a problem with emacs ITS search mode which ends things with ESC. See error list entries 30 and 2 for the related problems. THis limitation will be noted in the documentation. 41 phx15761 The 6M PAD should allow a TTY configured as '7300' to be used. It should also print an error message if an unsupported terminal type is used, rather than quietly returning to L6 command level. 40 phx15760 TRANX must log into Multics to initiate a file transfer. Currently it uses a very simple-minded parse of the greeting banner to find out where to send the user login line and password. This fails when padding characters are sent as part of the greeting banner and password prompt. (For instance, if the default terminal type for the login channel specifies output padding.) 39 phx15759 The L6 file transfer protocol as implemented by the TRANX command is not very good at interpreting errors from the host. The protocol should be modified to correctly diagnose and report errors to the L6 user. 36 In Mod 400 release 3.0, there is a problem with the handling of the operating system clock. It cannontt be turned off. This causes any breakall mode application not to work (e.g. emacs, video). 34 When transferring a very large file from the L6 to Multics (initiated by the L6), the Multics side seems to get a fatal process error. This seems to be dependent of the baud rate of the connection, ie. at slower speeds this happens sooner, and at higher speeds it takes longer. According to the stack of the dead process, l6_tran_overseer_ returned to initialize_process, something it should not do. 33 The PAD occasionally terminates a connection with the message: "APAD: (830603) 35 BLOCK RETURNED IS NOT WITHIN ITS OWN MEMORY POOL". This mostly seems to happen on a 9600 baud terminal connection. After it happens the user can reinvoke the PAD and connect again. 31 The L6 can only handle file names of 12 characters or less. When doing a starname type of transfer from Multics, if one of the Multics segment names is more than 12 characters, the transfer will abort. This is also true if the user types in a name longer than 12 characters by hand. 27 When using TRANX initiated from Multics the following rules must be followed in configuring the x.25 connection. First, the packet size on both the Multics and L6 sides must be 128 (this is the default, so the best bet is not to use the "packet_size" argument in the TTF). Second, the baud_rate in the CMF for the channel should be set to at least 9600, regardless of whether the actual physical connection is slower than that. This baud rate is not used for any physical parameters and only affects the minimum tty buffer size used for the channel. 18 phx15764 phx15907 phx15912 The L6 PAD handles PAD parameter 3 set to 2 (forward on CR) incorrectly. When parameter 3 is set to 2, the L6 PAD uses L6 character erase/kill and backslash processing on the input line (i.e. @ deletes a char, ^X deletes the line, and \ is an escape character locally). This is because the PAD does line at a time input through ATD which is where this editing is done. 17 phx15791 While in the video system, i.e. with PAD parameter 2 set to "no echo", typing a ^G causes an immediate bell, and also sends the ^G to Multics. This is probably caused by the ATD handler echoing a bell on receipt of the ^G. There should be a way to get the correct behavior. 14 It is very easy to get the L6 to stop listening to a terminal, and it is very hard to get it back. That is, none of the documented ways (SET_LISTEN, etc.) seems to work. The only solution seems to be to reboot the L6 13 The PAD should not discard characters when the PAD parameters change in most cases. For instance, when echoing is turned off to mask the password. Recomendation X.29, section 3.1.2 says: "The PAD will also consider the arrival of such a PAD message [set, read, or set and read] as a data forwarding condition in the direction PAD to packet mode DTE." 9 The L6 PAD has problems communicating with a terminal connected to the L6 through the RNP6 network software. The main problem seems to be tha RNP cannot handle character at a time reads from the PAD. Currently, since Multics sets PAD parameter 3 to 2 (forward on CR) by default, and this causes the PAD to do line at a time reads, the RNP network can be used through the PAD. However, the solution to error #18 will probably have some impact on this behavior. 5 A VIP7801 terminal connected to the L6 must be configured as a TTY or '7200' type device in the CLM_USER file if it will use the PAD to connect to Multics. No functionality is lost because all normal Multics terminal handling is available once the connection is made. 4 A terminal which is going to use the L6 PAD command to make a connection to Multics must be connected to the L6 through an MLCP channel. It can not be connected through a MDC channel. Also, the channel must be configured in the CLM_USER file using the ATD directive (not TTY or KSR). 3 phx14985 phx15794 phx17276 The L6 PAD sometimes can not keep up with fast typing and looses input. This is signalled by a "beep". The user must retype the input. This problem is especially visible when input is typed while output is coming to the terminal. This is probably caused by the fact that the ATD handler gives priority to writes to the terminal rather than to reads from the terminal. 1 none The answering service and the x25 multiplexer sometimes get out of sync. The AS thinks a subchannel is attached or listening, and the multiplexer thinks it is hungup. This mostly seems to happen when there are two or more slave subchannels defined with user data fields, and, and only one is attached. When the other end of the connection disconnects, sometimes, the multiplexer recognizes it, but the AS does not. So, a subsequent connect with that user call data gets the second subchannel (to which no one is attaching), while the first subchannel does not know it has been hungup. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved