1-Jan-81 15:58:54-EST,540;000000000000
Mail from SU-SCORE rcvd at 1-Jan-81 1558-EST
Mail-from: ARPANET site DEC-2136 rcvd at 31-Dec-80 1451-PST
Date: 31 Dec 1980 1749-EST
From: Dave Lyons <LYONS at DEC-2136>
To: admin.mrc at SCORE
Subject: Did you know about
Message-ID: 11692920292.4.16.35268 at DEC-2136
Remailed-date: 1 Jan 1981 1302-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.60: ;
The bug in the special queue stuff?
At SNDIM1-3, the
MOVE 3,3(2)
DPB 3,junk
should be
MOVEM 4,3(2)
JFCL
12-Jan-81 21:14:36-EST,739;000000000000
Mail from SU-SCORE rcvd at 12-Jan-81 2114-EST
Mail-from: ARPANET site USC-ECL rcvd at 7-Jan-81 2235-PST
Date: 7 JAN 1981 2234-PST
From: THOMPSON at USC-ECL
Subject: oversigt in PHYSIO
To: smith at ISIB, Admin.MRC at SU-SCORE
Remailed-date: 12 Jan 1981 1808-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.60: ;
While adding a new data mode to the magtapes, i discovered a little
goof in physio. There is a table called MODTAB that purports to give
bytes per word for I/O requests. It should have an EXP 1 at the
end for the tu70 hi-density data mode.
As it turns out, the next word IS a 1, but if you add another
data type, you will lose big.
mark
-------
14-Jan-81 21:15:47-EST,1667;000000000000
Mail from SU-SCORE rcvd at 14-Jan-81 2115-EST
Mail-from: ARPANET site MIT-AI rcvd at 14-Jan-81 1628-PST
Date: Wednesday, 14 January 1981 19:21-EST
From: Chris Ryland <CPR at MIT-EECS>
To: admin.MRC at SU-SCORE
Subject: can you ask people if they've seen this? Tnx.
Remailed-date: 14 Jan 1981 1804-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.60: ;
Date: Wednesday, 14 January 1981 18:52-EST
From: EBM at MIT-XX
To: bug-twenex at MIT-XX
Re: Magtape problem
I have encountered a bug in the magnetic tape code (MTA not MT), which
appears to be very obscure:
Bad behavior: I have a tape with data on it and am at EOT (i.e., in
between the two file marks), but with no jfn to the tape drive. I open
a jfn (normal, not dump mode) and then issue a .MOEOT MTOPR, which
should get me to the end of the tape. Indeed, it eventually does, but
it does so by backspacing, record by record, to the start of the file,
and then spacing to the end of the file.
If I write a program to do essentially what the call does, then my
program works correctly. Here is the algorithm:
backspace 1 file
label: forward 1 file
forward 1 record
if MT%EOF set, then we are after the second file mark, and are
done; otherwise, loop back to "label".
I suspect that the problem has something to do with the way MOEOT steps
through its various states, and particularly the handling of the bit
MTOWT. However, detailed examination of the code has not revealed the
bug to me. It was moderately repeatable, but could be timing dependent.
Sounds like something that DEC should fix ....
15-Jan-81 16:11:17-EST,4071;000000000000
Mail from SU-SCORE rcvd at 15-Jan-81 1610-EST
Mail-from: ARPANET site RUTGERS rcvd at 15-Jan-81 1151-PST
Date: 15 Jan 1981 1452-EST
From: HEDRICK at RUTGERS
Subject: Re: can you ask people if they've seen this? Tnx.
To: cpr at MIT-MC
cc: admin.MRC at SU-SCORE
In-Reply-To: Your message of 14-Jan-81 2116-EST
Remailed-date: 15 Jan 1981 1253-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.60: ;
We have seen behavior that looks like this from DUMPER. I am not
sure we can repeat it. Indeed the SAVE/ARC command may even be
doing this. One would think SAVE/ARC would simply go to the end
of the tape and then start saving. But in fact it seems to go
to the end, back to the beginning, and again to the end. I
conjecture (but have not looked at the code) that this is what is
going on. However the person who has been looking at rel. 4 tape
problems for us is Don Watrous, who is currently on vacation.
He will answer you with more authority than I when he gets back.
In general, tape handling has taken a large leap back at our site
since we brought up rel. 4. We are considering setting all drives
unavailable and going back to our interim archiver. The problems
we are having are:
- tapes are very sensitive to problems in the label area. It
is fairly common for tapes that we know are labelled
to somehow magically become unlabelled (i.e. when you
mount them, MOUNTR no longer sees them as having
valid labels). We are considering setting all our drives
unavailable, and only using the new tape system if a
user needs to deal with labelled tapes.
- the rel. 4 archiver is about an order or magnitude too complex.
Our local interim archiver had users mark files for archiving
by setting a bit in the FDB (same bits as used by BSYS),
and also setting a bit corresponding to the directory number
in a file on system: (like the bit file used by NMAILR).
Then the archiver did
for each marked directory do
for each marked file do
add file to command file
The archiver simply made up a command file to dumper. (We
added a TAKE command to DUMPER. very easy to do.) There
was a second command file (a TAKE file to the EXEC) that
deleted the files. All of this meant that everything
was under the control of the operator. If anything went
wrong, he could back up the tape and rewrite the save set.
Or if he lost one of the two archive tapes, he could simply
copy the other one. DUMPER was modified to have an ARCHIVE
command. ARCHIVE foo was like LIST foo, i.e. it put a listing
to file foo. But it also caused the dump to be done in
"archive mode". This meant that the names of all files being
dumped were appended to the file 20-ARCHIVE.DIR in the
directory from which the files came, long with the tape name.
ARCHIVE was set only for the second of the two archive tapes.
Since we maintained pairs of identical tapes, the tape name
refers to the pair, and we only need one name for each file.
The only disadvantage of this system is that restoration
was manual. (This would be easy to fix. One could add a
RESTORE command to the archiver which would look in
20-ARCHIVE.DIR to validate file names, and make up a command
file for the restoration.)
The disadvantages of the DEC archiver are:
- the whole archive/virtual disk system has so many states,
modes, and flags that no one understands all of it.
- if anything goes wrong during an archive save, the
system is so automated that there is nothing you can
do about it. You can't position the tape and
rewrite a save set, nor can you usefully copy one
of two copies of an archive set if you lose one,
since they aren't guaranteed to be identical.
We are currently working on a program to undo any possible
state that archiving can leave you in and allow us to redo
it. However I suspect that it might be better just to go
back to our old system, possibly with automated retrieval
added.
-------
16-Jan-81 15:48:10-EST,931;000000000000
Mail from SU-SCORE rcvd at 16-Jan-81 1547-EST
Mail-from: ARPANET site USC-ISID rcvd at 15-Jan-81 2306-PST
Date: 15 Jan 1981 1508-PST
From: KODA at USC-ISID (Jim Koda)
Subject: Re: Magtape problem
To: Admin.MRC at SU-SCORE
Remailed-date: 16 Jan 1981 1239-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.61: ;
I just want to point out that there is a serious performance
deficiency in the way Tops-20 handles magtape skip files. Currently
it skip files by skipping 5 records at a time and looking for a
tape mark. The newer tape controllers have this function built in.
We have modified our system to do this and the speed increase is
tremendous. Of course there are systems which do not have skip
file controller (e.g. TU45s) but Tops-20 should use the hardware
function if its available. I have also sent a SPR suggestion to DEC.
/Jim Koda
-------
19-Jan-81 21:16:11-EST,515;000000000000
Mail from SU-SCORE rcvd at 19-Jan-81 2116-EST
Date: 19 Jan 1981 1810-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: bug in DIRECTORY command
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.61: ;
@DIRECTORY,
@@NO SEPARATE
requires two confirmations and acts like SEPARATE.
In EXEC3.MAC, the $$NO table entry for SEPARATE
T SEPARATE,ONEWRD,.SEPAR
should be
T SEPARATE,ONEWRD,.NSEPA
instead.
-------
24-Jan-81 17:38:04-EST,972;000000000000
Mail from MIT-MC rcvd at 24-Jan-81 1737-EST
Date: 24 Jan 1981 1727-EST
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Ethernet protocols
To: local-nets at MIT-MC
Can anyone tell me (or point me) about the "higher level" protocols
being used/developed for use with ethernet? I'd like to know what the
availability, advantages, disadvantages, relative cost, relative
throughput, development stage, availability of source,.... for these
different protocols (and of course their implementations). I've only
heard of PUP and CHAOSNET, if there are others I'd like to know. Also
since we (read that I) will be implementing one in the near future (as
soon as it can be decided which one to do), we (I) are willing to
share/cooperate our results with others. At present I am planning to
connect 2 DEC-20s (possibly with a single DN-20 with 2 DTEs and no
Ethernet), but we have need for PDP-11, IBM, and microcomputer software
eventually.
Roy
-------
24-Jan-81 22:30:20-EST,6610;000000000000
Mail from MIT-MC rcvd at 24-Jan-81 2229-EST
Date: Saturday, 24 January 1981 21:58-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Roy Marantz <MARANTZ at RUTGERS>
Reply-to: CPR at MIT-MC
Cc: local-nets at MIT-MC
Subject: Ethernets, et alia
Date: Saturday, 24 January 1981 17:27-EST
From: Roy Marantz <MARANTZ at RUTGERS>
Re: Ethernet protocols
Someone like Dave Clark or Noel Chiappa is probably better suited to
reply to parts of this message, but here are my comments for what
they're worth.
Can anyone tell me (or point me) about the "higher level" protocols
being used/developed for use with ethernet?
Do you mean old Ethernet itself? These protocols are well-publicized
by now, and are nothing more than PARC's various internal protocols;
they are only used outside of Xerox at the three grant universities
(most heavily at Stanford and CMU), and only as utility protocols (to
get to the Dover and IFS, mostly). Not much of interest there; I
don't think anyone considers these protocols worth worrying about
except as existing workhorses.
No word is officially out yet on the plans that various places have
for the protocols based on the new Xerox/DEC/Intel (XDI) hardware.
Xerox is being pretty closed-mouthed about it (somoene from MIT is
going to find out more this week), and the word from DEC is that the
hope of actually standardizing (among Xerox, DEC and Intel) on any
higher-level protocols is pretty slim, given the incredible difficulty
they had agreeing on the hardware level as recently released. What
will probably happen is that every manufacturer will have her own
protocols based on the new Ethernet hardware, but at least we'll be at
first base: the hardware will be (hopefully) standard and various
protocols can live peacefully with each other on the hardware base.
As far as MIT goes, people generally agree that the Chaosnet hardware
will be replaced by the XDI hardware when and if it matures, though
the higher-level protocols will probably remain those of Chaos.
However, Chaos packets will probably soon be encapsulated in
Internet-format packets so Internet and Chaosnet protocols can
co:exist on the same cable (this is hardware-independent, really).
I'd like to know what the
availability, advantages, disadvantages, relative cost, relative
throughput, development stage, availability of source,.... for these
different protocols (and of course their implementations). I've only
heard of PUP and CHAOSNET, if there are others I'd like to know.
Well, PUP is actually a family of protocols (EFTP, BSP, etc), based on
Xerox's idea of an internet packet format. Chaosnet is also a
software packet format, with higher-level protocols not necessarily
implied; it turns out that the Chaosnet protocols are not much more
than those required to support the Lisp Machines, since they are its
raison d'etre (though this doesn't imply any lack of generality, or
impossibility of other protocols; currently, (a form of) FTP, ARPA
Telnet, SUPDUP and other smaller protocols are supported by the
various Chaosnet hosts). The Chaos protocols and supporting software
for nearly any machine (the Chaosnet support for VAX/VMS is not in a
clear state) are of course totally available to you (they're all
publically readable, etc). As mentioned in early Local-Nets mail, the
Yale folks are importing the Chaosnet hardware and software for -20's,
and eventually for Unices (they have the -20-to-20 hardware and
software working).
Also
since we (read that I) will be implementing one in the near future (as
soon as it can be decided which one to do), we (I) are willing to
share/cooperate our results with others. At present I am planning to
connect 2 DEC-20s (possibly with a single DN-20 with 2 DTEs and no
Ethernet), but we have need for PDP-11, IBM, and microcomputer software
eventually.
If you are just looking for a quick and dirty way for your -20's and
Unices to talk to each other, while you (most wisely) wait for the XDI
hardware and associated protocols to show up and mature a bit, I would
heartily recommend just connecting up your -20's with a null Chaosnet
(an 11/34 with two DTE's, which will only run you about $15K if you
get a used 11/34 for around $10K (that's what American Used is selling
them for in Boston) and the DTEs from Field Circus for about $2.5K
each). The software installation probably wouldn't be more than a
matter of a week, and you'd end up with full Telnet, mail and file
transfer, which is what you probably need to get started.
Furthermore, it would be a nice throw-away network to tide you over,
since you be wouldn't investing any real effort in it.
In the longer run, while you're still (wisely) waiting to see what
happens to XDI Ethernet, you could start gearing up for Internet/TCP
and its associated protocols. Since some of your machines are ARPA
hosts, it makes sense to start worrying about this now anyway, and
since the world seems to be going this route, you might as well head
in that direction (note that the (IN/TCP-based) CSNet approval pretty
much ices the cake, since the DoD has already given notice that the
ARPAnet is going IN/TCP by '83). Any IN-based software you build or
import (and we have reason to expect growing amounts of this kind of
software) is going to have a lengthy life, regardless of the hardware
set(s) it runs on. And, the -20 IN/TCP software, as poor as it may be
(comes from BBN), does exist, though it needs to be beaten into
submission (something which XX is facing right now).
Just FYI, DEC has its own in-house effort to implement IN/TCP on the
-20; don't know about any higher-level protocols based on it, but I
presume they'd supply the standard mail, Telnet, FTP, etc. 3COM, Bob
Metcalfe's (Mr. Packet Networks') company, is now selling a Unix
implementation of TCP, and BBN has had one for some time.
As for your micros, they're probably doomed to be second-class
citizens on nearly any of these networks, since you can't expect the
interfaces to cost less than $2-4K each for some time to come.
Hopefully, someday, somewhere, someone will design a super-cheap
interface for the XDI net, but until then... (BTW, there is an effort
here at MIT to do something like that for a currently unspecified
local network medium so all the students' micros can talk to each
other and the larger machines around campus; it's called the
campus-net effort; Campus-Net@MIT-MC gets mail to that group.)
25-Jan-81 18:24:10-EST,735;000000000000
Mail from MIT-MC rcvd at 25-Jan-81 1824-EST
Date: 25 Jan 1981 1514-PST
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Subject: Re: Ethernet protocols
To: MARANTZ at RUTGERS, local-nets at MIT-MC
cc: CSL.LANTZ at SU-SCORE
In-Reply-To: Your message of 24-Jan-81 1427-PST
Rochester and CMU have been working on internetwork IPC protocols.
Rochester's is PUP-based, CMU's is INTERNET-based (but running on
the Ether). You should request a copy of the respective documents
from Feldman@SUMEX-AIM (Attn: Liudvikas Bukys) and Rashid@CMUB.
Rochester also had their own homegrown Ethernet protocols (as they
had Altos long before Pup was distributed), which might or might
not (most probably) be of interest.
Keith
-------
26-Jan-81 00:42:41-EST,4568;000000000000
Mail from MIT-MC rcvd at 26-Jan-81 0042-EST
Date: 26 Jan 1981 0022-EST
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: Ethernet protocols
To: MARANTZ at RUTGERS, local-nets at MIT-MC
cc: JNC at MIT-XX
In-Reply-To: Your message of 24-Jan-81 1727-EST
CPR already said most everything worth saying, but I'll elaborate a
few things he missed.
The new XEROX protocols are still XEROX proprietary, and are under
tight security. MIT has up to now had no luck prying them out of XEROX for
review. It's not certain that we will be told about them. If we get a
preview, it is possible we may not be able to spread the info. They will
probably be released in a few months, though.
Note that the existing XEROX protocols (PUP) (as released to the
universities) are incompatible and will be obsoleted. Note also that since
DEC and XEROX aren't cooperating, there won't be any one tremendously
wide-spread protocol. I'd probably order them (in decreasing strength)
X25/IN/SNA/XEROX/DEC...
You must be aware that asking questions about the advantages,
disadvantages, relative cost and relative throughput of any internetwork
protocol is not too useful for anything except the short term at this point,
as none have been in service long enough or in enough different environments
for any real (as apposed to toy, lab) results. Most aren't even on their
second implementation yet. Complete network software is typically larger and
almost as sophisticated as the kernel of a system. There is also no
operating system that really uses networks, especially the very high
bandwidth local networks not coming into service.
It interests me that you did not mention the two most wide-spread
internet protocols; the X25 family and InterNet. The former, at least, was
discussed in this mailing list at some length.
People still seem to be missing a vital point; IN and PUP are a
FAMILY of protocols based on a common transport layer. Some are datagram
based, and there is usually a reliable stream protocol, but all share common
addressing and transport layers (gateways and links). However, they provide
much more flexibilty to the users than X25, old NCP (HHP) or old CHAOS, which
offer (essentially) only streams.
Thus, to restate what CPR said, there is a proposal afoot to change
CHAOS to run on IN; i.e. to make it one of the family of IN protocols. This
is being held up more by manpower considerations than anything else; the
technical and political battles are (for a large part) over.
CHAOS offers a fairly wide spectrum of protocols, most based on the
existing old NCP based ones, and quite general. The only protocol I know of
that is LISPM oriented at all is the File Access protocol.
Since I am hearing that it will be sometime in '82 before DEC comes
up with ETHERNet, you might be interested in a local network interface for
PDP11's and other that is about to become commercially available from a small
company in Boston called Proteon. I have flamed about this before; to restate
what I said then, it was developed by LCS at MIT. It has a 10MBd network
interface on a dual DEC board with an 8-bit parallel out, start/end of packet
and next byte sort of interface to the second board, a PDP-11 full duplex DMA
board with two 2K byte packet buffers. It comes in two pieces to ease
construction of other host interfaces; ones for the NuBus and S100 bus are in
debug, and others are planned. We have gone through the protoype stage now,
and multi-wire versions exist. The manufacturer isn't being stellar, but you
ought to be able to convert cash into a working one before the start of the
summer (slightly pessimistic). They are accepting PO's now, but unless you're
masochistic wait a bit. The current multi-wire has known mis-features (none
very bad).
Note that the ETEHRNet hardware that 3COM is selling consists of
TRANSCEIVERS only. I heard rumors of host interfaces; this, as far as I know,
is not so.
It's not clear how this relates to small machines. The network
interface Proteon is selling is listed at $700 (if I remember right), but the
guy who built it claims $1500 for a commercial host interface, $300 for a
home-rolled one (you wire the board, etc). MIT will probably hand out the
prints for that gratis to non-profit use, but I can't say for sure. Both
prices may come down as volume increases.
Please people, a lot of this is redundant. Please read the archives
(available as CPR;LCLNET MAIL on MC) so that we don't have to repeat ourselves
at length.
-------
27-Jan-81 23:33:50-EST,801;000000000000
Mail from SU-SCORE rcvd at 27-Jan-81 2333-EST
Date: 27 Jan 1981 2025-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: ARPANET access from TIPs
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.62: ;
I have had a number of complaints from my users about the unreliability
of accessing SCORE from a TIP, and a couple from users at SRI-KL. It
has been rumored that the problem happens with other hosts, at least
from the SU-TIP and AMES-TIP.
Has anybody else had similar difficulties with network access or similar
complaints from users? I personally have had no difficulties, although
from the console log the network itself does seem to be randomly dropping
messages.
-- Mark --
-------
29-Jan-81 23:50:25-EST,1506;000000000000
Mail from SU-SCORE rcvd at 29-Jan-81 2349-EST
Date: 29 Jan 1981 2043-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: execute-only evasion bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.63: ;
The following program will let you get a copy of the system
EXEC, even if it is protected EXECUTE-ONLY. I am SPR'ing it to
DEC. Isn't it amazing what students will discover?
-- Mark --
TITLE BUG
SEARCH MONSYM
A=1 ; AC definitions
B=2
C=3
BYTES=10 ; size of EXEC in bytes
PAGES=11 ; size of EXEC in pages
JFN=12 ; save of output JFN
EXJFN==1 ; EXEC's JFN
FRSPAG==11 ; first page to map EXEC into
BUG: RESET%
MOVSI A,(GJ%SHT) ; open out output file
MOVE B,[POINT 7,[ASCIZ/COPY-OF-EXEC.EXE/]]
GTJFN%
0
MOVEM A,JFN
MOVE B,[440000,,OF%WR!OF%RD]
OPENF%
0
MOVEI A,EXJFN ; get size of SYSTEM:EXEC.EXE
SIZEF%
0
DMOVE BYTES,B ; stash size away
MOVSI A,EXJFN ; map EXEC into our address space
MOVE B,[.FHSLF,,FRSPAG]
HRLI C,(PM%PLD!PM%CPY!PM%CNT!PM%RD)
PMAP%
IFN 0,< ; This was once thought to be necessary, but isn't
MOVEI B,FRSPAG*1000
LOOP: MOVES (B) ; touch all pages for write
ADDI B,1000
CAIG B,FRSPAG*1000(BYTES)
JRST LOOP
>;IFN 0
MOVE A,JFN ; now dump EXEC out
MOVE B,[POINT 36,FRSPAG*1000]
MOVN C,BYTES
SOUT%
CLOSF%
0
HRROI A,[ASCIZ/Done
/]
PSOUT%
DONE: HALTF%
JRST DONE
END BUG
-------
30-Jan-81 18:20:25-EST,684;000000000000
Mail from SU-SCORE rcvd at 30-Jan-81 1820-EST
Date: 30 Jan 1981 1511-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.63: ;
According to Dale@USC-ISIB, a way around the problem of hung NVT's is to
periodically ASND (then RELD if successful) all possible NVTs. SCORE is
doing this now and it seems to be effective in sweeping the symptoms
under the rug. Of course, this does nothing to cure the disease, but the
fact that this works seems to indicate what probably needs to be changed
in NVTDET.
-------
2-Feb-81 22:12:40-EST,467;000000000000
Mail from SU-SCORE rcvd at 2-Feb-81 2212-EST
Date: 2 Feb 1981 1906-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: NVT handling bug
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.66: ;
The HRR T2,P1 at IMPTS1 should be a HRRZ T2,P1. This doesn't affect
most systems, but systems which have the STDDET paranoia bug check
will get upset.
-- Mark --
-------
3-Feb-81 23:14:13-EST,638;000000000000
Mail from SU-SCORE rcvd at 3-Feb-81 2314-EST
Mail-from: ARPANET site RAND-AI rcvd at 3-Feb-81 0944-PST
Date: 3 Feb 1981 0931-PST
From: Geoffrey C Mulligan (at The Pentagon) <GeoffM at RAND-AI>
Subject: Autospeed
To: Admin.MRC at SU-SCORE
In-Reply-To: Your message of 2-Feb-81 1906-PST
Remailed-date: 3 Feb 1981 2005-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.68: ;
I was wondering if anyone has tried to get a 20200 to do auto-speed
searching like the 40 50 and 60s seem to do. It seems as though it
should be possible to do. Would you know?
geoff
-------
5-Feb-81 03:05:20-EST,876;000000000000
Mail from MIT-MC rcvd at 5-Feb-81 0305-EST
Date: 5 Feb 1981 0257-EST
From: WAGGONER at RUTGERS
Subject: Local-Nets mailing list
To: local-nets at MIT-MC
cc: WAGGONER at RUTGERS
Hi,
This account represents the OSU DEC-20 site. We are workings on a few
projects that are dealing with just that kind of netting. We would be
very interested in joining your mailing list. Current projects here
are: a loop network (PDP11's and our 20) a database machine (Dr. Hsiao
Very Large Databases) which is VAX and PDP11/44's (also the 20 to some degree)
and a project just starting that is to run all our terminals into a 'switch'
and allow us to connect to any of a number of system. Thsi project is currently
just in the planning stages however. Thanks very much.
-- Mark --
-- DEC-20 / Database Staff --
-- Ohio State University--
-------
7-Feb-81 21:38:47-EST,930;000000000000
Mail from SU-SCORE rcvd at 7-Feb-81 2138-EST
Mail-from: ARPANET site UTEXAS-20 rcvd at 7-Feb-81 1825-PST
Date: 7 Feb 1981 2017-CST
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Renaming archived files
To: admin.mrc at SU-SCORE
Remailed-date: 7 Feb 1981 1833-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.69: ;
Mark, please forward to your hackers list:
I discovered a few days ago that it is possible to rename
files which have been archived. Does anybody see any rationale
for allowing this? If a file is renamed, retrieval will lose unless
it is first renamed back to its original name. If the user forgets
what the old name is, he loses completely.
I will probably get around to fixing (i.e. prohibiting) this, but
just wanted to find out if anybody has already done so, or if someone
thinks this should be a feature.
Clive
-------
8-Feb-81 00:14:02-EST,618;000000000000
Mail from SU-SCORE rcvd at 8-Feb-81 0013-EST
Date: 7 Feb 1981 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: bug in edit 474 of TV
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.69: ;
EDIT 474 to TV, published in the October '80, completely breaks the N
command. It causes the first N to do a P, and after that N is just
like S. The proper fix is to remove all of edit 474, and at NOFND1+5
after the JRST NOFND2 insert:
TXNE FF,FINF ;AT END OF FILE?
JRST NOFND2 ;STRING NOT FOUND, PUNT
-------
8-Feb-81 04:34:37-EST,783;000000000000
Mail from MIT-MC rcvd at 8-Feb-81 0434-EST
Date: 8 Feb 1981 0125-PST
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Subject: Re: Ethernets, et alia
To: CPR at MIT-MC, MARANTZ at RUTGERS
cc: local-nets at MIT-MC, CSL.LANTZ at SU-SCORE
In-Reply-To: Your message of 24-Jan-81 1918-PST
As per "cheap ethernet interfaces" Andy Bechtolsheim and Forest
Baskett have (with some assistance) designed a nice Multibus
compatible board for the SUN workstations. Parts cost for the
board is < $2K. It works with the experimental 3 Mbaud Ethernet,
however, but it does work! Send mail to AVB@SU-AI if you're
interested. Beyond the interface you can bet that Stanford will
have some reasonable networking software for the 68000's before
the end of the year.
Keith
-------
8-Feb-81 04:45:30-EST,748;000000000000
Mail from MIT-MC rcvd at 8-Feb-81 0445-EST
Date: 8 Feb 1981 0138-PST
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Subject: Re: Ethernet protocols
To: JNC at MIT-XX, MARANTZ at RUTGERS, local-nets at MIT-MC
cc: CSL.LANTZ at SU-SCORE
In-Reply-To: Your message of 25-Jan-81 2122-PST
Re the comment that "no operating system currently uses networks",
RIG has used the Ethernet in particular for years. It is fully
integrated and works just fine. You wouldn't want to buy the software,
just the ideas. Also, GUARDIAN/EXPAND is the operating system for
Tandem and it works just fine too -- ask all of Tandem's customers.
If a 26Mbaud "local" bus + network extensions means "using networks"
I think they've got it!
Keith
-------
9-Feb-81 09:25:31-EST,736;000000000000
Mail from SU-SCORE rcvd at 9-Feb-81 0925-EST
Date: 9 Feb 1981 0619-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: [SU-SCORE]MRC:<UTILITIES>MAILBX.MAC.15
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.69: ;
The file [SU-SCORE]MRC:<UTILITIES>MAILBX.MAC.15 is a version of
the MAILBOX program with a couple of TOPS-20 bug fixes and also
the capability to recognize long-leader network addresses. Boy
is that program ever cretinous!! Would anybody care to rewrite
it?
In case you don't know what MAILBOX is, it implements mail
forwarding of sorts for ARPANET systems. It's an old BBN Tenex
special.
-- Mark --
-------
12-Feb-81 03:55:14-EST,930;000000000000
Mail from SU-SCORE rcvd at 12-Feb-81 0355-EST
Mail-from: ARPANET site RUTGERS rcvd at 11-Feb-81 1303-PST
Date: 11 Feb 1981 1553-EST
From: WATROUS at RUTGERS
Subject: Erroneous FB%LNG
To: Admin.MRC at SU-SCORE
Remailed-date: 12 Feb 1981 0047-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.70: ;
Remember the bug in the EXEC's COPY command whereby files which had
an even multiple of 512 pages got garbage copied to the next section
(and a free FB%LNG)? Well, we have a good suspicion that DUMPER
(ugh!) has the same problem (setting FB%LNG after trying to PMAP
non-existent pages beyond the end of the real file). Has anyone else
found that bug and/or (hopefully) fixed it? If not, I should have a
fix for it out soon as we have to get it fixed before we do a disk
refresh 2/13/81 0000.
Thanks in advance if anyone's beat me to the fix,
Don
-------
14-Feb-81 14:00:26-EST,958;000000000000
Mail from MIT-MC rcvd at 14-Feb-81 1400-EST
Date: Saturday, 14 February 1981 13:48-EST
From: Chris Ryland <CPR at MIT-EECS>
To: local-nets at MIT-MC
Subject: Ethernets, et alia
Date: Sunday, 8 February 1981 04:25-EST
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Re: Ethernets, et alia
As per "cheap ethernet interfaces" Andy Bechtolsheim and Forest
Baskett have (with some assistance) designed a nice Multibus
compatible board for the SUN workstations. Parts cost for the
board is < $2K. It works with the experimental 3 Mbaud Ethernet,
however, but it does work! Send mail to AVB@SU-AI if you're
interested. Beyond the interface you can bet that Stanford will
have some reasonable networking software for the 68000's before
the end of the year.
That's great, but what protocols will it use? I presume it won't use
TCP/IN, and therefore won't be very portable in a protocol sense.
15-Feb-81 14:54:41-EST,400;000000000000
Mail from MIT-MC rcvd at 15-Feb-81 1454-EST
Date: 15 February 1981 14:50-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject: Ethernets, et alia
To: CSL.LANTZ at SU-SCORE
cc: LOCAL-NETS at MIT-MC
Parts cost is around $2K? That's pretty high. I believe the
parts cost of a chaosnet board is fair bit less than $1K. If you
mean that the finished cost is less than $2K, that's different.
16-Feb-81 00:23:24-EST,310;000000000000
Mail from MIT-MC rcvd at 16-Feb-81 0023-EST
Date: 15 Feb 1981 2219-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Ampex memory
To: twenex-wizards at MIT-MC
Has anyone put Ampex MOS memory on their KL processor?? I'd be interested
in experience (or the names of people with experience).
-------
16-Feb-81 22:15:35-EST,2814;000000000001
Mail from MIT-MC rcvd at 16-Feb-81 2215-EST
Date: 15 Feb 1981 2118-PST
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
Subject: SUN Ethernet interface
To: local-nets at MIT-MC
A more accurate figure for the parts cost of the SUN (Stanford University
Network) Ethernet interface is $800. The following three paragraphs come from
a writeup of the board, available from AVB@SAIL.
This is an Intel Multibus compatible board for a 3 Mb Ethernet supplying all
functions of the Ethernet data link and physical layer, namely:
- data encapsulation (framing, addressing, checksum)
- link management (channel allocation and contention resolution)
- channel access (bit transmission, carrier sense, collision detection)
- packet buffering (storing packets being sent or received)
- exception reporting (failure to send a message, receipt of bad messages)
- address recognition (can specify any subset of 256 addresses)
- data encoding (preamble generation, phase encoding)
In addition it offers:
- back-to-back packets (no refractory period)
- loopback (can receive packets it transmits)
- 32-Mbaud bus rate (16 bits per 0.5 usec, so needing only 10% of an 8MHz 68k)
- 4 kbyte buffer (tolerates host latency of 2 kbyte, i.e. 5 msecs)
In short, you supply/receive unencapsulated packets at your reasonable
convenience and at your speed, it does the rest.
This board is one of the (currently) seven board types used in the
implementation of the various nodes of the SUN network, all of which are Intel
Multibus boards, physically, electrically, and logically. The other board
types are:
CPU (M68k, 2-level map, 256 kbyte onboard memory, full 8 MHz, 2xUART, timer)
Offboard Memory
Graphics Controller (novel design permits blt'ing in x OR y direction!)
Graphics Memory (128 kbyte)
Communications Interface (commercial 8-uart board)
Disk Controller (commercial)
These boards assemble in various combinations to produce the following SUN
nodes:
Ethertip EI+CPU+4xCI
Gateway 2xEI+CPU
File Server EI+CPU+DC
Small Personal Computer EI+CPU
Large Personal Computer EI+CPU+OM+GC+GM
Home Computer CPU+DC (linked to network via CPU.UART2 + telco)
etc.
Only prototypes of the non-commercial boards presently exist.
The Ethernet to which the above will be initially attached carries mainly Pup
traffic between a KL-10 (Sail), 3 Vaxes running Berkeley Unix, a Dover printer,
a file server, and something like a dozen and a half Altos, plus a pending
connection to a 20/60 (Score). There are also other networks at Stanford, as
observed in an earlier message, which will hopefully all be connected with
gateways when the hardware and software are available. Once things have
settled down IP/TCP will be either imported if available or generated locally.
-------
16-Feb-81 22:27:02-EST,479;000000000000
Mail from MIT-MC rcvd at 16-Feb-81 2226-EST
Date: 14 Feb 1981 1157-PST
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Subject: Stanford Ethernet board
To: local-nets at MIT-MC
The Stanford Ethernet board implements the data link layer protocols.
It couldn't care less what internet protocols you use. Hence, it is as
portable as the Dec/Intel/Xerox chip will be and can be reconfigured
eventually to support the 10MBaud Ethernet rather than 3MBaud.
Keith
-------
16-Feb-81 22:38:04-EST,456;000000000000
Mail from MIT-MC rcvd at 16-Feb-81 2238-EST
Date: 15 Feb 1981 1441-PST
From: Keith A. Lantz <CSL.LANTZ at SU-SCORE>
Subject: Re: Ethernets, et alia
To: EAK at MIT-MC
cc: LOCAL-NETS at MIT-MC, CSL.LANTZ at SU-SCORE
In-Reply-To: Your message of 15-Feb-81 1150-PST
Look guys, if you care about the Ethernet board, talk with Andy
Bechtolsheim (AVB@SU-AI). I have obviously got your interest, but I
am not up on the figures.
Keith
-------
18-Feb-81 13:20:15-EST,547;000000000000
Mail from MIT-MC rcvd at 18-Feb-81 1320-EST
Date: 18 Feb 1981 0953-PST
From: MIKE at RAND-AI
Subject: Update on connecting to 20's
To: local-nets at MIT-MC
We at Rand have an urgent need to connect our 20 to some UNIX systems.
I'd like an update from anyone out there with some knowledge on what
currently exists to allow a high-bandwidth connection, and what is being
worked on now for that purpose (ie, 3Mbit ethernet at Stanford, Chaosnet
at Mit, etc). Anyone done a lot of work with DECNET?
Thanks
Michael Wahrman
-------
23-Feb-81 05:21:38-EST,1073;000000000000
Mail from SU-SCORE rcvd at 23-Feb-81 0521-EST
Mail-from: ARPANET site RAND-AI rcvd at 18-Feb-81 0943-PST
Date: 18 Feb 1981 0942-PST
From: MIKE at RAND-AI
Subject: 20 to 10 Mailing (phone line) mailing systems
To: admin.mrc at SU-SCORE
cc: mike at RAND-AI
Remailed-date: 23 Feb 1981 0217-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>Tops-20.DIS.70: ;
Mark,
Please pass this on to your list, if appropriate.
Problem:
We want to pass mail daily from our tops-20 to a tops-10
in the LA area. The only connection is via telephone lines. Now,
were this a UNIX system, a mere minicomputer operating system, we
would have UUCP which could automatically call any other UNIX system
daily and transfer mail. Is there such a system for the 10's and 20's?
(PS. This system should make use of an autodialer, the phone lines
will not be dedicated to this purpose).
(PPS. Another possibility is UUCP for a 10, in which case our UNIX
system could call the 10.)
Many thanks,
Michael Wahrman
-------
23-Feb-81 12:58:33-EST,354;000000000000
Mail from MIT-MC rcvd at 23-Feb-81 1258-EST
Date: 23 Feb 1981 1046-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: COMNDizing FTP
To: twenex-wizards at MIT-MC
We're considering biting the bullet and COMNDizing user FTP. Before we
dive in, we want to make sure no one else has started such a project.
If you have, plz let me know.
-------
23-Feb-81 14:03:35-EST,1381;000000000000
Mail from MIT-MC rcvd at 23-Feb-81 1403-EST
Date: 23 Feb 1981 1356-EST
From: TAPPAN at BBND (Dan Tappan)
Subject: User FTP Feature
To: Twenex-Wizards at MC
Description: When making a connection to a machine running TOPS20, FTP
Defaults to 8 bit bytes (rather than 36 bit paged)
Cause: The latest Host tables now describe 20x hosts as TOPS20 instead
of TENEX, FTP doesn't know about this system type so defaults to the
default, screwing things up
Fix: Make FTP know about TOPS20 and treat as 10x. Comparision follows:
(Note that anyone running TENEX needs this fix also)
; FTP.MAC.13 & FTP.MAC.12 23-Feb-81 1318 PAGE 1
LINE 1, PAGE 1
1) ;<BBN-4-UTILITIES>FTP.MAC.13, 26-Nov-80 15:43:18, Edit by TAPPAN
1) ; Recognize TOPS20 as a system type
1) TITLE FTP - USER HALF OF THE FILE TRANSFER PROTOCOL
LINE 1, PAGE 1
2)
2) TITLE FTP - USER HALF OF THE FILE TRANSFER PROTOCOL
LINE 30, PAGE 2
1) OPST20==11B8 ; Site runs tops20
1)
LINE 30, PAGE 2
2)
LINE 37, PAGE 16
1) CAIE A,(OPST20) ; Same for Tops20's
1) CAIN A,(OPST10) ;SAME FOR TOPS10 SYSTEMS
LINE 37, PAGE 16
2) CAIN A,(OPST10) ;SAME FOR TOPS10 SYSTEMS
LINE 42, PAGE 16
1) CAIE A,(OPST20) ; TOPS20 PAGED
1) CAIN A,(OPS10X) ;IMAGE IF 36 UNLESS 10X, THEN PAGED.
LINE 41, PAGE 16
2) CAIN A,(OPS10X) ;IMAGE IF 36 UNLESS 10X, THEN PAGED.
-------
23-Feb-81 18:13:05-EST,1548;000000000000
Mail from SU-SCORE rcvd at 23-Feb-81 1812-EST
Date: 23 Feb 1981 1502-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: [Chris Ryland <CPR at MIT-EECS>: Can you forward this to people to see if anyone has fixed these?]
To: [SU-SCORE]<Admin.MRC>Tops-20.DIS.70: ;
I am not convinced that the first complaint is a bug; isn't TTY:
translated into the appropriate TTYnn:? At least the behavior
isn't totally unexpected or unreasonable.
The second complaint is obviously specific to MIT.
---------------
Mail-from: ARPANET site MIT-AI rcvd at 23-Feb-81 1148-PST
Date: Monday, 23 February 1981 14:45-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at SU-SCORE
Subject: Can you forward this to people to see if anyone has fixed these?
Date: Monday, 23 February 1981 11:39-EST
From: RWS at MIT-XX
To: bug-twenex at MIT-XX
Re: longstanding Rel. 4 terminal jfn bugs
If you have an explicit jfn to TTY: and you attach
to a different terminal, RFMOD and SFMOD (and possibly
others) give "line is not active" errors. This was
not true under Release 3.
If you open two jfns to a terminal without assigning it,
when you close one of the jfns, IDLSRV prematurely gets
the terminal back, and it becomes impossible to close or
release the other jfn. Resetting the fork fails to get
rid of itt, as does EXEC's CLOSE command; you have to log
out.
---------------
-------
23-Feb-81 18:14:41-EST,936;000000000000
Mail from MIT-MC rcvd at 23-Feb-81 1814-EST
Date: 23 Feb 1981 1456-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: COMNDizing FTP
To: FRANK at UTAH-20, twenex-wizards at MIT-MC
In-Reply-To: Your message of 23-Feb-81 0946-PST
I have started on a complete rewrite of user FTP (ala my TELNET) which
will have the multiple network support, etc.
In other notes about TELNET, coming up soon are:
TCP/IN TELNET support (BBN style, DEC style too as soon as there
is a system running it to debug on)
SU-NET support (essentially Ethernet + Chaosnet routing)
Local host padding option (Ann Arbors, VT100's, etc.)
Option to use the DECnet TTY/DCN tie-in facility
VAX DECnet TELNET support
There is a possibility that DEC will distribute TELNET in a forthcoming
release of TOPS-20.
-- Mark --
-------
23-Feb-81 22:04:37-EST,597;000000000000
Mail from MIT-MC rcvd at 23-Feb-81 2204-EST
Date: 23 Feb 1981 2056-CST
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: Autobaud
To: twenex-wizards at MIT-MC
Has anyone written a autobaud program for a 20. I'm talking about
one that autobauds up to 9600 baud. What I am thinking of is a daemon
that grabs the line you want to autobaud on, waits for a character,
reads the character and then decides what baud rate you are on and
sets your line appropriately. Anyone heard of such a beast? If not,
I'm embarking on it soon ...
Thanks for considering,
Ed
-------
24-Feb-81 12:41:48-EST,444;000000000000
Mail from MIT-MC rcvd at 24-Feb-81 1241-EST
Date: 24 Feb 1981 0925-PST
From: LARSON at SRI-KL
Subject: Re: Autobaud
To: G.ECP at UTEXAS-20, twenex-wizards at MIT-MC
In-Reply-To: Your message of 23-Feb-81 1856-PST
Yes, I heard about it at the last DECUS. It works only with ^C as the
recognition character, and had to be done in the front end. The system
had to be quite restrictive to get the wide speed range.
Alan
-------
24-Feb-81 15:10:05-EST,1640;000000000000
Mail from MIT-MC rcvd at 24-Feb-81 1509-EST
Date: 24 Feb 1981 1451-EST
From: David Richard Lyons <LYONS at DEC-MARLBORO>
To: LARSON at SRI-KL, G.ECP at UTEXAS-20, twenex-wizards at MIT-MC
Subject: Re: Autobaud
Message-ID: <MS"5(1563)"11707305851.14.124.21038 at DEC-MARLBORO>
In-reply-to: Message from LARSON at SRI-KL of 24-Feb-81 1225-EST
The decision to only recognize on ^C had nothing to do with getting
the larger range. That crock was done to save room by not having the
Autobaud tables large and containing many different chars. The extra
space buys more thruput for those who have 128 lines and 2 lpts and a
card (what are cards) reader. The code was a direct steal from the
DN87 (ANF10) code, and that will work on <cr>, <^c>, <,>, and a few
others. It is true that ^c is a particularly bad choice for an
autobaud char, <cr> and <,> have much better bit patterns. The speed
range is not all that great, but I believe it is the most one can get
from a single byte and still cover 110, 150, 300 and 1200 baud. ANF
also get 134 for those of you who just love your 2741. If two bytes
were allowed, there would be no reason not to cover all the way up to
9600 baud, but again, that would cost about 200-300 bytes of buffer
space. The problem with 9600 baud is that open (and ringing) lines
will kill you. Any noise on the line (i.e. from the last send all)
will look like a 9600 ^C on the input side. This is only a problem
with long lines running at 9600/9600 and unterminated. When the system
types the greeting, that will cause more false input, and things get
worse from there.
--------
25-Feb-81 18:40:04-EST,524;000000000000
Mail from MIT-MC rcvd at 25-Feb-81 1839-EST
Date: 25 Feb 1981 1524-PST
Sender: CERF at USC-ISI
Subject: Re: COMNDizing FTP
From: CERF at USC-ISI
To: Admin.MRC at SU-SCORE
Cc: FRANK at UTAH-20, twenex-wizards at MIT-MC
Message-ID: <[USC-ISI]25-Feb-81 15:24:43.CERF>
In-Reply-To: Your message of 23 Feb 1981 1456-PST
Mark,
thanks for the update on TCP/IP - DEC says they will support
their version in release 5 of TOPS-20; BBN will help verify
correct operation of the TCP and IP peer protocols.
Vint Cerf
25-Feb-81 18:48:35-EST,361;000000000000
Mail from MIT-MC rcvd at 25-Feb-81 1848-EST
Date: 25 Feb 1981 1542-PST
From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Re: COMNDizing FTP
To: CERF at USC-ISI, Admin.MRC at SU-SCORE
cc: FRANK at UTAH-20, twenex-wizards at MIT-MC
In-Reply-To: Your message of 25-Feb-81 1524-PST
Did DEC say when the expect Release 5 to come out?
harris
-------
25-Feb-81 19:37:25-EST,933;000000000000
Mail from MIT-MC rcvd at 25-Feb-81 1937-EST
Date: 25 Feb 1981 1624-PST
Sender: CERF at USC-ISI
Subject: Re: COMNDizing FTP
From: CERF at USC-ISI
To: Meyers at SRI-KL
Cc: CERF, Admin.MRC at SU-SCORE, FRANK at UTAH-20,
Cc: twenex-wizards at MIT-MC
Message-ID: <[USC-ISI]25-Feb-81 16:24:07.CERF>
In-Reply-To: Your message of 25 Feb 1981 1542-PST
Roughly in early 1982.
Vint
Date: 25 Feb 1981 1606-PST
From: CERF at USC-ISI
To: Popek at UCLA-SECURITY
Cc: Cerf
Subject: Re: LOCUS performance update
In-Reply-To: Your message of 24 Feb 1981 1945-PST (Tuesday)
Message-ID: <[USC-ISI]25-Feb-81 16:06:07.CERF>
Sender: CERF at USC-ISI
Jerry,
what kind of data rate do your results correspond to?
Vint
--------------------
P.S. Early release to alpha test sites could probably happen sooner.
Have you seen the DEC proposal - ISI had many comments on its merits and
deficiencies.
vint
25-Feb-81 20:00:39-EST,2078;000000000000
Mail from SU-SCORE rcvd at 25-Feb-81 2000-EST
Mail-from: ARPANET site UTAH-20 rcvd at 24-Feb-81 1401-PST
Date: 24 Feb 1981 1419-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Scheduler patch to fix NBSWP problem
To: admin.mrc at SU-SCORE
Remailed-date: 25 Feb 1981 1647-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.71: ;
The following patch is from Dan Murphy at DEC:
Under very heavy load, NBSWP (scheduler variable counting number of
processes in balset wait) is not properly decremented. In therefore
become permanently non-zero, causing all future idle time to be billed
to balset wait time. This appears to the naive user as very large WAIT
times and very low IDLE times in monitor statistics.
In SCHED.MAC:
; SCHED.MAC.3 & SCHED.MAC.2 18-Feb-81 2134 PAGE 1
LINE 1, PAGE 1
1) ;PS:<4.MONITOR-SOURCES>SCHED.MAC.3 18-Feb-81 21:32:59, Edit by FRANK
1) ;FIX NBSWP NOT BEING DECREMENTED PROPERLY (TCO 5.1198)
1) ;PS:<4-MONITOR-SOURCES>SCHED.MAC.2, 16-Feb-80 18:17:08, Edit by FRANK
LINE 1, PAGE 1
2) ;PS:<4-MONITOR-SOURCES>SCHED.MAC.2, 16-Feb-80 18:17:08, Edit by FRANK
LINE 10, PAGE 38
1) JRST SKDJS2 ;AND WAIT SOME MORE
1) CAIE 1,SWPINT ;WAS BEING LOADED?
LINE 10, PAGE 38
2) JRST [ SOS NBSWP ;YES. ONE LESS IN SWAP WAIT
2) JRST SKDJS2] ;AND WAIT SOME MORE
2) CAIE 1,SWPINT ;WAS BEING LOADED?
LINE 9, PAGE 39
1) CAIN T2,PRELWT ;PRELOAD WAIT??
1) JRST DISAC2 ;YES, HANDLE LIKE SWAP WAITS
1) CAIE 2,SWPINT ;SWAPIN?
1) CAIN 2,SWPRT ;OR SWAP?
1) DISAC2: JRST [ ADDM T1,DRMWT ;YES, CHARGE TO DRUM
1) SOS NBSWP ;REDUCE COUNT OF SWAP WAITS
LINE 9, PAGE 39
2) CAIE 2,SWPINT ;SWAPIN?
2) CAIN 2,SWPRT ;OR SWAP?
2) JRST [ ADDM T1,DRMWT ;YES, CHARGE TO DRUM
2) SOS NBSWP ;REDUCE COUNT OF SWAP WAITS
(P.S. AS I SAID ABOVE, THIS PATCH IS DUE TO DAN MURPHY'S WIZARDRY.
I DON'T TOTALLY UNDERSTAND WHY IT WORKS AND THE PREVIOUS METHOD
SCREWS UP, BUT IT LOOKS LIKE IT FIXES SOME SORT OF RACE CONDITION
IN THE SCHEDULER)
-------
25-Feb-81 22:38:41-EST,5286;000000000000
Mail from MIT-MC rcvd at 25-Feb-81 2238-EST
Date: 25 Feb 1981 2011-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Building an Erector Set DN20
To: twenex-wizards at MIT-MC, b-smith at USC-ISIB
Building an Erector Set DN20
We have just finished putting together our second "erector set" DN20.
Several people have asked for the "recipe", so here it goes:
A DN20, for those who don't know, is a secondary front-end PDP 11/34
for a DEC 20. (One can have up to three DN20 secondary front-ends
on a KL, in addition to the 11/40 primary front-end). At Utah, we
have one DN20 running X.25 connecting us to Telenet, and another
driving a Versatec plotter and a Mergenthaler photocomposer (it also
acts as the "rasterizer" for the Versatec, thus off-loading that
CPU-intensive activity from the KL).
The current price for a DN20 from DEC (including a "pretty" orange
cabinet) is about $35K. One can cut the price at least in half by
putting one together from the component pieces (assuming one is willing
to give up the pretty orange cabinet! -- we install ours in standard
"short" PDP-11 cabinets, which look fine).
The following list gives the component pieces of a DN20, our normal
sources, and price estimates. There are a few pieces that are difficult
to get from DEC; our field service organization has been helpful in
acquiring them (for a price).
Component suggested sources price estimate
PDP 11/34A CPU (no memory) (used) Newman Computer, other $8K-$10K (1)
user vendors
128KW PDP-11 memory favorite memory vendor $2.5K
Data Ten Eleven Boards (DTE) DEC Customer spares $2.5K
M873-YJ bootstrap DEC Customer spares $1K (2)
M9306 terminator DEC Customer spares $150 (2)
M9310 terminator-remote power DEC Customer spares $250 (2)
BC-11A 25foot Unibus cable DEC $200
PDP 11 short cabinet $1.5K
Remote power/doorbell cable build yourself (3)
total apx.$16K-$18K
Notes:
(1) you may be able to save some money by getting the 11/34 without the
standard M9301 or M9312 bootstrap, both of which are useless for a
DN20. You should pay the extra money for an 11/34 with the programmer
panel (lights and push-button switches). Among other things, it lowers
maintenance costs!
(2) Bootstraping/termination is very funny on a DN20. Normal CPU end
termination is usually done by a M9301 or M9312 bootstrap (a dual-high
A/B card). On a DN20, you need a M873-JY bootstrap, a quad high SPC
card. This mean you need to get a CPU-end "terminator minus bootstrap",
which is what the M9306 is. At the end of the Unibus, you normally
terminate with a M9302 terminator; on a DN20, this termination
occurs inside the DTE Unibus block in the KL. Unfortunately, there
is no +5 volts, so you must use a special version of the M9302 called
the M9310 (Unibus terminator-Remote power). This terminator has
faston tabs for supplying +5 Volts, which must be cabled over from the
PDP 11/34 power supply!
We have had great difficulty in getting some of these funny terminators
and bootstraps (in particular the M9306). We finally got our local
field service organization to help. Without the help of your field
service organization, doing an erector set DN20 may be difficult.
If you have trouble getting the M9306, we believe that one can convert
a standard M930 (old style) terminator (the little short ones) by
cutting a few traces. If you have to do this I can give you more
info (we almost had to do this, but our M9306 finally arrived!)
As an aside, once together, the local field service organization
considers this unit as a garden variety DN20 for maintenance contract
purposes (it is, except for the lack of an orange cabinet!)
(3) There is one cable we have been unable to buy from DEC, and we've
had no problem building ourself. It is the (combined) cable from the
11/34 to the KL which provide remote power to the terminator (above)
and also acts as the "doorbell" cable from the KL to the M873-YJ
bootstrap (telling the bootstrap to boot); this is the way that the
KL starts a front-end. If you decide to go this erector set
approach, I can send you a drawing of this cable.
Summary:
Building an erector set DN20 can save substantial bucks, but you must
be prepared to play scavenger. Don't assume that you can get some
of the component pieces overnight -- allow yourself months to get
some of them. However, even with the difficulty of getting some of
these parts, delivery is often better than an assembled DN20 from DEC.
You might also want to determine if your DEC field service will consider
your "kit" acceptable for field service -- that might affect your
decision as to which way to go.
-------
26-Feb-81 03:34:22-EST,3070;000000000000
Mail from SU-SCORE rcvd at 26-Feb-81 0333-EST
Mail-from: ARPANET site RUTGERS rcvd at 12-Feb-81 1749-PST
Date: 12 Feb 1981 2038-EST
From: WATROUS at RUTGERS
Subject: DUMPER bug which creates long files
To: Admin.MRC at SU-SCORE
Remailed-date: 26 Feb 1981 0027-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.72: ;
Problem:
Files which are not long files but contain page 511 become
long files when restored to disk with DUMPER.
Diagnosis:
DUMPER relies on a SKIP on a non-existent page mapped from
the file failing in order to determine that the page does not exist
in that file. This works when the process page is in fact mapped to
a non-existent page in the file. When the PMAP passes page 511 for a
file without FB%LNG set, the PMAP fails with LNGFX1 and pages beyond
511 do not get mapped. The SKIP in this case creates a private page
which DUMPER thinks is page 512 and saves it. These pages get
restored when the file is restored to disk, thus creating long files.
Solution:
Trap this failure in PMAP and temporarily shrink the buffer
so DUMPER won't look at the non-mapped buffer pages.
File 1) N:DUMPER.MAC created: 1758 12-Feb-1981
File 2) O:DUMPER.MAC created: 2023 27-Jan-1981
1)13 bufsiz==10 ; number of pages in window
1) NBUF: bufsiz ;SIZE OF FILE WINDOW AT BUF0
1) INIPDL: IOWD NPDL,PDL ;INITIAL PUSH DOWN LIST
****
2)13 NBUF: 10 ;SIZE OF FILE WINDOW AT BUF0
2) INIPDL: IOWD NPDL,PDL ;INITIAL PUSH DOWN LIST
**************
1)46 movx c,pm%rd!pm%pld!pm%cnt+bufsiz ; bits and buffer size
1) hrrzm c,nbuf ; reset window size here, too
1) PMAP
1) erjmp dmpl4a ; handle PMAP failures
1) ;MAKE SURE THE PAGE WE ARE ABOUT TO DUMP EXISTS
****
2)46 MOVX C,PM%RD!PM%PLD!PM%CNT
2) HRR C,NBUF ;NUMBER OF PAGES TO MAP
2) PMAP
2) ERJMP DMPL4 ;IN CASE NON-EX PT
2) ;MAKE SURE THE PAGE WE ARE ABOUT TO DUMP EXISTS
**************
1)46 ; here when PMAP fails
1) dmpl4a: movei a,.fhslf ; get our last error
1) geter
1) hrrz a,b ; just error in a
1) caie a,lngfx1 ; Page table does not exist?
1) jrst dmpl4b ; no
1) hrrz a,lastid ; yes, get next section boundary
1) trz a,777
1) addi a,1000
1) hrrz c,lastid ; subtract starting page
1) sub a,c
1) movem a,nbuf ; save mapped buffer size
1) caie a,1000 ; if whole section
1) jrst dmpl2 ; not, go continue dumping
1) jrst dmpl4 ; yes, go do FFUFP
1) ;dmpl4 won't handle PMAP failure right under all circumstances anyway
1) dmpl4b: btmsgc <?PMAP failed dumping file >
1) hrroi b,nambuf
1) call btmsgq ; filespec
1) btmsg <
1) >
1) jrst dmplux ; punt
1) ;HERE WHEN CURRENT PAGE CANNOT BE ACCESSED (SKIP ERJMP'ED)
****
2)46 ;HERE WHEN CURRENT PAGE CANNOT BE ACCESSED (SKIP ERJMP'ED)
**************
1)50 move c,[pm%cnt+bufsiz] ; set number of pages
1) hrrzm c,nbuf ; and reinitialize it here
1) PMAP ;REMOVE THEM
****
2)50 MOVX C,PM%CNT ;SET NUMBER OF PAGES
2) HRR C,NBUF
2) PMAP ;REMOVE THEM
**************
-------
26-Feb-81 19:29:26-EST,6662;000000000000
Mail from MIT-MC rcvd at 26-Feb-81 1928-EST
Date: 26 Feb 1981 1602-PST
From: Frank da Cruz <G.DACRUZ at SU-SCORE>
Subject: DECnet vs ARPAnet vs CSnet vs local nets (a long flame)
To: Local-Nets at MIT-MC
cc: G.DACRUZ at SU-SCORE
I've been following the local nets mail with some dismay; the
overwhelming impression is that there are dozens of sites out
there, all investing prodigious amounts of hacker power - & thus
presumably money - in home-grown, mutually incompatible local nets.
Some of them work, some "almost" work. All of them seem to depend
on a small cadre of hackers. If your local net hacker disappears,
you're likely to be stuck with a horribly complicated mess that
"almost" works, thatis most likely totally undocumented, and probably
impossible to modify or debug.
The CS sites that were lucky enough to be the beneficiaries of
Xerox's largesse - Ethernet, Altos, Dovers - seem to have fared
best (despite having a heck of a time getting their own computers
to cooperate), and this is most likely because a large (greedy?)
corporation had a vital interest in testing these things out.
One "local"network that has worked very nicely for some time
is ARPAnet. Local (intra-site) communication has been a happy
by-product of the general design of the network. I don't
know a lot about these things, but I'll bet some high proportion
of an IMP's work - especially at some universities - is sending
packets around between local hosts. In any case, ARPAnet is fine
for those who can get on it, but it may have stalled the progress
in the area of local networking because the sites that may have been
most likely to do research in that area always had the ARPAnet to
provide for their local communication needs.
At Columbia, where we have mostly DEC & IBM computers,
we have hankered after local networks for years, but have been
reluctant to grow our own because of the Ephemeral Hacker syndrome
(though if we had ever received funding for such a venture, I'm
sure we would have plunged into it happily). When we bought our
first -20 in 1977, we also got DECnet in hopes that it might allow
us to tie some of the PDP-11's on campus to the central facility.
It was 2 1/2 years before the first packet was successfully transfered.
We have been laughing up our sleeves at DECnet for so long that it's
hard to break the habit. Our record was so abysmal that we were never
able to get a single campus lab or department to join us, even though
there are hundreds of -11's out there, and a growing number of VAXes.
But we didn't give up; when we got our second -20, we DECnetted it to the
first one, and imagine our surprise when - after some initial screwups -
it worked like a dream. It does file transfer, mail, virtual
terminal service, finger, most of what you want (many of these are hacks
but what network isn't full of hacks?). The only major drawback is
that only adjacent nodes can communicate, but this restriction will
be lifted in the next release (due for field test in a month or two).
At Columbia, and at some other sites, DECnet is serving very nicely
as a local network.
I recently read the plans for CSnet. I understand that CSnet has
grown out of frustration in the CS community at the exclusiveness
of ARPAnet. The CSnet folks want to reimplement ARPAnet nearly
from the ground up, piggybacking on a public commercial packet
network like TELENET, and opening it up to all PhD-granting CS
departments. This is a fine idea. But the initial plan calls for
support only for DEC computers: DEC-20's, VAXes, and big -11's -
the very machines that DECnet runs on! (Note - no -10's.)
Of course, they're not interested in DEC's operating systems for
the -11's & VAXes, sticking strictly to UNIX. I suppose that makes
good sense for -11's (name a good DEC operating system that runs on
-11's). But can't you run UNIX "under" VMS (Eunice?). It might be
worth considering when you get DECnet as a bonus.
The real catch here is the cost. Not only is DECnet expensive to
use locally (DN20's are running over $35,000; a TOPS-20 DECnet
license is $5800). But what's the alternative? A hacked-up,
homegrown, incompatible, almost-working arrangement that probably
costs more in the long than the ransom you pay for DECnet, and
that may not work as well. And what if you want to connect your
local net to someone else's? Build a gateway? If both nets happen
to be DECnet, you probably just need a wire. The phone company can
provide you with a 9600 baud leased line in about 30 days, and
the monthly cost is not bad for moderate distances (like across a
state or two) - several hundred dollars. For longer distances -
well, within a year or so, DECnet will support X.25 communication
and will be able to use TELENET as a backbone: 9600 baud access
to the entire network for $1100/month, 56Kb for $2100/month.
Seems like this does everything CSnet would have done, at about
the same cost (maybe less - depends on who's paying), and
provides for local communications at the same time. And it's all
supported. And most of it's available right now or in the very
near future; no need to wait 3-5 years for CSnet. By the way,
CSnet would probably be much nicer than DECnet, since it's built
on internet protocols, possibly allowing interconnection with
all sorts of other nets, but I wonder if it will survive the budget
axe?... Anyway, as we all know from the trade papers, DEC & Xerox
are cooperating on Ethernet. DEC fully intends to make Ethernet
a part of DECnet, so that local high bandwidth communication,
complete with typesetters, personal computers, etc, will be
taken care of too.
What about non-DEC hosts? Well, every day you hear of another
vendor who has succumbed to Ethernet mania - HP, Zilog, Nixdorf
(who?)- not to mention Xerox itself (did you hear about the
Executive Workstation?) - let's hope that all sorts of gadgets
will fit on the local DEC/Ethernet. And for IBM, well, there's
always RJE (and what's this I hear about Stanford CIT having
a DECnet/IBM channel interface running in a little -11?).
Sure DECnet is ugly & yucchhy & expensive. But it works, and
it's all supported. Wouldn't you rather holler at DEC when things
are broken than have your users yelling at you (just when your
hacker - bored with the mundane details of "finishing touches",
documentation, etc - has left you with an almost working local
net to work on something more fulfilling)?
Sorry for the extended flame. This all came to me in a dream.
Am I crazy? - Frank da Cruz, Columbia U.
-------
26-Feb-81 21:36:43-EST,2518;000000000000
Mail from MIT-MC rcvd at 26-Feb-81 2136-EST
Date: 26 Feb 1981 2120-EST
From: J. Noel Chiappa <JNC at MIT-XX>
Subject: Re: DECnet vs ARPAnet vs CSnet vs local nets (a long flame)
To: G.DACRUZ at SU-SCORE, Local-Nets at MIT-MC
cc: JNC at MIT-XX
In-Reply-To: Your message of 26-Feb-81 1923-EST
Flame on:
Yes, probably.
DECNet is not supported by anybody that I know of except DEC.
If you have an 11, and don't want to run a crappy DEC OS, you get to
implement DECNet all over. Of course, no other manufacturer supports
it. DECNet also has significant problems in terms of long haul usage
since all traffic must flow through intervening computers, unless you
regenerate the ARPANet with special forwarding nodes. I won't go into
the rest of the technical details.
The Xerox grant stuff wasn't as wonderful as it seems. At
Stanford and Rochester, they simply adopted PUPs as their local
protocol. At MIT, where there is significant competition from other
protocols (NCP, CHAOS, IN, etc....) PUPs have been more or less
confined to the EtherNet and the original Xerox software. We got the
the Altos to talk to the rest of the world by implemeting IN on
Altos.
CSNet is a Mom, God & Apple Pie number. It will do good
things for everyone easily. Can I interest you in the Brooklyn
Bridge? Also, "gateways" are the Finagle's Constants of networking.
A magic box that magicaly appears that will connect ANYTHING to
ANYTHING. Right. And if you think the fact that your Xerox printer
(running OIS) and you DEC20 (running DECNet) both plug into the
same wire means anything, I've got some great land in Florida for
you.
This is all true for a whole slew of reasons that I don't want
to get into. If you want to find out why, spend a few years building
network conglomerations. If that seems like a cheap elitist weasel out,
sorry, but it's true. Most of what I learned about networks I learned
by doing it wrong at least once, which unfortunately seems like the only
way.
Flame off:
As always, the main problem is that no one protocol will let
you talk to EVERYBODY, and providing the right magic so that the
users don't have to get into the grubby details of "well, foo implements
a, and bar implements b, but zap implements both a and b and you can
go through him" is almost impossible except on a case by case basis,
which rapidly gets into a n^2 problem.
Standardising on a single protocol is a good idea, but I don't
think DECNet is the one.
Noel
-------
26-Feb-81 21:48:43-EST,3045;000000000000
Mail from MIT-MC rcvd at 26-Feb-81 2148-EST
Date: Thursday, 26 February 1981 21:22-EST
From: Chris Ryland <CPR at MIT-EECS>
To: twenex-wizards at MIT-MC
Reply-to: CPR at MIT-MC
Cc: b-smith at USC-ISIB
Subject: Building an Erector Set DN20
Some comments on Randy's notes, from our experience.
We have had great difficulty in getting some of these funny terminators
and bootstraps (in particular the M9306). We finally got our local
field service organization to help. Without the help of your field
service organization, doing an erector set DN20 may be difficult.
If you have trouble getting the M9306, we believe that one can convert
a standard M930 (old style) terminator (the little short ones) by
cutting a few traces. If you have to do this I can give you more
info (we almost had to do this, but our M9306 finally arrived!)
Well, if your local field circus is helpful, you should have NO
trouble getting any of these parts, including the more obscure ones,
since they (obviously) have full access to a complete spares set for
real DN20s. We got our parts in two days (except for the -11) by
simply having our FE deliver them as "replacement parts". (Of course,
they've learned their lesson now, and want a P.O. before they'll give
us the parts...)
(3) There is one cable we have been unable to buy from DEC, and we've
had no problem building ourself. It is the (combined) cable from the
11/34 to the KL which provide remote power to the terminator (above)
and also acts as the "doorbell" cable from the KL to the M873-YJ
bootstrap (telling the bootstrap to boot); this is the way that the
KL starts a front-end. If you decide to go this erector set
approach, I can send you a drawing of this cable.
Gee, we had no trouble getting this---it's part of the standard DN20
piece kit. I forget the number, and could get it, if anyone cares.
One thing: don't let them sell you a "ruggedized Unibus": it's just a
heavy-duty Unibus cable, but it costs $1K. Totally useless unless you
like running hydrochloric acid under your raised floors. You should,
of course, plan to put the DN20 box reasonably near the I/O bay, where
the DTEs are. If you have two front-end expansion boxes (the usual),
then it could go next to those. We're going to try to move our DH in
the third expansion box to the second, and put the 11/34 in the place
of the third box.
Also, if you're wondering what kind of 11 to get, make sure it's a
/34A, not a plain /34 (lots of the latter around). It doesn't really
matter, but the closer you stick to vanilla DN20's, the better off you
are for maintenance reasons and peace of mind. And, depending on your
backplane requirements, you might get away with just the CPU
backplane, so you don't need to buy another system unit (this is true
only if you have a single quad-high or hex-high board you want to put
in the -11, I guess).
26-Feb-81 23:36:29-EST,1534;000000000000
Mail from MIT-MC rcvd at 26-Feb-81 2336-EST
Date: 26 Feb 1981 2124-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Building an Erector Set DN20
To: CPR at MIT-MC, twenex-wizards at MIT-MC
cc: b-smith at USC-ISIB
In-Reply-To: Your message of 26-Feb-81 1938-MST
Reply to Chris's comments:
Even with the help on your field service organization (and our was VERY
helpful), some of the parts are difficult to get. Field Service had the
M9306 on order for over a month, and then finally had to priority-1
order it. Even then, it still took over 3 additional weeks to get.
Moral: Plan ahead. Some of the parts (such as the M9306) aren't
even on the recommended spares lists for the DN20 (after all, what can
you do to a terminator...), so they might not have them in the local
office even if they wanted to loan them to you in the meantime.
Regarding 11/34 vs. 11/34A: One of our DN20 has an 11/34, the other
an 11/34A. We've been unable to observe any difference between them.
Both function perfectly normally. If you can save substantial money
getting a 34 over a 34A, I'd get it, assuming your local field service
doesn't care (and assuming you don't need 34A only options such as the
DEC cache or floating point). If you need a cache, I'd recommend the
ABLE cache over the DEC one anyway, and it'll work on a 34. The 34A also
has a heftier power supply, so you might want to take that into consideration
if you're planning on loading your DN20 with a lot of bus devices.
Randy
-------
27-Feb-81 05:02:02-EST,4038;000000000000
Mail from MIT-MC rcvd at 27-Feb-81 0501-EST
Date: 27 Feb 1981 0138-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: DECnet vs ARPANET vs CSnet vs... (flaming message)
To: Local-Nets at MIT-MC
{Begin Flame}
I don't think that the relative technical merits of a
solution are important, at least "important" in the sense of "how
likely it is to succeed." The following true story illustrates
my point:
About a year ago, I sent several messages around to the
Stanford local network discussion list about the inadequacy of
Pup protocol and urged that thought be given to another protocol.
My arguments were mostly based upon the limited address space of
Pup, but I presented software issues as well. I urged that
thought be given either to a new protocol (ala MIT's Chaosnet
protocol) or TCP/Internet. My argument for the latter was that
while TCP/Internet is both more complicated than is necessary and
deficient in some ways it is at least close to a "standard" and
that a TCP/Internet development effort would be looked on
favorably by ARPA.
I also wrote a paper about the addressing problem and
expressed my belief that the proper solution was not to use a
numeric address but a heirarchical string structure. ARPANET ran
out of address space not because there were 255 hosts, but
because it ran out of bits in the individual fields. Internet
will suffer the same fate very soon, even though there will be
far from 4,294,967,303 connected hosts.
I was told by the Computer-Science "experts" here that I
didn't know what I was talking about. You see, various people
with PhD's who worked at Xerox thought that Pup's were the
greatest thing in the world. I won't embarass the people
involved by telling the outside world how they proposed solving
the addressing problem.
So what has happened? All of a sudden, everybody thinks
that TCP/Internet is the greatest thing in the world and want it
implemented...yesterday. Yeah, but what about all this Pup code
I'm debugging that I didn't want to waste my time on in the first
place? And why the turnaround? ARPA is starting to put pressure
for TCP/Internet...
The point is, it doesn't matter what the technical merits of
a solution are. It's all local politics. If local politics
favor a completely idiotic technical solution, that is what will
get implemented, irregardless of how much it costs or what the
technical people feel or whether it is even technically feasible.
It's worse if you are at a university site, because all the
practical experience in the world is considered worthless if your
opinion disagrees with somebody with a PhD who has used a
distributed network elsewhere.
No site seems to be free of the problem. Certainly the "big
three" -- MIT, CMU, and Stanford -- aren't.
{End flame}
I feel that in the long run TCP/Internet with an X.25 line
protocol is probably everybody's best bet. It's redundant (X.25
provides services duplicated by TCP/Internet), but it will make
the most people happy. We also know that they work, although the
present implementations of TCP/Internet are wretched. I should
add that I don't believe that the user program or the local
system itself should have any knowledge whatsoever that it is
talking TCP/Internet, X.25, or DECnet, or voodoo. DEC is coming
to realize that, and so are other people in the network design
business. Who knows? Perhaps in 50 years we'll be freed from
the monstrosities we're stuck with today.
-- Mark --
PS: Does anybody want to get together and form a company to
design hardware/software for a true universal network (in other
words, with the primary goal of allowing everybody to talk to
everybody)? We'll make a mint selling to all these universities
and research sites which are too busy in internal quarrels to do
any real work.
-------
27-Feb-81 10:25:47-EST,1153;000000000000
Mail from MIT-MC rcvd at 27-Feb-81 1025-EST
Date: 27 Feb 1981 1011-EST
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Re: DECnet vs ARPANET vs CSnet vs... (flaming message)
To: Admin.MRC at SU-SCORE, Local-Nets at MIT-MC
In-Reply-To: Your message of 27-Feb-81 0438-EST
Flame on:
Well Mark (and all others), why don't ***WE*** do something about it?
Many (most?) of us are implementing local nets, and from my impressions
of talking to people TCP/IN seems to be the way to go, why don't we make
a serious effort to do this right. I don't care if we form a company
or not. We will be the ones stuck with maintaining the software
(and maybe the hardware). Does anyone else think it is possible for us
to cooperate and develop good software. I think it is possible, especially
if each of us doesn't have to duplicate the others work. Comments.
:Flame off
By the way I am serious about distributing the work around, if anyone else
can do this (I think I can), please let me know. One thing I don't want
is to have to put up some bad kludgy software because I don't have time
to do the whole thing myself.
Roy
-------
27-Feb-81 17:40:15-EST,1895;000000000000
Mail from MIT-MC rcvd at 27-Feb-81 1739-EST
Date: Friday, 27 February 1981 17:28-EST
From: Chris Ryland <CPR at MIT-EECS>
To: twenex-wizards at mc, b-smith at isib
Reply-to: CPR at MIT-MC
Subject: addendum, clarification on DN20 homebrewing
Re the /34 vs /34A question: yes, my recommendation of the 34A was
just that your local field service MIGHT care and thus you'd be better
of with a vanilla DN20 (as far as they're concerned). As Randy says,
the /34 works, in any case (and that's what we have).
Also, Randy forgot to mention that you'll need another DL-11 in your
primary front-end (don't know what they cost), to talk to your /34's
console line; DEC claims this is necessary for them to consider it a
real DN20 since some of their diagnostics use it for booting. BTW,
once you plug in a DL and configure it at the appropriate address and
interrupt vector, it will magically work as DLn: (1, 2, or 3) on the
back-end. You can dig the configuration info off your field service
fiche (DN20 installation manual; actually, I'm not sure if the entire
manuals are there in fiche; you might have to buy the two-volume set
from DEC, or, if you're going to have them maintained by DEC, they'll
supply them, I presume).
Here's the complete list of components you'll need from DEC once you
have the 11, memory, and the extra DL.
M9306 special passive terminator $ 200.00 (yes: 25 resistors)
M8552 10/11 data patch \ 1010.00
M8553 10/11 bus & data control > DTE 910.00
M8554 10/11 b & d control ext. / 330.00
70-13912 Unibus boostrap cable 215.85 *
M9310 active Unibus terminator 140.14
DM873-YJ DN20 bootstrap module 292.50
(* This is the wierdo cable which Randy fabricated in-house; your
local DEC folks may not be able to find it in their catalogs; it took
a lot of trouble to find it, but they eventually did.)
2-Mar-81 17:39:32-EST,1026;000000000000
Mail from SU-SCORE rcvd at 2-Mar-81 1739-EST
Date: 2 Mar 1981 1434-PST
From: Frank da Cruz <G.DACRUZ at SU-SCORE>
Subject: Using Printronix via DN65
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.72: ;
Does anybody out there run DN65 IBM RJE software in a DN20? We do, and
we have a few extra ports on it. There's apparently a 3780-talking
interface for the Printronix printer available from QMS. Why tie up
another TTY line with a printer when there's a whole PDP-11/34 sitting
there with next to nothing to do? The question is - can the Printronix
be driven in this way without translating all the ASCII characters to
EBCDIC in the wrong way (square brackets becoming cent-signs, etc), e.g.
by running in transparency mode, and if so, can this be done alongside
the normal RJE communications, which in our case is HASP multileaving?
I tried to get one of these boards to try it out, but they make you buy it
without trying it. Has anybody ever tried this kind of thing?
- Frank da Cruz (Columbia U.)
-------
6-Mar-81 15:08:35-EST,2253;000000000000
Mail from SU-SCORE rcvd at 6-Mar-81 1508-EST
Date: 5 Mar 1981 1848-EST
From: Dan Tappan <TAPPAN at BBNG>
Subject: Fix to TIPs losing network connection
To: Admin.MRC at SU-SCORE
Remailed-date: 6 Mar 1981 1157-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.73: ;
[The original message has been edited and abridged prior to
redistribution to the list. -- MRC]
Our sources have an edit by John Borchek about a year ago "FIX
TIPS LOSING NETWORK CONNECTION". I don't know what the bug was,
from the fix it looks like something to do with non-existant, of
half open connections. I haven't gotten any reports about that
particular problem with TIPS's though. I'm including a SRCCOM of
the relevant parts below.
; NETWRK.MAC.4003 & <4-MONITOR>NETWRK.MAC.1 5-Mar-81 1540 PAGE 1
LINE 1, PAGE 1
1) ;<BBN-4-MONITOR>NETWRK.MAC.6, 24-Jan-80 16:57:36, EDIT BY JBORCHEK
1) ;<BBN-4-MONITOR>NETWRK.MAC.6, 19-Nov-79 21:16:36, EDIT BY JBORCHEK
1) ;FIX TIPS LOSING NETWORK CONNECTIONS
1) ;<4.MONITOR>NETWRK.MAC.51, 29-May-79 17:27:39, Edit by LCAMPBELL
LINE 1, PAGE 1
2) ;<4.MONITOR>NETWRK.MAC.51, 29-May-79 17:27:39, Edit by LCAMPBELL
LINE 46, PAGE 2
1) ;FLAGS IN NETSTS
1)
LINE 46, PAGE 2
2) ;FLAGS IN LH OF NETSTS
2)
LINE 56, PAGE 2
1)
1) FLG(LINKF,R,IOS,400000) ;LINK TABLE INDEX VALID
1) ^L
1) ; BBN socket numbers description
1) ; A socket number is a 32-bit number which in conjunction with
LINE 56, PAGE 2
2) ^L
2) ; Bbn socket numbers description
2) ; A socket number is a 32-bit number which in conjunction with
LINE 89, PAGE 35
1) NETCLL: LOAD T1,LTIDX,(UNIT) ; Get link table index
1) TQZE <LINKF> ; Link setup?
1) CALL IMPCLL
1) MOVEM IOS,NETSTS(UNIT) ; Store status
1) RET
1)
LINE 89, PAGE 36
2) NETCLL: LOAD T1,LTIDX,(UNIT) ;GET LINK TABLE INDEX
2) CALLRET IMPCLL
2)
LINE 13, PAGE 36
(NETOPS+2)
1) MOVX IOS,LINKF ; Mark valid link table index
1) IORB IOS,NETSTS(UNIT)
1) RET
LINE 13, PAGE 37
2) RET
LINE 28, PAGE 37
1) MOVE IOS,NETSTS(UNIT) ; Get current status
1) CALL @ACTAB(T2) ; Call action routine
LINE 28, PAGE 38
2) CALL @ACTAB(T2) ; Call action routine
-------
10-Mar-81 19:29:17-EST,2703;000000000000
Mail from MIT-MC rcvd at 10-Mar-81 1928-EST
Mail-from: ARPAnet host PARC-MAXC rcvd at 10-Mar-81 1504-PST
Date: 10 Mar 1981 15:03 PST
From: GWilliams at PARC-MAXC
Subject: 3Com takes on DEC
To: "@Gang.dl"
Remailed-date: 10 Mar 1981 1609-PST
Remailed-from: Harris A. Meyers <Meyers at SRI-KL>
Remailed-to: local-nets at MIT-MC
---------------------------
Date: 10 March 1981 11:46 am PST (Tuesday)
From: Weissman.PA
Subject: 3Com takes on DEC
To: AllJunk^
From "Information Systems News" of 3/10/81:
3Com To Build Ethernet Transceiver
3Com Corp. will build 10-megabit-per-second Ethernet Transceivers designed to
meet the specifications for the Ethernet office network published last September
by Xerox Corp., Digital Equipment Corp. and Intel Corp.
Each of the three companies are [sic] to provide different components to the
Ethernet system, with DEC manufacturing the network transceivers. By
introducing its transceiver now, 3Com is attempting to grab the inside track from
the minicomputer manufacturer.
Robert M. Metcalf [sic], president of 3Com, was one of the original developers of
the Ethernet architecture while he was with the Xerox Palo Alto Research Center.
The Menlo Park, Calif., manufacturer of computer communications products said
it has already accepted orders from more than 20 customers for preproduction
models of a local networking device.
The first installations of Ethernet, a local computer networking system that uses
coaxial cable to link computer and office equipment from multiple vendors, are
currently being made.
Currently the only Ethernet components available are from Xerox, which has
produced a limited number of transceivers for the first Ethernet customers. But
Xerox says it has no plans to mass produce the device.
A modified version of the Ethernet specifications was recently adopted by the
Institute of Electrical and Electronics Engineers (IEEE). Firms now known to be
pursuing Ethernet as put forward by its three developers are: 3Com,
Hewlett-Packard Co., Nixdorf Computer Corp., Olivetti Computers, Thomson-CSF
and Zilog Inc.
The 3Com Ethernet Transceiver will, when combined with other hardware and
software products, enable manufacturers and users to be compatible with Xerox,
DEC and Intel Ethernet systems.
Each transceiver has standard N-series connectors for coupling to the coaxial
cable and comes with a 50-foot transceiver cable.
The transceivers will cost $550 each for the first 10 units, and $365 each for
additional units. They are available now, and delivery will begin in two to
three weeks.
------------------------------------------------------------
11-Mar-81 17:37:38-EST,2433;000000000000
Mail from RADC-TOPS20 rcvd at 11-Mar-81 1737-EST
Date: 11 Mar 1981 1655-EST
From: Kevin Paetzold <PAETZOLD at RADC-TOPS20>
To: TOPS-20: G.Cower at SU-SCORE, Baker at AFSC-HQ, Pace at AFSC-HQ,
Perilli at AFSC-HQ, Allen at BBND, EONeil at BBND, JBorchek at BBNG,
Tappan at BBNG, CSD.Milligan at SU-SCORE, Lindblad at CIT-20,
King at CMU-20C, G.daCruz at SU-SCORE, G.SLogin at SU-SCORE,
G.TJM 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, Wallace at MIT-XX,
NCP.Pine at SU-SCORE, Rowe at NBS-10, Mittal at RUTGERS,
Waggoner at RUTGERS, GeoffM at RAND-AI, Paetzold at RADC-TOPS20,
Pratt at RADC-TOPS20, 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,
Rindfleisch at SUMEX-AIM, Schoen at SUMEX-AIM, Sweer at SUMEX-AIM,
Larson at SRI-KL, Meyers at SRI-KL, CC.Clive at UTEXAS-20,
CC.David at UTEXAS-20, CC.Loomis at UTEXAS-20, G.ECP at SU-SCORE,
Thompson at USC-ECLB-IPI, CTaylor at USC-ISIF, Dale at USC-ISIB,
Koda at USC-ISID, LSims at USC-ISIE, Frank at UTAH-20,
C-Griss at UTAH-20, Crossland at UTAH-20;
Reply-to: Paetzold at RADC-TOPS20
Telephone: 315-330-4013 AV-587
Subject: Changing of the guard
Message-ID: 11711260450.17.240.65054 at RADC-TOPS20
As some of you know I am leaving RADC-TOPS20 for bigger and
better things. I have been transferred by DEC to Marlboro. I am
being replaced by Mark Pratt (PRATT@RADC-TOPS20). I would appreciate
all of you adding Mark to your mail lists. I will still receive mail
at RADC-TOPS20 (the preferred address) as well as DEC-MARLBORO and
DEC-2136.
This mail list (first began by MRC I believe) has saved me
countless hours of aggravation and pain by seeing some bugs and the
fixes for them before they occured on my system. It has also given
me some amused moments (eg Mr. Bill buys a 20).
I wish you all luck in the future. Please do not hesitate to
contact me if you think I can ever be of any help to you. My address
is (I do not know my new phone number):
Kevin W. Paetzold MR1-2/E37
Digital Equipment Corporation
Large Systems Engineering
200 Forest Street
Marlboro, Mass 01752
--------
12-Mar-81 22:21:33-EST,788;000000000000
Mail from SU-SCORE rcvd at 12-Mar-81 2221-EST
Mail-from: ARPANET site MIT-AI rcvd at 12-Mar-81 1226-PST
Date: Thursday, 12 March 1981 15:08-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at score
Subject: scheduler bug
Remailed-date: 12 Mar 1981 1910-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.75: ;
At MIT we often see a problem when loads get fairly high (10 or
greater) where the scheduler "forgets about" some jobs and gives them
essentially no time. This often clears up by itself, but sometimes
degenerates to the point where we have to reload. I haven't had a
chance to look at it closely, but wondered if other people had ever
seen it. (It's entirely possible that it's a local problem.)
14-Mar-81 19:51:06-EST,1089;000000000000
Mail from SU-SCORE rcvd at 14-Mar-81 1950-EST
Mail-from: ARPANET site MIT-MC rcvd at 14-Mar-81 0612-PST
Date: Saturday, 14 March 1981 09:12-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at Score
Subject: Tops-20 people: scheduler problems
Remailed-date: 14 Mar 1981 1642-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.76: ;
Re my last query about the scheduler "forgetting about" certain jobs
when the load gets high: I remembered that this is a feature of the R4
scheduler---when it thinks things are in tough shape due to a high
load, it will first put all batch jobs to sleep, then it will quiesce
forks in the higher (ie, less interactive) queues. I'm almost sure
this is what's happening, since interrupting the fork and contininuing
it (which gets it into an interactive queue for a while) buys some
time for it.
I don't think this is a good idea, especially when the loads are only
10 that we're talking about. Is there some way to set this quiescing
parameter, or turn it off entirely?
16-Mar-81 04:58:53-EST,1170;000000000000
Mail from SU-SCORE rcvd at 16-Mar-81 0458-EST
Mail-from: ARPANET site UTAH-20 rcvd at 14-Mar-81 1912-PST
Date: 14 Mar 1981 2002-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Tops-20 people: scheduler problems
To: Admin.MRC at SU-SCORE, cpr at MIT-AI
In-Reply-To: Your message of 14-Mar-81 1753-MST
Remailed-date: 16 Mar 1981 0154-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.76: ;
My recollection is that this is controlled by the bias control knob.
The particular parameter of the scheduler which controls it is the
"disaster avoidance" facility as it is called. We set our bias knob at
9, which I'm pretty sure disables disaster avoidance. I'm note
sure how much lower you can set bias without turning disaster
avoidance on. We did have it on for a while and found it to be
a disaster!
Disaster avoidance works something like this: at a certain high queue
load avg (4 or something like that) no low q processes are added to the
balset. At another high q load avg (6?? 8??) low q processes are
forceably removed from the balance set, even if they reserve time left.
-------
16-Mar-81 05:08:58-EST,1312;000000000000
Mail from SU-SCORE rcvd at 16-Mar-81 0508-EST
Mail-from: ARPANET site RUTGERS rcvd at 14-Mar-81 1917-PST
Date: 14 Mar 1981 2212-EST
From: HEDRICK at RUTGERS
Subject: Re: Tops-20 people: scheduler problems
To: cpr at MIT-MC
cc: Admin.MRC at SU-SCORE
In-Reply-To: Your message of 14-Mar-81 1951-EST
Remailed-date: 16 Mar 1981 0154-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.76: ;
I assumed you knew the way the scheduler worked, and had some other
problem. Actually it depends upon the setting of the bias control.
With the bias control at 11, it does not forget processes under high
load. With the control anywhere under 11, it does. We find that
what we want is the behavior of 6, but without the forgetting of
processes. Therefore, we make even bias control numbers turn off
the bit that controls this feature. Odd numbers retain the original
DEC functions. We find that with this definition 6 gives us
significantly better results than 11 (the default), whereas with the
original DEC definitions, 6 was a disaster, because our serious
research jobs (e.g. Lisp) got turned off.
Also, we find that background batch is a bit too background.
Apparently the jobs get so frozen that you can't even log them off.
-------
18-Mar-81 01:22:02-EST,1304;000000000001
Mail from SU-SCORE rcvd at 18-Mar-81 0121-EST
Mail-from: ARPANET site MIT-AI rcvd at 16-Mar-81 1119-PST
Date: Monday, 16 March 1981 13:45-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at SCORE
Reply-to: CPR at MIT-MC
Subject: RSX20F serious problem
Remailed-date: 17 Mar 1981 2215-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.76: ;
Here's a simple C program, whose purpose and method should be clear.
It's not totally artificial; there's a hacker on XX who does the same
thing in a Muddle graphics program, and consequently trashes 20F. It
appears (if it's not obvious) that lots of negotiations about
page-mode causes buffer-overflows in the front-end (doing this 100
times really keeps the front-end down for a long time).
Is there any hope that DEC can fix this? We surely don't want to hack
20F.
main ()
{while (TRUE)
{int n, tmp;
char buf[100];
setprompt ("Number of times to thrash front end: ");
gets (buf);
tmp = copen (buf, 'r', "s");
if (scanf (tmp, "%d", &n) != 1) break;
cclose (tmp);
while (--n >= 0)
{int omode;
omode = _RFMOD (PRIOU);
_STPAR (PRIOU, omode & ~PAGE_MODE);
SYSBOUT (PRIOU, 'x');
_STPAR (PRIOU, omode | PAGE_MODE);
}
}
}
18-Mar-81 23:51:42-EST,1360;000000000000
Mail from SU-SCORE rcvd at 18-Mar-81 2351-EST
Mail-from: ARPANET site SRI-KL rcvd at 18-Mar-81 2037-PST
Date: 18 Mar 1981 2031-PST
From: LARSON at SRI-KL
Subject: FTPSER bug
To: Admin.MRC at SU-SCORE
Remailed-date: 18 Mar 1981 2044-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.77: ;
[Note from MRC: Systems running an XMAILR FTPSER (e.g. Stanford
and MIT) should not put this change in. It is unnecessary since
the XMAILR FTPSER handles this differently.]
PROBLEM:
If FTPSER receives a message to forward to a user for whom it already
has a message waiting to be remailed, it will append it to the same file;
resulting in the user recieving two messages with one length header. This
will confuse all mail readers known to the author.
Normally this is not noticed, since most mailers respond to the "will
forward" message by aborting and sending directly to the new destination.
SOLUTION:
When forwarding, insist on the creation of a new file.
LINE 7, PAGE 43
1) ;8 TLZ A,101000 ;YES. ALLOW NEW FILE
1) movsi a,(gj%fou!gj%new!gj%sht) ;8 yes, require new output file
1) MAIL2C: GTJFN
LINE 7, PAGE 43
2) TLZ A,101000 ;YES. ALLOW NEW FILE
2) MAIL2C: GTJFN
I am running with this in, and it seems to work. The complaints stopped.
Alan
-------
19-Mar-81 16:09:43-EST,2620;000000000000
Mail from SU-SCORE rcvd at 19-Mar-81 1609-EST
Date: 19 Mar 1981 1255-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: COMND% bugfix, from Columbia
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.77: ;
Submitted by Jeff Damens (212-280-3754) & Andy Lowry (212-280-3704)
Problem:
If a carriage return is typed when using the COMND jsys to
parse a noise word, and if none of the buffer contents have
yet been processed (words .cmbfp and .cmptr in the CSB point
to the same character), COMND will reissue the prompt and
wait for futher input, without ever returning to the user
program. This situation might naturally arise if the noise
word is preceded by one or more fields all of which are
supplied with defaults, and the user simply types a carriage
return expecting to accept all the defaults and move on.
Diagnosis:
In almost all parsing situations when none of the buffer has
been processed and the user types a carriage return, the
correct action is to reissue the prompt and wait for further
input. Exceptions to this rule are in these situations:
- The function code was .CMCFM (parsing a confirm)
- A default was supplied for the field (use it & continue)
- The function code was .CMFIL (arbitrary filespec) and the
GTJFN block contains a default name
- The function code was .CMNOI (Parsing a noise word)
All but the last of these cases is checked for in the literal
that begins two lines past NLINE (the literal is jumped to as
soon as it has been determined that the next input in the
buffer is a carriage return). The ommission of the test for
the last case is what causes the problem.
Cure:
Make the following changes inside the literal:
Old code:
NLINE: CALL RDCRLF ;END OF LINE FIRST THING ON IT
CAIA ;NO
JRST [ TXNE F,CMPS1F ;JUST SCANNING?
.
.
CAIN T1,.CMFIL ; PARSE ARBITRARY FILE?
JRST CHKDEF ; YES. CHECK GTJFN BLOCK...
CALL CHKCFM ;NO, SEE IF THERE IS A CONFIRM...
JRST CHKDF1 ; NONE, REISSUE PROMPT
JRST XCOM0] ;YES, PROCESS IT
New code:
NLINE: CALL RDCRLF ;END OF LINE FIRST THING ON IT
CAIA ;NO
JRST [ TXNE F,CMPS1F ;JUST SCANNING?
.
.
CAIN T1,.CMFIL ; PARSE ARBITRARY FILE?
JRST CHKDEF ; YES. CHECK GTJFN BLOCK...
(insert) CAIN T1,.CMNOI ;NO, NOISE WORD?
(insert) JRST XCOM0 ;YES, PROCESS IT
CALL CHKCFM ;NO, SEE IF THERE IS A CONFIRM...
JRST CHKDF1 ; NONE, REISSUE PROMPT
JRST XCOM0] ;YES, PROCESS IT
-------
19-Mar-81 16:28:45-EST,1458;000000000000
Mail from SU-SCORE rcvd at 19-Mar-81 1628-EST
Date: 19 Mar 1981 1256-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: CRDIR leaving JFN open, from Columbia
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.77: ;
Andre Lowry
Columbia University Center for Computing Activities
Problem:
If CRDIR% fails to delete a directory because someone had the
directory file mapped, the process doing the CRDIR% is left with a jfn
on the firectory file.
Diagnosis:
Approximately halfway between DELDI6 and DELDI2, CRDIR% calls CHKOFN
to make sure that the directory file is not open anywhere. If the
file is open, CRDIR% RETBAD's immediately with error code CRDIX6.
At this point, the process has a JFN on the directory file, which should
have neen released before the RETBAD.
Cure:
The code at DELDI3 was written to handle the jfn release followed
by a RETBAD. Just use it instead of the bare RETBAD. Make the following
code chages:
Old Code:
DELDI6: LOAD A,DRLIQ,(Q1) ;GET LIQ
:
:
CALL CHKOFN ;SEE IF THIS FILE IS OPEN (DIRECTORY IS MAPPED)
RETBAD(CRDIX6) ;YES. CAN'T DELETE THE FILE, THEN
New Code:
DELDI6: LOAD A,DRLIQ,(Q1) ;GET LIQ
:
:
CALL CHKOFN ;SEE IF THIS FILE IS OPEN (DIRECTORY IS MAPPED)
JRST [ MOVEI D,CRDIX6 ;YES. CAN'T DELET THE FILE, THEN
JRST DELDI3]
-------
19-Mar-81 16:52:45-EST,3952;000000000000
Mail from SU-SCORE rcvd at 19-Mar-81 1651-EST
Date: 19 Mar 1981 1257-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: ILMNRF crash in GET%, from Columbia
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.77: ;
Andrew Lowry & Bill Schilit
Columbia Computer Center
Problem:
Any user can crash the monitor with a ILMNRF bughlt by issuing a
GET% jsys under certain conditions
Diagnosis:
The problem occurs when GET% makes an internal call to SIN% in such
a way that the XCTBUU [IDPB B,2] instruction at SIN1+7 causes an
illegal memory write. This instruction is executed only after filling
the file's input buffer. Thus in particular if the input buffer is
empty at the start of the SIN% call the instruction will be executed.
All the other data transfer in SIN% when called by GET% is handled
by the BYTBLT routine which is protected against memory protect
failures by setting a trap dispatch address in TRPDSP on entry to the
routine and restoring the previous value upon exiting.
Since GET% will ask for no more than 1000 (octal) words to be
transferred at a time, and the input buffer size for a disk file is
1000 words, this condition can only occur when the input buffer is
empty at the time of the SIN% call. In addition, this SIN% must be
the first reference to the write-protected page; otherwise the trap
would already have occured in BYTBLT and would have caused an
interrupt in the process executing the GET%.
Note that this bug only manifests itself with nonsharable save
files, since SIN% is not used by GET% for sharable files.
Example:
The following sequence of commands will create a bogus csave file
and then issue a GET% on that file in a way that will crash the
system. We have given a rather long procedure here since it clearly
demonstrates all the conditions that must be present for the crash to
occur.
@; First make the file exist so we can FILDDT it
@
@cop nul: dont-get-me.exe
NUL: => DONT-GET-ME.EXE.1 [OK]
@
@; Now we'll build a bogus csave file inside it
@
@filddt
FILDDT>get dont-get-me.exe/patch
% Not in .EXE format -- Data file assumed
[Looking at file DONT-GET-ME.EXE.1]
0! -776,,777 ! Load 776 words starting at loc 1000
! (the contents are unimportant)
777! -1,,1777 ! Then load one more word at loc 2000.
! Note that when SIN% is called to
! process this block, the file's input
! buffer will be empty since we just
! read 1000 words, and the word will
! be stored in a new core page.
1000! 0 ! Make this file page exist.
^Z
@
@; Now we have to fix the file's byte count or GET% will hit
@; eof before getting to the danger spot.
@
@sddt
1! gj%sht
2! -1,,1000
100! ""dont-get-me.exe"
gtjfn%$x
<SKIP>
1/ 13 .fbsiz,,13
2! -1
3! 200 ; Make it big enough to read past the
; trouble spot.
chfdb%$x
<SKIP>
2000! 0 ; Make the page exist so we can set
; it to be write-protected
^Z
@
@; Now we'll use the EXEC to make process page 2 write-protected.
@; (Note we'll do our GET% right into the SDDT fork we've been
@; using, just for convenience's sake.)
@
@set page-access (of pages) 2 (access) no write -
@ no copy-on-write
@
@; Finally, we're read to do our killer GET%
@
@ddt
DDT
1! .fhslf,,13 ; Use our old jfn, no flags set
get%$x ; Oh nooooooooooo!
%DECSYSTEM-20 NOT RUNNING^G^G^Gx~~~'&^x
Cure:
The XCTBUU [IDPB B,2] instruction must be protected against illegal
memory references either by setting up a dispatch address (and
possibly requesting a psi interrupt for the user fork) in TRPDSP, or
by inserting and ERJMP or ERCAL instruction immediately afterwards.
These are the two conditions that will cauise the code at ILWR in the
PAGEN module to avoid BUGHLT'ing.
-------
21-Mar-81 03:56:28-EST,655;000000000001
Mail from SU-SCORE rcvd at 21-Mar-81 0356-EST
Date: 20 Mar 1981 2130-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-15152
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.80: ;
I am unable to install SPR 20-15152, as printed in the 1 March 1981
Software Dispatch. I get a T04 11-HALT right after doing the
DEPOSIT 35006:000137. Thinking that it might be because my system
has the KLINIK enabled by default, I did a CLEAR KLINIK in a fresh
RSX and tried again, but I still got the T04. Does anybody have
any clues?
-- Mark --
-------
24-Mar-81 16:55:23-EST,3539;000000000001
Mail from SU-SCORE rcvd at 24-Mar-81 1654-EST
Mail-from: ARPANET site DEC-MARLBORO rcvd at 22-Mar-81 2114-PST
Date: 23 Mar 1981 0013-EST
From: DEUFEL at DEC-MARLBORO
To: ADMIN.MRC at SU-SCORE
Subject: RSX20F Patch for Split Speed KLINIK/CTY
Message-ID: <MS"5(1563)"11714223825.15.385.13799 at DEC-MARLBORO>
Remailed-date: 24 Mar 1981 0930-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.83: ;
Hi Mark, I got your message concerning edit G to RSX20F VB1341.
Sorry for the inconvenience but I discovered the typo to late to
prevent it from being published. The corrected answer is due to be
published soon. Here is the corrected answer:::
---------------------------------------------------------------------
Aux file:
Thank you for your SPR on RSX20F. The following will allow
you to run your CTY and KLINIK at different speeds.
[SYMPTOMS]
The CTY and KLINIK hang when logically connected together
in REMOTE mode and the two lines are running at different
speeds.
[DIAGNOSIS]
The routines which acknowledge the processing of output data
for the KLINIK/CTY assume that they will both be running at
the same speed.
[CURE]
Deallocate and acknowledge output nodes when the slower of
the two lines is done with it and let the faster of the two
lines wait on the slower. Note that this patch makes the
assumption that the CTY is always running at the same speed
or faster than the KLINIK line is running when the two are
logically connected. This is edit G to RSX20F VB13-41.
To apply this patch do the following:
1) Shut down the system by typing the following:
^\ ! Control-\ to invoke the PARSER
--
PAR>SHUT ! Causes TOPS20 to stop running
2) Now reboot the Console Front End by setting the switches
on the PDP-11 to 203 and pressing the ENABLE and SWITCHES
load switches on the KL10 front panel.
3) Type ^\ (Control-\) to invoke the PARSER.
4) Type the following to the PARSER:
SET CONSOLE MAINTENANCE
SET MEMORY ELEVEN
! CMP R5,KLNPTR
DEPOSIT 144:020537
DEPOSIT 146:002636
! BNE #166
DEPOSIT 150:001006
! MOV R5,-(SP)
DEPOSIT 152:010546
! MOV CTYPTR,R5
DEPOSIT 154:013705
DEPOSIT 156:002634
! JSR PC,.TTCAK
DEPOSIT 160:004737
DEPOSIT 162:034522
! MOV (SP)+,R5
DEPOSIT 164:012605
! RTS PC
DEPOSIT 166:000207
! JMP #144
DEPOSIT 34514:000137
DEPOSIT 34516:000144
! .ASCII /1G/
DEPOSIT 1044:043461
!
WHAT VERSION
!
SET CONSOLE OPERATOR
5) NOW TYPE "MCR SAV<CR>"
IN RESPONSE TO THE PROMPT SAV> TYPE "SY0:/WB<CR>"
This will save the patched RSX20F immage on the front end file
system.
If you have any questions about applying this patch please
contact your local software specialist before proceeding.
--------------------------------------------------------------------------
BEWARE: There is a problem with this patch in that the KLINIK line
cannot be used as regular timesharing line. If you try to use the
KLINIK line as a timesharing line (e.g. USER mode) the KLINIK line
will hang after printing about 12 characters of the system header
when someone dials in... We are working on this problem and hope
to have it fixed shortly. The patch was published because VB1341
hung if you tried to run the CTY at a speed greater than the KLINIK
line ant the KLINIK line was used as a REMOTE console.
If you have any questions let me know...
-Abdul-
--------
25-Mar-81 20:40:57-EST,438;000000000000
Mail from MIT-MC rcvd at 25-Mar-81 2040-EST
Date: 25 Mar 1981 1835-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: tape copy program
To: twenex-wizards at MIT-MC
Does anyone have a general program that just copies (duplicate)
tapes, with the source and destination tapes as possible
different densisites. I want something that will copy the
entire contents of a tape (e.g., it may have multiple files).
Randy
-------
25-Mar-81 21:38:54-EST,376;000000000000
Mail from MIT-MC rcvd at 25-Mar-81 2138-EST
Date: 25 Mar 1981 1934-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: tape copy program
To: C-GRISS at UTAH-20, twenex-wizards at MIT-MC
In-Reply-To: Your message of 25-Mar-81 1928-MST
I got a program called MTU from SCORE, which also does tape copying.
It looks pretty powerfull. Itps over here now.
-------
25-Mar-81 21:43:32-EST,474;000000000000
Mail from MIT-MC rcvd at 25-Mar-81 2143-EST
Date: 25 Mar 1981 1928-MST
From: C-GRISS at UTAH-20
Subject: Re: tape copy program
To: FRANK at UTAH-20, twenex-wizards at MIT-MC
In-Reply-To: Your message of 25-Mar-81 1835-MST
Randy,
I have a program that copies tapes bit for bit and can change
densities. As it doesnt double buffer, it runs a little slower in real
time than it has to -- but weve used it for distributions and it works
fine.
Ced.
-------
25-Mar-81 23:21:44-EST,499;000000000000
Mail from MIT-MC rcvd at 25-Mar-81 2321-EST
Date: 25 Mar 1981 2308-EST
From: HEDRICK at RUTGERS
Subject: Re: tape copy program
To: FRANK at UTAH-20
cc: twenex-wizards at MIT-MC
In-Reply-To: Your message of 25-Mar-81 2035-EST
MTU will do it, I think. At least it always has worked for me.
I have always used it with unlabelled tapes, however. It should
also work with labelled tapes if set unavailable or mounted
bypass. It does let source and dest be different densities.
-------
31-Mar-81 19:09:43-EST,770;000000000000
Mail from SU-SCORE rcvd at 31-Mar-81 1909-EST
Date: 27 Mar 1981 1936-PST
From: Patrick Milligan <CSD.Milligan>
Subject: Desired: TOPS-20 BCPL
To: Admin.MRC
Remailed-date: 31 Mar 1981 1600-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.83: ;
You might be able to help me with this, or perhaps the TOPS-20
distribution list is the right thing. I would like to get a
recent version of BCPL which works with TOPS-20. I have an old
TENEX version. I believe that BBN, SRI, and USC-ISI have BCPL,
but I don't know who maintains BCPL at those sites. I would like
to get everything associated with BCPL, including sources for the
compiler and utilities.
I hope you can help...
-- Patrick
-------
22-Mar-81 5:15:48,783;000000000000
Mail-From: ADMIN.MRC created at 22-Mar-81 04:01:04
Mail-from: ARPANET site AFSC-HQ rcvd at 22-Mar-82 1444-PST
Date: 22 Mar 1982 1756-EST
From: Chuck Perilli <PERILLI at AFSC-HQ>
Postal-address: HQ AFSC/ACDPS, Andrews AFB, DC 20334
Phone: (301)981-4002; AUTOVON: 858-4002
Subject: Free DBMS
Remailed-date: 22 Mar 1981 0401-PST
Remailed-from: Mark Crispin
Remailed-Sender: ADMIN.MRC at SU-SCORE
Remailed-to: TOPS-20 at SU-SCORE
Software House of Cambridge, MA has announced that through June 1, they
will issue a limited number of FREE licenses for their 1022 data base
management system to non-profit, tax-exempt universities or colleges.
They are even offering to throw in a week-long seminar to go with it.
Might be a good deal for anyone qualified.
-------
10-Apr-81 20:43:32-EST,647;000000000000
Mail from MIT-MC rcvd at 10-Apr-81 2043-EST
Date: 10 Apr 1981 1833-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Program counter sampler program
To: twenex-wizards at MIT-MC
cc: lepreau at UTAH-20
Does anyone know a a program that samples the PC of another program
(perferably running as an inferior fork), adn then prints out a histogram
or the like of the pc. Ideally it would look the PC up against the
symbol table and give the histogram in a usable form (i.e., not just
PC address).
I'm aware of PCHIST. I'm looking for something with a little more
smarts, and which can be used by a non-priv user.
Randy
-------
10-Apr-81 20:54:54-EST,484;000000000000
Mail from MIT-MC rcvd at 10-Apr-81 2054-EST
Date: 10 Apr 1981 1748-PST
From: LARSON at SRI-KL
Subject: Re: Program counter sampler program
To: FRANK at UTAH-20, twenex-wizards at MIT-MC
cc: lepreau at UTAH-20
In-Reply-To: Your message of 10-Apr-81 1733-PST
There is an old TENEX program called PCSAMP. It does what you want.
I think later versions may even have looked through the symbol table,
but I am sure it is very close to what you want.
Alan Larson
-------
10-Apr-81 21:15:53-EST,2619;000000000000
Mail from MIT-MC rcvd at 10-Apr-81 2115-EST
Date: 10 Apr 1981 1902-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Availability of Portable C Compiler for the 20 - PRELIMINARY NOTICE
To: twenex-wizards at MIT-MC
THIS IS A PRELIMINARY ANNOUNCEMENT OF A FORTHCOMING RELEASE OF PCC/20.
PLEASE DO NOT DISTRIBUTE FURTHER WITHOUT OUR PERMISSION. THANKS.
The Univ. of Utah will be releasing (hopefully by June) the Unix Portable
C Compiler (PCC) ported to the DECSystem 20, along with a mostly-Unix
compatable library for the 20. The purpose of this announcement is to
let interested parties initiate the Western Electric licensing procedure,
which is necessary since PCC is part of Unix V7.
As silly as it sounds, before we can send you PCC/20, you will have to
get your 20 licensed for Unix V7 or Vax Unix. If you already have V7
Unix or Vax Unix licensed to your institution, usually all it takes is
a letter to Bell Labs asking that your 20s be added to your V7 or Vax
Unix license (along with $$$ if you are not an educational site - I don't
know how much is involved for a second system license for commercial
sites). If you don't have either a V7 or Vax Unix license, you must get
one from Bell Labs/Western Electric. Licenses (or modifications to licenses)
from Bell have been running about 8-10 weeks, so this is one reason why we
are pre-announcing this program.
We will require a copy of your Unix license, as well as a signed Univ.
of Utah license agreement (available from me). Once released, it will
be available free of charge to universities and non-profit institutions
that have had a policy of free distribution of similar software. (I think
most of you are in this category!). Policy for commercial organizations
and universities who are in the "software house" business has not been
decided, yet.
Technical considerations: The main advantage to PCC/20 is that it is
source code compatable with both v7 Unix C and Vax C (the Vax C compiler
also uses PCC as a basis; V7 C is a non-portable compiler, but is
nevertheless compatable with PCC). Jay Lepreau (LEPREAU@UTAH-20) has
been responsible for the implementation of PCC/20, and should be
contacted for technical questions. Our goal here (and the reason
we undertook the project) was so that we could have a common source
language for programming our 20s, Vax Unixs, and 11 Unixs.
IF INTERESTED YOU MUST INITIATE THE LICENSING WITH BELL. Please don't
ask us to forward you a copy until this is done, as we expose ourselves
legal action if we do, and therefore we won't!
Randy
-------
13-Apr-81 22:46:37-EST,933;000000000000
Mail from SU-SCORE rcvd at 13-Apr-81 2246-EST
Mail-from: ARPANET site DEC-MARLBORO rcvd at 3-Apr-81 0753-PST
Date: 3 Apr 1981 1053-EST
From: MILLER at DEC-MARLBORO
To: admin.mrc at SCORE
Subject: For distribution
Message-ID: <MS"5(1563)"11717223952.18.258.1600 at DEC-MARLBORO>
Remailed-date: 13 Apr 1981 1626-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.84: ;
I have been asked to solicit extended programs that people have
written. The request has come from the MBOX designers so that they
can do some cache simulations.
Ideally, the examples should be working programs that use multiple
sections (i.e. not just a single section program that happens to run
in any section). We would prefer not to have any proprietary stuff
since we don't want the hassle of legal agreements.
If anyone has such an application, contact Mike Uhler or me.
--------
13-Apr-81 22:57:30-EST,834;000000000000
Mail from SU-SCORE rcvd at 13-Apr-81 2257-EST
Mail-from: ARPANET site MIT-XX rcvd at 9-Apr-81 1144-PST
Date: Thursday, 9 April 1981 14:40-EST
From: Chris Ryland <CPR at MIT-XX>
To: Admin.MRC at SU-SCORE
Reply-to: CPR at MIT-MC
Subject: SFTAD fatal bug
Remailed-date: 13 Apr 1981 1716-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.84: ;
Someone at CMU pointed out that giving a -1 in T2 to SFTAD% would
crash the system (clearly, at SFTAD3, in JSYSF, the XCTU is going to
fail with an invalid section reference). I'm afraid that there are
lots and lots of JSi that would do the same. Probably, someone will
have go through and add calls to routines to validate all addresses
given (usually a range of addresses), especially with multiple
section support.
13-Apr-81 23:01:32-EST,1420;000000000000
Mail from SU-SCORE rcvd at 13-Apr-81 2301-EST
Mail-from: ARPANET site MIT-AI rcvd at 9-Apr-81 1020-PST
Date: Thursday, 9 April 1981 13:17-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at SU-SCORE
Subject: [JONL: Queries about logical names]
Remailed-date: 13 Apr 1981 1715-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.84: ;
Has anyone seen the first problem? The second seems like a real bug.
--CPR
---Begin forwarded message---
Date: Tuesday, 17 March 1981 11:22-EST
From: JONL at MIT-MC (Jon L White)
Re: Queries about logical names
1) The first usage of the .NULIO designator as the destination
argument to LNMST causes an ilgl memry trap; subbsequent
usages in the same fork seem to win.
2) A name with multiple alternates is not correctly searched
by JFNS -- for example, the current SYS: defintion on MIT-XX
has PS:<SUBSYS> first, PS:<UNSUPPORTED> second, and etc.
the file PS:<UNSUPPORTED>RNMVRN.EXE exists, but no other
RNMVRN file exists on SYS:. If one gets a JFN with the
long form of GTJFN, using the string
"SYS:RNMVRN.EXE"
then he has a valid JFN which can be opened, etc, but if
he queries it with JFNS, it will say that the directory
field (from the JS%DIR specification) is SUBSYS rather
than UNSUPPORTED; all other fields are correctly reported.
15-Apr-81 03:24:41-EST,1749;000000000001
Mail from SU-SCORE rcvd at 15-Apr-81 0324-EST
Date: 15 Apr 1981 0018-PST
From: Patrick Milligan <CSD.Milligan>
Subject: Release 4 and XON/XOFF
To: Admin.MRC
Remailed-date: 15 Apr 1981 0019-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.86: ;
This is a request for information about the way that Release 4 of
TOPS-20 and/or RSX20F handles XON/XOFF on terminal input. I have been
debugging a DEC-20 program that needs to handle very high volume input
(256 bytes at a time, 8 bit bytes, at 9600 baud). I have done
everything I could think of with the various terminal JSYS calls, but
I still have XOFFs being set to my "Rogue terminal" that doesn't
handle XON/XOFF... I suspect that the culprit is the Front-End. I
vaguely remember something said at DECUS a couple of sessions ago
about changes in RSX20F for terminal input (seems like the silo buffer
size was reduced to 1 so that the backend would see XOFF's coming from
a VT100 fast enough to shut up so the VT100's buffer wouldn't
overflow).
I am working on making my "Rogue terminal" (actually, a Three Rivers
PERQ) understand XON/XOFF, but I would appreciate information about
how to get around the problem on the DEC-20/Front-End side of things.
(I realize I may be asking for framing errors if I do manage to stop
the flow control). Recommended parameters for OPENF/MTOPR/SFMOD/STPAR
and friends and/or Front-End/Back-End patches would be appreciated (or
simply information about the way that terminal input flow control
works...)
If appropriate, please forward this message to the TOPS-20 Distribution
list and/or people at DEC who might be able to enlighten me.
Thanks...
-- Patrick
-------
15-Apr-81 22:44:18-EST,818;000000000000
Mail from SU-SCORE rcvd at 15-Apr-81 2244-EST
Mail-from: ARPANET site DEC-MARLBORO rcvd at 15-Apr-81 1838-PST
Date: 15 Apr 1981 2136-EST
From: MILLER at DEC-MARLBORO
To: admin.mrc at SCORE
Subject: reported logical name bug
Message-ID: <MS"5(1563)"11720486662.24.258.4631 at DEC-MARLBORO>
Remailed-date: 15 Apr 1981 1937-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: CPR at MIT-EECS at MIT-AI,
[SU-SCORE]<Admin.MRC>TOPS-20.DIS.86: ;
I am sending this to you because the author's address is unknown here.
The second bug appears to be the problem that the program has write access
to SUBSYS and is doing the GTJFN without specifying GJ%OFL. COnsequently,
GTJFN is creating a new file in SUBSYS. As such it is not a bug, just
a very poorly thought out feature.
--------
16-Apr-81 23:36:08-EST,1016;000000000000
Mail from MIT-MC rcvd at 16-Apr-81 2336-EST
Date: Thursday, 16 April 1981 23:31-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at Score, Local-Nets at MIT-MC
Reply-to: CPR at MIT-MC
Subject: DEC-20 sites: building your own DN20, revisited
(Mark, please forward this to your Twenex mailing list; forgive
duplications.)
This is to announce a revised edition of Randy Frank's "Building your
own DN20" document, which I have put together from our little message
exchange. If you have a -20 and are interested in putting a front-end
on it for any number of reasons (most of us just want to get Unibus
devices interfaced to the KL), this may be interesting to you.
The document is at MIT-MC, file spec CPR;DN20 ERECTR (it's FTP'able
without logging in, of course). This may be updated as time goes by
and we think of new things to put in it; other sites that suffer the
slings and arrows of similar ventures are invited to send me mail
about their experiences so we can all benefit.
17-Apr-81 00:33:41-EST,1239;000000000000
Mail from SU-SCORE rcvd at 17-Apr-81 0033-EST
Mail-from: ARPANET site MIT-AI rcvd at 16-Apr-81 2027-PST
Date: Thursday, 16 April 1981 23:31-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at Score, Local-Nets at MIT-MC
Reply-to: CPR at MIT-MC
Subject: DEC-20 sites: building your own DN20, revisited
Remailed-date: 16 Apr 1981 2127-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: REG at SU-AI,
[SU-SCORE]<Admin.MRC>TOPS-20.DIS.86: ;
(Mark, please forward this to your Twenex mailing list; forgive
duplications.)
This is to announce a revised edition of Randy Frank's "Building your
own DN20" document, which I have put together from our little message
exchange. If you have a -20 and are interested in putting a front-end
on it for any number of reasons (most of us just want to get Unibus
devices interfaced to the KL), this may be interesting to you.
The document is at MIT-MC, file spec CPR;DN20 ERECTR (it's FTP'able
without logging in, of course). This may be updated as time goes by
and we think of new things to put in it; other sites that suffer the
slings and arrows of similar ventures are invited to send me mail
about their experiences so we can all benefit.
17-Apr-81 00:39:53-EST,1239;000000000000
Mail from SU-SCORE rcvd at 17-Apr-81 0039-EST
Mail-from: ARPANET site MIT-AI rcvd at 16-Apr-81 2027-PST
Date: Thursday, 16 April 1981 23:31-EST
From: Chris Ryland <CPR at MIT-EECS>
To: Admin.MRC at Score, Local-Nets at MIT-MC
Reply-to: CPR at MIT-MC
Subject: DEC-20 sites: building your own DN20, revisited
Remailed-date: 16 Apr 1981 2127-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: REG at SU-AI,
[SU-SCORE]<Admin.MRC>TOPS-20.DIS.86: ;
(Mark, please forward this to your Twenex mailing list; forgive
duplications.)
This is to announce a revised edition of Randy Frank's "Building your
own DN20" document, which I have put together from our little message
exchange. If you have a -20 and are interested in putting a front-end
on it for any number of reasons (most of us just want to get Unibus
devices interfaced to the KL), this may be interesting to you.
The document is at MIT-MC, file spec CPR;DN20 ERECTR (it's FTP'able
without logging in, of course). This may be updated as time goes by
and we think of new things to put in it; other sites that suffer the
slings and arrows of similar ventures are invited to send me mail
about their experiences so we can all benefit.
18-Apr-81 10:29:14-EST,468;000000000001
Mail from SU-SCORE rcvd at 18-Apr-81 1029-EST
Date: 18 Apr 1981 0726-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: fork 1
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.87: ;
Does anybody know what fork 1 of job 0 is? It has zero runtime, all
zeroes in its UPDL, and is halted. It seems to have last run a second
or two after the system was loaded.
-------
23-Apr-81 00:06:08-EST,1146;000000000000
Mail from SU-SCORE rcvd at 23-Apr-81 0005-EST
Date: 22 Apr 1981 2101-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: [MILLER at DEC-MARLBORO: Re: fork 1]
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
Thanks goes to everybody who responded to my message about what fork 1
is. There were lots of guesses (TGHA, SYSERR, HSYS, expunge) but this
seems to be the right answer:
---------------
Mail-from: ARPANET site DEC-MARLBORO rcvd at 21-Apr-81 1343-PST
Date: 21 Apr 1981 1641-EST
From: MILLER at DEC-MARLBORO
To: Admin.MRC at SU-SCORE
Subject: Re: fork 1
Message-ID: <MS"5(1563)"11722005921.30.258.2271 at DEC-MARLBORO>
In-reply-to: Message from Mark Crispin <Admin.MRC at SU-SCORE>
of 18-Apr-81 1026-EST
I believe that it is the IPCF page mode fork. The system creates
a fork simply to ravage its address space in order to hold pages
of IPCF messages waiting to be recieved. The fork never runs beyond
its inititialization code.
--------
---------------
-------
23-Apr-81 20:44:09-EST,1969;000000000000
Mail from SU-SCORE rcvd at 23-Apr-81 2043-EST
Mail-from: ARPANET site RUTGERS rcvd at 23-Apr-81 1317-PST
Date: 23 Apr 1981 1608-EST
From: WATROUS at RUTGERS
Subject: DUMPER bug causes problems during archive retrieval
To: Admin.MRC at SU-SCORE
Remailed-date: 23 Apr 1981 1734-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
We have discovered that DUMPER has a bug in it which causes it to
create savesets which have different saveset numbers in the records
from the saveset number indicated by the character string in the
header record. This caused the the problem that restore requests
from archive tapes were not being found on the tapes which had the
errors. Following is a patch which will enable DUMPER to use the
tapes with these errors. (We didn't find the bug, but suspect there
is something wrong in the recovery from a catastrophe during an
archive run.)
========================
Just before LODFIL insert:
jrst lodfil ;skip this code
lodfia: move a,buff+bfmsgp ;get offset of header text
hrroi a,buff+2(a) ;point directly to saveset#
movei c,^d10 ;get it in decimal
movei d,xbuff
nin ;read it from header
load b,ssno,(d) ;use this if fails
load c,ssno,(d) ;compare it with binary info
skipn arctsn ;if no previous problems
came b,c ;and if they match,
skipa
jrst lodfil ;no problem
push p,b ;tuck away right info
hrroi b,[asciz \%Saveset info in headers disagrees with that in records.
Using info from headers.
\] ;complain
skipn arctsn ;if this is first time
call tmsgqc
pop p,arctsn ;save correct information
Change the JRST LODFIL in the literal at LODHX2+5 to JRST LODFIA
At LODRET+15(octal), just before the CAIE A,0(B) insert:
skipe arctsn ;have better info?
move b,arctsn ;yes - use that
At RETTAP+1, insert:
setzm arctsn ;no alternate saveset# yet
========================
-------
26-Apr-81 23:04:44-EDT,754;000000000000
Mail from SU-SCORE rcvd at 26-Apr-81 2304-EDT
Mail-from: ARPANET site MIT-XX rcvd at 26-Apr-81 1336-PDT
Date: 26 Apr 1981 1635-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: DUMPER
To: admin.mrc at SU-SCORE
Remailed-date: 26 Apr 1981 1943-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
That message about the DUMPER bug reminded me of a DUMPER problem
which I've experienced a few times. Namely, after retrieving a set of
archived files DUMPER seems to hang up: I think this happens before
the last "[OK]". The tape doesn't move and DUMPER is SLEEPing. The
last file has in fact been retrieved.
Any comments? Could you disseminate this as you deem appropriate?
-------
27-Apr-81 12:59:22-EDT,243;000000000000
Mail from MIT-MC rcvd at 27-Apr-81 1259-EDT
Date: 27 Apr 1981 1153-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: VTTREK
To: twenex-wizards at MIT-MC
Anyone know where I can get a copy of VTTREK? Thanks, Ed
-------
27-Apr-81 14:25:01-EDT,490;000000000000
Mail from MIT-MC rcvd at 27-Apr-81 1424-EDT
Date: 27 April 1981 14:16-EST
From: Christopher P. Ryland <CPR at MIT-MC>
Subject: VTTREK
To: G.ECP at UTEXAS-20
cc: TWENEX-WIZARDS at MIT-MC
Date: 27 Apr 1981 1153-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
To: twenex-wizards
Re: VTTREK
Anyone know where I can get a copy of VTTREK? Thanks, Ed
Sorry, Eric never got back to me on this. I'm in CA now, by the way;
started work here today.
28-Apr-81 22:06:07-EDT,1418;000000000001
Mail from SU-SCORE rcvd at 28-Apr-81 2205-EDT
Date: 28 Apr 1981 1900-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: RSX-20F field test
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
[TOPS-20.DIS was protected by accident. I've unprotected it again. -- MRC]
---------------
Date: 28 Apr 1981 1200-PDT
From: Frank da Cruz <G.DACRUZ>
Subject: For distribution (TOPS-20.DIS is read protected?)
To: Admin.MRC
Perhaps foolishly, I've agreed to field-test RSX20F version 14.
DEC says it has:
1. Improved buffer management.
2. Improved flow control when buffer space low.
3. Removal of BF1, B01, B02, SAI and SAQ stopcodes.
4. Echoing of BELLs when buffer space not available (after sending XOFF
I presume. By the way, did you know that TOPS-20 already does this
when the FE attempts to give the KL some characters and the KL can't
find any place to put them?).
5. Optional running of CHK11 in the primary FE.
6. Bugs fixed in modem control code.
7. Automatic execution of PARSER.CMD when the KL crashes.
Also, I hear DEC is sending out feelers to find field testers for
TOPS-20 release 5, "Pascal 36" (U. of Washington Pascal, same as on VAX),
and "Common APL".
- Frank da Cruz, Columbia U.
-------
---------------
-------
28-Apr-81 22:16:33-EDT,2621;000000000001
Mail from SU-SCORE rcvd at 28-Apr-81 2216-EDT
Date: 28 Apr 1981 1234-PDT
From: Frank da Cruz <G.DACRUZ>
Subject: Re: [CSD.Milligan: Release 4 and XON/XOFF] (for forwarding)
To: Admin.MRC
In-Reply-To: Your message of 15-Apr-81 0020-PST
Remailed-date: 28 Apr 1981 1904-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
Don't know if you've already had some replies already, but yes, you're
right about what DEC had to do to RSX20F in Release 4 in order to
accommodate VT100's - in fact, they changed the silo interrupt level from
16 to 1! When we first installed the R4 FE software, the FE was crashing
like crazy because it couldn't shuffle its little buffers fast enough.
You could almost always make this happen by doing a page transmit from a
batch-mode terminal, or by reading data from a floppy (in either case,
the culprit was not doing XON/XOFF, of course). DEC's solution to the
problem was to have the FE always send an XOFF to a line it deemed "obnoxious"
and if, within x character times, the line does not quiet down, the speed
is set to zero for y amount of time. X and Y can be varied by changing
monitor code as follows:
TTQAD1/ movei t1, 5670 {the immediate quantity is the amount of time
to set the speed to zero}
BIGST2+2/ cail c, 50 {the immediate quantity is the number of chars
seen since XOFF was sent before turning off
the line}
There are optimum values for these two numbers, depending very much on
what goes on at your particular site. It's probably not a very good idea
to monkey with them too much. The real problem is that a PDP-11/40
running RSX20F just can't be expected to handle high speed input from
non XON/XOFFing lines because it's just too small and slow. The next
release of RSX20F alleges to have improved its capabilities in this area,
but we'll have to wait & see.
By the way, even if you get your high speed input past the front end, there's
still the back end to worry about, as we discovered when we were fooling
with file transfer between the -20 and micros over TTY lines. The only
reliable way of getting data through the front end is to have a protocol,
and somebody checking things on both ends. This holds even when both sides
are doing XON/XOFF.
Another by the way - I've heard of people hooking up high speed terminals
to a -20 in other ways that on ordinary TTY lines. Maybe that's what you
really want to do. I understand that CMU has PERQ's and a -20; maybe they
have them talking already.
- Frank da Cruz, Columbia U.
-------
29-Apr-81 20:11:00-EDT,745;000000000000
Mail from SU-SCORE rcvd at 29-Apr-81 2010-EDT
Date: 29 Apr 1981 1703-PDT
From: g.eldre at SU-SCORE (Tim Eldredge)
Subject: Request for information
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88:
I have an autodialer on my 20 which needs DTR to be raised
before it will dial. When I was running Rel3A all seemed to
be well, but now that I am running Rel4 it no longer works.
I have observed that DTR is not on. Can anyone tell me if
it is on in Rel3A (when the line is not in use of course, it
does come up if the phone rings)? Further, do any of you
know how I might convince the front-end to raise DTR at my
bidding. I'm quite willing and able to change the monitor, but
hacking at the -11 is out of bounds.
Thanks Tim
-------
30-Apr-81 02:48:07-EDT,888;000000000000
Mail from SU-SCORE rcvd at 30-Apr-81 0248-EDT
Date: 29 Apr 1981 1703-PDT
From: g.eldre at SU-SCORE (Tim Eldredge)
Subject: Request for information
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88:
Remailed-date: 29 Apr 1981 2346-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
I have an autodialer on my 20 which needs DTR to be raised
before it will dial. When I was running Rel3A all seemed to
be well, but now that I am running Rel4 it no longer works.
I have observed that DTR is not on. Can anyone tell me if
it is on in Rel3A (when the line is not in use of course, it
does come up if the phone rings)? Further, do any of you
know how I might convince the front-end to raise DTR at my
bidding. I'm quite willing and able to change the monitor, but
hacking at the -11 is out of bounds.
Thanks Tim
-------
30-Apr-81 10:29:08-EDT,580;000000000000
Mail from SU-SCORE rcvd at 30-Apr-81 1029-EDT
Date: 30 Apr 1981 0729-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: duplicate mail message
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.88: ;
My apologies for the duplicate message sent to the distribution list
yesterday. My mail reader's profile is set up to suppress all header
lines except for From: and Subject: by default. I remailed the message
without thinking to check the To: list first.
-- Mark --
-------
30-Apr-81 23:51:43-EDT,591;000000000000
Mail from MIT-MC rcvd at 30-Apr-81 2351-EDT
Date: 30 Apr 1981 2145-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Sources to LOOK Program
To: twenex-wizards at MIT-MC
Does anyone have the sources to the LOOK program (it's a program counter
histogram program that also gives output in terms of the symbol table).
Unfortunately, it has several losses we want to fix (namely it picks
bucket sizes in a strange and not very useful way). Pointers
appreciated. (I think it came from DEC somewhere; I've already chased
down a pointer to the SWSKIT tape with no luck).
-------
2-May-81 12:55:18-EDT,3206;000000000000
Mail from SU-SCORE rcvd at 2-May-81 1255-EDT
Date: 1 May 1981 1746-PDT
From: Bill Schilit <g.Mr-Bill>
Address: 715 Watson Labs, Columbia University, NYC 10027
Subject: Sysjob and the future
To: admin.mrc
cc: g.Mr-Bill
Remailed-date: 2 May 1981 0954-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.90: ;
Hi, the other night Andy and I wrote out a skeleton version of a new
sysjob. We were motivated when all our local hacks to the program got
"lost" in a source disaster... well I'm sending this along because I
want to pick your brain a little, and to ask if you have heard of any
like endeavors, or know of the history of this program (judging from
the source it was written in one sitting when TOPS-20 was still a
babe, no monsym, getting TTYJOB from SYSGT% instead of using .ttyjo
etc.). Here are somethings we'd like to see in our version:
System startup output to a file. This already seems to be standard at
SCORE and CU with the quiet feature.
OUTPUT filename - sends sysjob output to a file (or tty) Waiting for
the 300 baud console when advising subjobs is a pain.
Slowness when when starting up pty subjobs bypassed. We noticed that
sysjob waits 30 seconds for each pty job to start up during
initialization. This means about four minutes at CU (though I noticed
you guys run only one pty job so you probably don't notice this as
much.
No more "to much input for line", we installed a dynamic memory allocator.
Free format time and date input for the attime command. This allows
for +time, monday + time, etc.
Take notice if a subjob becomes detached from its pty. This has
happened here when a bad guy got the operator password and attached.
When this happens print a message on the console, and stop sending
output to the pty until it comes back.
Optionally log output to a file in addition to printing the stuff on
the console. We want this one because the machine room is sooooo far
away.
Time stamp the output as you do.
A TAKE command so we don't have to copy foo.cmd to system:sysjob.commands
and wait around for it to get noticed.
Inferior fork command parser uses comnd. This is one of the more
esoteric mods since most people don't use it.
Internal modifications include parsing with comnd and a neater format
for the program, much of the original code remains intact. All the
old command formats remain the same (for compatibilities sake - waaa).
Also it might be nice to write a command parser called espeak which
will make sure you are sending correct stuff (by using comnd) to the
sysjob.commands file.
Our favorite of these is something Andy and Jeff Damens came up with;
the output command. We have had problems though of people outputting
to their tty: and then detaching... this somethimes causes hanging. To
avoid this checking is made and maybe an attime command will be
generated for five minutes after the output command is given echoing
first a warning, and then another attime command re-redirecting to the
console.
I'd be glad to hear comments, suggestions, or "what I hate about sysjob
is..."s.
/Bill
-------
4-May-81 13:14:58-EDT,627;000000000000
Mail from MIT-MC rcvd at 4-May-81 1314-EDT
Date: 4 May 1981 13:08-EDT
From: Christopher P. Ryland <CPR at MIT-MC>
Subject: Twenex-Wizards mailing list now defunct
To: Paetzold at RADC-TOPS20, Pratt at RADC-TOPS20,
JGOLDBERGER at USC-ISIB
cc: TWENEX-WIZARDS at MIT-MC
I've decided to abandon this mailing list, since there's no sense in
trying to keep it up to date with MRC's list of -20 systems types, and
since some of the mail concerns security issues. Please send all
future mail to Admin.MRC at SU-Score, whence Mark will forward it
appropriately; if you want to be on his mailing list, contact him.
4-May-81 23:40:07-EDT,589;000000000001
Mail from SU-SCORE rcvd at 4-May-81 2340-EDT
Mail-from: ARPANET site RUTGERS rcvd at 4-May-81 2033-PDT
Date: 4 May 1981 2322-EDT
From: HEDRICK at RUTGERS
Subject: question about J0NRUN bughlt
To: admin.mrc at SU-SCORE
Remailed-date: 4 May 1981 2040-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.91: ;
We have been getting J0NRUN's at the rate of about once a week, on
two different systems. Fork 0 seems to be hung at DDMP waiting
to get the structure lock STRLOK. Anybody have any idea what is
going on?
-------
6-May-81 20:25:01-EDT,1121;000000000000
Mail from MIT-XX rcvd at 6-May-81 2024-EDT
Date: 6 May 1981 2023-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Wonderful world of patching
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
In case everyone hasn't heard about DEC's new software "product", I
thought I'd mention their new object-level automatic patcher. Basically
its a little data base maintainter that keeps track of all the patches
you've applied. It "interfaces" with MAKLIB.
Apparently DEC plans on distributing tapes for use by this tool.
Presently they support patching the monitor, EXEC and APL.
Unfortunately, this is all fairly useless if you've modified any stuff
locally to any great degree. Now I know you'll say: "that's what you
get for grubbing in system software" and I'd probably agree.
It would be nice however, that as long as DEC is sending out these tapes
if they'd supply some source-level patches. Presently, the only user
interpretable stuff is an about 2000 line edit history. Some of the patches
might be nice to apply if one had the source level change.
Anyone think they might be convinced?
-------
9-May-81 16:51:33-EDT,839;000000000000
Mail from SU-SCORE rcvd at 9-May-81 1651-EDT
Mail-from: ARPANET site USC-ECLB-IPI rcvd at 8-May-81 1742-PDT
Date: 8 May 1981 1742-PDT
From: Mark Thompson <THOMPSON at USC-ECLB-IPI>
PHE 232; USC: (213) 743-7121
Subject: fix for low load averages
To: Admin.MRC at SU-SCORE, Smith at USC-ISIB
Remailed-date: 9 May 1981 1347-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
i remember there was a problem people noticed where if the load average
got very, very low (below about .01), tops20 would start giving truly
awful response (on the order of several seconds between action and
response). I seem to have this problem, does either of you remember the
fix? (My fix was to run SYSBIG to thrash the machine, but thats not
really right...).
mark
-------
11-May-81 13:57:24-EDT,390;000000000000
Mail from MIT-MC rcvd at 11-May-81 1357-EDT
Date: Monday, 11 May 1981 10:47-PDT
To: local-nets at MIT-MC
Subject: DEC and Ethernet
From: mike at RAND-UNIX
According to MIS Week (which is often very, very wrong) DEC's David
Rodgers announced at the NCC that DEC was one to two years from
producing an Ethernet product. He claimed that they had only the
rawest of prototypes.
11-May-81 14:39:27-EDT,1387;000000000000
Mail from MIT-MC rcvd at 11-May-81 1439-EDT
Date: 11 May 1981 1201-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: DEC and Ethernet
To: local-nets at MIT-MC
cc: griss at UTAH-20, lepreau at UTAH-20, crossland at UTAH-20, thomas at UTAH-20
Confirming what Mike said, I talked to Dave Rodgers at NCC. At the NCC
DEC had a VERY prototype ethernet interface. It was bread boarded, was
not a DMA (NPR) device, and was not even prototypical of the control
register structure they eventually plan on using.
The only real ethernet "product" at the show was an Intel multibus interface,
which meets the full spec (does data link layer on the board). It is a two
board set, and is designed to conform to the eventual architecture of the
VLSI chip set (the current product is a MSI implementation using off the
shelf communications controller chips). Delivery is scheduled for fourth
quarter, with pricing about $4K.
Dave Rodgers of DEC did say that it is DEC's policy to make available the
print set for the current prototype (the one mentioned above) to universities
who want to use it to design their own 10MB ethernet interfaces. How useful
it would be, especially since it's not a NPR device, is questionable.
There are, of course, the rumors about a 3-COM 10MB Unibus ethernet interface
to be available in the not too distant future...
Randy
-------
18-May-81 10:16:47-EDT,690;000000000000
Mail from MIT-MC rcvd at 18-May-81 1016-EDT
Date: 18 May 1981 0639-EDT
From: JIS at MIT-XX
Subject: I am hacking with ORION
To: Wallace at MIT-XX
cc: Twenex-Wizards at MIT-MC
To allow people with the CIA bit to run it. I am putting this
change in so that we can give this bit out to TA's so they
can unwedge our line printers. If I here any objections I
will put this under an EE only conditional, but I would
rather not put this site dependance in if it isn't truely
necessary. I will probably be hacking with this stuff in the
near future so as to get a workable version of the galaxy
stuff working at EE, ours is really broken for the most part...
-Jeff
-------
18-May-81 12:56:08-EDT,1164;000000000000
Mail from SU-SCORE rcvd at 18-May-81 1256-EDT
Mail-from: ARPANET site MIT-XX rcvd at 17-May-81 1018-PDT
Date: 17 May 1981 1300-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Power fail
To: admin.mrc at SU-SCORE
Remailed-date: 18 May 1981 0947-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
Remail as deemed appropriate:
During the past few days we've been having thunder storms and power glitches.
There are at least 2 problems with TOPS-20's power fail restart logic:
- If the power goes off for anything more than a few seconds (I guess)
it might as well not try to do the power fail restart logic if
you have any MOS memory. Its really pitiful to see it grope
its way back to consciousness only to find scrambled bits.
I guess it makes it as far as its does only because we have
256K core.
- When a power fail restart does succeed, the remote lines don't get
reset right and you have to crash the FE to get things
straightened out.
Anyone got any quick fixes for such problems?
-- Nat Mishkin
Yale Computer Science Dept.
-------
26-May-81 20:36:43-EDT,582;000000000000
Mail from SU-SCORE rcvd at 26-May-81 2036-EDT
Mail-from: ARPANET site RAND-AI rcvd at 26-May-81 1700-PDT
Date: 26 May 1981 1658-PDT
From: Jim Guyton <Guyton at RAND-AI>
Subject: Twenex RS232 Flow Control
To: Admin.MRC at SU-SCORE
cc: Guyton at RAND-AI
Remailed-date: 26 May 1981 1731-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
Hi,
Do you know offhand if the standard twenex tty drivers are set up
to handle the Clear-To-Send lines on the RS232 connections for
flow control?
Thanks,
Jim
-------
27-May-81 14:24:42-EDT,1380;000000000001
Mail from SU-SCORE rcvd at 27-May-81 1424-EDT
Date: 27 May 1981 1118-PDT
From: Frank da Cruz <G.DACRUZ at SU-SCORE>
Subject: Short flame about RSX20F
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
I understand that at DECUS, DEC said they would not consider letting sites
configure RSX20F to provide more TTY buffer space at the expense of
unnecessary device support, because buffer space is not a problem any more.
Well, maybe that's true in Marlboro where everybody has XON/XOFFing terminals
(like DEC wants us to have). Or maybe they figure that just because the
front end doesn't crash with buffer allocation errors as much as it used to
that everyone is happy. In fact, there have always been, and always will be,
requirements for high speed - or at least continuous - input from TTY lines,
and the present technique of periodically turning off such lines may well
prevent crashes, but it doesn't let us get our data in. To my knowledge,
most other DEC systems (PDP-11's and VAXes) don't have this problem -- nobody
has ever noticed these machines crashing when you read from a floppy disk,
or connect another computer, via TTY line. I don't think RSX20F would be
setting our line speeds to 0 if buffers were not a problem. Maybe the
problem will go away in version 14 (we still haven't received the field test).
- Frank da Cruz, Columbia U.
-------
27-May-81 18:46:00-EDT,2461;000000000000
Mail from SU-SCORE rcvd at 27-May-81 1845-EDT
Mail-from: ARPANET site RUTGERS rcvd at 15-May-81 1539-PDT
Date: 15 May 1981 1300-EDT
From: HEDRICK at RUTGERS
Subject: distribution of mail outside the arpanet
To: admin.mrc at SU-SCORE
Remailed-date: 27 May 1981 1543-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
I am not quite sure who to send this to. What I would really like is to
reach system managers on the net. But since I mostly deal with DEC-20
sites, this seems like a reasonable approximation.
Apparently my communications have a way of propagating what I intended.
It is unclear to me whether this is appropriate or not. I would like to
be able to use our bulletin board to make somewhat editorial comments to
my users. E.g. when I come back from a conference, they expect to find
out what I thought about it. They also expect to hear what is going on
with our hardware. It is fairly clear that the tone of these comments
might be different in this case than if I were writing an article to be
distributed in a national magazine. At the moment, however, I have
gotten enough feedback from people concerned that I am having to write
all messages to BBOARD as if the whole world was going to read them.
QLt is more alarming, apparently the way to reach the top level
management of a certain vendor (please don't make unwarranted
assumptions - I am not talking about DEC) is to respond to a request for
information about a product from a user elsewhere on the Arpanet. I
would like to believe that I can respond to such requests without having
to worry that I am going to find a marketing person calling on my boss
to complain about what I said. (Yes, that actually happened.)
I'm not sure what I expect all of you to do about this. Possibly just
be a bit careful about redistributing messages. I would consider it
polite to get the author's permission before distributing something,
even if it was made public on the author's system. Certainly private
communication should not be distributed without permission. However at
the moment I guess I am going to have to write all BBOARD notices as if
they were going to be published in Computerworld, and only give candid
evaluations of products to people that I know. (Another alternative
would be to request that the person involved call me, so there was
nothing in writing.)
-------
27-May-81 18:51:53-EDT,1645;000000000000
Mail from SU-SCORE rcvd at 27-May-81 1851-EDT
Mail-from: ARPANET site BBNG rcvd at 15-May-81 0427-PDT
Date: 15 May 1981 0723-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Possible Bug
To: Admin.MRC at SU-SCORE
Remailed-date: 27 May 1981 1549-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
Mark,
I've noticed what looks to me like a fairly noxious bug,
if fact it looks so bad that I can't really believe it's there.
Would you check me on this?
In the TTY and DTE code there are a lot of CHNOFF/CHNON DLSCHN
pair. They seem to occur (at least a couple I traced all the way
back) in normal process context, not NOSKED. It seems to me that this
means that the process can get descheduled in between.
a) That leaves the channel off for an arbitrarily long length of time and
b) The channel probably gets turned back on by a different process
(since CHNOFF's aren't additive, another process going through a
CHNOFF/CHNON pair leaves the channel on) so the original process is
unprotected when it finally resumes.
Is this actually true?
The worst thing is: DLSCHN happens to be channel 6, the same channel
everything else (IMP's disks etc) is on.
Dan
-------
Mail-from: ARPANET site BBND rcvd at 15-May-81 0648-PDT
Date: 15 May 1981 0948-EDT
From: TAPPAN at BBND (Dan Tappan)
Subject: Re: Possible Bug
To: Admin.MRC at SCORE
Hmmm, On second look the bug may not be as widespread as I thought,
most of the instances do seem to go NOSKED. The one I saw first, however,
(In TTYDEA) doesn't, so that may be an isolated bug.
Dan
-------
27-May-81 19:12:58-EDT,723;000000000000
Mail from SU-SCORE rcvd at 27-May-81 1912-EDT
Date: 27 May 1981 1607-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: a personal note
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
Friends -
I would like to take a moment away from bug fixing and
folklore for a personal note. Yesterday afternoon at 3:14PM Lynn
Gold and I were married in a private civil ceremony in San Jose.
Lynn's a former English major who got hooked on DEC-20's about a
year ago. We met, believe it or not, as a result of an MM bug
report (don't ask).
Some good things do happen on these 'puters!
-- Mark --
-------
28-May-81 14:03:21-EDT,1156;000000000001
Mail from SU-SCORE rcvd at 28-May-81 1403-EDT
Date: 28 May 1981 1101-PDT
From: Ted Markowitz <G.TJM>
Subject: Re: Short flame about RSX20F
To: G.DACRUZ, admin.mrc
cc: G.TJM
In-Reply-To: Your message of 27-May-81 1121-PDT
Remailed-date: 28 May 1981 1102-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
I would like to pour some gasoline on the RSX20F flame by Frank da Cruz.
I'm in the process of hooking two -20's together via TTY lines for simple-
minded FTPing (the cable is only ~ 10 feet long). It's inconceivable to
me that I can't move the data throught this "CheapNet" at a speed of more than
300 baud with either front-end crashes or horrible data lossage.
DEC never seemed to take into account anything hanging off the end of a TTY
port other than a medium-speed typist. If they really have solved the buffering
problem, then why is this still a reality? I can only hope that FDC's test
RSX20F shows some improvement. Perhaps DEC doesn't really see this as a problem
area or perhaps Marketing is currently pushing DN20's? I wonder...
--Ted Markowitz
-------
29-May-81 14:37:13-EDT,1452;000000000000
Mail from SU-SCORE rcvd at 29-May-81 1437-EDT
Date: 29 May 1981 1111-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: hung job folklore
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
Have you ever had the bug where a job is looping through its
address space with no pages mapped, getting lots of illegal instruction
PSIs, chomping up the CPU, no JFNs, one fork, and impossible to log
out? The job is trying to log out, but it is stuck in this losing state.
LOTS and Columbia seem to have it happen a lot to them. It happened to
SCORE just a few minutes ago.
I successfully backed out of the state by doing the following: I
modified ITR2+n (before the JRST MRETN) to see if the fork was the losing
fork. If so, I replaced UPDL/UPDL+1 and UPDL+2/UPDL+3 with an exec mode
PC/flags doubleword to go to FLOGO. I got an OPOPAC bug halt, which I
backed out of by AOS CX,ACBAS and starting at MRETN1+12 (right before
the XCT OPOPAC). I suspect that it would work to AOS ACBAS when you
stomp on the UPDL return PC/flags doubleword; if you don't have EDDT
loaded you'd probably have to do this!
I still don't know why the bug happens, but having a way to back
out of the losing state is sure helpful. Have any of the DEC folks
seen this condition and/or have any idea why it has happened?
-- Mark --
-------
29-May-81 14:46:21-EDT,1394;000000000001
Mail from SU-SCORE rcvd at 29-May-81 1446-EDT
Mail-from: ARPANET site RUTGERS rcvd at 29-May-81 1013-PDT
Date: 29 May 1981 1312-EDT
From: HEDRICK at RUTGERS
Subject: DECUS menu items
To: admin.mrc at SU-SCORE
cc: ricart at RUTGERS
Remailed-date: 29 May 1981 1112-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.92: ;
Somehow we seem to have missed one possible MENU item at the last DECUS.
At least I didn't hear it addressed. I conjecture this is because there
was no session at which it would have been appropriate. That is making
RSX-20F understand high-speed input. I propose to get a number of sites
to petition DECUS to add that to the list of MENU items retroactively.
If it is not possible, then I propose to issue a joint letter signed by
as many system administrators as possible, to Rose Ann, with a copy to
At Large. I am getting tired of DEC saying that they only support slow
typists, and that all problems are solved in the next release. Would you
please send this to the Tops-20 distribution list. I would appreciate
hearing from any DECUS Installation Delegates who would be willing to
endorse a letter asking that this be added retroactively to the MENU,
and any system administrators who would be willing to sign such a letter
directly to DEC. Please send me a U.S. Mail address.
-------
29-May-81 18:24:11-EDT,1308;000000000001
Mail from SU-SCORE rcvd at 29-May-81 1824-EDT
Mail-from: ARPANET site RUTGERS rcvd at 29-May-81 1013-PDT
Date: 29 May 1981 1302-EDT
From: hemphill@rutgers <RGSMITH.HEMPHILL at RUTGERS>
Subject: Data transfer over async. Lines.
To: ADMIN.MRC at SU-SCORE
cc: RGSMITH.HEMPHILL at RUTGERS
Remailed-date: 29 May 1981 1515-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.93: ;
We at DREA are currently using a standard TTY line to communicate
with an 11/60 running RSX11-M. The main clue seems to be to use the
line in a half duplex fashion ie. each block of data requires a confirmation
before the next is sent. We have developed a simple protocal for
transfering 8-bit data in both directions (with the line speeds set to
9600 baud) and to date have not had any problems with front end crashes.
The effective throughput rate depends (of course) on the 20 load but
we find that under low load averages it is about 5600 baud dropping
to about 500 baud at a load of 6 (we currently are running a 2050 with
5 M of memory). We will be happy to send a copy of the protocal to
anyone interested but that is about the best we can do till we actually
get on the net. By the way the 20 end of the program is written in
SAIL.
-------
31-May-81 14:45:17-EDT,2416;000000000000
Mail from SU-SCORE rcvd at 31-May-81 1445-EDT
Mail-from: ARPANET site MIT-XX rcvd at 31-May-81 0818-PDT
Date: 31 May 1981 1120-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Re: hung job folklore
To: Admin.MRC at SU-SCORE
Remailed-date: 31 May 1981 1140-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.94: ;
I've got an idea about your problem. I've had the same one several
times. My theory is that the EXEC (or whoever happens to be at the
top level) has somehow gotten trashed but it still has "illegal instr
trap" enabled; unfortunately the illegal instr trap routine is also
trashed. Maybe there's something preventing an infinite loop on this
situation...but I'm not sure.
In any case, the way I stop this kind of job is by patching in a HALTF
instream in mon context which will get executed only by the offending
fork. Recently, I've also used the following technique:
- map the fork's PSB and JSB into a user context which has
MONITR.EXE in it (this is a DEC hack written up in one
of their SWSKIT documents; I can provide it if necessary).
- Move a HALTF into UAC+1 (user context AC 1).
- Change UPDL (base of mon context stk; user mode return addr)
to contain 0; the next time the fork enters user context,
it'll execute the HALTF. This step may have to be repeated
a few times since the fork may have been in user context
when you changed UPDL.
Great hack, eh? Of course this only halts the fork...you still can't
log it out...but at least it isn't swamping your machine. This
technique is preferable to the instream patch since you don't have to
go modifying monitor code on the fly (always a dangerous proposition).
By the way...I'm in the process of writing up some of this folklore.
The document will contain all this kind of junk one picks up from
poking the monitor. It starts with a description of what user/mon
context is and how JSYSes work. It will contain procatical info about
E/MDDT and how you can tweak the monitor on the fly. Has anyone else
ever worked on such a document?
Unfortunately, the documentation is on my non-ARPA machine at Yale.
If there is sufficient interest, I can mail a tape to someone on the
net. Yale may be on the net in the fall anyway (don't hold your
breath though).
-- Nat Mishkin
Yale CS Department
-------
1-Jun-81 12:45:07-EDT,2298;000000000001
Mail from SU-SCORE rcvd at 1-Jun-81 1245-EDT
Mail-from: ARPANET site RUTGERS rcvd at 31-May-81 1253-PDT
Date: Sunday, 31 May 1981 15:52-EDT
From: Jonathan Alan Solomon <SOLOMON at RUTGERS>
To: Nat Mishkin <NWM at MIT-XX>
Cc: Admin.MRC at SU-SCORE, Solomon at RUTGERS
Subject: hung job folklore
Remailed-date: 1 Jun 1981 0937-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.94: ;
Hmm.. We have those types of jobs all the time. What I do is pretty simple
and most of the time works (save one bugchk).
Get into SYSDPY and find out what the monitor thinks the fork's number is.
Then go into MDDT:
FFF/CAIN FX,Fork-number
FFF+1/RET
FFF+2/JRST GOCONC
and the clincher:
RTG2+3/JRST FFF <cr> to crash the system or be fine...
BUGCHK ....
[Phew]
Actually it works fine every time, though the monitor doesnt
expect you to tell the scheduler not to schedule this fork in quite
this way.
Occasionally we get two or three of them, in which case we do
the CAIN/CAIE jumps to stop both of them, *or* treat them specifically
(if three or more, for example) (in other words, dont JRST GOCONC
until you have stopped all the offending forks). Im sure there are
better ways to do it, but We have left these hung jobs on the system
for two weeks or so and it has not effected system performance in the
least (though NBAL and NRUN are off by the number of hung forks we
have).
The biggest problem we have in doing this is if we leave the
jobs detached our Exec offers them to unsuspecting users to attach to
(when you log in we prefer you attach to your detached jobs so we made
it convenient for you to do so). Therefore I usually put them on a PTY
(its the not logged in jobs that are hardest to put on a pty). They
look funny in the finger listing (Tee hee).
Oh, a fairly reproducable way to hang yourself this way is to
use MRC's TELNET to open a connection to your controlling terminal,
then type a ^C or two and then a ^^C (control-uparrow C to close the
connection). The fork gets stuck in CLOSF and then when you log the
job out you get a single fork hung job chomping on the CPU (im sure
thats not the only way to do it).
Cheers,
JSol
1-Jun-81 12:59:15-EDT,2467;000000000000
Mail from SU-SCORE rcvd at 1-Jun-81 1259-EDT
Mail-from: ARPANET site CMU-20C rcvd at 31-May-81 1754-PDT
Date: 31 May 1981 2048-EDT
From: WOHL at CMU-20C
Subject: Hung jobs.
To: Admin.MRC at SU-SCORE
Remailed-date: 1 Jun 1981 0951-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.95: ;
How to nuke such a job:
FFF/ SETO 1,
/ LGOUT% (or WAIT% to just make it quite down).
/ erjmp .+1
/ jrst jtenqe+2
ILUUO+1/ JRST FFF
You may wish to check the job or fork number.
The reason the problem happens seems to be do to a combination of the
following two problems:
1) When a job gets a carrior-off psi, in SCHED at PIRLG1+1 there is a
MOVE T2,PIFL to pick up the current flags. But the new flags are not
set so the carrior off psi (or remote logout psi!) is handled in the
current mode. This causes the top fork to sometimes jump to the JOBCOF
or FLOGO address in the USER context of the top fork... To fix the problem:
Replace the MOVE T2,PIFL with
SETZ T2, ;Handle in monitor mode please.
EXCH T2,PIFL ;Get current, set new.
To test the fix, go into PTYCON and log in a job, go into EDDT on its top
fork and have it loop doing a JRST . (so it is running in user mode).
Then push from ptycon and do a logout on the job. Before putting in the fix
you will get a ?internal illegal instruction at PC=FLOGO+1, after the fix
the job should logout (as soon as you let it type out its bye message).
2) The other problem is in LGOUT%. It clears out the address space of the top
fork and then does a bunch of terminal IO to print the 'Killed usage
mumble mumble' message. Most of the SOUT%'s, NOUT%'s and the final DOBE%
for this IO don't have ERJMP's after them. So if you have a job on a NVT or
PTY with an almost full output buffer, it will hang waiting at the DOBE%
or a earler. Now if a carrier-off psi comes in due to the other end being
closed, the DOBE% (or SOUT%) will generate an illegal instruction and try
to go back to the user who, at this time doesn't have pages in his top
fork anymore....
If after the DOBE% just before LOG2 (in MEXEC) you put a ERJMP LOG2 it
helps alot as that is where the problem usualy happens. The printing of
the 'Killed used mumble mumble' is spread all over the place and isn't
so easy to fix.
Aaron Wohl
WOHL@CMU-20C
-------
2-Jun-81 23:05:17-EDT,1762;000000000000
Mail from SU-SCORE rcvd at 2-Jun-81 2305-EDT
Mail-from: ARPANET site BBNG rcvd at 2-Jun-81 1441-PDT
Date: 2 Jun 1981 1741-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Ultra-Cheap DN20
To: Admin.MRC at SU-SCORE
Remailed-date: 2 Jun 1981 1944-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.96: ;
Mark, forward as you see fit.
It is possible, if one is willing to do some extra software work,
to do the Erector Set DN20 one better, and build an ultra-cheap
front end for a KL. For host interfaces on our local network we've
done this by using an LSI11 as the front end, and the result is
surprisingly usable. The cost is approximately 1/2 - 2/3 that of
even the cheapest DN20.
LSI11/03, CPU, Backplane, memory,DLV11J ~5K
(11/23 ~7K)
Plessy QBUS->Unibus converter ~.5K
DTE ~2.5K
Total 8-10K
(Plus, of course, the cost of whatever devices you put on the
thing).
In our case this is acting as a simple Internet gateway. I've
done some throughput measurements, with as little KL participation
as possible. With an 11/03 throughput ranges from 47KB (40 byte
packets) to 155KB (512 byte packets). With an 11/23 that goes from
77KB (40 bytes) to 164KB (512 bytes).
If the KL is required to do any processing then throughput drops
precipitously (not surprisingly, since this was done on a memory
bound 256K machine), so these speeds are easily sufficient to swamp
it.
All in all, if the application is such that the '11 isn't required
to do a lot of work, then it isn't really necessary to go all the
way to an 11/34 (it seems to me that this throughput would be easily
enough to drive several LPT's or what-have-you).
Dan
-------
3-Jun-81 18:23:59-EDT,1100;000000000000
Mail from SU-SCORE rcvd at 3-Jun-81 1823-EDT
Mail-from: ARPANET site DEC-2136 rcvd at 3-Jun-81 1453-PDT
Date: 3 Jun 1981 1753-EDT
From: PAETZOLD at DEC-2136
To: admin.mrc at SU-SCORE
Subject: DEC-2136 Release 5 ARPANET Test System
Message-ID: <MS"5(1646)"11733280310.2.16.96571 at DEC-2136>
Remailed-date: 3 Jun 1981 1518-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.96: ;
Mark: Please forward this to the TOPS-20 list and any other lists
that seem appropiate.
We have built a test system for TOPS-20AN release five. This
system will be running on arpanet host DEC-2136. We encourage all
people involved with TOPS-20AN to login and help us test out the
release 5 arpanet software. The guest account at DEC-2136 is "G"
and the password is "G". The guest account has the ability to create
subdirectories for personal use. We will try to have this system up
for several hours a day starting at 5PM EDT. For other policy matters
see the file [DEC-2136]<SUBSYS>POLICY.HLP.
Kevin Paetzold
--------
5-Jun-81 03:44:28-EDT,1408;000000000000
Mail from SU-SCORE rcvd at 5-Jun-81 0344-EDT
Date: 4 Jun 1981 2325-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: new MM/FINGER interaction
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.96: ;, Admin.MDP at SU-SCORE,
MMcM at MIT-AI
I wish to enhance MM to obtain the personal name from the FINGER
database if it was not supplied by the user in the PERSONAL-NAME field
of her MM.INIT file. Since there are at least three implementations
of FINGER for TOPS-20 (Cerberus in its many dialects, SCORE FINGER, and
LOTS FINGER), I felt it advisable not to try to make MM read the database
itself.
I would therefore like to define a new entry point to FINGER. Entry
vector offset 4 (right after the version) is defined to be the personal
name server. MM will ignore a FINGER which doesn't have this entry point.
If supplied, MM will pass FINGER the user name in the rescan buffer, and
then will start FINGER at that point. When FINGER returns, it should
leave the personal name in the rescan buffer. If the lookup fails for
any reason FINGER should clear the rescan buffer.
This change will not happen in MM immediately, but we'd like to do
it here pretty soon; we have other applications which would like to use
this functionality in FINGER.
-- Mark --
-------
5-Jun-81 04:17:46-EDT,3145;000000000000
Mail from SU-SCORE rcvd at 5-Jun-81 0417-EDT
Mail-from: ARPANET site RUTGERS rcvd at 5-Jun-81 0107-PDT
Date: 5 Jun 1981 0408-EDT
From: HEDRICK at RUTGERS
Subject: fun and games with FOO.DIRECTORY.2
To: admin.mrc at SU-SCORE
cc: remarks at RUTGERS
Remailed-date: 5 Jun 1981 0112-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.96: ;
One of my staff decided to create a file FOO.DIRECTORY.2 on his
directory. He already had a FOO.DIRECTORY.1, which was a real
directory. .2 was a normal file. Suddenly CHECKD started failing
mysteriously if you answered Run CHECKD? with Y in the startup dialog.
By failing I mean that it didn't print the usual message about the
number of pages before and after CHECKD. No error messages either.
The system just went ahead and loaded. It turns out that this case
has turned up 3 separate bugs:
- CHECKD finds all the directories by doing a wild-card RCDIR. Given a
directory number it does DIRST to get the directory name, and
then manufactures the file name, e.g. <FOO>BAR.DIRECTORY. It
then does a GTJFN on this filename. The monitor has somewhat
similar code for looking up directory files. However when they
get around to the GTJFN, the monitor specifies version one in
the right half of the flag word. CHECKD neglects this. Thus in
the case mentioned above, CHECKD gets version 2 of the file.
This causes two ill effects: (1) it fails to read the directory
file, thus in principle causing all pages in it to be
garbage-collected; (2) it reads a file that is not a directory,
causing it to blow up.
- CHECKD is not sufficiently paranoid about the format of directory
files. If page 0 is missing, it gets an ill mem read trying to
look at it, and blows up.
- The monitor does not bother to see how CHECKD terminates. If CHECKD
blows up, e.g. with an ill mem read, the monitor happily
proceeds on its way, without even printing an error message. I
have not looked at the code, but conjecture that it is the usual
CFORK; GET; START; WFORK; proceed on merry way.
The first two bugs are fixed in the following FILCOM. I have not
fixed the monitor problem. I regard this as a fairly important
fix, since users could corrupt the disk system by creating .DIRECTORY
files, causing pages from active subdirectories to be returned to the
free list.
File 1) DSK:CHECKD.MAC[4,211] created: 0252 05-Jun-1981
File 2) DSK:CHECKD.DEC[4,211] created: 1524 03-Jan-1980
**************
1)62 GTFIL3: MOVX T1,GJ%PHY!GJ%SHT!1 ;[2] PHYSICAL ONLY, SHORT BLOCK
1) GTJFN ;GET A JFN
****
2)62 GTFIL3: MOVX T1,GJ%PHY!GJ%SHT ;PHYSICAL ONLY, SHORT BLOCK
2) GTJFN ;GET A JFN
**************
1)85 DR0CHK: MOVE T4,DIRORA ;GET BASE ADR OF MAPPED DIR AREA
1) LOAD T2,DRNUM,(T4) ;GET DIR NUMBER
1) ERJMP DR0CHB ;[2] error if page missing
1) CAME T1,T2 ;DO THE DIRECTORY NUMBERS MATCH?
****
2)85 DR0CHK: MOVE T4,DIRORA ;GET BASE ADR OF MAPPED DIR AREA
2) LOAD T2,DRNUM,(T4) ;GET DIR NUMBER
2) CAME T1,T2 ;DO THE DIRECTORY NUMBERS MATCH?
**************
-------
5-Jun-81 15:36:42-EDT,1098;000000000000
Mail from SU-SCORE rcvd at 5-Jun-81 1536-EDT
Mail-from: ARPANET site MIT-XX rcvd at 5-Jun-81 1213-PDT
Date: 5 Jun 1981 1217-EDT
From: Ted Markowitz <TJM at MIT-XX>
Reply-To: g.tjm@score
Subject: Lost MTA's
To: admin.mrc at SU-SCORE
Remailed-date: 5 Jun 1981 1228-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.96: ;
Has anyone had the experience of losing control of a tape drive in the
following situation?
1) Tapes are not allocated to the system, but can be assigned
directly by the users.
2) A drive is controlled by Job 0 somehow, but not allocated to MOUNTR.
3) Turning the controller off and on (usually a brutal but effective
way of getting the Monitor to notice the device) has no effect at all.
I haven't been able to figure out how Job 0 has a hold on this device. Killing
and restarting MOUNTR (even reloading SYSJOB entirely) has no effect. The drive
has now become totally unusable. SYSDPY reports that no one has a handle on the
device at all.
Thanks for any help.
--ted
-------
6-Jun-81 13:37:37-EDT,604;000000000000
Mail from SU-SCORE rcvd at 6-Jun-81 1337-EDT
Mail-from: ARPANET site RUTGERS rcvd at 5-Jun-81 1513-PDT
Date: 5 Jun 1981 1803-EDT
From: HEDRICK at RUTGERS
Subject: Re: Lost MTA's
To: g.tjm at SU-SCORE
cc: admin.mrc at SU-SCORE
In-Reply-To: Your message of 5-Jun-81 1217-EDT
Remailed-date: 6 Jun 1981 1029-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.96: ;
Yes, this happens all the time. To fix it, write a short program
that does the deassign JSYS on the tape drive. Save it as an
EXE file, and run it with ^E SPEAK.
-------
8-Jun-81 12:22:41-EDT,910;000000000000
Mail from SU-SCORE rcvd at 8-Jun-81 1222-EDT
Date: 8 Jun 1981 0919-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: [Ted Markowitz <G.TJM>: TTY "remoteness"]
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.97: ;
DEC says that it would be very hard to implement, and also has expressed
surprise that anybody would want to do this. -- MRC
---------------
Date: 8 Jun 1981 0846-PDT
From: Ted Markowitz <G.TJM>
Subject: TTY "remoteness"
To: admin.mrc
Has anyone ever noticed that you can't "unremote" a line that's been
set that way at boot time? There doesn't seem to be a JSYS function
that can make it happen. Runnning SETSPD doesn't do the trick as you'd
expect. Perhaps a MONITOR poker has some lore on the subject?
--ted
-------
---------------
-------
12-Jun-81 17:45:08-EDT,1826;000000000000
Mail from SU-SCORE rcvd at 12-Jun-81 1745-EDT
Mail-from: ARPANET site USC-ECLB-IPI rcvd at 10-Jun-81 1103-PDT
Mail from USC-ECLB-IPI rcvd at 10-Jun-81 1007-PDT
Date: 10 Jun 1981 0839-PDT
From: BALLENTINE at USC-ECLB-IPI
Subject: Extended addressing hardware bug
To: mark at ECLB
cc: belmont
Remailed-date: 10 Jun 1981 1103-PDT
Remailed-from: Mark Thompson <THOMPSON at USC-ECLB-IPI>
Remailed-to: Admin.MRC at SU-SCORE
Remailed-date: 11 Jun 1981 2022-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.97: ;
An interesting microcode bug we've found that you may want to pass on
to DEC. It's a combination of MOVSLJ and extended addressing (I'm sure
you love to hear about these!).
It appears that MOVSLJ doesn't respect the local byte pointer
convention if running in other than section 1. If a byte pointer is
not global, it uses section 0 regardless of the section it's running
in. The example I found that doesn't work:
AC7 has a global address. I want to move from that address to a local
address within my section (I'm running in section 1)
movei 1,10 ; size of source
move 2,[point 36,(7)] ; source bp
movei 4,10 ; destination size
move 5,[point 7,fname] ; destination bp
extend 1,[movslj
0 ]
:
:
fname: block ..
This picks up the correct information, but moves it to 0,,fname
(rather that 1,,fname). The local bp [point 7,fname] should use the
current section.
We got around this problem by using a global bp there. I wish I had
more time to test this a bit further, but the project I'm on (DARPA
Ada) is keeping us all too busy. Call if you'd like.
Mike Ballentine
Intermetrics, Inc.
(617) 661-1840 x2386
3 hours behind you in Massachusetts
-------
13-Jun-81 05:53:27-EDT,1595;000000000000
Mail from SU-SCORE rcvd at 13-Jun-81 0553-EDT
Mail-from: ARPANET site RUTGERS rcvd at 12-Jun-81 1710-PDT
Date: 12 Jun 1981 2000-EDT
From: HEDRICK at RUTGERS
Subject: FLKTIM/FLKNS problem due to extended addressing
To: admin.mrc at SU-SCORE
Remailed-date: 12 Jun 1981 2208-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.97: ;
Problem: If you are using extended addressing, ^C out of the program,
and do anything that would trigger a KFORK on the program,
then do something else that would try to get a fork lock, your
job will be hung until you get FLOCK time out. For example,
^C'ing and running another program triggers this, since
running another program KFORK's the old and does a GET into
a new fork.
Diagnosis: Coding error in FLOCK causes an AC to be garbaged.
Cure:
FLOCK::
REPEAT 0,< ;NOT CHECKED NOW BECAUSE MLKBLK PROBLEM
SKIPN FORKN ;TOP FORK?
JRST FLOCK1 ;YES, INTERRUPTIBILITY NOT SIGNIFICANT
SKIPL INTDF ;INTERRUPTABLE NOW?
BUG(FLKINT)
>
ACVAR <W1,W2> ;[163]
SETZM W2 ;[163] INDICATE NESTING NOT ALLOWED
JRST FLOCK1
;HERE TO ALLOW NESTING OF THE LOCK
FLOCKN::ACVAR <W1,W2> ;[163]
SETOM W2 ;[163] INDICATE NESTING ALLOWED
FLOCK1: CSKED ;BE CRITICAL IF LOCK WORKS
AOSN FKLOCK ;LOCK SUCCESSFUL?
;THE LOCK WAS PREVIOUSLY UNLOCKED. SAVE THIS FORK INDEX AND INCREMENT
;THE NEST COUNT
JRST [ HRR W2,FORKN ;[163] GET OUR JOB-WIDE FORK HANDLE
MOVEM W2,FLKOWN ;[163] SAVE IT AS THE OWNER
SKIPE FLKCNT ;IF NOT ZERO, SOMETHING IS WRONG
-------
17-Jun-81 00:02:33-EDT,689;000000000000
Mail from SU-SCORE rcvd at 17-Jun-81 0002-EDT
Mail-from: ARPANET site BBNG rcvd at 16-Jun-81 1900-PDT
Date: 16 Jun 1981 2200-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Update on Cheap DN20 (for list)
To: Admin.MRC at SU-SCORE
Remailed-date: 16 Jun 1981 2059-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.99: ;
As it turns out, the real limiting factor on throughput through
a DN20 is the DTE. By going to 16 bit transfers over the DTE
(I had originaly used 8 to make things easier for the '11)
I can get throughput through my cheap DN20's on the order of
250KB for an 11/03 or 350KB for an 11/23.
Dan
-------
17-Jun-81 13:02:26-EDT,1162;000000000000
Mail from SU-SCORE rcvd at 17-Jun-81 1302-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 17-Jun-81 0141-PDT
Date: 17 Jun 1981 0341-CDT
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Net lossage
To: admin.mrc at SU-SCORE
Remailed-date: 17 Jun 1981 0954-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.99: ;
Mark, please distribute to the wizards if appropriate (i.e. if you
don't have an answer).
For the second time in about 10 days we have experienced a problem
in which IMPABF BUGINF's start pouring out of the CTY at the rate
of one every couple of seconds. In both cases, the problem occured
late at night, and a few thousand came out before the problem was
discovered. All jobs doing anything with the net simply hang, and
cannot be stopped or logged out. In each case I tried to flush
relevant hosts, etc, but only succeeded in hanging my own job running
TELNET. After trying various other things, I finally gave up,
took a crash dump and reloaded. Everything came up fine.
Has anybody seen this before, and diagnosed it perchance?
Many thanks,
Clive
-------
17-Jun-81 13:44:18-EDT,1645;000000000000
Mail from SU-SCORE rcvd at 17-Jun-81 1344-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 17-Jun-81 1032-PDT
Date: 17 Jun 1981 1030-PDT
From: Sweer at SUMEX-AIM
Subject: Re: Net lossage
To: CC.Clive at UTEXAS-20
cc: Admin.MRC at SU-SCORE, Sweer at SUMEX-AIM
Remailed-date: 17 Jun 1981 1037-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.99: ;
In response to your message sent 17 Jun 1981 1004-PDT
It appears to me that the IMPABF bug messages in TOPS20 are a direct
decendant of the ASNTBF Failure bug messages that have plagued Tenex
over the years. I'm not sure exactly how TOPS20 handles this but I
can offer some lore from Tenex. The problem starts because ASNTBF
can't find a buffer for output, perhaps because they are all used
up for input messages. Tenex has tried 2 approaches to this. First
you can define a low water mark of a number of buffers below which
no more buffers will be assigned for input. This requires isolating
the calls to ASNTBF for input and output. Secondly, if it is not
already there, you should put a check to see if the running fork
owns NCPLCK, and if so allow it to assign the buffer anyway, assuming
there are any.
It is also possible that ASNTBF fails because the buffer linkage is
screwed up somehow. If this is the case you're in deep yogurt. No
ammount of MDDT'ing has ever allowed us to successfully back out
of this condition. If you try to relink the buffers on a live system
you inevitably run into another more serious BUGHLT due to the fact
that some fork still thinks it owns a given buffer.
Andy
-------
17-Jun-81 16:11:55-EDT,2107;000000000000
Mail from SU-SCORE rcvd at 17-Jun-81 1611-EDT
Mail-from: ARPANET site SRI-KL rcvd at 17-Jun-81 1123-PDT
Date: 17 Jun 1981 1109-PDT
From: LARSON at SRI-KL
Subject: re: Net lossage
To: CC.Clive at UTEXAS-20, Admin.MRC at SU-SCORE
Remailed-date: 17 Jun 1981 1304-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.99: ;
Yes, I have seen it before. It is caused by the ASNTBF (assign net
buffer) routine failing. This routine prints the buginf, then DISMS's
for 5 seconds, then tries again (forever). Sadly, it is entered with
one of the network locks set, and nobody can get in to release any of
the used buffers, so you generally remain hung (again, forever).
You can recover without crashing the system most of the time, with a
little magic in MDDT. Here is how.
1. Turn the net off. Either with the ^Eset command, or by
setting the monitor location NETON to 0.
2. Examine the cells (in octal) starting at NETFRE. NETFRE+2
will be the number of free words of net buffer space. The
others are good to learn about (but not essential here).
3. Set the content of ASNTHR to 1/2 it's present value, but
not below 2000. (If it is already below 4000, you are
configured very wrong.) Note: ASNTHR is normally the first
word after the NETFRE array (NETFRE+5).
4. Look at NETFRE+2 again, as soon as it starts to rise again,
reset ASNTHR. Do not leave the changed value in ASNTHR,
the extra buffer space gained will not prevent the problem
happening again. If you do not reset ASNTHR, when you have
the same problem happen again, you will not have enough free
buffer space reserved to unwedge yourself.
5. When all seems to be normal again, turn the net back on.
I have not discovered why the net seems to run out of net buffers so often.
Increasing the size of the buffer area helped a little, but did not really
fix the problem. I suspect that something is going wild and grabbing them
up, but have not proved it yet.
Alan Larson
-------
17-Jun-81 16:20:52-EDT,1856;000000000000
Mail from SU-SCORE rcvd at 17-Jun-81 1620-EDT
Mail-from: ARPANET site BBNG rcvd at 17-Jun-81 1136-PDT
Date: 17 Jun 1981 1433-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Re: Net lossage
To: Sweer at SUMEX-AIM
cc: CC.Clive at UTEXAS-20, Admin.MRC at SU-SCORE, Tappan at BBNG
In-Reply-To: Your message of 17-Jun-81 1330-EDT
Remailed-date: 17 Jun 1981 1308-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.99: ;
Both approaches help somewhat, (except that you DON'T want to
limit input buffers, that'll make things worse, the problem is
that the IMP has been holding you off for some reason, so there
are a lot of output buffers queued, stopping input will
just stop your RFNMs from coming in and the problem will get worse,
you want to limit OUTPUT). A major problem is that when the NCP
fork processes an input buffer, it is likely to go ahead and
immediately send out a reply, which causes it to hit the 0 buffer
condition, hang up waiting for a buffer, and make the problem worse
since there is then nothing cleaning things up. Unfortunately there
isn't any way to prevent this without totaly re-writing the code.
The best way I've found to prevent the problem is simply to double
the number of buffers.
On another note, Another reason I've seen for this sort of thing
is that the NCP fork got hung for some other reason. Occasionally
I've seen the NCP fork hung up on either a dynamic data lock
or a SNDALL lock while trying to close down an NVT.
To find out if thats the problem look in NCPFRK for the
fork number, then at FKSTAT+N. if the test is a DISMS (BLOCKW)
then its probably in the buffer deadlock, is its something else
(like TSACT3) you may be able to fix things just by clearing
what it's waiting for and letting it do it's thing.
Dan
-------
17-Jun-81 16:28:43-EDT,1510;000000000000
Mail from SU-SCORE rcvd at 17-Jun-81 1628-EDT
Mail-from: ARPANET site SRI-KL rcvd at 17-Jun-81 1124-PDT
Date: 17 Jun 1981 1121-PDT
From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Re: Net lossage
To: CC.Clive at UTEXAS-20, admin.mrc at SU-SCORE
In-Reply-To: Your message of 17-Jun-81 0141-PDT
Remailed-date: 17 Jun 1981 1315-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.99: ;
Andy's analsis is correct, by the way his check on NCPLCK is not in TOP-20,
but here is some more lore that may be useful.
1) Turn the net off - this avoids hanging more jobs & is nessary for the one
possible fix i know of.
2) Wait for the net to come all the way down.
3) Get into MDDT and check the following values:
a) NETFRE + 2 - the number of free buffers.
b) ASNTBF (=NETFRE + 5) - the limit below which not to allocate new
buffers.
4) If NETFRE + 2 <= ASNTBF then continue , else giveup your buffers are munged.
5) Reduce the value of ASNTBF (try cutting it in half) this will allow the
hung processes to get buffers then fail because the net is off.
6) Wait a min. or so for the hung jobs to free up.
7) Restore ASNTBF to its original value.
8) Turn the net back on.
9) If this is happening offen, consider building a new moitor with a larger
value of NNTBFS (the number of net buffers, defined if STG). We are
currently using NNTBFS =100000, and it seems to work well.
good luck
harris
-------
18-Jun-81 19:19:26-EDT,2166;000000000000
Mail from SU-SCORE rcvd at 18-Jun-81 1919-EDT
Mail-from: ARPANET site DEC-MARLBORO rcvd at 10-Jun-81 1458-PDT
Date: 10 Jun 1981 1756-EDT
From: HALL at DEC-MARLBORO
To: admin.mrc at SU-SCORE
cc: hall at DEC-MARLBORO
Subject: Hung jobs
Message-ID: <MS"5(1631)"11735115866.27.456.3693 at DEC-MARLBORO>
Remailed-date: 18 Jun 1981 1612-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.101: ;
You sent some mail a while ago about jobs that get hung trying to
logout. At the time, I hadn't experienced that, but today we had one.
I had to leave before I could finish investigating, but I did get some
interesting data. While I realize that you're looking for a way out
once the condition has happened -- and I think it would be nice to
generate that -- right now I'd like to know the cause of the problem.
Have you seen this kind of data?
The stack pointer pointed to the top of UPDL (UPDL+3 or so), but on the
stack was some interesting data. There was a DESX2, which means something
like "Terminal not available to this job". There was also a terminal number.
If you looked at JOBPT of this job, its terminal was in fact the one on
the stack.
Unfortunately, if you looked at DEVUNT for that terminal, another job
owned it. And if you looked at JOBPT for that job, it pointed to the
terminal.
Thus one job and a terminal agreed that they belonged to each other, but
the hung job also thought that it belonged to that terminal (or vice
versa). Seems like the classic triangle, almost. Alas, computers have no
heart.
I haven't gone bug-hunting yet, but I'm wondering if something like this
is happening:
Job is in logout
Job deassigns the terminal, thus making TTACTL be -1
Job dismisses for some reason, not necessarily a bug
User pounds on CTRL/C and gets a new job
Old job has the controlling terminal lying around and does a
JSYS on it (like DOBE) even though it already deassigned
it
Old job gets error
I didn't have time to see why it loops, however. Have you figured that out?
Maybe it's trying to type an error message to the terminal!
--------
18-Jun-81 23:19:20-EDT,636;000000000000
Mail from SU-SCORE rcvd at 18-Jun-81 2319-EDT
Mail-from: ARPANET site SRI-KL rcvd at 18-Jun-81 1922-PDT
Date: 18 Jun 1981 1922-PDT
From: ROODE at SRI-KL (David Roode)
Subject: for dist. list
To: Admin.MRC at SU-SCORE
Remailed-date: 18 Jun 1981 1932-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.101: ;
How come, when stepping through the files of a directory with GNJFN,
if I alter the account of some file, further files which have that
account are skipped by that series of GNJFN's? Shouldn't this
be considered a bug?
---------------
-------
19-Jun-81 18:56:09-EDT,1044;000000000000
Mail from SU-SCORE rcvd at 19-Jun-81 1856-EDT
Mail-from: ARPANET site SRI-KL rcvd at 19-Jun-81 0247-PDT
Date: 19 Jun 1981 0244-PDT
From: ROODE at SRI-KL (David Roode)
Subject: more on wildcarding
To: Admin.MRC at SU-SCORE
Remailed-date: 19 Jun 1981 1545-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.102: ;
The exact situation seems to be that if I am stepping through
a file group, and I use the JFN to change the account of
one of the files, the wildcard specification is modified
to specify the particular account to which I changed the file,
so that only files on that account appear.
The problem comes up in the case of a program designed to
verify files' accounts and correct invalid accounts as needed,
since we use the account of the file for disk usage billing.
As soon as one correction is made, this bug masks any
further files needing correction. One might have expected
DEC to provide a utility to handle this aspect of account
validation.
-------
19-Jun-81 19:04:07-EDT,1676;000000000000
Mail from SU-SCORE rcvd at 19-Jun-81 1904-EDT
Mail-from: ARPANET site SRI-KL rcvd at 19-Jun-81 1304-PDT
Date: 19 Jun 1981 0858-PDT
From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Re: for dist. list
To: ROODE at SRI-KL, Admin.MRC at SU-SCORE
In-Reply-To: Your message of 18-Jun-81 1922-PDT
Remailed-date: 19 Jun 1981 1551-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.102: ;
I agree with Dave that this "feature" is probably a bug & at one point
was considering "fixing" it, but when i saw that DEC appeared to have
gone out of their way to get it, I began to wonder it someone might be
depending on it and worked around it rather than fixing it. Here is
a coy of the message I sent to the list about it before.
harris
-------------------------------------------------------------------------------
27-Jun-80 21:02:56-PDT,741;000000000001
Mail-from: ARPAnet host SU-SCORE rcvd at 27-Jun-80 2102-PDT
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
-------
-------
20-Jun-81 00:19:04-EDT,728;000000000000
Mail from SU-SCORE rcvd at 20-Jun-81 0019-EDT
Date: 19 Jun 1981 2113-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: KL UCODE bugs
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.102: ;
DEC is working on the KL microcode. The project is a short
one, but there is some opportunity to get bugs fixed and I am
trying to get together a "short list" of critical UCODE bugs to
pass to DEC. The UCODE bugs that have gone out on TOPS-20.DIS
have apparently already been passed to the UCODE developers.
Please keep the bug reports short and concise. If the demand
seems excessive, we may not get anything done.
-------
26-Jun-81 00:22:54-EDT,1877;000000000000
Mail from SU-SCORE rcvd at 26-Jun-81 0022-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 25-Jun-81 1554-PDT
Date: 25 Jun 1981 1753-CDT
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Swapping space
To: admin.mrc at SU-SCORE
cc: cc.clive at UTEXAS-20
Remailed-date: 25 Jun 1981 2116-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.103: ;
To the Twenex-Wizards:
Our system is running low on swapping space.
The DDMP: SWAPPING SPACE LOW ACTION message is appearing on the CTY
every minute or so during the busy times of the day. We currently have
10,070 pages of swapping space allocated, and I don't know where it's
all going. I have a few questions:
1. Has anybody come up with any good utilities which can give you
an idea of how your swapping space is being used? Right now I
use SYSDPY which gives me the size of everybody's forks, but it's
hard to figure out how much space is shared due to mapped files, etc.
2. I imagine we'll eventually have to reconfigure our PS: and add more
swapping space, but I'm trying to hold off for another month until
some new disk drives arrive. In the meantime, does anybody have any
hints on how to alleviate the situation? In particular, the threshold
for firing up DDMP is 4000 (octal) free pages. Since DDMP seems to
contribute significantly to the system load when it runs, I'm considering
reducing the threshold to 3000 or even 2000. Does anybody know the
effects of this?
3. What is the relation between the programs listed under the "Info
subsystem-statistics" and those that are resident on the swapper?
Are all of those really out there, or does the monitor keep track
of them even if they're not using swapping space.
Many thanks for any help..
Clive
-------
26-Jun-81 20:31:28-EDT,1470;000000000000
Mail from SU-SCORE rcvd at 26-Jun-81 2031-EDT
Mail-from: ARPANET site MIT-XX rcvd at 26-Jun-81 1639-PDT
Date: 26 Jun 1981 1942-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Re: Swapping space
To: CC.Clive at UTEXAS-20
cc: admin.mrc at SU-SCORE
In-Reply-To: Your message of 25-Jun-81 1853-EDT
Remailed-date: 26 Jun 1981 1728-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.103: ;
Two points: first, as to finding where all the swap space is, I have
hacked SYSDPY so that the "mapped pages" column in the fork display
shows the NUMBER of private pages for each fork as opposed to just
the existence of private pages. Normal SYSDPY just shows a "P" in
this column and this gives you no idea as to the number of private
pages. I have actually tracked down "private page hogs" using this
information. It'd tedious but better than nothing.
Second point: I got burned by the fact that when you build a structure
from scratch you can override the default swapping space but the max
the default monitor can handle is the default swapping space (~10000).
I.e. you can make the swap space be, say, 12000 pages but the default
monitor is configured to handle only 10000. You can rebuild the
monitor with the appropriate parameter increased. Now I maybe I
should have known better but I don't recall seeing anything in DEC's
documentation describing this "feature"
-- Nat Mishkin
-------
26-Jun-81 20:35:50-EDT,1324;000000000000
Mail from SU-SCORE rcvd at 26-Jun-81 2035-EDT
Mail-from: ARPANET site SRI-KL rcvd at 26-Jun-81 0920-PDT
Date: 26 Jun 1981 0922-PDT
From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Re: Swapping space
To: CC.Clive at UTEXAS-20, admin.mrc at SU-SCORE
In-Reply-To: Your message of 25-Jun-81 1553-PDT
Remailed-date: 26 Jun 1981 1720-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.103: ;
We have found that for fairly large systems the DEC caculations for
DRMIN0 (when to run DDMP) and DRMLV0 (when to disallow new private pages)
in PAGEM are way too conservative. The following works well for us.
harris
-------------------------------------------------------------------------------
from dec
SETSSP::MOVE B,TOTRC ;PREVENT NEW PRIVATE PAGES
CAIL B,^D1024 ;A VERY LARGE SYSTEM?
MOVEI B,^D1024 ;YES. USE CUTOFF THEN
MOVEM B,DRMLV0 ;WHEN FREE DRUM EQUALS TOTAL CORE
IMULI B,2 ;DOUBLE THAT LEVEL
MOVEM B,DRMIN0 ;TO CAUSE DDMP ACTIVITY
RET
-------------------------------------------------------------------------------
from sri monitor
SETSSP::MOVE B,TOTRC ;5
MOVEM B,DRMIN0 ;5 TO CAUSE DDMP ACTIVITY
ASH B,-1 ;5 PREVENT NEW PRIVATE PAGES
MOVEM B,DRMLV0 ;5 WHEN FREE DRUM EQUALS 1/2 TOTAL CORE
RET
-------
30-Jun-81 02:21:14-EDT,1272;000000000000
Mail from SU-SCORE rcvd at 30-Jun-81 0221-EDT
Mail-from: ARPANET site RUTGERS rcvd at 27-Jun-81 1953-PDT
Date: 27 Jun 1981 2252-EDT
From: Jonathan Alan Solomon <Solomon at RUTGERS>
Subject: Bug in the DEC Exec for release 4.
To: Admin.MRC at SU-SCORE
Remailed-date: 29 Jun 1981 2318-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.103: ;
Problem:
If have a fork that requires SC%CTC, and you ENABLE and
DISABLE above it in the exec, the SC%CTC goes away (and so does
SC%GTB, SC%MMN, SC%LOG, SC%MPP, SC%SDV, and SC%SCT).
Diagnosis:
The code looks like this:
DISAB1+13 (in the vanilla unmodified EXEC)
RPCAP% ;get capabilities
TDZ C,[777B8+777777] ;make them disabled
SKIPE PRVENF ;unless were enabling
MOVE C,B ;then we should enable them
EPCAP
Apparently DEC goes out of its way to make this happen, but it
breaks all kinds of programs (try pushing out of your kept emacs after
doing that), but is not too apparent from the Vanilla Non-multiforking
EXEC (but it CAN be reproduced in that EXEC).
Solution:
Replace the TDZ at DISAB1+14 with a HLLZ C,C would do the
trick for disabling the user caps while leaving the job capabilities
as they were.
Jon
-------
1-Jul-81 04:12:47-EDT,2228;000000000000
Mail from SU-SCORE rcvd at 1-Jul-81 0412-EDT
Date: 1 Jul 1981 0108-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: An interesting SPR and answer
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
Last April 1, A. N. Onymous sent an SPR to DEC as follows:
PROBLEM:
No way to input or output Roman numerals.
DIAGNOSIS:
The NIN% and NOUT% jsi have no code to check for or support
SIXBIT/ROMAN/ in AC3.
SOLUTION:
Allow SIXBIT/ROMAN/ in AC3, and add code to do Roman numeral
I/O when this is specified as the base. This is obviously useless
in many applications.
DEC's reply was:
NIN, FOREIGN LANGUAGES, SMOKE, FIRE AND NOVAS SUGGESTION
Thank you for your SPR on the NIN JSYS in TOPS-XX version
IV. We have decided to implement Roman numeral support in
the same release that we change the power line clock to a
sundial with a laser measuring the sun's shadow. Both of
these issues have had the same priority since the first
release of TOPS-20.
Similar issues of the same priority are support in the COMND
JSYS for foreign languages (ie. new flags specifiying the (sic)
language in which the field should be input, CM%GER, CM%FRE,
and CM%SPA for German, French and Spanish respectively).
This will allow the user to supply a keyword table in
English but set the appropriate bit and have the MONITOR do
its own translation.
This release will also add support for two new devices
(called SMOKE: and FIRE:). Whenever a BUGCHK is executed,
the SMOKE: device will be activated. Whenever a BUGHLT is
executed, the FIRE: device will be activated. We feel that
this will allow the DEC-20 to come closer to meeting the
image that the public has about computers.
As you can see, there are many really exciting features
awaiting the TOPS-20 customer base. Unfortunetly, the (sic)
project plan for this release calls for this to be released
only after the sun novas. We hope you can wait until then.
[End of answer to SPR #:20-16152 ]
Who says DEC doesn't have a sense of humor??
-------
8-Jul-81 02:16:26-EDT,951;000000000000
Mail from SU-SCORE rcvd at 8-Jul-81 0216-EDT
Mail-from: ARPANET site MIT-XX rcvd at 7-Jul-81 1733-PDT
Date: 7 Jul 1981 2035-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Swap space low...
To: admin.mrc at SU-SCORE
Remailed-date: 7 Jul 1981 2312-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
For circulation among TOPS-20 hackers:
Can someone explain what goes on in the DDMP routine which gets called
by fork 0 every minute or when swap space is low? How is it freeing
up swap space? Also, why are there two messages on swap space low:
DDMP: SWAP SPACE LOW ACTION
and
[Caution -- swapping space low...]
The latter message appears to have been intended to be printed
on all terminals (but the code has been commented out so it only
comes out on the CTY). Sometimes you get both messages, sometime
you only get the first.
-- Nat Mishkin
-------
8-Jul-81 15:55:30-EDT,748;000000000000
Mail from SU-SCORE rcvd at 8-Jul-81 1555-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 8-Jul-81 1224-PDT
Date: 8 Jul 1981 1425-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: MOUNTR.CMD
To: admin.mrc at SU-SCORE
Remailed-date: 8 Jul 1981 1245-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
Mark,
Would you forward this to your mailing list if appropriate ;
Does anyone know what the format of the file SYSTEM:MOUNTR.CMD is
supposed to be? It is read at the time of a mount request, to set
structures domestic or unregulated etc., but I can't get any
reasonable format to work!
Any help is greatly appreciated,
-- Ed
-------
8-Jul-81 20:09:41-EDT,1745;000000000000
Mail from SU-SCORE rcvd at 8-Jul-81 2009-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 8-Jul-81 0710-PDT
Date: 8 Jul 1981 1008-EDT
From: Kevin Paetzold <PAETZOLD at RADC-TOPS20>
To: NWM at MIT-XX, admin.mrc at SU-SCORE
Reply-to: Paetzold at RADC-TOPS20
Telephone: 617-467-7430
Subject: Re: Swap space low...
Message-ID: <MS"5(1646)"11742370563.27.240.24758 at RADC-TOPS20>
In-reply-to: Message from Nat Mishkin <NWM at MIT-XX>
of 7-Jul-81 2035-EDT
Remailed-date: 8 Jul 1981 1701-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
When DDMP does its SWAP SPACE LOW thing it is because CHKR has called
DDMP0. DDMP0 has noticed that free swapping space (DRMFRE) is below
DRMIN0. DDMP moves (updates) modified file pages in swapping space
back to regular disk areas. If swap space is NOT low it only updates
pages to files which are in thaw mode. If swap space is low then DDMP
will move (update) pages to any file which is not suppressing DDMP.
The DDMP SWAP SPACE LOW action is very expensive as it causes a great
amount of disk activity and yet more job zero runtime.
After CHKR has got DDMP to do its thing it continues along it merry way.
Eventually its calls CHKDMS which checks drum space. If CHKDMS notices
that space is still low it types the "*****Swapping space low" message
on the cty. (remember space is still low after ddmp swap space low
action...things are not in good shape). CHKDMS also sends a message
to everyone saying the space is low. If you are not seeing the message
on your tty then something is amiss. Perhaps your system still suffers
from the TTMSG to ARPANET NVT's doesn't work bug.
--------
9-Jul-81 14:25:39-EDT,608;000000000000
Mail from SU-SCORE rcvd at 9-Jul-81 1425-EDT
Date: 9 Jul 1981 1038-PDT
From: Ted Markowitz <G.TJM>
Subject: Re: MOUNTR.CMD
To: G.ECP at UTEXAS-20, admin.mrc
In-Reply-To: Your message of 8-Jul-81 1225-PDT
Remailed-date: 9 Jul 1981 1112-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
The information on MOUNTR.CMD is buried in the OPERATOR'S GUIDE
(AA-4176D-TM) in Section V on page 3-39. It is a note on the
format of the file. Why this info isn't in the System Manager's
Guide is beyond me.
Hope that helps.
--ted
-------
10-Jul-81 13:24:27-EDT,673;000000000000
Mail from SU-SCORE rcvd at 10-Jul-81 1324-EDT
Date: 10 Jul 1981 0942-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: SFUST% bug/documentation error
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
Page 3-338 of the Monitor Calls book explicitly states that SFUST%
returns with an updated byte pointer in AC2. In reality, it leaves
the byte pointer untouched. Is this a bug or a feature? I suspect
that the documentation should be changed to reflect reality, but I'm
interested in other folks' comments...any comments from DEC people?
-- Mark --
-------
12-Jul-81 05:21:54-EDT,7017;000000000000
Mail from SU-SCORE rcvd at 12-Jul-81 0521-EDT
Mail-from: ARPANET site RUTGERS rcvd at 10-Jul-81 1137-PDT
Date: 10 Jul 1981 1430-EDT
From: WATROUS at RUTGERS
Subject: Abbreviations vs. TBADD/TBDEL
To: Admin.MRC at SU-SCORE
Remailed-date: 12 Jul 1981 0214-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
The JSYSes TBADD and TBDEL ignore abbreviations entirely when
manipulating command for use with the COMND JSYS. Thus, if you have,
say, a CONNECT and a CONTINUE command, with a CON abbreviation for
CONTINUE, and you dynamically insert a BLANK command, then the CON
abbreviation, which pointed to the CONTINUE entry will now point to
the CONNECT entry, since the entire table after the inserted entry
has been moved one position. Presumably, you wouldn't like this to
happen.
We have submitted a previous version of this fix to DEC, who
responded that abbreviations are only supported in COMND, so COMND
should be responsible for maintaining the integrity of tables. They
are considering supplying new functions for COMND to add and delete
entries in command tables. Their argument is that some user
applications might be broken by enforcing bit 33 as an abbreviation
for TB%%%. They also pointed out that some cases wouldn't be handled
by the fix we supplied. We've fixed those cases and some more that
we've come across.
So, if you'd like to be able to use TBADD and TBDEL on command tables
for the COMND JSYS, and you don't think you'll be breaking any of
your local user applications, then here's what you need to do:
Replace the entire routine, XTDEL through TDELZ+1 with
XTDEL:: stkvar <xtdbeg,xtditm,xtdend>
movem t1,xtdbeg ;save table start
aos xtdbeg ;point it to first entry
movem t2,xtditm ;and entry address
XCTU [HLRZ T4,0(T1)] ;GET USED COUNT
MOVE T3,T4
SOSGE T3 ;REDUCE COUNT, TABLE ALREADY EMPTY?
RETBAD TDELX1 ;YES
ADD T4,T1 ;COMPUTE END OF TABLE
movem t4,xtdend
CAILE T2,(T1)
CAMLE T2,T4 ;DELETED ENTRY WITHIN TABLE?
RETBAD TDELX2 ;NO
xctu [hlrz t2,(t2)] ;get string addr for entry being deleted
call xttst1 ;see if entry is abbreviation
jrst xtdela ;it is, go ahead and delete it
move t4,t1 ;point to first entry in table
xtdelc: caml t4,xtditm ;have we reached entry being deleted?
jrst xtdela ;yes, go delete it now
xctu [hlrz t2,(t4)] ;get address of string for this entry
call xttst1 ;is it an abbreviation?
skipa ;it is, check further
aoja t4,xtdelc ;check next entry
xctu [hrrz t2,(t4)] ;get address of entry this is abbr for
came t2,xtditm ;is it entry being deleted?
aoja t4,xtdelc ;no, check next entry
move t2,t4 ;point to entry
call [ savet ;save temporaries
call xtdel ;delete abbr for entry being deleted
retbad () ;error
retskp]
retbad ()
sos t3 ;one less entry in final table
sos xtditm ; and entry to delete has moved
sos xtdend ; as has end of table
jrst xtdelc ;go check this entry
xtdela: move t2,xtditm ;restore entry to delete
move t4,xtdend ;and end of table pointer
XCTU [HRLM T3,0(T1)] ;YES, STORE DECREMENTED COUNT
JUMPE T3,TDELZ ;JUMP IF TABLE NOW EMPTY
HRLI T2,1(T2) ;COMPACT TABLE, FROM DELETED ENTRY +1
XBLTUU [BLT T2,-1(T4)] ;TO DELETED ENTRY UNTIL END
move t4,xtdend
sos t4 ;compute the end of the table
move t1,xtditm ;get the address of the deleted entry
xtdel1: camge t4,xtdbeg ;is the entry within range?
jrst xtdel2 ;no, go finish
xctu [move t3,0(t4)] ;yes, get that table entry
call xttst ;is it an abbreviation
jrst [ hrrz t2,t3 ;yes
caig t2,(t1) ;has the pointer entry been moved?
jrst .+1 ;no, go look for another
sos t3 ;yes, adjust the pointer
camg t2,xtdend ;only if before end of table
xctu [movem t3,0(t4)] ;and save the updated pointer
jrst .+1] ;try for more
soja t4,xtdel1
xtdel2: move t4,xtdend ;resetup t4
TDELZ: XCTU [SETZM 0(T4)] ;CLEAR EMPTY WORD AT END OF TABLE
RETSKP
Add TBE as a third argument to the ASUBR at XTADD, and after the
CALL CHKTBS at XTADD+2, add
jxe t1,cm%abr,xtadd1 ;if not abbreviation, don't check it
hrrz t3,ent ;point to entry
xctu [move t3,(t3)] ;get entry
call xtcabr ;check abbreviation
retbad()
xtadd1:
Replace the code from XTADD2 to the end of the page with
movem t4,tbe ;save it for comparisons
XTADD2: CAML T1,T4 ;NOW AT 'HOLE'?
JRST [ MOVE T3,ENT ;YES, INSERT ENTRY
call xttst ;is this an abbreviated entry?
call adjint ;yes, adjust pointer if in table
UMOVEM T3,0(T1)
jrst xtadd3] ;continue moving abbreviations
XCTU [MOVE T3,-1(T4)] ;MOVE TABLE TO CREATE HOLE
call xttst ;is the entry an abbreviation
call adjint ;adjust pointer if in table
;since it was moved
XCTU [MOVEM T3,0(T4)]
SOJA T4,XTADD2
;here to fixup the part of table before the hole
xtadd4: xctu [move t3,0(t4)] ;get table entry
call xttst ;is it an abbreviation?
jrst [ hrrz t2,t3 ;yes
caig t2,(t1) ;has the pointered to entry been moved?
jrst xtadd3 ;no, go look for another
call adjint ;yes, adjust pointer if in table
xctu [movem t3,0(t4)] ;place it back
jrst xtadd3] ;
xtadd3: move t2,tba ;get the table address
cail t4,1(t2) ;is the pointer still in range?
soja t4,xtadd4 ;yes, go try again
xtrskp: retskp ;no, all done
;routine to test to see if the entry is an abbreviation
;enter at: xttst, t3 has an entry in it
; xttst1, t2 has a string pointer in it
;returns +1 if it is and +2 if it isn't
;on return: t2 has a pointer to the string
xttst: hlrz t2,t3 ;get the address of the entry
xttst1: push p,t1
call chktbs ;get flags and byte pointer
; txne t1,cm%fw ;if not flag word
;the monitor doesn't seem to care if cm%fw is set!!!
txnn t1,cm%abr ;or not an abbreviation
jrst [ pop p,t1 ;then restore the register
retskp] ;and ignore this entry, fail return
pop p,t1 ;else restore the register
ret ;and say it is an abbreviation
;routine to insure abbreviation is substring of keyword pointed to
;t2/ string
;t3/ entry for which string is abbreviation
; returns with error already set up, or skips when verified
; with t2 preserved
xtcabr: push p,t2 ;save string pointer
call xttst ;get string pointer for keyword
jrst xtcang ;abbreviation points to abbreviation!
jxn t1,cm%nor,xtcang ;error if not legit keyword
move t1,(p) ;get abbreviation
call ustcmp ;compare
jxe t1,sc%sub,xtcang ;error if not substring
pop p,t2 ;restore string pointer
retskp ;and return success
xtcang: pop p,t2 ;fix up stack
retbad taddxx ; and give error
;routine to add 1 to t3 iff it points inside current table
;clobbers t2
adjint: hrrz t2,t3 ;get just address
caml t2,tba ;before beginning ot table?
camle t2,tbe ;or after end?
ret ;yes, do nothing
aos t3 ;in table, increment
ret
And finally, define an error in MONSYM:
err (3001,taddxx,<Abbreviation not substring of keyword>)
-------
13-Jul-81 14:27:36-EDT,1930;000000000000
Mail from SU-SCORE rcvd at 13-Jul-81 1427-EDT
Date: 13 Jul 1981 1124-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: [Mike Peeler <ADMIN.MDP>: New FINGER here]
To: MMcM at MIT-AI, TOPS-20 at RUTGERS, G.daCruz at SU-SCORE
I intend to implement this interface in MM shortly.
---------------
Date: 13 Jul 1981 1038-PDT
From: Mike Peeler <ADMIN.MDP>
Subject: New FINGER here
To: Admin.MRC
Mark,
You can now invoke Score Finger as an inferior fork to look up a personal
name. Simply place the user name at the beginning of some page and map it
(with PMAP%) onto page 777 of the Finger fork. Then start Finger (with
SFRKV%) at entry vector position 3 (which is fourth in the entry vector,
right after the version information). On success, Finger will return the
personal name in place of the username on Finger's page 777, and otherwise it
will return the null string.
Finger first tries for an exact username match and returns the corresponding
personal name if that succeeds. If not, it tries for a unique substring
match with all the usernames and personal names it knows. If it finds no
match or the substring proves ambiguous, it returns the null string, and
otherwise it has found precisely one match and returns the personal name.
This satisfies the basic need you expressed in your message entitled
"MM/Finger interaction". This linkage is intended to supersede the original
scheme of using the RSCAN buffer, which, as several people pointed out, is
job-wide and may be contested for by other processes. Note that DDT does use
page 777, but that Finger should not ever need DDT when invoked as an
inferior.
The DOVER program uses this new feature without any apparent problems.
Happy hacking,
Mike
-------
---------------
-------
14-Jul-81 04:11:50-EDT,4341;000000000001
Mail from SU-SCORE rcvd at 14-Jul-81 0411-EDT
Date: 14 Jul 1981 0109-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: TOPS-20 extended addressing status
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
Following is an excerpt of a message sent to me by one of
DEC's TOPS-20 developers on the status of some problems with
extended addressing in release 4. They would like for people to
look through this list and send anything else back to them.
Please note that the people who are doing this are doing it
out of the kindness of their hearts to try to make it as winning
as possible. What are most important are known fixes to real
bugs, followed by wishlist kinds of things.
Please send any comments on this to me, and I'll pass them
on to DEC.
-- Mark --
**********************************************************************
Below is a list of the problems that have been reported to us regarding
extended addressing in R4. While the official position is that we don't support
the stuff, we obviously want to get it right. If possible, I would like to
publish a list of patches, along with a couple of specs, in a user-read
document. Would those of you who use extended addressing verify these fixes
for us?
We have made significant changes in the code since shipping R4. That implies
a couple of things:
a) Some of the fixes can't be patched easily into R4.
b) We may have broken things that worked in R4.
If you have a favorite program that demonstrates a R4 problem, and would like to
lend it to us, we could use it to test the current code.
1. Problem: Mark Crispin reported jobs looping in KSELF, waiting in a deadly
embrace for share counts to go to zero.
Solution: Use Mark's patch, which causes SECMAP to decrement the share count.
Status: The code has been rewritten, but it still decrements the share
count.
2. Problem: CMU reported a security bug such that a user can SMAP a file and
write into it in spite of not having write access to the file.
Diagnosis: For historical reasons, CPMAP ignored the access bits returned
by FKHPTN. This is no longer valid.
Status: A lot of code has been written for this since R4, so there is
no patch for R4.
3. Problem: FLKTIM BUGCHK's in jobs using extended addressing.
Diagnosis: There are lots of causes of FLKTIM's, but one in particular is
related to extended addressing. In R4 a new entry point, FLOCKN, was added
to FLOCK to allow nested locking. The left half of FLKOWN is supposed to
contain -1 if nesting is allowed. However, if the process every has to block,
W1 gets a time, and that time gets stored into FLKOWN.
Solution: There are several ways to get around this. We are now allowing nesting
for all callers, which eliminates the bug. You can get this effect by making
the following change:
FLOCK1+5/ CAMN Q1,FORKN JFCL
FLOCK1+6/ SKIPL FLKOWN CAME Q1,FORKN
If that makes you nervous, you can add another variable to the ACVAR and use the
second variable for temporary storage.
4. Problem: Repeat counts don't work when creating private sections.
Diagnosis: This must have slipped through the cracks in R4. It just wasn't
coded.
Status: We now have this working. We trust you can live without it for now.
5. Problem: Chuck Hedrick reported J0NRUN's when swapping space is low.
Status: We are unable to reproduce this with our current sources. We may get
around to debugging it in R4, but in the meantime we hope you'll just increase
your swapping space.
6. Problem: Mark Crispin reported that Release 4 MONSYM or MACSYM defined
XHLLI to be XMOVEI.
Status: For some reason, the R4 MONSYM has two definitions of XHLLI, and the
second (and therefore dominant) one is obsolete. The correct definition equates
XHLLI with HLLI. It's fixed in our sources now.
7. Problem: Because of a microcode bug, IBP on a two-word byte pointer
produces garbage.
Status: It's fixed here, but I don't know when you will get the changes.
Meanwhile, ILDB works fine.
8. Problem: With large address spaces, RMAP is painfully slow.
Status: We've implemented an extended version of RMAP that takes page
ranges, but there's no solution in R4.
-------
15-Jul-81 05:25:30-EDT,1188;000000000001
Mail from SU-SCORE rcvd at 15-Jul-81 0525-EDT
Mail-from: ARPANET site RUTGERS rcvd at 14-Jul-81 0921-PDT
Date: 14 Jul 1981 1216-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: problem in DDMP possibly leading to J0NRUN
To: admin.mrc at SU-SCORE
cc: hall at DEC-MARLBORO
Remailed-date: 15 Jul 1981 0220-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.104: ;
In module PAGEM, at DDMP, there is code
ddmp: lock strlok
noint
This is clearly wrong. In general one wants to go no-int before
getting locks, not afterwards, since otherwise an interrupt could
theoretically happen between the lock and the noint. Thus the
code should be
ddmp: noint
lock strlok
I do not see that there could in fact be an interrupt during DDMP, so
this code shouldn't matter. However we were getting J0NRUN's every few
weeks, and the dumps showed that STRLOK was being locked but not
unlocked. This is what one would expect from this problem if it were a
problem. So it seems safest to change it. We have not had any J0NRUN's
(except one whose cause we know) since changing this.
-------
15-Jul-81 06:24:11-EDT,7140;000000000000
Mail from SU-SCORE rcvd at 15-Jul-81 0624-EDT
Mail-from: ARPANET site RUTGERS rcvd at 15-Jul-81 0308-PDT
Date: 15 Jul 1981 0603-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: DDT extended addressing problem
To: admin.mrc at SU-SCORE
cc: hall at DEC-MARLBORO
Remailed-date: 15 Jul 1981 0317-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.106: ;
Here is what I have found, and what I have accomplished so far.
Probably you might as well distribute it to the list. I will not
likely do any more for some time, and others might see some problem
in what I propose to do.
There are some clear bugs in the way effective addresses are
handle in $X logic. One of these can be fixed easily. However the
other is complex. The problem is that when the effective address
is computed by local addressing, if RH(ea) < 20, any memory reference
using it gets the AC's. E.g. MOVE 1,2 always moves from AC 2 to AC
1, even when done in section 12.
Unfortunately the DDT implementors chose to handle this in the effective
address logic. They simply treat MOVE 1,2 as if its effective address
were 2 (or 1,,2 - which is equivalent). This is not quite right, as
the following examples show:
- If you do JRST 2 in section 12, the effective address will turn out
to be 2. This is close, but no cigar. It is true that JRST 2
should transfer control to AC 2, even when done in section 12.
But the PC will be 12,,2. This shows up if you do a PUSHJ while
you are in the AC's. The PC pushed on the stack should be
12,,2 but with the current DDT you will get a simple 2.
- Consider DMOVE 1,17. The current DDT will take this to refer to 17
and 20. However it should refer to 17 and 12,,20.
- Consider XMOVEI 2,3. This should give [1,,3] in AC 2, because the
AC's are considered to be in section 1. In DEC's code, this
will give 3.
The point is that the effective address should still have the section
number in it. The mapping to AC's should occur only when an actual
memory reference is to be made, but all internal variables should
remember it in the form containing the section number. In order for
this to work, an extra bit will be needed so that DDT knows the address
was calculated by local addressing. Clearly some occurences of 12,,2 do
indeed refer to 12,,2, not AC 2. One can disambiguate these only by
knowing whether they are local or global references. The implementors
tried to avoid doing this by turning 12,,2 into 2 but as I think I have
shown, that will not work.
I have a patch that appears to make things work in sections 0 and 1,
which are typically where code is. It works (if it does work) because
in sections 0 and 1 there is no problem. One can leave around the
actual effective address, since 0,,3 and 1,,3 both will result in AC 3.
One doesn't need to know whether they were computing locally or not.
This fix will *not* work in section 2, as there one has to choose
between 2,,3, which is the right effective address but will result in
DDT refering to the wrong place in memory, and 1,,3 (or 0,,3) which will
refer to the right word, but give wrong results in the cases shown
above. I choose 1,,3 in this case, on the grounds that simple memory
references are more common than the problem cases shown above.
I would be interested in knowing whether anyone sees any problems with
this analysis, before I proceed with redesigning the addressing logic
of DDT.
The following FILCOM shows
- a fix to a bug in doing global indirection
- the partial fix just mentioned
- the code from the Dispatch related to IBP and ILDB
File 1) DSK:DDT.MAC[4,211] created: 0519 15-Jul-1981
File 2) DSK:DDT.DEC[4,211] created: 1532 06-Nov-1979
**************
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) JRST CIFIW7 ;[CLH] NOT LOCAL, SO NOT LOCAL 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 ;HERE TO DETECT AC'S
1) ;[clh] check for AC's: Note that this will work for code in section
1) ;0 or 1, but not in general for higher sections. The problem is that
1) ;JRST 2 will end up with a PC of 1,,2, which is wrong in sections > 1
1) ;Also things like DMOVE 1,17 will load from 1,,17 and 1,,20.
1) CIFIW6: TXNE T,777760 ;[CLH] IS LOCAL REFERENCE TO A REGISTER?
1) JRST CIFIW7 ;[CLH] NO
1) ANDI T,17 ;YES, REDUCE TO UNABIGUOUS AC
1) ; (NOTE "SECTION-NESS" STILL IN S)
1) SKIPE S ;[CLH] IF IN NON-ZERO SECTION
1) HRLI T,1 ;[CLH] AC's are considered in section 1
1) ;CHECK IFIW INDIRECTION
1) CIFIW7: POP P,R ;GET BACK ORIGINAL WORD
1) TXNN R,@ ;IFIW I BIT ON?
****
2)94 ;CHECK IFIW INDIRECTION
2) CIFIW6: TXNN T,777760 ;IS LOCAL REFERENCE TO A REGISTER?
2) ANDI T,17 ;YES, REDUCE TO UNABIGUOUS AC
2) ; (NOTE "SECTION-NESS" STILL IN S)
2) POP P,R ;GET BACK ORIGINAL WORD
2) TXNN R,@ ;IFIW I BIT ON?
**************
1)95 ;[CLH] INSERT LABEL
1) CEFFEX: MOVEI W,INDPTH ;MAX LOOP COUNT FOR INDIRECTION
1) MOVEM W,TEM ;SO WE DON'T GET CAUGHT
****
2)95 MOVEI W,INDPTH ;MAX LOOP COUNT FOR INDIRECTION
2) MOVEM W,TEM ;SO WE DON'T GET CAUGHT
**************
1)140 MOVEM 17,HAK304 ;[CLH] SAVE USER AC17
1) ILDB @I.NSTE ;[CLH] INCREMENT THE USER'S BYTE PTR
1) MOVE 17,HAK304 ;[CLH] RESTORE USER AC17
1) JSR SWAP ;BACK TO DDT CONTEXT
****
2)140 IBP @I.NSTE ;INCREMENT THE USER'S BYTE PTR
2) JSR SWAP ;BACK TO DDT CONTEXT
**************
1)140 JUMPE S,IXBP2 ;[CLH] JUMP IF IN NON-ZERO SECTION
1) TLNN T,(1B12) ;[CLH] NON-ZERO SECTION - IS THIS EXTENDED?
1) JRST IXBP2 ;[CLH] NO, LUCKY - DO IT AS IF IN SECTION 0
1) MOVE R,I.NSTE ;[CLH] YES, GET EA OF OPCODE
1) HRRI R,1(R) ;[CLH] POINT TO SECTION ADDR.
1) PUSHJ P,FETCH ;[CLH] GET IT
1) POPJ P, ;[CLH] FAILED
1) HLLZ S,I.NSTE ;[CLH] GET SECTION # OF OPCODE
1) PUSHJ P,CEFFEX ;[CLH] GET EA OF IT'S TARGET BYTE
1) POPJ P, ;[CLH] FAILED
1) JRST IXBP5 ;[CLH] CONTINUE
1) ;[CLH] INSERT LABELS
1) IXBP2: PUSHJ P,CEFFIX ;CALCULATE BYTE POINTER EFFECTIVE ADDRESS
1) POPJ P, ;MEMORY READ ERROR
1) IXBP5: MOVEM T,I.NEA2 ;REMEMBER IT FOR LATER TYPEOUT
1) EXCH F,FLAGS ;BACK TO $X FLAGS
****
2)140 PUSHJ P,CEFFIX ;CALCULATE BYTE POINTER EFFECTIVE ADDRESS
2) POPJ P, ;MEMORY READ ERROR
2) MOVEM T,I.NEA2 ;REMEMBER IT FOR LATER TYPEOUT
2) EXCH F,FLAGS ;BACK TO $X FLAGS
**************
1)194 PADR: TDNN T,[777776,,777760] ;[CLH] IF 0-17 IN SECTION 0-1
1) TLZ T,1 ;[CLH] THEN PRINT IT AS SECTION 0
1) JRST (AR) ;PADSO OR TOC
1) PADSO: JUMPE T,FP7B ;PRINT A ZERO
****
2)194 PADR: JRST (AR) ;PADSO OR TOC
2) PADSO: JUMPE T,FP7B ;PRINT A ZERO
**************
1)362 DD(HAK304,1) ;[CLH] TEMP USED TO SAVE AC17 IN $X OF IBP
1) DD(I.PXC,1) ;-1 IF $X01 CALLED FROM $PX
****
2)362 DD(I.PXC,1) ;-1 IF $X01 CALLED FROM $PX
**************
-------
21-Jul-81 16:25:23-EDT,5531;000000000000
Mail-from: SU-SCORE rcvd at 21-Jul-81 1625-EDT
Mail-from: ARPANET site RUTGERS rcvd at 21-Jul-81 0700-PDT
Date: 21 Jul 1981 0956-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: comnd jsys bug fix
To: admin.mrc at SU-SCORE
Remailed-date: 21 Jul 1981 1318-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.106: ;
Problem:
A program sets up a comnd call consisting of two alternatives:
a switch and a file spec. It supplies a default file name (via
CMDEF, not the GTJFN defaults). If the user types something illegal,
e.g. an illegal switch, no error message is issued. Furthermore,
? causes the program to start, and does not issue the help text.
Diagnosis:
Defaulting is being done wrong for file names. Normally, the
default is copied to the COMND buffer only if it is displayed on the
screen. However when a file spec is involved, after the GTJFN the atom
buffer is copied to the main COMND buffer. (This is done at CMFIL2+24.)
The idea is that if the user typed <esc> or ^F during the GTJFN, there
will be recognition output which he saw on the screen, and we want it
put in the buffer in case of future ^R, etc. This is usually OK, but in
the case mentioned above, here is what happens:
user types /FOOBAR ?
the buffer now contains /FOOBAR ?<nul>
^
We call COMND. It fails to recognize /FOOBAR as either a switch or a
filename. Thus it supplies the default file name. The default
is put into the atom buffer, terminated by CRLF. After the
GTJFN, it is copied to the main buffer.
the buffer now contains GAZONK.DEL<cr><lf>
^
All traces of the illegal switch and the ? have disappeared. The program
now parses a confirm, and proceeds on its way.
I believe that when a default is supplied, normally it should not be
copied into the main buffer. Since the user didn't see it, ^R shouldn't
show it. Any typeahead will now remain undisturbed in the buffer.
However there are some exceptions to this. If the user typed <esc> or
^F, the default is displayed on his terminal. If the default is a
partial file name (e.g. without version number), he could now type
another <esc> or ^F to complete the file name. This completion output
must be copied to the buffer, since it showed on his screen. I believe
I can show that whenever the user typed <esc> or ^F, it is safe to
copy the filename back to the buffer. Since <esc> and ^F cause the
COMND jsys to activate immediately, there can't be any typeahead there.
Hence there is no harm done in this case. Thus it seems that the
correct solution is to skip copying the file name back to the buffer
when the default is supplied, except that if the user typed ^F or
<esc>, it should be copied:
Cure:
The following patch goes in COMND, at CMFIL2+24. (It is probably
easier to find as CMGJE-7.)
File 1) COMND.MAC.13,21-Jul-81 09:18:36
File 2) COMND.MAC.12,10-Jul-81 11:55:00
1)37 txnn f,cm%esc ;[172] if esc was typed, arg was echoed
1) txnn f,cmdeff ;[172] else if default, shouldn't be in buffer
1) CALL CMGJC ;COPY INPUT TO MAIN BUFFER
****
2)37 CALL CMGJC ;COPY INPUT TO MAIN BUFFER
**************
We are running with the patch installed in DDT, and all the test cases I
can dream up work. However the COMND jsys is so obscure and convoluted
that there could be ill effects.
Further discussion:
The entire concept of supplying defaults because of "null input" is
controversial. The Monitor Calls Manual says that defaults are supplied
when the user types ^F, <esc>, or <cr> as the non-blank character in the
field. This is quite clear. However in addition, the monitor attempts
to supply it when the user types a "null field". SPR 20-13582 (1-Jul-80),
by Leslie McMillin, describes in some detail the pitfalls with trying to
handle null fields. From that SPR and the response, it appears that in
3A the default is supplied whenever the current user input does not
match the syntax of any of the alternatives. I.e. in my example, if the
user types a nonexistent switch, this would be treated as an error.
Since it was a switch, it matches the switch syntax, and the default is
not supplied. However if the user types a comma, it does not match the
syntax of any of the options, and the default is supplied. The comma is
left around for a later call to COMND. In 4, it appears that the
default is used whenever there would otherwise be an error, although
this behavior does not seem to be consistent. (It almost looks like a
non-existent switch if left for later COMND calls, but a non-existent
file is treated as an error. People who are using defaults in
sophisticated ways should be warned of this issue. The DEC response to
Leslie's SPR was incredibly arrogant, both in tone and in substance.
They told Leslie that everything would be fine if she just went back and
read her manual more carefully. It seems to me that the supplying of
defaults for null fields is in fact not documented, and that it is going
to be very difficult to do this in a way that does not lead to surprises.
PS: The program that led me to have to fix this bug is our native-mode
version of FILCOM. That is now finished, and anyone who wants it is
welcome to copy it from us, provided of course that you are licensed
for DEC's FILCOM. You will also need our version of the COMND package,
which we have modified to handle RSCAN when requested.
-------
25-Jul-81 21:58:20-EDT,1162;000000000000
Mail-from: SU-SCORE rcvd at 25-Jul-81 2158-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 24-Jul-81 0813-PDT
Date: 24 Jul 1981 0912-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Front-end tidbit
To: admin.mrc at SU-SCORE
Remailed-date: 25 Jul 1981 1851-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.106: ;
(Mark, for distribution list)
Learned something interesting about the front-end:
As shipped from Marlboro, the core memory on the 11/40 is set up to run in
non-interleaved mode. It is a trivial jumper change on the memory boards
(documented in the prints) to modify 11/40 memory to run 2-way interleaved.
Seems to speed up the 11/40 about 15-20%. We have done so, and it seems
to improve some 11/40 problems (especially lost input data at high speeds),
although the problems don't go away.
We are planning to add a cache to the 11/40 (on a trial basis) to see if it
further improves 11/40 performance. Will let you know the results.
Randy
(P.S. Does anyone have any idea why DEC ships the damn thing non-interleaved?
Seems to be a stupid thing to do.)
-------
27-Jul-81 20:13:57-EDT,747;000000000000
Mail-from: SU-SCORE rcvd at 27-Jul-81 2013-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 27-Jul-81 0830-PDT
Date: 27 Jul 1981 1122-EDT
From: Donna Lynch <ADMIN at RADC-TOPS20>
To: ADMIN.MRC at SU-SCORE
cc: ADMIN at RADC-TOPS20
Subject: DEC'S ARCHIVE
Message-ID: <MS"5(1646)"11747364897.4.43.141821 at RADC-TOPS20>
Remailed-date: 27 Jul 1981 1707-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
Mark--
I am system manager on RADC TOPS-20, replacing Bob Doane.
I am quite unhappy with DEC's archive. Would you know
of anyone who has a better archive system?
Could you send such a message to your distribution list?
Thank you.
Donna Lynch
--------
28-Jul-81 03:10:05-EDT,2717;000000000001
Mail-from: SU-SCORE rcvd at 28-Jul-81 0309-EDT
Mail-from: ARPANET site RUTGERS rcvd at 27-Jul-81 1736-PDT
Date: 27 Jul 1981 2031-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: DEC'S ARCHIVE
To: ADMIN at RADC-TOPS20
cc: admin.mrc at SU-SCORE
In-Reply-To: Your message of 27-Jul-81 1122-EDT
Remailed-date: 28 Jul 1981 0004-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
It all depends upon what you mean by better. In my opinion,
the DEC archiver does a much better job of storing information
about offline files, and doing retrievals, than anything else
I have seen. Since these facilities have to be integrated into
monitor and spooling system, you are not going to find anyone
else who has done a system like that. I had an archiver under
release 3A. To archive a file you used a program ARCHIVE.
It set a bit in the FDB, and another bit in a system file that
said there was a request for that directory. Then the operator
used a privileged command within ARCHIVE to scan the system.
For each directory that was marked in the system file, it
looked at all files to find those with the bit in the FDB. It
then created .CMD files for DUMPER and the EXEC to dump and
delete the files. We modified DUMPER to append the file name,
save date, etc. to a file 20-ARCHIVE.DIR in the user's area.
The advantages of this system are:
- very simple. none of the complexities of Archived, Migrated,
Offline, Invisible, etc. The data is in a normal text
file which you can search with any editor. (Also this
keeps you from filling up your directory.)
- saving is fast, since only the directories with requests
are scanned, and the scan happens only once. The rest
is done by command files. DEC's archiver seem to look
at every file on the system 4 times
- the two tapes are guaranteed to be identical, since they are
produced with the same command file. Thus if something
odd happens to one, you can make a copy of the good one.
This is a fairly common problem. Some files take the
system stand-alone to do archiving just to make sure
the two tapes are the same.
However we abandoned this system in favor of DEC's, because
- archive retrievals had to be done by hand. This isn't too
important, since we had far more saves than retrieves.
- there was slightly more manual intervention in the dump,
though most of the stuff was in command files.
- we thought it would be nice to have the data in the directory
I am no longer so sure that this was a good idea. I think the
efficiency and simplicity of our old system is probably a win.
-------
29-Jul-81 22:58:57-EDT,850;000000000000
Mail-from: SU-SCORE rcvd at 29-Jul-81 2258-EDT
Date: 29 Jul 1981 1955-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: IPCF MAILER crashes
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
SCORE has been experiencing some strange MAILER crashes, with PCs
like 2, 600105, etc. One very obvious bug is at ONQ+4; there is a RET
which should be
JRST [ POP P,W
RET]
However, this only happens if MAILER is about to crash due to lack
of further free storage. I am trying replacing the HALTF in the literal
that reports NO MORE FREE STORAGE AVAILABLE with the following:
MOVEI A,4
MOVEI B,W
MSEND ;SEND IT OFF NOW
ERJMP DOQ1 ;TOSS IT ON THE FLOOR IF IT FAILS
JRST DOQ ;DO THE REMAINDER OF THE QUEUE
-------
30-Jul-81 18:52:07-EDT,1835;000000000000
Mail-from: SU-SCORE rcvd at 30-Jul-81 1851-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 30-Jul-81 1539-PDT
Date: 30 Jul 1981 1735-CDT
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Misc. things
To: admin.mrc at SU-SCORE
Remailed-date: 30 Jul 1981 1545-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
Mark-- A couple of things have arisen that I'd like your comments
on.
1) A user on our other 2060 system managed to create 4-page file which
had a byte-count of approx. 17,000,000,000 36-bit bytes. Presumably
he did this by accident, but it turns out that an unprivilged user can
also do this on purpose. Anyway, he then proceeded to try and print the
file, which caused LPTSPL to hang in a solid RUN state, doing a SIN JSYS.
A couple of hours went by before the operator noticed this and tried
to cancel the print job with OPR. This didn't work, and we ended up
having to kill LPTSPL. When we brought it back up it of course grabbed
the same job again, etc., until I finally discovered the problem with
the file and made the byte count more reasonable using REV.
This is a clearly undesireable situation, since any user can cause
plenty of headaches for operators. The question is, what is a good
fix? Should users be prevented from munging byte-counts, or at least
setting them to something ridiculous? Or should the monitor know
enough not to get stuck when trying to read such files (i.e. pay more
attention to the actual page count)?
2) Do you know of anybody who has hacked the monitor to allow ^H as a
rubout character, WITHOUT the undesireable effect of having ^H's
converted to DEL's when a user program does single-character input?
-------
31-Jul-81 20:49:03-EDT,665;000000000000
Mail-from: SU-SCORE rcvd at 31-Jul-81 2048-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 31-Jul-81 1629-PDT
Date: 31 Jul 1981 1629-PDT
From: MCGREAL at USC-ISIB
Subject: Accounting software
To: Larson, MRC at SU-SCORE, Knight
Remailed-date: 31 Jul 1981 1743-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
Does anyone have a program that will dump login and logout times from the
fact files on rel. 4 for a specific user only. Better yet a program that will
allow you to dump various fields with optional filters to pick out
particular users or pieslices etc.
Thanks, Gary
-------
1-Aug-81 02:23:19-EDT,847;000000000000
Mail-from: SU-SCORE rcvd at 1-Aug-81 0223-EDT
Mail-from: ARPANET site SRI-KL rcvd at 30-Jul-81 2001-PDT
Date: 30 Jul 1981 2000-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: outstanding bug with SIN?
To: admin.MRC at SRI-KL
Remailed-date: 31 Jul 1981 2317-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
Mark: Do you happen to know if the R4 bug with bogus destination byte
pointers to SIN has been fixed? In particular, do the following:
MOVE 1,JFN
MOVE 2,[770777,,anything]
MOVNI 3,^D512
SIN
and your program will hang in the SIN for a few seconds before the system
crashes with an ILLPT3. I haven't looked into it, because I presume this
is a silly non-zero-section bug which has probably been fixed. Has it?
Anyone want to try it?
/Chris
-------
4-Aug-81 01:31:19-EDT,953;000000000000
Mail-from: SU-SCORE rcvd at 4-Aug-81 0131-EDT
Mail-from: ARPANET site MIT-XX rcvd at 3-Aug-81 1518-PDT
Date: 3 Aug 1981 1816-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: FFORK/RFORK
To: admin.mrc at SU-SCORE
Remailed-date: 3 Aug 1981 2222-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
Do you know of this problem? Do you know of a solution?
If a fork (call it A) freezes (FFORKs) another fork (call it B) which
has the "inferior fork termination" interrupt (.ICIFT) enabled and
itself has a fork (call it C) which has previously halted normally
(via HALTF), then when A unfreezes (RFORKs) B, B gets another fork
termination interrupt (presumably from C). Diagrammatically:
A FFORK...RFORK
|
B .ICIFT enabled
|
C halted
I grovelled around in the PSI code in the monitor for a while but
I couldn't find the answer.
-- Nat Mishkin
-------
4-Aug-81 20:33:52-EDT,1063;000000000000
Mail-from: SU-SCORE rcvd at 4-Aug-81 2033-EDT
Mail-from: ARPANET site SANDIA rcvd at 4-Aug-81 0911-PDT
Date: 4 Aug 1981 1011-MDT
From: Norm Samuelson <SAMUELSON at SANDIA>
Subject: FTP and FTPSER bugs
To: admin.mrc at SU-SCORE
Remailed-date: 4 Aug 1981 1727-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.108: ;
(Mark - please send this to your distribution list)
The DEC versions of FTP and FTPSER use the old style 8-bit arpanet addresses
internally. That causes problems when a host on a large numbered imp (one
which will not fit in the 8-bit format) tries to communicate with any other
host. I have tried to fix these bugs in the most straightforward way I
could, without adding any other useful features. All sites which are running
vanilla DEC versions of FTP and FTPSER should install these patches. The
patched files are available in directory <G.SAMUELSON> at SU-SCORE or in
<ANONYMOUS> at SANDIA. There are .MAC files and .DIF files for both FTP
and FTPSER.
-------
6-Aug-81 16:26:00-EDT,549;000000000000
Mail-from: SU-SCORE rcvd at 6-Aug-81 1625-EDT
Mail-from: ARPANET site BBNG rcvd at 6-Aug-81 1022-PDT
Date: 6 Aug 1981 1323-EDT
From: Dan Tappan <Tappan at BBNG>
To: Admin.MRC at SU-SCORE
Remailed-date: 6 Aug 1981 1319-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Mark, could you forward this to the 20 list (unless you
know the answer).
Does anyone know the format of IPCF messages sent to/from
QUASAR? I'm particularly interested in SUBMIT messages.
Dan
-------
7-Aug-81 23:01:47-EDT,3561;000000000000
Mail-from: SU-SCORE rcvd at 7-Aug-81 2301-EDT
Mail-from: ARPANET site USC-ISIC rcvd at 7-Aug-81 1521-PDT
Date: 7 Aug 1981 1513-PDT
From: JGOLDBERGER at USC-ISIC (Joel Goldberger)
Subject: Performance improvement for Class-Scheduler
To: Admin.MRC at SU-SCORE
Remailed-date: 7 Aug 1981 1953-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Problem: 1) Class Scheduler is too rigorous in using Class & Job Distances for
ordering of GOLST. Q1 & Q2 should always be above the "compute"
queues reagrdless of windfall or how greedy they are.
2) Network terminals should be treated as "physical", only PTYs
should be penalized
Cause: 1) The actual Q a fork is on is disregarded if Class-Scheduling is on.
2) Check is being made for "physical TTY" rather than specifically
PTY
Solution: 1) Recognize Q1 & Q2 as special.
2) Use CHKPTY instead of CKPHYT
--------------------------------------------------
;<ISI.MONITOR>SCHED.MAC.2130 & <ISI.MONITOR>SCHED.MAC.2530 27-Jul-81 2031
LINE 1, PAGE 1
1) ;<4.ISI-MONITOR>SCHED.MAC.2130 31-Mar-81 13:25:06 Edit by SMITH
LINE 1, PAGE 1
2) ;ISISRC:<4.ISI-MONITOR>SCHED.MAC.2530 4-May-81 13:13:58, Edit by CHASE
2) ;#253 Use CHKPTY, not CKPHYT, to decide if line is pty vs "physical"
2) ;ISISRC:<4.ISI-MONITOR>SCHED.MAC.2370 14-Apr-81 09:44:10, Edit by JGOLDBERGER
2) ;#237 Give additional priority to forks in TCOTST as well as those in TCITST
2) ;ISISRC:<4.ISI-MONITOR>SCHED.MAC.2340 13-Apr-81 16:10:31, Edit by JGOLDBERGER
2) ;#234 Make Q1 & Q2 more loveable at CORFC4-2 & CORF55
2) ;<4.ISI-MONITOR>SCHED.MAC.2130 31-Mar-81 13:25:06 Edit by SMITH
LINE 36, PAGE 74
1) JUMPL T1,R ;IF CLASS IN WINDFALL, NO BOOST
1) CAIN CX,INTQ1 ;SECOND INTERACTIVE QUEUE?
1) FADRI T1,(EXP 0.5) ;YES. ATTENUATE CLASS DISTANCE SUCH
1) ; THAT A WELL-BEHAVED CLASS WILL
1) ; ACHIEVE PRIORITY ON THIS QUEUE
1) RET ;AND DONE
LINE 36, PAGE 74
2) ;#234 JUMPL T1,R ;IF CLASS IN WINDFALL, NO BOOST
2) CAIN CX,INTQ1 ;SECOND INTERACTIVE QUEUE?
2) ;#234 FADRI T1,(EXP 0.5) ;YES. ATTENUATE CLASS DISTANCE SUCH
2) ; THAT A WELL-BEHAVED CLASS WILL
2) ; ACHIEVE PRIORITY ON THIS QUEUE
2) MOVSI T1,(EXP 1.0) ;#234 make Q2 forks better than other Queues,
2) ;#234 but not as good as Q1
2) RET ;AND DONE
LINE 6, PAGE 75
1) SKIPL T1 ;IN WINDFALL?
1) CORF55: SKIPA T1,[EXP 3.1] ;NO. USE BIG BOOST
LINE 6, PAGE 75
2) ;#234 SKIPL T1 ;IN WINDFALL?
2) SKIPA ;#234 Ignore windfall status for Q1
2) CORF55: SKIPA T1,[EXP 3.1] ;NO. USE BIG BOOST
LINE 13, PAGE 75
1) FADRI T1,(0.5)
1) CALLRET PB2] ;RESTORE T2 AND RETURN
LINE 14, PAGE 75
2) ;#234 FADRI T1,(0.5)
2) MOVSI T1,(2.0) ;#234 Q1 forks go to the head of the line
2) CALLRET PB2] ;RESTORE T2 AND RETURN
; ISIMON:<ISI.MONITOR>SCHED.MAC.2130 & ISIMON:<ISI.MONITOR>SCHED.MAC.2530 27-Jul-81 2031 PAGE 2
LINE 19, PAGE 85
1) CAIN 2,TCITST ;TTY INPUT?
1) JRST [ HLRZ 2,FKSTAT(FX) ;YES
1) CALL CKPHYT ;IS IT A PHYSICAL TERMINAL?
1) JRST NEWST2 ;FOR PTY, FOLLOW NORMAL ALGORITHM
1) JRST NEWST1] ;YES, BE MORE GENEROUS
1) NEWST2: LOAD 2,FKQN ;CURRENT QUEUE
LINE 19, PAGE 85
2) CAIE 2,TCOTST ;#237 TTY Output ?
2) CAIN 2,TCITST ;TTY INPUT?
2) JRST [ HLRZ 1,FKSTAT(FX) ;#253 YES
2) CALL CHKPTY ;#253 IS IT A PTY?
2) JRST NEWST1 ;#253 NO, BE MORE GENEROUS
2) JRST NEWST2] ;#253 FOR PTY, FOLLOW NORMAL ALGORITHM
2) NEWST2: LOAD 2,FKQN ;CURRENT QUEUE
-------
7-Aug-81 23:12:57-EDT,4181;000000000000
Mail-from: SU-SCORE rcvd at 7-Aug-81 2312-EDT
Mail-from: ARPANET site USC-ISIC rcvd at 7-Aug-81 1521-PDT
Date: 7 Aug 1981 1515-PDT
From: JGOLDBERGER at USC-ISIC (Joel Goldberger)
Subject: Problems CRJOBing detached jobs
To: Admin.MRC at SU-SCORE
Remailed-date: 7 Aug 1981 1953-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Problem:1) CRJOBing a detached job hangs on the DVCHR in RTTYMD
2) When you "CRJOB" a detached job and then attach to it, the terminal
modes are wrong (echo is off, etc.) and if you try to continue the
fork that was running the EXEC says "Program never RUN".
Cause: 1) The Fork created by CRJOB is never set up as one belonging to the
EXEC and therefore never marked as RUN.
2) The initial TTY modes saved at startup are junk since they apply
to a detached terminal.
Solution: 1) Change CMDN5E to do standard setup for an EXEC owned fork and
mark it as having been run.
2) Make RTTYMD recognize detached state and read TTY modes from
some known terminal. On our systems TTY1 is the error TTY: and
always has valid modes or a reasonable nature.
3) Make LTTYMD avoid DVCHR when no TTY attached
--------------------------------------------------
CMDN5E:
; Check to see if CRJOB/PRARG start up & if so, a program to run
SKIPE CRPRA ; CRJOB start up?
JRST [ HRRZ A,CRPRA+.CJPLP ; Yes, get flags ptr
MOVE B,CRPRA(A) ; then flags
TLNN B,(1B2) ; Want fork started?
JRST .+1 ; No
MOVEI A,.FKSZE ;#01 Get a Buffer for FRKTBL entry
MOVEI B,XDICT ;#01 From Perm Free Space
CALL GETMEM ;#01
HALTF ;#01 Can't happen at this point
MOVE Q1,B ;#01 Save Pointer
MOVE A,FORK ;#01 Get fork handle
MOVX B,FK%RUN ;#01 Flag it as having run
IORM B,SLFTAB(A) ;#01 ...
MOVEM A,RUNFK ;#01 and also as current running fork
HRRM Q1,SLFTAB(A) ;#01 Save addr in FRKTAB
MOVSI B,.FHSLF ;#01 We own it
MOVEM B,.FKOWN(Q1) ;#01 ...
MOVSI B,ITTYMD ;#01 Use Initial TTY modes
HRRI B,.FKPTM(Q1) ;#01 Loc for Program/TTY modes
BLT B,.FKPTM+NTTYMD+1(Q1) ;#01 Store the modes
HRRZ A,CRPRA+.CJPKP ; Get ptr to fork & SFRKV offset
HRRZ B,CRPRA(A)
CALL CLPRA ; Clear CRJOB/PRARG area
PUSH P,[CMDIN4] ; Where to return when done
JRST ..STCR] ; Run it
CALL CLPRA
----------
SETIOF:: GJINF ;#01 Find out if terminal attached
HRRZ A,CIJFN ;FIND OUT WHERE WE'RE READING FROM
SETZM TINPF ;#01 First assume not TTY:
SKIPGE D ;#01 If detached
CAIE A,.PRIIN ;#01 and reading from primary input
CAIA ;#01
RET ;#01 return now
DVCHR
LDB B,[221100,,B] ;GET DEVICE TYPE OF INPUT DEVICE
CAIN B,.DVTTY ;#01 GOOD GUESS?
SETOM TINPF ;#01 NO, LOUSY ONE.
RET
--------------------------------------------------
LTTYMD: SKIPN (Q1) ;DO NOTHING IF BLOCK IS 0 DUE TO A BUG OR
RET ;A STRANGE INTERRUPT-RESTART SEQUENCE
ATSAVE
MOVEI A,.CTTRM
MOVE B,TTWMOD(Q1) ;FILE MODE WORD
TXZ B,TT%OSP ;ENSURE NO OUTPUT SUPPRESS
SFMOD
GJINF ;#01
JUMPL D,NOTTY1 ;#01 Avoid DVCHR & MTOPR if detached
MOVEI A,.CTTRM ;#01
DVCHR ;MTOPR WORKS ON TTY ONLY
--------------------------------------------------
RTTYMD: ATSAVE
STKVAR <TERMNO> ;#01 Variable for TTY designator
MOVEI A,.CTTRM ;#01 Assume we'll use .CTTRM
MOVEM A,TERMNO ;#01 ...
GJINF ;#01 Check for Detached
JUMPL D,[MOVEI A,.TTDES+1 ;#01 Detached, use TTY1 (It has reasonable
;#01 modes )
MOVEM A,TERMNO ;#01
JRST .+1 ] ;#01 Rejoin the flow
MOVE A,TERMNO ;#01 Use whichever was selected
RFMOD
MOVEM B,TTWMOD(Q1)
DVCHR ;MTOPR WORKS ON TTY ONLY
LDB B,[POINTR B,DV%TYP] ;GET DEVICE TYPE CODE
CAIE B,.DVTTY ;SKIP IF IT'S A TERMINAL
JRST NOTTY2 ;NO - NOT A TTY
MOVEI A,4 ;PUT LENGTH INTO BLOCK
MOVEM A,TTWMSK(Q1)
MOVE A,TERMNO ;#01 NOW SAVE THE MASK
MOVEI B,.MORBM
MOVEI C,TTWMSK(Q1)
MTOPR
ERJMP NOTTY2 ;ERROR MEANS WRONG MONITOR
MOVEI B,.MORFW ;NOW FOR THE FIELD WIDTH
MTOPR
MOVEM C,TTWFWT(Q1)
MOVEI B,.MOSFW
SETZ C, ;TURN OFF FIELD WIDTH
MTOPR
NOTTY2: MOVE A,TERMNO ;#01
-------
10-Aug-81 18:03:10-EDT,1455;000000000000
Mail-from: SU-SCORE rcvd at 10-Aug-81 1803-EDT
Mail-from: ARPANET site RUTGERS rcvd at 7-Aug-81 2210-PDT
Date: 8 Aug 1981 0102-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: Performance improvement for Class-Scheduler
To: JGOLDBERGER at USC-ISIC
cc: Admin.MRC at SU-SCORE
In-Reply-To: Your message of 7-Aug-81 1813-EDT
Remailed-date: 9 Aug 1981 1437-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
It is not clear to me that the reported change for Q1 and Q2 is really
a bug fix. I can see that some sites might want it that way. However
the reason we turned on the class scheduler was that compiles were never
getting done. Our interpretation was the "interactive" jobs were taking
over the system. Now I am as willing as the next man to give a certain
priority to jobs coming out of TI wait. But I would like to restrict
this priority to jobs that are "well-behaved". It is quite possible to
create interactive tasks that take more than their fair share of the
CPU. I want them held in check, to allow the rest of us to get some
work done. I believe that the class scheduler as supplied by DEC does
this. It may result in spotty response now and then, but my video
editor is still usable, and people are getting work done.
I would be curious whether you believe that your patch will have ill
effects for us.
-------
10-Aug-81 18:49:09-EDT,868;000000000000
Mail-from: SU-SCORE rcvd at 10-Aug-81 1849-EDT
Date: 10 Aug 1981 1545-PDT
From: Bob Knight <ADMIN.KNIGHT at SU-SCORE>
Subject: Wedged LPTSPLs.
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
We at LOTS have seen a lot of wedged LPTSPLs. The symptom is that LPTSPL has
just executed a MTOPR with an argument of .MONOP ($MTOPR called from OUTDMP+4
in LPTSPL), and is in a scheduler test of STSWAT (wait for status has arrived
from the -11). Lighting bits 19 (status has arrived) and 30 (EOF) in LPTST1
in the monitor cures it. The problem is intermittent and has been observed
both on a vanilla-hardware -20 with a R4 front end and 2 -20s with a Print-
ronix interface and R3A front end. Somebody's dropping a status response on
the floor, but we aren't sure who yet. Has anyone out there seen this prob-
lem?
Bob Knight
ADMIN.KNIGHT@SCORE
-------
10-Aug-81 20:12:37-EDT,612;000000000000
Mail-from: SU-SCORE rcvd at 10-Aug-81 2012-EDT
Mail-from: ARPANET site CIT-20 rcvd at 10-Aug-81 1409-PDT
Date: 10 Aug 1981 1409-PDT
From: Barry Megdal <BARRY at CIT-20>
Subject: bliss-11
To: admin.mrc at SU-SCORE
Remailed-date: 10 Aug 1981 1647-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
I'm interested in getting a copy of a BLISS-11 compiler (to run on a 20).
Ive heard that there are various versions around. Are you familiar with
said versions and from where I can get them? Else, who should I ask?
Thanks.
B. Megdal
-------
10-Aug-81 23:16:55-EDT,536;000000000000
Mail-from: SU-SCORE rcvd at 10-Aug-81 2316-EDT
Mail-from: ARPANET site USC-ECL rcvd at 10-Aug-81 1717-PDT
Date: 10 Aug 1981 1714-PDT
From: BEC.SHAPIN at USC-ECL
Subject: FORUM for tops20
To: admin.mrc at SU-SCORE
cc: bec.shapin at USC-ECL
Remailed-date: 10 Aug 1981 1722-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Mark,
Do you know if CONFER has been converted for TOPS20 or
know of any TOPS 20 computer aided conferencing system?
Ted Shapin.
-------
12-Aug-81 02:05:25-EDT,2545;000000000001
Mail-from: SU-SCORE rcvd at 12-Aug-81 0205-EDT
Mail-from: ARPANET site MIT-XX rcvd at 11-Aug-81 1704-PDT
Date: 11 Aug 1981 2003-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Several things
To: admin.mrc at SU-SCORE
Remailed-date: 11 Aug 1981 2257-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
The following are some things of general interest.
- In the category "now that we've got you hooked...": We just
received the renewal for our "Binary Program Update Service
Agreement" from DEC on which they informed us that the "TOPS-20
Source Package" is "no longer available". Some checking with our
local sales people turns up the fact that instead of the present
"self-maintenance" agreement whereby DEC supplies new source
releases to source licensees, they are going to charge $8K per
release. This of course assumes that you've already coughed up the
$??,000 for the source license in the first place.
Does anyone have more (or conflicting) information on this subject?
It seems to me that this new arrangement is somewhat in conflict
(at least ethically) with the understanding one got when one bought
a source license.
- In the category bugs: (1) I had a DUMPER problem which showed up
when doing a retrieve. Apparently when doing some ARCHIVE, DUMPER
numbered the 1st saveset on a tape "2", the 2nd "3", etc. The
problem is that the files saved in the 2nd saveset (number "3")
had their tape location saved in the FDB as saveset "2". When
a retrieve was done, the file was erroneously retrieved from
the 1st saveset on the tape (DUMPER RETRIEVE just looks at the
tape#:ss#:file# when it retrieves the file). Anyone seen
anything like it?
(2) I saw a MONPDL BUGHLT. When I looked at UPDL in the dump,
the process was deep inside COMND and apparently got a carrier
off interrupt and jumped to JOBCOF to logout. I don't think this
would have blown the stack except for the fact that for some reason
while in the JOBCOF logic, it got the interrupt again and re-entered
at JOBCOF. Any suggestions on increasing the size of UPDL?
- In the category "folklore": can anyone tell me what area of the
monitor one can expect to be trashed in a dump from having been
overwritten by BOOT? For a while I've been looking at dumps with the
RESCD around LCKTTY trashed and it wasn't until now that I thought
that this might be due to BOOT.
-- Nat Mishkin
-------
12-Aug-81 02:21:26-EDT,1070;000000000001
Mail-from: SU-SCORE rcvd at 12-Aug-81 0221-EDT
Date: 11 Aug 1981 2311-PDT
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: Several things
To: NWM at MIT-XX
cc: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
In-Reply-To: Your message of 11-Aug-81 1703-PDT
About your MONPDL bug halts due to recursive JOBCOF calls; I
know that can happen for ARPANET jobs which get carrier off
interrupts while in the middle of COMND (or while the dynamic
data base for the TTY is locked). I fixed it by setting a new
flag in the dynamic data saying "already in JOBCOF"; if that flag
is set then JOBCOF just dismisses.
If the terminal dynamic data base is locked, it cannot be
detached. JOBCOF tries to detach the job, but it can't. Since
the job is on a network terminal, it tries to close the network
connection because it is detaching (or so it thinks!). Closing
the network terminal causes a carrier off PSI, and... RECURSION!
-- Mark --
-------
12-Aug-81 03:01:59-EDT,1751;000000000000
Mail-from: SU-SCORE rcvd at 12-Aug-81 0301-EDT
Mail-from: ARPANET site AFSC-HQ rcvd at 7-Aug-81 1259-PDT
Date: 7 Aug 1981 1558-EDT
From: Major Bob Baker <BAKER at AFSC-HQ>
To: ADMIN.MRC at SCORE
cc: BAKER at AFSC-HQ
Subject: PA1050 Problem
Message-ID: <MS"5(1646)"11750298609.6.30.119572 at AFSC-HQ>
Remailed-date: 11 Aug 1981 2349-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Mark,
Have you worked with the TOPS-20 compatibility package, PA1050?
I'm having a problem because the INPUT UUO works differently on
TOPS-10 and TOPS-20. The problem shows up when I have INITed
my controlling TTY and am reading from it with INPUT. If I type
some non-break characters and then a Ctrl-Z, TOPS-10 works as
follows: As soon as Ctrl-Z is typed, the INPUT UUO returns to
the program. The end-of-file flag (as determined by STATZ or
STATO) is not set. The program can then process the characters
in the input buffer, up to and including the Ctrl-Z. The next
INPUT call returns immediately with the EOF flag set. In other
words, if INPUT returns with EOF set, it means the buffer is
empty and the end-of-file condition (Ctrl-Z) was detected on
the previous INPUT.
Under TOPS-20, when Ctrl-Z is typed the INPUT UUO returns to the
program as with TOPS-10, but the EOF flag is already set. The
program sees this (with a STATO), assumes it has processed all
input, and goes on its way. Thus it fails to process the
characters read in by the last INPUT before the Ctrl-Z.
Do you know if this difference is intentional? It doesn't seem
like it should be, because it can make programs which work under
TOPS-10 bomb under TOPS-20.
Bob Baker
--------
12-Aug-81 19:56:31-EDT,723;000000000000
Mail-from: SU-SCORE rcvd at 12-Aug-81 1956-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 12-Aug-81 0811-PDT
Date: 12 Aug 1981 0910-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Several things
To: NWM at MIT-XX, admin.mrc at SU-SCORE
In-Reply-To: Your message of 11-Aug-81 1803-MDT
Remailed-date: 12 Aug 1981 1651-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Re: the source issue. We were told the same thing, namely, that instead
of charging $4K per year for continuing a source license, there would be
a charge everytime a new monitor was released (but no annual charge).
The $8K seems high, but doesn't surprise me.
Randy
-------
12-Aug-81 20:05:23-EDT,1521;000000000000
Mail-from: SU-SCORE rcvd at 12-Aug-81 2005-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 12-Aug-81 0947-PDT
Date: 12 Aug 1981 1144-CDT
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Re: Several things
To: NWM at MIT-XX, admin.mrc at SU-SCORE
In-Reply-To: Your message of 11-Aug-81 1903-CDT
Remailed-date: 12 Aug 1981 1653-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
Regarding software maintenance licenses for monitor source sites:
We were also surprised that self-maintenance was no longer available.
The way DEC explained it to us was that somebody figured out that
new releases of the monitor, exec, and front-end sources are taking
place about every two years. Therefore, rather than pay n hundred
dollars a month for the self-maintenance service, they simply lump
the whole thing into a one-time fee at the time of the release.
In other words, the one-time price of a new release is supposed to
be pretty close to what 2 years of self maintenance would have
cost you.
It is easy to see what DEC is up to. At each of the last several
DECUS conferences, source sites have repeatedly pointed out that
binary patches provided in the standard SPR answers are of little
use to those who have to update source files. It seems to me that
we finally have DEC's answer on this: they have eliminated the
special self-maintenance service for source sites, making source-
level patches a moot point.
Clive
-------
12-Aug-81 20:16:49-EDT,6336;000000000000
Mail-from: SU-SCORE rcvd at 12-Aug-81 2016-EDT
Mail-from: ARPANET site RUTGERS rcvd at 12-Aug-81 1429-PDT
Date: 12 Aug 1981 1727-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: Several things
To: NWM at MIT-XX
cc: admin.mrc at SU-SCORE
In-Reply-To: Your message of 11-Aug-81 2003-EDT
Remailed-date: 12 Aug 1981 1704-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
1) The change in source maintenance is the result of demands from users
at DECUS. I was not one making the demand, but I think DEC has in good
faith responded to what they heard as user requests. The problem was
that monitors are released about once every 1.5 years. So if you have
a source update contract, as we (and I guess you) did, there were some
years during which you paid, but got nothing. Some sites had problems
with their auditors about that. Thus they have changed it so that you
pay only when there is an actual release. The charge for a release was
supposedly calculated to be 1.5 times the previous yearly charge, so that
things would come out the same in the end. Possibly it is 1.5 times
the previous charge plus some price increase, but there are price increases
all the time. I also prefer the old arrangement, and feel queasy under
the new one, but I can't come up with any concrete problem with it,
assuming DEC does what they say they will do (i.e. sell the new release
to all licensed sites for a price comparable with the old contract
price).
2) Yes, we have seen the problem with DUMPER also. Actually, we have
done a fair amount of work with DUMPER, and you (and others) might like
to take all or part of it. You should look at s:<4-bundled>dumper.*.
DEC is DEC's original. .MAC is our current. .DIF is an REDIT difference
file from which I have removed some of the more obviously site-dependent
changes (however I have not tested the version produced from it). Here
is a list of the changes we have made. (I hope whoever is scanning this
list at DEC will take note, as one or two of these have never been
SPR'ed.) I believe that edit 13 answers your particular question.
The edits marked with * are those that are present in DUMPER.DIF. You
should feel free to just take DUMPER.MAC. I think the only thing that
would be likely to cause incompatibilities is the fact that we don't
set files invisible when archiving them. The reason is that the EXEC
already does this. If you say ARCHIVE FOO, the EXEC sets FOO invisible.
The only way it could be visible when DUMPER gets to it is if the user
explicitly set it visible again. In that case it is considered
unfriendly for DUMPER to make it invisible again.
;local edits -*-.=1005
;1* - make it handle tops10 sfd's - not marked. This takes only a few lines
; of code, and makes migration from Tops-10 to Tops-20 feasible for
; sites that use SFD's on the 10. Also, it handles the fact that
; Tops-10 uses _ to separate the project and programmer numbers,
; while DUMPER thinks they use - [We have a special version of
; dumper in which the CREATE command works for Tops-10 BACKUP tapes.
; This was what we used for making our initial migration from Tops-10
; to Tops-20. We have not bothered to move that patch to later
; releases, since we don't anticipate remigrating.
;2 - add archive mode - this was an earlier archiving system, which we
; have now commented out (in edit 14)
;3 - add take command - needed by the old archiver, but generally useful.
; I use this for preparing SAIL and PASCAL export tapes.
;4 - add CSAVE command - needed by the old archiver. The problem was that
; we had to be able to write an arbitrary number of specified files.
; But a given SAVE command can only list about 10 files, or your
; job runs out of JFN's. CSAVE is like a save, but it continues a
; previous save set. So we just break the commands up into groups
; of 10 files, using CSAVE for all but the first.
;5 - daw 12/12/78 make dumper parse wild fields, not
; just wildcard them entirely
; from Dispatch 5/78 pg. 181 (SPR # 20-11419)
; This edit has been withdrawn, as DEC put it in
;6* - daw 12/3/80 fix loop due to Illegal Record Length
; from Dispatch 10/15/80 pg. 3-19 (SPR # 20-14491)
;7* - daw 12/3/80 avoid ?Drive probably offline due to TM03 error
; from Dispatch 10/15/80 pg. 3-23 (SPR # 20-14685)
;10 - daw 1/26/81 don't set file invisible when archiving - this
; is due to the way we use archiving, and other sites may prefer
; not to do it
;11* - daw 1/27/81 add /NOMAIL to not notify user by mail system
; This is needed mostly when doing reruns to repair odd events,
; something that is more common than we would like.
;12* - daw 2/11/81 shrink buffer after LNGFX1 so we don't dump
; too many pages for file.
; Otherwise some files come back with a few extra (garbage)
; pages when they are restored. In particular, any file edited with
; TVEDIT can't be edited with TVEDIT after a refresh!! This is
; essentially the same bug that was present in the EXEC's COPY command.
;13* - daw 3/10/81 show preference for saveset number in headers
; of tape over that in header of logical blocks
; We don't understand why these numbers ever disagree. This
; patch should be regarded as a workaround to allow you to retrieve
; files from archive tapes with inconsistent save set numbers. We
; leave it to DEC to fix the problem that causes this inconsistency.
; Howver even after they do, this patch will still be necessary to
; allow you to retrieve files from old tapes that still have the
; inconsistency.
;14* - daw 3/19/81 IGNORE becomes useful function from old ARCHIVE
; command; ARCHIVE becomes same as SAVE/ARCHIVE
; This is the edit that removes the old archive system. The old
; ARCHIVE command caused save set boundaries to be ignored when
; retrieving (since we stored the tape name but not save set number).
; That function turns out to be useful apart from out old archiver,
; so we have kept it as IGNORE (SAVESET BOUNDARIES). This requires
; only a few lines of code, and has been requested at many DECUS's.
; so DEC should surely install it.
ruedit==14 ;local edit number
-------
13-Aug-81 15:20:20-EDT,1087;000000000000
Mail-from: SU-SCORE rcvd at 13-Aug-81 1520-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 12-Aug-81 2030-PDT
Date: 12 Aug 1981 1832-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: more on the source issue
To: admin.mrc at SU-SCORE
Remailed-date: 13 Aug 1981 1215-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
We were told that there is one supposed additional advantage: namely, that
you can elect to skip a release of the source package, and then get
the next one, without paying a premium. Previously, if you let your
self-maintenance expire, you had to pay a large premium to re-start it at
a later time (this applied to both binary and source self-maint).
While I admit that no one will want to skip a monitor/exec release, some
might want to skip a release on the FE sources (which I believe is half
of the $8k). Or alternately, you could take a wait and see attitude to see
if you really needed the FE sources, and then order them for a given
release only if you needed them.
Randy
-------
13-Aug-81 15:53:29-EDT,834;000000000000
Mail-from: SU-SCORE rcvd at 13-Aug-81 1553-EDT
Date: 13 Aug 1981 1219-PDT
From: Ted Markowitz <G.TJM>
Subject: Working sets
To: admin.mrc
Remailed-date: 13 Aug 1981 1246-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
A question for the list:
Do you use working set pre-loading? Why or why why not?
My user community just recently changed in that I'm getting swamped
with jobs that seem to use large working sets (~350 pages) for extended
periods of time. I'm looking for a way to knock down the swapping rate
that is starting to balloon tremendously. I have a 10,000 page drum and
am now considering moving one pack of my PS: onto a separate channel to
ease contention. Any thoughts or useful experience would be much appreciated.
--ted
-------
14-Aug-81 04:42:19-EDT,551;000000000000
Mail-from: SU-SCORE rcvd at 14-Aug-81 0442-EDT
Date: 14 Aug 1981 0139-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: PAGER.MAC bug - FPD cleared in wrong word
To: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
I believe that the ANDCAM CX,-1(P) at PGUNT0 is wrong and
should be replaced with ANDCAM CX,(P). The alleged purpose of
this code is to clear FPD (first part done), but -1(P) is the
PC location, not the flags word.
-------
14-Aug-81 07:46:44-EDT,0001087;000000000000
Date: 14 Aug 1981 0746-EDT
From: HEDRICK
Subject: [MILLER at DEC-MARLBORO: Re: Performance improvement for Class-Scheduler]
To: TOPS-20
Mail-from: DEC-MARLBORO rcvd at 13-Aug-81 1531-EDT
Date: 13 Aug 1981 1532-EDT
From: MILLER at DEC-MARLBORO
To: HEDRICK at RUTGERS
Subject: Re: Performance improvement for Class-Scheduler
Message-ID: <MS"5(1631)"11751866734.35.258.11194 at DEC-MARLBORO>
In-reply-to: Message from HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
of 8-Aug-81 0102-EDT
I am responsible for the strategy in question and I know for sure
that it will have an ill effect. The reason the scheduler does
not absolutely favor interactive jobs is exactly the reason you have
stated.
Note that interactive jobs suffer only if the class as a whole
is being promiscuous. This requires that one or members are
being malicous, or the class has not purchased sufficient computes.
Either way, the policy decision seems a far better choice than denying
others their fair share.
--------
---------------
========
14-Aug-81 15:11:17-EDT,1492;000000000000
Mail-from: SU-SCORE rcvd at 14-Aug-81 1511-EDT
Mail-from: ARPANET site CMU-20C rcvd at 14-Aug-81 0425-PDT
Date: 14 Aug 1981 0722-EDT
From: WOHL at CMU-20C
Subject: Re: PAGER.MAC bug - FPD cleared in wrong word
To: Admin.MRC at SU-SCORE
In-Reply-To: Your message of 14-Aug-81 0439-EDT
Remailed-date: 14 Aug 1981 1201-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.111: ;
I submitted an spr to that effect just before leaving for boston.
It causes all sorts of problems on a disk full. For example map one page
of some file read only (or into a disk full directory) then do a GFUST%
giving a byte pointer into the beggining of the page. After a long pause,
the string ends up at the begining of the following page! Ofcourse if
there are many non-writable pages it hangs the job with the directory locked..
The problem is, what happens to PXCT of a IDPB while NOINT that
gets an illref of some sort because the user page can't get created. What
is supposed to happen is the IDPB is skipped, that byte is never returned
to the user, as soon as you go OKINT you get the PSI. What happens with
FPD set wrong is that the IDPB is restarted instead, but since the bytepointer
has been incremented, it gets an illref again and so on. Eventualy it
stepps of the end of the non-writable pages (given enough time for lots of
pages) and deposits the string into the first writable page thereafter.
Aaron
-------
15-Aug-81 13:30:20-EDT,632;000000000000
Mail-from: SU-SCORE rcvd at 15-Aug-81 1330-EDT
Date: 15 Aug 1981 1025-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: test message
To: TOPS-20 at SU-SCORE
This is a test of the new TOPS-20@SCORE mailing list. TOPS-20@SCORE
forwards to @PS:<ADMIN.MRC>TOPS-20.DIS, and can be referenced as an
ARPANET address. If you have received this message, you are on the
TOPS-20 distribution list.
Mail for the distribution list can still be sent to me for distribution,
or it can be sent directly.
-- Mark --
-------
15-Aug-81 15:58:25-EDT,467;000000000000
Mail-from: SU-SCORE rcvd at 15-Aug-81 1558-EDT
Date: 15 Aug 1981 1250-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: bug in answer to SPR 20-15773
To: TOPS-20 at SU-SCORE
There is a bug in the answer to SPR 20-15773 (CTCO 555.1). The
patch at DSK10A+4 should read SKIPN T3 followed by MOVSI T3,.STDFE
(it was published as MOVEI T3,.STDFE).
-------
15-Aug-81 21:34:29-EDT,1739;000000000000
Mail-from: SU-SCORE rcvd at 15-Aug-81 2134-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 15-Aug-81 1820-PDT
Date: 15 August 1981 18:19-PDT (Saturday)
From: Joel Goldberger <JGOLDBERGER at USC-ISIB>
To: Ted Markowitz <G.TJM at 1257-PDT>
Cc: admin.mrc at Score
Subject: Working sets
Remailed-date: 15 Aug 1981 1830-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
Date: Thursday, 13 August 1981 12:19-PDT
From: Ted Markowitz <G.TJM at 1257-PDT>
To: admin.mrc at 1257-PDT
Re: Working sets
Remailed-date: 13 Aug 1981 1246-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: [SU-SCORE]<Admin.MRC>TOPS-20.DIS.110: ;
A question for the list:
Do you use working set pre-loading? Why or why why not?
My user community just recently changed in that I'm getting swamped
with jobs that seem to use large working sets (~350 pages) for extended
periods of time. I'm looking for a way to knock down the swapping rate
that is starting to balloon tremendously. I have a 10,000 page drum and
am now considering moving one pack of my PS: onto a separate channel to
ease contention. Any thoughts or useful experience would be much appreciated.
--ted
Ted,
We tried it a few times at periods of heavy load and while it did seem to
reduce swapping rates the effect on load-average was far too adverse to leave
it on. The explanation is fairly obvious since more jobs couldn't run since
they couldn't get swapped in. Performance was as one might expect, once you
got in core it was great, but if you blocked for any reason it was a long time
before you ran again.
Joel Goldberger
15-Aug-81 21:51:55-EDT,2881;000000000000
Mail-from: SU-SCORE rcvd at 15-Aug-81 2151-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 15-Aug-81 1840-PDT
Date: 15 August 1981 18:33-PDT (Saturday)
From: Joel Goldberger <JGOLDBERGER at USC-ISIB>
To: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Cc: Admin.MRC at SU-SCORE
Subject: Performance improvement for Class-Scheduler
Remailed-date: 15 Aug 1981 1845-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
Date: Friday, 7 August 1981 22:02-PDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
To: JGOLDBERGER at USC-ISIC
cc: Admin.MRC at SU-SCORE
Re: Performance improvement for Class-Scheduler
It is not clear to me that the reported change for Q1 and Q2 is really
a bug fix. I can see that some sites might want it that way. However
the reason we turned on the class scheduler was that compiles were never
getting done. Our interpretation was the "interactive" jobs were taking
over the system. Now I am as willing as the next man to give a certain
priority to jobs coming out of TI wait. But I would like to restrict
this priority to jobs that are "well-behaved". It is quite possible to
create interactive tasks that take more than their fair share of the
CPU. I want them held in check, to allow the rest of us to get some
work done. I believe that the class scheduler as supplied by DEC does
this. It may result in spotty response now and then, but my video
editor is still usable, and people are getting work done.
I would be curious whether you believe that your patch will have ill
effects for us.
It was our experience that the DEC definition of "good-behavior" was too
restricted, and many of us that thought we were behaving pretty well were
still getting terrible response. Our situation is somewhat different from
yours in that we actually have to enforce allocations of CPU usage among
our customers, rather than just having a large user community that all
deserve and expect the same level of performance. Because of this restriction
we have classes set up rather disproportionately, and it was our observation
that the classes with the big allocations were killing the little ones since
they rarely ran over their share (misbehaved in DEC's eyes). Since the smaller
classes were almost always over their allocation whenever a process in the big
class wanted the machine the little guy got thrown to the very end of the line.
The changes (which I never advertised as Bug Fixes) made life in the little
class atleast bearable. We have also monitored long-range percentages of CPU
utilization and haven't seen any real perturbation since making these changes,
that is the big classes are still getting most of the machine.
Joel Goldberger
17-Aug-81 11:27:36-EDT,524;000000000000
Mail-from: SU-SCORE rcvd at 17-Aug-81 1127-EDT
Mail-from: ARPANET site SU-SCORE rcvd at 17-Aug-81 0823-PDT
Date: 17 Aug 1981 0823-PDT
From: Ted Markowitz <G.TJM at SU-SCORE>
Subject: Opinions on Pre-loading
To: tops-20 at SU-SCORE
The consenus seems to be that there is no consensus! For some folks
it's a tremendous boost in performance and for others it's a disaster.
The best advice is to try it while monitoring the system's performance and
see if you like it.
Thanks for the responses.
--ted
-------
17-Aug-81 16:34:19-EDT,466;000000000000
Mail-from: SU-SCORE rcvd at 17-Aug-81 1634-EDT
Mail-from: ARPANET site CIT-20 rcvd at 17-Aug-81 1329-PDT
Date: 17 Aug 1981 1327-PDT
From: Barry Megdal <BARRY at CIT-20>
Subject: Who's on list
To: tops-20 at SU-SCORE
Is anyone from Caltech on the TOPS-20 list? (Ours systems people have
changed... Lindblad is gone). If he was the only one, you should replace
him with me (BARRY@CIT-20). Dick Lang (DICK@CIT-20) should also be on there.
Thanks.
-------
17-Aug-81 19:49:37-EDT,1636;000000000000
Mail-from: SU-SCORE rcvd at 17-Aug-81 1949-EDT
Date: 17 Aug 1981 1645-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: Administrivia with TOPS-20@SCORE
To: BARRY at CIT-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 17-Aug-81 1327-PDT
Barry, I have updated the TOPS-20 mailing list per your
request.
Everybody: Please be careful about what you send to
TOPS-20@SCORE. Requests for additions and deletions to the
mailing list should be sent to me and not to the list.
TOPS-20@SCORE was created for the convenience of people who knew
their message should go out on the list and wanted to send it
"directly". It also saves me the effort of redistributing these
messages. Other large lists on the network have been forced to
move back to a "moderator" to act as a filter; I hope we're a
tight enough community that we don't have to do this.
In case anybody wants to see the list of members on the
list, it is online at SU-SCORE as PS:<ADMIN.MRC>TOPS-20.DIS.
This file can be FTP'd from SCORE without an FTP login, or by
logging in as user ANONYMOUS with any password.
I would also like to mention here the existance of a mailing
list at MIT-XX, "BUG-TWENEX", which MIT-XX's users report bugs in
their system to. At times this mailing list has interesting
mail, but it is NOT a safe mailing list to report security bugs
to. The MIT systems people normally forward messages of general
interest from this list to me to redistribute to TOPS-20@SCORE.
-- Mark --
-------
19-Aug-81 00:09:03-EDT,687;000000000000
Mail-from: SU-SCORE rcvd at 19-Aug-81 0008-EDT
Mail-from: ARPANET site RAND-UNIX rcvd at 18-Aug-81 2026-PDT
Date: Tuesday, 18 Aug 1981 18:22-PDT
To: admin.mrc at SU-SCORE
Cc: mike at RAND-UNIX
Subject: AN20 for vdh
From: mike at RAND-UNIX
Remailed-date: 18 Aug 1981 2036-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
Mark,
If you don't know the answer to this offhand, can you forward it
to the list? Thanks.
What is involved in a) connecting a 20 to a VDH connection on a
TIP and b) converting an AN20 local host connection to an AN20
VDH connection? I already know that the VDH is a lose.
Thanks,
Michael Wahrman
20-Aug-81 16:33:32-EDT,736;000000000000
Mail-from: SU-SCORE rcvd at 20-Aug-81 1633-EDT
Mail-from: ARPANET site SU-SCORE rcvd at 20-Aug-81 1325-PDT
Date: 20 Aug 1981 1325-PDT
From: Patrick Milligan <CSD.Milligan at SU-SCORE>
Subject: Archived TOPS-20.Dist mail
To: TOPS-20 at SU-SCORE
Does anyone keep an archive of TOPS-20.Dist [and Twenex-wizards] mail?
I am missing all mail from 6-May-81 to 18-May-81 due to a tape screwup,
and I would like to fill in the hole. [Admin.MRC doesn't keep an
archive, although he's thinking about it]. If an archive can
be found, maybe we can set up a generally available place to keep
it...
Reply to CSD.Milligan@SU-SCORE. If an archive is set up, I will
let everyone know about it...
Thanks...
-- Patrick
-------
20-Aug-81 23:26:42-EDT,684;000000000000
Mail-from: SU-SCORE rcvd at 20-Aug-81 2326-EDT
Mail-from: ARPANET site RUTGERS rcvd at 20-Aug-81 2020-PDT
Date: 20 Aug 1981 2106-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: Re: Archived TOPS-20.Dist mail
To: CSD.Milligan at SU-SCORE
cc: TOPS-20 at SU-SCORE, JSol at RUTGERS
In-Reply-To: Your message of 20-Aug-81 1625-EDT
Rutgers has been keeping Archives of all the information on
TOPS-20.DIS in a private directory available only to Systems
programmers. Mail dating back to 1979 (don't know when in 79)
is archived on tape, but the most recent stuff (since 1-jan-1981)
are online. I'll send you the stuff from that time in a
second.
/Jsol
-------
20-Aug-81 23:55:55-EDT,1319;000000000000
Mail-from: SU-SCORE rcvd at 20-Aug-81 2355-EDT
Date: 20 Aug 1981 2048-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: patch in NETWRK
To: TOPS-20 at SU-SCORE
I sent this out as a source level patch a while ago, but a site recently
asked me for a DDT version. This patch alleges to avoid IMPMSO BUGINFs;
it makes sure there is a valid link set up before doing the link closing
code.
If you have this patch installed, the symbol LINKF is defined in NETWRK:
FLG(LINKF,R,IOS,400000) ; Link table index valid
The DDT patch follows:
TOPS-20 Command processor 4(560)
@ENABLE
$GET SYSTEM:MONITR
$START 140
DDT
NETWRK$:
NETCLL 1/ JRST IMPCLL JRST FFF
FFF/ 0 TRZE IOS,400000
FFF2+1/ 0 CALL IMPCLL
FFF2+2/ 0 MOVEM IOS,NETSTS(UNIT)
FFF2+3/ 0 RET
FFF2+4/ 0 FFF:
NETOPS+2/ RET JRST FFF
FFF/ 0 MOVEI IOS,400000
FFF+1/ 0 IORB IOS,NETSTS(UNIT)$>
FFF+2/ 0 RET
FFF+3/ 0 FFF:
DOFSMA+13/ PUSHJ P,@ACTAB(T2) $<
FFF/ 0 MOVE IOS,NETSTS(UNIT)$>
FFF+1/ 0 PUSHJ P,@ACTAB(T2)
FFF+2/ 0 JUMPA T1,DOFSMA+14
FFF+3/ 0 JUMPA T2,DOFSMA+15
DOFSMA+13/ PUSHJ P,@ACTAB(T2) JUMPA FFF2+11
^Z
$SAVE SYSTEM:MONITR.EXE
-------
21-Aug-81 01:32:49-EDT,1157;000000000000
Mail-from: SU-SCORE rcvd at 21-Aug-81 0132-EDT
Date: 20 Aug 1981 2224-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: correction to previous message
To: TOPS-20 at SU-SCORE
There was a minor typographical error in the previous
message re: patch to NETWRK. A spurious DDT end patch
instruction was listed in the second of the three patches. The
corrected patch follows:
TOPS-20 Command processor 4(560)
@ENABLE
$GET SYSTEM:MONITR
$START 140
DDT
NETWRK$:
NETCLL 1/ JRST IMPCLL JRST FFF
FFF/ 0 TRZE IOS,400000
FFF2+1/ 0 CALL IMPCLL
FFF2+2/ 0 MOVEM IOS,NETSTS(UNIT)
FFF2+3/ 0 RET
FFF2+4/ 0 FFF:
NETOPS+2/ RET JRST FFF
FFF/ 0 MOVEI IOS,400000
FFF+1/ 0 IORB IOS,NETSTS(UNIT)
FFF+2/ 0 RET
FFF+3/ 0 FFF:
DOFSMA+13/ PUSHJ P,@ACTAB(T2) $<
FFF/ 0 MOVE IOS,NETSTS(UNIT)$>
FFF+1/ 0 PUSHJ P,@ACTAB(T2)
FFF+2/ 0 JUMPA T1,DOFSMA+14
FFF+3/ 0 JUMPA T2,DOFSMA+15
DOFSMA+13/ PUSHJ P,@ACTAB(T2) JUMPA FFF2+11
^Z
$SAVE SYSTEM:MONITR.EXE
-------
21-Aug-81 19:11:39-EDT,1245;000000000000
Mail-from: SU-SCORE rcvd at 21-Aug-81 1911-EDT
Mail-from: ARPANET site SU-SCORE rcvd at 21-Aug-81 1604-PDT
Date: 21 Aug 1981 1603-PDT
From: Patrick Milligan <CSD.Milligan at SU-SCORE>
Subject: Re: Archived TOPS-20.Dis mail
To: TOPS-20 at SU-SCORE
Thanks to all of you who replied to my request. There were several
people who either mailed me the messages, a pointer to an archive, or
offered to make the message available.
Due to the potentially confidential nature of some of the messages
on TOPS-20.Dis (especially those relating to security holes), it is
probably not a great idea to have the archives generally available
for FTP via an ANONYMOUS login... Perhaps a special FTP login
(TOPS-20?) on some host (SU-SCORE?) could be set up, and the password
obtained by sending a request to Admin.MRC@SU-SCORE... Any ideas or
comments?
The most complete set of archived mail that I ran across was via
Jonathan Alan Soloman <JSol at Rutgers>. He has archives on magtape
going back to 1979, and has messages since 1-Jan-81 online. If we
can setup a reasonably secure archive, we appear to have no problems
with "stocking" it with back issues...
Thanks again to fellow TOPS-20.Dis packrats...
-- Patrick
-------
23-Aug-81 12:26:12-EDT,578;000000000000
Mail-from: SU-SCORE rcvd at 23-Aug-81 1226-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 23-Aug-81 0918-PDT
Date: 23 Aug 1981 1217-EDT
From: Kevin Paetzold <PAETZOLD at RADC-TOPS20>
To: TOPS-20 at SU-SCORE
Reply-to: Paetzold at RADC-TOPS20
Mail-stop: MR1-2/L10
Telephone: 617-467-7430
Subject: newest greatest netsrv
Message-ID: <MS"5(1646)"11754452721.16.240.192941 at RADC-TOPS20>
is in RADC-TOPS20::PS:<PAETZOLD>NETSRV.MAC.2. Big bug fix and a new
feature switch (FT.TIP). You probably do not want ft.tip on. DEC-2136
does however.
KWP
--------
24-Aug-81 13:30:11-EDT,537;000000000000
Mail-from: SU-SCORE rcvd at 24-Aug-81 1330-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 24-Aug-81 1023-PDT
Date: 24 Aug 1981 1322-EDT
From: Kevin Paetzold <PAETZOLD at RADC-TOPS20>
To: TOPS-20 at SU-SCORE
Reply-to: Paetzold at RADC-TOPS20
Mail-stop: MR1-2/L10
Telephone: 617-467-7430
Subject: NETSRV
Message-ID: <MS"5(1646)"11754726811.9.240.14199 at RADC-TOPS20>
For those who dont know or havent figured it out yet.
NETSRV now reads initial commands from SYSTEM NETSRV.RUN and not
SYSTEM:NETSRV.CMD.
--------
24-Aug-81 14:36:45-EDT,1123;000000000000
Mail-from: SU-SCORE rcvd at 24-Aug-81 1436-EDT
Date: 24 Aug 1981 1117-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: What NETSRV is
To: TOPS-20 at SU-SCORE
Re: Kevin Paetzold's earlier messages to TOPS-20@SCORE about
a new version of NETSRV available:
For those of you who may not have heard of NETSRV, it is a
new program that replaces both NETSER and FTSCTL (the SYSJOB
subjobs which handle incoming TELNET and FTP connections).
NETSRV is a major change for the better, and I believe it will be
part of DEC's Release 5 distribution of TOPS-20AN. Considering
all the bugs in NETSER/FTSCTL (including the security bug that a
host can crash your SYSJOB by continually leaving half-opened
connections which NETSER/FTSCTL never close until job 0 runs out
of JFNs), I cannot recomment NETSRV more highly for ARPANET
TOPS-20 sites.
There are some basic hooks in NETSRV for other networks, and
I intend to implement 3mb Ethernet functionality in it shortly.
-- Mark --
-------
25-Aug-81 14:54:55-EDT,331;000000000000
Mail-from: SU-SCORE rcvd at 25-Aug-81 1454-EDT
Mail-from: ARPANET site SRI-AI rcvd at 25-Aug-81 1148-PDT
Date: 25 Aug 1981 1148-PDT
From: ROODE at SRI-AI (David Roode)
Subject: MTU tape copy program
To: TOPS-20 at SU-SCORE
Does anyone have sources to this program? It doesn't do
some things I would like it to.
-------
29-Aug-81 00:54:42-EDT,736;000000000000
Mail-from: SU-SCORE rcvd at 29-Aug-81 0054-EDT
Mail-from: ARPANET site RUTGERS rcvd at 28-Aug-81 2150-PDT
Date: 29 Aug 1981 0049-EDT
From: PLEASANT at RUTGERS (Mel Pleasant)
Subject: QUASAR documentation
To: tops-20 at SU-SCORE
Does anyone have some online documentation on the entire QUASAR
queueing system? Also, for those of you who have played with it;
what pitfalls should I be aware of when creating a new spooled
device.
Any information would be apreciated. I am willing to put together
some type of document that will describe the wheres and hows of
playing with the QUASAR system so that others will not have to suffer
the fate of modifying it without help.......
-Mel
-------
29-Aug-81 13:58:40-EDT,588;000000000000
Mail-from: SU-SCORE rcvd at 29-Aug-81 1358-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 29-Aug-81 1053-PDT
Date: 29 Aug 1981 1152-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: QUASAR documentation
To: PLEASANT at RUTGERS, tops-20 at SU-SCORE
In-Reply-To: Your message of 28-Aug-81 2249-MDT
The only documentation of know of is
a) the various .unv files - they contain fairly complete descriptions of
of the control blocks
b) a hard-copy document describing the quasar run time system. I've never
seen an on-line version of this document.
Randy
-------
29-Aug-81 16:55:13-EDT,569;000000000000
Mail-from: SU-SCORE rcvd at 29-Aug-81 1655-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 29-Aug-81 1350-PDT
Date: 29 Aug 1981 1645-EDT
From: Kevin Paetzold <PAETZOLD at RADC-TOPS20>
To: PLEASANT at RUTGERS, tops-20 at SU-SCORE
Reply-to: Paetzold at RADC-TOPS20
Mail-stop: MR1-2/L10
Telephone: 617-467-7430
Subject: Re: QUASAR documentation
Message-ID: <MS"5(1646)"11756074404.37.240.16841 at RADC-TOPS20>
In-reply-to: Message from PLEASANT at RUTGERS (Mel Pleasant)
of 29-Aug-81 0049-EDT
Documentation for GLXLIB exists.
--------
1-Sep-81 13:30:39-EDT,976;000000000000
Mail-from: SU-SCORE rcvd at 1-Sep-81 1330-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 1-Sep-81 1020-PDT
Date: 1 Sep 1981 1320-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: tops-20 at SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: DEC's SNDMSG
Message-ID: <MS"5(1646)"11756823498.22.158.14496 at RADC-TOPS20>
DEC's distributed copy of SNDMSG has a bug which may or may not
be known to the TOPS-20 distribution list, but here goes anyway.
With the new HSTNAM.TXT file, SNDMSG overflows the HSTTAB table
but does not tell the user. This can be remedied by changing the
NHSTTB value to 4000, however it will still never tell when it
overflows.
At around SYSGET+17:
CAILE C,HSTTAB+NHSTTB ;OVERFLOW TABLE?
JRST SYSGTF
Can be changed to:
CAILE C,HSTTAB+NHSTTB ;OVERFLOW TABLE?
JRST [HRROI A,[ASCIZ/
?SNDMSG's host table overflowed.
/]
PSOUT
HALTF
JRST SYSGTF] ;CONTINUE IF THEY WANT TO
--------
1-Sep-81 17:49:46-EDT,746;000000000000
Mail-from: SU-SCORE rcvd at 1-Sep-81 1749-EDT
Mail-from: ARPANET site SRI-KL rcvd at 1-Sep-81 1128-PDT
Date: 1 Sep 1981 1122-PDT
From: LARSON at SRI-KL
Subject: re: DEC's SNDMSG
To: TOPS-20 at SU-SCORE
At the risk of flaming, I am puzzled why people keep ignoring the
ESOUT jsys. It will send the CR and LF if needed and the ?. It will
also clear the input buffer so there will be no problem with typeahead.
Here is Mark's fix (which I highly recommend - failing without a message
is bad form), modified to use ESOUT.
CAILE C,HSTTAB+NHSTTB ;OVERFLOW TABLE?
JRST [HRROI A,[ASCIZ /SNDMSG's host table overflowed.
/]
ESOUT ;give error message
HALTF ; and stop.
JRST SYSGTF] ;CONTINUE IF THEY WANT TO
-------
2-Sep-81 08:33:01-EDT,1083;000000000000
Mail-from: SU-SCORE rcvd at 2-Sep-81 0832-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 28-Aug-81 1618-PDT
Date: 28 Aug 1981 1618-PDT
From: Gilmurray at SUMEX-AIM
Subject: Tops-20 time bugs
To: Admin.MRC at SU-SCORE
Remailed-date: 2 Sep 1981 0511-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
Mark,
Consider the following times: 0023:00, 0024:00, and 0025:00. IDTIM% can
handle the 1st and 3rd OK. However, it gives an TILFX1 error on the 2nd.
I don't like that (especially since Tenex allows the 2nd format). The
following patches fix this bug(?):
ITN7+4/ CAIL => CAILE
CKMDT1 1/ GAIGE => CAIG
The equivalent bug exists in ODCNV% too and the fix is:
ODC2+6/ CAIL => CAILE
The issue is whether or not the time can be eactly 1 day. Personally I
can go either way on this but, in any case, 0024:00 shouldn't be illegal.
The above fixes treat 0024:00 as 24 hours (not minutes).
Also, I finallly got the 4 monitor loaded (including the PUP code) and
I'll start testing it next week.
Frank G.
-------
2-Sep-81 18:39:45-EDT,708;000000000000
Mail-from: SU-SCORE rcvd at 2-Sep-81 1839-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 2-Sep-81 1533-PDT
Date: 2 Sep 1981 1731-CDT
From: Clive Dawson <CC.Clive at UTEXAS-20>
Subject: Moving archived files
To: tops-20 at SU-SCORE
I need to move the contents of a directory from one structure to
another. Unfortunately, there are several off-line (archived) files
in the directory which COPY complains about. It seems that I'll
either have to retrieve all the files in order to move them, or
else use DUMPER to save the entire directory and restore it on the
other structure. Does anybody know of any easier way to do this
which doesn't involve the tape drive?
Thanks,
Clive
-------
2-Sep-81 19:56:36-EDT,549;000000000000
Mail-from: SU-SCORE rcvd at 2-Sep-81 1956-EDT
Mail-from: ARPANET site MIT-XX rcvd at 2-Sep-81 1650-PDT
Date: 2 Sep 1981 1950-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Archive
To: tops-20 at SU-SCORE
Can anyone explain to me why the archive system has the peculiar
property that archive "requests" are marked in the file being
archived while retrieve requests are handled by QUASAR? It is
incredibly painful to have to sweep the whole file system
to determine whether anyone wants any files archived.
-- Nat Mishkin
-------
2-Sep-81 20:06:34-EDT,448;000000000000
Mail-from: SU-SCORE rcvd at 2-Sep-81 2006-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 2-Sep-81 1701-PDT
Date: 2 Sep 1981 1758-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Archive
To: NWM at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 2-Sep-81 1750-MDT
Everyone (including it seems DEC) seems to agree that this assymetry is
stupid. Whether or not anything will ever get done about it is anyone's
guess.
-------
3-Sep-81 00:56:05-EDT,644;000000000000
Mail-from: SU-SCORE rcvd at 3-Sep-81 0056-EDT
Mail-from: ARPANET site SRI-KL rcvd at 2-Sep-81 2147-PDT
Date: 2 Sep 1981 1745-PDT
From: ROODE at SRI-KL (David Roode)
Subject: Re: Archive
To: NWM at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 2-Sep-81 1650-PDT
You have to sweep the filesystem anyway, if you are doing
forced migration. Maybe the system was designed with forced
migration as an assumption.
P.S. Anybody have any handle on what fraction of forced
migrations are never retrieved? Anybody have any
plans to arrange to have all the directory deadwood
pointing to such files cleaned out?
-------
3-Sep-81 01:14:04-EDT,438;000000000000
Mail-from: SU-SCORE rcvd at 3-Sep-81 0114-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 2-Sep-81 2207-PDT
Date: 2 Sep 1981 2303-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Archive
To: ROODE at SRI-KL, NWM at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 2-Sep-81 1845-MDT
Yes, but even for forced migration you would only have to sweep the file
system ONCE, not twice like the current system does.
-------
4-Sep-81 09:02:37-EDT,484;000000000000
Mail-from: SU-SCORE rcvd at 4-Sep-81 0902-EDT
Mail-from: ARPANET site RUTGERS rcvd at 4-Sep-81 0556-PDT
Date: 4 Sep 1981 0856-EDT
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Connecting Dolphins to the 20
To: tops-20 at SU-SCORE
Has anyone had any experience connecting Dolphins tothe 20? I'm about
to start doing this soon and would appreciate and info about how you
did (or are doing) it. I'm also willing to exchange software with others.
Thanks.
Roy
-------
4-Sep-81 10:48:31-EDT,2319;000000000000
Mail-from: SU-SCORE rcvd at 4-Sep-81 1048-EDT
Mail-from: ARPANET site BBND rcvd at 4-Sep-81 0741-PDT
Date: 4 Sep 1981 1041-EDT
From: EONEIL at BBND
Subject: Moving archived files, archive runs
To: TOPS-20 at SU-SCORE
cc: EONEIL, DIPACE
re:Moving archived files--Clive Dawson @UTEXAS-20
We too have had trouble moving directories across structure boundaries,
so I have added a COPY command to DUMPER which runs the SAVE and RESTORE
code as coroutines--each page is set up as if to go to tape, only to
trigger a context switch, and then go off to the output file as if
it had just come off tape. Thus you get a file copy mechanism identical
to dumping to tape and restoring from tape, without the physical tape.
The modifying commands--SINCE ..., SUPERSEDE...,CREATE, etc. can be
used to modify the appropriate side of the operation. For ex.,
DUMPER>CREATE
DUMPER>COPY PS:<EMACS*> FS:
will create FS:<EMACS> and all its subdirectories and copy all the
files in these directories, preserving archive data, access dates,
invisibility status, etc. "All the files" means, of course, all
files DUMPER would dump, and omits temporary, deleted, and no-dump
files. It would also use DUMPER's obnoxious SUPER OLDER default
and refuse to copy an older-but-higher-version file. To get around
this, you can use our SUPER UNLESS command which allows any file
restored unless there is a file of that exact filespec already on
disk. The CREATE command has had much-needed work as well.
I can supply the binary version of this DUMPER--the sources are
considered proprietary.
re:Nat Mishkin's question about the inefficiency of archive runs
Jim Calvin and I designed and implemented the archive system here
at BBN, so we are responsible for this situation. My figures show
it costs about .6 KLsec/1000 files on the structure to do the 4 scans
necessary for a full archive run (2 tape copies of each file),
or about 30KLsecs for a "typical" 50,000 file-600Mbyte file system.
Our idea was to offload as much computation, such as queue management,
from first shift onto second or third shift, when our machines
are more or less idle--we considered this "free" computer time.
Obviously if your machines are running day and night this assumption
is no good.--Betty O'Neil
-------
4-Sep-81 10:58:53-EDT,1462;000000000000
Mail-from: SU-SCORE rcvd at 4-Sep-81 1058-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 4-Sep-81 0746-PDT
Date: 4 Sep 1981 0743-PDT
From: Rindfleisch at SUMEX-AIM
Subject: Re: Connecting Dolphins to the 20
To: MARANTZ at RUTGERS, tops-20 at SU-SCORE
In response to the message sent 4 Sep 1981 0856-EDT from MARANTZ@RUTGERS
Roy,
The Dolphins use the PUP protocol on the 3 Mbit/sec Ethernet. They also
connect to the 10 Mbit/sec Xerox Ethernet but the specs for that have
not been released and we are not using it.
We have our 2020 on the Ethernet and the Dolphins can communicate with
it. Thus, TOPS-20 is not a problem. As far as hardware connections,
we can get away with a UNIBUS interface for the 2020. For 2040-2060's,
there are two approaches being pursued:
1) Ralph Gorin and company are debugging a massbus interface for the
SCORE 2060. This should be working soon and I'm sure can be made
available to others. However, this is not DEC-supported hardware.
2) RAND (Chris Ryland) and possibly CMU (Aaron Wohl) are looking into
a DTE connection. I'm not sure what the state of this is.
A final hassle for now is when Xerox will release the 10/20 PUP software
so we can share the code with you and others who have asked. This has
been months coming, with frequent promises that the release is just
about to be finalized. I just don't know when that act will get
together.
Tom R.
-------
4-Sep-81 14:17:43-EDT,390;000000000000
Mail-from: SU-SCORE rcvd at 4-Sep-81 1417-EDT
Mail-from: ARPANET site BBND rcvd at 4-Sep-81 1113-PDT
Date: 4 Sep 1981 1412-EDT
From: EONEIL at BBND
Subject: Corr. to Archive run stats
To: TOPS-20 at SU-SCORE
cc: EONEIL
Change "KLsecs" to "KLmins" in my previous message, i.e., it should
be .6 KLmin/1000 files, or 30KLmin for a "typical" large filesystem.
--Betty
-------
4-Sep-81 17:15:50-EDT,1082;000000000000
Mail-from: SU-SCORE rcvd at 4-Sep-81 1715-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 4-Sep-81 1410-PDT
Date: 4 Sep 1981 1409-PDT
From: Rindfleisch at SUMEX-AIM
Subject: Re: Connecting Dolphins to the 20
To: MARANTZ at RUTGERS, tops-20 at SU-SCORE
cc: RINDFLEISCH at SUMEX-AIM
In response to the message sent 4 Sep 1981 1310-EDT from MARANTZ@RUTGERS
I guess I don't understand what the interface protocol between the front
end and the 20 will be for terminals, file xfers, etc. Are you planning
to use existing DECnet or NCP code in TOPS-20 and convert to/from PUP's
at the front end? You stand to have to rewrite much of the user level
code that exists for various kinds of Ethernet servers (PUPSRV, CHAT,
PUPFTP, XMAILR, etc.). There has been some work on Ethernet/ARPAnet
gateways at PARC but I don't know how complete or available that stuff
is. I personally would not spend much time writing new PUP code since
the durability of that protocol is questionable. Seems easier to adopt
(soon to be) available TOPS-20 hacks...
Tom R.
-------
4-Sep-81 19:33:49-EDT,1635;000000000000
Mail-from: SU-SCORE rcvd at 4-Sep-81 1933-EDT
Date: 4 Sep 1981 1625-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: New format for TOPS-20 distribution list
To: TOPS-20 at SU-SCORE
Folks -
Effective immediately, an archive has been established at SCORE
for the TOPS-20 distribution list messages. This directory is
<TOPS-20-ARCHIVE> at SCORE. Due to the sensitive nature of some of
the messages which have gone out on the list, the directory is
protected; however anybody with a "guest system programmer" account
(user group 1) at SCORE has access to the directory.
All messages starting with this one will be logged in this
directory as PS:<TOPS-20-ARCHIVE>TOPS-20.MESSAGES; anybody with
access to the <TOPS-20-ARCHIVE> directory can read this file.
In addition, the famous TOPS-20.DIS file which contains the
membership list for this list has moved to <TOPS-20-ARCHIVE> as
well. Unlike all the other files on this directory, it allows read
access to the world.
I am expecting to have the past messages which have been
distributed to the list on <TOPS-20-ARCHIVE> in a couple of days.
<TOPS-20-ARCHIVE> also contains some other files which I have moved
over from my "notes" directory. I haven't gone through all of it
yet (some of it is complete trash), and there may be some duplication
with messages on the list; but I hope to eventually have a true archive
of TOPS-20 folklore here.
Yours in maintaining our favorite operating system,
-- Mark --
-------
5-Sep-81 04:20:45-EDT,676;000000000000
Mail-from: SU-SCORE rcvd at 5-Sep-81 0420-EDT
Mail-from: ARPANET site RAND-AI rcvd at 5-Sep-81 0115-PDT
Date: 4 Sep 1981 2203-PDT
Sender: GEOFFM at RAND-AI
Subject: Re: New format for TOPS-20 distribution list
From: Geoffrey C. Mulligan (AFDSC, The Pentagon) <GeoffM@RAND-AI>
To: Admin.MRC at SU-SCORE
Cc: TOPS-20 at SU-SCORE
Message-ID: <[RAND-AI] 4-Sep-81 22:03:45.GEOFFM>
In-Reply-To: Your message of 4 Sep 1981 1625-PDT
Mark, If you need help putting the archive together I would be
glad to volunteer some time. How are you able to put so much
time into this? I thought that married person had to devote time
to their spouses!
geoff
5-Sep-81 18:42:51-EDT,1377;000000000000
Mail-from: SU-SCORE rcvd at 5-Sep-81 1842-EDT
Mail-from: ARPANET site SRI-KL rcvd at 5-Sep-81 1538-PDT
Date: 5 Sep 1981 1536-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: Connecting Dolphins to the 20
To: Rindfleisch at SUMEX-AIM, MARANTZ at RUTGERS, tops-20 at SU-SCORE
In-Reply-To: Your message of 4-Sep-81 1409-PDT
Yes, I agree wholeheartedly with Tom about using existing protocols.
The EOS folks promise in all directions that they'll free up the
PARC TENEX PUP support so that we can use SUMEX's excellent TOPS-20
adaptation. Using a front-end -11 on the -20 to interface to the
Ethernet is rather painless. In particular, I've just made some
minor changes to DTESRV which allow a front-end -11 to come up
with no previous arrangement on the -20 (unlike the current DN20
support). This allows you to write packet forwarders for nearly
any network with little pain (we will soon have one at Fairchild
for the Chaosnet and Ethernet.) The hardware is dirt cheap using
this approach, since you don't have to buy all those special boot
hardware components: viz., for the cost of a used 11/34 (around
$7K), plus the bare DTE boards ($3K exactly), you have a network
front-end. Anyone want to network up to 4 -20's together with
the Chaosnet? It'd only cost you $7K plus $3K per -20, and the
Chaosnet software is free from MIT.
-------
8-Sep-81 11:06:50-EDT,754;000000000000
Mail-from: SU-SCORE rcvd at 8-Sep-81 1106-EDT
Mail-from: ARPANET site RUTGERS rcvd at 8-Sep-81 0758-PDT
Date: 8 Sep 1981 1056-EDT
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Re: Connecting Dolphins to the 20
To: RYLAND at SRI-KL, Rindfleisch at SUMEX-AIM, tops-20 at SU-SCORE
In-Reply-To: Your message of 5-Sep-81 1836-EDT
Chris, Wouyld you send me (or point to where I can find) the info about
what hardware is needed on the 11/34 to support interconnection with the
20? Also if you don't get the hardware to allow "remote" booting (via a
20 or something) how can you get the FE to reload itself without
operator intervention? What is the hardware needed for the "remote"
bootstrap capability by the way? Thanks.
Roy
-------
8-Sep-81 12:44:20-EDT,628;000000000000
Mail-from: SU-SCORE rcvd at 8-Sep-81 1244-EDT
Mail-from: ARPANET site SRI-KL rcvd at 8-Sep-81 0936-PDT
Date: 8 Sep 1981 0934-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: Connecting Dolphins to the 20
To: MARANTZ at RUTGERS, Rindfleisch at SUMEX-AIM, tops-20 at SU-SCORE
In-Reply-To: Your message of 8-Sep-81 0756-PDT
Sorry, my last message was chopped off by Score's mailer, from what I
can see.
I will send a note about this scheme to build ultra-cheap front-ends
and the software needed to support it, as soon as I finish our
Chaosnet installation here (which is the proof of the pudding.)
-------
8-Sep-81 12:53:43-EDT,325;000000000000
Mail-from: SU-SCORE rcvd at 8-Sep-81 1253-EDT
Mail-from: ARPANET site RAND-UNIX rcvd at 8-Sep-81 0949-PDT
Date: Tuesday, 8 Sep 1981 09:37-PDT
To: tops-20 at SU-SCORE
Subject: 2060 MIP rating?
From: mike at RAND-UNIX
Can anyone tell me how many MIPs (Million Instructions per Second)
a 2060 is?
Thanks,
Michael
8-Sep-81 13:19:08-EDT,523;000000000000
Mail-from: SU-SCORE rcvd at 8-Sep-81 1319-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 8-Sep-81 1014-PDT
Date: 8 Sep 1981 1011-PDT
From: Rindfleisch at SUMEX-AIM
Subject: Re: 2060 MIP rating?
To: mike at RAND-UNIX, tops-20 at SU-SCORE
In response to the message sent Tuesday, 8 Sep 1981 09:37-PDT from mike@RAND-UNIX
I did a simple-minded test some time ago under time-sharing to check
out an instruction mix typical of monitor coding and got a value for
the SCORE 2060 of 1.23 MIPS.
Tom R.
-------
8-Sep-81 13:31:20-EDT,518;000000000000
Mail-from: SU-SCORE rcvd at 8-Sep-81 1331-EDT
Mail-from: ARPANET site SRI-KL rcvd at 8-Sep-81 1028-PDT
Date: 8 Sep 1981 1019-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: 2060 MIP rating?
To: mike at RAND-UNIX, tops-20 at SU-SCORE
In-Reply-To: Your message of 8-Sep-81 0955-PDT
Whew, that's a toughie, but the "standard" figure we used at MIT
was about 2MIP. (JM@MC is the source of this figure.)
Thus, the Jupiter, which is supposedly 3-5x faster than a KL10E,
will be about 6-10MIP.
-------
8-Sep-81 17:23:47-EDT,462;000000000000
Mail-from: SU-SCORE rcvd at 8-Sep-81 1723-EDT
Mail-from: ARPANET site RUTGERS rcvd at 8-Sep-81 1417-PDT
Date: 8 Sep 1981 1708-EDT
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Re: Connecting Dolphins to the 20
To: RYLAND at SRI-KL, Rindfleisch at SUMEX-AIM, tops-20 at SU-SCORE
In-Reply-To: Your message of 8-Sep-81 1234-EDT
Thanks. Can you point me at Chaosnet documentation also? I'd like a
protocol description. Thanks again.
Roy
-------
9-Sep-81 13:09:41-EDT,448;000000000000
Mail-from: SU-SCORE rcvd at 9-Sep-81 1309-EDT
Mail-from: ARPANET site SU-SCORE rcvd at 9-Sep-81 1005-PDT
Date: 9 Sep 1981 1004-PDT
From: Ted Markowitz <G.TJM at SU-SCORE>
Subject: Re: 2060 MIP rating?
To: tops-20 at SU-SCORE
In-Reply-To: Your message of 8-Sep-81 1019-PDT
I've been a little out of touch with what's happening on the Jupiter
development. Anyone have any details on what it currently looks like,
etc.?
--ted
-------
11-Sep-81 02:15:41-EDT,3894;000000000000
Mail-from: SU-SCORE rcvd at 11-Sep-81 0215-EDT
Mail-from: ARPANET site RUTGERS rcvd at 10-Sep-81 2310-PDT
Date: 11 Sep 1981 0209-EDT
From: WATROUS at RUTGERS (Don Watrous)
Subject: Speeding up archiving
To: TOPS-20 at SU-SCORE
ARCF calls UPDDIR to update the directory during each jsys call, even
if it is a read-only function. This is incredibly costly for both
REAPER and DUMPER who gather the tape information of files with ARCF.
Skipping the call to UPDDIR for the read-only function speads up both
these programs tremendously. (I've just reaped and archived to two
tapes a three pack PS: in less than 50 minutes!)
To speed things up even further, I've modified ARCF to set a bit in
<SYSTEM>ARCHIVE-REQUESTS.BIN (like MAILER.FLAGS) whenever an archive
or a migration is requested. The monitor code is working, but I
haven't written the DUMPER support yet. I'll pass along the DUMPER
code when that's finished.
Both patches are included in the FILCOM below. Lines concerning
UPDDIR avoidance are commented with [a], while those for setting the
bit in <SYSTEM>ARCHIVE-REQUESTS.BIN are commented [b].
Don
File 1) JSYSF.MAC.19,10-Sep-81 09:45:58
File 2) JSYSF.MAC.15, 8-Jul-81 03:15:02
1) stkvar <arcflg,roflg> ;[b,a]
1) HRRZ JFN,T1 ; Copy JFN
****
2)5 HRRZ JFN,T1 ; Copy JFN
**************
1)5 setzm arcflg ;[b] assume not archive request
1) caie t1,.arrar ;[b] requesting archive
1) cain t1,.arriv ;[b] or migrate?
1) hrrzm q3,arcflg ;[b] yes, save set/clear
1) arc1: ;[b]
1) setzm roflg ;[a] assume not read-only function
1) cain t1,.argst ;[a] only read-only function?
1) setom roflg ;[a] this is it
1) CALL @ARCFF(T1) ; Do it
1) JRST ARCFX ; Failed for some reason
1) skipn roflg ;[a] if not read-only function
1) CALL UPDDIR ; Update directory
****
2)5 CALL @ARCFF(T1) ; Do it
2) JRST ARCFX ; Failed for some reason
2) CALL UPDDIR ; Update directory
**************
1)5 skipe arcflg ;[b] if setting archive/migrate
1) call flagit ;[b] flag archive request
1) MRETNG ; Done
****
2)5 MRETNG ; Done
**************
1)6 ;[b] routine to set bit in ARCHIVE-REQUESTS.BIN for this directory
1) flagit: stkvar <flgjfn,filjfn,<flgtmp,100>> ;[b]
1) xctu [ move t1,1] ;[b] get jfn
1) movem t1,filjfn ;[b]
1) hrroi t1,flgtmp ;[b] get structure string for archive request
1) move t2,filjfn ;[b]
1) movx t3,fld(.jsaof,js%dev)!js%paf ;[b]
1) jfns ;[b]
1) erjmp r ;[b]
1) hrroi t2,[asciz \<system>archive-requests.bin\] ;[b]
1) setzb t3,t4 ;[b] create name for binary file there
1) sout ;[b]
1) movx t1,gj%old!gj%sht ;[b] get jfn on binary file
1) hrroi t2,flgtmp ;[b]
1) noint ;[b] stop interrupts now
1) gtjfn ;[b]
1) erjmp flagi3 ;[b]
1) movem t1,flgjfn ;[b]
1) movx t2,fld(1,of%bsz)!of%rd!of%wr!of%thw ;[b] open file
1) openf ;[b]
1) erjmp flagi2 ;[b]
1) hrroi t1,flgtmp ;[b] get directory string of archive request
1) move t2,filjfn ;[b]
1) movx t3,fld(.jsaof,js%dev)!fld(.jsaof,js%dir)!js%paf ;[b]
1) jfns ;[b]
1) erjmp flagi1 ;[b]
1) movx t1,rc%emo ;[b] get that directory number
1) hrroi t2,flgtmp ;[b]
1) rcdir ;[b]
1) erjmp flagi1 ;[b]
1) txne t1,rc%nom ;[b]
1) jrst flagi1 ;[b]
1) hrrz t2,t3 ;[b] position there in binary file
1) move t1,flgjfn ;[b]
1) sfptr ;[b]
1) erjmp flagi1 ;[b]
1) seto t2, ;[b] mark that directory number
1) bout ;[b]
1) erjmp flagi1 ;[b]
1) flagi1: move t1,flgjfn ;[b] close the file
1) closf ;[b]
1) erjmp flagi2 ;[b]
1) jrst flagi3 ;[b]
1) flagi2: move t1,flgjfn ;[b] toss the jfn
1) rljfn ;[b]
1) erjmp flagi3 ;[b]
1) flagi3: okint ;[b]
1) ret ;[b]
1)7 ; Involuntary migration; File exempt from migration
****
2)7 ; Involuntary migration; File exempt from migration
**************
-------
11-Sep-81 21:53:36-EDT,361;000000000000
Mail-from: SU-SCORE rcvd at 11-Sep-81 2153-EDT
Mail-from: ARPANET site SRI-KL rcvd at 11-Sep-81 1849-PDT
Date: 11 Sep 1981 1837-PDT
From: ROODE at SRI-KL (David Roode)
Subject: MIP ratings
To: tops-20 at SU-SCORE
How about MIP ratings for 20's without cache, VAX-11/750's and VAX-11/780's,
PDP-11/70's, /44's, /23's, and IBM 370 compatibles?
-------
12-Sep-81 19:16:55-EDT,836;000000000000
Mail-from: SU-SCORE rcvd at 12-Sep-81 1916-EDT
Mail-from: ARPANET site MIT-XX rcvd at 12-Sep-81 1611-PDT
Date: 12 Sep 1981 1910-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: BAT blocks
To: tops-20 at SU-SCORE
Does anyone know an easy way of forcing particular disk sectors into
the BAT block table? I just image copied (pack to pack) a disk pack
and in the process I overwrote the destination pack's BAT block. I
knew I was going to do this so I isolated the files I knew would map
onto bad blocks on the new pack. I figured a couple of references to
these files would elicit enough disk errors for the monitor to mark
the files' blocks as bad in the new BAT block. Unfortunately, it
didn't and now I can't delete these files without returning bad blocks
to the free pool. Any ideas?
-- Nat Mishkin
-------
12-Sep-81 22:44:51-EDT,771;000000000001
Mail-from: SU-SCORE rcvd at 12-Sep-81 2244-EDT
Mail-from: ARPANET site SRI-KL rcvd at 12-Sep-81 1939-PDT
Date: 12 Sep 1981 1939-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: DTE hardware/software caveat
To: Tops-20 at SU-SCORE
I found out the hard way that (a) sending a packet via the MCB protocol
(and, I presume, the RSX20F protocol) which isn't an even number of words
or (b) sending a packet which doesn't start on an even-word (4-byte)
boundary will cause the KL to die horribly (the clock even stops.) This
is on a secondary front-end's DTE, not a privileged DTE. Could be
randomness in DTESRV, but I doubt it. Nothing of this sort was warned
about in the DTE hardware manual (field circus fiche version). Anybody
have any ideas?
-------
13-Sep-81 01:31:49-EDT,535;000000000000
Mail-from: SU-SCORE rcvd at 13-Sep-81 0131-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 12-Sep-81 2226-PDT
Date: 12 Sep 1981 2324-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: BAT blocks
To: NWM at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 12-Sep-81 1710-MDT
I have a program from DEC call BATUPD that is used form manipulating
BAT blocks. You can anonymous ftp them from [utah-20]<frank>batupd.*.
They normally don't reside their, so if anyone wants them, get them within
a week.
Randy
-------
13-Sep-81 23:18:07-EDT,690;000000000000
Mail-from: SU-SCORE rcvd at 13-Sep-81 2318-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 13-Sep-81 2015-PDT
Date: 13 Sep 1981 2115-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Speeding up archiving
To: WATROUS at RUTGERS, TOPS-20 at SU-SCORE
In-Reply-To: Your message of 11-Sep-81 0009-MDT
I'd like to add my vote to this obvious (why didn't I think of it...)
solution to speeding up archiving (i.e., a file similar to the mailer
flags file). If anyone from DEC is out their listening, I think that this
scheme should DEFINITELY be adopted, and it is a simple, elegant, and
easy to implement solution to the archiving overhead problem.
Cudos to Watrous!!!
-------
14-Sep-81 10:27:18-EDT,581;000000000010
Mail-from: SU-SCORE rcvd at 14-Sep-81 1027-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 14-Sep-81 0722-PDT
Date: 14 Sep 1981 1021-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: TOPS-20 at SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: VAX on Arpa
Message-ID: <MS"5(1646)"11760198811.28.158.109423 at RADC-TOPS20>
Can anyone tell me if Vax's have been interfaced to Arpa, and if so,
can you briefly tell me how it was done. I notice there are a couple
of Vax's out there and they are labeled as UNIX.
Thanks
Mark Pratt
--------
14-Sep-81 12:36:17-EDT,434;000000000000
Mail-from: SU-SCORE rcvd at 14-Sep-81 1236-EDT
Mail-from: ARPANET site SRI-KL rcvd at 14-Sep-81 0933-PDT
Date: 14 Sep 1981 0930-PDT
From: Richard R. Cower <COWER at SRI-KL>
Subject: Re: VAX on Arpa
To: Pratt at RADC-TOPS20, TOPS-20 at SU-SCORE
cc: COWER at SRI-KL
In-Reply-To: Your message of 14-Sep-81 0721-PDT
Contact David Kashtan. I think he is getting mail at sri-ai (if not..it
will be forwarded).
.rich
-------
14-Sep-81 15:35:41-EDT,480;000000000000
Mail-from: SU-SCORE rcvd at 14-Sep-81 1535-EDT
Mail-from: ARPANET site RUTGERS rcvd at 14-Sep-81 1231-PDT
Date: 14 Sep 1981 1335-EDT
Sender: AWALKER at RUTGERS
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: Re: VAX on Arpa
To: Pratt at RADC-TOPS20
cc: TOPS-20 at SU-SCORE
In-Reply-To: Your message of 14-Sep-81 1021-EDT
There's a VAX running VMS (it's a testbed for EUNICE), on SRI-IU.
Contact Dave <Kashtan at SRI-IU> for more information.
/JSol
-------
14-Sep-81 15:59:37-EDT,677;000000000000
Mail-from: SU-SCORE rcvd at 14-Sep-81 1559-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 14-Sep-81 1255-PDT
Date: 14 Sep 1981 1548-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: tops-20 at SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: Vax and Arpa
Message-ID: <MS"5(1646)"11760258400.28.158.235464 at RADC-TOPS20>
I'd like to thank everyone for all the responses I have gotten
regarding Vax's on the network. I now know what I needed to, and
if anyone is interested, I will redistribute those messages to anyone
that would like them, as long as the original senders have
no objections.
Again, thanks.
Mark
--------
14-Sep-81 19:59:24-EDT,600;000000000000
Mail-from: SU-SCORE rcvd at 14-Sep-81 1959-EDT
Mail-from: ARPANET site RUTGERS rcvd at 14-Sep-81 1652-PDT
Date: 14 Sep 1981 1831-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: Debugging aid needed.
To: TOPS-20 at SU-SCORE
I'm looking for a method of trapping on the modification of
a location in memory. Does anyone know of a program that breaks
(into DDT) when some location is referenced? Does an Address
Break do what I want? I will settle for some indication of
where in my program the word is being modified. Also it should
be continuable.
Thanks,
JSol
-------
14-Sep-81 23:39:21-EDT,653;000000000000
Mail-from: SU-SCORE rcvd at 14-Sep-81 2339-EDT
Mail-from: ARPANET site SRI-CSL rcvd at 14-Sep-81 2031-PDT
Date: 14 Sep 1981 2029-PDT
Sender: GEOFF at SRI-CSL
Subject: Re: VAX on Arpa
From: the tty of Geoffrey S. Goodfellow
Reply-To: Geoff at SRI-CSL
To: Pratt at RADC-TOPS20
Cc: TOPS-20 at SCORE
Message-ID: <[SRI-CSL]14-Sep-81 20:29:17.GEOFF>
In-Reply-To: <MS"5(1646)"11760198811.28.158.109423 at RADC-TOPS20>
There are two VMS NCP implementations that I know exist. One is
by Dave Kashtan of SRi-AI (Kashtan@SRI-IU), the other is by DTI.
You might try contacting Jody Kravitz (kravitz@dti) for
information on the DTI implementation.
16-Sep-81 02:00:34-EDT,856;000000000000
Mail-from: SU-SCORE rcvd at 16-Sep-81 0200-EDT
Mail-from: ARPANET site RUTGERS rcvd at 15-Sep-81 2255-PDT
Date: 16 Sep 1981 0156-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: Bug in the exec
To: TOPS-20 at SU-SCORE
Try this on your default EXEC:
@DEASSIGN (DEVICE) FOO?
^asking for help
bombs out with the error:
?Invalid help string pointer
What happens is that the macro that parses the device doesn't
have the <help> string. This is at DEAS1: in EXECMT.MAC
DEAS1: DEVX ;NOT "DEASSIGN *", CHECK FOR REAL DEVICE
CMERRX ;NOT THAT EITHER!
Should be
DEAS1: DEVX <Device name> ;NOT "DEASSIGN *", CHECK FOR REAL DEVICE
CMERRX ;NOT THAT EITHER!
This actually could be considered a bug in DEVX, but I discovered
it was trivial to fix in the exec hence this change.
Cheers,
JSol
-------
16-Sep-81 10:11:32-EDT,889;000000000000
Mail-from: SU-SCORE rcvd at 16-Sep-81 1011-EDT
Mail-from: ARPANET site DEC-MARLBORO rcvd at 16-Sep-81 0702-PDT
Date: 16 Sep 1981 1000-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: JSol at RUTGERS, TOPS-20 at SU-SCORE
Subject: Re: Debugging aid needed.
Message-ID: <"MS5(1734)+GLXLIB1(1033)" 11760719332.16.71.15809 at DEC-MARLBORO>
In-reply-to: Message from Jonathan Alan Solomon <JSol at RUTGERS>
of 14-Sep-81 1831-EDT
If you SET ADDRESS-BREAK, your fork will be terminated when it tries
the watched-for reference. You can continue it, or run DDT (but
to continue from DDT you do <address-of-failing-instruction>$G,
not $P, and must first turn off the break or increment the repeat count
or it will just break again). You can break after certain flavors
of references, or after n references, with subcommands to SET ADDRESS-BREAK.
--------
16-Sep-81 16:44:03-EDT,421;000000000000
Mail-from: SU-SCORE rcvd at 16-Sep-81 1643-EDT
Mail-from: ARPANET site MIT-XX rcvd at 16-Sep-81 1303-PDT
Date: 16 Sep 1981 1603-EDT
From: Steve Berlin <BERLIN at MIT-XX>
Subject: Release 5
To: tops-20 at SU-SCORE
Is there any recent info about release 5? Any good guesses
about when it will be released? When it goes into field-test?
Also, is PCL planned to be included? Thanks...
-- Steve
-------
16-Sep-81 21:28:04-EDT,871;000000000000
Mail-from: SU-SCORE rcvd at 16-Sep-81 2128-EDT
Mail-from: ARPANET site MIT-XX rcvd at 16-Sep-81 1821-PDT
Date: 16 Sep 1981 2122-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: MTOPR Documentation Error
To: tops-20 at SU-SCORE
Just in case anyone finds a need to use the MTOPR .MOTPS ("assign
interrupt channels for non-controlling terminal") feature...the
documentation in the Monitor Calls Reference Manual is completely
wrong.
A quick perusal of the monitor source (you know things must be getting
bad when this is the 1st place you look when something doesn't seem to
work as advertised) turns up the fact that the format is AC3 pointing
to a block whose 1st word contains 2, and whose 2nd word contains
(output channel#,,input channel#). The manual says AC3 is supposed
to contain (input channel#,,output channel#).
-- Nat Mishkin
-------
17-Sep-81 13:01:26-EDT,48;000000000000
Mail-from: SU-SCORE rcvd at 17-Sep-81 1301-EDT
17-Sep-81 13:31:28-EDT,820;000000000000
Mail-from: SU-SCORE rcvd at 17-Sep-81 1331-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 17-Sep-81 1024-PDT
Date: 17 Sep 1981 1122-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Investment opportunities
To: tops-20 at SU-SCORE
I have a great investment opportunity: better than the stock market, gold,
real estate, bonds...
Try DECSystem 20 Reference manuals: if you've tried to buy any manuals lately
you know what I mean. $46 for the Hardware Reference manual, and Monitor
Calls Reference manual, $30 for the Edit reference manual and Fortran,
etc.
It's obscene. Even with DEC's policy of "allowing" you to re-print manuals
for a 25% royalty, the manual prices are ridiculous. Two years ago when
everyone complained, the manual prices were bad; now they've gone into orbit.
Randy
-------
17-Sep-81 13:45:47-EDT,402;000000000000
Mail-from: SU-SCORE rcvd at 17-Sep-81 1345-EDT
Mail-from: ARPANET site SRI-KL rcvd at 17-Sep-81 1038-PDT
Date: 17 Sep 1981 1034-PDT
From: Richard R. Cower <COWER at SRI-KL>
Subject: Re: Investment opportunities
To: FRANK at UTAH-20, tops-20 at SU-SCORE
cc: COWER at SRI-KL
In-Reply-To: Your message of 17-Sep-81 1022-PDT
Does a futures market exist? Can we buy on margin?
.rich
-------
17-Sep-81 17:47:05-EDT,772;000000000000
Mail-from: SU-SCORE rcvd at 17-Sep-81 1746-EDT
Mail-from: ARPANET site SRI-KL rcvd at 17-Sep-81 1441-PDT
Date: 17 Sep 1981 1415-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: Release 5
To: FRANK at UTAH-20, BERLIN at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 17-Sep-81 0950-PDT
I've been talking with DEC about field-test and R5 release, and
here's the story: they plan to start field-testing in about a month,
with final release vaguely aimed at 4-6 months later.
The story with PCL is that all the hooks will be in the standard
DEC EXEC, and you'll receive enough .REL files to link in PCL as
a non-source site. This is a step up from the MFEXEC policy,
which was basically that it was unavailable to non-source sites.
-------
17-Sep-81 18:57:07-EDT,1051;000000000000
Mail-from: SU-SCORE rcvd at 17-Sep-81 1857-EDT
Mail-from: ARPANET site SRI-KL rcvd at 17-Sep-81 1550-PDT
Date: 17 Sep 1981 1546-PDT
From: ROODE at SRI-KL (David Roode)
Subject: Re: Investment opportunities
To: FRANK at UTAH-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 17-Sep-81 1022-PDT
A couple of thoughts... one reason for their high prices is that
you can order a single manual over the phone charging it to Master
Charge or Visa. This type of onsies and twosies has got to cost
them money.
The other reason is that they insist on pricing the manuals to recover
the complete cost of producing the manual--in the case of many manuals,
some of this cost should be considered for recovery under other
methods--for example, it behooves them to keep track of what
the monitor calls do even if they are not going to produce
a reference document on that matter.
Finally, when the manual is prices at $46, I wonder how many people
resist the temptation of the local double sided auto collating
Xerox machine?
-------
18-Sep-81 03:36:40-EDT,1177;000000000000
Mail-from: SU-SCORE rcvd at 18-Sep-81 0336-EDT
Mail-from: ARPANET site RUTGERS rcvd at 18-Sep-81 0028-PDT
Date: 18 Sep 1981 0321-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: Investment opportunities
To: FRANK at UTAH-20
cc: tops-20 at SU-SCORE
In-Reply-To: Your message of 17-Sep-81 1322-EDT
This is why we do our own local documentation. As far as I know, no one
buys any DEC manuals here, except a few copies of the JSYS manual. I
hadn't seen the $46 price, though. That may stop what little sales
there is. I agree that there is no possible way we can ask students to
pay $46 for a manual. Would it be legal for each university to take
responsibility for reprinting one manual, thus getting volumes high
enough that we could do a reasonable job? Actually, the best thing
for everyone would be for us to subcontract to DEC to do our printing
for us. This would keep their volume up, and help keep the costs
down for the rest of the customers. I would certainly be happy to
arrange for printing of one of the manuals here if it looked like the
volume was going to be enough to make it cost-effective.
-------
18-Sep-81 15:31:28-EDT,367;000000000000
Mail-from: SU-SCORE rcvd at 18-Sep-81 1531-EDT
Mail-from: ARPANET site SANDIA rcvd at 18-Sep-81 1225-PDT
Date: 18 Sep 1981 1325-MDT
From: Norm Samuelson <Samuelson at SANDIA>
Subject: MAINSAIL
To: tops-20 at SU-SCORE
I have a user who is interested in MAINSAIL. Can anybody tell me
who has it and under what conditions it is available?
- Sam -
-------
18-Sep-81 16:24:37-EDT,425;000000000000
Mail-from: SU-SCORE rcvd at 18-Sep-81 1624-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 18-Sep-81 1317-PDT
Date: 18 Sep 1981 1314-PDT
From: Eric Schoen <Schoen at SUMEX-AIM>
Subject: Re: MAINSAIL
To: tops-20 at SU-SCORE
MAINSAIL is available through XIDAK, Inc, in Los Altos, CA. You can
contact Clark Wilcox via Arpanet mail as Wilcox@SRI-KL, I think.
XIDAK's phone number is (415) 948-4387.
Eric
-------
20-Sep-81 13:40:07-EDT,820;000000000000
Mail-from: SU-SCORE rcvd at 20-Sep-81 1340-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 20-Sep-81 1032-PDT
Date: 20 Sep 1981 1327-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: TOPS-20 at SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: Passwords and EXEC
Message-ID: <MS"5(1646)"11761805450.4.158.119928 at RADC-TOPS20>
Here is a change to the EXEC which will not type out
passwords during a ^ECREATE, BUILD, or I DIR, unless VERBOSE
has been specified. This is nice since most of the time you
don't want the password to type out. This way you have to
specifically have to ask for it.
In EXEC4 of EXEC, at PR2-2, insert after the JUMPE
TLNN Z,F3 ;ONLY TYPE PASSWORD ON VERBOSE MODE
JRST [TYPE <- available using VERBOSE>
JRST PR2]
-- Mark
--------
20-Sep-81 13:47:19-EDT,1088;000000000000
Mail-from: SU-SCORE rcvd at 20-Sep-81 1347-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 20-Sep-81 1042-PDT
Date: 20 Sep 1981 1343-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: TOPS-20 at SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: IMPLEO's
Message-ID: <MS"5(1646)"11761808395.4.158.154419 at RADC-TOPS20>
Has anyone out there experienced something similar to this:
RADC-TOPS20 has recently experienced some problems with TELNET
in which the user (already connected to RADC-TOPS20) connected
to RADC-TOPS20, got logged in, started to work, and suddenly
his TELNET'd job seemed to hang. The job wouldn't respond to
anything. The job running TELNET was working fine.
When looking at the status of the connections with NETSTAT,
the hung job's status was OPND and the TELNET job was DATW.
At the same time, a buginf IMPLEO (can't find lt entry for
for output message) for that user came up on the console.
The problem does not seem to be reproducible.
I am wondering if anyone else has seen this.
Thanks
Mark
--------
22-Sep-81 17:21:18-EDT,2915;000000000001
Mail-from: SU-SCORE rcvd at 22-Sep-81 1721-EDT
Mail-from: ARPANET site BBND rcvd at 22-Sep-81 1104-PDT
Date: 22 Sep 1981 1256-EDT
From: TAPPAN at BBND (Dan Tappan)
Subject: Bug in FORK
To: TOPS-20 at SCORE
cc: Clynn
The following bug causes PAGLCK bughlt's occasionally when using
Mark's TCP TELNET. The cause is that the TCP, in the CLZFF code,
is fondling the user's address space after it has been
PMAP'ed to oblivion. The original code had a check of the SPT
share count to catch something like this, but since the check
was after the CLZFF it didn't work. One fix would have been
just to move the share count check to before the CLZFF, but I
decided the following one is not much less efficent, and
potentially catches more bugs.
(Note that this bug only shows up on a system running TCP,
but it might be a good idea to get the fix in any system,
since the bug could be hit if anything else new starts
playing around with the user address space)
A SRCCOM of the relevant changes follows:
; FORK.MAC.14 & FORK.MAC.9 22-Sep-81 1242 PAGE 1
LINE 1, PAGE 1
1) ;<BBN-4-MONITOR>FORK.MAC.10, 27-Aug-81 11:36:23, Edit by TAPPAN
1) ;101: Fix bug in KSELF, where shared UPT not getting properly cleared
1) ;<BBN-4-MONITOR>FORK.MAC.9, 10-Jul-81 18:51:14, Edit by TAPPAN
LINE 1, PAGE 1
2) ;<BBN-4-MONITOR>FORK.MAC.9, 10-Jul-81 18:51:14, Edit by TAPPAN
LINE 97, PAGE 15
1) ;;; 101: Deletion
1) CALL FLOCK
LINE 96, PAGE 15
2) MOVE FX,FORKX
2) HLRZ 1,FKPGS(7)
2) LOAD 2,SPTSHC,(1) ;GET SHARE COUNT OF UPT
2) PUSH P,2 ;SAVE IT FOR LATER CHECK
2) CALL FLOCK
; FORK.MAC.14 & FORK.MAC.9 22-Sep-81 1242 PAGE 2
(This is at just above KSEF2)
LINE 120, PAGE 15
1) ;;; 101: Do at least one pass through the UPT to be sure pages are gone
1) JRST KSEF3A ; Skip the DISMS first time through
1)
1) KSEF3: MOVEI 1,^D5000
1) DISMS ;WAIT FOR 5 SECS
1) KSEF3A: MOVE FX,FORKX ; get our fork index
1) HLRZ 1,FKPGS(FX) ; THEN CLEAR MAP AGAIN
1) LOAD 2,SPTSHC,(1) ; SHARE COUNT OF UPT
1) PUSH P,2
1) SETZ 1,
1) HLLZ 2,FKPGS(FX)
1) KSEF4: HRRZ T3,T2 ;MAKE A GOOD ADDRESS.
1) SKIPE UPTPGA(T3) ;QUICK CHECK FOR ALREADY EMPTY
1) CALL SETPT ;BUT NOT USING PMAP
1) MOVEI 6,0(T3)
1) CAIGE 6,777
1) AOJA 2,KSEF4
1) ; 101: End of change
1)
LINE 123, PAGE 15
2)
LINE 158, PAGE 15
1) ;;; 101: deletion
1) ^L
LINE 144, PAGE 15
2) KSEF3: MOVEI 1,^D5000
2) DISMS ;WAIT FOR 5 SECS
2) HLRZ 1,FKPGS(7) ;THEN CLEAR MAP AGAIN
2) LOAD 2,SPTSHC,(1) ;SHARE COUNT OF UPT
2) PUSH P,2
2) SETZ 1,
2) HLLZ 2,FKPGS(7)
2) KSEF4: HRRZ T3,T2 ;MAKE A GOOD ADDRESS.
2) SKIPE UPTPGA(T3) ;QUICK CHECK FOR ALREADY EMPTY
2) CALL SETPT ;BUT NOT USING PMAP
2) MOVEI 6,0(T3)
2) CAIGE 6,777
; FORK.MAC.14 & FORK.MAC.9 22-Sep-81 1242 PAGE 3
2) AOJA 2,KSEF4
2) JRST KSEF2
2) ^L
----------------
Dan
-------
22-Sep-81 18:18:35-EDT,432;000000000000
Mail-from: SU-SCORE rcvd at 22-Sep-81 1818-EDT
Mail-from: ARPANET site SANDIA rcvd at 22-Sep-81 1512-PDT
Date: 22 Sep 1981 1608-MDT
From: Norm Samuelson <Samuelson at SANDIA>
Subject: DECUS
To: tops-20 at SANDIA
It always helps to find out such things AFTER you make your reservations,
but all the DEC-10/20 sessions at the fall DECUS in L.A. will be in the
old Biltmore hotel, not the new Bonaventure.
- Sam -
-------
23-Sep-81 11:37:33-EDT,1127;000000000000
Mail-from: SU-SCORE rcvd at 23-Sep-81 1137-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 23-Sep-81 0831-PDT
Date: 23 Sep 1981 1131-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: TOPS-20 at SCORE
cc: ADMIN at RADC-TOPS20
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: MONRD% JSYS
Message-ID: <MS"5(1646)"11762570786.8.158.195061 at RADC-TOPS20>
There is a bug in the MONRD jsys which breaks reading of PSB locations
and the fork status function. This bug only occurs if you've changed the
edit number of the monitor, say like using the edit number as a local
edit number.
In the CHKFRK routine of the MONRD% jsys, which is in the source for
SYSDPY, there is the following code which can be removed
for version 4 sites.
At CHKFRK+4, remove
HRRZ T2,.JBVER ;GET MONITOR VERSION
CAIGE T2,NWFKPT ;NEW STYLE SCHEDULER CODE ?
JRST CHKFRO(P1) ;NO, GO DO IT THE OLD WAY
Also, remove
CHKFRO: <HLRZ T2,0(T1)>+$$(FKPT,STG) ;GET THE QUEUE FORK IS ON
CAIE T2,$$(WTLST,STG) ;IS FORK IN A WAIT ?
CAIN T2,$$(GOLST,STG) ;OR RUNNABLE ?
JRST SKP(P1)
-- Mark
--------
26-Sep-81 17:42:50-EDT,2859;000000000001
Mail-from: SU-SCORE rcvd at 26-Sep-81 1742-EDT
Mail-from: ARPANET site SRI-KL rcvd at 26-Sep-81 1436-PDT
Date: 26 Sep 1981 1435-PDT
From: ROODE at SRI-KL (David Roode)
Subject: abysmal state of VAX/VMS
To: tops-20 at SU-SCORE
A long time ago, I heard a rumor of a TOPS-30 that was supposed
to be a TENEX-like operating system for the VAX. Is there any
more recent rumbling along these lines? Can anyone comment on
the VMS operating system, specifically:
1) Why was there no "?" style help let along command completion
implemented in the command language?
2) Why are there no read dates kept for files?
3) Why was there no LOAD-class commands feature?
4) Why is the command language they did implement (DCL) so unruly
in its organization. For example, the command to cancel a spooler
request is a switch option on the DELETE command which is normally
used to delete files. This seems silly. Conversely, the command
to "unlock" a file is top level, where as it seems this should be
relatively little-used. (Files are "locked" when something goes wrong,
like a ^C while they are being written.)
5) If a parity error occurs in reading from a .EXE file which the
user is running, the user gets an abnormal termination report for
the .EXE file (several lines of "stack dump", etc.) but then
finds himself logged off the system, without so much as a message
to that effect.
6) Unless the user defines his own synonym, or "the image is installed"
in order to run a system provided program (CUSP, <SUBSYS> program),
the user must use a command like:
RUN SYS$SYSTEM:PROGNAME
or RUN DBA0:<SYSEXE>PROGNAME
or else he can use the only built in shorthand, which is
MCR PROGNAME
and which was designed to mean "run me in RSX-11M compatibility
mode, using its comand language, pretend PROGNAME is 'installed'
in RSX-11M, and run it."
7) Although there is little logic in it, every user is assigned
a UIC (like [101,2]) which essentially seems to be another
way of specifiying the username, and is stored as an attribute
of any directories the user may have (none of which need match
the username). Sometimes the UIC is required to identify the user,
and sometimes the directory. There doesn't seem to be any
easy way to find out the username of a given UIC, either. All files
are owned by someone specified via UIC. If you create
a file in a user's directory for him, you own it, and he cannot
access it as owner. There is no way to change the file owner.
If you want him to own it, you have to remember to specify this
by setting your UIC to be his before creating the file. If a user
finds files someone else created, he has no way of knowing whose
UIC that is.
Well, I guess DEC believes in repeating their past mistakes,
not repeating their successes, and then some.
-------
26-Sep-81 19:40:50-EDT,1347;000000000001
Mail-from: SU-SCORE rcvd at 26-Sep-81 1940-EDT
Mail-from: ARPANET site SANDIA rcvd at 26-Sep-81 1634-PDT
Date: 26 Sep 1981 1735-MDT
From: Norm Samuelson <Samuelson at SANDIA>
Subject: Re: abysmal state of VAX/VMS
To: ROODE at SRI-KL
cc: tops-20 at SANDIA
In-Reply-To: Your message of 26-Sep-81 1535-MDT
Boy, It sure is good to see that someone else thinks VMS sucks!!!
Oh, There are a couple of things I may be able to help you with.
There is a program called WHO which translates UIC to username
and vice-versa. It is NOT a one-to-one translation, each username
maps to one UIC, but many other user names may map to the SAME UIC.!
Most of what I see wrong with VMS seems to come from one of two places,
either trying to maintain compatibility with RSX-11M (not unreasonable),
or trying (and failing miserably) to make it somewhat compatible with
TOPS-10 and TOPS-20.
My favorite gripe is the TERRIBLE way COLON is handled in il-logical
names. If you use the DEFINE command, and include a colon (as you
should and must on TOPS-20), the logical name you just defined has
a colon on it, and will NEVER be of any use. Logical names MUST NOT
include the colon. There are some times you MUST INCLUDE the colon,
some times you MUST OMIT it, and still other times where it is
optional...A real mess!!!
- Sam -
-------
26-Sep-81 20:42:51-EDT,996;000000000000
Mail-from: SU-SCORE rcvd at 26-Sep-81 2042-EDT
Date: 26 Sep 1981 1737-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: discussions about VAX/VMS, etc.
To: TOPS-20 at SU-SCORE
I do not believe that discussions about VMS are apropos for this mailing
list, which is mostly for the spread of technical folklore on TOPS-20.
Many of the people on this list may be interested in such a discussion,
but it would be better to spawn off another list for it.
My personal belief is that there is little likelihood to see functionality
of the sort we know and love on TOPS-20 on VMS. The VMS developers seem
to believe that it is "inefficient" to have a user interface.
If anybody would like to spawn off a VMS mailing list, the membership of
the TOPS-20 list is online at SU-SCORE as PS:<TOPS-20-ARCHIVE>TOPS-20.DIS.
The file is in MM format.
-------
26-Sep-81 22:41:01-EDT,680;000000000000
Mail-from: SU-SCORE rcvd at 26-Sep-81 2240-EDT
Mail-from: ARPANET site RUTGERS rcvd at 26-Sep-81 1935-PDT
Date: 26 Sep 1981 2234-EDT
From: Jonathan Alan Solomon <JSol at RUTGERS>
Subject: Re: discussions about VAX/VMS, etc.
To: Admin.MRC at SU-SCORE
cc: TOPS-20 at SU-SCORE
In-Reply-To: Your message of 26-Sep-81 2037-EDT
There currently is a mailing list for discussion of VAX problems,
both for VMS and UNIX. The list is called INFO-VAX@MIT-AI, and I maintain
it. I am open to suggestions that it be moved to some more secure site
if discussions warrant doing so, but the current discussion is much
more appropriate on INFO-VAX than on TOPS-20
/Jon
-------
27-Sep-81 10:03:25-EDT,900;000000000000
Mail-from: SU-SCORE rcvd at 27-Sep-81 1003-EDT
Mail-from: ARPANET site USC-ECLB rcvd at 27-Sep-81 0701-PDT
Date: 27 Sep 1981 0650-PDT
From: Mark Thompson <THOMPSON at USC-ECLB-IPI>
Subject: Re: Investment opportunities
To: TOPS-20 at SU-SCORE
In-Reply-To: Your message of 17-Sep-81 1546-PDT
Unfortunately, at DEC everything is a P/L center, so the people
who print the manuals have to recover the cost (rather than the
more obvious method of charging it to the product). It does seem
that they could come up with some sort of scheme to keep the
prices reasonable (at the very least, print it on the same cheap
paper that IBM uses.... You dont really need notebook style paper),
and it is true that if you are a bookstore, they will kick the
price down to where you can use a reasonable markup before you
get to cover price (Which may have something to do with it too)..
-------
28-Sep-81 12:41:32-EDT,779;000000000000
Mail-from: SU-SCORE rcvd at 28-Sep-81 1241-EDT
Mail-from: ARPANET site SRI-KL rcvd at 28-Sep-81 0937-PDT
Date: 28 Sep 1981 0921-PDT
From: Richard R. Cower <COWER at SRI-KL>
Subject: Re: abysmal state of VAX/VMS
To: ROODE at SRI-KL, tops-20 at SU-SCORE
cc: COWER at SRI-KL
In-Reply-To: Your message of 26-Sep-81 1435-PDT
The only comment I can offer is that VMS is a "young" operating system,
and has a number of areas in which to grow. I can assure you, if you
had the opportunity to use an early Tenex...you would have found more
to complain about than the lack of various features in the command language.
I would advise you to make a list of your VMS complaints, and carry them
to DECUS, where you can present them to the developers.
.Rich Cower
-------
29-Sep-81 17:25:13-EDT,1206;000000000000
Mail-from: SU-SCORE rcvd at 29-Sep-81 1725-EDT
Mail-from: ARPANET site AFSC-HQ rcvd at 29-Sep-81 1420-PDT
Date: 29 Sep 1981 1716-EDT
From: Chuck Perilli <PERILLI at AFSC-HQ>
Address: HQ AFSC/ACDPS, Andrews AFB, DC 20334
Phone: (301)981-4002; AUTOVON: 858-4002
Subject: System Display Programs
To: TOPS-20 at SU-SCORE
cc: : ;
Our computer operations people have requested a program to display the
following information either on the same screen or to automatically
switch between different screens to display the information:
1. Print Queue
2. Mount Queue
3. Batch Queue
4. Jobs (a very abbreviated listing is adequate)
5. Free pages remaining on PS:
6. Load average
I am considering just modifying SYSDPY to do this on a 24x132 col CRT.
We do not have a full time operator for the 20, so they have placed a
CRT next to the console of the Honeywell 6000 that normally keeps the
operator(s) busy. Ideally, a glance at the CRT should give the operator
an idea of what's going on in the 20 and whether anything needs attention.
If anyone knows of a program more suitable than SYSDPY for this application,
I'd appreciate hearing about it.
-------
29-Sep-81 17:48:00-EDT,690;000000000000
Mail-from: SU-SCORE rcvd at 29-Sep-81 1747-EDT
Mail-from: ARPANET site SRI-KL rcvd at 29-Sep-81 1438-PDT
Date: 29 Sep 1981 1435-PDT
From: ROODE at SRI-KL (David Roode)
Subject: Re: System Display Programs
To: PERILLI at AFSC-HQ, TOPS-20 at SU-SCORE
cc: at AFSC-HQ
In-Reply-To: Your message of 29-Sep-81 1416-PDT
The way our operators watch what needs attention without being
at the console is to just make a one-way terminal link (TLINK)
from the console to their terminal. That way, all console
messages are visible at the remote location, and the terminal
they are on is free to issue normal commands.
Maybe the fancy display you want could be added to OPR.
-------
30-Sep-81 00:15:34-EDT,1124;000000000000
Mail-from: SU-SCORE rcvd at 30-Sep-81 0015-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 29-Sep-81 2109-PDT
Date: 29 Sep 1981 2108-PDT
Sender: JGOLDBERGER at USC-ISIB
Subject: Bad response under light load
From: Joel Goldberger
Reply-To: JGOLDBERGER at USC-ISIB
To: TOPS-20 at SCORE
Message-ID: <[USC-ISIB]29-Sep-81 21:08:17.JGOLDBERGER>
A number of our users have been reporting poor response even though the
Load Average is quite low (1-3). This seems to occur only after the
system has been through a period of very heavy load. For example several
of the reports have mentioned Saturday mornings after especially bad
Fridays (Load Av >25). Has anyone else noticed anything like this, or
does anyone have any ideas what might be going on.
We have class scheduling turned ON and use a bias knob setting of 6.
We have changed the bias settings so that SK%HQR is off for 6.
The specific symptom is that large programs (NLS or LISP) take a very
long time to startup. It seems that if the system is reloaded and
never goes through a high load period response is much better.
Joel Goldberger
1-Oct-81 11:31:02-EDT,388;000000000000
Mail-from: SU-SCORE rcvd at 1-Oct-81 1130-EDT
Mail-from: ARPANET site SANDIA rcvd at 1-Oct-81 0828-PDT
Date: 1 Oct 1981 0928-MDT
From: Norm Samuelson <Samuelson at SANDIA>
Subject: DECNET - performance fix for NFT/FAL
To: tops-20 at SANDIA
In the 15-Sep-81 Dispatch, a 10 page patch is given to improve performance
of NFT and FAL. Has anyone installed it?
- Sam -
-------
1-Oct-81 12:39:48-EDT,378;000000000000
Mail-from: SU-SCORE rcvd at 1-Oct-81 1239-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 1-Oct-81 0934-PDT
Date: 1 Oct 1981 1133-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: FE packs
To: tops-20 at SU-SCORE
Can a FE source pack be mounted and accessed on a VAX? Is the FE pack
format compatible with any VAX (or -11) format?
Thanks, Ed
-------
1-Oct-81 16:38:11-EDT,542;000000000001
Mail-from: SU-SCORE rcvd at 1-Oct-81 1638-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 1-Oct-81 1334-PDT
Date: 1 Oct 1981 1430-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: FE packs
To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 1-Oct-81 1033-MDT
FE source packs are unfortunately in RSX Files-11 format, but written
in 18 bit (20 sectors/track) mode instead of 16 bit mode. Thus, I suspect
that you'd have to write some special software to read them under anything other
than RSX20F.
-------
1-Oct-81 18:18:02-EDT,664;000000000001
Mail-from: SU-SCORE rcvd at 1-Oct-81 1817-EDT
Mail-from: ARPANET site SRI-KL rcvd at 1-Oct-81 1504-PDT
Date: 1 Oct 1981 1454-PDT
From: Harris A. Meyers <Meyers at SRI-KL>
Subject: Re: FE packs
To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 1-Oct-81 0933-PDT
It is a 20 sector rsx format disk. The standard diskdriver on VAX/VMS only
supports 22 sector disks. Dave Kashtan (Kashtan@sri-iu) has a driver that
will support 20 or 22 sector disks. Be warned though that there is a bug in
the parity circit on the 780's MBA that can cause your system to hang if the
2 "extra" bits are not both 0 or both 1.
harris
-------
2-Oct-81 01:21:37-EDT,660;000000000001
Mail-from: SU-SCORE rcvd at 2-Oct-81 0121-EDT
Date: 1 Oct 1981 2217-PDT
From: J. Q. Johnson <Admin.JQJ at SU-SCORE>
Subject: Re: FE packs
To: G.ECP at UTEXAS-20
cc: tops-20 at SU-SCORE
In-Reply-To: Your message of 1-Oct-81 0933-PDT
Sorry. FE packs are written in 18-bit format, not 16-bit, so they are not
accessible to any -11, just as the FE file system for the -20 (what the
-20 sees as <ROOT-DIRECTORY>FRONT-END-FILE-SYSTEM.BIN ) is not accessible
to a standard -11 disk driver. However, it would not be hard to modify
your disk driver in the VAX or -11 to read such packs; look at the mods
that were made in RSX20F for details.
-------
2-Oct-81 14:52:11-EDT,3783;000000000000
Mail-from: SU-SCORE rcvd at 2-Oct-81 1452-EDT
Date: 2 Oct 1981 1142-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: MM/XMAILR/XMAILBOX
To: TOPS-20 at SU-SCORE
cc: MMcM at SU-SCORE, Mooers at BBNA, Geoff at SRI-CSL, KLH at SRI-NIC,
Postel at USC-ISIF
[I decided to send this message to the TOPS-20 list, because
I've lost track of all the sites which run XMAILR/XMAILBOX and
some interested sites may not have heard of it.]
There are new versions of MM, XMAILR, and XMAILBOX at
SU-SCORE as MRC:<UTILITIES>MM.FAI, MRC:<UTILITIES>XMAILR.FAI, and
MRC:<UTILITIES>XMLBX.FAI. SCORE allows FTP without login for
public access files. Several major problems have been fixed, as
well as minor annoyances users have been complaining about for a
long time.
For those of you who might not know what this software is,
MM is an advanced but simple to use mailsystem for TOPS-20. It
is not as powerful as Hermes, but it has most of what a typical
user actually uses and is considerably faster than Hermes. Most
TOPS-20 sites do run MM or at least DEC's variant of it, MS.
Presently there isn't any up-to-date document on MM other than
its built-in help, but my wife is working on an Intro to MM and
an MM Manual.
XMAILR is a multi-network mailer. It supports ARPANET,
Chaosnet, Dialnet, and Ethernet. It knows about the ARPANET XRCP
and MLFL options for efficient delivery of messages. XMAILR
knows how to route messages through gateways; using XMAILR a user
on a site on MIT's Chaosnet can send mail to a site on Stanford's
Ethernet.
XMAILBOX is an advanced mailbox database lookup utility. It
reads the file SYSTEM:MAILING.LISTS or SYSTEM:MAILING.LISTS-BIN
(the latter is a compilation of MAILING.LISTS, saving it the
trouble of recompiling if it is up to date) and returns the
expansion of a mailbox. A mailbox may expand to an address (what
the BBN MAILBOX utility does) or more generally a list of
addresses; an address may be a local or network address, another
mailbox, an indirect file, or an output file. For example,
TOPS-20@SCORE expands to @PS:<TOPS-20-ARCHIVE>TOPS-20.DIS, which
in turn has the membership list plus TOPS-20-ARCHIVE, a mailbox
which expands to *PS:<TOPS-20-ARCHIVE>TOPS-20.MESSAGES (the "*"
indicates a file destination).
There are some dependencies to this software. MM as set up
by default can be stand-alone, although it is recommended that
sites which use the DEC IPCF MAILER for local mail get ahold of
Stanford's modified version (I think DEC will distribute a new
version of IPCF MAILER with release 5 that will have the better
support for MM and MS). As an option, MM can use the HOSTS2 host
table instead of the monitor host table (the limited table in
SYSTEM:HSTNAM.TXT). To use XMAILR MM must use HOSTS2, and to use
XMAILBOX the system must run XMAILR as the network mailer
(actually this last limitation is only because the old Tenex
MAILER or NMAILR doesn't know about XMAILBOX). XMAILR can run
either along with NMAILR or as the only network mailer; in the
latter case the site should get Stanford/MIT's modifications to
FTPSER to write the right format queued mail files, also any
program that writes [--UNSENT-MAIL--] files has to be either
fixed to write XMAILR-format [--NETWORK-MAIL--] files or removed.
XMAILR can be tortured into reading [--UNSENT-MAIL--] files by an
assembly switch, but doing so loses a lot of the functionality
provided only by [--NETWORK-MAIL--] files.
MM, XMAILR, and XMAILBOX can be made to run under Tenex with
some additional software.
-- Mark --
-------
2-Oct-81 23:46:24-EDT,3095;000000000000
Mail-from: SU-SCORE rcvd at 2-Oct-81 2346-EDT
Mail-from: ARPANET site RUTGERS rcvd at 2-Oct-81 2017-PDT
Date: 2 Oct 1981 2203-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: for the mailing list, a query about administrative policy
To: admin.mrc at SU-SCORE
cc: rms at MIT-AI, rindFLEISCH at SUMEX-AIM, wactlar at CMU-10A
Remailed-date: 2 Oct 1981 2040-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE, REG at SU-AI
I would appreciate having a summary about the policies used at other
sites about giving software out. I am noticing that an increasing
amount of software is becoming proprietary. We are being asked to sign
various objectionable agreements to get software from sites to whom we
have freely given our software and software support. I am seriously
considering adopting some sort of policy whereby we treat a site the
same way they treat us. This will take some care to formulate. Among
the problems is how to handle the fact that there are different groups
at the same institution that have different policies. E.g. I have
excellent relations with most of MIT. However our VLSI group just got a
license from another research team at MIT which they are supposed to
sign that would by implication require us to make the software
execute-only, not put it on backups, and would allow them to remove our
right to use it (and make us expunge all copies) on 90 days notice
without cause. I do not intend to single out MIT, since we have had
similar occurrences with most Universities with whom we deal (and not with
some industrial groups).
If we don't do anything about this, it is easy to forsee the collapse
of the "hacker community" that has given us all the software we know
and love on PDP-10's of various colors.
If the problem is not with the groups themselves, but with University
lawyers, then I would suggest that a reasonable approach would be
to start a cooperative arrangement among any interested Universities
wherein all software within a certain class is mutually licensed.
Personally, I would be happy to include non-Universities, but some
University legal staffs might feel that this would be a bad idea.
(Or maybe they could join by paying some sort of royalty fee to
the group as a whole.) When you are dealing with only one program, it is
easy to feel that what you have to gain by keeping control of that
program outweighs any vague concern about mutuality with other
researchers. However if there is a large body of existing software from
which you will be cut off if you don't agree to share, the tradeoff will
probably look quite different.
What I really want is for this to go to system managers. I would
appreciate it if you would forward this message to anyone who seems
appropriate. I would appreciate in knowing how many sites would be
interested in getting involved in such an arrangement, and what they
think it could reasonably cover, i.e. just things developed by
hackers, or results of reseach projects?
-------
3-Oct-81 00:21:33-EDT,2174;000000000000
Mail-from: SU-SCORE rcvd at 3-Oct-81 0021-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 2-Oct-81 2113-PDT
Date: 2 Oct 1981 2214-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: for the mailing list, a query about administrative policy
To: tops-20 at SU-SCORE
In-Reply-To: Your message of 2-Oct-81 2003-MDT
I am in almost total sympathy with Chuck. For the record, we have a written
departmental policy requiring the free distribution of software developed
here to other universities and not-for-profit institutions, although it
does allow for the sale of software to for-profit concerns. The sole
exception to this is where the terms of a contract prohibit this (for
example, the sponsor reserved certain proprietary rights to the software);
we normally strongly fight against such clauses in contracts, but sometimes
they are inevitable.
It therefore strongly bothers us when we get charged for software developed
at other universities. I agree that it is very tempting to begin to treat
others the way that we're being treated.
The one mild exception that I have with Chuck's msg is that we have found
it necessary under certain circumstances to require license agreements for some
of our software (at the moment REDUCE, the X.25 package, and shortly PCC/20).
This is because of our desire to prevent recipients of the software from
re-marketing our software for profit. This is not some abstract concern.
About two years ago (prior to our having any license agreements), a Boston
firm actually took REDUCE and marketed it under the name AUTOMATH with only
trivial modifications. As we had (at that time) no licensing procedures,
the Univ. lawyers said we had no basis for legal action. Thus our
current license grants a non-tranferable, non-exclusive license to the
specified software. I sincerely hope that it doesn't have any of the
objectionable clauses that Chuck has alluded to (I promise I'll go check!)
I think that it may be very feasible to develop some blanket license
agreement that provides the type of protection we feel is needed, but doesn't
have to be signed for each piece of software.
Randy
-------
3-Oct-81 01:02:37-EDT,1210;000000000000
Mail-from: SU-SCORE rcvd at 3-Oct-81 0102-EDT
Date: 2 Oct 1981 2158-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: Re: for the mailing list, a query about administrative policy
To: FRANK at UTAH-20, HEDRICK at RUTGERS, TOPS-20 at SU-SCORE
cc: rms at MIT-AI, rindFLEISCH at SUMEX-AIM, wactlar at CMU-10A
In-Reply-To: Your message of 2-Oct-81 2112-PDT
I think Randy's message says more or less the same thing
about how Stanford handles licensing. For our "proprietary"
software we require some kind of a non-disclosure agreement (e.g.
a non-transferable non-exclusive software license) to prevent the
sort of theft Randy alluded to (the guy who attempted to market
REDUCE as AUTOMATH was unreal!). In some cases we just might
want to sell the software to a for-profit concern although we'd
never grant an exclusive license. I believe that Stanford is
usually pretty open about its software distribution policy and
our restrictions, such as they are, are to protect that software
from being re-marketed for profit by others.
-- Mark --
-------
3-Oct-81 02:08:49-EDT,1289;000000000010
Mail-from: SU-SCORE rcvd at 3-Oct-81 0208-EDT
Date: 2 Oct 1981 2259-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: Craig Taylor's MM problem
To: CTaylor at USC-ISIF, Action at USC-ISIB, TOPS-20 at SU-SCORE
The problem with MM and "MOVE ^B?" automatically doing the
MOVE turns out to be a monitor bug. If a SAVED-MESSAGES-FILE is
set up in MM, the MOVE command defaults to it. When COMND sees
the invalid character "^B", the file parse fails, and COMND
cleverly overwrites the garbage with the filename, leaving no
trace in the buffer of the garbage. What's worse, it appends a
CR/LF at the end after the filename, so if the filename is the
last item on the command line or is followed only by defaults,
the command will instantly execute!
This monitor bug can be demonstrated in my TELNET as well, by
typing "LOG ^B?" to it. You'll get no help, it will immediately
confirm, and behave as if "LOG TELNET.LOG" was typed.
I poked around a bit in MDDT at SCORE trying to come up with
a quick patch, but nothing I did worked right. If anybody has a
fix for this bug, I'd appreciate it...
-- Mark --
-------
3-Oct-81 11:59:02-EDT,1004;000000000000
Mail-from: SU-SCORE rcvd at 3-Oct-81 1158-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 3-Oct-81 0853-PDT
Date: 3 Oct 1981 0853-PDT
Sender: SMITH at USC-ISIB
Subject: OFNs getting used up
From: SMITH at USC-ISIB
To: TOPS-20 at SU-SCORE
Message-ID: <[USC-ISIB] 3-Oct-81 08:53:32.SMITH>
We found that on one of our systems with many directoriess and much
mutual access that we were steadily losing OFN's. The problem was a
flag set wrong in the directory cache code.
LINE 1, PAGE 1
1) ;<ISI.MONITOR>DIRECT.MAC.3200 17-Jul-81 12:26:35 Edit by SMITH
1) ;#320 Set "release OFN" flag correctly when no room in directory cache
1) ;<ISI.MONITOR>DIRECT.MAC.3110 7-Jul-81 10:32:12 Edit by SMITH
LINE 1, PAGE 1
2) ;<ISI.MONITOR>DIRECT.MAC.3110 7-Jul-81 10:32:12 Edit by SMITH
LINE 98, PAGE 33
1) JRST [ SETONE DRROF ;#320 INDICATE TO RELEASE THIS
1) UNLOCK DIRCLK ;RELEASE LOCK
LINE 98, PAGE 33
2) JRST [ SETZRO DRROF ;INDICATE TO RELEASE THIS
2) UNLOCK DIRCLK ;RELEASE LOCK
5-Oct-81 00:17:29-EDT,467;000000000000
Mail-from: SU-SCORE rcvd at 5-Oct-81 0017-EDT
Mail-from: ARPANET site RUTGERS rcvd at 4-Oct-81 2114-PDT
Date: 5 Oct 1981 0003-EDT
From: WATROUS at RUTGERS (Don Watrous)
Subject: Re: Craig Taylor's MM problem
To: Admin.MRC at SU-SCORE, CTaylor at USC-ISIF, Action at USC-ISIB,
To: TOPS-20 at SU-SCORE
In-Reply-To: Your message of 3-Oct-81 0159-EDT
See HEDRICK's message to TOPS-20 distribution list dated 21 Jul 81,
subject "comnd jsys bug fix".
-------
5-Oct-81 00:23:24-EDT,1332;000000000000
Mail-from: SU-SCORE rcvd at 5-Oct-81 0023-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 4-Oct-81 2120-PDT
Date: 4 Oct 1981 2218-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Performance "bug" in FESRV
To: tops-20 at SU-SCORE
This performance bug fix is un-important unless you make heavy use of FE:
devices on a front-end (I think some of the IBM comm stuff does; we do for
several specialized uses here).
In FESRV BLKSIZ is set to 64 words, which for 8 bit bytes translates to
a 256 byte buffer. This means that every time that FESRV calls DTESRV (DTEQ)
with a buffer, it's usually 256 bytes long. Unfortunately, a maximum
size front-end indirect packet is 254 bytes long, guaranteeing that
every FE buffer gets split up into two DTE buffers, one 254 long and one
2 bytes long, which totally kills the little performance that the DTE
is capable of (we're trying to stuff a lot of data down a DTE through a
FE device, and were analyzing where all the overhead was).
Cutting BLKSIZ down to 62 in FESRV guarantees that for 8 bit bytes an FE
buffer will fit in a DTE indirect packet. The correct solution (which
I haven't done since we always use 8 bit bytes on an FE:), it to calculate
the buffer size in conjunction with the byte size to make sure that
the result will fit in a DTE packet.
-------
6-Oct-81 16:32:45-EDT,1141;000000000000
Mail-from: SU-SCORE rcvd at 6-Oct-81 1632-EDT
Mail-from: ARPANET site RADC-TOPS20 rcvd at 6-Oct-81 1328-PDT
Date: 6 Oct 1981 1625-EDT
From: Mark Pratt <PRATT at RADC-TOPS20>
To: TOPS-20 at SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: [OPERATOR at WPAFB-AFWAL: Your Archive Program]
Message-ID: <MS"5(1646)"11766032243.6.158.112464 at RADC-TOPS20>
Is there anyone out there with an archive system for DEC-10's.
Please reply to OPERATOR@WPAFB-AFWAL (Joe McClendon)
Thanks,
Mark
- - - - - - - Begin message from: OPERATOR at WPAFB-AFWAL
Mail-from: ARPANET host WPAFB-AFWAL rcvd at 6-Oct-81 1533-EDT
Date: 6 Oct 1981 (Tuesday) 1532-EDT
From: OPERATOR at WPAFB-AFWAL
Subject: Your Archive Program
To: PRATT at RADC-TOPS20, ADMIN at RADC-TOPS20
This is Joe McClendon. I am the administrator for the DEC-10 here.
I've been told that you have a program that archives sets of files
for users. I'de like very much to get what info you have on this
program. Please advise if it works on a DEC-10 and how I can get
it.
Thanks,
Joe
- - - - - - - End forwarded message
--------
6-Oct-81 17:14:45-EDT,617;000000000000
Mail-from: SU-SCORE rcvd at 6-Oct-81 1714-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 6-Oct-81 1409-PDT
Date: 6 Oct 1981 1609-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: VISICALC
To: tops-20 at SU-SCORE
Does anyone know of a VISICALC implementation (or something
simular) on DEC20's? For those of you not familiar with
VISICALC, it is a very popular program on APPLES, Trash-80's,
etc, which provides an electronic worksheet for analyzing any
type of 'what if' situations.
(if I find anything, I will forward the info back to this
mailing list)
Thanks,
Ed
-------
7-Oct-81 15:16:44-EDT,359;000000000000
Mail-from: SU-SCORE rcvd at 7-Oct-81 1516-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 7-Oct-81 1212-PDT
Date: 7 Oct 1981 0954-PDT
From: Rindfleisch at SUMEX-AIM
Subject: UNINET
To: TOPS-20 at SU-SCORE
Does anyone know of or have direct experience with UNINET as a network
for remote terminal access to TOPS-20/TENEX systems?
Tom R.
-------
11-Oct-81 23:06:15-EDT,965;000000000000
Mail-from: SU-SCORE rcvd at 11-Oct-81 2306-EDT
Date: 11 Oct 1981 2003-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: RNAMX2 error
To: TOPS-20 at SU-SCORE
I have encountered a problem where a program can get the RNAMX2 error.
It reads a file, and can overwrite it with a new version of that file;
it first builds that file under another name and then renames it over.
If that file gets expunged at exactly the right time, the RNAMX2 can
happen.
I have come to the conclusion that the proper fix is to remove the
RNAMX2 error entirely. If a superceding RNAMF% finds that the file is
gone, it should treat that JFN as a virgin JFN (which is what the user
application wanted to do when it unmapped all the pages and closed the
file).
Has anybody else encountered this problem (and perhaps has a fix)?
-------
12-Oct-81 19:01:13-EDT,1118;000000000000
Mail-from: SU-SCORE rcvd at 12-Oct-81 1901-EDT
Mail-from: ARPANET site SRI-KL rcvd at 12-Oct-81 1548-PDT
Date: 12 Oct 1981 1446-PDT
From: LARSON at SRI-KL
Subject: host tables in monitor
To: TOPS-20 at SU-SCORE
I have noticed an apparent inefficiency in the monitor host tables.
It looks like the tables HSTSTS and HOSTNN need to have one entry per
host, while HOSTN needs to have one entry per host name. This means
that HOSTN must be larger by the number of nicknames in the tables.
There is only one variable (NHOSTS) that describes the length of these
tables, so two of them must be somewhat larger than they need to be.
If a new variable were created, perhaps NHOSTN (Number of HOST Names),
we could shrink the size of HOSTN. Many references would have to be
checked, to be sure that all indexes were properly based on the new
variable (some routines scan HOSTN, assuming it to be NHOSTS long).
Has anyone thought about this before? I am really suprised that it
hasn't been done -- especially in tenex, where address space in the
monitor is sometimes quite critical.
Alan
-------
12-Oct-81 19:31:20-EDT,583;000000000000
Mail-from: SU-SCORE rcvd at 12-Oct-81 1931-EDT
Date: 12 Oct 1981 1559-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: host tables in monitor
To: TOPS-20 at SU-SCORE
Of course, a solution is not to have nicknames in the monitor
host table at all, which is what Stanford and a number of other
places have done by moving to the HOSTS2 host table. That way monitor
address space isn't wasted with lots of worthless nicknames.
-------
12-Oct-81 20:18:15-EDT,995;000000000000
Mail-from: SU-SCORE rcvd at 12-Oct-81 2018-EDT
Date: 12 Oct 1981 1712-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: .MORSP function of MTOPR%
To: TOPS-20 at SU-SCORE
There is a monitor problem in that an unprivileged user
cannot do a .MORSP MTOPR% on another user's terminal. This
breaks the /DIAL-IN switch in SCORE's FINGER program for
unprivileged users. What happens is that MTOPR calls CHKJFN,
which does the access check without knowing that it is perfectly
safe to let a .MORSP MTOPR% through. My fix to this was to
replace the following two instructions at CHKJF5-2 in IO.MAC:
MOVEI A,DESX2
RET
with:
UMOVE A,B ;GET POSSIBLE MTOPR% FUNCTION CODE
HRL A,KIMUEF ;GET JSYS NUMBER
CAME A,[<MTOPR%>,,.MORSP] ;IS THIS AN .MORSP MTOPR%?
RETBAD (DESX2) ;TTY NOT AVAILBLE TO THIS JOB
;...DROP INTO CHKJF5
-------
13-Oct-81 12:33:10-EDT,520;000000000000
Mail-from: SU-SCORE rcvd at 13-Oct-81 1233-EDT
Mail-from: ARPANET site BBNG rcvd at 13-Oct-81 0526-PDT
Date: 13 Oct 1981 0821-EDT
From: Dan Tappan <Tappan at BBNG>
Subject: Re: host tables in monitor
To: Admin.MRC at SU-SCORE
cc: TOPS-20 at SU-SCORE, Tappan at BBNG
In-Reply-To: Your message of 12-Oct-81 1859-EDT
There really isn't an inefficency there. HOSTNN and HSTSTS
are hash tables, and thus need to be twice as large as the
number of hosts, whereas HOSTN is used in a linear search.
Dan
-------
13-Oct-81 17:38:21-EDT,748;000000000010
Mail-from: SU-SCORE rcvd at 13-Oct-81 1738-EDT
Mail-from: ARPANET site AFSC-HQ rcvd at 13-Oct-81 1433-PDT
Date: 13 Oct 1981 1750-EDT
From: Chuck Perilli <PERILLI at AFSC-HQ>
Address: HQ AFSC/ACDPS, Andrews AFB, DC 20334
Phone: (301)981-4002; AUTOVON: 858-4002
Subject: Character Handling in FORTRAN
To: TOPS-20 at SU-SCORE
cc: PM at AFSC-HQ, : ;
Does anyone have (or know of) a package of string handling routines
for FORTRAN. Current Air Force policy requires all "official" programs
be written in COBOL or FORTRAN, and our programmers are having fits
with DEC's archaic version of FORTRAN. Most other mini/maxi computers,
including VAX, have FORTRAN-77 which at least addresses the problem of
character handling.
-------
13-Oct-81 18:35:25-EDT,965;000000000000
Mail-from: SU-SCORE rcvd at 13-Oct-81 1835-EDT
Mail-from: ARPANET site RUTGERS rcvd at 13-Oct-81 1534-PDT
Date: 13 Oct 1981 1828-EDT
From: PLEASANT at RUTGERS (Mel Pleasant)
Subject: Re: Character Handling in FORTRAN
To: PERILLI at AFSC-HQ
cc: TOPS-20 at SU-SCORE, PM at AFSC-HQ, PLEASANT at RUTGERS
In-Reply-To: Your message of 13-Oct-81 1750-EDT
There exists a string handling package called STRLIB which
was explicitly written for FORTRAN. Unfortunately, the entire
package is written in MACRO. It does not contain any UUO or JSYS
calls so it can be used on either a DEC-10 or DEC-20. This package
was/is?? distributed by DEC. If you can't get the package from DEC
quickly, you can FTP the .rel and .doc files from here. If you want,
I can also restore the sources for you from tape. The two files
which are currently up on this system are:
<Unsupported>Strlib.Rel
<Documentation>Strlib.Doc
-Mel
-------
13-Oct-81 23:17:02-EDT,563;000000000000
Mail-from: SU-SCORE rcvd at 13-Oct-81 2316-EDT
Mail-from: ARPANET site RUTGERS rcvd at 13-Oct-81 2014-PDT
Date: 13 Oct 1981 2135-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: Character Handling in FORTRAN
To: PERILLI at AFSC-HQ
cc: TOPS-20 at SU-SCORE, PM at AFSC-HQ, at AFSC-HQ
In-Reply-To: Your message of 13-Oct-81 1750-EDT
DEC has an old package that is quite complete. I think it is called
STRLIB. We probably have it lying around from the days when we
were a Tops-10 site. Haven't seen it since.
-------
14-Oct-81 21:34:17-EDT,652;000000000000
Mail-from: SU-SCORE rcvd at 14-Oct-81 2134-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 14-Oct-81 1832-PDT
Date: 14 Oct 1981 2031-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: Visicalc
To: tops-20 at SU-SCORE
Regarding my earlier message concerning a implementation of
VISICALC on a DEC-20, a version is currently being developed by
National Computer Performance Company. More information can be
obtained by writing ;
Bud Pine
National Computer Performance Co.
907 Flying Fish St.
Foster City, CA 94404
The product is hoped to be ready for preliminary demonstrations in
about 6 weeks or so.
-- Ed
-------
15-Oct-81 06:59:31-EDT,328;000000000000
Mail-from: SU-SCORE rcvd at 15-Oct-81 0659-EDT
Mail-from: ARPANET site CMU-20C rcvd at 15-Oct-81 0357-PDT
Date: 15 Oct 1981 0656-EDT
From: WOHL at CMU-20C
Subject: Large RP06 structures?
To: TOPS-20 at SU-SCORE
Does someone have monitor changes to allow RP06 structures to be larger
than three packs?
Aaron
-------
15-Oct-81 10:51:44-EDT,666;000000000001
Mail-from: SU-SCORE rcvd at 15-Oct-81 1051-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 15-Oct-81 0747-PDT
Date: 15 Oct 1981 0730-PDT
Sender: SMITH at USC-ISIB
Subject: Re: Large RP06 structures?
From: SMITH at USC-ISIB
To: WOHL at CMU-20C
Cc: TOPS-20 at SU-SCORE
Message-ID: <[USC-ISIB]15-Oct-81 07:30:38.SMITH>
In-Reply-To: Your message of 15 Oct 1981 0656-EDT
You may have up to 6 RP06's in a structure if you change:
DSKMSK to 777770 in STG
DSKMSK to -1B14 in CHECKD
DSKNB to 1B13 in PROLOG
MXSTRU to 6 in your parameters file (it comes that way in PARAN only;
there is an "NDG MXSTRU,4" in PROLOG)
Dennis
15-Oct-81 14:48:13-EDT,1210;000000000000
Mail-from: SU-SCORE rcvd at 15-Oct-81 1448-EDT
Date: 15 Oct 1981 1142-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: bug?/misfeature? in IDTIM JSYS
To: TOPS-20 at SU-SCORE, Goldberg at USC-ISIB
The string "14 October 1981 21:50 edt" is parsed as being
October 14, 1981 9:50PM in whatever the local time zone is. This
is because IDTIM terminates its parse at the space after "21:50"
and never even sees the "edt". This breaks MM's date/time
parsing code (for "In-Reply-To:" in a REPLY message) if the
recepient is in a different time zone from the sender. Multics
systems send messages with this format date/time.
I think that what needs to be done is to fix IDTIM to save
the pointer after a successful time parse and continue reading
characters if the terminator was merely a space. If it's unable
to figure out what is after the time, it should restore the
pointer as the updated string pointer; otherwise it should parse
it in case it's a timezone or AM/PM/etc.
Has anybody worked on IDTIM in this area?
-- Mark --
-------
15-Oct-81 15:41:00-EDT,489;000000000000
Mail-from: SU-SCORE rcvd at 15-Oct-81 1540-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 15-Oct-81 1233-PDT
Date: 15 Oct 1981 1233-PDT
From: Eric Schoen <Schoen at SUMEX-AIM>
Subject: Re: bug?/misfeature? in IDTIM
To: tops-20 at SU-SCORE
Mark,
I'm all in favor of doing what you suggested. I have code in the Tops-20/Tenex
Pup service to do exactly that, since Unix and later IFS operating systems
place the timezone after the time, separated by a space.
Eric
-------
15-Oct-81 16:57:57-EDT,820;000000000001
Mail-from: SU-SCORE rcvd at 15-Oct-81 1657-EDT
Mail-from: ARPANET site USC-ISIB rcvd at 15-Oct-81 1349-PDT
Date: 15 Oct 1981 1347-PDT
Sender: SMITH at USC-ISIB
Subject: Re: Large RP06 structures? [revised reply]
From: SMITH at USC-ISIB
To: WOHL at CMU-20C
Cc: TOPS-20 at SU-SCORE
Message-ID: <[USC-ISIB]15-Oct-81 13:47:55.SMITH>
In-Reply-To: Your message of 15 Oct 1981 0656-EDT
You may have up to 6 RP06's in a structure if you change:
DSKMSK to 777770 in STG
DSKMSK to -1B14 in CHECKD
DSKNB to 1B13 in PROLOG
MXSTRU to 6 in your parameters file (it comes that way in PARAN;
there is an "NDG MXSTRU,4" in PROLOG)
You also need to modify the MXPGUN computation in STG to be based on
PAGCY1 & CYLUN1 instead of PAGCY0 & CYLUN0, or make MXSTRU be 12.
Dennis
15-Oct-81 17:32:53-EDT,4109;000000000000
Mail-from: SU-SCORE rcvd at 15-Oct-81 1732-EDT
Mail-from: ARPANET site RUTGERS rcvd at 15-Oct-81 1427-PDT
Date: 15 Oct 1981 1725-EDT
From: WATROUS at RUTGERS (Don Watrous)
Subject: <SYSTEM>ARCHIVE-REQUESTS.BIN, etc.
To: Tops-20 at SU-SCORE
Well, I believe I've finished the speedup for DEC's archive system.
I've also done some more support work on it too. The programs
affected are the monitor, the EXEC, and DUMPER. I've provided (on
[RUTGERS]PS:<ANONYMOUS>) FILCOMs (DIFs, actually) for the monitor
(DISC.DIF and JSYSF.DIF) and the EXEC (EXECIN.DIF) and our sources
for DUMPER, REAPER, and REV. FTP them at your convenience. Remember
we're only on the Arpanet over a 9600 baud phone line so please be
patient.
The monitor has three changes: 1) <SYSTEM>ARCHIVE-REQUESTS.BIN is
supported. (This has been redone since my last message to use two
bits to avoid races). ARCF does not call UPDDIR on read-only
functions. (This is the same patch I sent before and is highly
recommended.) 3) A table entry is changed for RNAMF. (A file
shouldn't take the "exempt from migration" bit with it if it's
renamed. When it does, people who rename MAIL.TXT to MAIL.OLD cannot
archive MAIL.OLD.)
The EXEC changes are: An INFO PENDING-ARCHIVE-REQUESTS command (much
like INFO ARCHIVE-STATUS, but only for incompleted requests) has been
added which now uses <SYSTEM>ARCHIVE-REQUESTS.BIN if the filespec is
<*>*.*.*. (There is a SCAN subcommand to override use of the .BIN
file.) INFO DISK reports on pages pending archive.
For DUMPER I've just included the source because it's easier and
there's no reason not to. It includes a lot of work done locally,
none of which should bother anyone. First of all, for archive runs
of <*>*.*.*, <SYSTEM>ARCHIVE-REQUESTS.BIN is supported. (There is a
/SCAN switch to override this.) Files being archived aren't set
invisible. (This is done automatically by the EXEC, and if the user
deliberately undoes it, why give them a hassle?) Other local mods
include handling Tops-10 SFD's (which was handy for moving from a 10
to a 20), a TAKE command, a CSAVE command (not used anymore, but for
continuing a saveset), a /NOMAIL switch for archiving (which we've
found useful when re-archiving files which were on a destroyed
archive tape - it saved half the confusion), an IGNORE command for
ignoring saveset boundaries on the tape (when you know the files are
\somewhere/ on that tape). Also included are various useful
bugfixes.
REV has a lot of support for the archive functions in the FDB. While
not necessary for the archive speedup, it's quite useful. (It also
supports a just added feature here - the "Last reader" string in the
FDB. If people are interested in this - I stole .FBBK2 for it - I
can distribute the code for the monitor/EXEC involved.)
REAPER too, while not being necessary for the archive speedup, has
had a LOT of work done on it. We use it basically for trimming users
down to quota, so we've put some work into that area. If you specify
INTERROGATE, REAPER will ask "Trim PS:<USER> to 100?" before doing
it. (If you like at this point, you can specify another value to
trim to.) The exempt from migration bit is set for MAIL.TXT,
20-ARCHIVE.DIR (a remnant of our previous archiver), [UNSENT-MAIL].*
and MIGRATION.ORDER. Files are trimmed in reverse chronological
order of access (rather than alphabetical). Much speedup has been
effected when used for a trim (90% of both elapsed and cpu time).
Pending archive/migration requests aren't counted against the user.
Online archived files have their contents deleted if they would be
migrated. A DISTRIBUTE command will invoke quota distributing
between a user and their subdirectories. (If the user's total usage
exceeds their total quota, then over quota directories are trimmed
proportionately until the total usage is brought in line.)
I'll leave the files online until they're not accessed for a while.
You'll feel better about the archiving system once you get all this
code in your system!
Don
-------
15-Oct-81 19:52:18-EDT,1790;000000000000
Mail-from: SU-SCORE rcvd at 15-Oct-81 1952-EDT
Mail-from: ARPANET site SUMEX-AIM rcvd at 15-Oct-81 1646-PDT
Date: 15 Oct 1981 1643-PDT
From: Sweer at SUMEX-AIM
Subject: Bug in Tenex EDDT
To: Tops-20 at SU-SCORE
There is a problem proceeding from breakpoints in Tenex EDDT
which TOPS20 has fixed, but I note is not fixed in our sources,
nor in those at ISI or BBN. When called from a breakpoint in
a BUGCHK or BUGHLT (or anywhere else for that matter), EDDT
saves the state of the PI system via CONI PI,SAVPI, and then
turns off all channels via CONO PI,@SAVPI+1. The location
SAVPI+1 contains the octal constant 1177 (in both 10X and Tops20),
which turns off all selected channels. The problem comes in
restoring the state of the PI system in the routine RESTOR.
The code in 10x is as follows:
MOVE T,SAVPI
... ;a few other instructions
AND T,SAVPI+1
IORI T,2000 ;Turn on channels
HRRZM T,SAVPI
... ;a few other instructions
CONO PI,@SAVPI
Bit 26 is the problem. If PI6 was in progress at the time of the
breakpoint (and at Sumex there's a lot of action on PI6), it is
preserved over the AND T,SAVPI+1, and the resultant CONO PI,@SAVPI
ends up with both bits 25 and 26 ON! This has resulted in the loss
of PI active bits for various channels, as the CONO tells the machine
to turn them on and turn them off in the same CONO. For us the fix
is to change the AND T,SAVPI+1 to an ANDI T,177. Tops20 chose to
insert a TRZ T,1000 following the IORI T,2000. I gather whoever
made that fix wasn't really sure what to do, as there was no edit
history line referring to it, and word of such a bug never got
passed around to the Tenex sites after it was discovered. Also they
left in the AND T,SAVPI+1 which is obviously wrong.
Andy
-------
16-Oct-81 17:14:39-EDT,387;000000000000
Mail-from: SU-SCORE rcvd at 16-Oct-81 1714-EDT
Mail-from: ARPANET site RUTGERS rcvd at 16-Oct-81 1404-PDT
Date: 16 Oct 1981 1651-EDT
From: WATROUS at RUTGERS (Don Watrous)
Subject: Support for last reader string
To: Tops-20 at SU-SCORE
Rutgers' support for the last reader string is now available for
anonymous FTP as [RUTGERS]PS:<ANONYMOUS>LAST-READER.STRING.
Don
-------
17-Oct-81 15:59:36-EDT,525;000000000000
Mail-from: SU-SCORE rcvd at 17-Oct-81 1559-EDT
Mail-from: ARPANET site SRI-KL rcvd at 17-Oct-81 1255-PDT
Date: 17 Oct 1981 1252-PDT
From: ROODE at SRI-KL (David Roode)
Subject: stalled forks
To: tops-20 at SU-SCORE
Was there some bug uncovered recently that had to do
with forks that on startup for the first time appeared
to be frozen for a period ranging from 20 seconds to
2 minutes? Control-C won't interrupt a fork in this state.
I thought I saw something about this but can't chase it down
now.
-------
17-Oct-81 18:58:29-EDT,983;000000000000
Mail-from: SU-SCORE rcvd at 17-Oct-81 1858-EDT
Mail-from: ARPANET site UTEXAS-20 rcvd at 17-Oct-81 1553-PDT
Date: 17 Oct 1981 1749-CDT
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: DEC Monitor classes
To: tops-20 at SU-SCORE
Does anyone have any experience with the two DEC Monitor classes,
the one week monitor structures class, and the two week monitor
internals class? If you are going to take the internals class,
do you need the structures class, and vice versa? I need to educate
my systems people on supporting the monitor. They have been hacking on
TOPS-20 for about two years, but just now have we received a source
license. If anyone has any experience that they can share, I would
appreciate it. I mainly need to decide if both classes are going
to be necessary for them, and whether I need to send everyone, or
whether the handouts are sufficient for one to be able to pass
on the knowledge to the rest.
Thanks,
Ed
-------
17-Oct-81 19:07:17-EDT,1069;000000000000
Mail-from: SU-SCORE rcvd at 17-Oct-81 1907-EDT
Date: 17 Oct 1981 1602-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: TOPS-20 monitor classes
To: TOPS-20 at SU-SCORE
I took Monitor Internals in February 1980. Monitor Structures is
a new course; I have the feeling it is mostly an overview course such
as the old System Programming course was. I highly recommend it. It
is not a good idea to try to use the course materials without taking
the course. Whether or not you send one person to take the course and
then to pass it on or send everybody is up to you; I feel that anybody
who is going to work on the monitor regularly should take the course
for him or her self.
My notes from MI are online at SCORE on the TOPS-20 archive as
PS:<TOPS-20-ARCHIVE>T20-MONITOR-INTERNALS.CLASS-NOTES. Most of it is
release 3A oriented, although there are some notes about 3A/4 differences.
-- Mark --
-------
17-Oct-81 19:16:01-EDT,474;000000000000
Mail-from: SU-SCORE rcvd at 17-Oct-81 1915-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 17-Oct-81 1611-PDT
Date: 17 Oct 1981 1707-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: DEC Monitor classes
To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 17-Oct-81 1649-MDT
I agree with MRC. I found the internals course to be well worth the time.
The lectures and labs were very good, and the course materials are also
excellent.
-------
18-Oct-81 16:21:40-EDT,962;000000000000
Mail-from: SU-SCORE rcvd at 18-Oct-81 1621-EDT
Mail-from: ARPANET site MIT-XX rcvd at 18-Oct-81 1317-PDT
Date: 18 Oct 1981 1615-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: Rebuilding file system
To: tops-20 at SU-SCORE
A funny things just happened to me when I re-built my PS: to make more
swap space...I got more free space when I was done than I had when I
started. Before the rebuild I had 8800 free pages. I increased the
swap space by 3000 pages. After restoring all the files I had 10000
free pages. There is a remote possibility that the old PS: was
configured with more swap space than I thought, but this is somewhat
unlikely.
Any ideas? I find it hard to believe that directory compaction could
account for ~5000 pages. Also, I can't see how we had that many "lost
pages". We may not run CHECKD as often as we should but we run it
often enough so that there wouldn't be that many lost pages.
-- Nat Mishkin
-------
19-Oct-81 09:41:30-EDT,433;000000000000
Mail-from: SU-SCORE rcvd at 19-Oct-81 0941-EDT
Mail-from: ARPANET site MIT-XX rcvd at 19-Oct-81 0637-PDT
Date: 19 Oct 1981 0935-EDT
From: Steve Berlin <BERLIN at MIT-XX>
Subject: Re: Stalled Forks
To: tops-20 at SU-SCORE
We sometimes get the condition you describe when a user resets
a multi-section fork, then creates any new fork. Eventually
a fork-lock timeout occurs (usually) and the new process continues.
-------
19-Oct-81 13:09:59-EDT,770;000000000000
Mail-from: SU-SCORE rcvd at 19-Oct-81 1309-EDT
Mail-from: ARPANET site RUTGERS rcvd at 19-Oct-81 1003-PDT
Date: 19 Oct 1981 1303-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: Rebuilding file system
To: NWM at MIT-XX
cc: tops-20 at SU-SCORE
In-Reply-To: Your message of 18-Oct-81 1615-EDT
Are you sure your swap space is what you think it is? There
are some problems about when swap space is octal and when it
is decimal, and it is very easy to get numbers that are
different than what you expected. We have a program, PHOME,
that prints disk parameters from the home blocks. It turns
out to be very useful in figuring out what changes you have
really made. You are welcome to FTP s:<un-sources>phome.mac.
-------
19-Oct-81 16:33:20-EDT,741;000000000000
Mail-from: SU-SCORE rcvd at 19-Oct-81 1633-EDT
Mail-from: ARPANET site DEC-MARLBORO rcvd at 19-Oct-81 1325-PDT
Date: 19 Oct 1981 1619-EDT
From: Kevin Paetzold <PAETZOLD at DEC-MARLBORO>
To: TOPS-20 at SU-SCORE, weiner at RADC-MULTICS, weiner.ball at RADC-TOPS20,
metzger at RADC-TOPS20, admin at RADC-TOPS20, ata at RADC-MULTICS
Reply-to: Paetzold at DEC-MARLBORO
DTN: 231-7430
Mail-Stop: MR1-2/L10
Telephone: 617-467-7430
Subject: My network mail address
Message-ID: <MS"5(1631)"11769438966.34.126.41318 at DEC-MARLBORO>
I have finally changed my mail address to DEC-MARLBORO from RADC-TOPS20.
My network mail address is now PAETZOLD@DEC-MARLBORO. Please send all
mail for me to PAETZOLD@DEC-MARLBORO.
--------
19-Oct-81 18:53:35-EDT,307;000000000000
Mail-from: SU-SCORE rcvd at 19-Oct-81 1853-EDT
Mail-from: ARPANET site SRI-KL rcvd at 19-Oct-81 1546-PDT
Date: 19 Oct 1981 1541-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: Stalled Forks
To: BERLIN at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 19-Oct-81 0635-PDT
-------
19-Oct-81 20:43:18-EDT,467;000000000000
Mail-from: SU-SCORE rcvd at 19-Oct-81 2043-EDT
Mail-from: ARPANET site WASHINGTON rcvd at 19-Oct-81 1736-PDT
Date: 19 Oct 1981 1726-PDT
From: Joe Kelsey <JOE at WASHINGTON>
Subject: Spooled terminals
To: tops-20 at SU-SCORE
cc: Joe at WASHINGTON
Does anyone have a version of 180SPL which has been modified for the
new Release 4 ORION/OPR operator interface? I would like to put a
Printronix on a serial line, and need a spooler for it.
/Joe
-------
19-Oct-81 23:12:31-EDT,3011;000000000011
Mail-from: SU-SCORE rcvd at 19-Oct-81 2312-EDT
Mail-from: ARPANET site SRI-KL rcvd at 19-Oct-81 2006-PDT
Date: 19 Oct 1981 1918-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: ultra cheap & easy front-ends
To: TOPS-20 at SU-SCORE
(Sorry for previous blank message: that was a mailsystem screwup.)
This is a simple announcement about easy-to-connect front-ends which
might be of interest to some of you.
We, at Fairchild, needed to connect up our -20 to our local Chaosnet
(for Lisp Machine and VAX interconnectivity), and needed to do it
quickly. I started the usual "fake" DN20 construction job (cf earlier
message from Randy Frank and myself about rolling your own DN20), but
soon found DEC to be totally wedged about it (at least out here):
Field Service will no longer be helpful about getting the few odd
parts needed to build a complete DN20 lookalike.
All is far from lost. I ordered a standard DTE set (M8552, M8553, M8554)
from DEC Direct Sales (call them in Nashua, and they'll take a phone
order, and bill you), as well as two 15' Unibus cables (I believe they're
called BC-11A-15's). That seemed to go well, and they promised one-
month delivery for all the boards and cables; however, I got a call back
from them after a week, reporting that one of the boards was going to be
6 months coming. I told them to cancel the order, in that case, and
they got back to me and promised 6 weeks instead. Sure enough, the
boards came.
Then, with a completely vanilla 11/34, ordered from Newman Used (with
an expansion backplane, which is necessary to avoid having to terminate
the Unibus inside the -10), we cabled it up in the obvious way, pulling
+5v from the Unibus backplane to the molex connector associated with
the -10 side of the DTE (this is to keep the Unibus crobar up).
Finally, I made some simple changes to DTESRV to notice a "dead" front-end
ringing the -10's doorbell, allowing a front-end to come up out of the blue.
Coupled with some modifications to the standard MIT Chaosnet/LCSnet/Internet
(and Ethernet) front-end software, this arrangement allows us to have a
totally independent front-end (which is booted and dealt with entirely
through a serial line, and all about as fast as using the DTE as a boot
device).
The Yale folks have adapted this software setup to LSI-11's, so with little
work, assuming you're using the MCB (DECnet) front-end communications
protocol (it would be trivial to make it work with the RSX20F protocol),
you can have a very cheap ($5K for the LSI-11/02 and $3K for the DTE
boards) front-end. (As BBN has already done.) Not only that, but the
-11 runs independently of the -10, and only has to be reloaded when it
crashes. Our network front-end -11 has been up for a month now, and
the -10 has been reloaded many times in that period.
If you want gory details, I'll be putting together yet another "roll
your own (even cheaper) DN20" document which I'll make publicly FTPable.
-------
19-Oct-81 23:18:50-EDT,514;000000000000
Mail-from: SU-SCORE rcvd at 19-Oct-81 2318-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 19-Oct-81 2008-PDT
Date: 19 Oct 1981 1845-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Spooled terminals
To: JOE at WASHINGTON, tops-20 at SU-SCORE
In-Reply-To: Your message of 19-Oct-81 1826-MDT
Our LPTSPL handles async terminals (it's not a separate version; it's
incorporated into the standard lptspl, and does special things if the
device type is a tty). Let me know if you want it.
Randy
-------
20-Oct-81 10:01:31-EDT,636;000000000000
Mail-from: SU-SCORE rcvd at 20-Oct-81 1001-EDT
Mail-from: ARPANET site SANDIA rcvd at 20-Oct-81 0653-PDT
Date: 20 Oct 1981 0747-MDT
From: Norm Samuelson <Samuelson at SANDIA>
Subject: Re: Spooled terminals
To: JOE at WASHINGTON, tops-20 at SU-SCORE
In-Reply-To: Your message of 19-Oct-81 1826-MDT
I have modified LPTSPL to work with EITHER a TTY or a real LPT.
To make it work I simply DEFINE PLPT1: TTY2: and run two LPTSPLs,
then start both printer 0 and printer 1. It is a simple change
in LPTSPL and I will be glad to give it away to anyone who wants
it. It will be in directory DIST: at SANDIA.
- Sam -
-------
20-Oct-81 17:25:05-EDT,1207;000000000000
Mail-from: SU-SCORE rcvd at 20-Oct-81 1725-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 20-Oct-81 1416-PDT
Date: 20 Oct 1981 1512-MDT
From: C-GRISS at UTAH-20
Subject: Re: Spooled terminals
To: JOE at WASHINGTON
cc: Tops-20 at SU-SCORE
In-Reply-To: Your message of 19-Oct-81 1826-MDT
Joe,
I have a hacked LPTSPL which I use to drive a printronix
with a XON/XOFF interface. Its (ala all LPTSPL's) inefficient, but
does the job quite well. There are a few patches to some of the other
components too. There are one/two bugs also. The hacks are different
enough so that the software dispatch bug reports will probably not
apply. In essence I needed to allow it to work from top of form
due to graphics requirements, and thusly needed to add a SKIP command
to the LPFORM.INI, and thereby having to re-organise LPTSPL because
of the way it handled its auto perforation skip. I also needed to add
a .PLT file type which lets the plotting software control tof and
perforation skipping.
At some point, I'm gonna pull out the guts, and replace it with
efficient code. Youd be welcome to the code and mods. If youre interested
send me mail/phone me at (801)581-5256
Cedric
-------
21-Oct-81 01:47:48-EDT,674;000000000000
Mail-from: SU-SCORE rcvd at 21-Oct-81 0147-EDT
Mail-from: ARPANET site SRI-KL rcvd at 20-Oct-81 2147-PDT
Date: 20 Oct 1981 2146-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: v4a?
To: NWM at MIT-XX, tops-20 at SU-SCORE
In-Reply-To: Your message of 20-Oct-81 1921-PDT
I don't know about V4A, but the latest I've heard about R5 is that it's
becoming a disaster: DECnet Phase III is being yanked out, and that was
the only truly new feature of 5, other than bug fixes and extended
addressing (apparently, RP07 support is also being yanked due to problems).
Of course, someone like Judy should straighten us out if we're gossiping
mistakenly.
-------
21-Oct-81 01:51:25-EDT,351;000000000000
Mail-from: SU-SCORE rcvd at 21-Oct-81 0151-EDT
Mail-from: ARPANET site MIT-XX rcvd at 20-Oct-81 2106-PDT
Date: 20 Oct 1981 2221-EDT
From: Nat Mishkin <NWM at MIT-XX>
Subject: v4a?
To: tops-20 at SU-SCORE
I have heard references to TOPS-20 v4A. I thought the next release
was going to be v5. Is my source of information confused?
-------
21-Oct-81 04:38:33-EDT,1665;000000000000
Mail-from: SU-SCORE rcvd at 21-Oct-81 0438-EDT
Date: 21 Oct 1981 0132-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: TOPS-20 4A
To: TOPS-20 at SU-SCORE
It would have been 4.1, since evidentally marketing decided
that minor version numbers should be octal numbers instead of
letters. Anyway, 4.1 got canned a while ago; Peter Hurley said a
few DECUS symposia ago that he didn't want to do 4.1 because it
would have delayed 5 the way 3A delayed 4.
I know that 5 has some significant fixes to the monitor as
well as a lot of neat functionality added to the EXEC; I believe
that DEC intends to make multi-forking available as an option
although the distributed EXEC will still be non-MF. I guess it's
pretty well-known that 5 will have more extended addressing
support; Judy Hall discussed the new functionality in the TOPS-20
Extended Addressing session at the last symposium in Miami. The
monitor enhancements would probably only be of concern to system
wizards.
I can't imagine why RP07 support would be yanked out. The
last I heard, several months ago, was that it was done and worked
just fine. However, I got the strong feeling at Miami that
marketing was being an obstacle on RP07's, perhaps because a lot
of customers who would otherwise buy RP20's would buy RP07's
instead. It's a safe assumption that there won't be an RP07 LIR
for release 4!
I have no comment regarding DECnet Phase III. I'm not going
to spread any rumors on this one!
-- Mark --
-------
22-Oct-81 01:29:51-EDT,2533;000000000000
Mail-from: SU-SCORE rcvd at 22-Oct-81 0129-EDT
Mail-from: ARPANET site RUTGERS rcvd at 21-Oct-81 2218-PDT
Date: 22 Oct 1981 0109-EDT
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: in case anyone is interested
To: admin.mrc at SU-SCORE
Remailed-date: 21 Oct 1981 2224-PDT
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
Some time ago we had to figure out what to do about remote printers that
were done using asynch lines rather than DECnet. We didn't think all
that SET LOCATION stuff could be made to work without DECnet, and so
came up with a kludge using unit numbers. It now turns out that two
simple patches would have allowed us to use the more elegant DECnet node
code. Although it is probably too late for us, I record these for the
benefit of anyone else that may find it useful. Once these are done, a
user merely does
SET LOCATION FOO::
and all of his printouts come out at location FOO::. In OPR,
START PRINTER 0 /NODE:FOO::/DEV:TTY123:
will specify which printer is to be used for FOO::. (Of course you have
to use a version of LPTSPL that knows about terminals, but that would be
the case anyway.)
In QSRNET.MAC
old:
NODE.3: MOVE S1,NETCOL(AP) ;GET THE NODE ID IN S1
MOVE S2,AP ;GET THE ENTRY ADDRESS
MOVE AP,NETSTS(AP) ;GET THE STATUS BITS
TXNE AP,NETONL ;IS IT ONLINE ???
$RETT ;ONLINE !!
$RETF ;OFFLINE !!!
new:
NODE.3: MOVE S1,NETCOL(AP) ;GET THE NODE ID IN S1
MOVE S2,AP ;GET THE ENTRY ADDRESS
MOVX AP,NETNSV+NETONL ;GET VALID STATUS+ONLINE
MOVEM AP,NETSTS(S2) ;SAVE IT
$RETT ;ONLINE !!
This has the effect that merely mentioning a node in OPR causes it to
appear magically online. Normally a node only appears when DECnet
detects it coming on line. We don't require real nodes, only things
that QUASAR thinks are nodes, so this is sufficient.
The only other change needed is to make LPTSPL know that it should treat
nodes using its normal methods, rather than trying to talk to them with
DECnet. In LPTSPL.MAC
old, SETU.2+26:
MOVE S1,SUP.NO(M) ;GET THIS GUYS NODE NAME
CAMN S1,CNTSTA ;IS IT A LOCAL LPT ???
JRST SETU.3 ;YES,,SKIP THIS
new:
JRST SETU.3
or possibly just comment out the code between here an SETU.3
It is my guess that minor modifications of this code could be used at
sites that have real DECnet or IBM remote support, to make remote asych
printers look real the same as real DECnet and IBM nodes.
-------
22-Oct-81 13:08:07-EDT,571;000000000000
Mail-from: SU-SCORE rcvd at 22-Oct-81 1308-EDT
Mail-from: ARPANET site BBNG rcvd at 22-Oct-81 1004-PDT
Date: 22 Oct 1981 1304-EDT
Sender: DIPACE at BBNG
Subject: More on RP07s
From: DIPACE at BBNG
To: tops-20 at SU-SCORE
Message-ID: <[BBNG]22-Oct-81 13:04:41.DIPACE>
We(BBN) will be receiving several RP07s in a few weeks. We are a
field test site for them. The software is in the form of an
"LIR" to release 4. Dec is using them on its marketing demo
machines,but that has only been for three(3) weeks. Mark could
you add my name to your tops20 list ?
22-Oct-81 13:26:00-EDT,378;000000000000
Mail-from: SU-SCORE rcvd at 22-Oct-81 1325-EDT
Date: 22 Oct 1981 1023-PDT
From: Ted Markowitz <G.TJM at SU-SCORE>
Subject: RP07 info
To: tops-20 at SU-SCORE
Does anyone have some detailed specs on the RP07? Speed, storage,
price/bit, etc.? We're looking at getting an RP20 this fiscal year
and I'd like to examine the RP07 as an alternative. Thanks.
--ted
-------
22-Oct-81 13:39:56-EDT,421;000000000000
Mail-from: SU-SCORE rcvd at 22-Oct-81 1339-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 22-Oct-81 1035-PDT
Date: 22 Oct 1981 1131-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: RP07 info
To: G.TJM at SU-SCORE, tops-20 at SU-SCORE
In-Reply-To: Your message of 22-Oct-81 1123-MDT
My understanding of the rp07 pricing is that the current list price is
$38,000, and current rh20 pricing is $19,000.
-------
22-Oct-81 14:26:52-EDT,549;000000000000
Mail-from: SU-SCORE rcvd at 22-Oct-81 1426-EDT
Mail-from: ARPANET site SRI-KL rcvd at 22-Oct-81 1120-PDT
Date: 22 Oct 1981 1118-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: RP07 update; RP20 costs
To: tops-20 at SU-SCORE
I hear from DEC people that the RP07 is definitely in R5, but that DECnet may
be dropped to get R5 out in a timely fashion (mostly for RP07 support).
Randy, I think Ted asked for RP20 pricing vs the RP07; the RP20 is vaguely
$45K, but requires the $100K IBM channel adaptor (still called the DX20?)
-------
22-Oct-81 14:40:48-EDT,520;000000000000
Mail-from: SU-SCORE rcvd at 22-Oct-81 1440-EDT
Mail-from: ARPANET site UTAH-20 rcvd at 22-Oct-81 1135-PDT
Date: 22 Oct 1981 1232-MDT
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: RP07 update; RP20 costs
To: RYLAND at SRI-KL, tops-20 at SU-SCORE
In-Reply-To: Your message of 22-Oct-81 1218-MDT
Chris is right on RP20 pricing, except that the $100K is for both the
IBM channel adapter (DX20) combined with the STC disk controller. Thus
the first drive is $145K, with add on drives costing $45K.
-------
25-Oct-81 21:48:54-EST,2528;000000000000
Mail-from: SU-SCORE rcvd at 25-Oct-81 2148-EST
Mail-from: ARPANET site RUTGERS rcvd at 25-Oct-81 1846-PST
Date: 25 Oct 1981 2139-EST
From: WATROUS at RUTGERS (Don Watrous)
Subject: Early mischief night this morning
To: TOPS-20 at SU-SCORE
If anybody has a batch job which runs at midnight, then submits
itself /AFTER:TODAY to run the next morning at midnight, I'll bet it
ran a good number of times this morning! And if that program submits
another to run right away...it'll look like rabbit time! That was
the situation around here this morning.
The reason? The EXEC, in figuring out times relative to TODAY has to
figure out 0000 (midnight) for today and tomorrow. To do this, it
takes the current date/time adds 24 hours, outputs to string space
the date of that date/time, appends to that "0:0:0" and reads back
the date/time to get tomorrow morning at 0000. It then subtracts 24
hours to get midnight of this morning. Unfortunately, today had 25
hours in it. Therefore, 00nn plus 24 hours becomes 23nn, not quite
making it to tomorrow. Thus, tomorrow becomes today and dates
relative to TODAY are screwed up for that one hour window.
The cure? Convert to real day numbers using ODTNC/IDCNV rather than
hoping the current day has the usual number of hours.
File 1) S:<4-EXEC>EXECSU.MAC.57,25-Oct-81 20:23:48
File 2) S:<4-EXEC>EXECSU.MAC.52,21-Oct-81 02:23:33
1)9 move b,a ;this is really TODAY 0000 now
1) HRROI A,STRNG0 ;WRITE TO SCRATCH
****
2)9 MOVSI B,1
2) ADD B,A ;GET TOMORROW SAME TIME IN A
2) HRROI A,STRNG0 ;WRITE TO SCRATCH
**************
1)9 MOVEM B,TODAY
1) setz d, ;don't supply any bits
1) odcnv ;break into real "days"
1) hlrzs c ;day of month to right half
1) hrlzi c,1(c) ;add one and return to left half
1) txz d,ic%dsa ;don't force daylight savings time
1) idcnv ;get internal date/time of tomorrow 0000
1) erjmp .+2 ;day of month too large
1) jrst gottom ;success
1) setz c, ;ok, make it first day of month
1) addi b,1 ; and bump month
1) idcnv ;try again
1) erjmp .+2 ;month is not less than 12
1) jrst gottom ;success
1) hlrzs b ;year to right half
1) hrlzi b,1(b) ;next try first month of next year
1) idcnv ;last try
1) ercal jerr ;punt
1) gottom: movem b,tomoro ;save tomorrow
1) MOVX A,CM%IDA+CM%ITM
****
2)9 MOVEM B,TOMORO ;REMEMBER VALUE FOR TOMORROW
2) SUB B,[1B17] ;CREATE BEGINNING OF TODAY
2) MOVEM B,TODAY
2) MOVX A,CM%IDA+CM%ITM
**************
-------
2-Nov-81 13:46:07-EST,1393;000000000000
Mail-from: SU-SCORE rcvd at 2-Nov-81 1346-EST
Mail-from: ARPANET site BBND rcvd at 2-Nov-81 1019-PST
Date: 2 Nov 1981 1318-EST
From: EONEIL at BBND
Subject: Archive saveset misnumbering
To: TOPS-20 at SCORE
The saveset misnumbering problem, which has been troubling us and
other sites by causing retrieval failures, turns out to result from
a sorry combination of my original (bad) code and DEC's modification
of it. Obviously, I should never have put SOS TAPNO in ARCINI--
the culprit, but rather should have set TNSF, the tape-no-set flag,
to compensate for the later AOS TAPNO done in DNEWV. All you have
to do to fix the problem is remove the SOS TAPNO and add TXO F,TNSF
at ARINI1.
In case you're curious how this could corrupt the saveset number,
note that it resides in the LH of TAPNO. A leftover set TNSF first
causes a SOS TAPNO without the AOS happening in DNEWV, leaving the RH
of TAPNO decremented, say from 1 to 0. Then the next saveset written
(with TNSF off) has SOS TAPNO, set LH of TAPNO, then AOS TAPNO in
DNEWV--the AOS causes overflow from the RH into the LH, leaving the
LH off by one. A sneaky bug, showing up at the earliest in the
third saveset written.
Tapes already written with bad saveset numbers can be read with
the help of a workaround reported by Watrous at Rutgers to this
mailing list on 23-Apr-81.
--Betty
-------
5-Nov-81 15:36:03-EST,556;000000000000
Mail-from: SU-SCORE rcvd at 5-Nov-81 1535-EST
Mail-from: ARPANET site MIT-XX rcvd at 5-Nov-81 1209-PST
Date: 5 Nov 1981 1519-EST
From: Steve Berlin <BERLIN at MIT-XX>
Subject: An apparent bug in DTESRV
To: tops-20 at SU-SCORE
It look to me as though the RETSKP at DTEQ12 + 9 should be a RET, indicating
that the packet is not getting queued. I don't know what ramifications this
might have, but we have been having periodic problems when front-end devices
crash, including buffers that don't get released properly.
-- Steve
-------
7-Nov-81 07:43:43-EST,3117;000000000000
Mail-from: SU-SCORE rcvd at 7-Nov-81 0743-EST
Date: 7 Nov 1981 0437-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: microcode bug in ADJBP?
To: TOPS-20 at SU-SCORE, REG at SU-AI, Moon at MIT-MC
I recently tried to write an ADJBP emulator, and in
debugging it I noticed an inconsistancy between my emulator and
the KL's implementation of ADJBP when fed a pathological byte
pointer. I don't think my emulator does the right thing, but
certainly what the KL is doing is totally random! I think it
should set Trap 1, Overflow, and No Divide, since there is no way
that that my sample byte point could specify a valid byte.
I left my emulator's code the way it was, since the KL
returned gubbish too and at least my emulator's gubbish made some
sense (e.g. the results are always normalized, word alignment is
preserved, and it bears some resemblance to what IBP does). I
did write a supposed fix (under the REPEAT 0 in the code example
below), which I think correctly implements the defined ISP.
Is this a for-real microcode bug? Comments, anybody?
With a byte pointer of 454400,,20,
An adjustment count of Returns
0 454400,,20
1 14400,,20
2 454400,,21
3 14400,,21
4 454400,,22
My ADJBP emulator returns:
0 14400,,17
1 14400,,20
2 14400,,21
3 14400,,22
4 14400,,23
The code for the emulator follows:
%ADJBP: HRRZ T,.JBUUO ;Get EA of ADJBP
CAIGE T,20 ;An AC?
SKIPA T,UUOACS(T) ;Yes, get from saved AC's
MOVE T,(T) ;Else get from memory
LDB U,[POINT 4,.JBUUO,12] ;U := AC argument
LDB V,[POINT 6,T,11] ;V := S field of byte pointer
LDB W,[POINT 6,T,5] ;W := P Field of byte pointer
REPEAT 0,<
; The following code normalizes byte pointers whose P field is larger than
;36. The case of P=36 is deliberately not normalized here, since it is a
;special case and is not equivalent to P=0.
CAIG W,^D36 ;Pointer need normalizing?
JRST %ADJB0 ;No
SUBI W,^D36 ;Yes, do so
SUBI T,1 ;Normalize address as well
%ADJB0:
>;REPEAT 0
JUMPE V,[MOVEM T,UUOACS(U) ;If S=0, ADJBP copies C(E) to AC
RET]
MOVEI A,^D36 ;Compute bytes/word using formula:
SUBI A,(W) ; ((36 - P) / S) + (P / S)
IDIVI A,(V)
MOVEI B,(W)
IDIVI B,(V)
ADDI A,(B) ;A := bytes/word
JUMPE A,CPOPJ ;Should set Trap 1, Overflow, No Divide
MOVE B,UUOACS(U) ;B := adjustment argument
IDIV B,A ;Divided by bytes/word
ADD T,B ;Quotient is added to BP's EA
IMULI C,(V) ;Number of bits to adjust
SUB W,C ;Adjust P field by specified # of bits
IMULI A,(V) ;A := bits used/word
JUMPL W,[ADD W,A ;Moved up a word, add a word of bits
AOJA T,%ADJB1] ;Move up a word and continue
CAIGE W,^D35 ;Moved back a word?
JRST %ADJB1 ;No, adjustment within a word
SUB W,A ;Subtract a word of bits
SUBI T,1 ;Move back a word
%ADJB1: DPB W,[POINT 6,T,5] ;Set P field in byte pointer
MOVEM T,UUOACS(U) ;Set byte pointer
RET ;And done
-------
7-Nov-81 16:31:23-EST,518;000000000000
Mail-from: SU-SCORE rcvd at 7-Nov-81 1631-EST
Mail-from: ARPANET site RUTGERS rcvd at 7-Nov-81 1321-PST
Date: 7 Nov 1981 1611-EST
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: Re: microcode bug in ADJBP?
To: Admin.MRC at SU-SCORE
cc: TOPS-20 at SU-SCORE, REG at SU-AI, Moon at MIT-MC
In-Reply-To: Your message of 7-Nov-81 0737-EST
Does your emulator properly emulate the randomness that pops up
now and then when using ADJBP in with extended (two-word) byte
pointers?
-------
10-Nov-81 14:48:44-EST,664;000000000000
Mail-from: SU-SCORE rcvd at 10-Nov-81 1448-EST
Mail-from: ARPANET site USC-ISIB rcvd at 10-Nov-81 1144-PST
Date: 10 Nov 1981 1142-PST
Sender: JGOLDBERGER at USC-ISIB
Subject: PA2050 (2040?)
From: Joel Goldberger
Reply-To: JGOLDBERGER at USC-ISIB
To: Tops-20 at SU-SCORE
Message-ID: <[USC-ISIB]10-Nov-81 11:42:49.JGOLDBERGER>
Who all has TENEX/TOPS-20 compatibility packages and what are
the features (misfeatures) of each. We have one here at ISI that
is quite old, though functional that includes COMND/RDTTY/TEXTI/
TBLUK/TBADD/TBDEL and ADJBP. Before we try to regenerate one
with the latest COMND module I thought to query the field.
Joel
11-Nov-81 11:07:39-EST,483;000000000000
Mail-from: SU-SCORE rcvd at 11-Nov-81 1107-EST
Mail-from: ARPANET site CMU-20C rcvd at 11-Nov-81 0805-PST
Date: 11 Nov 1981 1102-EST
From: WOHL at CMU-20C
Subject: Tops-20 on KL with external channels?
To: tops-20 at SU-SCORE
We have this old KL here (CMUA). The processor itself has been upgraded
so it should be able to run the current microcode. It does have external
channels however. Does anybody have experience running TOPS-20 on such
a beast?
Aaron
-------
11-Nov-81 11:49:09-EST,476;000000000000
Mail-from: SU-SCORE rcvd at 11-Nov-81 1149-EST
Mail-from: ARPANET site UTAH-20 rcvd at 11-Nov-81 0847-PST
Date: 11 Nov 1981 0941-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Tops-20 on KL with external channels?
To: WOHL at CMU-20C, tops-20 at SU-SCORE
In-Reply-To: Your message of 11-Nov-81 0902-MST
I think that the KL at SRI has (or used to have) both external memory
and external channels running tops-20. You might check with someone there.
-------
13-Nov-81 15:42:41-EST,746;000000000001
Mail-from: SU-SCORE rcvd at 13-Nov-81 1542-EST
Mail-from: ARPANET site RUTGERS rcvd at 13-Nov-81 1238-PST
Date: 13 Nov 1981 1537-EST
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: DNxx and system crashing
To: tops-20 at SU-SCORE
We're finishing installation of an "erector set" DN20. I have a few
questions about what I should expect from it.
1) Does anyone have any diagnostics for a DTE connected to an 11 that
the 20 can't reboot?
2) Should the 11 be able to do a bus init (ie reboot...) and/or be powered
up and down without effecting the 20?
3) Has anyone used the DTESRV routines to talk to a non-RSX20F, non-DN87
protocol FE?
Any ideas, comments, hints, or whatever will be appreciated. Thanks.
Roy
-------
13-Nov-81 17:44:10-EST,1656;000000000000
Mail-from: SU-SCORE rcvd at 13-Nov-81 1744-EST
Mail-from: ARPANET site UTAH-20 rcvd at 13-Nov-81 1434-PST
Date: 13 Nov 1981 1528-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: DNxx and system crashing
To: MARANTZ at RUTGERS, tops-20 at SU-SCORE
In-Reply-To: Your message of 13-Nov-81 1337-MST
1) it is possible to load 11 diagnostics either through the DTE, or
through the async line connecting the primary front-end DLn: to the
DN20 console. The stuff to do all of this is on the KLAD pack.
2) you can do almost anything to the 11 (power, init, kick, curse at...)
without effecting the 20. Even when active, you can screw up DTE
protocol from the 11 end with infinite variation without bothering
the KL; the worst that the KL will do is declare the dn20 dead. It's
incredibly robust - one of the more impressive parts of the interface.
In the course of debugging our front-end code, we have managed to
screw up protocol in more ways than can be imagined, and it has
NEVER caused the KL to crash, although we have gotten virtually
every BUGCHK DN20xx in the book.
3) Our software currently uses 20F protocol. We have found some bugs
in DTESRV, but they only appear if you have TTYSRV modified to put
tty lines on secondary front-ends.
With respect to 1), if your favorite field service tech can't help you
load diags from over the async line, I can look up how to do it. Haven't
done it in ages, so I don't remember off the top of my head. Of course,
you can also use DNLOAD with the DLOAD command to load diagnostics,
assuming you can talk thru the DTE.
Randy
-------
16-Nov-81 17:06:46-EST,830;000000000001
Mail-from: SU-SCORE rcvd at 16-Nov-81 1706-EST
Mail-from: ARPANET site UTEXAS-20 rcvd at 16-Nov-81 0637-PST
Date: 16 Nov 1981 0836-CST
From: CC.LOOMIS at UTEXAS-20
Subject: RSX-20F crashes
To: Admin.MRC at SU-SCORE
Remailed-date: 16 Nov 1981 1359-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
Our RSX-20F front-end has been crashing two or three times a day with
T04's or buffer overruns (B02/BO3). The trap-4s appear to be caused
by trashed linked lists or registers when -20F attempts to schedule
a task, i.e. linked list insertion. Routine .D.QIO seems to be the
culprit or is always closely involved. The buffer overruns usually
occur after send-all's, although we haven't verified that that is
the exact cause. Has anyone seen/fixed similar problems?
-------
17-Nov-81 13:09:29-EST,558;000000000000
Mail-from: SU-SCORE rcvd at 17-Nov-81 1309-EST
Mail-from: ARPANET site SRI-KL rcvd at 16-Nov-81 1654-PST
Date: 16 Nov 1981 1506-PST
From: Richard R. Cower <COWER at SRI-KL>
Subject: Recent UNIX article
To: Admin.mrc at SU-SCORE
Remailed-date: 17 Nov 1981 0955-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: tops-20 at SU-SCORE
Mark,
I think the folks on the 20 mailing list might like to see:
NOV. 81 DATAMATION The Trouble with UNIX by Donald A. Norman
ps...it is not pro-UNIX.
.thanks...Rich Cower
-------
18-Nov-81 12:55:34-EST,1696;000000000000
Mail-from: SU-SCORE rcvd at 18-Nov-81 1255-EST
Mail-from: ARPANET site UTAH-20 rcvd at 17-Nov-81 2216-PST
Date: 17 Nov 1981 2308-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: disk damage - explanation?
To: tops-20 at SU-SCORE
cc: LEPREAU at UTAH-20
We just experienced some logical damage to files on PS: which I am wont to
provide a reasonable explanation.
To the best that we can tell, some hardware went crazy this afternoon
(disk drive or RH20).
The net effect (to the best that we can tell) is the several files had
a few bits changed. However, what's difficult to understand is:
1) there appears to be no damage to the file sys database (checkd
check bittable reports no problems, no lost pages)
2) the files that we have found damaged are all files that were opened
read/execute (not write), e.g., system:exec, sys:emacs, etc.
They all had the bit 20,,000000 turned on on the first word of a
page.
My problem in figuring out a logical explanation is the following:
1) if the drive or RH were really just spraying bits over the disk in
ramdom places (a theory I don't believe), one would expect some
index blocks or directories to have been damaged.
2) if the problem occurred during writing a block to disk (a more likely
explanation), why should system:exec have been re-written. It has
always been my understanding that DDMP only writes pages from
swapping space back to disk if they have been written. Am I wrong?
Is there any way that a file that is open read/execute can have pages
written from swapping space back to the disk?
Any illuminating theories would be welcome. I'm stumped.
-------
18-Nov-81 13:00:03-EST,680;000000000000
Mail-from: SU-SCORE rcvd at 18-Nov-81 1259-EST
Mail-from: ARPANET site SU-SCORE rcvd at 18-Nov-81 0724-PST
Date: 18 Nov 1981 0723-PST
From: Ted Markowitz <G.TJM at SU-SCORE>
Subject: Re: disk damage - explanation?
To: FRANK at UTAH-20, tops-20 at SU-SCORE
cc: LEPREAU at UTAH-20
In-Reply-To: Your message of 17-Nov-81 2208-PST
DDMP does only write back changed pages. Are you sure that the reason
could only be hardware? I can't quite see the mechanism but, can you
completely discount some piece of software from being the culprit? ---
perhaps archiving, DUMPER, etc., that would in it's normal course of
operation munge around the file system.
--ted
-------
18-Nov-81 13:01:10-EST,516;000000000000
Mail-from: SU-SCORE rcvd at 18-Nov-81 1301-EST
Mail-from: ARPANET site AFSC-HQ rcvd at 18-Nov-81 0827-PST
Date: 18 Nov 1981 1125-EST
From: Chuck Perilli <PERILLI at AFSC-HQ>
Address: HQ AFSC/ACDPS, Andrews AFB, DC 20334
Phone: (301)981-4002; AUTOVON: 858-4002
Subject: CROSS
To: TOPS-20 at SU-SCORE
We are having a few problems trying to use the CROSS assembler (for
8080 code) and would appreciate hearing from anyone willing to answer
a number of questions we have. Thanks.
---Chuck
-------
18-Nov-81 23:22:36-EST,16282;000000000000
Mail-from: SU-SCORE rcvd at 18-Nov-81 2322-EST
Mail-from: ARPANET site RUTGERS rcvd at 18-Nov-81 2010-PST
Date: 18 Nov 1981 1535-EST
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: how to do a refresh
To: tops-20 at SU-SCORE
Every time we do a refresh, it is a crisis. The instructions in the
operator's manual are laughably incomplete. Each time we think we have
remembered everything, we find something more. Since many of the rest
of you may be in a similar situation, I thought you might find it
helpful to see our current list of instructions. Note that some of these
are site-dependent. For example, we have two drives that are connected
to the front end. We also have one more drive than the number of packs
in PS:. This allows us to bring up a backup (one-pack) system on the
extra drive (which we call S:) and mount PS: as a mountable pack. This
allows much more flexibility than trying to do everything running from
PS:. Some of the following instructions would not work if you had to run
from the system you were saving or restoring. If you are interested in
a more complete list of our procedures, you can look at <hedrick>opr.doc.
However things change around here so fast that almost anything in there
could be out of date.
=======================================================
5.9 Doing a refresh
Refreshes are done most often when something is wrong with the file
system. That is why this section is in the chapter on problems.
However refreshes are also done about once a year as preventive
maintenance. A refresh will cause all files to be stored
contiguously. This speeds up file access. It will also often get
more disk space.
Aside from the regular preventive maintenance, refreshes are done for
two kinds of reasons:
- There has been hardware trouble. This resulted in damage to
the file system, i.e. BUGxxx's of the DIRxxx sort, or
messages from CHECKD. The refresh will cure these problems.
However it will not cure the hardware problem that caused
them. You should make sure that the hardware is solid
before doing a refresh. If you don't, you will be in big
trouble.
- You are having swapping crashes, i.e. crashes beginning with
SWP (e.g. SWPUPT). If DEC believes that the problems is a
bad disk pack, they may ask for a refresh. The refresh will
cure this because you will end up putting the data onto a
new (presumably undamaged) disk pack. You should be fairly
sure that it is in fact the fault of the disk pack itself
before doing such a refresh.
A refresh consists of two steps: writing all files onto tape, and
reading them back onto fresh disk packs. When possible, you should
bring down the system and dump the disks onto tape. If you can do
this, you will have all files up to date. If the system is in such
bad shape that you can't do this, you will have to use the most recent
full dump of the system. In that case, you will lose all files that
have not been dumped. When dumping the system to tape, we normally
boot the system from S:, and mount PS: as a mountable structure. Here
is how to do that.
In the following instructions, if you try to do MOUNT X:/STR:PS: and
it doesn't work, try killing and restarting MOUNTR:
^ESPEAK
KILL MOUNTR
RUN SYS:MOUNTR
^Z
Here is how to save the system on tape. You should do this if you
can, i.e. if PS: is still readable.
- You must kill RFTP on the other system. Since we are going
to bring up S: calling it PS:, file transfers and mail could
end up going the wrong place. Do this on the other system:
^ESPEAK 1
KILL EXPORT
KILL IMPORT
KILL RMAILR
^Z
- Stop the system: ^ECEASE, ^\, SHUT
- Turn off PS:. PS: must be turned off in order to boot from
S:. If PS: is turned on, the system will always use it.
- Make sure S: is mounted on a drive that has access to the
PDP-11 front end (drives 0 or 1). Move the plugs so it is
called drive 0.
- Now do ENABLE/DISK. It will say UNIT NOT FOUND, and prompt
you with BOOT>. At this point type S:. this is telling it
to take the monitor from S: instead of PS: as usual.
- It will now say it can't find PS, and ask you what disk to
use. Say S: (in upper case).
- The system will now come up.
- Now turn on PS: and mount it.
- Make sure you are logged in as OPERATOR, since passwords
will not be put on the tape otherwise. Being a wheel is not
sufficient.
- ENABLE
- Say MOUNT STRUCT X:/STR:PS: This will mount PS:, but call
it X:.
- Use REV to set <ACCOUNTS>SYSTEM-DATA.BIN.0 so you can save
it. Normally a bit is turned on which will prevent DUMPER
from dumping this file. If you forget this, all accounting
data from the current month will be lost. Say REV
<ACCOUNTS>SYSTEM-DATA.BIN.0. Rev will show you that file.
Now type SET SAVED and then two carriage returns.
- Now save the system as you would for a weekly backup.
However of course you have to say SAVE X:<*>*.*.*, since PS:
is now called X:. Don't forget to say X:.
- Create a list of directory parameters. This is not strictly
necessary, since this is a part of the DUMPER tape, but it
proves to be useful for certain error recovery situations.
DLUSER
DLUSER>STRUCTURE X:
DLUSER>DUMP filename
where filename is a file on PS: (since it won't do you any
good to put the listing on the structure you are about to
recreate!).
- Now you are going to have to create a list of files that are
marked so that they are not saved by a normal DUMPER. These
are files which because of contractual commitments to
vendors we do not allow to show up on normal backup tapes.
Shortly, we will have an option in DUMPER to do this
automatically. At the moment you will have to produce a
list of these files, and then either change the bit by hand
using REV or produce a control file to do it automatically.
PHOTO
Log file: NOSAVE.LOG
EXEC <OPERATOR>NOSAVE.MAC
Files to check: X:<*>*.*.*
;; will output a list of these files
POP
;; you now have a list of them in NOSAVE.LOG
You should now edit NOSAVE.LOG and turn the list into a set
of REV commands that do SET SAVED for each one. However you
must omit the following files.
<JUNK> - all files - simply saves time
<ROOT-DIRECTORY> - all files - attempting to restore them
could cause real trouble
<SYSTEM>DUMP.EXE - this file must be recreated specially
Once you have set the files to allow them to be saved, you
then dump them with DUMPER. Since there are usually a
limited number of directories involved, we usually just save
the whole directory for each directory having such a file.
e.g. SAVE X:<VLSI>,X:<DPL>,X:<VLSI.FOO>...
Once you have the tapes written, DEC may want to look at the drives
and verify that they are properly aligned.
Here is how to refresh PS: from tape. We hope that you were able to
save PS: on tape using the procedure above. However if PS: was not
readable, you will have to use the regular backup tapes. In that case
you will start here. If you have already booted the system from S:,
do not stop and restart the system.
- You must kill RFTP on the other system. Since we are going
to bring up S: calling it PS:, file transfers and mail could
end up going the wrong place. Do this on the other system:
^ESPEAK 1
KILL EXPORT
KILL IMPORT
KILL RMAILR
^Z
- Stop the system: ^ECEASE, ^\, SHUT
- Turn off PS:. PS: must be turned off in order to boot from
S:. If PS: is turned on, the system will always use it.
- Make sure S: is mounted on a drive that has access to the
PDP-11 front end (drives 0 or 1). Move the plugs so it is
called drive 0.
- Now do ENABLE/DISK. It will say UNIT NOT FOUND, and prompt
you with BOOT>. At this point type S:. this is telling it
to take the monitor from S: instead of PS: as usual.
- It will now say it can't find PS, and ask you what disk to
use. Say S: (in upper case).
- The system will now come up.
- ****START HERE IF YOU HAVE ALREADY RELOADED THE SYSTEM FROM
S:. However if you skip the steps above, please verify that
you have killed EXPORT, IMPORT, and RMAILR.
- Make sure you are logged in as OPERATOR.
- ENABLE
- Now you must generate a new PS:. Do not use the same disk
packs that PS: was on before. Use new packs, or packs from
a previous copy of PS:. Put these packs on the drives and
turn them on, but do not do a MOUNT command. Make sure that
the pack that will be called "PS: volume 0" is on a drive
connected to the PDP-11. Move the plugs to make this drive
1.
- Run CHECKD. Say CREATE PS: to it. It will then ask you
some questions:
- How many packs in the structure: This is currently 3
- Name the drives: Type ? for list of drives. Usually S:
will be on one drive, and you want all the rest of them.
You need to type channel, unit. The output from ? will show
you what these are.
- How much swap space: The system manager must tell you how
much this is. Currently type 15105.
- How much front end space: Hit carriage return.
- CHECKD has now created a new structure. It is now ready for
mounting. MOUNT STR X:/STR:PS:
- If you have problems with CHECKD, make sure that none of the
drives are associated with structures that the system thinks
are mounted. It is safest if you bring the system up with
the drives spun down, and then spin them up with the new
packs on them. There is an alternate procedure for creating
a structure that is sometimes useful in odd situations. It
involves starting the monitor at a special start address.
Consult a system programmer before doing this.
- Make sure that account validation is disabled.
SDDT
1/ junk .SFAVR
2/ junk 0
SMON$X ;the $ represents an escape
^Z
- Run DUMPER. Say
TAPE tapename:
CREATE
ACCOUNT TAPE
SUPERCEDE ALWAYS
RESTORE X:<*>*.*.* X:<*>*.*.*
You cannot default the output specification in RESTORE,
since it defaults to the wrong thing. These commands should
be used for DUMPER even if you follow the instructions in
the operator's guide. If you had to use an existing backup
tape, you will probably have to say RESTORE PS:<*>*.*.*
X:<*>*.*.*. Or you can try DEF PS: X:. before running
DUMPER. While dumper is running, you should get messages
"Creating directory X:<name>" and "Loading files into
X:<name>". If not, something may be wrong.
- DUMPER will leave some files deleted, for reasons that are
hard to explain. Now do UNDELETE X:<*>*.*.*.
- Now look at SYS:MAILBOX.TEXT. This includes a list of all
users whose mail is to be forwarded. You must delete their
mailboxes. To delete a mailbox, say REV MAIL.TXT.1 then SET
NOT PERM and two crlf's. Then EDELETE MAIL.TXT.1. At some
point a program will be created to do this for you.
- Use REV to set <ACCOUNTS>SYSTEM-DATA.BIN.0 to its normal
state. If you are restoring from a normal backup rather
than doing a full refresh, this file will not be present, so
you can skip this step. Normally a bit is turned on which
will prevent DUMPER from dumping this file. If you forget
this, you will get an error message every time you try to do
a full backup. Say REV <ACCOUNTS>SYSTEM-DATA.BIN.0. Rev
will show you that file. Now type SET NOT SAVED and then
two carriage returns.
- Restore files from the special tape of files that are
normally not saved. Use the same procedure as for the
initial restoration. Once you have restored them, you must
set them to be NOT SAVED. This is the exact inverse of the
procedure you used to set them SAVED before dumping them.
That is, you use the file created by NOSAVE.MAC, editing it
so that REV does SET NOT SAVED for each one. If you are
restoring from a normal backup rather than doing a full
refresh, you will have to find the special tape left over
from the most recent refresh, or load them from some other
source. You should still make sure that they are SET NOT
SAVED.
- Create <SYSTEM>DUMP.EXE. This must be done by the special
program MAKDMP, since a pointer to this file must be put
into the home blocks:
MAKDMP
Max size of dump file in K (512): 1024 (for red)
1280 (for green)
- Create files in <JUNK>. We should leave about 4000 free
pages on X:. If there are more,
CONN X:<JUNK>
EXEC JUNK.PAS
JUNK>1000
JUNK>1000
...
JUNK>^C
- Stop the system: ^ECEASE ^\ SHUT
- Copy the front end system from S:. Instructions for this
are in the software installation guide, except that you are
copying from one disk to another instead of from floppies.
Bascially you run PIP and copy from DB0: to DB1:. (DB0: is
the S: front end and DB1: is the PS: front end.) The
software installation guide is currently in the red
notebooks, volume 14, chapter 4.
- Now move PS: to the desired drives. Volume 0 must be on a
drive connected to the PDP-11 front end, and the plugs must
be moved so it is unit 0.
- Do ENABLE/DISK and come up as usual. However answer Yes to
CHECKD? CHECKD will rebuild symbol tables for most
directories. If it finds any other problems, you are in
trouble. Probably you have hardware problems.
- Restart RFTP on the other system:
^ESPEAK 1
RUN EXPORT
RUN IMPORT
RUN RMAILR
^Z
If you lose the file system so completely that you can't dump it to
tape, then you will have to do a refresh from the most recent normal
system saves. Follow the above instructions, using the most recent
full copy of PS: and then the most recent incremental. The
instructions indicate the steps that must be changed if you are
working from a backup instead of doing a full refresh.
If you can't use S:, you will have to boot using the most recent
system disaster tape and the front end floppies. See the operator's
guide and the software installation manual. Aside from the fact that
you can't use any software on S:, the procedures are similar to those
shown above. We recommend avoiding this if at all possible. We
should have three complete systems: red, green, and S:. If S: is
usable, you can follow the procedures above. If either red or green
is usable, you can restore S: from tape.
Note that SYSTEM-DATA.BIN will not appear on the normal system saves.
This means that you will lose billing information from the first of
the month to the time of the refresh. There is a backup billing
system, whose data may possibly allow you to do some billing. See the
explanation of accounting.
-------
19-Nov-81 17:00:59-EST,1174;000000000000
Mail-from: SU-SCORE rcvd at 19-Nov-81 1700-EST
Mail-from: ARPANET site DEC-MARLBORO rcvd at 19-Nov-81 1353-PST
Date: 19 Nov 1981 1305-EST
From: Kevin Paetzold <PAETZOLD at DEC-MARLBORO>
To: TOPS-20 at SU-SCORE
Reply-to: Paetzold at DEC-MARLBORO
DTN: 231-7430
Mail-stop: MR1-2/L10
Telephone: 617-467-7430
Subject: A NOTE ON REFRESH'S
Message-ID: <MS"5(1631)"11777541041.17.126.6867 at DEC-MARLBORO>
QUITE OFTEN AFTER A REFRESH YO MAY NOTICE A DECREASE IN PERFORMANCE
WITH VERY DISK INTENSIVE APPLICATIONS. ONE OF THE FEATURES OF A
REFRESH IS THAT MOST OF THE PAGES NEAR THE MIDDLE OFF THE DISK GET
USED UP. MOST SYSTEMS HAVE A SET OF QUITE SMALL FILES THAT GET READ,
WRITTEN AND REWRITTEN A LOT. (EG. TMP FILES ETC...) WTHESE SMALL
SHORT LIVED FILES WILL BE FORCED TO LIVE ON THE OUTER AREAS OF
THE DISK (STATISTCALLY) AND IT WILL NORMALLY TAKE LONGER
STATISTICALLY TO GET AT THEM.
ONE WAY AROUND THIS IS TO CREATE A VERY LARGE FILE (10000 OR 20000)
PAGES) ON THE STRUCTURE BEFORE RESTORING THE STRUCTURE. AFTER THE
RESTORE IS COMPLEETED THEN THE HUGE FILE IS DELETED, FREEING UP
LOTS OF SPACE IN THE MIDDLE OF THE DISK.
--------
20-Nov-81 14:44:37-EST,596;000000000001
Mail-from: SU-SCORE rcvd at 20-Nov-81 1444-EST
Mail-from: ARPANET site SRI-KL rcvd at 20-Nov-81 1135-PST
Date: 20 Nov 1981 1001-PST
From: Chris Ryland <RYLAND at SRI-KL>
Subject: RSX20F on-line debugging
To: tops-20 at SU-SCORE
Did anyone ever get FEDDT to work on a live, snarling RSX20F? I've
seen lines go softwarily dead on the FE and would like to poke them
back to life without figuring out octal addresses, etc. Using FEDDT
with the $$O (open -11 memory via an FE device) always seemed to crash
it (or other, secondary FEs). I suppose one of us should fix this...
-------
20-Nov-81 16:23:31-EST,000001271;000000000001
Date: 20 Nov 1981 1623-EST
From: HEDRICK
Subject: [J. Q. Johnson <Admin.JQJ at SU-SCORE>: Re: Patch for shared disks]
To: tops-20
Mail-from: SU-SCORE rcvd at 20-Nov-81 1511-EST
Date: 20 Nov 1981 1209-PST
From: J. Q. Johnson <Admin.JQJ at SU-SCORE>
Subject: Re: Patch for shared disks
To: HALL at DEC-MARLBORO
cc: hedrick at RUTGERS
In-Reply-To: Your message of 20-Nov-81 1125-PST
Thanks for the write-register patch. It turns out that this was probably
NOT our problem with shared disks, since after installing our patch we
still got j0nruns. We have currently given up and gone to a workaround by
switching the shared disk to a less frequently used structure; the drop in
"legitimate" disk accesses corresponded to a dramatic decrease in j0nruns.
Note that we swapped packs, not drives, so if there's a dcl problem we'd
still be seeing it.
Anyway, I'll install Tony's version of the patch, complete with counter,
and give you a report (remind me in a week or so) on its effectiveness. I
never did any analysis of this problem myself, but only relied on Kashtan's
observations, coupled with Len Bosack's belief that this might be a likely
type of normally unnoticed hardware failure.
-------
---------------
========
20-Nov-81 16:34:34-EST,00000001665;000000000000
Date: 20 Nov 1981 1634-EST
From: HEDRICK
Subject: [HALL at DEC-MARLBORO: Patch for shared disks]
To: TOPS-20
Mail-from: DEC-MARLBORO rcvd at 20-Nov-81 1426-EST
Date: 20 Nov 1981 1425-EST
From: HALL at DEC-MARLBORO
To: admin.mrc at SU-SCORE, Admin.jqj at SU-SCORE
cc: hedrick at RUTGERS, hall at DEC-MARLBORO
Subject: Patch for shared disks
Message-ID: <MS"5(1631)"11777817863.40.456.17191 at DEC-MARLBORO>
Hi, guys. Chuck Hedrick and I are having a mail exchange about his shared
disks. He forwarded a patch that you had given him, in which you write the
control register in order to grab a port. I asked Tony Wachs to look at the
patch, and he gave me some information. He's going to continue looking into
this, but meanwhile he wants you to install a patch to gather some data.
OK with you?
TOPS-10 does, it turns out, write a register in this case, although Tony
says he had no real reason to choose that. But he isn't crazy about your
choice of register. He picked the serial number register because it's not
really writable. And he's not convinced that all this is necessary.
So he proposes the following:
At RP4ATU+3 change JRST ATNXIT to JRST FFF
FFF/ AOSA .+1
COUNT: 0
JRST ATNXIT
and at RP4CN2+1 replace the CALL WTREG with a JFCL.
He says a positive COUNT will indicate that your hardware is doing what
he expects it to do.
Got that?
By the way, I never got a single comment about the extended addressing
patches that I sent to you for distribution. Does that mean they work,
they don't work, or no one tried them?
Who's going to DECUS?
--------
---------------
========
20-Nov-81 21:42:32-EST,674;000000000001
Mail-from: SU-SCORE rcvd at 20-Nov-81 2142-EST
Mail-from: ARPANET site UTEXAS-20 rcvd at 20-Nov-81 1837-PST
Date: 20 Nov 1981 2030-CST
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: FE Hacking
To: tops-20 at SU-SCORE
What is the best way that one can learn RSX20F (masochistic, I know),
and the details of FE hacking?
Is this taught in any DEC classes ?
Is the 'RSX20F System Reference Manual' the only documentation?
Is "hands-on" experience the only way?
I would really appreciate any advice people can give on the best
way to become a FE hacker. Unfortunately, we are embarking on
this dastardly journey.
Thanks, Ed
-------
23-Nov-81 10:32:11-EST,1044;000000000010
Mail-from: SU-SCORE rcvd at 23-Nov-81 1032-EST
Mail-from: ARPANET site BBND rcvd at 23-Nov-81 0722-PST
Date: 23 Nov 1981 1024-EST
From: EONEIL at BBND
Subject: re: How to do a refresh
To: tops-20 at SU-SCORE
I was horrified to see DUMPER's SUPERCEDE ALWAYS in this authoritative
document. It was the cause of our worse restore ever. It forces
files from tape to disk regardless of write dates, etc., changing
generation numbers as necessary to do it. For example, a busy
MAIL.TXT gets written to each incremental, and all these copies
come back. I had to clean up multiple copies for 700 mailboxes
on the system before we could bring up the system (mail would
have been delivered to the wrong copy), and then we had to
restore most important directories over again. The massive
duplication meant we ran out of disk space and had to delete
many directories: SUPERCEDE ALWAYS + INCREMENTALS =>DISASTER!
We had already installed a SUPERCEDE UNLESS option
which attempts to do a better job than SUPERCEDE OLDER, the
23-Nov-81 12:07:05-EST,895;000000000000
Mail-from: SU-SCORE rcvd at 23-Nov-81 1206-EST
Mail-from: ARPANET site RUTGERS rcvd at 23-Nov-81 0903-PST
Date: 23 Nov 1981 1143-EST
From: WATROUS at RUTGERS (Don Watrous)
Subject: re: How to do a refresh
To: EONEIL at BBND, tops-20 at SU-SCORE
In-Reply-To: Your message of 23-Nov-81 1024-EST
If you specify RESTORE X:<*>*.*.* X:<*>*.*.*, you won't get duplicate
copies of MAIL.TXT and the like. (DUMPER's default output in this
case is <*>*.*.-1, which \will/ change generation numbers and create
duplicate copies of files which have been updated using the same
generation number.) Still in this case, files which were on the disk
at the time of the full dump, but not at the time of the incremental
will reappear. (We're trying to figure a way around this now, by
somehow keeping a list of files which either did or did not exist at
the time of the imcremental.)
-------
23-Nov-81 17:10:21-EST,1116;000000000000
Mail-from: SU-SCORE rcvd at 23-Nov-81 1710-EST
Mail-from: ARPANET site RUTGERS rcvd at 23-Nov-81 1400-PST
Date: 23 Nov 1981 1337-EST
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: re: How to do a refresh
To: EONEIL at BBND
cc: tops-20 at SU-SCORE
In-Reply-To: Your message of 23-Nov-81 1024-EST
No, the idea is
supercede always
restore <*>*.*.* <*>*.*.*
This forces the same generation numbers to be used on the output
as the input. Without the explicit output spec, it default to
restore <*>*.*.* <*>*.*.-1, which gave the problem you observed.
I typically update files in place, i.e. without bumping the
generation number. It sounds like in your system I would not
get the new version from the incremental. Is that true?
-------
NET-MAIL-FROM-HOST:SRI-NIC
SU-SCORE
g.bets
Mail-from: ARPANET site SRI-NIC rcvd at 23-Nov-81 1400-PST
Date: 23 Nov 1981 1128-PST
From: Francine Perillo <PERILLO at SRI-NIC>
Subject: Last Thursday night
To: g.bets at SU-SCORE
cc: kdo at SU-SCORE
Had a great time with you both last week.
Love,
Fran
-------
24-Nov-81 11:06:33-EST,548;000000000000
Mail-from: SU-SCORE rcvd at 24-Nov-81 1106-EST
Mail-from: ARPANET site DEC-MARLBORO rcvd at 24-Nov-81 0803-PST
Date: 24 Nov 1981 1102-EST
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: EONEIL at BBND, tops-20 at SU-SCORE
Postal-address: "73 Concord St., Maynard, Mass. 01754"
Subject: re: How to do a refresh
Message-ID: <"MS5(2026)+GLXLIB1(1056)" 11778829421.26.71.10241 at DEC-MARLBORO>
Regarding: Message from EONEIL at BBND of 23-Nov-81 1024-EST
The letter C does not appear in the correct spelling of SUPERSEDE.
--------
24-Nov-81 15:33:44-EST,1256;000000000001
Mail-from: SU-SCORE rcvd at 24-Nov-81 1533-EST
Mail-from: ARPANET site RAND-AI rcvd at 24-Nov-81 1220-PST
Date: 24 Nov 1981 1220-PST
Sender: WESCOURT at RAND-AI
Subject: J0NRUN after ^ECEASE
From: Keith Wescourt
Reply-To: Wescourt at RAND-AI
To: TOPS-20 at SCORE
Message-ID: <[RAND-AI]24-Nov-81 12:20:58.WESCOURT>
Frequently, after issuing a ^ECEASE in advance (more than an hour) of
a shutdown, we have had the system stop with a J0NRUN BUGHLT and
automatically reboot itself. When it has happened before, it usually
occurred within a few minutes of the scheduled shutdown, so that users
were seldom effected. Today, it happened 30 minutes before the
shutdown and did affect users adversely.
Has anyone seen this before, and if so is there a known fix? We have
the following DDT auto patch, supplied by DEC, installed in our monitor.
We are not a source site, so I can't determine what it is supposed to
do or whether it bears on the types of JONRUN problems I've described.
<4-PATCHES>J0NRUN-RSX20F-KL-4-MON.ATO.1
;;;;;SPR# 20-14651,EDIT# 240,SD 15-OCT-80
;;;;; FOR KL ONLY
CONN A
ENA
GET MONITR
ST 140
DTESRV:
DTEQ12+31/JRST FFF SKIPN NSKED
SKIPN FORKX
JRST DTEQ12+32
JRST DTEQ12+33
FFF:
^Z
SAVE
^X
24-Nov-81 16:55:38-EST,773;000000000001
Mail-from: SU-SCORE rcvd at 24-Nov-81 1655-EST
Date: 24 Nov 1981 1350-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Subject: Re: J0NRUN after ^ECEASE
To: Wescourt at RAND-AI, TOPS-20 at SU-SCORE
In-Reply-To: Your message of 24-Nov-81 1220-PST
Keith -
You need one of the various patches to SOBE% to return output buffer
non-empty if a TTMSG is pending on an NVT. The problem is that fork 0
is trying to deliver a TTMSG to an NVT and it is getting hung doing so
because TTMSGs don't start output on release 4. Actually, a better idea
is to have timeouts on TTMSGs, but that may be too difficult to patch.
-- Mark --
-------
24-Nov-81 17:09:43-EST,824;000000000000
Mail-from: SU-SCORE rcvd at 24-Nov-81 1709-EST
Mail-from: ARPANET site SANDIA rcvd at 23-Nov-81 1351-PST
Date: 23 Nov 1981 1231-MST
From: Norm Samuelson <Samuelson at SANDIA>
Subject: TOPS-20 hang
To: mrc at SANDIA
Remailed-date: 24 Nov 1981 1403-PST
Remailed-from: Mark Crispin <Admin.MRC at SU-SCORE>
Remailed-to: TOPS-20 at SU-SCORE
I have been experiencing a problem in TOPS-20 which I have not been able
to figure out yet. Lots of jobs have been hung trying to logout. The
terminal is dead. At the same time, ORION is hung in an i/o wait doing
a TTMSG at SNDTTY+2. Is there any way to look at the ACs of a SYSJOB
fork? I would like to know what ORION is trying to tell me. Or should
I run ORION over a PTY so I can talk to it? Any suggestions or hints
would be appreciated.
- Sam -
-------
1-Dec-81 22:05:00-PST,2293;000000000000
Mail-from: ARPANET site RUTGERS rcvd at 1-Dec-81 2153-PST
Date: 2 Dec 1981 0045-EST
From: WATROUS at RUTGERS (Don Watrous)
Subject: More on archiving speedup
To: Tops-20 at SU-SCORE
Some modifications to the archiving speedup I sent to this mailing
list a while back:
First of all, I seem to have dropped a signifigant 0 while stealing
code from the mailer. In DUMPER at OPNFL1-3 and PASS2A-4, and in
EXECIN at FLGLUP-1, MOVSI ac,-100 should be changed to MOVSI ac,-1000.
(Has anybody but Randy Frank noticed that some directories weren't
getting archived?)
Also pointed out by Randy: It was possible to rename a file being
archived to a directory which wasn't flagged in ARCHIVE-REQUESTS.BIN.
The solution, simply enough, was to check if the file being renamed
was panding archive, and if so flag the target directory in A-R.BIN.
Unfortunately, the monitor was very sensitive to where the code was
placed, and DDT was uncooperative with the debugging effort, so it
took me a while to get it right. (Does anybody either have or plan
on a DDT which works in sections other than 0?) Anyway, if you've
already installed the code, a difference file of new changes follows.
(If you still haven't put in the changes, I've updated the files
here on <ANONYMOUS>, so pick up a fresh copy!)
Don
File 1) JSYSF.MAC.28,25-Nov-81 03:28:14
File 2) JSYSF.MAC.23,13-Oct-81 10:49:08
[At FLAGIT+2]
1)6 jrst flagi0
1) flagt2: stkvar <flgjfn,filjfn,<flgtmp,100>>
1) xctu [ move t1,2] ; get jfn
1) flagi0: movem t1,filjfn
****
2)6 movem t1,filjfn
**************
[At .RNAMF+1]
1)116 trvar <arcbts>
1) CAMN 1,2 ;BE SURE NOT SAME JFN
****
2)116 CAMN 1,2 ;BE SURE NOT SAME JFN
**************
[At .SACTF-8 (after CALL @REND and ERUNLK)]
1)116 move jfn,(p) ; get new jfn
1) call getfdb ; get fdb for same
1) erunlk(,<pop p,jfn ; where'd it go?
1) call unlckf
1) pop p,jfn>)
1) load a,fbbbt,(a) ; get bits
1) movem a,arcbts ; save'm here
1) call ustdir ; free directory
1) POP P,JFN
****
2)116 POP P,JFN
**************
[And a few lines down...]
1)116 move a,arcbts ; get saved bits
1) txne a,ar%rar!ar%riv ; file going away?
1) call flagt2 ; yes, flag it
1) AOS -1(P)
****
2)116 AOS -1(P)
**************
-------
2-Dec-81 10:21:15-PST,1822;000000000000
Mail-from: ARPANET site RUTGERS rcvd at 2-Dec-81 1010-PST
Date: 2 Dec 1981 1305-EST
From: WATROUS at RUTGERS (Don Watrous)
Subject: Hold the presses on archiving speedup
To: Tops-20 at SU-SCORE
The patch for RNAMF to mark ARCHIVE-REQUESTS.BIN for archived files I
sent out this morning has a bug in it. In order to do a skip return,
the RNAMF jsys manipulates the stack directly, then JRSTs to MRETN
rather than use the routine SKMRTN which was set up for just that
purpose. My introduction of the TRVAR sabotaged RNAMF's bogus
return. (The EXEC didn't suffer from RNAMF not skipping, since it
uses ERJMP.) The corrected differences follow. This patch has been
tried in MDDT, the source is being assembled right now.
Don
File 1) JSYSF.MAC.28,25-Nov-81 03:28:14
File 2) JSYSF.MAC.23,13-Oct-81 10:49:08
[At FLAGIT+2]
1)6 jrst flagi0
1) flagt2: stkvar <flgjfn,filjfn,<flgtmp,100>>
1) xctu [ move t1,2] ; get jfn
1) flagi0: movem t1,filjfn
****
2)6 movem t1,filjfn
**************
[At .RNAMF+1]
1)116 trvar <arcbts>
1) CAMN 1,2 ;BE SURE NOT SAME JFN
****
2)116 CAMN 1,2 ;BE SURE NOT SAME JFN
**************
[At .SACTF-8 (after CALL @REND and ERUNLK)]
1)116 move jfn,(p) ; get new jfn
1) call getfdb ; get fdb for same
1) erunlk(,<pop p,jfn ; where'd it go?
1) call unlckf
1) pop p,jfn>)
1) load a,fbbbt,(a) ; get bits
1) movem a,arcbts ; save'm here
1) call ustdir ; free directory
1) POP P,JFN
****
2)116 POP P,JFN
**************
[And a few lines down...]
1)116 move a,arcbts ; get saved bits
1) txne a,ar%rar!ar%riv ; file going away?
1) call flagt2 ; yes, flag it
1) smretn ; have to clear up from TRVAR
1)117 ; Set account for file
****
2)116 AOS -1(P)
2) JRST MRETN
2)117 ; Set account for file
**************
-------
3-Dec-81 11:34:12-PST,649;000000000001
Mail-from: ARPANET site UTEXAS-20 rcvd at 3-Dec-81 1122-PST
Date: 3 Dec 1981 1318-CST
From: Edward C. Pattermann <G.ECP at UTEXAS-20>
Subject: Owners of directories
To: tops-20 at SU-SCORE
I want TOPS-20 to identify the owner of a sub-directory to be
the owner of the top-level directory. For example, my login dir
is PATTERMANN. If I create a sub-dir called PATTERMANN.LISP,
TOPS-20 does not give me owner access to PATTERMANN.LISP, although
that is what makes sense in this case. Does anyone know of a way
I can make this happen? Is there a patch that will work? Is there
something here I am missing?
Thanks, Ed
-------
3-Dec-81 13:03:23-PST,2014;000000000000
Mail-from: ARPANET site RUTGERS rcvd at 3-Dec-81 1248-PST
Date: 3 Dec 1981 1544-EST
From: WATROUS at RUTGERS (Don Watrous)
Subject: Re: Owners of directories
To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 3-Dec-81 1418-EST
This patch will allow a user who has connect without password access
to a superior directory to connect to any subdirectories of that
directory without a password. It still doesn't allow the files to be
accessed without connecting to the directory. Hope it's of some use.
Don
File 1) S:<4-MONITOR>DIRECT.MAC.5,13-Oct-81 10:29:42
File 2) S:<4-MONITOR>DIRECT.DEC.1, 3-Jan-80 08:08:30
1)5 SUPCH0: MOVEM T1,SUPCDN ;SAVE DIRECTORY NUMBER
****
2)5 MOVEM T1,SUPCDN ;SAVE DIRECTORY NUMBER
**************
1)5 HRRZ T3,SUPCSP ;CHECK FOR ROOT-DIRECTORY
1) CAIN T3,ROOTDN ;IF SO,
1) JRST .+5 ; DO RETBAD
1) MOVE T2,SUPCBT
1) MOVE T1,SUPCSP ;CHECK SUPERIORS SUPERIOR
1) CAME T1,SUPCDN ;PREVENT AN INFINITE LOOP
1) JRST SUPCH0
1) RETBAD ;RETURN FAILURE
****
2)5 RETBAD ;RETURN FAILURE
**************
File 1) S:<4-MONITOR>JSYSA.MAC.10,24-Oct-81 12:06:27
File 2) S:<4-MONITOR>JSYSA.DEC.1,24-Jan-80 09:45:24
[At ACCES5+4]
1)8 JRST .+2 ; NO, CONTINUE
1) JRST ACCES6 ; YES, PROCEED
1) ULKDIR ; UNLOCK THE DIRECTORY
1) HRR T1,Q2 ; GET DIRECTORY NUMBER
1) HRL T1,P5 ; GET STRUCTURE UNIQUE CODE
1) MOVX T2,DC%CN ; CHECK FOR ABILITY TO
1) CALL SUPCHK ; CONNECT TO SUPERIOR
1) JRST [ MOVEI T1,CNDIX1 ;NO. ASSUME INVALID PASSWORD
****
2)8 JRST [ MOVEI T1,CNDIX1 ;NO. ASSUME INVALID PASSWORD
**************
1)8 MOVEM T1,Q1 ; SAVE ERROR CODE
1) JRST ACCER0]
1) HRR T1,Q2 ; GET DIRECTORY NUMBER
1) HRL T1,P5 ; GET STRUCTURE UNIQUE CODE
1) CALL SETDIR ; RE-MAP THE DIRECTORY
1) RETBAD
1) ACCES6: STOR P5,JSUC ;NO. STORE CONNECTED STRUCTURE UNIQUE CODE
****
2)8 JRST ACCER3]
2) ACCES6: STOR P5,JSUC ;NO. STORE CONNECTED STRUCTURE UNIQUE CODE
**************
-------
5-Dec-81 09:59:53-PST,680;000000000000
Mail-from: ARPANET site SANDIA rcvd at 5-Dec-81 0947-PST
Date: 5 Dec 1981 1046-MST
From: Norm Samuelson <Samuelson at SANDIA>
Subject: XPASCAL - an eXtended Addressing version of PASCAL
To: tops20 at SANDIA
An extended addressing version of PASCAL, based on Hedrick's PASCAL
compiler from Rutgers, is now available. It still has a minor bug or
two, but it works for all the test cases I have. If you are interested
the source and object files are all in directory XPAS: at SANDIA.
Please read XPASCAL.DOC in that directory for more info. Please send
any bug reports to Samuelson@SANDIA. I hope to have all known bugs
out of it by New Years.
- Sam -
-------
5-Dec-81 17:06:32-PST,769;000000000000
Mail-from: ARPANET site MIT-XX rcvd at 5-Dec-81 1656-PST
Date: 5 Dec 1981 1956-EST
From: Nat Mishkin <NWM at MIT-XX>
Subject: Re: Owners of directories
To: G.ECP at UTEXAS-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 3-Dec-81 1418-EST
I have a patch to DIRECT which gives you owner access to
subdirectories (i.e. the directory AND its contents) of both your
login and connected directory. It makes life much nicer
especially when you really use subdirectories heavily.
I can't embed the patch in this msg since I'm here via a guest acct.
I can supply a paper listing to anyone interested. Alternatively,
you can wait until I (Yale) get on the net (hopefully within the
next month).
-- Nat Mishkin
Yale Comp. Sci. Dept.
-------
6-Dec-81 05:27:26-PST,1248;000000000000
Mail-from: ARPANET site CMU-20C rcvd at 6-Dec-81 0521-PST
Date: 6 Dec 1981 0818-EST
From: WOHL at CMU-20C
Subject: Re: Owners of directories
To: NWM at MIT-XX, G.ECP at UTEXAS-20, tops-20 at SU-SCORE
In-Reply-To: Your message of 5-Dec-81 1956-EST
We made a change to direct to DIRECT here at CMU to allow
users to give out owner access the same way group access
is given. The 400000 bit in directory group numbers to
give owner access. Clexec has an owner command that
is the same as the directory-group command but turns on
the 400000 bit for you, I DIR lists owners and directory
group numbers seperatly so evan though it is a hack it
looks nice to users.
The redit is [cmuc]ps:<wohl>DIRECT.DIF. It has two other
changes:
a) User group membership information is always looked up in the PS:
list for domestic structures rather than the list for
that structure. The idea here is that if you move some
big project directory off of PS: you don't have to give
everyone in the project a directory on the new structure
just so they can access it.
b) Dave put in a bunch of code to print out more information
on DIRxxx bugchecks to help in diagnosing directory
problems.
Aaron
-------
9-Dec-81 00:36:29-PST,11833;000000000001
Mail-from: ARPANET site RUTGERS rcvd at 9-Dec-81 0017-PST
Date: 9 Dec 1981 0307-EST
From: HEDRICK at RUTGERS (Mngr DEC-20's/Dir LCSR Comp Facility)
Subject: problems with dropped interrupts from disk; shared disks
To: tops-20 at SU-SCORE
The enclosed patch is for a somewhat subtle problem. Thus this is going
to be an extremely long explanation. If you are not interested in
reading it all, here is a synopsis:
problem: all transfers hang on a disk drive which is shared
between systems. (Note that this is an unsupported use
of Tops-20.) Possible J0NRUN's in some cases even on
standard systems, due to contention for PS0: between
Tops-20 and the front end.
diagnosis:
(1) code in PHYH2 is unable to handle more than one attention
interrupt at the same time.
(2) hardware does not do what the code at RP4CON assumes it
does.
(3) race condition when code at RP4CON takes branch to RP4CN2
cure: the following patches.
Now here are the gory details:
We developed some software that uses a shared disk drive to transfer
files and mail between two Tops-20 systems. The drive is mounted on one
system, but not on the other, since the monitor can't handle sharing of
file systems. The transfers are done using the DSKOP jsys to read and
write pages into the swapping area. DSKOP does not require the drive to
be mounted.
Anyway, in the course of this we are trying to access the same drive
from two different systems. There is monitor code to support this, as
long as you don't try to share the file system. The code is normally
used for sharing PS: volume 0 between Tops-20 and the front end. Before
using the drive, the system that wants it "seizes" the drive. It then
releases it when it is finished. If system A tries to seize the drive
when system B has it, the hardware remembers the request. When the
drive is freed by the system B, it is automatically allocated to system
A, and an attention interrupt is generated to system A, so that the
software knows it can proceed to use the drive. If a system seizes the
drive and does not release it, the seizing times out after 1 second. The
problem was that now and then one of the systems would "hang". I.e. all
programs attempting to access the shared drive would go into I/O wait,
and could not be ^C'ed. It appeared that the system had tried to seize
the drive when the other system had it, but had failed to get the word
when the drive was freed. We conjecture that if this had happened with
PS: (which it could due to competition between Tops-20 and RSX-20F), you
would get a J0NRUN.
The first theory was that something was wrong with the hardware such
that it did not seize the drive as documented. SRI and DEC seem to
agree that one of the documented methods of seizing a drive (reading the
control register) does not work all the time. They proposed a change to
the code in PHYP4 that uses a different way of seizing the drive
(writing to an illegal register) that seems to work all the time. I
have been unable to verify that this problem happens at Rutgers.
However I did find two software problems that could result in similar
situations. One was a race condition in the code that handled the
situation where the drive could not be seized. Fortunately the fix
proposed by SRI and DEC for the hardware problem also fixes this race
condition. The other problem is more complex. It turns out that it is
possible to get attention interrupts for more than one unit on a given
channel at the same time. Such interrupts apparently can mean any one
of a number of things: that a seek is finished, that a transfer is
finished, that a drive has gone on or off line, and (what is relevant
here) that a shared drive which was previously seized by the other
system has now become available to this system. I will refer to this as
a "seize done" condition. Of these various kinds of attention
interrupts, drive on line and drive off line can be processed locally by
the low-level routine that diagnoses the interrupts. However seek done,
transfer done, and seize done all require new I/O operations to be
started, and so must be processed by the top-level module (PHYSIO). But
the design of the code is that PHYSIO calls the interrupt handler, which
returns a flag and some other data giving it at most one task to carry
out. The effect is that if more than one of these done conditions occurs
(on different drives) at the same time, only one is actually processed.
I have no idea what the effects of this are on seek done and transfer
done. However when a seize done lost the competition as to which should
be processed, the result was that the drive became unusable. The
low-level interrupt routine had marked it available, but PHYSIO lost the
command to restart I/O.
The real solution is to rewrite the relevant routines in PHYSIO and
PHYH2 to process multiple interrupts at the same time. I have adopted a
less elegant solution, but one which appears to work. There is a piece
of code in PHYSIO that looks at each drive on the system one a second to
see whether it needs any help. (This is the routine that prints
%PROBLEM ON DEVICE ... .) If it finds a drive that was previously noted
as unavailable, but which has just become available, it restarts pending
I/O requests for that drive. This is just what we need done after we
manage to get the shared drive. In fact when PHYP4 first discovers that
it can't get the drive (at RP4CON), it does set the status bits in
UDBSTS such that this once-per-second code will look at the drive. That
would be sufficient, although it would result in relatively slow
recovery of the drive. However when the seize done interrupt occurs,
RP4ATU clears these bits, since it believes that the drive is now
available, and that PHYSIO will restart the I/O on it. Thus if the
interrupt is not handled, due to several interrupts interfering, the
once per second code will not rescue the situation, since the bits that
cause this code to look at the drive have been cleared. The solution I
have adopted is to have RP4ATU not clear the unavailable bits. (Indeed I
have RP4ATU verify that they are set.) Rather, I move the clearing of
the bits up into NOATTN (in PHYH2), where it is finally determined that
the interrupt is going to be handled properly. Thus in the case where
the interrupt cannot be handled, the bits are still set in such a way
that the once per second code rescues us. If this seems overly complex,
the obvious alternatives do not work:
- you might think we could just leave the unavailable bits set in all
cases. However these bits would interfere with PHYSIO's attempt
to restart I/O in the situation where it *is* able to handle the
interrupt
- you might think that we could simply ignore the seize done
interrupts completely, and depend upon the once per second code
to restart I/O in all cases. The problem with this is that it
would badly slow down thruput with this disk. When the drive
was being heavily used on both systems, we had a situation
where exactly one disk access happened on each system each
second. This is clearly too high a performance penalty. We
need the interrupt handling in the cases where it works, in
order to get reasonable performance.
So the following patch moves the clearing of the unavailable bit up into
PHYR2, where it is finally determined that the seize done is going to be
handled. There is one remaining problem: The original code simply set
LH(Q1) as a flag that something needed to be done. Unfortunately, by the
time we get to the code in PHYR2, we can no longer tell which unit the
request is for. The code there assumes that the request is for the most
recent unit examined, and that the AC's are still set up for it. If
there is more than one interrupt, this need not be the case. So we put
the unit number + 1 into LH(Q1) as the flag. This allows us to check
whether the AC's still have data pertaining to this unit. If not, we
simply ignore the request and let the once per second code handle it.
(The unit number + 1 is used to avoid a zero value, which would indicate
nothing to do.)
File 1) PHYH2.MAC.4, 8-Dec-81 23:26:40
File 2) PHYH2.MAC.1, 3-Jan-80 08:10:11
1)17 CAIG P4,0 ;[221] 1,,0 -special from RP4ATU
1) RETSKP ;AND LET PHYSIO DO ITS THING
1) ;[221] all of the code here is needed because the code here
1) ;[221] is unable to do anything interesting for more than one unit
1) ;[221] at a time. We could get attn done from one and another
1) ;[221] interrupt from another. The code here is designed to handle
1) ;[221] the case where RP4ATU has found that a shared drive is now
1) ;[221] available. Its sets Q1 to indicate that we should ask
1) ;[221] PHYSIO to restart I/O on that drive. This is fine, but if
1) ;[221] another kind of interrupt happened at the same time, it is
1) ;[221] possible that we will go to XFR and handle it, or that
1) ;[221] P1 could now be pointing to the UDB of a different unit.
1) ;[221] Thus the code here is designed to make sure that we are still
1) ;[221] set up for the same unit that RP4ATU found. If so, we set P4
1) ;[221] to -1, which is a flag to PHYINT to continue I/o on the unit.
1) ;[221] if not, we clear P4. In this case we are ignoring the fact
1) ;[221] that the shared drive is now available. Since the US.OIR
1) ;[221] bit is still set, the once a second code will eventually notice
1) ;[221] that the drive is back and restart I/O. RP4ATU set LH(Q1) to
1) ;[221] unit number+1. The +1 is to guarantee that it is non-zero,
1) ;[221] since zero is a null request.
1) HLRZ P4,Q1 ;[221] get unit number+1, from RP4ATU request
1) ADD P4,P1 ;[221] access below is CDBUDB+.P4-1(P1)
1) CAME P3,CDBUDB-1(P4) ;[221] compare current unit with RP4ATU's
1) JRST [ SETZ P4, ;[221] wrong unit, forget request
1) RETSKP] ;[221]
1) MOVSI T1,(US.OFS!US.OIR!US.OMS) ;[221] this is going to work, so
1) ANDCAM T1,UDBSTS(P3) ;[221] clear bits saying we're in trouble
1) SETO P4, ;[221] now ask for continuing I/O
1) RETSKP ;[221] from PHYINT
1) XFR: TRNN T1,CI.DON ;IS CONTROLLER BUSY?
****
2)17 RETSKP ;AND LET PHYSIO DO ITS THING
2) XFR: TRNN T1,CI.DON ;IS CONTROLLER BUSY?
**************
File 1) PHYP4.MAC.5, 8-Dec-81 23:16:08
File 2) PHYP4.MAC.1, 3-Jan-80 08:10:13
1)9 RP4CON: MOVSI T2,DO.DT ;[221] WRITE RANDOM REGISTER - SIEZE PORT
1) CALL WTREG ;[221] IF IN A/B MODE
1) MOVSI T2,DO.DRC ;READ CONTROL REGISTER - SEE IF WE GOT IT
1) CALL RDREG ; IF IN A/B MODE
****
2)9 RP4CON: MOVSI T2,DO.DRC ;READ CONTROL REGISTER - SIEZE PORT
2) CALL RDREG ; IF IN A/B MODE
************** at RP4CN2+??
1)9 ;[221] MOVSI T2,DO.DRC ;PICK A REGISTER TO WRITE
1) ;[221] CALL WTREG ;WRITE IT TO INDICATE ACCESS DESIRED
1) RET ;WE'LL BE INTERRUPTED WHEN DRIVE AVAILABLE
****
2)9 MOVSI T2,DO.DRC ;PICK A REGISTER TO WRITE
2) CALL WTREG ;WRITE IT TO INDICATE ACCESS DESIRED
2) RET ;WE'LL BE INTERRUPTED WHEN DRIVE AVAILABLE
**************
1)13 ;[221] device is now ours. But the code in PHYH2 may not be able to
1) ;resume the transfer. If not, will have to depend upon the operator
1) ;intervention stuff to do so.
1) RP4ATU: MOVX T1,US.OIR!US.OMS ;[221] DEVICE IS NOW OURS AGAIN, BUT ASSUME
1) IORM T1,UDBSTS(P3) ;[221] the worst - will need UNICHK to resume
1) HRLI Q1,1(Q1) ;[221] flag this special case for PHYH2
1) JRST ATNXIT ;JOIN COMMON EXIT
****
2)13 RP4ATU: MOVX T1,US.OFS!US.OIR!US.OMS ;DEVICE IS NOW OURS AGAIN
2) ANDCAM T1,UDBSTS(P3) ;SO MAKE UNIT ONLINE AGAIN
2) TLO Q1,-1 ;SET TO RESTART I/O
2) JRST ATNXIT ;JOIN COMMON EXIT
**************
-------
10-Dec-81 09:29:23-PST,718;000000000000
Mail-from: ARPANET site CIT-20 rcvd at 10-Dec-81 0918-PST
Date: 10 Dec 1981 0918-PST
From: DICK at CIT-20
Subject: Domestic Structure Access
To: TOPS-20 at SU-SCORE
I found, to my dismay and amazement, that the monitor does not recognize
any correspondence between user group numbers and directory group numbers
on domestic structures. I would imagine that this simple, yet basic,
problem would have been noticed and fixed long ago by some of you folk out
there. I presume that there exists a source mod for DIRECT.MAC that
corrects this oversight in DIRCHK and/or ACCCHK. If anyone knows of such a
fix I would appreciate a pointer to it. Patches are welcome too.
Dick Lang
-------
10-Dec-81 15:43:59-PST,462;000000000000
Mail-From: ADMIN.MRC created at 10-Dec-81 15:28:17
Date: 10 Dec 1981 1528-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: MPW program
To: TOPS-20 at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Does anybody have the source for the MPW program? It generates pronouncable
random strings for use as passwords. Please reply to EIBEN@DEC-MARLBORO.
-------
12-Dec-81 15:53:58-PST,1034;000000000000
Mail-from: ARPANET site SANDIA rcvd at 12-Dec-81 1545-PST
Date: 12 Dec 1981 1644-MST
From: Norm Samuelson <Samuelson at SANDIA>
Subject: Extended Addressing
To: tops20 at SANDIA
DEC is VERY interested in Extended Addressing. At DECUS they said that
FORTRAN is their highest priority software engineering project, and that
extended addressing support was definitely planned as part of the next
release after v6. DEC has asked me to create a mailing list of users
with an interest in extended addressing. If you want to be on that mailing
list please let me know as soon as possible. The list will probably turn
out to be a large subset of the TOPS20 mailing list at SCORE, but DEC
specifically askd for another list, so that is what they will get.
Also, it is already time to start planning for the next DECUS, which will
be in Atlanta in May. I think it would be useful to have a session on
extended addressing applications. If you would be interested in taking
part please let me know.
- Sam -
-------
12-Dec-81 16:40:04-PST,542;000000000000
Mail-from: ARPANET site SANDIA rcvd at 12-Dec-81 1633-PST
Mail-from: ARPANET site UTAH-20 rcvd at 12-Dec-81 1728-MST
Date: 12 Dec 1981 1727-MST
From: Randy Frank <FRANK at UTAH-20>
Subject: Re: Extended Addressing
To: Samuelson at SANDIA, tops20 at SANDIA
In-Reply-To: Your message of 12-Dec-81 1644-MST
I think Norm misunderstood DEC's statement on Fortran. I understood
that next release after v6 will be Fortran 77, and release after that (r8)
will be extended addressing. Anyone else who was there care to comment?
-------
12-Dec-81 21:26:14-PST,977;000000000000
Mail-From: ADMIN.MRC created at 12-Dec-81 21:15:12
Date: 12 Dec 1981 2115-PST
From: Mark Crispin
Subject: Re: Domestic Structure Access
Sender: ADMIN.MRC at SU-SCORE
To: DICK at CIT-20, TOPS-20 at SU-SCORE
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of 10-Dec-81 0918-PST
It is not a bug that groups are different across domestic structures, it
is a feature. The idea of structures are that each should be allowed to
have independent groups. Domestic vs. foreign means that FOO is the owner
of BAR:<FOO> as well as PS:<FOO>. By doing ACCESS BAR:<FOO> she can get
the user groups that BAR:<FOO> has the right for.
It is a trivial routine in your ACJ to implementing global user groups, at
least in so far as CONNECT/ACCESS works. Look at MRC:<UTILITIES>ACJ.MID
for how SCORE's ACJ does it.
-- Mark --
-------
16-Dec-81 12:34:59-PST,580;000000000000
Mail-from: ARPANET site SUMEX-AIM rcvd at 16-Dec-81 1220-PST
Date: 16 Dec 1981 1220-PST
From: Eric Schoen <Schoen at SUMEX-AIM>
Subject: Page mapping question
To: tops-20 at SU-SCORE
Can someone tell me why when I map a private page in a process into
a page in a file, the process page disappears? This is not consistent
with Tops-20's behavior in mapping pages from files into processes (i.e.
the file page doesn't disappear). I can get around this problem by
mapping the file page back into the process, but I think that should
be unnecessary.
Eric
-------
16-Dec-81 15:39:11-PST,583;000000000000
Mail-from: ARPANET site RUTGERS rcvd at 16-Dec-81 1525-PST
Date: 16 Dec 1981 1823-EST
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: REFUSE SYSTEM-MESSAGES for terminals
To: tops-20 at SU-SCORE
Does anyone have a way to have some terminals set up so that they
are by default refusing system-messages? We have a graphics display
which should be set up that way and I noticed that when a tty line is
reset (ie a job starts on it or a jfn is opened for the "first time")
the monitor sets up the line to terminal type system-default....
Any ideas or help?
Roy
-------
16-Dec-81 17:02:42-PST,422;000000000000
Mail-from: ARPANET site RUTGERS rcvd at 16-Dec-81 1651-PST
Date: 16 Dec 1981 1948-EST
From: Roy Marantz <MARANTZ at RUTGERS>
Subject: Re: REFUSE SYSTEM-MESSAGES for terminals
To: Admin.MDP at SU-SCORE
cc: tops-20 at SU-SCORE
In-Reply-To: Your message of 16-Dec-81 1941-EST
What is TTYINI? Also I don't think it will help because the monitor
resets these parameters each time the line is reset.
Roy
-------
16-Dec-81 17:02:50-PST,477;000000000000
Mail-From: ADMIN.MDP created at 16-Dec-81 16:41:55
Date: 16 Dec 1981 1641-PST
From: Mike Peeler <Admin.MDP at SU-SCORE>
Subject: Re: REFUSE SYSTEM-MESSAGES for terminals
To: MARANTZ at RUTGERS
cc: tops-20 at SU-SCORE
In-Reply-To: Your message of 16-Dec-81 1523-PST
Roy,
One way would be, if your system runs TTYINI on job startup, to
add switches to it for receiving and refusing, and put the appropriate
settings into SYSTEM:TTYINI.CMD.
- mdp -
-------
17-Dec-81 07:01:33-PST,680;000000000000
Mail-from: ARPANET site AFSC-HQ rcvd at 17-Dec-81 0652-PST
Date: 17 Dec 1981 0945-EST
From: Chuck Perilli <PERILLI at AFSC-HQ>
Postal-address: HQ AFSC/ACDPS, Andrews AFB, DC 20334
Phone: (301)981-4002; AUTOVON: 858-4002
Subject: Re: REFUSE SYSTEM-MESSAGES for terminals
To: MARANTZ at RUTGERS
cc: : ;
In-Reply-To: Your message of 16-Dec-81 1948-EST
What we did here was add the code to refuse system messages in the
initialization routine of each of the graphics packages we use. Most
graphics software has some initialize or startup routine that must be
called before any other routines. This is not a very elegant fix, but
it works.
---Chuck
-------
17-Dec-81 14:59:27-PST,246;000000000000
Mail-From: G.ELDRE created at 17-Dec-81 14:44:20
Date: 17 Dec 1981 1444-PST
From: Tim Eldredge <g.eldre at SU-SCORE>
Subject: ADA for TOPS-10/20
To: tops-20 at SU-SCORE
Does anyone have an ADA compiler/interpreter for the 10/20?
-------
17-Dec-81 15:25:38-PST,353;000000000000
Mail-from: ARPANET site SRI-KL rcvd at 17-Dec-81 1459-PST
Date: 17 Dec 1981 1535-PST
From: Richard R. Cower <COWER at SRI-KL>
Subject: Re: ADA for TOPS-10/20
To: g.eldre at SU-SCORE, tops-20 at SU-SCORE
cc: COWER at SRI-KL, kennard at SRI-KL
In-Reply-To: Your message of 17-Dec-81 1444-PST
yes...give me a call. 859-6336.
.rich
-------
17-Dec-81 15:25:39-PST,713;000000000000
Mail-from: ARPANET site RADC-TOPS20 rcvd at 17-Dec-81 1500-PST
Date: 17 Dec 1981 1838-EST
From: Mark Pratt <PRATT at RADC-TOPS20>
To: g.eldre at SU-SCORE, tops-20 at SU-SCORE
Reply-to: Pratt at RADC-TOPS20
Telephone: 315-330-4013
Subject: Re: ADA for TOPS-10/20
Message-ID: <MS"5(1646)"11784941794.6.158.162480 at RADC-TOPS20>
In-reply-to: Message from Tim Eldredge <g.eldre at SU-SCORE>
of 17-Dec-81 1744-EST
We have an ADA compiler. It came from ECLB and is being developed
by a contractor out there. I don't have a contact name but if you
want I can find out for you. I don't really have anything to do
with it but can find out from a user on my system.
--Mark
--------
18-Dec-81 11:47:15-PST,521;000000000000
Mail-from: ARPANET site SRI-KL rcvd at 18-Dec-81 1137-PST
Date: 18 Dec 1981 1002-PST
From: Richard R. Cower <COWER at SRI-KL>
Subject: ADA compiler
To: tops-20 at SU-SCORE
I"ve had more requests for this information than I care to answer individually.
The ADA compiler I know of is from a company called INTERMETRICS, located
somewhere in Mass. The contact there is Mike Ryer. It is written in SIMULA.
I found out about it last week at a DOD meeting at DECUS, chaired by Lloyd
Snow.
.Rich Cower
-------
18-Dec-81 13:28:37-PST,286;000000000000
Mail-from: ARPANET site SRI-KL rcvd at 18-Dec-81 1318-PST
Date: 18 Dec 1981 1304-PST
From: ROODE at SRI-KL (David Roode)
Subject: Intermetrics address
To: tops-20 at SU-SCORE
733 Concord Avenue Cambridge MA 02138 617 661 1840
I believe this is the ECLB compiler too.
-------
18-Dec-81 15:55:01-PST,492;000000000000
Mail-from: ARPANET site SRI-KL rcvd at 18-Dec-81 1539-PST
Date: 18 Dec 1981 1538-PST
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Re: Intermetrics address
To: ROODE at SRI-KL, tops-20 at SU-SCORE
In-Reply-To: Your message of 18-Dec-81 1304-PST
Note that the Intermetrics Ada compiler is a toy compiler, and is also
the world's slowest piece of software: it is written in Simula, compiles
Ada to an internal tree language, and then interprets that (general)
language.
-------
18-Dec-81 20:27:07-PST,3569;000000000000
Mail-From: ADMIN.MRC created at 18-Dec-81 20:18:39
Date: 18 Dec 1981 2018-PST
From: Mark Crispin
Subject: new release of MM/XMAILR/XMAILBOX
Sender: ADMIN.MRC at SU-SCORE
To: TOPS-20 at SU-SCORE
cc: MMcM at SU-SCORE
Reply-To: Admin.MRC at SU-SCORE
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
A major release of the MM mailsystem is hereby announced,
with several functionality improvements and bugfixes. The
bugfixes are especially important to anybody who has an MM with a
version number above 650 or so. This release is MM version 663
(version of 12/18/81); accompanying it are XMAILR version 481
(version of 12/5/81) and XMAILBOX version 112 (version of
12/14/81).
Among the interesting changes are:
FROM and REPLY-TO commands which allow setting those fields
in the message header in a more controlled way than USER-HEADERS
allow. FROM sets up a default Reply-To of the alias sender, as
well as forcing a Sender line of the physical sender.
The SHOW command outputs the current MM.INIT variables to
the terminal (it is literally CREATE-INIT redirected to TTY:).
This is in response to a number of requests for this
functionality. It is planned to get rid of the magic numbers and
to have a more selective help facility in this area.
MM.CMD is a new initialization file. It is run when MM is
invoked as MM (as opposed to "MM SEND" or "MAIL" or "MM READ").
It contains ordinary MM commands. This uses the new MM "TAKE"
facility (yes, there is now a TAKE command in MM); essentially,
whenever MM is run as MM it does an implicit "TAKE MM.CMD" if the
file exists. PS:<ADMIN.MRC>MM.CMD at SCORE shows what MM.CMD
files can be good for. You can have SET commands in MM.CMD, but
it is recommended that MM.INIT be used to set MM variables
instead (MM.CMD corresponds to EMACS.INIT much as MM.INIT
corresponds to EMACS.VARS).
A site-selectable option allows the system to select MM's
style of file I/O; either by page-mapping the mail file in or by
keeping a private copy in memory. Page-mapping is faster and
cheaper on disk space (the private copy method requires twice as
much space), although somewhat more dangerous if the system
crashes at an awkward time. MM currently uses the page-mapping
mechanism by default; some Tenex sites must use the private copy
mechanism. We are working on making MM more careful to keep the
disk copy consistant at all times.
The next two changes apply only to sites which use the
XMAILR mailer daemon instead of NMAILR:
XMAILR now has code to write the origin of the message in a
Mail-From: line for local recepients if the origin was not
FTPSER (e.g. its writer is not OPERATOR). This is a modest
attempt at message security but at the same time not get in the
way of useful functionality (such as ALIAS).
XMAILBOX has some code to protect itself against garbage
indirect files (files with bad byte counts confused the hell out
of it).
I urge all MM sites to install this new release, which is
located on MRC:<MM>*.MAC at SU-SCORE. Please report any problems
with the new release by using MM's BUG command. If there are any
local changes to MM which you have made but are not in this
version, please try to get those changes to me. The best way to
get your changes installed in the official MM is to send me a
copy of the current SCORE MM.MAC (or MM.FAI) with your changes
edited in.
-- Mark --
-------
21-Dec-81 10:04:56-PST,679;000000000000
Mail-From: G.TJM created at 21-Dec-81 09:46:04
Date: 21 Dec 1981 0946-PST
From: Ted Markowitz <G.TJM at SU-SCORE>
Subject: Setting duplex
To: tops-20 at SU-SCORE
This question is in the same vein as the one on refusing messages. I'd
like to have the monitor bring up jobs on specific ports as
line-half-duplex. This will be used to help connect us to an
SNA-network (don't laugh too hard... it wasn't my idea). So far the
connections have been made (well sort of) but, the software in the IBM
boxes chokes on full-duplex talking back to it. I've never heard of
TTYINI either but, does it provide some functionality that would help
in this case?
--ted
-------
30-Dec-81 19:25:18-PST,277;000000000000
Mail-from: ARPANET site CIT-20 rcvd at 30-Dec-81 1906-PST
Date: 30 Dec 1981 1906-PST
From: Barry Megdal <BARRY at CIT-20>
Subject: fortran-77
To: tops-20 at SU-SCORE
Is an implementation of fortran-77 available for DEC-20's, and if so,
from where?
Thanks.
-------
