Google
 

Trailing-Edge - PDP-10 Archives - bb-bt99e-bb - apl1s2.d09
There are 2 other files named apl1s2.d09 in the archive. Click here to see a list.
                 EDIT DESCRIPTIONS FOR APLSF-10-V2                              
  
  
                             EDIT 555    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     )DROP with  a  non-wild  card  file  specification  and
swicthes will get WS NOT FOUND, even if the file is present.
This only happens in APLSF-10 after edit 525.
  
[DIAGNOSIS]
  
     Edit 525 forced the file argument to )DROP to be looked
up  in  the  default  PPN  if the file specification did not
contain wild cards.  However, the code to search through the
UFD  (or the SFD on the -10 after edit 525) is used by )DROP
when there are switches present, even if the  file  argument
does not contain wild cards.
  
[CURE]
  
     Fix edit 525 to use the default PPN only if wild  cards
and switches are not present.
********************************************************************************
  
  
                             EDIT 556    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     APL will overwrite the directory block of  a  /DA  file
when the amount of disk space used by the file is too large.
  
[DIAGNOSIS]
  
     It is not true that the only limit on the size of a /DA
file  is  the amount of disk available.  Certain pointers in
the /DA file are stored in 18-bit fields.  If  those  fields
are  to  contain  a  number  bigger  than  .NG1+2*18,  it is
truncated.  Using such a truncated field can result in  file
damage.
  
     The fields that are affected are  the  "record  number"
field  in the component directory and the "first free record
number" field in the gargabe block.
  
[CURE]
  
     Edit 556 keeps DFOUTPUT in DFILE from trying to  create
a  component with a record number bigger than 18 bits.  Both
.OQ and []APPEND can create components but only by finding a
hole  in  the  file big enough for the new component to fit.
If it will fit in an existing hole (or if .OQ  is  replacing
an  existing  component  with  data the same size), then the
existing hole will already have a valid record number.
  
     After the valid component is written,  the  "next  free
record  number" is updated to reflect the new "free space at
the end of the file".  If the record number to be written to
that  field  is bigger than 18 bits, the file is now full so
we want to signal FILE FULL (a new error message, number 76)
if  any  more  data  is  added  to the file in other than an
existing hole.  Therefore, set the "next free record number"
field to a 1.  1 is the only choice since 0 might mean "this
garbage entry can be deleted" (even though its right half ==
-1);   2  and  up  can be valid record numbers for the first
free record (NB:  )CREATE 1 FOO 128 has 2,,-1  as  the  last
garbage entry).  Check for a "first free record number" of 1
before adding a new component to the  file;   if  it  is  1,
signal FILE FULL because it is.
  
     Note that a normal TOPS-10 USETO UUO  cannot  access  a
disk  block  number  bigger than 18 bits.  The code in APLSF
does not check for such a big number  and  simply  truncates
the  block number or OR's the bits into a USETO somehow.  In
either case, the wrong block is positioned to.  This  should
either  be  fixed  (by  using  FILOP.  USETOs) or declared a
restriction and checked for.  With a blocking factor of 128,
the record number and the block number are the same so block
numbers bigger than 18 bits won't  fit  into  the  component
directory  fields anyway so edit 556 simply checks the block
number  before  OUTCMP  is  called  to  write  out  the  new
component.  If the block number is bigger than 18 bits, FILE
                                                      Page 2
  
  
FULL is signalled.
  
     Note that the following example reproduces the problem:
     1.  )CREATE 200000 FOO 8
     2.  components 1 thru 227 written with X_.IO8189
     3.  X .OQ[228]foo would set "next free record number"
     4.  X .OQ[229]foo gets FILE FULL
  
********************************************************************************
  
  
                             EDIT 557    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     Writing to a channel assigned to NUL:/AS gets a  PA1050
error.
  
[DIAGNOSIS]
  
     In STRTIO in FS (-20 version only), there is  an  extra
dot  in  the  expression  that  computes the size of the I/O
buffers.  Since NUL:  is capable of both input  and  output,
there must be lots of buffer space.  When the buffer ring is
allocated for input, there is not enough room between  where
APLSF  says  the  buffers start and the bottom of the HISEG.
PA1050 aborts with an "ERROR IN JOB" message  (from  routine
XPAND).
  
[CURE]
  
     Remove the dot so the code works (just like it works in
FS on the -10).
********************************************************************************
  
  
                             EDIT 560    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     []FI on an  argument  that  starts  off  with  lots  of
Booleans  but  then  contains  a floating point value gets a
SYSTEM ERROR under TOPS-10.
  
