1 
  2 09/23/87  Satellite_6M
  3 Known errors in the current release of Satellite_6M.
  4 #         Associated TR's
  5 Description
  6 
  7 57  phx18766
  8 The TR says that 1 too many characters are created when a character is
  9 decompressed.  Assuming this is true, it comes from a
 10 mis-interpretation of the RBF spec.  That is, apparently the
 11 compression count includes the character that was compressed, whereas,
 12 I assumed it did not.  The fix is to change line 769 in rbf_.pl1 to set
 13 the compression_count to 1, and change line 778 to use
 14 compression_count - 1, rather than compression_count.
 15 
 16 56  phx17349
 17 The network_request command (in l6_tran_$parser) should not check for
 18 11 arguments, since there may legally be more than 11.  In trying to be
 19 user friendly, I miscounted the maximum number of arguments.
 20 
 21 52  phx16410
 22 The 6M PAD command implements a feature which allows the definition of
 23 a "rotary group" of x25 subchannels for use by the PAD.  The TRANX
 24 command does not implement this rotary feature, but it should.  The
 25 documentation should make this clear, and it should be changed in the
 26 next release to do the rotary connect.
 27 
 28 51
 29 The nr command and the l6_tran_overseer_ should allow transfer of
 30 Multics multi-segment files.  These are currently rejected by a status
 31 check which finds them to be directories.
 32 
 33 49  phx15902
 34 This TR describes one problem with sending multiple files from Multics
 35 to the L6.  I do not have this problem at CISL, however, when I
 36 transfer multiple files they all get concatenated into the first file.
 37 
 38 48  phx15897
 39 There seems to be some problem with the configuration specified in the
 40 TR which causes the DPS6 to hang when Multics tries to initiate a
 41 connection to it.  This does not occur at any other site, and it is not
 42 known if it occurs here with MOD400 Rel.  3.0.  As reported, this also
 43 occurs with Rel.  3.0.  No other site has this problem, so it must
 44 still be something to do with the configuration.
 45 
 46 47  phx15893
 47 The 6M PAD will not interrupt a partial input line with pending output.
 48 This is because of the way ATD works, and the fact that the terminal
 49 connection is really handled in a half-duplex fashion.
 50 
 51 46  phx15894
 52 The 6M PAD outputs a LF character when it forwards a long line due to
 53 exceeding the packet character count.  This is probably caused by the
 54 interaction between the PAD and ATD.  The PAD puts up a read that
 55 terminates either with a CR or on character count.  If it terminates on
 56 character count, ATD outputs a LF gratuitously.
 57 
 58 The other problem associated with this is if the DPS6 line and
 59 character editing characters are used, they can only affect the
 60 untransmitted portion of the input line.  Thus if you type a long line,
 61 part of which is forwarded, and then type @ to delete the line, only
 62 the untransmitted portion will be deleted.
 63 
 64 45  phx15932
 65 The PAD can run in a swap pool, but not if it is being used through
 66 RNP.  If these are to be run together, make sure the PAD is not in the
 67 swap pool.
 68 
 69 43  phx15770
 70 In order for the PAD to correctly handle escape sequences which may be
 71 sent at line speed (e.g from a function key), it buffers up things that
 72 start with ESC until it gets another character.  This causes a problem
 73 with emacs ITS search mode which ends things with ESC.  See error list
 74 entries 30 and 2 for the related problems.  THis limitation will be
 75 noted in the documentation.
 76 
 77 41  phx15761
 78 The 6M PAD should allow a TTY configured as '7300' to be used.  It
 79 should also print an error message if an unsupported terminal type is
 80 used, rather than quietly returning to L6 command level.
 81 
 82 40  phx15760
 83 TRANX must log into Multics to initiate a file transfer.  Currently it
 84 uses a very simple-minded parse of the greeting banner to find out
 85 where to send the user login line and password.  This fails when
 86 padding characters are sent as part of the greeting banner and password
 87 prompt.  (For instance, if the default terminal type for the login
 88 channel specifies output padding.)
 89 
 90 39  phx15759
 91 The L6 file transfer protocol as implemented by the TRANX command is
 92 not very good at interpreting errors from the host.  The protocol
 93 should be modified to correctly diagnose and report errors to the L6
 94 user.
 95 
 96 36
 97 In Mod 400 release 3.0, there is a problem with the handling of the
 98 operating system clock.  It cannontt be turned off.  This causes any
 99 breakall mode application not to work (e.g.  emacs, video).
