Trailing-Edge - PDP-10 Archives - bb-bt99g-bb - anfv23.d10
There is 1 other file named anfv23.d10 in the archive. Click here to see a list.
                 EDIT DESCRIPTIONS FOR ANF10-V23                                
                             EDIT 91     FOR ANF
     Incorrect TAB simulation for ANF10 terminals.
     The column counter can become negative if the first character  on
a  line is a backspace.  If the next character is a horizontal TAB, it
will be simulated by only one space.
     Check the column counter when outputting a backspace.  If  it  is
negative, put it back to zero.  See related filcom.
                             EDIT 92     FOR ANF
DN8X can crash with bizarre symptoms,  possibly  implicating  the  DTE
The DTE driver is not checking to ensure that a  call  to  allocate  a
chunk  succeeded,  it  assumes  success.   With FTDGUTS turned off, an
ASSERT MACRO will trap if the call  fails.   However,  if  FTDGUTS  is
turned  on,  the ASSERT MACRO does nothing, and the call to GETCNK can
return "0" (i.e., no chunk), which is then used as the  address  of  a
chunk, thereby trashing whatever happens to get in the way.
Remove the call to ..ALOW, it is superfluous.  Instead,  call  ..ALCB,
and  TRAP  if  the  call to allocate a chunk fails.  Additionally, use
ERSGET rather than GETCNK as a last-ditch effort to not crash.
                             EDIT 93     FOR ANF
Terminals (and RDA lines) can get stuck on heavily-loaded systems.
The -11 attempts to "ease off" its load by  basically  ignoring  DH/DZ
lines  for  awhile,  assuming  the  IRMA  catcher  will  restart them.
Unfortunately, the line is left marked idle (i.e.,  the  line  is  NOT
marked active) so IRMA ignores it, thereby hanging the line forever.
Mark the forcibly-idled line as active  (DS.ACT)  so  that  IRMA  will
catch it and restart/resume output.
                             EDIT 94     FOR ANF
DN8X terminals (and RDAs) may hang, especially on a loaded system.
If the DH-11 gets a NXM error  (DH.NXM),  it  may  or  may  not  light
transmit  done  (DH..TI) as well.  The test for an error condition was
made on the presence or absence of transmit done, not on NXM.  Thus if
both  transmit  done  and  NXM are set, the -11 misses NXM and doesn't
clear the error, in effect hanging the DH-11.
Check explicitly for the presence of  NXM  error,  and  execute  error
recovery appropriately.
                             EDIT 95     FOR ANF
DZ11 terminal speeds can be left in the wrong state  (i.e.,  the  true
terminal speed is not what the user specified).
A program must issue two TRMOP.s in order to  set  both  transmit  and
receive  speeds  for the DZ11.  If the program is (e.g.,) scheduled or
otherwise interrupted  between  the  two  TRMOP.s,  the  -11  will  be
notified  of  the  partial  speed  change, and will reject it since it
appears to be an attempt to set the DZ to split-speed, which the  DZ11
does  not  support.   The  -11  will  then  send  back  to the -10 the
"correct" (i.e., unaltered) speed.  The user program  then  continues,
setting  the other speed, which again sends a partial (or split) speed
request to the -11, which is also rejected.  The end  result  is  that
both  TRMOP.s appear to succeed (take the skip return) but in fact the
-11 did not change the terminal's speed.
For DZ11 lines, rather than ignoring/rejecting  split-speed  requests,
just  ignore  the terminal receive speed and believe only the terminal