[DIAGNOSIS]
  
     The code in FIVI in DLEX1 that expands the result being
built at DX when the data type must change does not check to
see if there will be enough  room  in  memory  to  hold  the
object  of  the  new  type.  On the -10, a memory protection
violation  occurs  when  non-existent  memory  is   touched,
resulting  in  a  SYSTEM  ERROR report.  When APLSF restarts
after the SYSTEM ERROR, memory is garbaged,  thus  resulting
in an infinite loop.  On the -20, all of memory is available
so the SYSTEM ERROR  does  not  occur;   however,  given  an
almost full workspace, a WSFULL should result in this case.
  
[CURE]
  
     Edit  256  in  NUML  fixed  this  problem  for  .XQ  of
characters,  where  Booleans  expand  to  either  integer or
D-floating.  Duplicate that code in FIVI for both  the  case
where  Booleans  expand  and  also  the  case where integers
expand.
********************************************************************************
  
  
                             EDIT 561    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     .XQ on an argument of numbers represented as characters
that  starts  off  with lots of integers but then contains a
floating point value gets a SYSTEM ERROR under TOPS-10.
  
[DIAGNOSIS]
  
     The code in NUML in DLEX1 that expands the result being
built at DX when the data type must change does not check to
see if there will be enough  room  in  memory  to  hold  the
object  of  the  new  type.  On the -10, a memory protection
violation  occurs  when  non-existent  memory  is   touched,
resulting  in  a  SYSTEM  ERROR report.  When APLSF restarts
after the SYSTEM ERROR, memory is garbaged,  thus  resulting
in an infinite loop.  On the -20, all of memory is available
so the SYSTEM ERROR  does  not  occur;   however,  given  an
almost full workspace, a WSFULL should result in this case.
  
[CURE]
  
     Edit  256  in  NUML  fixed  this  problem  for  .XQ  of
characters,  where  Booleans  expand  to  either  integer or
D-floating.  Duplicate that code in NUML for the case  where
integers expand.
********************************************************************************
  
  
                             EDIT 562    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     .BXASCII  written  to  a  /BS  file  in   7-bit   ASCII
characters is not always the equivalent ASCII characters.
  
[DIAGNOSIS]
  
     SETWRT in BFILE.BLI translates  .BXAV  codes  to  7-bit
ASCII  for  /BS output.  It was never modified for .BXASCII.
It simply translates large  runs  of  .BXAV  into  7-bit  by
stripping  high  order  bits if there is no more appropriate
translation.  .BXCTRL (which is the  first  32  elements  of
.BXASCII) is OK.
  
[CURE]
  
     Rewrite the ZCODE to 7-bit translation  tests  to  make
the translation obvious and to get all of .BXASCII correct.
********************************************************************************
  
  
                             EDIT 563    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     'AS'.IOB_'' changes B to numeric.
  
[DIAGNOSIS]
  
     Edit 545 insured that dyadic .IO returned a  result  of
type  numeric,  with  the  same shape as its right argument,
even if the right argument is character.  Unfortunately, the
call  to  MAKEM in edit 545 passed the actual address of the
right argument whereas  MAKEM  expects  an  XSTACK  pointer.
Therefore MAKEM did not copy the right argument and edit 545
modified the actual right argument instead of a copy of  the
right argument.
  
[CURE]
  
     Give MAKEM .OPRND2, which is an XSTACK pointer, for its
argument.
********************************************************************************
  
  
                             EDIT 564    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     Assigning integers to a Boolean  matrix  gets  a  RANGE
ERROR.
  
[DIAGNOSIS]
  
     Edit 554 tried to  fix  subscripted  assignment  to  an
empty  array  when  the  data type of the right argument was
"bigger" than the data type of the left argument.  The patch
worked for empty left arguments;  however for non-empty left
arguments, edit  554  causes  the  data  type  of  the  left
argument not to be converted when it needs to be.
  
     Edit 554 to LSUB in SBSCR was  supposed  to  check  the
left argument for emptiness and not allow CNVTO to be called
in such a case.  Unfortunately edit  554  used  the  operand
pointed  to  by register R, which is the right argument.  It
was supposed to use reister S.
  
[CURE]
  
     Use register S to check for empty left arguments.
********************************************************************************
  
  
                             EDIT 565    FOR APLSF
  
  
  
  
[SYMPTOM]
  
     In response to the QAR for TOPS-20 release 6 field test