100 
101 34
102 When transferring a very large file from the L6 to Multics (initiated
103 by the L6), the Multics side seems to get a fatal process error.  This
104 seems to be dependent of the baud rate of the connection, ie.  at
105 slower speeds this happens sooner, and at higher speeds it takes
106 longer.  According to the stack of the dead process, l6_tran_overseer_
107 returned to initialize_process, something it should not do.
108 
109 33
110 The PAD occasionally terminates a connection with the message:  "APAD:
111 (830603) 35 BLOCK RETURNED IS NOT WITHIN ITS OWN MEMORY POOL".  This
112 mostly seems to happen on a 9600 baud terminal connection.  After it
113 happens the user can reinvoke the PAD and connect again.
114 
115 31
116 The L6 can only handle file names of 12 characters or less.  When doing
117 a starname type of transfer from Multics, if one of the Multics segment
118 names is more than 12 characters, the transfer will abort.  This is
119 also true if the user types in a name longer than 12 characters by
120 hand.
121 
122 27
123 When using TRANX initiated from Multics the following rules must be
124 followed in configuring the x.25 connection.  First, the packet size on
125 both the Multics and L6 sides must be 128 (this is the default, so the
126 best bet is not to use the "packet_size" argument in the TTF).  Second,
127 the baud_rate in the CMF for the channel should be set to at least
128 9600, regardless of whether the actual physical connection is slower
129 than that.  This baud rate is not used for any physical parameters and
130 only affects the minimum tty buffer size used for the channel.
131 
132 18  phx15764 phx15907 phx15912
133 The L6 PAD handles PAD parameter 3 set to 2 (forward on CR)
134 incorrectly.  When parameter 3 is set to 2, the L6 PAD uses L6
135 character erase/kill and backslash processing on the input line (i.e.
136 @ deletes a char, ^X deletes the line, and \ is an escape character
137 locally).  This is because the PAD does line at a time input through
138 ATD which is where this editing is done.
139 
140 17  phx15791
141 While in the video system, i.e.  with PAD parameter 2 set to "no echo",
142 typing a ^G causes an immediate bell, and also sends the ^G to Multics.
143 This is probably caused by the ATD handler echoing a bell on receipt of
144 the ^G.  There should be a way to get the correct behavior.
145 
146 14
147 It is very easy to get the L6 to stop listening to a terminal, and it
148 is very hard to get it back.  That is, none of the documented ways
149 (SET_LISTEN, etc.)  seems to work.  The only solution seems to be to
150 reboot the L6
151 
152 13
153 The PAD should not discard characters when the PAD parameters change in
154 most cases.  For instance, when echoing is turned off to mask the
155 password.  Recomendation X.29, section 3.1.2 says:  "The PAD will also
156 consider the arrival of such a PAD message [set, read, or set and read]
157 as a data forwarding condition in the direction PAD to packet mode
158 DTE."
159 
160 9
161 The L6 PAD has problems communicating with a terminal connected to the
162 L6 through the RNP6 network software.  The main problem seems to be tha
163 RNP cannot handle character at a time reads from the PAD.  Currently,
164 since Multics sets PAD parameter 3 to 2 (forward on CR) by default, and
165 this causes the PAD to do line at a time reads, the RNP network can be
166 used through the PAD.  However, the solution to error #18 will probably
167 have some impact on this behavior.
168 
169 5
170 A VIP7801 terminal connected to the L6 must be configured as a TTY or
171 '7200' type device in the CLM_USER file if it will use the PAD to
172 connect to Multics.  No functionality is lost because all normal
173 Multics terminal handling is available once the connection is made.
174 
175 4
176 A terminal which is going to use the L6 PAD command to make a
177 connection to Multics must be connected to the L6 through an MLCP
178 channel.  It can not be connected through a MDC channel.  Also, the
179 channel must be configured in the CLM_USER file using the ATD directive
180 (not TTY or KSR).
181 
182 3  phx14985 phx15794 phx17276
183 The L6 PAD sometimes can not keep up with fast typing and looses input.
184 This is signalled by a "beep".  The user must retype the input.  This
185 problem is especially visible when input is typed while output is
186 coming to the terminal.  This is probably caused by the fact that the
187 ATD handler gives priority to writes to the terminal rather than to
188 reads from the terminal.
189 
190 1  none
191 The answering service and the x25 multiplexer sometimes get out of
192 sync.  The AS thinks a subchannel is attached or listening, and the
193 multiplexer thinks it is hungup.  This mostly seems to happen when
194 there are two or more slave subchannels defined with user data fields,
195 and, and only one is attached.  When the other end of the connection
196 disconnects, sometimes, the multiplexer recognizes it, but the AS does
197 not.  So, a subsequent connect with that user call data gets the second
198 subchannel (to which no one is attaching), while the first subchannel
199 does not know it has been hungup.