16-Jan-80 03:35:45-EST,474;000000000000
Mail from SU-SCORE rcvd at 16-Jan-80 0335-EST
Date: 15 Jan 1980 2223-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: FTPSER bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.24: ;
The following bug exists in release 3 and release 4 FTPSER. Credit goes
to MIT for discovering the bug. In the ABORPC routine, there are three
HRROI B,string instructions for various messages. They should be
HRROI X,string instead. The HRROI A,[ASCIZ /456 /] is correct.
-------
22-Jan-80 18:34:56-EST,878;000000000000
Mail from SU-SCORE rcvd at 22-Jan-80 1834-EST
Date: 22 Jan 1980 1528-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: IMP reinitialization bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.24: ;
Problem: After an IMP failure, the network does not initialize
properly. Things look as if the IMP thinks we are talking short
leaders. Things are wedged until the network is cycled.
Diagnosis: In IMIERR, there is a MOVNM T1,NOPCNT which should be
a MOVEM T1,NOPCNT since the NOP output routine takes a positive
value in NOPCNT to mean it should output the NOPs.
Solution: Make the change. IMIERR is in IMPANX.MAC. This fix is
valid in release 3 and release 4.
I have not verified that this will actually remedy the problem,
but since the Stanford IMP crashes on a daily basis I'll know
soon enough. The MOVNM in IMIERR is almost certainly a bug.
-------
22-Jan-80 22:14:37-EST,519;000000000000
Mail from SU-SCORE rcvd at 22-Jan-80 2214-EST
Date: 22 Jan 1980 1759-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: previous message irt IMIERR
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.24: ;
The bug fix in the previous message was incomplete and skewed with the
DEC sources. The proper fix is to replace the MOVNM T1,NOPCNT with
MOVEI T1,3
MOVEM T1,NOPCNT
The bug in the standard DEC sources was that an insufficient number of
NOPs were sent, and not that NOPCNT was set up incorrectly.
-------
22-Jan-80 22:18:55-EST,988;000000000000
Mail from SU-SCORE rcvd at 22-Jan-80 2218-EST
Mail-from: ARPANET site UTAH-20 rcvd at 22-Jan-80 1824-PST
Date: 22 Jan 1980 1655-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Bug in ACTGEN for Class Scheduling by Accounts
To: ADMIN.MRC at SU-SCORE
Remailed-date: 22 Jan 1980 1913-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.24: ;
Under R4 if you want to do class scheduling by accounts instead of by
Access control, there is a critical bug fix to ACTGEN. Class
scheduling by accounts won't work without it.
In routine .CLASS, after reading in the desired class number with
NIN, T2 is manipulated to check for valid class, but is not saved.
T2 is then returned with garbage instead of the desired class.
Fix:
After the RETBAD following the NIN save T2 (MOVEM T2,T4)
then before the AOJA T2,RSKP (last line of routine) restore
T2 with MOVE T2,T4
Plz forward this fix to mailing list.
-------
24-Jan-80 05:06:28-EST,700;000000000000
Mail from SU-SCORE rcvd at 24-Jan-80 0506-EST
Date: 24 Jan 1980 0204-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Bug fix to release 4 SYSDPY
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.24: ;
Problem: The AN command in SYSDPY omits some hosts
Diagnosis: DPYARP is using the number of existing hosts rather than
the size of the hash table as the AOBJN counter to paw
over host indices. It really has to look through the whole
hash table
Solution: At DPYARP+3, replace MOVEM T2,APANUM with MOVEM T3,APANUM
Note: I have enhanced the AN display for SYSDPY in a number of ways, including
another bug fix relating to lost output. Contact me for more information.
-------
27-Jan-80 23:06:39-EST,596;000000000001
Mail from SU-SCORE rcvd at 27-Jan-80 2306-EST
Date: 27 Jan 1980 2004-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: more on IMIERR
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.25: ;
I have modified IMIERR to do an AOS IMPDRQ before the JRST PA1 at the end
of the routine. It appears that this exorcises the problem of the NCP
getting wedged when the IMP crashes - basically, it cycles the network.
If you've ever had the problem that the network gets into a losing state
after an IMINX2 bug check, you should probably make this modification.
The routine is in IMPANX.MAC.
-------
1-Feb-80 13:05:11-EST,894;000000000000
Mail from SU-SCORE rcvd at 1-Feb-80 1304-EST
Date: 1 Feb 1980 0959-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: list of bug fixes for 4th field test release 4
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
I have compiled a list of bug fixes for the fourth field test of
release 4. They are on two files:
<ADMIN.MRC>EXEC-BUGS.TXT
<ADMIN.MRC>MONITOR-BUGS.TXT
All of these changes are changes which I would recommend to
DIGITAL for installation. A few of them are in the "feature
addition" category, but the bulk of them are bug fixes. I have
not included the numerous "matter of taste" changes made at
Stanford (this category includes useful and desirable things like
backspace-rubout and lazy login), since I felt that I was more
interested in compiling a list of things that should get done
before release 4 is shipped to the masses.
-- Mark --
-------
3-Feb-80 22:49:25-EST,2025;000000000000
Mail from SU-SCORE rcvd at 3-Feb-80 2249-EST
Date: 3 Feb 1980 1947-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Bug fix/kludge for hung jobs using section mapping/sharing
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
This patch is applicable to the fourth field test of
release 4, version 4(3230). It is probably not valid on any
earlier versions.
Problem:
Inferior forks hung in KSEF3, keeping top level fork from
logging out.
Diagnosis:
One way this happens is if the user runs TV in extended
addressing mode. TV runs in big addresses (unfortunately not to
advantage yet) if you enable it and fix a couple of minor bugs on
the way. What it does is map section 0 into a private section 3
then goes there.
When the fork is reset, it does an SMAP% to get rid of
the private section. SECMAP notices that the section has a share
count greater than 1 and returns SMAPX1.
However, it can't get rid of the other side either, so we
have a deadlock.
Solution:
Break the deadlock by decrementing the share count in
SECMAP regardless of whether or not somebody else has it mapped.
At SECMAP+15 or so, replace:
RETBAD (SMAPX1,<OKSKED
CALL RELCPT>) ;YES, CAN'T DELETE
with:
RETBAD (SMAPX1,<OKSKED
LOAD T1,SPTX,T2 ;DECREMENT THE SHARE COUNT THOUGH
CALL DWNSHR
CALL RELCPT>) ;YES, CAN'T DELETE
Note: this is sort of a kludge. The right thing would be
for it to noticed that it was mapped to another section in the
same fork, and break the share counts on both ends. Then SECMAP
can flush the section the first time KSELF tries instead of the
current delay.
Also I suspect that with the right kind of funny section
mapping you could get the system to SHROFD you. This has not
happened to me yet, although SMAP% hasn't been used extensively
yet here. I DON'T think you could get SHROFD'd with this fix if
you use SMAP% in the ways which DEC has suggested it should be
used. I would be interested to hear DEC's comments on this.
-- Mark --
-------
4-Feb-80 21:49:34-EST,1335;000000000000
Mail from SU-SCORE rcvd at 4-Feb-80 2149-EST
Mail-from: ARPANET site UTAH-20 rcvd at 4-Feb-80 1838-PST
Date: 4 Feb 1980 1826-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: bug in dumper archiving feature
To: admin.mrc at SU-SCORE, c-griss at UTAH-20
cc: frank at UTAH-20
Remailed-date: 4 Feb 1980 1840-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
THIS BUG FIX HAS NOT BEEN CHECKED OUT YET, AS IT IS NOT EASY TO CHECK OUT.
I WILL CHECK IT OUT DURING OUR NEXT ARCHIVE RUN (THIS WEEKEND) AND CONFIRM
ITS CORRECTNESS. HOWEVER, IT IS FAIRLY IMPORTANT IF YOU RUN THE ARCHIVING
SYSTEM.
If a user requests a file archive (voluntary) with disk contents retained,
the archiving system leaves the archive status in the fdb in a funny
state during the cleanup pass of the archiving run.
Diagnosis:
in DUMPER.MAC at ARFXB1 - (apx) 4 dumper executes code to delele
the disk contents in the normal case. This code is skipped when
the user requests that the contents remain on-line. Unfortunately,
this code also picks up the jfn for the file; the code after arfxb1
assumes that the correct jfn is in reg. a.
Fix:
At arfxb1 get the jfn for the file (HRRZ A,P2JFN) so that the ARCF
jsys following has the correct jfn in a.
-------
7-Feb-80 15:26:14-EST,835;000000000000
Mail from SU-SCORE rcvd at 7-Feb-80 1526-EST
Date: 7 Feb 1980 1224-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
This fix is a critical fix for release 4:
Problem:
IMPNII, ILLUUO, other strange bug halts. Analysis of the
crash shows that the SOSL IMPNFI at IMISRT+2 has been smashed to
randomness.
Diagnosis:
Somebody changed IMIN3 to "use [the] stack as [a] bit
bucket" instead of reusing the buffer when an over-sized message
came in. Whomever did it did not realize that PIMSTK was a stack
pointer and not the stack. In my system, the expression that it
evaluated to came out to be...IMISRT+2
Solution:
At IMIN3+3, change:
DATAO ANI,[1B12+PIMSTK+NIMSTK-1] ;Use stack as bit bucket
to:
DATAO ANI,[1B12+IMSTK+NIMSTK-1] ;Use stack as bit bucket
-------
16-Feb-80 19:20:56-EST,1033;000000000000
Mail from SU-SCORE rcvd at 16-Feb-80 1920-EST
Date: 16 Feb 1980 1614-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: scheduler requeue queue size bug fix
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
Problem:
Less than half of the SCDRQ queue is actually used. Besides
wasting resident variable space, it makes the scheduler queue more
likely to overflow.
Diagnosis:
NSCDRQ is multiply-defined. It is globally defined in STG
as 41 (33 decimal), and locally defined in SCHED as 20 (16 decimal).
Evidentally the SCDRQB table used to live in SCHED before STG existed
and somebody forgot to delete the NSCDRQ definition when moving SCDRQB
to STG - sometime later the table size got increased but it never
really happened.
Solution:
In SCHED.MAC, delete the definition of NSCDRQ. While you're
at it, you might as well delete the definition of SCTLW since it is
also defined in STG. It's probably a good idea to take care of SHLTW
as well, although I didn't feel like editing STG and GLOBS.
-------
17-Feb-80 17:53:34-EST,1529;000000000000
Mail from SU-SCORE rcvd at 17-Feb-80 1753-EST
Mail-from: ARPANET site UTAH-20 rcvd at 15-Feb-80 1654-PST
Date: 15 Feb 1980 1318-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Bug "circumvention" to fillfw problem
To: admin.mrc at SU-SCORE, dacruz at UTAH-20, kincl at UTAH-20
Remailed-date: 17 Feb 1980 1451-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
From Arnie Miller (via Dave Braithwaite) comes the following bug
"circumvention" for the fillfw problem. What this does is to automatically
do the clzff5+13 patch that we've been doing manually under the
appropriate circumstances. I've had it in for a day now with no hung jobs
and no noticeable side effect. As there probably won't be a true bug fix
for the problem until release 4.1, this will have to do. From DEC's point
of view, the problem only seems to be bad at sites running the mfexec and
using ephemeral programs. My own experience confirms this; when I de-
ephemeralized several commonly used programs, the incidence of hung jobs
went down by an order of magnitude.
The "fix: is in jsysf at about clzff5 +22 (??) after the JRST CLZFF7 and
before the CALL UNLCKF
JRST CLZFF7 ;NO, DON'T CLOSE
IFN UTAHSW,<
SKIPN FORKN ;SEE IF FORK STILL EXISTS
JRST [CALL CKMMOD ;MONITOR CONTEXT
JRST .+1 ;NO SO DON'T DO THE FOLLOWING
HRRZS FILLFW(JFN) ;CLEAR PAGE COUNT
JRST CLZFM1 ] ;AND PROCEED
>;IFN UTAHSW
CALL UNLCKF ;YES, UNLOCK JFN
-------
25-Feb-80 01:22:22-EST,858;000000000000
Mail from SU-SCORE rcvd at 25-Feb-80 0122-EST
Date: 24 Feb 1980 2021-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: FTSCTL JFN loser bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.28: ;
Problem:
FTSCTL forgets about JFNs at times. This can be
disasterous if it is running under SYSJOB.
Diagnosis:
The REJECT code is too clever for its own good. It tries
so hard to not do any unnecessary work that it fails to do
necessary work. In particular, if it fails to get a JFN for one
side it doesn't even try to get rid of the JFN for the other
side, etc.
Solution:
Make it stupider. Make REJEC1, REJEC2, and REJEC4 all
point to REJECT. At REJECT+6, delete the JRST REGO and the
REJEC1 label. At the end of the formerly REJEC1 routine, replace
the JRST REJECT with JRST REGO and delete the REJEC2 and REJEC4
routines.
-------
27-Feb-80 05:44:22-EST,1537;000000000000
Mail from SU-SCORE rcvd at 27-Feb-80 0544-EST
Date: 27 Feb 1980 0111-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: more on EXEC ALERT feature
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
[Note: This supercedes my earlier message tonight about EXEC's
ALERT feature. Install this edit instead of the previous one,
because it turns out that mail watching does use recursive %.
Sorry 'bout that.
By the way, ALERTs and hence the bug only happen with the multi-
forking EXEC. -- Mark]
Problem:
User specifies %<randomness> in a string for an alert and
gets illegal instruction traps with I ALERT and endlessly when
the alert happens.
Diagnosis:
ALERT text printing uses %\ which allows recursive %ing.
Code just blows up when the % code is invalid, and users
shouldn't be allowed to get at this anyway.
Solution:
Rewrite the alert text printout code to not use %\. In
EXECIN.MAC, at .ALRST+5, replace:
SKIPE B,REASON ; USER MESSAGE
TYPE < - >
ETYPE <%2\%%_>
with:
SKIPN B,REASON ; USER MESSAGE
JRST ALRST1
TYPE < - >
UTYPE (B)
ALRST1: ETYPE <%_>
and at ALRST2+6, replace:
SKIPE B,REASON+1(D) ; MESSAGE TABLE
TYPE < - >
ETYPE <%2\%%_>
with:
SKIPN B,REASON+D(D) ; USER MESSAGE
JRST ALRST5
TYPE < - >
UTYPE (B)
ALRST5: ETYPE <%_>
In EXECSE.MAC, at ALRCHK+17, replace:
SKIPE B,REASON ; GIVE MESSAGE SAVED
TYPE < - >
ETYPE <%2\]%_>
with:
SKIPN B,REASON ; GIVE MESSAGE SAVED
JRST ALRCH0
TYPE < - >
UTYPE (B)
ALRCH0: ETYPE <]%_>
-------
27-Feb-80 05:50:13-EST,745;000000000000
Mail from SU-SCORE rcvd at 27-Feb-80 0550-EST
Date: 26 Feb 1980 2353-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: EXEC ALERT bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
Problem:
Illegal instruction trap and possible endless looping if
user sets an alert with a "%" embedded in it
Diagnosis:
The %\ typeout routine calls UETYPE recursively, which in
turn can process % commands in strings. The code was never
written to handle the case of an illegal % command from a %\
string.
Solution:
Make %\ use UTYPE instead, since nothing needs this
functionality and it is a bug in the case of the ALERT feature.
At %STRNG+6, replace:
HRLI C,(<UETYPE>) ; FORM LUUO
with:
HRLI C,(<UTYPE>) ; FORM LUUO
-------
27-Feb-80 06:40:55-EST,778;000000000000
Mail from SU-SCORE rcvd at 27-Feb-80 0640-EST
Date: 27 Feb 1980 0338-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: more with capabilities passed to processes
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
This change is to EXECP.MAC. I recommend it to anybody who has
installed the earlier change to not pass capabilities down for
non-ephemeral programs.
Problem:
Ephemeral programs run by a privileged user run
privileged, even though user has disabled his/her capabilities.
This is not desirable for security reasons.
Diagnosis:
Coded that way.
Solution:
At REPH1+15 or so, between the MOVE A,EFORK and the
EPCAP, insert:
SKIPE C,PRVENF ; IF ENABLED, ALL CAPABILITIES
SKIPA C,B
TRZ B,-1 ; NOT ENABLED, DISALLOW ALL EPCAP
-------
27-Feb-80 07:03:37-EST,778;000000000000
Mail from SU-SCORE rcvd at 27-Feb-80 0703-EST
Date: 27 Feb 1980 0402-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: more with capabilities passed to processes
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
This change is to EXECP.MAC. I recommend it to anybody who has
installed the earlier change to not pass capabilities down for
non-ephemeral programs.
Problem:
Ephemeral programs run by a privileged user run
privileged, even though user has disabled his/her capabilities.
This is not desirable for security reasons.
Diagnosis:
Coded that way.
Solution:
At REPH1+15 or so, between the MOVE A,EFORK and the
EPCAP, insert:
SKIPE C,PRVENF ; IF ENABLED, ALL CAPABILITIES
SKIPA C,B
TRZ B,-1 ; NOT ENABLED, DISALLOW ALL EPCAP
-------
1-Mar-80 18:35:17-EST,2826;000000000000
Mail from SU-SCORE rcvd at 1-Mar-80 1834-EST
Date: 1 Mar 1980 1532-PST
From: Admin.JQJ at SU-SCORE (J. Q. Johnson)
Subject: [FRANK at UTAH-20 (Randy Frank): Terminal type names and numbers]
To: frank at UTAH-20
cc: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29:
Has anything ever come of this? When we discussed this last spring we
got as far as a tentative list of MONSYM symbols, but didn' generate any
concensus. I'm playing around with various long-term ideas fo terminal
support (e.g. a Unix-style termtyp file, and/or a program that assists the
user to determine his/her terminal type). I need to know what standardization
activities are currently in progress, and what people think they need.
The key question as I see it is "how many different types are there?"
This would determine whether we can think of terminal types as small integer
numbers or not. For example, is a VT132 different from a VT100? Is a DM2500
different from a DM3025 which simulates the 2500 except for handling of CRLF?
Is a home microcomputer that totally simulates a Teleray 1061 except for
padding requirements a different tty type? Is the modified-rom Teleray at
Utah different enough from the standard one to rate a separate type? How
about DMs with modified keyboards?
My current feeling is that our short-run best bet is to try to
standardize on the names for 20 or 30 common terminal types, but in the long
run to flush the notion of "terminal type" altogether in favor of a Unix-style
approach. I can imagine a replacement to the STTYP jsys which accepted a
string of keywords and values documenting the characteristics of a particular
terminal, or a number which indexed into a "standard characteristics" table.
Comments?
---------------
Mail from UTAH-20 rcvd at 29-Apr-79 1934-PDT
Date: 29 Apr 1979 2027-MDT
From: FRANK at UTAH-20 (Randy Frank)
Subject: Terminal type names and numbers
To: crossland at UTAH-20, heathman at SRI-KL, admin.mrc at SU-SCORE,
To: admin.jqj at SU-SCORE
Has anybody considered (or attempted) to standardize terminal type names
and/or numbers for non-DEC terminals. While I admit that standardizing
numbers may not be reasonable in that many may not want to reserve terminal
entries in stg for terminals which a site doesn't have, at least standarding
names would mean that all you would have to do is re-assemble with the
local monsym. If people think that standardizing names and/or numbers
is a good idea, I would be willing to maintain a "standard names list". Once
we have an initial list we should probably submit it to DECUS for consideration
by non-net sites. The standard name should include both a monsym name and
an Exec name, e.g., for the Teleray-1061 our monsym name is .tttel and our
exec name is Teleray-1061.
-------
5-Mar-80 07:33:49-EST,1559;000000000000
Mail from SU-SCORE rcvd at 5-Mar-80 0733-EST
Date: 5 Mar 1980 0432-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: higher priority for NCP fork
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
Note: This change is passed on as a SUGGESTION and not as a bug fix.
You should decide for yourself whether or not you really want to put
it in. Putting the NCP fork in queue 0 may well turn out to be too
much priority for it; I am experimenting with it like this now and so
far I am obtaining quite satisfactory results. John Borchek at BBN
has modified BBN's NCP to put most of the NCP fork tasks with the
periodic check or interrupt level. I feel that Borchek's solution is
better in the long run.
Problem:
NCP fork does not get run often enough. This can cause
IMINX2 buginfs and much grief to ARPANET users as network service
continually yo-yos during busy times.
Diagnosis:
The NCP fork is running at a high priority by virtue of
having been MSFRK'd. The problem is that it is sharing this
level of priority with other job 0 forks.
Solution:
Give the NCP fork an extra priority bump, so that it will
only run in queue 0. The right half of the priority word
contains two six bit fields. Bits 24:29 are the highest priority
queue the fork can run in, and 30:35 are the lowest priority
queue +1. If both of these bytes are zero, there isn't any
special priority. At IMPBP0+2, after the MCENTR:
MOVEI T1,.FHSLF ;GIVE THE NCP FORK SOME PRIORITY
MOVEI T2,1 ;ONLY ALLOW QUEUE 0
SPRIW%
ERJMP .+1
-------
5-Mar-80 08:11:00-EST,2332;000000000000
Mail from SU-SCORE rcvd at 5-Mar-80 0810-EST
Date: 5 Mar 1980 0506-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: STKOVF bug halts when the NCP is yo-yoing
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
Problem:
The ARPANET is yo-yoing. The system dies with a STKOVF
bug halt.
Diagnosis:
A user is in the middle of some JSYS which has locked
down the TTY's dynamic data when the network goes down. NVTDWN
calls NVTDET (in TTNTDV) to detach the user by generating a
carrier off PSI. Eventually, we get to JOBCOF which calls LDTACH
to actually detach the user, but since the TTY's dynamic data is
locked the TTYDAS call fails and we sit MDISMSing for the dynamic
data to be deallocated.
Now, the network goes up and down for another cycle while
the job is still hung on that NVT. Another carrier off PSI is
generated, which again gets us to JOBCOF... Each time this
happens 10 words or so are eaten off the UPDL until eventually
while doing the TLINK% in LDTACH we run out of UPDL space.
Solution:
This solution is in two parts, and while it fixes the
problem I'm not satisfied this is the end of the matter.
Part I: If the dynamic data deassignment in LDTACH fails,
try to win by giving the job a ^C interrupt. In MEXEC, in the
literal jumped to by LDTACH+16 or so, after the UNLOCK DEVLCK,
insert:
PUSH P,T1 ;SAVE TEST ROUTINE ADDRESS
MOVE T2,LDTALN ;POSSIBLY DYNAMIC DATA LOCKED BY SOME JSYS,
MOVEI T3,"C"-100; SO GIVE JOB A ^C INTERRUPT AND HOPE FOR BEST
CALL TTPSRQ ; DOESN'T HELP IF USER ENABLED FOR ^C THOUGH
POP P,T1
I'm not sure if this will really back us out of the JSYS (any DEC
people care to comment?), but I doubt it will hurt and just
possibly it will do precisely the right thing.
Part II: Don't allow repeated carrier off interrupts on
an ARPANET NVT. In TTNTDV, at NVTDT1+20 or so, after the
JRST NVTDT2 followed by the three lines of comments and before
the MOVE T2,NVTDLN, insert:
LOAD T1,TTDIP,(T2) ;IS THIS TERMINAL TRYING TO DETACH ALREADY?
JUMPN T1,NVTDT4 ;YES - DON'T DO PSI AGAIN!!!
SETONE TTDIP,(T2) ;TELL US NEVER TO COME HERE AGAIN
Insert the NVTDT4 label 5 instructions further down, at the CALL
ULKTTY. In TTYSRV, you then need to define TT%DIP and the TTDIP
structure. I defined TT%DIP as 1B29 in TTFLG1.
-------
5-Mar-80 08:24:41-EST,1055;000000000000
Mail from SU-SCORE rcvd at 5-Mar-80 0824-EST
Date: 5 Mar 1980 0518-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: getting carrier off PSI when job is detached
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
Problem:
A job which has enabled for the carrier off interrupt
does not get it until after the job has been reattached. If an
FTPSER is logged in and the other side breaks the network
connection without completing the BYE protocol, the FTPSER is
hung until the detach timeout expires.
Diagnosis:
The JOBCOF code freezes all the job's forks, on the
theory that maybe the job really was abandoned, so why let it
chew up CPU time for 5 minutes.
Solution:
Refrain from freezing the forks if the carrier off PSI is
enabled by some fork in the job. In MEXEC, at JOBCF1+4 (between
the CALL LDTACH and the CALL FFORKI), insert:
MOVE T1,BITS+.TICRF ;CHECK IF TOP-LEVEL FORK ENABLED
TDNN T1,TTSPSI ;...FOR CARRIER OFF INTERRUPT
Incidentally, the MOVE T1,FORKX at JOBCF1+2 is unnecessary and
can be deleted.
-------
9-Mar-80 22:21:02-EST,717;000000000000
Mail from SU-SCORE rcvd at 9-Mar-80 2220-EST
Date: 9 Mar 1980 1743-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: EXEC0 bug in SYSTAT - class scheduler printout
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.29: ;
Problem:
Illegal instruction from EXEC while printing out the
class scheduler parameters for a job.
Diagnosis:
Timing error. Job has logged out between the time that
the GETJI% was done on it and when the SKED% was done to get the
class scheduler info.
Solution:
Return all zeros for the information. At SYSTS3+11,
after the SKED%, insert:
ERJMP [SETZM .SAJCL+SYCLB
SETZM .SAJSH+SYCLB
SETZM .SAJUS+SYCLB
JRST .+1] ;FAILED, JOB LOGGED OUT, RETURN ALL ZEROS
-------
14-Mar-80 06:47:00-EST,1373;000000000000
Mail from SU-SCORE rcvd at 14-Mar-80 0646-EST
Date: 14 Mar 1980 0344-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: TOPS-20 Tools DECUS Session
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.30: ;
cc: RMS at MIT-AI, MMcM at MIT-AI, REG at SU-AI
I will be chairing a session entitled "TOPS-20 Tools" at
the 1980 Spring DECUS U.S. Symposium in Chicago. This
session is scheduled on Friday, April 25 from 9:45 to
11:45 AM in the Rosemont D Room of the Hyatt Regency
O'Hare.
The purpose of this session is essentially to introduce
"neat software not supported by DEC" to the general DECUS
community. Obvious programs such as MM, EMACS, and
SYSDPY will be covered, but I'm hoping to see other
programs mentioned in this session as well.
I am hoping, given enough interest and organization that
we will be able to make a TOPS-20 Tools tape for the tape
copy facility. I have been in contact with some people
at DIGITAL who have expressed interest in presenting some
of their own personal tools, hacks, etc. so it should be
an interesting session.
I would like to take this opportunity to invite you to
contribute your favorite tools to this session. This is
going to be the first DECUS session I have chaired, so
I'm going to need help to get the session to live up to
its full potential. Hope to see you there.
Regards,
Mark
-------
16-Mar-80 16:39:55-EST,3008;000000000001
Mail from SU-SCORE rcvd at 16-Mar-80 1639-EST
Date: 16 Mar 1980 1331-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Mr. Bill's DEC-20
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.30: ;
cc: Helliwell at DEC-2136, MMcM at MIT-AI
Hopefully everybody knows about the "Mr. Bill Show", but in case
you don't, it is one of the weekly parts of NBC's Saturday Night
Live and is a rather black humor takeoff on kids' TV shows. Mr.
Bill is a clay doll, and Spot is his little dog. Sluggo is a big
and mean clay doll that does mean things to Mr. Bill. Mr. Hands
are a pair of hands which move these characters around and does
most of the narration. Most of Mr. Bill's parts are various
high-pitched cries of pain as he gets crushed, multilated, and
otherwise made miserable by Sluggo (and Mr. Hands, his "friend").
Anyway, for your amusement, here is Mr. Bill's DEC-20, written in
TOPS-20 Monitor Internals class the day we learned about mapping
directories by yours truly with the help of certain people who
will go nameless (libel laws and all that...):
Mr. Bill's DEC-20
Mark Crispin
Mr. Hands: Hi kids! It's time for the Mr. Bill Show!
Mr. Bill: Yay!
H: Say Mr. Bill, I see you've bought a DECSYSTEM-20.
B: Yes, I'm gonna run a service bureau and make a lot of money!
H: Hey Mr. Bill, your DEC Software Specialist Sluggo is here to
install some patches.
B: Ohh, he's gonna be mean to me!
H: Come now, Mr. Bill. Your SWS Sluggo is your FRIEND. First,
he's going to map your directory.
B: Ohhhhhh!
H: Say Mr. Bill, your SWS Sluggo says your directory has some
errors in an FDB. He's going to fix it for you.
20: %DECSYSTEM-20 NOT RUNNING
*********************
* BUGHLT 'BADROT'
*********************
B: Ohhhhhhh!
H: Your SWS says your hardware's bad, since it happened just
while he was writing out your directory. Fortunately,
your DEC Field Service Representative Sluggo just came in
to do PM.
B: I don't think you're a friend Mr. Hands all you do is let
Sluggo be mean to me.
H: Your FE says for you to take a CLOSE look at this power supply
fan.
B: Ohhhhhhhhhhhhhhh!
H: Your FE says your problem is dog hairs.
B: Oh Spot's my friend don't throw him out the window we're on
the ninth floor...ohhhhhh! Poor Spot!
H: Now your FE is going to clean your disks.
B: Ohhhhhhhh!
H: He says that your disks had a lot of oxide on them and he had
to clean it ALL off. It looks like your system hasn't
been properly maintained, Mr. Bill. Your FE Sluggo has
no choice but to cancel your service contract and junk
your machine.
B: Ohhhhh! Let me have my machine back you are all being mean to
me.
H: Come now, Mr. Bill. Your DEC salesman Sluggo just came in to
sell you a VAX to replace your -20.
B: OHHHHHHHHHHHHHHHHHHHHHHH!
H: Well kids, that's all for now. See ya next week, when Mr.
Bill goes to DECUS!
-------
16-Mar-80 18:48:59-EST,728;000000000000
Mail from SU-SCORE rcvd at 16-Mar-80 1848-EST
Date: 16 Mar 1980 1545-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: timing race in LGOUT% which causes ILMNRF bug halts
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.30: ;
Problem:
ILMNRF and other wicked possibilities.
Diagnosis:
LGOUT% tried to hang up a detached TTY. In most places
it checks to make sure the TTY isn't detached, but it missed a
couple.
Solution:
In MEXEC.MAC, at LOG1+10, replace:
MOVE T2,CTRLTT
with:
SKIPGE T2,CTRLTT ;MAKE SURE TTY NOT DETACHED
JRST LOG2
and at LOG1+25, replace:
MOVE 2,CTRLTT
CALL TTHNGU ;HANG UP LINE
with
SKIPL 2,CTRLTT ;DON'T TRY TO HANG UP A DETACHED JOB
CALL TTHNGU ;HANG UP LINE
-------
23-Mar-80 07:08:01-EST,1344;000000000000
Mail from SU-SCORE rcvd at 23-Mar-80 0707-EST
Date: 23 Mar 1980 0401-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: FTSCTL
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.30: ;
I finally got sick and tired of having to constantly restart
FTSCTL because it had lost track of its shelf job, or having to
kill off multiple FTSCTL shelf jobs, or having FTP connections
in-between shelf job creations getting hung. So I have ripped
all of that code out of FTSCTL and have greatly simplified the
program in the process.
FTSCTL at SCORE now never keeps a job "on the shelf"; instead, it
CRJOB%'s a server when somebody wants one. This meant I could
get rid of all the IPCF stuff, and lots of other code as well.
The resulting program is a mere shell of the hair it once was,
and I hope - I expect - that it is much more reliable now. It
should be, since many possible timing problems got eliminated in
one fell swoop.
The only cost to going this route is that it may take a little
bit longer for the FTP server to start once the connections are
opened. I haven't noticed a significant difference. If anybody
wants to try running the SCORE FTSCTL, just send me a message.
You'll probably need to modify it if you're still running the
32-bit leader NCP since it uses the GTNCP% JSYS in one place.
-- Mark --
-------
23-Mar-80 22:57:18-EST,989;000000000000
Mail from SU-SCORE rcvd at 23-Mar-80 2257-EST
Date: 23 Mar 1980 1951-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: multi-forking EXEC bug - OUTPUT subcommand of CONTINUE
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.30: ;
Problem:
In the multi-forking EXEC, the OUTPUT subcommand of the
CONTINUE command does not work. The subjob immediately bombs out
with a unassigned JFN error.
Diagnosis:
The JFNs obtained by the OUTPUT and INPUT subcommands of
CONTINUE are on the JFN stack. EXEC flushes all JFNs it finds
there when it goes to get another top-level command.
Solution:
The right thing is for EXEC to forget that those JFNs
were ever there. This fix is sort of a kludge, but it's
effective:
At .CONT1+1, replace:
TRVAR <TMPJFN>
with:
TRVAR <TMPJFN,SJBUFP>
MOVE B,JBUFP ;WE WANT TO FORGET ABOUT JFN'S WE MAKE
MOVEM B,SJBUFP
and at .CONT6, insert:
.CONT6: MOVE A,SJBUFP ; FORGET ALL ABOUT THE JFNS FOR BACKGROUND FORK
MOVEM A,JBUFP
-------
30-Mar-80 14:44:56-EST,1018;000000000000
Mail from SU-SCORE rcvd at 30-Mar-80 1444-EST
Date: 30 Mar 1980 1142-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Full-time ARPA person at DEC
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.31: ;
Effective April 7, Dave Lyons (Lyons@DEC-2136) will
be DEC's full-time ARPA person. He's now on this
mailing list, so he'll receive all messages which
come out on this list.
For those of you who may want to send a message to
this list and don't know or have forgotten how, you
can either FTP the file <ADMIN.MRC>TOPS-20.DIS from
SU-SCORE or send the message to me and I'll remail
it to the entire list. TOPS-20.DIS is an indirect
file in MM COMND% JSYS format, so probably you'll
need to massage it a bit to get other mailsystems
to read it (for example, MS will not work with it,
although presumably MS can be fixed to do so). This
list changes often, so remember to check the latest
version here if you choose to send the message out
yourself.
Welcome aboard Dave!
-- Mark --
-------
1-Apr-80 04:10:16-EST,1209;000000000000
Mail from SU-SCORE rcvd at 1-Apr-80 0410-EST
Mail-from: ARPANET site MIT-AI rcvd at 31-Mar-80 1002-PST
Date: 31 Mar 1980 1303-EST
From: Chris Ryland <CPR at MIT-EE at MIT-AI>
Reply-to: CPR at MIT-XX
To: mrc at SU-SCORE
Remailed-date: 1 Apr 1980 0103-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
An interesting bug that recently showed up in MIT's pre-pre-non-standard-R4
system: after an auto-reload, the -10 and -11 alternate in their disk
accessi, providing an interesting blinking light effect on the disk, but
not much else (it goes on forever). Of course, rebooting by hand works.
Now, I don't know if this has anything to do with the non-standard front-end
we have (MMcM's chaos support version), but I've heard rumors that this problem
exists in some versions of R4. Any corroborators?
[Note from MRC: This problem has not happened at SCORE. The only
thing wrong with our front end is that it gets DTB 11-HALTs. It
seems to be associated with the lineprinter being sick, though;
so it could merely be that the lineprinter service isn't
sufficiently defensive against printer hardware lossage.]
-------
5-Apr-80 08:51:41-EST,900;000000000000
Mail from SU-SCORE rcvd at 5-Apr-80 0851-EST
Mail-from: ARPANET site UTAH-20 rcvd at 4-Apr-80 2359-PST
Date: 5 Apr 1980 0053-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Access control job and logout
To: admin.mrc at SU-SCORE
Remailed-date: 5 Apr 1980 0544-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
(plz forward to dist list)
If you are using the .golgo function in access control (logout function),
you cannot run batcon under sysjob. The getok function in the monitor
refuses to issue a getok on behalf of job 0 (presumable to avoid hanging
some critical job 0 function). You must therefore run batcon as either a
separate job or as a fork (assuming a multi fork exec) under some non
job 0 job. If Batcon runs under job 0, then any batch job which is logged
out by batcon will not go thru ACJ
-------
7-Apr-80 01:34:11-EST,887;000000000000
Mail from SU-SCORE rcvd at 7-Apr-80 0134-EST
Date: 6 Apr 1980 2229-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: bug in EXECP for multi-forking EXEC users
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
Problem:
In the multi-forking EXEC, the STAY subcommand of the
START command is broken, and bombs out looping with an illegal
memory write at the SETZM (C) at RJFNS8.
Diagnosis:
The earlier edit to fix the OUTPUT subcommand of CONTINUE
in the multi-forking EXEC forgot that START enters .CONT3 as
well, and so .CONT3 was called without the proper TRVAR context.
Solution:
(only if you inserted the earlier CONTINUE edit involving
the addition of a SJBUFP TRVAR variable) In EXECP, at .START+4,
insert:
TRVAR <TMPJFN,SJBUFP> ;TMPJFN NOT USED, BUT TO KEEP TRVAR CONTEXT
MOVE B,JBUFP ;WE WANT TO FORGET ABOUT JFN'S WE MAKE
MOVEM B,SJBUFP
-------
7-Apr-80 01:56:14-EST,1071;000000000000
Mail from SU-SCORE rcvd at 7-Apr-80 0156-EST
Date: 6 Apr 1980 2255-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: EXECP bug - START command in multi-forking EXEC
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
My apologies to anybody who is getting this twice, or who received
it in a garbage form the first time. The network mailer here blew
up while mailing the message:
Problem:
In the multi-forking EXEC, the STAY subcommand of the
START command is broken, and bombs out looping with an illegal
memory write at the SETZM (C) at RJFNS8.
Diagnosis:
The earlier edit to fix the OUTPUT subcommand of CONTINUE
in the multi-forking EXEC forgot that START enters .CONT3 as
well, and so .CONT3 was called without the proper TRVAR context.
Solution:
(only if you inserted the earlier CONTINUE edit involving
the addition of a SJBUFP TRVAR variable) In EXECP, at .START+4,
insert:
TRVAR <TMPJFN,SJBUFP> ;TMPJFN NOT USED, BUT TO KEEP TRVAR CONTEXT
MOVE B,JBUFP ;WE WANT TO FORGET ABOUT JFN'S WE MAKE
MOVEM B,SJBUFP
-------
-------
7-Apr-80 04:34:32-EST,1827;000000000000
Mail from SU-SCORE rcvd at 7-Apr-80 0434-EST
Date: 6 Apr 1980 2333-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: critical fix to MEXEC - carrier off PSI system crashes
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
I consider the following fixes to be critical fixes, because
it is rather trivial to exploit these bugs to crash the system.
In fact, I have a program which reproducably crashes SCORE both
under SCORE's monitor and a vanilla DEC monitor. I doubt that
anybody requires a demonstration. I certainly feel that it's
worth a CTCO. -- Mark
Problem:
All sorts of wondrous system crashes can occur when a job
which was detached by a carrier off PSI continues. The errors
are many and varied - ILLUUO's in magtape SOUT%, NETBAU's
following on the heels of a IMPBSC (of a totally 0 message),...
Diagnosis:
PSI service (in SCHED) runs in section 0. However, it
can call routines such as JOBCOF which (since they may run the
IMP) must run in section 1.
Solution:
At JOBCOF, insert:
SE1ENT
Note: I originally attacked the problem as changes to PSI
service, but when I saw that FLOGO (the other routine called in
the way JOBCOF is called) went into section 1 via SE1ENT I
decided to do it this way for consistancy. There are a lot of
really dubious practices done in SCHED around the PSI service
code - it needs revamping.
Problem:
There are some other obvious section 0 losers in MEXEC.
Diagnosis:
Ho Ho Ho, see the clever programmer who PUSH's a literal
as a PC.
Solution:
In MEXEC.MAC, at the literal pointed to by JOBCOF+1,
replace:
PUSH P,[MRETN] ;SETUP RETURN
with:
PUSH P,[IFIW!MRETN] ;SETUP RETURN
and at SAVEB+2, replacce:
PUSH P,[SAVEBL] ;YES, DO IT IN TWO PARTS
with:
PUSH P,[IFIW!SAVEBL] ;YES, DO IT IN TWO PARTS
-------
7-Apr-80 09:38:25-EST,648;000000000000
Mail from SU-SCORE rcvd at 7-Apr-80 0938-EST
Date: 7 Apr 1980 0636-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: reporting errors in Ephemerals
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
Problem:
An error in an ephemeral gives the confusing (and
meaningless) error message ?Unusual fork termination status xxxx
where xxxx is some random number
Diagnosis:
WEPHM calls FKTRM1, which expects the fork status in B,
but WEPHM didn't set it up. Maybe it is in A, although not
necessarily.
Solution:
At WEPHM+21, before the
JRST FKTRM1 ; TELL OF LOSSAGE
insert:
MOVE B,LRFSTS+.RFPSW ; SET UP STATUS IN B
-------
7-Apr-80 09:44:11-EST,648;000000000000
Mail from SU-SCORE rcvd at 7-Apr-80 0944-EST
Date: 7 Apr 1980 0636-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: reporting errors in Ephemerals
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
Problem:
An error in an ephemeral gives the confusing (and
meaningless) error message ?Unusual fork termination status xxxx
where xxxx is some random number
Diagnosis:
WEPHM calls FKTRM1, which expects the fork status in B,
but WEPHM didn't set it up. Maybe it is in A, although not
necessarily.
Solution:
At WEPHM+21, before the
JRST FKTRM1 ; TELL OF LOSSAGE
insert:
MOVE B,LRFSTS+.RFPSW ; SET UP STATUS IN B
-------
7-Apr-80 12:09:54-EST,2040;000000000000
Mail from SU-SCORE rcvd at 7-Apr-80 1209-EST
Mail-from: ARPANET site UTAH-20 rcvd at 7-Apr-80 0901-PST
Date: 7 Apr 1980 0950-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Fix to MEXEC to have ACJ called on implicit logout caused by carrier off
To: admin.mrc at SU-SCORE
Remailed-date: 7 Apr 1980 0903-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
Problem: If you are using the login/logout function of ACJ for accounting
(and/or controlling the maximum number of login for a user), the logout
function is not invoked if a job is implicitly logged out. This can happen
if a dial-up user hangs up without logging out. The job is first detached,
then after a timeout (five minutes in the distributed monitor) if no attach
has occured the job is logged out by the monitor.
Diagnosis: The logout function of ACJ is only invoked if an explicit
LGOUT jsys is executed for a job (either by itself or another job).
Fix: Add code to call ACJ on implicit logout of a job after hang up/detach
timeout. Note, that due to the special nature of this logout, I don't
accept "NO" for an answer from ACJ (I ignore a "deny request" return
from ACJ). For this reason (and the fact that the "job to log out"
argument normally given in the LGOUT jsys must be simulated), this
patch cannot use the normal logout getok utility subroutine.
In MEXEC at JOBCF1+14 replace the JRST FLOGO (preceeding the NOINT) with:
JRST [ MOVSI T1,(UMODF) ;FAKE USER PC
MOVEM T1,FFL
SETZM FPC
SE1ENT ;ENTER SECTION 1
MCENTR ;SIMULATE ENTRY FROM USER
MOVE T1,JOBNO
HRRZ T1,JOBDIR(T1) ;DIRECTORY
JUMPE T1,FLOGO1 ;DON'T GETOK SINCE NOT LOGGED IN
HRLI T1,USRLH
CALL CNVDIR ;GET DIRECTORY NUMBER
GTDAL ;GET ALLOCATION
ERJMP FLOGO1 ;DON'T GETOK SINCE SOME ERROR
SETOM T1 ;PRETEND AS THOUGH LGOUT WITH -1 GIVEN
GTOKM (.GOLGO,<T2,T3,T1>,FLOGO1) ;PERMISSION (DON'T TAKE
;NO FOR AN ANSWER)!!
JRST FLOGO1 ]
-------
8-Apr-80 03:34:16-EST,1881;000000000000
Mail from SU-SCORE rcvd at 8-Apr-80 0333-EST
Date: 8 Apr 1980 0031-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: revised section mapping/hung jobs bug fix
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
Note: If you inserted my earlier change to SECMAP which decremented
the share count before returning an error, remove it and replace it
with this fix. The earlier bug fix is wrong and can cause PAGLCK
bug halts because it can try to unmap the fork's page table while it
is still in use (I didn't think that fix was right anyway).
Problem:
Inferior forks hung in KSEF3, keeping top level fork from
logging out.
Diagnosis:
One way this happens is if the user runs TV in extended
addressing mode. TV runs in big addresses (unfortunately not to
advantage yet) if you enable it and fix a couple of minor bugs on
the way. What it does is map section 0 into a private section 3
then goes there.
When the fork is reset, it does an SMAP% to get rid of
the private section. SECMAP notices that the section has a share
count greater than 1 and returns SMAPX1.
However, it can't get rid of the other side either, so we
have a deadlock.
Solution:
The earlier code of last summer allowed unmapping the
page irregardless of whether or not it had a share count greater
than 1. For some reason this code was changed, but it isn't
clear why. Len Bosack and I went through the code and it seems
that the old code really was the right thing.
At SECMAP+14 or so, replace:
RETBAD (SMAPX1,<OKSKED
CALL RELCPT>) ;YES, CAN'T DELETE
with:
JRST [ LOAD T1,SPTX,T2 ;DECREMENT THE SHARE COUNT THOUGH
CALL DWNSHR
JRST SECMA2] ;AND CHARGE ON
Note that this change effectively deletes the SMAPX1 error. This
seems to be alright though. If anybody has a case where it isn't,
I'll see if we can debug it here.
-- Mark --
-------
8-Apr-80 14:36:06-EST,563;000000000000
Mail from SU-SCORE rcvd at 8-Apr-80 1435-EST
Date: 8 Apr 1980 1128-PST
From: Chris Ryland <g.Ryland at SU-SCORE>
Subject: bad lptspl security bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.34: ;
I don't know if this is a function of the old Quasar system we're running
(prerelease) but if you can print a file you can also /delete it (ie as
requested in the print command). This is, needless to say, somewhat unfor-
tunately. I guess the solution is to put a delete-access check into lptspl, but
I haven't had time yet. Try it, you'll like it.
-------
12-Apr-80 22:21:59-EST,1078;000000000000
Mail from SU-SCORE rcvd at 12-Apr-80 2221-EST
Mail-from: ARPANET site UTAH-20 rcvd at 10-Apr-80 1604-PST
Date: 10 Apr 1980 1656-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Fix to page fault in sched. context problem
To: admin.mrc at SU-SCORE
Remailed-date: 12 Apr 1980 1920-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.35: ;
The routine ACJKIL in JSYSA should be RESCD and not SWAPCD as it is
called from scheduler context. Change the SWAPCD to RESCD above
ACJKIL::
[Note from MRC: This isn't completely right. What you really
want to do is to move the SWAPCD above RESCD to the bottom of
that page, after the ACJDON routine. This causes .GTABS to be
in swappable code as it should be.
This is a pretty important bug fix if you swap a lot, since if
your ACJ crashes (the RCVTMR bug check) you stand a chance of
blowing your system away as well. Of course, you may want the
system to be blown away if ACJ dies, but the right way to do
that is to make RCVTMR a bug halt.]
-------
16-Apr-80 22:10:17-EST,656;000000000000
Mail from SU-SCORE rcvd at 16-Apr-80 2210-EST
Date: 16 Apr 1980 1908-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: EXECP bug - ephemerals not resetting TTY modes
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.36: ;
Problem:
After running an ephemeral, the TTY's mode is left set
the way the program set it instead of the way EXEC wants it. In
particular, the COC words may be wrong.
Diagnosis:
The ephemeral code doesn't bother to reset the TTY's mode
to EXEC's TTY mode.
Solution:
Add code to reset the TTY modes. At WEPHM+2, after the
CALL PIOFF, insert:
MOVEI Q1,ETTYMD ;RESTORE EXEC'S TTY MODES
CALL LTTYMD ;..
-------
18-Apr-80 15:42:40-EST,1118;000000000000
Mail from SRI-KL rcvd at 18-Apr-80 1542-EST
Date: 18 Apr 1980 1227-PST
From: LARSON at SRI-KL
Subject: FTSCTL
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.40: ;
I too have had many troubles with FTSCTL. It would try to make
connections before it had established the shelf job, or lose the
shelf job and connect the ftp users to an exec, and other things.
Instead of removing the shelf job code, as Mark did, I removed
ALL of FTSCTL. Instead of running FTSCTL, I now have NETSER do my
ftp server connections. I have therefore eliminated the shelf job,
and a system fork. There appears to be no signifigant delay in the
operation of ftp service.
In order to continue with my efficiency effort, I also csaved the
new NETSER, so the JFN/OFN would not be needed for the mapped pages
of the program. Sharing did not seem to be a benefit, since netser
is only run once on the system anyway. I had already done the same
thing with SYSJOB.
Since the srccom for this is rather long, I will not clutter up
everyone's mail with it. If you are interested in it, let me know.
Alan
-------
29-Apr-80 20:29:05-EDT,2067;000000000000
Mail from SU-SCORE rcvd at 29-Apr-80 2028-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 29-Apr-80 1302-PDT
Date: 29 Apr 1980 1402-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Bug causing system to hang due DEVLCK locked
To: admin.mrc at SU-SCORE
Remailed-date: 29 Apr 1980 1714-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
We've been seeing our system hanging periodically due to a process locking
DEVLCK and then blocking with DEVLCK locked. It happens when a process
goes to close a non-primary TTY line (opened for write) which still has
data in its output buffer. In our case, if that line is blocked (for example,
^S is blocking it), the system will totally hang as other processes queue
up on DEVLCK. The problem is that the system does a DOBE with DEVLCK locked.
Our fix follows. We have decided that under such a case it is reasonable
to allow the user to cntl-C out of such a state; I'd be interested in comments
from others as to whether they think that is reasonable. Our patch has been
in for about 48 hours and seems to solve the problem, although it's hard to
tell for sure given the nature of the system hang.
In FILMSC.MAC:
; FILMSC.MAC.2 & FILMSC.MAC.1 28-Apr-80 1624 PAGE 1
LINE 1, PAGE 1
1) ;DSK:<4-MONITOR-SOURCES>FILMSC.MAC.2 28-Apr-80 16:07:45, Edit by FRANK
1) ;FIX SYSTEM HANGING CAUSED BY DOBE WHILE DEVLCK IS LOCKED AT TTYCL5-1
1) ;<4.MONITOR>FILMSC.MAC.45, 26-Oct-79 14:51:15, EDIT BY ZIMA
LINE 1, PAGE 1
2) ;<4.MONITOR>FILMSC.MAC.45, 26-Oct-79 14:51:15, EDIT BY ZIMA
LINE 35, PAGE 20
1) SOBE ;SEE IF OUTPUT BUFFER EMPTY
1) JRST [ UNLOCK DEVLCK ;DON'T DISMISS WITH DEVLCK LOCKED
1) OKINT ;SO USER CAN CNTL-C
1) DOBE ;Wait until finished doing anything
1) MOVE T1,TTFLX
1) JRST TTYCL3 ] ;AND TRY AGAIN
1) TTYCL5: MOVE T1,TTYCLX ;GET INDEX TO DEVICE TABLES
LINE 35, PAGE 20
2) DOBE ;Wait until finished doing anything
2)
2) TTYCL5: MOVE T1,TTYCLX ;GET INDEX TO DEVICE TABLES
-------
29-Apr-80 21:37:12-EDT,1113;000000000000
Mail from SU-SCORE rcvd at 29-Apr-80 2136-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 29-Apr-80 1823-PDT
Date: 29 Apr 1980 1922-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Revision to previous FILMSC patch
To: admin.mrc at SU-SCORE
Remailed-date: 29 Apr 1980 1832-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
Mark caught error in previous patch; following is corrected version:
; FILMSC.MAC.3 & FILMSC.MAC.1 29-Apr-80 1917 PAGE 1
LINE 34, PAGE 20
1) TQNN <WRTF> ;If opened for output
1) JRST TTYCL5 ;not output, so don't look at output buffer
1) SOBE ;SEE IF OUTPUT BUFFER EMPTY
1) JRST [ UNLOCK DEVLCK ;DON'T DISMISS WITH DEVLCK LOCKED
1) OKINT ;SO USER CAN CNTL-C
1) DOBE ;Wait until finished doing anything
1) MOVE T1,TTFLX
1) JRST TTYCL3 ] ;AND TRY AGAIN
1) TTYCL5: MOVE T1,TTYCLX ;GET INDEX TO DEVICE TABLES
LINE 34, PAGE 20
2) TQNE <WRTF> ;If opened for output
2) DOBE ;Wait until finished doing anything
2) TTYCL5: MOVE T1,TTYCLX ;GET INDEX TO DEVICE TABLES
-------
14-May-80 21:00:39-EDT,2177;000000000000
Mail from SU-SCORE rcvd at 14-May-80 2100-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 12-May-80 0011-PDT
Date: 11 May 1980 2221-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Replacement fix to DOBE problem in FILMSC
To: admin.mrc at SU-SCORE, lyons at DEC-2136
Remailed-date: 14 May 1980 1752-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
The previous fix I sent out corrected the problem of the system hanging
due to DEVLCK being locked and the process dismissing, but unfortunately
didn't toally correct the problem as the user couldn't ^C out of the
close (the process was several levels deep in NOINT, and the single
OKINT didn't make the process interruptable).
The following fix replaces the previous one; the fix is stated in terms of
the original DEC code and not in terms of the previous patch.
This patch not only prevents the system from hanging if a user tries
to CLOSF a line which is suspended (e.g., by ^S being typed on it),
but also allows the user to ^C out of such a condition.
; FILMSC.MAC.4 & PIC:FILMSC.MAC.1 11-May-80 2212 PAGE 1
LINE 1, PAGE 1
1) ;DSK:<4-MONITOR-SOURCES>FILMSC.MAC.4 6-May-80 12:45:31, Edit by FRANK
1) ;Fix system/process hanging at TTYCL5-1 due to dismiss while DEVLCK locked
1) ;and process NOINT
1) ;<4.MONITOR>FILMSC.MAC.45, 26-Oct-79 14:51:15, EDIT BY ZIMA
LINE 1, PAGE 1
2) ;<4.MONITOR>FILMSC.MAC.45, 26-Oct-79 14:51:15, EDIT BY ZIMA
LINE 34, PAGE 20
1) TQNN <WRTF> ;If opened for output
1) JRST TTYCL5 ;not output, so don't look at output buffer
1) SOBE ;SEE IF OUTPUT BUFFER EMPTY
1) JRST [ UNLOCK DEVLCK ;DON'T DISMISS WITH DEVLCK LOCKED
1) OKINT ;Undo NOINT done by lock of DEVLCK
1) HLL T1,DEV ;Set up T1 for MDISMS
1) HRRI T1,TTOBET ;same test as for DOBE
1) TQO <BLKF> ;tell caller we want to block and restart
1) RET ] ;and return failure
1) TTYCL5: MOVE T1,TTYCLX ;GET INDEX TO DEVICE TABLES
LINE 34, PAGE 20
2) TQNE <WRTF> ;If opened for output
2) DOBE ;Wait until finished doing anything
2)
2) TTYCL5: MOVE T1,TTYCLX ;GET INDEX TO DEVICE TABLES
-------
17-May-80 20:18:40-EDT,1568;000000000001
Mail from SU-SCORE rcvd at 17-May-80 2018-EDT
Mail-from: ARPANET site SRI-KL rcvd at 9-May-80 0059-PDT
Date: 8 May 1980 1836-PDT
From: Meyers at SRI-KL (Harris A. Meyers)
Subject: FTP bug fix
To: admin.mrc at SU-SCORE
Remailed-date: 17 May 1980 1713-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
*** Mark, please forward ***
In version 3 (and beyound) the SAVEAC macro in MACSYM does a
SETMI 16, [...]
PUSH 17,16
to make things work in nonzero sections. 16 is supositly reserved to MACSYM,
but in FTP at TYI1 there is a SAVEAC with good data in 16, I fixed it by
changing 16 to 12 (see attached srccom). However mayhaps the code in MACSYM
should get changed to
PUSH 17,16
SETMI 16,[...]
EXCH 16,(17)
harris
-----------------------------------------------------------------------------
; FTP.MAC.3 & FTP.MAC.2 8-May-80 1745 PAGE 1
LINE 1, PAGE 1
1) ;<3-SOURCES>FTP.MAC.3, 8-May-80 16:42:22, Edit by MEYERS
1) ;2 change ac X from 16 to 12 to avoid interaction with MACSYM
1) ;<3-SOURCES>FTP.MAC.2, 10-Feb-78 16:32:12, Edit by MMCM
LINE 1, PAGE 1
2) ;<3-SOURCES>FTP.MAC.2, 10-Feb-78 16:32:12, Edit by MMCM
LINE 43, PAGE 1
1) VWHO==1 ;2 LAST EDITED BY SRI
1) VMAJOR==3 ;MAJOR VERSION #
LINE 41, PAGE 1
2) VWHO==0 ;LAST EDITED BY DEC
2) VMAJOR==3 ;MAJOR VERSION #
LINE 63, PAGE 1
1) X=12 ;2 MESSAGE POINTER
1) BP=15
1) P=17 ;STANDARD STACK
LINE 61, PAGE 1
2) BP=15
2) X=16 ;MESSAGE POINTER
2) P=17 ;STANDARD STACK
-------
27-May-80 02:12:08-EDT,982;000000000000
Mail from SU-SCORE rcvd at 27-May-80 0211-EDT
Date: 26 May 1980 2307-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: ILMNRF bug halt bug fix
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
Problem:
Another way to get an ILMNRF bug halt.
Diagnosis:
An old friend. At LDTAC2+11 there is a MOVE T2,CTRLTT
which assumes that CTRLTT contains a real TTY because earlier it
had checked. However, as usual there is a timing race problem.
It lost the race earlier this morning.
Solution:
At LDTAC2+11, replace:
MOVE T2,CTRLTT
with:
SKIPGE T2,CTRLTT
RET
Note: there are other bugs of the same type reported earlier to
this list. Most of them tend to be of the form
MOVE T2,CTRLTT
CALL STADYN
<go away since line is idle>
We get an ILMNRF because STADYN skip returns with whatever is in
TTACTL-1 when it is fed a -1 in T2. I am tempted to fix STADYN
to take the non-skip return and possibly bug check if it is fed a
detached line.
-------
28-May-80 13:54:11-EDT,802;000000000000
Mail from SU-SCORE rcvd at 28-May-80 1354-EDT
Date: 28 May 1980 1045-PDT
From: G.Norm at SU-SCORE (Norm Kincl)
Subject: Two R4 fixes
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42:
There are two problems that DEC fixed for us during Field Test,
but did not get into the final release (nor into any .BWR file we got)
Problem: If ACJ refuses a structure mount, the structure lock
count is not unlocked.
Solution: At about MSTDMC+14, the GTOKM macro should be:
GTOKM (.GOSMT,<T1>,MCTNOK)
and, just before MCTERR, add
MCTNOK: CALL MCTERR ;unlock the structure
ITERR () ;return illegal instr. error
Problem: Tops-20 doesn't seem to like 3-pack RP06 PS:
Cause: MXPGUN is defined in terms of RP04 packs
Solution: Redifine MXPGUN to be
MXPGUN==:<HOMTBL*PAGCY1*CYLUN1>
-------
28-May-80 23:06:30-EDT,401;000000000000
Mail from SU-SCORE rcvd at 28-May-80 2306-EDT
Date: 28 May 1980 2002-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Norm Kincl's note about MXPGUN definition
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
Note that you don't need to make Norm's MXPGUN redefinition if you
remember that MXSTRU is in RP04 units. You just redefine MXSTRU as
6 if you want a three-RP06-pack PS:.
-------
28-May-80 23:32:14-EDT,472;000000000000
Mail from SU-SCORE rcvd at 28-May-80 2332-EDT
Date: 28 May 1980 2027-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: CRITICAL BUG FIX -- SECURITY BUG
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.42: ;
Problem:
Anybody can do an MSFRK% JSYS.
Diagnosis:
The privilege check checks the left halfword for the
privilege bits instead of the right halfword. Oops.
Solution:
At MSFRK+3, replace:
TLNE 4,SC%WHL!SC%OPR
with:
TRNE 4,SC%WHL!SC%OPR
-------
12-Jun-80 07:48:10-EDT,278;000000000001
Mail from SU-SCORE rcvd at 12-Jun-80 0748-EDT
Date: 12 Jun 1980 0213-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: IMPDV bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.43: ;
T4 should be saved in the literal called by IMPOSY. It gets clobbered
by HSTDED.
-------
13-Jun-80 23:07:39-EDT,2697;000000000000
Mail from SU-SCORE rcvd at 13-Jun-80 2307-EDT
Date: 13 Jun 1980 2001-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: [HEDRICK at RUTGERS: for your mailing list]
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.45: ;
[Note from MRC:
This problem had to be fixed in the SAIL compiler. In general, I
think it is a bad idea to analyze error codes from the COMND%
JSYS. I'm afraid the best way is to have multiple blocks. It
seems to me that trusting the maintainers of COMND% not to
change the error codes around is being too trusting.]
---------------
Mail-from: ARPANET site RUTGERS rcvd at 13-Jun-80 1609-PDT
Date: 13 Jun 1980 1904-EDT
From: HEDRICK at RUTGERS
Subject: for your mailing list
To: admin.mrc at SU-SCORE
Has anyone SPR'ed the following bug, and gotten an answer? I have
code that it breaks. While I can make the code survive the bug, a
complete workaround would require me to distribute a fairly complex
patch (requiring fixes to all Pascal programs that use the COMND
jsys, as well as the Pascal and Sail compilers) to almost 100 sites.
I would much rather hear that DEC agrees to fix it and the fix is
to be published in the next Dispatch.
The problem is that COMND now returns NPXAMB for several different
errors in switches. This message is supposed to mean that a switch
is ambiguous. That is what it does mean for 3A. But on 4 apparently
it gets returned when you do CMSWI and somebody types a <cr>, or
even /<cr>. One could almost believe that these were in fact degenerate
forms of switches, and treat them as ambiguous, if there weren't
error codes that are clearly better, NPXNSW (Not a switch - does not
begin with slash) and NPXNUL (Null switch or keyword). Unfortunately
I did not bother to implement linking several function blocks in the
Pascal COMND support. I allow optional switches by distinguishing
between an illegal switch (which I treat as an error) and something
that is clearly not a switch at all (in which case I return a special
code, and the user typically goes on to the next field in the command).
On 4 I can't see any way to make this work, since I can't distinguish
between <cr> and an ambiguous switch. I can implement multiple
function blocks, of course, but then I have to update all the sites
who are not on the arpanet and whose Pascal has suddenly stopped
working. The update is going to be complex, probably several pages
of code in PASCMD, and logic changes to several Pascal programs. It
will also double the number of states in the finite-state automaton
used by SAIL's command parser.
grrrrr.....
-------
---------------
-------
16-Jun-80 00:41:27-EDT,814;000000000000
Mail from SU-SCORE rcvd at 16-Jun-80 0041-EDT
Date: 15 Jun 1980 2133-PDT
From: J. Q. Johnson <Admin.JQJ at SU-SCORE>
Subject: Re: [HEDRICK at RUTGERS: for your mailing list]
To: Admin.MRC at SU-SCORE
cc: [SU-SCORE]<Admin.MRC>Tops-20.DIS.45: ;
In-Reply-To: Your message of 13-Jun-80 2002-PDT
I'm afraid I can't agree with Chuck's analysis. It is ALWAYS a bad idea
on Tops-20 to depend on the error codes for an analysis of what went
wrong with a jsys. It is MUCH too likely that they will change. When
I write code, I don't even use the eof error message on SIN, but rather
do a GTSTS to make sure. In this case it is very clear that using linked
fdbs is the right way to do things; the code is actually shorter if it's
done right, and it makes available better standard help messages.
-------
19-Jun-80 05:07:05-EDT,4416;000000000000
Mail from SU-SCORE rcvd at 19-Jun-80 0506-EDT
Date: 19 Jun 1980 0159-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: ARPANET host status and the HS%VAL bit
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46: ;
cc: Clements at BBNA, DBell at DEC-2136, MMcM at MIT-AI
[Note: This message is of interest to people writing or
maintaining software for the ARPANET, especially software which
reads host status information. As the author and maintainer of
the new TOPS-20 TELNET program, I have a good deal of interest
in this issue and would like to hear other people's opinions.]
I have been investigating why I was not receiving any host
status from certain hosts. These hosts were invisible to the
host display in SYSDPY, and TELNETing to them simply returned
host dead with no other information. After some wild goose
chases, I observed that in all cases the HS%VAL bit was off in
the host status, and both my TELNET and SYSDPY were ignoring a
host status with this bit off.
After some further reading of the code, I determined that
this is what HS%VAL really means:
HS%VAL is cleared when the host hash table is set up when
SYSTEM:HSTNAM.TXT is read in. HS%VAL is set when an RST or RRP
comes in from a host, or when a dead host status message is
returned from the IMP. Since the monitor normally broadcasts
RSTs to every host on the network when the NCP comes up for the
first time, HS%VAL should be set for every host unless the IMP
fails to return any disposition of the message.
Suppose however that the host is up, but is not talking NCP
protocol or (I presume this is true) is on the secure subnet. In
this case, messages can be sent to the host and an RFNM will come
back, but no NCP protocol reply will ever be returned. The
result is that HS%VAL will never be set for the host, despite the
fact that the host's status is known; up but not talking NCP.
When you try to connect to such a host, the system will
notice HS%UP and HS%VAL are off, and will try to send an RST.
When the RRP timeout happens (5 seconds or so; the code actually
checks for HS%UP coming up which won't happen either), the job
gets OPNX20 but once again HS%VAL won't be set.
There is an obvious fix to this, which is to make IMRFNM
call IM8RRP first thing. This will have the effect that as far
as host status is concerned, the status is "valid" and "up". I'm
not sure if doing this for every RFNM (including doing a HSTHST)
that comes in is a good idea or not. Doing this will also defeat
the clever RRP timeout code, causing the OPENF% to wait around
much longer until the RTS times out. Also, "up but no NCP
protocol" would be indistinguishable from "up" without actual
experimentation. This does, however, make the code match the
documentation.
Alternatively, the code could be left as it is, and change
the documentation to say that HS%VAL being off coming after an
attempt to connect to the host really means that the host is up
but it doesn't have an NCP. This "works" a bit better; there is
a separate status for "up but no NCP" and "up" and the RST
timeout will work. However, this is sort of airing dirty laundry
in public by documenting incredible ugliness as a feature.
More complex but really the right thing would be to clean up
the status bits so that they are meaningful. Currently HS%UP is
used as both a host up and a status-is-valid bit (it gets turned
off if the IMP flaps) while HS%VAL never goes off once it comes
on. Probably three status bits are desired:
(1) valid status. We have determined initial status for this
host, and the IMP has been up since that time.
(2) host up. The host is up; ie, you get an RFNM when you send
a message to that host.
(3) host NCP up. The host has sent us an RST or an RRP,
indicating that it is talking NCP protocol.
This would be some work, but would be a lot cleaner; probably no
user programs would be affected adversely. However, my TELNET
would use this information for more meaningful error reporting.
I would be interested in some comments from the BBN folks
about this, particularly in regards to redoing the status bits.
I am willing to assist in such a project, but only if I had some
certainty that these changes would be merged into the official
TOPS-20AN sources.
-- Mark --
-------
28-Jun-80 00:02:03-EDT,727;000000000000
Mail from SU-SCORE rcvd at 28-Jun-80 0001-EDT
Date: 27 Jun 1980 2059-PDT
From: g.Meyers at SU-SCORE (Harris A. Meyers)
Reply-to: Meyers@SRI-KL
Subject: Question about SACTF
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46:
In JSYSF at SACTF1+3 and SACTF4+4 plus other related code scattered
throughout .SACTF great care is taken to store the new account in the
JFN data base in the JSB (FILACT(JFN)). Can anyone tell me of what
use this code is? It has the following bad side effect: any GNJFN
done on the JFN used by the SACTF will only find files with the new
account from then on. I consider this a bug and am considering
removeing the code, but was wondering if doing so will break something
harris
-------
1-Jul-80 15:07:02-EDT,1913;000000000000
Mail from SU-SCORE rcvd at 1-Jul-80 1506-EDT
Mail-from: ARPANET site MIT-XX rcvd at 30-Jun-80 2228-PDT
Date: 1 Jul 1980 0121-EDT
From: Michael Travers <MT at MIT-XX>
Subject: Long lines in .CTL files - fix to BATCON
To: Admin.MRC at SU-SCORE
Remailed-date: 1 Jul 1980 0602-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46: ;
Release-4 BATCON contains new code to deal with the IOX33 error.
Unfortunatly the code does the wrong thing, resulting in the batch
job seeing the first segment of input multiple times. This change
fixes it.
;COMPARISON OF SRC:<SYS.GALAXY>BATCON.MAC.2 AND SRC:<DEC.4.LANGUAGE>BATCON.MAC.1
;OPTIONS ARE /E /Y /3
**** FILE SRC:<SYS.GALAXY>BATCON.MAC.2, 1-1 (0)
;<SYS.GALAXY>BATCON.MAC.2, 30-Jun-80 20:48:21, Edit by MT
;1 Make recovery from overstuffed PTY buffer work
TITLE BATCON -- GALAXY Batch Job Controller
**** FILE SRC:<DEC.4.LANGUAGE>BATCON.MAC.1, 1-1 (0)
TITLE BATCON -- GALAXY Batch Job Controller
***************
**** FILE SRC:<SYS.GALAXY>BATCON.MAC.2, 83-32 (128759) AFTER "PTYSN1: SOUT ;OUTP"
PTYSN2: PUSH P,S2 ;1 Save updated pointer
MOVX S1,.FHSLF ;GET OUR PROCESS HANDLE
GETER ;GET LAST ERROR CODE
**** FILE SRC:<DEC.4.LANGUAGE>BATCON.MAC.1, 83-32 (128647) AFTER "PTYSN1: SOUT ;OUTP"
PTYSN2: MOVX S1,.FHSLF ;GET OUR PROCESS HANDLE
GETER ;GET LAST ERROR CODE
***************
**** FILE SRC:<SYS.GALAXY>BATCON.MAC.2, 83-40 (129079) AFTER "PTYSN2: PUSH P,S2 "
;1 HRROI S2,.JPTYO(R) ;POINT TO OUTPUT AREA
POP P,S2 ;1 Restore pointer
JRST PTYSN1 ;GO OUTPUT A BUFFER
**** FILE SRC:<DEC.4.LANGUAGE>BATCON.MAC.1, 83-39 (128929) AFTER "PTYSN2: MOVX S1,.FHS"
HRROI S2,.JPTYO(R) ;POINT TO OUTPUT AREA
JRST PTYSN1 ;GO OUTPUT A BUFFER
***************
[MRC - please forward to distribution list, if someone hasn't already
sent it in.]
-------
16-Jul-80 15:26:31-EDT,00000001479;000000000000
--------
DATE: 16-Jul-80 15:26
FROM: SOLOMON
Subject: IMPAUF bughlt after bringing up a new FTPSER
To: Admin.MRC at SU-SCORE
cc: NCP.Alpha at SU-SCORE, Tops-20
Problem: I took the FTPSER off XX and SRCCOM'd all the rutgers
patches in to it (and disabled XRCP, sigh, since we STILL dont have
rel 4) and brought it up on the system (at test time) and we got an
IMPAUF bughlt.
What we did:
First ^Eset no logins and ^ESET arpa off
then ^Espeak to kill ftsctl
then renamed the new version of FTPSER to <SYSTEM>
then ^Espeak to run sys:ftsctl
then ^Eset arpa on and ^Eset logins arpanet-terminals
Then tested the FTPSER and found it to be OK, and used it a
few times with no problems. (someone here played with the DEBUG switch
in it, but I hardly feel that he did anything to harm it) All of a
sudden-like (don't they all happen that way?) *C*R*A*S*H*.
Looking at the DUMP.CPY, we saw that it was in IMPEI1 (in
IMPANX.MAC) (location was IMPEI1+3) and t1 had a pointer to some CODE
rather than data in a buffer, sounds like the monitor was really
screwed at the time.
I suspect that the IMP initialization code may have a bug in
it by not clearing the buffer space properly, have you heard of the
problem? It is not THAT crucial, but in order to have Network sends,
we have to have the new ftpser.
Has anyone else that you know of had this problem?
Thanks Muchly,
Jon Solomon
========
17-Jul-80 00:35:03-EDT,893;000000000000
Mail from SU-SCORE rcvd at 17-Jul-80 0034-EDT
Date: 16 Jul 1980 2134-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re: IMPAUF bughlt after bringing up a new FTPSER
To: Solomon at RUTGERS
cc: NCP.Alpha at SU-SCORE, Tops-20 at RUTGERS
In-Reply-To: Your message of 16-Jul-80 1226-PDT
Jon -
I doubt seriously that your crash had anything to do
whatsoever with the new FTPSER. I am sure the bug is due to
various forms of section 0 jumping bugs. Get a copy of
<ADMIN.MRC>MONITOR-BUGS.TXT and look for "section 0" in the file.
Make sure all the fixes relevant to that are in your monitor.
Oh yeah, there are a couple of other bugs related to ARPANET
buffers. Make sure you have those fixes too. They're all pretty
important, and apply to release 3 as well as 4. Many of these
fixes HAVE NOT made it into 4, so be aware of this.
-- Mark --
-------
17-Jul-80 04:33:41-EDT,4764;000000000001
Mail from SU-SCORE rcvd at 17-Jul-80 0432-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 16-Jul-80 2007-PDT
Date: 16 Jul 1980 2052-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Fix to J0NRUN/TTMSG Bug in R4
To: admin.mrc at SU-SCORE
cc: crossland at UTAH-20, frank at UTAH-20
Remailed-date: 17 Jul 1980 0128-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46: ;
Problem: J0NRUN Bughlts caused by job 0 (fork 0) blocking in TTMSG (for
example when it prints out "DECSystem 20 Continued").
Diagnosis: TTMSG will block for two reasons: the SNDALL buffer is busy when
TTMSG is entered, or that the SNDALL buffer has not been copied to individual
network buffers (or the primary front-end for DH11 lines) before it returns.
For ARPANET NVTs there is code to make sure that if the SNDALL buffer
has not been copied to each individual NVT within a certain amount of
time, then the TTMSG to that line is discarded (and as a result the SNDALL
buffer eventually freed). Unfortunately, this TTMSG time-out for NVTs
only gets noticed if there is other NVT traffic present; if no other NVT
traffic exists, the SNDALL buffer will remain tied up indefinitely. This
happens, for example, if a single NVT is open but suspended for some reason.
Fix: Make the time-out for a TTMSG to an NVT noticed by the NCP fork as part
of it's overhead cycle. Also, make the wake-up condition (scheduler test)
for the NCP fork consider the time-out value for releasing the SNDALL
buffer in setting the next time that the NCP fork should run.
; IMPDV.MAC.3 & IMPDV.MAC.2 14-Jul-80 2235 PAGE 1
LINE 1, PAGE 1
1) ;<4.MONITOR-SOURCES>IMPDV.MAC.3, 14-Jul-80 22:01:26, EDIT BY CROSSLAND
1) ;MAKE SURE NCP FORK RUNS TO DISCARD TTMSG'S FOR STOPED NVT'S
1) ;PS:<4-MONITOR-SOURCES>IMPDV.MAC.2, 3-Feb-80 14:25:32, Edit by FRANK
LINE 1, PAGE 1
2) ;PS:<4-MONITOR-SOURCES>IMPDV.MAC.2, 3-Feb-80 14:25:32, Edit by FRANK
LINE 26, PAGE 11
1) SKIPE T2,ITMSTM ; Any TTMSG's out?
1) CALL TMSNTR ; Yes. Flush all TTMSG's to NVT's
1) MOVE T1,IMPNFI
LINE 26, PAGE 11
2) MOVE T1,IMPNFI
LINE 22, PAGE 12
1) SKIPE T2,ITMSTM ; Any TTMSG's outstanding
1) JRST [ CAMLE T1,T2 ; To be discarded before next scheduled wakeup
1) MOVE T1,T2 ; Yes. Set as wakeup time
1) JRST .+1]
1) MOVEM T1,IBPTIM ; Save time to dismiss until
LINE 22, PAGE 12
2) MOVEM T1,IBPTIM ; Save time to dismiss until
LINE 15, PAGE 16
1) RET
LINE 15, PAGE 16
2) SKIPN T2,ITMSTM ; Any TTMSG's out?
2) RET ; Done if not.
2) CAMLE T2,TODCLK ; Yes, time to flush yet?
2) RET ; No, return.
2) NOSKED ; Prevent anyone from changing data
2) CALL TMSNTR ; Flush all TTMSG's to NVT's
2) OKSKED
2) SETZM ITMSTM ; Clear timer
2) RET
; TTNTDV.MAC.2 & TTNTDV.MAC.1 14-Jul-80 2234 PAGE 1
LINE 1, PAGE 1
1) ;<4.MONITOR-SOURCES>TTNTDV.MAC.2, 14-Jul-80 21:48:40, EDIT BY CROSSLAND
1) ;MAKE SURE NCP FORK RUNS TO GET RID OF SNDALL'S TO STOPED NVT'S
1) ;<4.MONITOR>TTNTDV.MAC.55, 3-Jan-80 08:10:41, EDIT BY R.ACE
LINE 1, PAGE 1
2) ;<4.MONITOR>TTNTDV.MAC.55, 3-Jan-80 08:10:41, EDIT BY R.ACE
LINE 26, PAGE 7
1) CAMGE T2,IBPTIM ;IS IT BEFORE NEXT NCP FORK WAKE UP
1) MOVEM T2,IBPTIM ;YES. CHANGE WAKE UP TIME
1) POP P,T2 ;RESTORE T2
LINE 26, PAGE 7
2) POP P,T2 ;RESTORE T2
LINE 38, PAGE 7
1) ; T2 contains time to discard message
1)
1) RESCD
1)
1) TMSNTR::CAMLE T2,TODCLK ;TIME TO FLUSH YET?
1) RET ;NO, RETURN.
1) NOSKED ;PREVENT ANYONE FROM CHANGING DATA
1) MOVE T3,NVTPTR ;GET AOBJN COUNTER FOR NVT'S
1) TMSNR1: SKIPN T2,TTACTL(T3) ;GET ADDRESS OF DYNAMIC DATA
LINE 36, PAGE 7
2) ;CALLED NOSKED
2)
2) RESCD
2)
2) TMSNTR::MOVE T3,NVTPTR ;GET AOBJN COUNTER FOR NVT'S
2) TMSNR1: SKIPN T2,TTACTL(T3) ;GET ADDRESS OF DYNAMIC DATA
LINE 54, PAGE 7
1) OKSKED ;YES
1) SETZM ITMSTM ;CLEAR TIMER
1) RET ;RETURN
1)
LINE 49, PAGE 7
2) RET ;YES RETURN
2)
Note: the above patch does not totally eliminate the possibility of J0NRUN
bughlts with respect to a TTMSG being performed by fork 0 (job 0), but
significantly reduces the possibility. In general, the fact that TTMSG can
still block for an indeterminate amount of time (for example if multiple TTMSGs
are waiting for the SNDALL buffer) is dangerous since you really don't want
fork 0 blocking for long amounts of time. However, the solution to this
is non-trivial, and would probably require getting around the single
SNDALL buffer (e.g., by using a pool of buffers and thus guanteeing that
TTMSG never blocked). However, I'll leave this solution up to someone with
more ambition (DEC????).
-------
28-Jul-80 05:55:47-EDT,811;000000000001
Mail from SU-SCORE rcvd at 28-Jul-80 0555-EDT
Mail-from: ARPANET site RUTGERS rcvd at 27-Jul-80 1314-PDT
Date: 27 Jul 1980 1612-EDT
From: HEDRICK at RUTGERS
Subject: high queue reserve in 3A
To: admin.mrc at SU-SCORE
Remailed-date: 28 Jul 1980 0249-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46: ;
It looks to me like somebody used a TRNE where they meant TRNN, at
sched.mac:ajbals+16. The effect seems to be to turn off the
high queue reserve iffi you ask for it to be turned on. The code
in 4 looks right.
(I am trying an experiment where I change the definition of
high queue and low queue in AJBALS, so I consider any job with
working set > 100 pages to be low queue. I was wondering
why it seemed to be a no-op.)
-------
1-Aug-80 08:52:03-EDT,875;000000000000
Mail from SU-SCORE rcvd at 1-Aug-80 0851-EDT
Date: 1 Aug 1980 0546-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: EXEC bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46: ;
Problem: (bug fix courtesy JQ Johnson@LOTS)
Typing SET DEFAULT PLOT <cr> gets an illegal instruction
trap in EXEC.
Diagnosis:
The BADDEF table is missing an entry for PLOT.
Solution:
At BADDEF, replace:
BADDEF: XCT [ CMERRX <Invalid SET DEFAULT CARDS command>
CMERRX <Invalid SET DEFAULT PRINT command>
CMERRX <Invalid SET DEFAULT SUBMIT command>
CMERRX <Invalid SET DEFAULT PAPER-TAPE command>](P4)
with:
BADDEF: XCT [ CMERRX <Invalid SET DEFAULT CARDS command>
CMERRX <Invalid SET DEFAULT PRINT command>
CMERRX <Invalid SET DEFAULT SUBMIT command>
CMERRX <Invalid SET DEFAULT PAPER-TAPE command>
CMERRX <Invalid SET DEFAULT PLOT command>](P4)
-------
7-Aug-80 06:26:31-EDT,641;000000000001
Mail from SU-SCORE rcvd at 7-Aug-80 0626-EDT
Date: 7 Aug 1980 0321-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: TTYSRV bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.46: ;
(Credit goes to Chris Ryland at MIT for finding this one)
Problem:
Structures TTOMX and TTOCN are meaningless in TTYSRV. At
present it doesn't seem to have any bad effects, but...(!)
Diagnosis:
Bad definition.
Solution:
In TTYSRV, replace:
DEFSTR TTOMX,8,1 ;EXTRA BUFFERS IN USE
DEFSTR TTOCN,7,3 ;COUNT OF EXTRA BUFFERS
with:
DEFSTR TTOMX,TTDAT1,8,1 ;EXTRA BUFFERS IN USE
DEFSTR TTOCN,TTDAT1,7,3 ;COUNT OF EXTRA BUFFERS
-------
12-Aug-80 12:00:21-EDT,500;000000000000
Mail from SU-SCORE rcvd at 12-Aug-80 1200-EDT
Date: 12 Aug 1980 0854-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: bug in NETRBG bug check
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.49: ;
Problem:
NETRBG bug check RET's into data
Diagnosis:
When RLNTBF was fixed to save T1 (fixing the infamous
NETRBG bug halt problem) NETRBG wasn't told about the change
Solution:
At RLNTER, add
POP P,T1
after
RLNTER: JRST [ BUG (NETRBG) ;REPORT THE PASSING OF BAD ARGUMENTS
-------
14-Aug-80 20:32:20-EDT,1557;000000000000
Mail from SU-SCORE rcvd at 14-Aug-80 2031-EDT
Date: 14 Aug 1980 1723-PDT
From: G.LYONS at SU-SCORE
Subject: Information, please
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.49: ;
Dear Systems Person:
We would like to request comments on a few possible projects we are
working on. Would you please take the time to comment on these issues,
and let us know how you feel.
PCL
We are considering using CMU's PCL exec. We would like to know what
your users like or dislike about this exec, and what types of things are
done with it. What level of user at your site uses these features? Are
there extensions that you feel are required? What is your opinion of
the documentation available. Is it good? If not, how can it be
improved?
Multi-Fork Exec
Many sites are running what is known as the Multifork Exec. There are a
few concepts which need expansion, as handling of terminal I/O, Priv
passing/control between forks, control of fork action upon invocation,
etc. Also, are other features needed in the Exec?
TCP/IP
TCP/IP is the way the network is going. What type of user interfaces do
you envision requiring? Do you see a need for TCP/IP on other DEC
systems? If so, which ones? Any other comments on this subject would
be helpful.
Note that these are not commitments, as we are VERY short handed these
days, but a request for comments. Please forward your comments to
Dave Lyons MR1-2/E37
Digital Equipment Corp.
200 Forrest St.
Marlborough, MA. 01752
or LYONS @ DEC-2136
-------
25-Aug-80 18:22:36-EDT,1344;000000000000
Mail from SRI-KL rcvd at 25-Aug-80 1822-EDT
Date: 25 Aug 1980 1431-PDT
From: LARSON at SRI-KL
Subject: file access in tops20
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.49: ;
If you open a file for read, and are blissfully munching through
it expecting it to be stable while you do so -- you may get a rude
awakening. While you and your friends are reading the file, I can
come along and do a straightforward OPENF on the file, map it, and
change it out from under you. Impossible, you say? The operating
system will protect you from such things? Dream on... It would do
so in the days of Tenex, but TOPS-20 has changed things.
In Tenex, frozen access to a file guaranteed that the file would
not change while it was being read. Any number of processes could
open a file in frozen read mode, and they would see a stable file.
Frozen write access allowed no other writers, and disallowed other
processes from reading the frozen file (to protect them aganst the
changing data).
In TOPS-20 a frozen file is openable by at most one user writing
the file, but by any number of users reading the file.
In short:
Tenex frozen access allows
many readers OR one writer
TOPS-20 frozen access allows
many readers AND one writer
It seems to me that DEC blew it with this change. Opinions?
Alan
-------
29-Aug-80 20:04:41-EDT,787;000000000000
Mail from SU-SCORE rcvd at 29-Aug-80 2004-EDT
Date: 29 Aug 1980 1656-PDT
From: Eric Schoen <G.SCHOEN at SU-SCORE>
Subject: bug in CHKJFN for PTYs
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.49: ;
Contrary to its documentation, CHKJFN can destroy AC2. If and only
if you call CHKJFN with on a PTY, and if and only if you are NOT
enabled (this is why SYSJOB works), CHKJFN calls PTCHKA, which clobbers
2 (leaves the job number in 2, where the address of the dynamic data
belongs). This bug is not exercised anyplace in the DEC monitor, but
was tickled by Ethernet modifications made to Sumex's monitor. The solution
is to protect ac2 within PTCHKA (in module FILMSC). The code is faulty
in both rel 3A and rel 4.
Frank Gilmurray and Eric Schoen
Sumex-AIM
-------
5-Sep-80 04:46:02-EDT,268;000000000000
Mail from SU-SCORE rcvd at 5-Sep-80 0446-EDT
Date: 5 Sep 1980 0142-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: bug in ^ESEND
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.50: ;
Insert a CONFIRM after the CMERRX at DETSND+5. ^Esend is missing it.
-------
5-Sep-80 15:48:25-EDT,892;000000000000
Mail from SU-SCORE rcvd at 5-Sep-80 1548-EDT
Date: 5 Sep 1980 1242-PDT
From: g.Meyers at SU-SCORE (Harris A. Meyers)
Reply-to: Meyers@SRI-KL
Subject: bug in dluser
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.50:
Alan and I discovered the following bug in the error routines in dluser,
it applies to ver 3, 3a, and 4.
harris
------------------------------------------------------------------------
; DLUSER.MAC.2 & DLUSER.MAC.1 5-Sep-80 1235 PAGE 1
LINE 1, PAGE 1
1) ;<3-SOURCES>DLUSER.MAC.2, 5-Sep-80 12:27:29, Edit by MEYERS
1) ;1 make the move t1,.priou at inperr+1 an moveI
1) ;<3-UTILITIES>DLUSER.MAC.10, 8-Nov-77 10:46:57, EDIT BY KIRSCHEN
LINE 1, PAGE 1
2) ;<3-UTILITIES>DLUSER.MAC.10, 8-Nov-77 10:46:57, EDIT BY KIRSCHEN
LINE 35, PAGE 16
1) MOVEi T1,.PRIOU ;1
1) MOVE T2,JFN
LINE 35, PAGE 16
2) MOVE T1,.PRIOU
2) MOVE T2,JFN
-------
8-Sep-80 04:43:03-EDT,1203;000000000000
Mail from SU-SCORE rcvd at 8-Sep-80 0442-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 4-Sep-80 2041-PDT
Date: 4 Sep 1980 1932-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Reaper bug/misfeature
To: ADMIN.MRC at SU-SCORE
Remailed-date: 8 Sep 1980 0132-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.51: ;
Reaper, the program to force migration of old files, has a serious misfeature.
In order to prevent files like mail.txt from being migrated (archived), it
opens them for read to make sure they've been accessed recently. Unfortunately,
this screws up users being told they have new mail, etc. Note this happens
even if you run reaper in the "scan only" mode (i.e., tell me about old files
but don't actually mark them for migration), which is all we use reaper for.
The obvious solution is that if you want to prevent a file from being migrated,
set the prohibit migration bit instead of opening it for read.
In REAPER.MAC at DOKEP1+5, replace the code that opens and closes the file
with the following:
MOVX T2,.AREXM ;SET PROHIBIT MIGRATION
MOVX T3,.ARSET
ARCF
POP P,T1
RLJFN
JFCL
RET
-------
9-Sep-80 15:46:25-EDT,590;000000000000
Mail from SU-SCORE rcvd at 9-Sep-80 1546-EDT
Date: 9 Sep 1980 1244-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Labeled tapes on TOPS-20 question
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.51: ;
Gavin Hemphill of D.R.E.A. in Canada would like to know if "anyone
else has had bad experiences with labeled tapes. They seem to work
fine when they don't hang all the tapes on the system (about 60% of
the time any operation having to do with a labeled tape just causes
the tapes to disappear).
He can be reached via ARPANET mail at RGSMITH@RUTGERS.
-- Mark --
-------
16-Sep-80 18:33:23-EDT,1450;000000000000
Mail from SU-SCORE rcvd at 16-Sep-80 1833-EDT
Mail-from: ARPANET site RUTGERS rcvd at 16-Sep-80 1323-PDT
Date: 16 Sep 1980 1621-EDT
From: WATROUS at RUTGERS
Subject: Disk file copy patch
To: Admin.MRC at SU-SCORE
Remailed-date: 16 Sep 1980 1527-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.53: ;
There is still a problem with the patch supplied by Dave Bell to fix
copying a file with an even multiple of 512 pages (that is, having
page 511, or etc.). While the BLT is shortened, preventing
extraneous pages from being copied, the PMAP is still set up to map
those non-existent pages to the destination file. Sure those pages
don't end up in the file, but a side effect of trying to map them there
is that the long file bit (FB%LNG) gets lit. (TVEDIT uses page 511
for it's own purposes, but refuses to edit long files.)
So, to prevent the destination file from becoming a long file you should
insert, just before the PMAP to the destination file:
move d,endptr ; get end pointer
camn d,endpt0 ; was it changed?
jrst dsklp2 ; no, proceed with pmap
aos d ; yes, refigure count
sub d,desbfr ; number of words
lsh d,-9 ; number of pages
hrr c,d ; put where it belongs
dsklp2:
Don
P.S. - Also, to avoid confusion in installing the patch, the line
reading "In DSKDIS, before the line" should read "At DSKBLT+3, before
the line".
-------
23-Sep-80 07:31:29-EDT,1450;000000000000
Mail from SU-SCORE rcvd at 23-Sep-80 0731-EDT
Mail-from: ARPANET site RUTGERS rcvd at 16-Sep-80 1323-PDT
Date: 16 Sep 1980 1621-EDT
From: WATROUS at RUTGERS
Subject: Disk file copy patch
To: Admin.MRC at SU-SCORE
Remailed-date: 23 Sep 1980 0425-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.53: ;
There is still a problem with the patch supplied by Dave Bell to fix
copying a file with an even multiple of 512 pages (that is, having
page 511, or etc.). While the BLT is shortened, preventing
extraneous pages from being copied, the PMAP is still set up to map
those non-existent pages to the destination file. Sure those pages
don't end up in the file, but a side effect of trying to map them there
is that the long file bit (FB%LNG) gets lit. (TVEDIT uses page 511
for it's own purposes, but refuses to edit long files.)
So, to prevent the destination file from becoming a long file you should
insert, just before the PMAP to the destination file:
move d,endptr ; get end pointer
camn d,endpt0 ; was it changed?
jrst dsklp2 ; no, proceed with pmap
aos d ; yes, refigure count
sub d,desbfr ; number of words
lsh d,-9 ; number of pages
hrr c,d ; put where it belongs
dsklp2:
Don
P.S. - Also, to avoid confusion in installing the patch, the line
reading "In DSKDIS, before the line" should read "At DSKBLT+3, before
the line".
-------
23-Sep-80 15:44:50-EDT,1212;000000000000
Mail from SU-SCORE rcvd at 23-Sep-80 1544-EDT
Mail-from: ARPANET site RUTGERS rcvd at 23-Sep-80 1237-PDT
Date: 23 Sep 1980 1537-EDT
From: WATROUS at RUTGERS
Subject: Extensionless file COMPILE-class bug
To: Admin.MRC at SU-SCORE
Remailed-date: 23 Sep 1980 1240-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.53: ;
Problem:
Trying to compile an extensionless file without specifying a
null extension fails.
Diagnosis:
The EXEC, in trying to determine which file to compile,
checks out filnam.*. Then it gets a JFN on the "best" file using the
extension implied by the language type of the "best" file found,
which doesn't work in the case of an extensionless file.
Solution:
Since the EXEC's already made an exact copy of the extension
of the "best" file, use that instead of the implied extension.
In EXECCS, at GTLNG3+23, replace:
MOVE B,SAVLNG ;RESTORE LANGUAGE
HRROI A,LTAB(B) ;GET EXTN FROM TABLE
with:
MOVE A,EXTP ;USE EXTENSION WE COPIED
3 lines down, remove:
PUSH P,B ;SAVE THIS
and 11(octal) lines down from there, replace:
POP P,B ;RESTORE B
with:
MOVE B,SAVLNG ;GET LANGUAGE TYPE
-------
29-Sep-80 07:26:08-EDT,1429;000000000000
Mail from SU-SCORE rcvd at 29-Sep-80 0725-EDT
Mail-from: ARPANET site RUTGERS rcvd at 26-Sep-80 0950-PDT
Date: 26 Sep 1980 1253-EDT
From: RGSMITH at RUTGERS
Subject: LASER PRINTERS OR EQUIVALENT
Remailed-date: 29 Sep 1980 0420-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.53: ;
[Note from MRC: This is an edited version of a message sent to me
by Gavin Hemphill, D.R.E.A. Canada]
We are trying to acquire some form of laser printer
(xerographic). At the moment we are pushing Cannon to sell us
one of the LBP-10's that they have been advertising around the
country but from the response we're getting I get the feeling
that they just don't want to sell the things whether or not you
care about the interface (we were going to build one) or support.
I have heard rumours that the University of Minnesota (not sure
about that) has modified and interfaced a teletype facimile
machine to get a 380 dot/inch device and I was wondering whether
there are any other homebrew devices like that in use around the
net. If there are I would like to get in touch with these people
to find out what items were bought/built etc. The eventual goal
is to acquire a report quality output device doesn't cost us
$490K up front. If the hardware costs are right it is almost
immaterial how much time and effort is necessary get a working
device.
-------
2-Oct-80 15:06:07-EDT,1343;000000000000
Mail from MIT-MC rcvd at 2-Oct-80 1505-EDT
Date: Thursday, 2 October 1980 14:54-EDT
From: Chris Ryland <CPR at MIT-EE>
To: Twenex-Wizards at mc
Reply-to: CPR at MIT-MC
Subject: MOUNTR lossage
We have had very poor luck with MOUNTR under R4, and I'd like to
compare notes with you folks. Basically, after a little frobbing with
labelled tapes, MOUNTR loves to nosedive with an illegal memory write,
at seemingly random times. Haven't really looked into the code at
all, since we don't mind just restarting it, but if no one has any
suggestions or similar experiences, I guess we'll have to bite the
bullet. I have a sneaky suspicion it might have to do with its
DEVICE-STATUS.BIN file being mapped strangely or having non-existent
pages, or whatever, since we have been pretty careless about running a
fully R4 system (we went through several stages of R4ness before
becoming 'real', if you can call our monitors real).
Also, I've set up this alternate mailing list on MC which is a copy of
[Score]<Admin.MRC>Tops-20.dis, since it's infinitely easier to reach
you all this way (I just wasted 1/2 an hour trying to get it all right
via Score, but the load was too high there, MM wasn't very
cooperative, etc.). I suppose that supplies me or someone with the
problem of keeping the MC list up to date. Oh well.
2-Oct-80 15:59:54-EDT,1603;000000000000
Mail from MIT-MC rcvd at 2-Oct-80 1559-EDT
Date: 2 Oct 1980 1236-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
To: CPR at MIT-MC, Twenex-Wizards at MIT-MC
In-Reply-To: Your message of 2-Oct-80 1156-PDT
Chris -
I haven't had any problems with MOUNTR, although we don't
use labeled tapes here so it is hardly ever spoken to. It is
reputed from several sources, both on the TOPS-20.DIS list and
off it (ie, SF Bay Area LUG meetings) that MOUNTR is inexcusibly
fragile and dies at the slightest provocation. Some
bullet-proofing is clearly necessary.
It is intentional that the TOPS-20.DIS list is on SCORE
instead of on MC. I find ITS and long network delays too
unusable, and will not be responsible for keeping that copy of
the list up to date. Not to mention the name -- "Twenex" is
unspeakably cute!
Much more importantly is the fact that there is no control
on who gets on the list if it lives on some random ITS host. It
would greatly hurt the utility of this list if we could not
discuss security bugs and bugfixes because some randoms have
added themselves to the list. I don't think it is that
troublesome to mail the message to me and have me remail it; the
only times there have been delays with this have been when I've
had to edit the message (e.g. if the note to TOPS-20.DIS was
embedded in another message).
Speaking of security bugs, I will be sending an important
fix for a security bug out shortly.
-- Mark --
-------
2-Oct-80 16:06:02-EDT,1930;000000000000
Mail from SU-SCORE rcvd at 2-Oct-80 1605-EDT
Date: 2 Oct 1980 1254-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
This bug was noted in SPR 20-14575, CTCO 526.1, not to
mention having been triggered a few times at SCORE by accident.
The CTCO included a few older RNAMF% bug fixes, but neglected to
include THE fix!!! [At least in my copy it didn't have it.]
Problem:
The following program, where LOGIN.CMD is an existing
file, crashes the system with a SHROFD bug halt:
MOVSI 1,(GJ%SHT!GJ%OLD)
HRROI 2,[ASCIZ/LOGIN.CMD/]
GTJFN%
0
RNAMF%
After you get the error return from RNAMF%, just ^Z out of DDT
and run any other program. Blam!
Diagnosis:
The SHROFD happens because it is trying to release OFN 0.
OFN 0 is never assigned. Examination of the JFN shows that it
isn't a JFN at all, although its FILSTS word makes it look like
an open JFN. At the time of the crash, we are trying to CLOSF%
the JFNs that the previous fork has open because we are resetting
the fork prior to making a new one.
The error returns in RNAMF% can jump to ERUNLD with junk
in STS. Since ERUNLD saves STS in FILSTS(JFN), the randomness is
left there. All that's needed is for OPNF (the sign bit) to be
set in the randomness for CLOSF% to think that there is an open
JFN there. However, its OFN field is zero, so it attempts to
release OFN 0. Sorry folks.
Solution:
Go through the .RNAMF routine, and fix every error return
to do MOVE STS,FILSTS(JFN) before any unlocking calls. Probably
the safest thing to do (what I did) was to find every POP P,JFN
and put the MOVE STS,FILSTS(JFN) after it. I don't know what to
tell you folks who don't have sources, although presumably DEC
will issue a corrected version of the CTCO shortly.
-------
2-Oct-80 16:39:59-EDT,855;000000000000
Mail from MIT-MC rcvd at 2-Oct-80 1639-EDT
Date: 2 Oct 1980 1600-EDT
From: Jon Solomon <Solomon at RUTGERS>
Subject: Re: MOUNTR lossage
To: CPR at MIT-MC
cc: Twenex-Wizards at MIT-MC, Solomon at RUTGERS
In-Reply-To: Your message of 2-Oct-80 1505-EDT
I have seen MOUNTR die only when some other process under SYSJOB
has the MAGTAPE it wants opened. We tend to like to do Prints off magtape
for the IBM-370 which occupis a space in our machine room. The trouble
occurs when the operator sets the tape drive available before stopping
the Print queue associated with it. MOUNTR and LPTSPL both compete for the
drive, and MOUNTR crashes.
Chris, Some time when you can get the machine to yourself, you
might try deleting the DEVICE-STATUS.BIN file and re-creating it, though
I believe that it is re-created each time.
Jon
-------
2-Oct-80 17:27:43-EDT,651;000000000000
Mail from MIT-MC rcvd at 2-Oct-80 1727-EDT
Date: Thursday, 2 October 1980 16:57-EDT
From: Chris Ryland <CPR at MIT-EE>
To: SOLOMON at RUTGERS
Reply-to: CPR at MIT-MC
cc: Twenex-Wizards at mc
Subject: twenex-wizards mailing list.
Jon: No, I'd rather not have the MC one diverge; I think it should be
used soley for what MRC is using TOPS-20.DIS now (ie, real system
maintainers). Maybe the best policy is to send security-related
things to MRC directly, whence he can remail them 'securely', and
otherwise use the MC mailing list. I didn't mean to brew up a storm
here, just wanted to have a simple direct way to get mail to folks.
3-Oct-80 08:25:30-EDT,409;000000000000
Mail from MIT-MC rcvd at 3-Oct-80 0825-EDT
Date: 3 Oct 1980 0815-EDT
From: RGSMITH at RUTGERS
Subject: Re: MOUNTR lossage
To: CPR at MIT-MC, Twenex-Wizards at MIT-MC
In-Reply-To: Your message of 2-Oct-80 1506-EDT
Our version of MOUNTR is up to the same things. I don't think the problem
is local to you as we are running a virgin copy of rel-4 and are still
having the same problem.
-------
9-Oct-80 08:12:50-EDT,916;000000000000
Mail from SU-SCORE rcvd at 9-Oct-80 0812-EDT
Mail-from: ARPANET site RUTGERS rcvd at 9-Oct-80 0014-PDT
Date: 9 Oct 1980 0314-EDT
From: WATROUS at RUTGERS
Subject: Internal illegal instruction on I MEM
To: Admin.MRC at SU-SCORE
Remailed-date: 9 Oct 1980 0403-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
Problem:
A user ^C's out of MM, does an I MEM, and gets "?Internal
illegal instruction at <pc> - Invalid source/destination designator"
Diagnosis:
The utility routine which outputs a file name for the JFN
(%S) cleverly handles JFNS errors (the JFN in question was
restricted), then saves the error code as the output JFN. Next time
output is tried, blam.
Solution:
In EXECSU, make RET in literal ERCAL'ed at %S+4 a RETSKP.
This has been fixed in rel 5.
-------
[NOTE BY MRC: Even better, make the ERCAL an ERJMP.]
11-Oct-80 22:38:40-EDT,1608;000000000000
Mail from SU-SCORE rcvd at 11-Oct-80 2238-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 11-Oct-80 1039-PDT
Date: 11 Oct 1980 1235-CDT
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Line printer problems
To: admin.mrc at SU-SCORE
Remailed-date: 11 Oct 1980 1934-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
Have you had to make any patches to LPTSPL to solve problems
like the following:
In the middle of printing a file, the LPT will get an I/O
error, after which the VFU gets totally screwed up. It seems
that it still knows about top-of-page, but it doesn't
automatically skip the paper folds, and the header & trailer
pages are completely overstruck. This will continue until
I manage to get the VFU reloaded. The only way I know to
do this is to SHUTDOWN and START the printer. I'm wondering
if the I/O errors are a hardware problem, or if perhaps
LPTSPL should automatically reload the VFU after all I/O
errors...Unfortunately this would probably screw it up more,
since the paper would need to be realigned...Anyway, this
is happening about once or twice a day, so it's getting to
be a pain. Also, do you know a simpler way to cause the VFU
to be reloaded? I'm wondering if this is related to
another problem with the LPT which I may have told you about--
when the system comes up for the first time after being powered
down, the LPT will start spewing paper out continuously until
you physically turn it off line. Since it is in another room,
this might take a while to notice!
-------
25-Oct-80 21:15:28-EDT,963;000000000000
Mail from SU-SCORE rcvd at 25-Oct-80 2115-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 25-Oct-80 1722-PDT
Date: 25 Oct 1980 1813-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Galaxy questions
To: admin.mrc at SU-SCORE
Remailed-date: 25 Oct 1980 1809-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
(Mark, could you mail to wizard list if you don't know the answer)
Does anyone know why galaxy's spool file (primary-master-queue-file.quasar)
keeps growing in size, seemingly without bound (on our system I've seen it
as large as 1000 pages)?? Is it a (fixable) bug?? Any solutions other
than periodically deleting it and having quasar re-create it??
-------
[MRC - My PRIMARY-MASTER-QUEUE-FILE.QUASAR is only 52 pages, and
seems quite happy to stay at that size or smaller. Perhaps
spooler and/or system crashes cause it to grow, both relatively
rare occurances at SCORE.]
27-Oct-80 20:29:09-EST,679;000000000000
Mail from SU-SCORE rcvd at 27-Oct-80 2028-EST
Mail-from: ARPANET site CIT-20 rcvd at 27-Oct-80 1316-PST
Date: 27 Oct 1980 1316-PST
From: Barry Megdal <BARRY at CIT-20>
Subject: ciphers
To: admin.mrc at SU-SCORE
Remailed-date: 27 Oct 1980 1722-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: BBoard at SU-SCORE, BBoard at SU-AI,
[SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
Do you know of any programs on the net (Stanford in particular) that are designed to aid in the breaking of simple alphabetic cyphers (codes)? I would
appreciate any info you have as soon as possible, as I have a pending
application for such a program.
thanks.
-------
29-Oct-80 04:55:50-EST,1541;000000000001
Mail from SU-SCORE rcvd at 29-Oct-80 0455-EST
Mail-from: ARPANET site RUTGERS rcvd at 29-Oct-80 0139-PST
Date: 29 Oct 1980 0439-EST
From: HEDRICK at RUTGERS
Subject: monitor patch
Remailed-date: 29 Oct 1980 0147-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
problem: gtjfn on MT0:AAAAAAAAAAAAAAAAAAAAAAAAAAAA (i.e. more
than 16 characters) returns the length of the string
in AC 1 instead of an error message.
diagnosis: All the tests are there to make sure that the file
spec isn't too long (tape labels don't have enough
space for a full 39-char file name). However no one
ever bothered to add an error code for it. Thus
two places there are RETBAD() where there should be
RETBAD(error code).
cure: For testing we used GJFX5, which is the code used when
a normal file name is longer than 39 char's. Since the
message mentions the number 39, this isn't right.
Actually, one should add to MONSYM.MAC:
.ERR (3002,gjfxxx,<File name plus extension cannot be longer than 16 characters on labelled tape>)
In module TAPE.MAC, at TSTSZ0+10, there is a
RETBAD()
Change this to
RETBAD(GJFXXX)
or GJFX5 if you don't want to regenerate the error messages.
At MTEXL+about 25 you will find
ADD T1,SVSIZ ;GET SIZE OF BOTH STRINGS
CAILE T1,^D16 ;FITS?
RETBAD () ;NO
TQNN <NAMSF,EXTSF,VERSF> ;ANY STEPPING GOING ON?
Replace the RETBAD () with
RETBAD (GJFXXX)
or GJFX5.
-------
31-Oct-80 08:26:57-EST,1322;000000000000
Mail from SU-SCORE rcvd at 31-Oct-80 0826-EST
Mail-from: ARPANET site UTAH-20 rcvd at 29-Oct-80 1236-PST
Date: 29 Oct 1980 1335-MST
From: C-GRISS at UTAH-20
Subject: Missing CONFIRM in Dir Command
To: Admin.Mrc at SU-SCORE
Remailed-date: 31 Oct 1980 0520-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
Problem:
@@NO PROT(esc) and friends dont wait for the CR. This causes
a problem in PCL using the NO subcommand of DIRECTORY: The subcommands
get lost and exec left in strange parse state until ^C^C typed.
Diagnosis:
The keyword branch for the NO subcommand needs to have
a CONFIRM installed before it returns to regular subcommand parsing.
Solution:
; EXEC3.MAC.3 & EXEC3.MAC.1 29-Oct-80 1316 PAGE 1
LINE 1, PAGE 1
1) ;DSK:<4.EXEC.LOCAL>EXEC3.MAC.3 29-Oct-80 13:02:02, Edit by C-GRISS
1) ;c2: NO command of DIR not confirming
1) ;REL4:<4.EXEC.LOCAL>EXEC3.MAC.1 20-Oct-80 21:25:39, Edit by C-GRISS
LINE 1, PAGE 1
2) ;REL4:<4.EXEC.LOCAL>EXEC3.MAC.1 20-Oct-80 21:25:39, Edit by C-GRISS
LINE 36, PAGE 9
1) noclsc,< JRST (P3) > ;c2: want a CONFRM
1) clsc,< CALL (P3) ;c2:
1) CONFIRM ;c2:
1) RET > ;c2:
1)
LINE 36, PAGE 9
2) JRST (P3)
2)
Note: Youll need to remove the CLSC stuff.
-------
31-Oct-80 08:57:17-EST,1177;000000000000
Mail from SU-SCORE rcvd at 31-Oct-80 0857-EST
Mail-from: ARPANET site RUTGERS rcvd at 30-Oct-80 1051-PST
Date: 30 Oct 1980 1347-EST
From: WATROUS at RUTGERS
Subject: PRARG interface bug in EXEC
To: Admin.MRC at SU-SCORE, King at CMU-20C
cc: Remarks at RUTGERS
Remailed-date: 31 Oct 1980 0544-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.54: ;
Problem:
A user compiles a SAIL program which contains an error. The
user has SAIL replace itself with the editor (in this case, EDIT) to
correct the problem. The user then tells EDIT to execute the last
compile class command via the EXEC's PRARG interface. The EXEC then
chokes on a PDL overflow.
Diagnosis:
EXEC routines being used are eating up stack with STKVARs,
TRVARs, etc., but the user is never coming up for air (to EXEC
command level) to reinit the stack. Lengthening the stack only
postpones the problem.
Solution:
Since the data on the stack at CMAGN is never referenced
after that point, the stack can be reinitialized there. At CMAGN in
EXECCS, insert the instruction:
XCT INISTK ;throw away what's on stack
-------
11-Nov-80 00:22:28-EST,798;000000000001
Mail from SU-SCORE rcvd at 11-Nov-80 0022-EST
Date: 10 Nov 1980 2115-PST
From: g.Meyers at SU-SCORE (Harris A. Meyers)
Reply-to: Meyers@SRI-KL
Subject: RSX20F source pack
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.55:
cc: Meyers at SRI-KL
If you have received a source pack for the release of 20F that shiped with
ver 4, you might want to check directory [20,30], so far out of 2 sites
checked, our selves and Utah, both have bad files in this area. The area should
contain 3 files, TOPS20.MAC TOPS10.MAC and T1091.MAC, doing a directory of
this area will gea a read atribute error for each of those files if they are
bad. Could you check this and let me know what you find, so we can tell weather
it is a case of 2 bad packs, or weather SDC screwed up again.
thanks
harris
-------
13-Nov-80 07:25:46-EST,777;000000000000
Mail from SU-SCORE rcvd at 13-Nov-80 0725-EST
Date: 13 Nov 1980 0417-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: GLXLIB.MEM
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.55: ;
Has anybody seen or heard of this file? According to the DEC Galaxy
person at DECUS, it was distributed with the documentation for the
TOPS-10 release, and was also supposed to be on the release 4 SWSKIT
tape. I don't have it, although it's possible it came out on a
different tape from what I got. If anybody can make this file
available (DEC folks?) or can explain why it isn't, please send a
note to Patrick Milligan (G.Milligan@SCORE) with a cc to myself.
-- Mark --
-------
13-Nov-80 13:32:49-EST,1823;000000000000
Mail from SU-SCORE rcvd at 13-Nov-80 1332-EST
Date: 13 Nov 1980 1022-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: 32-bit leader question
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.55: ;
cc: Feinler at SRI-KL, DCAcode535 at USC-ISI, Postel at USC-ISIF,
Geoff at DARCOM-KA
Folks -
As we all know, DCA has scheduled the demise of 32 bit
leaders on the ARPANET at the end of this year. According to the
best of my knowledge, SRI-KL was the last TOPS-20 system which
was running with 32 bit leaders, and they converted a few weeks
ago. I would like to know if there is any reason user programs
should continue to worry about supporting the old 32 bit leader
operating system interface.
In particular, I am the author/maintainer of an alternative
TELNET program to BBN TELNET (my program, colloquially called
"TN" on many systems, is 2-5 times faster and uses 55% less CPU)
which makes a runtime check for whether it is on a 32 or 96 bit
leader system and which sets up its internal data structures
accordingly. Other programs presently under development use the
same routines. If there is no reason for its continued existance
I would like to remove the support for 32 bit leaders entirely; I
wouldn't be able to test it any more and it will get in the way
of my adding TCP/IN support.
I have heard rumors of private ARPANETs which may not be
joining ARPANET in the 96 bit leader transition. Is this the
case? Do these networks use ARPANET user software? Are there
any TOPS-20 users of these networks who are using my TELNET
program and would they be impacted by this change?
Thanks in advance for any information you can supply.
-- Mark --
-------
21-Nov-80 15:08:46-EST,603;000000000000
Mail from SU-SCORE rcvd at 21-Nov-80 1508-EST
Date: 21 Nov 1980 0751-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: SPR 20-14934 answer
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.56: ;
There is a bug in the patch in the answer for SPR 20-14934. The proper
fix for MSTDMC is to have SETOM JSSTLK(P5) not SETOM JSSTLK. MSTDCF is
alright with SETOM JSSTLK. They should NOT be the same routine, contrary
to what the patch says. Read the code carefully when installing this
patch!!
-------
10-Dec-80 01:45:58-EST,000001262;000000000000
Date: 10 Dec 1980 0145-EST
From: SOLOMON
Subject: GTDIR getting garbage length in block bug..
To: watrous, TOPS-20, admin.mrc at SU-SCORE
cc: Solomon
GTDIR seems to hang the system when there is a garbaged length
in the block.
In the EXEC, the command SET DIRECTORY ARCHIVE-EXPIRED-FILES does a
GTDIR to get the info needed, and then switches the mode, and uses
CRDIR to set it. My exec didnt bother to clear the block out before
it did the GTDIR.
I dont know if the default EXEC has this problem, but to be paranoid,
do the following:
at DMODE: insert:
DMODE: MOVEI B,GTDLN ;length of the GTDIR block
MOVEM B,SEBLK+.CDLEN ;put it where monitor can find it
SETZM SEBLK+1 ; zero out first word
HRLI B,SEBLK+1 ; set up for BLT
HRLI B,SEBLK+2 ; start of BLT output
BLT B,SEBLK+GTDLN-1 ;zero out the memory
This should be done before XARCSW is turned on in the system
exec.
This really deserves monitor investigation...
Mark - Ever see anything like this before? A user does a
SET DIR ARCHIVE-EXPIRED-FILES, and then gets hung. Anyone who
does systat (same as the other one I sent you) gets hung... etc
we had to reload the system because the whole fork structure was
locked... sigh...
========
10-Dec-80 05:27:28-EST,1565;000000000000
Mail from SU-SCORE rcvd at 10-Dec-80 0527-EST
Mail-from: ARPANET site RUTGERS rcvd at 9-Dec-80 2246-PST
Date: 10 Dec 1980 0145-EST
From: Jon Solomon <Solomon at RUTGERS>
Subject: GTDIR getting garbage length in block bug..
To: watrous at RUTGERS, TOPS-20 at RUTGERS, admin.mrc at SU-SCORE
cc: Solomon at RUTGERS
Remailed-date: 10 Dec 1980 0220-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.56: ;
GTDIR seems to hang the system when there is a garbaged length
in the block.
In the EXEC, the command SET DIRECTORY ARCHIVE-EXPIRED-FILES does a
GTDIR to get the info needed, and then switches the mode, and uses
CRDIR to set it. My exec didnt bother to clear the block out before
it did the GTDIR.
I dont know if the default EXEC has this problem, but to be paranoid,
do the following:
at DMODE: insert:
DMODE: MOVEI B,GTDLN ;length of the GTDIR block
MOVEM B,SEBLK+.CDLEN ;put it where monitor can find it
SETZM SEBLK+1 ; zero out first word
HRLI B,SEBLK+1 ; set up for BLT
HRRI B,SEBLK+2 ; start of BLT output
BLT B,SEBLK+GTDLN-1 ;zero out the memory
This should be done before XARCSW is turned on in the system
exec.
This really deserves monitor investigation...
Mark - Ever see anything like this before? A user does a
SET DIR ARCHIVE-EXPIRED-FILES, and then gets hung. Anyone who
does systat (same as the other one I sent you) gets hung... etc
we had to reload the system because the whole fork structure was
locked... sigh...
-------
10-Dec-80 09:39:06-EST,451;000000000000
Mail from MIT-AI rcvd at 10-Dec-80 0939-EST
Date: Wednesday, 10 December 1980 09:22-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Jon Solomon <Solomon at RUTGERS>
Reply-to: CPR at MIT-MC
Cc: TOPS-20 at RUTGERS, admin.mrc at SU-SCORE, watrous at RUTGERS
Subject: GTDIR getting garbage length in block bug..
DEC took out those commands from the standard exec for a good reason:
the monitor is definitely buggy when it comes to such things.
12-Dec-80 03:26:08-EST,917;000000000000
Mail from MIT-XX rcvd at 12-Dec-80 0326-EST
Date: 12 Dec 1980 0323-EST
From: JIS at MIT-XX
Subject: Re: GTDIR getting garbage length in block bug..
To: Solomon at RUTGERS, watrous at RUTGERS, TOPS-20 at RUTGERS,
admin.mrc at SU-SCORE
In-Reply-To: Your message of 10-Dec-80 0145-EST
We have seen this bug on MIT-EE. The problem is that the directory lock for
the directory in question is being left locked. Then slowly (or quickly
if you users like to systat) every job hangs waiting for the lock to become
free. We solved the problem in the exec, by simply removing the
archive-expired-files command (the set command...) being that we don't
run the archive virtual disk system on MIT-EE anyway.
The real problem is in GTDIR, and is on my queue of things to look at,
so unless someone comes up with the problem sooner, I will mail out my
fix (if and when I work on it).
-Jeff
-------
13-Dec-80 02:30:02-EST,629;000000000000
Mail from SU-SCORE rcvd at 13-Dec-80 0229-EST
Date: 12 Dec 1980 2327-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: Re: GTDIR getting garbage length in block bug..
To: JIS at MIT-XX, Solomon at RUTGERS, watrous at RUTGERS, TOPS-20 at RUTGERS
In-Reply-To: Your message of 12-Dec-80 0023-PST
The problem is obviously something like a page fault is occuring while the
directory lock is locked. Probably both the length and things like the
string pointer should be validated before locking the directory.
-------
14-Dec-80 02:03:10-EST,2065;000000000001
Mail from SU-SCORE rcvd at 14-Dec-80 0202-EST
Mail-from: ARPANET site RUTGERS rcvd at 13-Dec-80 2252-PST
Date: 14 Dec 1980 0127-EST
From: HEDRICK at RUTGERS
Subject: for Tops-20 dist list: problem with DDT in extended addresses
To: admin.mrc at SU-SCORE
Remailed-date: 13 Dec 1980 2254-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.58: ;
I am now playing with an extended-addressing version of Lisp. I
find that most of the extended addressing support is in fairly
good shape. (In particular, you can create private pages, despite
what some people seem to think.) DDT works surprisingly well.
But it has this one annoying problem: when doing $X, it
interprets location 10,,1 as AC 1. DDT's address calculation is
quite complex. Unfortunately so is the hardware's. Someone
really needs to rewrite the appropriate routine in DDT, following
the flowcharts for the hardware exactly. Then we can be sure it
works. I settled for solving this one problem. Note that the code
is complicated by the fact that global address 1,,1 is AC1. Section
1 is special. (come on guys...)
Here is the patch:
File 1) DSK:DDT.MAC[4,211] created: 0054 14-Dec-1980
File 2) OLD:DDT.MAC[4,211] created: 0418 30-Aug-1980
1)94 JRST CIFIW4 ;[CLH]
1) ;HERE IF GLOBAL ADDRESSING
1) TLZ T,770000 ;[CLH] LEAVE ONLY EFIW Y FIELD
1) HLLZ S,T ;[CLH] UPDATE S TO NEW CURRENT SECTION
1) TLNN T,007776 ;[CLH] IF IN SECTION ZERO OR 1
1) JRST CIFIW6 ;[CLH] TREAT AS AC IF 0 TO 17 IN RH
1) JRST CIFIW7 ;[CLH] ELSE IT IS NOT AN AC
1) ;HERE IF LOCAL ADDRESSING
1) CIFIW4: HLL T,S ;THEN E STAYS IN LOCAL SECTION
****
2)94 CIFIW4: HLL T,S ;THEN E STAYS IN LOCAL SECTION
**************
1)94 JRST CIFIW6 ;AND GO CHECK FOR AC
1) ;CHECK IFIW INDIRECTION
****
2)94 ;CHECK IFIW INDIRECTION
**************
1)94 CIFIW7: POP P,R ;GET BACK ORIGINAL WORD
1) TXNN R,@ ;IFIW I BIT ON?
****
2)94 POP P,R ;GET BACK ORIGINAL WORD
2) TXNN R,@ ;IFIW I BIT ON?
**************
-------
15-Dec-80 04:29:53-EST,687;000000000000
Mail from SU-SCORE rcvd at 15-Dec-80 0429-EST
Date: 15 Dec 1980 0110-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: NVTs hung in CLZW wait
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.58: ;
Has anybody come up with a fix for this problem yet? I recently was
forced to reboot SCORE after a perfectly good run because SCORE ran
out of NVTs, all of which were hung in CLZW. The problem seems to
be that NVTDET somehow fails to completely flush the NVT. At the
very least, is there a stopgap fix to completely flush all NVTs when
the network is cycled?
-- Mark --
-------
15-Dec-80 23:54:38-EST,1121;000000000000
Mail from MIT-MC rcvd at 15-Dec-80 2354-EST
Date: 15 Dec 1980 2044-PST
From: ROODE at SRI-KL (David Roode)
Subject: directory disk allocation definition
To: twenex-wizards at MIT-MC
I think that the overhead page used for each file in a directory
should be charged to that directory's disk allocation. Otherwise,
there is too much uncertainty in enforcement of disk allocations.
A pathological user could use up a lot of disk space by creating
0 page files, and be charged for none. More commonly, there are
efficiencies in storing a given amount of data in large files
versus storing the same amount of date in a greater number
of smaller files. Masking the pointer pages from
the user's view encourages him to disregard this efficiency.
Today I encountered a user who had inherited a directory which
had so many files of one page each that he was up against the
release 3 limit in files per directory.
Besides wasting disk space, small files cause backup
programs like dumper which do a full filesystem scan to take
an increased amount of time to backup the same amount
of data.
-------
16-Dec-80 00:20:03-EST,468;000000000000
Mail from MIT-MC rcvd at 16-Dec-80 0019-EST
Date: 15 Dec 1980 2110-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: Re: directory disk allocation definition
To: ROODE at SRI-KL, twenex-wizards at MIT-MC
In-Reply-To: Your message of 15-Dec-80 2044-PST
2I think it is insane to charge users for index pages. My users
would never stand for it.
-------
16-Dec-80 10:02:06-EST,1562;000000000000
Mail from MIT-MC rcvd at 16-Dec-80 1001-EST
Date: Tuesday, 16 December 1980 09:52-EST
From: Chris Ryland <CPR at MIT-EECS>
To: ROODE at SRI-KL (David Roode)
Reply-to: CPR at MIT-MC
Cc: twenex-wizards at MIT-MC
Subject: directory disk allocation definition
From: ROODE at SRI-KL (David Roode)
Re: directory disk allocation definition
I think that the overhead page used for each file in a directory
should be charged to that directory's disk allocation. Otherwise,
there is too much uncertainty in enforcement of disk allocations.
As MRC pointed out, there are political problems with changing this
definition this late in the Tops-20 game. However, I agree in theory
with you, since those pages actually belong to a directory.
Besides wasting disk space, small files cause backup
programs like dumper which do a full filesystem scan to take
an increased amount of time to backup the same amount
of data.
Well, but all you're saying is that more files are worse than less
files, which is certainly true. I doubt if one-page files have
anything to do with DUMPER's problems, which really stem from its
desire to use RCDIR (VEERRRY SLOOOW) stepping and GNJFN stepping
within a directory. We still can't blame DEC for doing it this way,
though, since it IS modular and all that rot, but it would be quite a
bit faster if it did the scan by mapping the directories itself and
grovelling therefrom. Oh well, it would also be nice if DEC would
rewrite TOPS-20 and make it capability-based.
16-Dec-80 17:07:41-EST,1253;000000000000
Mail from MIT-MC rcvd at 16-Dec-80 1707-EST
Date: 16 Dec 1980 1357-PST
From: ROODE at SRI-KL (David Roode)
Subject: Re: directory disk allocation definition
To: CPR at MIT-MC
cc: TWENEX-Wizards at MIT-MC
In-Reply-To: Your message of 16-Dec-80 0657-PST
I notice that it is much quicker to build a left half word
of a directory number from a STDEV and then step
the right half word from one on up to some
extra large possible high directory number (old LSTDRN)
doing DIRST's along the way to verify existence of a directory
and obtain the string than it is to use stepping RCDIR.
This doesn't seem to lack much in modularity to me. LSTDRN
being accessible would be nice.
The speed advantage does not hold as well on a maximally
subdirectoried system. Simply splitting <root-directory>
into 26 top level directories with an approximately
even distribution of user directories seems to speed a stepping
RCDIR tremendously. I suspect it speeds LOTS of other operations
as well. I bet most sites that categorize users and
create them as subdirectories of the categories do not have
enough categories to gain this advantage.
In any event, the method of the first paragraph is much
faster for stepping directories.
-------
16-Dec-80 20:40:30-EST,2329;000000000000
Mail from MIT-MC rcvd at 16-Dec-80 2040-EST
Date: 16 Dec 1980 2017-EST
From: Dan Tappan <TAPPAN at BBNG>
Sender: TAPPAN at BBNG
Subject: SET DIRECTORY ARCHIVE-ONLINE-EXPIRED-FILES Bug
To: TWENEX-WIZARDS at MC
I got hit with this today, It looks to me like the problem
(in the monitor) is that when the EXEC passes it the garbage
GTDIR block, it is looking in it for pointers to where to store
various things, since its fairly full of randomness (including
pointers to code space) this caused an ILMWR trap out of the
code, leaving the directory still locked.
I fixed it by putting in checks to be sure that all pointers are
legit before doing anything (SRCCOM follows). I've tested it out
and it seems to work (anyway the command dies with an ILMWR rather
than hanging things up, which is the correct response)
____
; JSYSA.MAC.5 & JSYSA.MAC.4 16-Dec-80 2012 PAGE 1
LINE 12, PAGE 49
1)
1) ;;; At this point, (before we actually lock down the directory)
1) ;;; We must make sure that all the pointers point to acessable
1) ;;; places, this is so an ILMRF won't zap us with the directoy still
1) ;;; locked
1) XCTU [MOVES 0(Q3)] ; Make sure block is writable
1) MOVE A,Q3 ; And that
1) ADDI T1,(Q2) ; The last word
1) XCTU [MOVES 0(A)] ; Is also
1) CAIGE Q2,.CDUGP ; Do we want groups?
1) JRST GTDIR1 ; No, skip next tests
1) UMOVE A,.CDUGP(Q3) ; get pointer
1) XCTU [MOVES 0(A)] ; test for accesability
1) CAIGE Q2,.CDDGP ; directory groups?
1) JRST GTDIR1 ; no
1) UMOVE A,.CDDGP(Q3)
1) XCTU [MOVES 0(A)] ; Check it out
1) CAIGE Q2,.CDCUG ; inferior groups?
1) JRST GTDIR1 ; no
1) UMOVE A,.CDCUG(Q3) ;..
1) XCTU [MOVES 0(A)] ; check it out
1) CAIGE Q2,.CDDAC ; Account?
1) JRST GTDIR1 ; No
1) UMOVE A,.CDDAC(Q3) ; Get pointer
1) XCTU [MOVES 0(A)] ; and be sure is allowed
1) ;;; Made it, all pointers are valid
1) GTDIR1: SETZ P1, ;INITIALIZE PRIVILEGE FLAG
1) UMOVE A,1 ;GET DIRECTORY NUMBER
LINE 12, PAGE 49
2) SETZ P1, ;INITIALIZE PRIVILEGE FLAG
2) UMOVE A,1 ;GET DIRECTORY NUMBER
LINE 78, PAGE 49
1) LOAD B,DRPSW,(A) ;GET POINTER TO NAME STRING
1) ADD B,DIRORA ;MAKE IT ABSOLUTE
LINE 52, PAGE 49
2) GTDIR1: LOAD B,DRPSW,(A) ;GET POINTER TO NAME STRING
2) ADD B,DIRORA ;MAKE IT ABSOLUTE
-------
18-Dec-80 10:24:50-EST,2017;000000000000
Mail from MIT-MC rcvd at 18-Dec-80 1024-EST
Date: 18 Dec 1980 1012-EST
From: TAPPAN at BBND
Subject: Re: Previous bugfix to GTDIR%
To: twenex-wizards at MC
A slightly better version follows, it is better in that the
checks don't affect the "Get system defaults" function,
which can legally have grabage in some of those areas.
----
; JSYSA.MAC.7 & JSYSA.MAC.3 18-Dec-80 0956 PAGE 1
LINE 15, PAGE 49
1)
1) ;;; At this point, (before we actually lock down the directory)
1) ;;; We must make sure that all the pointers point to acessable
1) ;;; places, this is so an ILMRF won't zap us with the directoy still
1) ;;; locked
1) UMOVE B,C ; Get password pointer
1) SKIPE B ; If non-zero
1) XCTU [MOVES 0(B)] ; Be sure the first word, at least, is writable
1) XCTU [MOVES 0(Q3)] ; Make sure block is writable
1) MOVE B,Q3 ; And that
1) ADDI B,(Q2) ; The last word
1) XCTU [MOVES 0(B)] ; Is also
1) CAIGE Q2,.CDUGP ; Do we want groups?
1) JRST GTDIR1 ; No, skip next tests
1) UMOVE B,.CDUGP(Q3) ; get pointer
1) XCTU [MOVES 0(B)] ; test for accesability
1) CAIGE Q2,.CDDGP ; directory groups?
1) JRST GTDIR1 ; no
1) UMOVE B,.CDDGP(Q3)
1) XCTU [MOVES 0(B)] ; Check it out
1) CAIGE Q2,.CDCUG ; inferior groups?
1) JRST GTDIR1 ; no
1) UMOVE B,.CDCUG(Q3) ;..
1) XCTU [MOVES 0(B)] ; check it out
1) CAIGE Q2,.CDDAC ; Account?
1) JRST GTDIR1 ; No
1) UMOVE B,.CDDAC(Q3) ; Get pointer
1) XCTU [MOVES 0(B)] ; and be sure is allowed
1) ;;; Made it, all pointers are valid
1) GTDIR1: STKVAR <GTDINO>
1) MOVEM A,GTDINO ;SAVE DIRECTORY NUMBER
LINE 15, PAGE 49
2) STKVAR <GTDINO>
2) MOVEM A,GTDINO ;SAVE DIRECTORY NUMBER
; JSYSA.MAC.7 & JSYSA.MAC.3 18-Dec-80 0956 PAGE 2
LINE 81, PAGE 49
1) LOAD B,DRPSW,(A) ;GET POINTER TO NAME STRING
1) ADD B,DIRORA ;MAKE IT ABSOLUTE
LINE 52, PAGE 49
2) GTDIR1: LOAD B,DRPSW,(A) ;GET POINTER TO NAME STRING
2) ADD B,DIRORA ;MAKE IT ABSOLUTE
____
/Dan
-------
18-Dec-80 16:52:11-EST,2221;000000000000
Mail from SU-SCORE rcvd at 18-Dec-80 1651-EST
Mail-from: ARPANET site MIT-MC rcvd at 18-Dec-80 0717-PST
Date: 18 Dec 1980 1012-EST
From: TAPPAN at BBND
Subject: Re: Previous bugfix to GTDIR%
To: twenex-wizards at MC
Remailed-date: 18 Dec 1980 1341-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.58: ;
A slightly better version follows, it is better in that the
checks don't affect the "Get system defaults" function,
which can legally have grabage in some of those areas.
----
; JSYSA.MAC.7 & JSYSA.MAC.3 18-Dec-80 0956 PAGE 1
LINE 15, PAGE 49
1)
1) ;;; At this point, (before we actually lock down the directory)
1) ;;; We must make sure that all the pointers point to acessable
1) ;;; places, this is so an ILMRF won't zap us with the directoy still
1) ;;; locked
1) UMOVE B,C ; Get password pointer
1) SKIPE B ; If non-zero
1) XCTU [MOVES 0(B)] ; Be sure the first word, at least, is writable
1) XCTU [MOVES 0(Q3)] ; Make sure block is writable
1) MOVE B,Q3 ; And that
1) ADDI B,(Q2) ; The last word
1) XCTU [MOVES 0(B)] ; Is also
1) CAIGE Q2,.CDUGP ; Do we want groups?
1) JRST GTDIR1 ; No, skip next tests
1) UMOVE B,.CDUGP(Q3) ; get pointer
1) XCTU [MOVES 0(B)] ; test for accesability
1) CAIGE Q2,.CDDGP ; directory groups?
1) JRST GTDIR1 ; no
1) UMOVE B,.CDDGP(Q3)
1) XCTU [MOVES 0(B)] ; Check it out
1) CAIGE Q2,.CDCUG ; inferior groups?
1) JRST GTDIR1 ; no
1) UMOVE B,.CDCUG(Q3) ;..
1) XCTU [MOVES 0(B)] ; check it out
1) CAIGE Q2,.CDDAC ; Account?
1) JRST GTDIR1 ; No
1) UMOVE B,.CDDAC(Q3) ; Get pointer
1) XCTU [MOVES 0(B)] ; and be sure is allowed
1) ;;; Made it, all pointers are valid
1) GTDIR1: STKVAR <GTDINO>
1) MOVEM A,GTDINO ;SAVE DIRECTORY NUMBER
LINE 15, PAGE 49
2) STKVAR <GTDINO>
2) MOVEM A,GTDINO ;SAVE DIRECTORY NUMBER
; JSYSA.MAC.7 & JSYSA.MAC.3 18-Dec-80 0956 PAGE 2
LINE 81, PAGE 49
1) LOAD B,DRPSW,(A) ;GET POINTER TO NAME STRING
1) ADD B,DIRORA ;MAKE IT ABSOLUTE
LINE 52, PAGE 49
2) GTDIR1: LOAD B,DRPSW,(A) ;GET POINTER TO NAME STRING
2) ADD B,DIRORA ;MAKE IT ABSOLUTE
____
/Dan
-------
23-Dec-80 13:46:21-EST,2735;000000000000
Mail from RADC-TOPS20 rcvd at 23-Dec-80 1345-EST
Date: 23 Dec 1980 1325-EST
From: Kevin Paetzold <PAETZOLD at RADC-TOPS20>
To: R4-Bugs at DEC-2136, G.Cower at SU-SCORE, Baker at AFSC-HQ,
Perilli at AFSC-HQ, Allen at BBND, EONeil at BBND, JBorchek at BBNG,
Tappan at BBNG, G.Milligan at SU-SCORE, Lindblad at CIT-20,
King at CMU-20C, G.daCruz at SU-SCORE, G.SLogin at SU-SCORE,
Kincl at UTAH-20, G.LCampbell at SU-SCORE, Lyons at DEC-MARLBORO,
G.Miller at SU-SCORE, RGSmith at RUTGERS, G.Eldre at SU-SCORE,
CPR at MIT-XX, JIS at MIT-XX, MT at MIT-XX, Wallace at MIT-XX,
NCP.Pine at SU-SCORE, Rowe at NBS-10, Mittal at RUTGERS,
GeoffM at RAND-AI, Mike at RAND-AI, Hedrick at RUTGERS,
TOPS-20 at RUTGERS, Admin.MRC at SU-SCORE, Admin.Bosack at SU-SCORE,
Admin.JQJ at SU-SCORE, Admin.Lougheed at SU-SCORE, Gilmurray at SUMEX-AIM,
Schoen at SUMEX-AIM, Sweer at SUMEX-AIM, Larson at SRI-KL,
Meyers at SRI-KL, Clive at UTEXAS, CTaylor at USC-ISIF,
Dale at USC-ISIB, Koda at USC-ISID, LSims at USC-ISIE,
Thompson at USC-ECL, Frank at UTAH-20, C-Griss at UTAH-20
Reply-to: Paetzold at RADC-TOPS20
Telephone: 315-330-4013 AV-587
Subject: TOPS20AN Telnet IP/SYNCH bug
Message-ID: 11690775042.5.240.53008 at RADC-TOPS20
I have found a solution for the Telnet IP/SYNCH bug. This bug has been in
existence before release 4. The problems stems from the fact that if a DECR
macro is used on a field containing zero it will mess up other fields. The
solution was to use a load, aos/sos, stor sequence.
File 1) DSK:TTNTDV.MAC[4,55] created: 0848 23-Dec-1980
File 2) DSK:TTNTDV.OLD[4,55] created: 1616 21-May-1980
1)1 ;<DEC.R4.MONITOR>TTNTDV.MAC.4, 23-Dec-80 08:48:00, Edit by PAETZOLD
1) ;dont use decr and incr on ptitc as they get confused and trash rest of word
1) ;<PAETZOLD.REL4.MSOURCE>TTNTDV.MAC.3, 21-May-80 16:16:29, Edit by PAETZOLD
****
2)1 ;<PAETZOLD.REL4.MSOURCE>TTNTDV.MAC.3, 21-May-80 16:16:29, Edit by PAETZOLD
**************
1)9 NVTDSC:: ;[KWP] INC COUNTS -1, SYNC CHAR COUNTS 1
1) LOAD Q1,PTITC,(T2) ;[KWP] GET INS/SYNCH COUNT
1) SOJ Q1, ;[KWP] DECREMENT IT
1) STOR Q1,PTITC,(T2) ;[KWP] STORE THE NEW PTITC
1) LOAD Q1,PTNTI,(T2) ;GET INPUT UNIT
****
2)9 NVTDSC::DECR PTITC,(T2) ;INS COUNTS -1, SYNC CHAR COUNTS 1
2) LOAD Q1,PTNTI,(T2) ;GET INPUT UNIT
**************
1)32 NVTCL1: ;[KWP] SYNCH COUNT 1, INS COUNTS -1
1) PUSH P,T1 ;[KWP] SAVE T1
1) LOAD T1,PTITC,(T2) ;[KWP] GET COUNT
1) AOJ T1, ;[KWP] ADJUST IT
1) STOR T1,PTITC,(T2) ;[KWP] SAVE NEW COUNT
1) POP P,T1 ;[KWP] GET T1 BACK
1) RET
****
2)32 NVTCL1: INCR PTITC,(T2) ;SYNC COUNTS 1, INS COUNTS -1
2) RET
**************
--------