that  reported  a  system  error  in APLSF, the problem is a
memory  protection  violation  caused  by  an  illegal  byte
pointer.  The byte pointer looks like a one-word global byte
pointer, which is now legal in section 0 as of  the  TOPS-20
release 6 microcode.
  
[DIAGNOSIS]
  
     This problem could appear in several  places  in  APLSF
because  of  a BLISS-10 trick used to back a byte-pointer up
one byte.  Since APLSF was written for the KI, ADJBP was not
available.  The trick is used on 9-bit byte pointers to back
the pointer up one byte before an ILDB loop starts  (because
the  pointer  is in fact pointing to the first byte that the
loop wants to check).  For a byte pointer of the form:
  
     44 11 00,, adr
  
which points before the first 9-bit byte at location  "adr",
the trick is to add
  
     11 00 00,, 0
  
to it, resulting in a byte pointer of
  
     55 11 00,, 0
  
This is a one-word global byte pointer (unfortunately).   In
pre-release  6 microcode, an ILDB on such a pointer returned
a null byte and set the byte pointer to
  
     44 11 00,, adr
  
The next ILDB on such a byte pointer gets the first byte  at
adr.   The  trick works on the other possible forms of 9-bit
byte pointers.
  
[CURE]
  
     So ...  all the places in APLSF that  do  this  "trick"
should  either  back  the byte pointer up correctly, eg, use
ADJBP, or only add the constant if the  byte  pointer  needs
backing up, ie, is not 44 11 00,, adr.
  
     The trick is used in several places:
  
      o  )SI commmand
  
      o  )SIV command
                                                      Page 2
  
  
      o  )HI privileged command
  
      o  TOPS-10 protection (<ppp>) and ppn parsing on  file
         specs
  
  
     The "correct" solution to the problem will be  in  edit
565,  which  will  have to go out on the next Autopatch tape
for both the -10 and the -20.  In the meantime, the  TOPS-20
release 6 field test sites can do the following:
  
      o  don't use the )HI command
  
         If they don't know what it is, they should look  in
         the  .DOC file on the APLSF kit:  it describes this
         privileged command for building the HI file.
  
         This should be no great loss to anyone.
  
      o  don't use [ppn] and <protection> on file specs
  
         I believe that most TOPS-20 customers  use  logical
         names, not ppns (APLSF-20 runs under PA1050 so does
         not accept a TOPS-20 file spec).   I  also  believe
         that they don't use TOPS-10 style protcctions.
  
      o  Install the following DDT patch in APLSF:
  
                @GET SYS:APLSF
                @DDT
                SI+16/    HRLZI 11,110000    $<
                PAT../    HRLI 11,360600
                PAT..+1/  HRRI 11,STPTR
                PAT..+2/  LDB 11,11
                PAT..+3/  CAIL 11,44
                PAT..+4/  JRST SI+20         $>
                PAT..+5/  HRLZI 11,110000
                PAT..+6/  JUMPA 1,SI+17
                PAT..+7/  JUMPA 2,SI+20
                SI+16/    HRLZI 11,110000    JUMPA address-
                        of-where-PAT..-used-to-be
                ^Z
                @SAVE
  
         This patch  makes  )SI  and  )SIV  work.   Those  2
         commands are very important and must work for APLSF
         to be use for development.
  
  
     QAR 706111 from Case Western (attached)  diagnoses  the
problem and suggests a workaround which is not as general as
the above DDT patch.
  
                                                      Page 3
  
  
     QARs 706006 and 706007  from  Mobil  also  report  this
problem.  Note that Mobil thinks this is LOW priority.
                                                      Page 4
  
  
From:   MONTY::KL2137::WHITLOCK 27-JUN-1984 16:57
To:     EIFFEL::WHITLOCK
Subj:   APLSF QARs
  
        Here they are.  The first is the most interesting.  If I can help
out in any way, give a holler!
  
--------------------------------------------------
  
Qar: 706111     Local: 18 TSC:              Tape: 1
Product: TOPS-20                Version: 6.0          Edit: 6132
Date: 13-Jun-84 11:28:39
  
Customer: CASE WESTERN RESERVE UNIV      Code: CWRU
Author: ROB GINGELL
   System: 2925                 Type: 2060
   Problem class: SOFTWARE ERROR Priority: HIGH
   Module: APLSF                Reproducible: YES Attachments: NONE
  
Problem summary:
APLSF )SI COMMAND PRODUCES SYSTEM ERROR
  
  
Developer: GRANT        Date: 22-Jun-84 09:42:28
Status: ASSIGNED        MCO/PCO:
DEC-Priority: NONE   Key1:          Key2:          Key3:
  
