Trailing-Edge
-
PDP-10 Archives
-
bb-bt99g-bb
-
apl1b2.d09
There are 2 other files named apl1b2.d09 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR APL-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 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 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.
--------
--------
********************************************************************************
END OF APL-10-V2