[PROBLEM DESCRIPTION]
  
Problem
  
     Request for )SI, when state indicator is non-null,  produces  APLSF
     "system error".
  
     The following sequence will produce the error.
  
                .DL A
          [1]   Z.BX
          [2]   .DL
                A
          .BX:
                .GO
                )SI
          system error
                .IB30      < clear State Indicator
                )SI
                .DL B
          [1]   Z.QQ
          [2]   .DL
                B
          .OU
                )SI
          system error
  
Diagnosis
                                                      Page 5
  
  
  
     The "system error" is the result of an illegal memory read produced
     by  a  bogus one-word global byte pointer.  The one-word global has
     been formed by a code sequence at SI+16 in  APLSF.EXE,  which  adds
     110000,,0  to  a  byte  pointer of the form 441100,,OBUF.  Prior to
     microcode V352, an ILDB to this byte pointer (at SI+20) retrieved a
     byte  with  a  value  of  0  and  changed  the byte pointer back to
     441100,,OBUF.  However, with V352 installed, an attempt is made  to
     retrieve  the  2nd  8  bit  byte from word OBUF in section 1100(8),
     which produces the illegal memory read.
  
Workaround
  
     Replace the ADDB 11,STPTR at SI+17 with a NOP.
  
Suggestion
  
     There appear to be at least a half-dozen other such code  sequences
     in  APLSF, these should also be inspected to determine if they will
     produce bogus one word global byte pointers.
  
  
--------------------------------------------------
  
Qar: 706006     Local: 3 TSC:              Tape: 1
Product: TOPS-20                Version: 6.0          Edit: 6
Date: 17-May-84 15:55:08
  
Customer: MOBIL RESEARCH & DEVELOPMENT   Code: MOBIL
Author: R. E. FOULKS
   System: 80039030X            Type: 2060
   Problem class: SOFTWARE ERROR Priority: NORMAL
   Module: APLSF                Reproducible: YES Attachments: NONE
  
Problem summary:
)SI SYSTEM COMMAND
  
  
Developer: GRANT        Date: 22-Jun-84 09:42:28
Status: ASSIGNED        MCO/PCO:
DEC-Priority: NONE   Key1:          Key2:          Key3:
  
[PROBLEM DESCRIPTION]
  
THE )SI AND )SIV SYSTEM COMMANDS RESULT IN A SYSTEM ERROR UNLESS THE
STATE INDICATOR IS CLEAR.  HOWEVER THE EXECUTE OF ')SI' AND ')SIV'
DOES WORK.  IT DOESNT MATTER WHICH PA1050 WE USE (DONT KNOW IF THEY DIFF
ER).  MICROCODE??
  
--------------------------------------------------
  
Qar: 706007     Local: 3 TSC:              Tape: 1
Product: TOPS-20                Version: 6.0          Edit: 6.0
Date: 17-May-84 16:03:19
  
                                                      Page 6
  
  
Customer: MOBIL RESEARCH & DEVELOPMENT   Code: MOBIL
Author: R.E.FOULKS
   System: 80039030X            Type: 2060
   Problem class: SOFTWARE ERROR Priority: LOW
   Module: APLSF                Reproducible: YES Attachments: NONE
  
Problem summary:
APLSF )SI COMMAND FAILS
  
  
Developer: GRANT        Date: 22-Jun-84 09:42:28
Status: ASSIGNED        MCO/PCO:
DEC-Priority: NONE   Key1:          Key2:          Key3:
  
[PROBLEM DESCRIPTION]
  
)SI AND )SIV RESULT IN SYSTEM ERROR IF STATE INDICATOR IS NOT CLEAR.
THIS IS NEW WITH VERS 6.0, USED OLDER PA1050 WITH SAME RESULT. THE
EXECUTE OF ')SI' OR ')SIV' DOES WORK, HOWEVER.
   --------
  
   --------
********************************************************************************
  
  
                             EDIT 007    FOR APLTAP
  
  
  
  
[SYMPTOM]
  
     The APL character .DM (.BXAV [117] for .BXIO ==  0)  is
converted  by  APLTAP  to a character overstruck with <null>
(octal 000).
  
[DIAGNOSIS]
  
     The translate table entry for .DM is padded with  a  0,
which  labels  it as a character overstruck with <null>.  It
should be padded with  a  <blank>,  which  labels  it  as  a
non-overstruck character.
  
[CURE]
  
     Fix the translate table for APL .DM to be padded with a
<blank>.
********************************************************************************
  
  
  
END OF  APLSF-10-V2