2-Jan-86 08:55:31-PST,905;000000000001

2-Jan-86 08:55:31-PST,905;000000000001
Return-Path: <@CU20B.COLUMBIA.EDU:STAFF.HERSHMAN@NYU20>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 2 Jan 86 08:55:16-PST
Received: from NYU20 by CU20B with DECnet; 2 Jan 86 11:58:32 EST
Date: Thu 2 Jan 86 11:58:45-EST
From: Ittai Hershman <Staff.Hershman@NYU20>
Subject: Cache memory for front-end
To: [email protected]
Office-Phone: 212-285-6068

A seemingly small outfit called Minntronics (St. Paul, MN) recently sent
me a direct-mail blurb on cache memory for 11/40 front-ends of
DECSYSTEM-%0's. It seems that they have been selling these to PDP-11
customers since 1979, but all of a sudden have discovered the 10/20
market. They claim that several 10/20 customers have bought the cache
and found performance improvements of up to 30% or so.

Have any of you tried the unit, or heard any reliable information about
it?

Thanx,
-Ittai
-------
2-Jan-86 08:58:03-PST,572;000000000000
Return-Path: <@CU20B.COLUMBIA.EDU:STAFF.HERSHMAN@NYU20>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 2 Jan 86 08:57:52-PST
Received: from NYU20 by CU20B with DECnet; 2 Jan 86 12:01:08 EST
Date: Thu 2 Jan 86 12:01:22-EST
From: Ittai Hershman <Staff.Hershman@NYU20>
Subject: oops
To: [email protected]
Reply-To: Ittai@NYU
Office-Phone: 212-285-6068

I meant to add REPLY-TO: Ittai@NYU and hit ^Z to fast... Not all mailers know
how to route to my sending address, so please send replies to Ittai@NYU.

Sorry,
-Ittai
-------
3-Jan-86 13:26:51-PST,407;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Fri 3 Jan 86 13:26:32-PST
Date: Fri 3 Jan 86 14:28:43-MST
From: Walt <[email protected]>
Subject: Source for TSTAT
To: [email protected]
Message-ID: <[email protected]>

Does anybody have the source for the TSTAT.EXE which is on the
TCP/IP tools tape?

Thanks in advance -- Walt
-------
8-Jan-86 12:46:19-PST,746;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 8 Jan 86 12:46:09-PST
Date: Wed 8 Jan 86 13:47:53-MST
From: Randy Frank <[email protected]>
Subject: DEC Support for TCP/IP
To: [email protected]
Message-ID: <[email protected]>

I just got a copy of the SPD for TCP/IP-20 from DEC. Evidently DEC has
unbundled TCP/IP. I assume that if you had a Tops-20AN license then you
automatically (free) get a license to TCP/IP-20. However, there is one
unbelievable phrase in the SPD dealing with sources: "NOTE: Software built
from the sources kit is not supported". Thus, if you are a source code
customer, DEC makes no claim that the sources they send you work.
-------
9-Jan-86 06:21:55-PST,328;000000000000
Return-Path: <[email protected]>
Received: from G.BBN.COM by SU-SCORE.ARPA with TCP; Thu 9 Jan 86 06:21:36-PST
Date: Thu 9 Jan 86 09:20:43-EST
From: Dan Tappan <[email protected]>
Subject: DMZ32's
To: [email protected]

Does anyone out there know whether DMZ32's will ever be supported
by the KL front-end?

-------
9-Jan-86 17:46:57-PST,998;000000000001
Mail-From: BILLW created at 9-Jan-86 17:46:54
Date: Thu 9 Jan 86 17:46:54-PST
From: William "Chops" Westfield <[email protected]>
Subject: Lisp machines talking to MEIS based 20's
To: [email protected]
Message-ID: <[email protected]>

We have had problems with symbolics lisp machines talking directly
to the 10 Mb ethernet interfaces on the local 20's. This turns
out to be because the LM is sending a packet whose hardware and
software data lengths differ by 2, and the 20 discards all packets
whose length differs by more than 1. It turns out that there is
a simple patch to tops20 to allow it to accept these packets,
which seems to allow LM's and 20's to talk to each other just fine.

at IPRCI1-2, change CAILE T1,1 to CAILE T2,2

Since both we and the LM people around here view this as a bug
in the LM code, we hope to have it fixed by symbolics. therefore
I have put this patch in MONITR.MIC, rather than in the sources.

BillW
-------
13-Jan-86 15:22:17-PST,1076;000000000000
Return-Path: <[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Jan 86 15:21:44-PST
Date: Mon 13 Jan 86 15:24:49-PST
From: Ted Shapin <[email protected]>
Subject: Multiple RP07 query
To: [email protected]
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
Message-ID: <[email protected]>

Subject: MULTIPLE RP07 STRUCTURE

DOES ANYONE KNOW OF A PATCH OR POSSIBLY A SOURCE CODE CHANGE
THAT WILL ALLOW A MULTIPLE RP07 STRUCTURE ON TOPS-20 (V5.1 OR V6.1).
DEC'S DOCUMENTATION STATES THE ONLY DISK DRIVE THAT CAN'T BE MADE
INTO A MULTIPLE SPINDLE STRUCTURE IS THE RP07. WHY? I DON'T KNOW.

I ALSO THOUGHT (FROM INFORMATION GATHERED AT DECUS SESSIONS A FEW
YEARS AGO THAT THIS WAS GOING TO BE IMPLEMENTED BY VERSION 6), BUT
ALAS NO SUCH LUCK. IF ANYONE OUT THERE HAS ANY INFORMATION ON THIS
I WOULD SHURE APPRECIATE IT. THANKS.

WILL WOOD
BECKMAN INSTRUMENTS, X-11
2500 HARBOR BLVD.
FULLERTON CA., 92634

-------
13-Jan-86 15:55:58-PST,770;000000000000
Return-Path: <[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Jan 86 15:55:45-PST
Date: Thu 19 Dec 85 14:14:43-PST
From: Ted Shapin <[email protected]>
Subject: One-way password transform wanted
To: [email protected], [email protected]
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
Message-ID: <[email protected]>
ReSent-Date: Mon 13 Jan 86 15:58:50-PST
ReSent-From: Ted Shapin <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

I am looking for a one-way transform algorithm that could be
used with passwords on 8088 and/or 8080 systems.
-------
13-Jan-86 16:14:52-PST,1468;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 13 Jan 86 16:14:29-PST
Date: Mon 13 Jan 86 18:17:47-CST
From: Clive Dawson <[email protected]>
Subject: Re: Multiple RP07 query
To: [email protected]
cc: [email protected]
In-Reply-To: Message from "Ted Shapin <[email protected]>" of Mon 13 Jan 86 17:36:22-CST

Multiple-RP07 structures are indeed being used at quite a few sites,
including Stanford, Univ. of Texas, and here at MCC. There are at least
two (possibly more?) different versions of the necessary patches, some of
which preserve compatibility with vanilla file structures and some of which
don't. We're using one of the versions which does not preserve
compatibility, which we got in early 1983 from Mark Crispin. This means
that even our traditional, "small" structures must be rebuilt in order to
be used by the new monitor. Also, this set of patches really should be
used only if you have sources, since one of the .UNV files is involved.

The monitor changes are simple, but must be made with care. Changes are
also required in the CHECKD program, as well as BOOT and MTBOOT in the
front-end area (and floppies). If you have access to the TOPS-20 archives
(see the <TOPS-20-ARCHIVE> directory at SCORE) you should find several
messages on the subject sometime in 1983. If you can't find them, let me
know and I'll dig up Mark's original message.
Clive
-------
16-Jan-86 14:15:22-PST,1520;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Jan 86 14:14:54-PST
Date: Thu 16 Jan 86 15:15:37-MST
From: Walt <[email protected]>
Subject: SYN with a window size of zero
To: [email protected], [email protected]
Message-ID: <[email protected]>

One of our TCP implementations (TOPS-20) opens a TCP connection
with a segment that contains the usual SYN and a window size of
zero. According to one interpretation of the spec there should be
no legal response to such a segment since the normal response is
SYN+ACK and the SYN in the response would take up sequence number
space, which does not exist according to the sender of the first
segment. According to another intepretation, the window size
refers to data octets only, and the sequence number space taken by
SYNs and FINs shouldn't count.

Various implementations handle this in various ways - some apparantly
assume that it's silly to send SYN with a window size of zero, and just
go ahead and reply with SYN+ACK. One implementation appears to go
into a tight loop in this situation.

Does anybody have any references that would resolve the apparent
ambiguity? It isn't clear to me how to apply the robustness principle
to this case - one could imagine that an implementation could have
an unusual situation where it needed to open a connection but didn't
at the moment have any place to put a reply.

Thanks in advance for any helpful comments -- Walt
-------
16-Jan-86 18:45:52-PST,1168;000000000000
Return-Path: <[email protected]>
Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Thu 16 Jan 86 18:45:44-PST
Date: 16 Jan 1986 21:44-EST
Sender: [email protected]
Subject: Re: SYN with a window size of zero
From: [email protected]
To: [email protected]
Cc: [email protected], [email protected]
Message-ID: <[USC-ISI.ARPA]16-Jan-86 21:44:33.CERF>
In-Reply-To: <[email protected]>

Walt,

since one could not successfully "open" a connection without
getting the matching SYN-ACK, it seems appropriate for the
recipient of such a packet to respond, despite the apparent
violation. As you know, it is allowed to send at least one
octet into a closed (0) window to assure that when it
opens you hear that. The SYN can safely elicit an ACK without
opening the window any further.

Depending on the implementation, some systems don't apply the
window size until AFTER the connection has reached the OPEN state
which it cannot get to without first exchanging SYN-ACKs.

Jon Postel will undoubtedly have a reference to page xx para gg
and sugestion to look in one of Dave Clark's marvelous
tutorial sections...

Vint Cerf
17-Jan-86 03:03:56-PST,3811;000000000000
Mail-From: BILLW created at 17-Jan-86 03:03:51
Date: Fri 17 Jan 86 03:03:51-PST
From: William "Chops" Westfield <[email protected]>
Subject: TVT performace improvements...
To: [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>

The following message will be sent to various mailing lists
with wider circulation after the code has run for a while.
I haven't tested out the sources yet, but SU-Score and
SRI-Stripe are both running with equivilent patches that
were installed using MDDT. It seems to cause nothing
except goodness, especially on Stripe (which is behind
a particurally unhappy gateway) - The time it took the
sample losing code segment to run went down from 30-40
seconds to a much more reasonable 1-2 seconds...

Enjoy
BillW
------------------------------

BUG: Under certain situations, throughput on TOPS20 TVTs drops to
approximately 0 for long periods of time. I believe that
the problem got worse with v6.1, and may be the reason
that the TVT SMTP server doesn't work well under 6.1.

Reproduce by:
I think this shows up best when trying to run a dialout
type program while logged in on a TVT. However, the
following program will exhibit the problem too:

start: movei 6,^d32
loop: movei 1,"%"
pbout
movei 1,^d30
disms
sojg 6,loop
haltf

Diagnosis:
The tops20 TVT scanner attempts to send characters that are
part of "echoing" immediately. It's criteria for recognizing
"echoes" is that there be fewer than 8 characters in the
terminal output buffer. Since the TCP process runs at a very
high priority, it will probably get to look at the TTY output
buffers if the user process blocks for any reason. In the
case above, therefore, there is a good chance that 32
separate 1 byte packets are queued. And there are certainly
lots of machines that don't like to receive 32 almost
back-to-back short packets. This leads to many retransmissions
and excessive use of CPU time on both systems, not to mention
any gateways that might be in between them.

Fix: Make TOPS20 TCP pickier about what it considers echoing.
In addition to there being only a few characters in the
buffer, have it insist that the retransmission queue for
that connection be empty. (If a person types faster than
the Round trip times, it won't hurt to have his echoing
clumped together a little anyway.) This is much simpler
than having the TCP repacketize retransmissions.

The relevant code is in TVTSRV, just before OPSCA7:
[This is from 6.1 sources. There should be an easy
equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ]

SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT
JRST OPSCA7 ; No.
IFE STANSW,<
MOVX T1,^D200 ; The function to queue for PZ if a lot
MOVX T2,<XCDSEC,,ENCPKT> ; to send - wait a bit, maybe more
CAIGE T4,^D8 ; Less that 8 is echoing so
MOVX T2,<XCDSEC,,FRCPKT> ; Force it now
CALL (T2) ; See Note above
>;IFE STANSW
IFN STANSW,< ;;; there is not going to be any more output if all of the
;;; output buffers are full, so send packets immediately.
CALL TTSOBF ;output buffer full?
CAIGE T4,^D8 ; or looks like echoing.
SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now
MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
LOAD T1,QNEXT,<+TCBRXQ(TCB)> ;check if retranmission queue empty?
CAIE T1,TCBRXQ(TCB) ;skip if RXQ empty
CAIL T4,^D8 ; or if a large packet
TRNA
MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
MOVEI T1,^D200 ; for a couple hundred millisecs.
CALL (T2) ;call appropriate packet routine.
>;IFN STANSW
OPSCA7: MOVE T2,LINADR ; Restore address of terminal block
OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT
-------
17-Jan-86 14:25:12-PST,916;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 17 Jan 86 14:24:46-PST
Date: Thu 16 Jan 86 22:37:57-PST
From: Mark Crispin <MRC%[email protected]>
Subject: front end cache memory
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12175874812.10.MRC@PANDA>

Minntronics Corp, 2599 White Bear Ave., St Paul MN 55109, (612) 770-5247
sells their model 8040AP Cache memory for the PDP-11/40 front end in a
DECSYSTEM 10 or 20. They claim a 33% performance improvement on the front
end, software transparency, and otherwise no effect on the system. They
offer a 2 week free trial. Apparently they just discovered the 10/20
market.

I have no relation to Minntronics; I just visited their booth at DEXPO
and remembered that people asked about their product.
-------
17-Jan-86 16:38:05-PST,548;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 17 Jan 86 16:38:01-PST
Date: Fri 17 Jan 86 16:40:37-PST
From: Kirk Lougheed <[email protected]>
Subject: HLP:DOVER.HLP
To: [email protected]

I've updated the Dover help file to more accurately reflect the state of
Dover support these days. It mentions the three Dovers and it reflects
the fact that SWITCH.INI is no longer used.

If anyone has something better, or wants to do a better job, let me know.

Kirk
-------
17-Jan-86 17:21:10-PST,655;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 17 Jan 86 17:21:06-PST
Date: Fri 17 Jan 86 17:23:39-PST
From: Bill Palmer <[email protected]>
Subject: new version of GETLOC
To: [email protected]

I improved the GETLOC module for FINGER and friends somewhat so that when
confronted with a connection from a TCP-based ethertip, it goes through
the same machinations as with a pup connection, rather than just printing
[36.40.0.85] or whatever. Relinking with this new GETLOC should fix
FINGER, TTYLOC, WIZARDS, etc. It can be found in <FINGER.SOURCES> on
Sierra.

Bill
-------
18-Jan-86 00:42:13-PST,1061;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 18 Jan 86 00:42:04-PST
Date: Sat 18 Jan 86 01:42:36-MST
From: Jay Lepreau <[email protected]>
Subject: Re: SYN with a window size of zero
To: [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[USC-ISI.ARPA]16-Jan-86 21:44:33.CERF>
Message-ID: <[email protected]>

This recently came up in another context: the TAC's put garbage in the
window field in their initial SYN, all the way up to 64K. This raised
havoc with some of our hosts which remembered the max window size they'd
ever seen. I talked to the TAC folks at BBN who maintained that since
the window is only defined relative to the ack seq number, the window is
meaningless unless ACK is set, and therefore it's not their bug, it's
ours. Sounds plausible, so we fixed it here. (A zero initial window
is quite good behavior, in contrast with the TAC's, which are clearly
violating the robustness principle.)
-------
18-Jan-86 01:13:05-PST,693;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 18 Jan 86 01:12:47-PST
Date: Sat 18 Jan 86 00:24:44-PST
From: Mark Crispin <MRC%[email protected]>
Subject: TOPS-20 EGP implementation
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12176156395.8.MRC@PANDA>

An implemention of the Exterior Gateway Protocol (EGP) now exists
for TOPS-20. This allows a multi-homed TOPS-20 system to be used as an
Internet gateway in the brave new world that no longer allows "dumb"
gateways. Interested parties should contact me.

-- Mark --
-------
19-Jan-86 12:38:55-PST,685;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 19 Jan 86 12:38:52-PST
Date: Sun 19 Jan 86 12:41:34-PST
From: Kirk Lougheed <[email protected]>
Subject: bugfix to TFTPSR
To: [email protected]

I've fixed the bug in TFTPSR that caused it to not timeout inactive
connections, which eventually resulted in a hung server. TFTPSR is
used to boot configuration files for SUNBOOT13, version 4.2 and greater.
If you have a -20 that is booting configuration files, you must install
this new version of TFTPSR.

The binary is SYSTEM:TFTPSR.EXE, the source is PS:<TCP>TFTPSR.MAC.8, both
on Sierra.

Kirk
-------
20-Jan-86 22:21:39-PST,647;000000000000
Mail-From: BILLW created at 20-Jan-86 22:21:35
Date: 20 Jan 1986 22:21-PST
Sender: [email protected]
Subject: Re: new version of GETLOC
From: William "Chops" Westfield <[email protected]>
To: [email protected]
Cc: [email protected]
Message-ID: <[SU-SCORE.ARPA]20-Jan-86 22:21:35.BILLW>
In-Reply-To: The message of Fri 17 Jan 86 17:23:39-PST from Bill Palmer <[email protected]>

I made some more modifications to TTYLOC:

Have the new TVT code pay attention to GL%DES (description only) flag.

Add a $RMREL in NAMTVT or some such - prevents [36.8.0.60].#Internet

The sources at sierra have been updated.

BillW
21-Jan-86 09:28:43-PST,1315;000000000000
Return-Path: <[email protected]>
Received: from cu-arpa.cs.cornell.edu by SU-SCORE.ARPA with TCP; Tue 21 Jan 86 09:27:53-PST
Received: by cu-arpa.cs.cornell.edu (5.31/4.30)
id AA14957; Tue, 21 Jan 86 12:29:51 EST
Date: Tue, 21 Jan 86 12:29:36 est
From: [email protected] (George R. Boyce)
Message-Id: <[email protected]>
Received: by gvax.cs.cornell.edu (4.30/4.30)
id AA00457; Tue, 21 Jan 86 12:29:36 est
To: [email protected]
Subject: V6.1 distribution

I finally got my source distribution and a have a few flames/questions.
In fall of 84 and spring of 85, at DECUS, I was told I'ld receive the
distribution around early November. That was considered a safe date by
the nervous digital spokesperson... Not even he thought that it would
take longer than that. Well, here are the dates I see on my material:

exec tape written: 08/27/85
exec letter dated: 09/05/85
mon letter dated: 09/05/85
rsx20f letter written:09/05/85
mon tape written: 09/20/85
rsx20f pack written: 12/05/85
received by shipping: 12/11/85
expected delivery: 01/17/86
received: 01/21/86

Am I missing something or did this process take an unreasonable amount
of time??

george Boyce, Cornell Computer Services, george@cornell
21-Jan-86 12:08:23-PST,469;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Jan 86 12:05:37-PST
Date: Tue 21 Jan 86 13:06:46-MST
From: Randy Frank <[email protected]>
Subject: Re: V6.1 distribution
To: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

I think it's called what happens when a vendor has written off a product.
-------
21-Jan-86 18:31:23-PST,902;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 21 Jan 86 18:27:30-PST
Date: Tue 21 Jan 86 18:22:34-PST
From: Stu Grossman <[email protected]>
Subject: Re: V6.1 distribution
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: Message from "Randy Frank <[email protected]>" of Tue 21 Jan 86 14:11:12-PST

Actually, its an artifact of the SDC (Software Delay Center). This is the
group within DEC that has to bless all tapes before they get shipped to
customers. Supposedly, they do the tape copying and final shipment. In
reality, they just sit on the tapes for at least one fiscal quarter, and
then send the originals back to Marlboro where the actual distribution
copies are promptly made. Note that the last part of this process only
occurs for LCG tapes.
Stu Grossman
-------
22-Jan-86 18:08:39-PST,639;000000000000
Return-Path: <[email protected]>
Received: from cu-arpa.cs.cornell.edu by SU-SCORE.ARPA with TCP; Wed 22 Jan 86 18:04:43-PST
Message-Id: <[email protected]>
Received: by cu-arpa.cs.cornell.edu (5.31/4.30)
id AA16734; Tue, 21 Jan 86 19:05:39 EST
To: [email protected]
Subject: tops-20 V6.1 distribution
Date: Tue, 21 Jan 86 19:03:51 -0500
From: [email protected]

And on top of the 4+ months it took to get the exec/monitor source
distribution, it of course arrived without monsym and macsym. Sigh.

George Boyce, Cornell Computer Services, george@vax[1234].ccs.cornell.edu
24-Jan-86 00:04:08-PST,647;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 23 Jan 86 23:59:34-PST
Date: Fri, 24 Jan 1986 01:02 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To: [email protected]
Subject: Semi-automated BUILD

I know of MIT's OPEN package and SUBDIR. What do you or your
administrators use to set up login directories other than BUILD?
Points to sources welcome! If there is sufficient interest, I'll
summarize your replies and make whatever source I collect available
(with the authors' permission, of course).

Thanks,
Frank
24-Jan-86 05:58:27-PST,2767;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 24 Jan 86 05:58:14-PST
Date: Fri, 24 Jan 1986 07:29 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: MRC%[email protected], [email protected]
Cc: [email protected]
Subject: Twenex domain resolver
In-reply-to: Msg of 20 Dec 1985 14:42-EST from Mark Crispin <MRC%[email protected]>

I just happened to be digging through the TOPS-20 mail archive (trying
to figure out why the spiffy new TCP code we stole from you and other
people is consistently hanging solid in the IP fork), and happened to
notice that Mark had forwarded my flame about domain resolver lossage
here. So an update seems in order.

I have been in touch with Mockapetris again recently. I understand
from him that you people have 6.1'ified GTDOM, but I don't know how
current you are or if you are running a resolver. Anyway, Paul says
he is about ready to release this thing publicly (I think he may even
mean it). In the last few days he has fixed several major standing
bugs, including one that was causing XX to emulate a yoyo earlier this
week (deadly embrace in the locking code, triggered by environmental
conditions like cache timeouts). He also fixed the bug I mentioned to
Mark earlier where the resolver was throwing legal packets on the
floor. I don't have this stuff up yet, but XX was running tolerably
well (until this week) even with a number of major bugs in this code,
so with a little bit of luck the new code will at least be runable
without constant care and feeding. As an added bonus, he just added
support for MX entries, complete with (sez he) a frob to generate MXs
from MDs and MFs. Haven't seen this part yet.

I expect to have the current stuff up on XX within the next week. If
you are interested I will let you know how it goes.

While I am blathering.... Quite a while back I rewrote a then-current
copy of GTDOM.MAC to use IFSKP./ENDIF. and DO./ENDDO. rather than
Paul's rather amusing coding style. I am now in the process of
(groan) merging his bugfixes into my code (to be fair, he has cleaned
up a lot from the version that got me disgusted enough to rewrite
it). Anyway, once this mess settles down a bit, would you people be
interested in using the structured version? I despair of ever getting
Paul to distribute it, the one time I tried to talk to him about it he
started on about paging characteristics of structured code. But I
suspect that if Stanford and MIT are both promoting a more reasonable
version the majority of sites would use it ("Help stamp out labels in
literals!"). Let me know if you are interested in this.

--Rob
24-Jan-86 10:47:21-PST,1139;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 24 Jan 86 10:43:21-PST
Date: Fri 24 Jan 86 10:09:42-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: Twenex domain resolver
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12177835749.9.MRC@PANDA>

Rob -

I certainly am interested in a 5.4 version of your code for the
PANDA monitor. Sooner or later, Milnet and DREnet will adopt domains.
How stable is your 5.4 code?

I don't understand what Mockapetris has against structured code.
If anything, it should have better paging characteristics than code
using lots of literals; of course, this makes more of a difference on
machines like the SC30M than a KL10.

I'll lobby around Stanford for adoption of your code. SUMEX is
the last 5.3 holdout, but will be migrating to 6.1 real soon. I hope
that the 6.1 changes to GTDOM are under a REL6 flag...

-- Mark --
-------
24-Jan-86 20:11:04-PST,2025;000000000001
Mail-From: HEGARTY created at 24-Jan-86 20:10:47
Date: Fri 24 Jan 86 20:10:47-PST
From: Paul Hegarty <[email protected]>
Subject: Common File System Login capability
To: [email protected]
Message-ID: <[email protected]>

Last August, I made modifications to our 6.1 Monitor to allow the "login
structure" (that is to say, the structure which contains login directories) to
be on a disk pack other than "PS:". System boot-up and swapping do NOT occur
on this pack, only logins. Since we have run this software for 5 months
without mishap (with 8000 users across 3 systems), and since DEC may not be
offering something similar for a while, I want to make it generally available.

The obvious purpose of this is to allow for CFS sites to give each user ONE
directory which he can log into from any of the systems. The boot-up pack
need only have the 17 or so basic directories and a total of about 30 files
(including catastrophe files if you keep your SUBSYS and most of your SYSTEM:,
etc. on the common structure).

Only the monitor changes need be made (there are no EXEC or Galaxy hacks).
All user software works under this scheme save for ones which use
HRLI AC,540000 constructs (instead of RCDIR) to find login directories.
Also, PS: can be defined to be either the login structure OR the boot-up
structure, so, whichever way you define it, programs that use "PS:" and mean
the other structure will obviously not work. Note that if you define PS: to
be the user structure, Galaxy will break (since it so graciously uses
PS:<SPOOL> instead of SPOOL: or some such). Mail works as long as you point
POBOX: to the login structure and get the latest version of MM.

The sources are in [SU-SIERRA]PS:<HEGARTY.CFS>. There is documentation as
well as REDIT files. Note that two of the changes only apply to Stanford
Monitors (re: Unix style directory naming).

Feel free to contact me (Hegarty@Sierra) with questions or suggestions.

... Paul
-------
24-Jan-86 22:41:06-PST,2591;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Fri 24 Jan 86 22:40:57-PST
Date: Sat, 25 Jan 1986 01:39 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: Mark Crispin <MRC%[email protected]>
Cc: [email protected], [email protected]
Subject: Twenex domain resolver
In-reply-to: Msg of 24 Jan 1986 13:09-EST from Mark Crispin <MRC%[email protected]>

My 5.4 code is pretty much the same functionality as Paul's 5.0 code
(modulo his recent bugfixes which I am currently installing). The one
major bug I know of is that the wait loop for the resolver has to run
NOINT, which means that you lose big if the resolver ever goes away or
hangs. It has to run NOINT because there are some resources in the
shared database which GTDOM% has locked down while it is waiting for
the resolver; most of these locks could probably be dispensed with
(with some work), but the cache lock is a problem. The resolver
passes back pointers to RRs in the cache, and for this to work the
process receiving the pointers has to already hold a read lock on the
cache (which the resolver carefully ignores when it gets its write
lock!), since otherwise the cache gc process (when it exists) could
slip in that window and do something that invalidates the pointer. I
don't know of any way to really fix this and still use the shared
memory idea, which would put us back with VAF's idea of having
GTDOM/.GTHST use IPCF to talk to the resolver, which is kind of high
overhead. My current plan is to install this kludge (purely as a
workaround, I hasten to add) where the resolver wait loop (which is a
busy wait, not a DISET) will also check INTDFF to see if there is an
interrupt trying to happen (ie, check if INTDFF<>SOS INTDF or whatever
the cannonical value is). I really don't like this idea, so if you
have a better one, holler.

I could repeat Paul's ideas on paging but I don't think they are
relevant. I think the real issue with Paul's assembler code is just
that he doesn't believe there is such a thing as elegant assembler
code so he doesn't try. It is pretty easy to see which parts of
GTDOM were written by Paul and which by Wook.

I'll send another message to this list when I get my version up to
what Paul is currently distributing. I'm not going to have much more
time for hacking this in the near future, since it looks like I am
taking over maintanence of COMSAT and getting it to grok domains, but
we can work something out.

--Rob
25-Jan-86 21:27:09-PST,1882;000000000000
Return-Path: <[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Sat 25 Jan 86 21:26:51-PST
Date: Sun 26 Jan 86 01:30:09-AST
From: Peter Gergely <[email protected]>
Subject: New version of CHKBBD available
To: [email protected]
Reply-To: [email protected]
Postal-address: 9 Grove St., P.O. Box 1012, Dartmouth, NS B2Y 3Z7, Canada
Phone-Number: (902) 426-3100 x 215 [8:30am to 4:15pm Atlantic time]
Message-ID: <[email protected]>

For all of you that use CHKBBD (check bulletin board IDX files), to
clean up your BBOARD database entries, there is a new version available.
It can be FTP'ed ANONYMOUSly from DREA-XX on <ANONYMOUS>CHKBBD.MAC. New
features include:

- a FORMAT subcommand and/or switch with keywords NORMAL, USER,
BRIEF which result in the NORMAL display; one showing a USER,
his read time and the file on a one line entry; and just the
number of readers respectively

- an OUTPUT subcommand and/or switch which allows an output file
to be given

- a DAYS subcommand and/or switch which allows you to remove
entries whose last read date is older than the current date
minus the number of DAYS given (default 366 days).

- a DATE subcommand and/or switch which allows you to specify an
exact date for entry extinction (see DAYS).

- Complete cleanup of .IDX files whose corresponding mail file
is empty, nonexistant, or deleted. This leaves the .IDX file
with 0 length.

If you pick it up you will also need <SUBSYS>PJGSYM.*, and possibly
<SUBSYS>CMD.* to compile it and make modifications. Please let me know
if you do grab the file, as I would like to maintain an update list,
rather than bother the whole TOPS-20 list. CHKBBD will also accept an
indirect file for input (useful for keeping a list of active bboards).

- Peter
-------
27-Jan-86 15:28:01-PST,651;000000000000
Mail-From: BILLW created at 27-Jan-86 15:27:57
Date: Mon 27 Jan 86 15:27:57-PST
From: William "Chops" Westfield <[email protected]>
Subject: new 6-1-setspd
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

I added an INHIBIT keyword to the TERMINAL command of SETSPD.
This sets the TTNTM bit in the terminal data, which is essentially
a REFUSE ALL MESSAGES bit in static storage, and can be used
to prevent terminals that should NEVER receive sends (such
as the APS on Score) from getting screwed.

Source code (not yet tested) on sierra in <6-1-sources>SETSPD.MAC

BillW
-------
28-Jan-86 22:24:40-PST,376;000000000000
Return-Path: <[email protected]>
Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Tue 28 Jan 86 22:24:31-PST
Date: Tue 28 Jan 86 22:27:07-PST
From: Bob Albrightson <[email protected]>
Subject: xns
To: [email protected]

I am looking for an implementation of NS for tops20. Does anybody know
where I can find such a beast? -thanks.

-bob
-------
29-Jan-86 15:48:10-PST,617;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 29 Jan 86 15:48:06-PST
Date: Wed 29 Jan 86 15:49:55-PST
From: Kirk Lougheed <[email protected]>
Subject: bboard program
To: [email protected]

The file PS:<SU-UTILITIES>BBOARD.DREA is the latest version of BBoard
from DREA, incorporating some changes/fixes/whatevers from UTEXAS-20.
It appears to be pretty close to the BBOARD.MAC that we're running here.
If anyone is interested in checking it out and possibly making the DREA
version be the Stanford version, please do so.

Kirk
-------
31-Jan-86 14:47:48-PST,1999;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 31 Jan 86 14:47:33-PST
Date: Fri 31 Jan 86 17:50:56-EST
From: Thomas De Bellis <[email protected]>
Subject: EXEC problem with use of private Galaxy
To: [email protected]
Message-ID: <[email protected]>

Recently, I was testing out a new version of Galaxy here at the
Columbia Computer Center. The testing was going on in GLXLIB
`private' mode so I wouldn't interfere with normal system usage. In
particular, I was checking out some code that I had added to MOUNTR at
the request of our operations department. I issued a cancel command
to throw out a test mount request that I had queued and boy was I ever
surprised to find out that my job wedged! My changes were so small...

It turns out after a lot of detective work that the bug of my EXEC
hanging in private Galaxy mode is, in fact, an EXEC bug and a rather
old one at that. I have verified that it exists in current 6.1
sources.

Briefly, when you go into private Galaxy mode, the EXEC goes through
some logic to get the PID of the private Quasar that you are running
so that you can exchange IPCF messages with it. Unfortunately, when
you are doing mount'ish things, you can also get messages from the
moby device animal but the EXEC never bothers to find this private PID
out. Thus, you are left with the situation where QSRPID points to a
private Quasar (like it should) and MDAPID is left pointing to the
system MOUNTR (like it *shouldn't*). When messages come in from the
private MOUNTR, they are not recognised as such and they are tossed by
the EXEC and you hang. Neat huh?

The EXEC changes are pretty minimal. If any of you are scratching
your heads about this, drop me a note and I'll mail them to you. They
are for a 5 EXEC, but are trivially tailored to a 6 EXEC.

-- Tom De Bellis
Columbia Computer Center
-------
3-Feb-86 16:41:12-PST,2495;000000000001
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Feb 86 16:41:01-PST
Date: Mon 3 Feb 86 18:12:40-CST
From: Clive Dawson <[email protected]>
Subject: IPNIDV patch to prevent IPGHTF's.
To: [email protected]

Symptom: IPGHTF BUGINF's and failure to establish network connections.

Diagnosis: IPGHTF's indicate that the ARP tables (pointed to by GHTAR1
and GHTAR2) are full. The recommended action is to increase
the size of these tables by upping NIMAXH. Unfortunately,
this will not always solve the problem. We had NIMAXH set
to 200. and a network with only about 100. hosts. Inspecting
the table pointed to by GHTAR1 revealed that each host had
multiple (as many as 5 or 6) entries, causing the table to
fill up prematurely. This led to the discovery of a bug
which was introduced when a binary search algorithm was added
to speed up ARP table searching. In particular, when the
binary search exits with failure, T1 and T2 are supposed to point
to the table locations where the new entry can be inserted.
This is only true half the time, when the last entry examined
is .gt. the target. When the last entry examined is .lt. the
target, the appropriate insertion point should be one greater.

Cure: At ISRCH+10 in IPNIDV.MAC, change

CAMG T2,(T1) ;HOST # .GT. MIDDLE ?
IFSKP.
MOVEI P1,1(P2) ;YES. LOW = MIDDLE + 1
JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED
ENDIF.
JUMPE P2,ISNFND ;IF MIDDLE IS ZERO, DONE - NOT FOUND

to:

CAMG T2,(T1) ;HOST # .GT. MIDDLE ?
IFSKP.
MOVEI P1,1(P2) ;YES. LOW = MIDDLE + 1
AOS T1 ; Adjust T1 & P2 to point to correct the
AOS P2 ; insertion point in the case where
; the last entry examined is .LT. host.
JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED
ENDIF.
JUMPE P2,ISNFND ;IF MIDDLE IS ZERO, DONE - NOT FOUND

This patch was apllied to our 5.4 monitor and all is working fine.
Examination of the sources for TCP/IP-20 Version 4.0 reveals the
same problem, so this patch should apply to 6.1 as well.

Cheers,

Clive

P.S. Here's a small addition to TOPS-20 folklore: A messed-up ARP table
(either due to the above bug or to host address changes) can be
fixed on the fly with no apparent ill effects by entering MDDT and
setting GHTCNT to 0.
-------
3-Feb-86 22:17:07-PST,918;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Feb 86 22:16:56-PST
Date: Tue 4 Feb 86 00:22:03-CST
From: Clive Dawson <[email protected]>
Subject: Initializing the ARP table
To: [email protected]

Regarding my bit of folklore in a previous message, Chuck Hedrick just
reminded me of the "ETHERNET INITIALIZE (ADDRESS MAPPING FILE)" command in
IPHOST. Hopefully safer, it will, however, deprive you from experiencing
that exquisite split-second between typing carriage return to MDDT and
knowing you've avoided a BUGHLT. (Anybody have a good Sniglet* for that?)

Clive

(*) (TM) For those who don't know, a Sniglet is any word that doesn't
appear in the dictionary but should. A good example in this case is
IGNISECOND, the overlapping moment of time when the hand is locking the
car door even as the brain is saying "my keys are in there!"
-------
4-Feb-86 04:43:41-PST,2709;000000000000
Mail-From: BILLW created at 4-Feb-86 04:38:11
Date: Tue 4 Feb 86 04:38:11-PST
From: William "Chops" Westfield <[email protected]>
Subject: results of tonights hacking... (TCP stuff).
To: [email protected]
Message-ID: <[email protected]>

It turns out that the tops20 retransmitter seems to run a lot more
often than it should. In particular, it gets signaled to run whenever
an ACK is received (in REMSEQ) AND/OR whenever "packets previously
made untransmittable ...become transmittable". The time interval used
in these cases was either the next retransmission time as calculated by
the "packet last transmitted time" plus the "packet rexmit interval".

Unfortunately, the retransmission scheme used to probe a 0 window sets
the next time to run the RX process a long ways (2 minutes) away, but
does NOT update the packet retransmission interval. Thus what happens
when output is sent to an ethertip that has returned to its exec is
that the probe packet is retransmitted at whatever the last
retransmission interval for that connection was (typically 300 ms or
so), and the tip responds with an ACK for old data and a 0 window,
which causes REMSEQ to signal RX again, completely bypassing the long
retransmission interval that should be used for the 0 window probe.

In addition, the second piece of code (I haven't quite figured out
what it THINKS it's doing yet), appears to contain some sort of
fencepost error, as RX is frequently started up on a TCB, only to
decided that it doesn't have any packets to retransmit! More
wasted cycles. I plan to look into this further.

So. I added code to avoid signaling RX when the send window
is 0. This appears to cause the system to behave much more
reasonable for this case. I also believe that this code
will properly fail to timeout a connection when the send
window is zero, but that has not been extensively tested.

The new code is on Score in <6-1-MONITOR> (in TCPTCP). This version
also contains new code for scanning TVT output - it looks at a bitmap
instead of carefully locking and examining the dynamic data for ALL
the TVTs each time (in TVTSRV). It seems to work fine. (What
happened to <6-1-exp-mon>? Well, that contains the REALLY new
stuff (it doesn't even compile yet.)

The (un)special handling of DEC TCP buffers with respect to
not thrashing page tables is now also in this TCPTCP (it has
been in <6-1-exp-mon>, and running on Score and Sushi for
some time now, without any apparent problems).

For kicks, Score also contains a runtime patch to count the times that
RX decided is didn't have anything to do after all in REXABT.

Enjoy
BillW
-------
5-Feb-86 15:15:17-PST,1223;000000000000
Return-Path: <BUDD%BUCS20%[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Feb 86 15:14:38-PST
Received: from bostonu by csnet-relay.csnet id ab15094; 5 Feb 86 16:19 EST
Received: from BUCS20 by bu-cs.ARPA (3.0/4.7)
id AA29434; Wed, 5 Feb 86 14:41:08 EST
Date: Wed 5 Feb 86 14:40:02-EST
From: Philip Budne <BUDD%BUCS20%[email protected]>
Subject: TOPS-20 RSHD/RMT
To: tops-20%[email protected]
Message-Id: <12180997923.21.BUDD@BUCS20>

I have written a Un*x style RSHD (Remote Shell Daemon), that uses proxy
login on a TVT to provide a remove command interpeter. I have been
trying to implement an RMT (remote tape protocol) server under TOPS-20
so that we can make better use of the '20s TU78.

RMT is a program running on a TVT (with every terminal mode bit
frobbed that I could think of), listening for tape commands. The BSD
rdump program connects up, issues an open and a write for 10240
characters. (ie; "W10240\n.....). However, we lose data, and the RMT
hangs waiting for the rest of the block.

Systems: TOPS-20 5.4(1025) vs. SUN/3 3.0, 11/750 BSD 4.2, SUN/2

Any guesses to why the data lands on the floor?
-------

5-Feb-86 15:47:58-PST,1990;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Feb 86 15:47:43-PST
Date: Wed 5 Feb 86 17:52:26-CST
From: Clive Dawson <[email protected]>
Subject: Another ARP patch
To: [email protected]

Another bug in the ARP table updating routines has been uncovered.
Here's another patch which should be applied together with the one
I sent out a couple of days ago.

SYMPTOM:
ARP table messed up. Entries out of order and extraneous 0 entries.
Monitor will at the very least generate a lot of unnecessary ARP
traffic.

DIAGNOSIS:
When the ARP search routine fails to find an entry, it returns a
pointer which tells where to insert the new entry. Sometime later
the actual update takes place, and the monitor carefully goes
NOSKED to make sure nobody else tries a simultaneous update.
However, updates may have already taken place by this time, making
the pointer returned by the previous search invalid.

CURE: After going NOSKED, call the search routine again to make sure
the insertion pointer is valid.

In IPNIDV.MAC, at ARPUPD+3, change:

NOSKED ;DON'T LET OTHERS INTO THE GHT
MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE

to:

NOSKED ;DON'T LET OTHERS INTO THE GHT
MOVE T2,SPADR ;Get internet address
CALL INTSRC ;Search table again to ensure pointer is valid
SKIPA ;Not found, as expected
JRST [OKSKED
RET] ;Aha! Somebody else did it for us
MOVEM T1,AREA1 ;Save insertion pointers
MOVEM T2,AREA2 ;...
MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE

................

BTW, I'm also a bit concerned about the following code at the
end of ARPUPD:

OKSKED ;TABLE IS SAFE NOW
MOVX T1,GH%ARP ;GET UPDATED BY ARP FLAG
IORM T1,GH.GCF(T3) ;SET IT IN THE GHT
RET

It seems to me that the flag should be set *before* going OKSKED, since,
again, there is a possibility that another update will happen and
the pointer in T3 will be invalid.

Clive
-------
5-Feb-86 18:39:40-PST,538;000000000000
Return-Path: <[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Feb 86 18:39:29-PST
Date: Wed 5 Feb 86 18:17:08-PST
From: Bruce Tanner <[email protected]>
Subject: PCL
To: [email protected]
Message-ID: <[email protected]>

While building a PCL exec from the tools tape, I noticed that no PCL
documentation was included. If the 6.1 PCL is different from the 5.1
version, does anybody have the new documentation? Also, why no source code?

Thanks,
-Bruce
-------
6-Feb-86 08:52:03-PST,4988;000000000000
Return-Path: <RJONES%[email protected]>
Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 08:51:47-PST
Received: from (MAILER)UDCVM.BITNET by WISCVM.WISC.EDU on 02/06/86 at
10:13:33 CST
Return-path: [email protected]
Received: by UDCVM (Mailer X1.23) id 6375; Thu, 06 Feb 86 10:37:41 EST
Received: by UDCVM (Mailer X1.23) id 4115; Tue, 04 Feb 86 18:10:07 EST
Date: Tue, 4 Feb 1986 16:12 EST
From: Rob Jones <RJONES%[email protected]>
Subject: Minntronics Cache for KL FE
To: <ITTAI@NYU>
CC: <[email protected]>

We recently installed the Minntronics memory cache in the Front End 11/40
of our 2065. We did this as a experiment to determine if we could add to
the throughput capability of the FE under heavy terminal loads. The cache
installs very easily, Field Service did the installation for us and charged
the usual 2 hour minimum, though we had to pay for an additional 3 hours as
a result of some complications I will describe later.

We became aware of the product as a result of seeing it at work
in a DN2xx remote station on a DEC10 ANF10 network. A local DEC10 site
has been using it with 11/40s and Emulex DH emulators (CS11) successfully
for quite a few years without ever replacing it. The DEC10 site had done
some benchmarking and found that the cache increased the throughput of the
11 by about 30%. We are using the Emulex CS11 in our FE on the DEC20 and
have not had any trouble at all with it. We support 32 lines with one
Unibus slot in the FE box in addition to the 96 lines we have on the usual
DHs. That worked so well that we decided to try the cache.

Getting the cache installed and testing it took a little doing. At first
we did not know how to coordinate this through DEC FS. So we just went ahead
and installed it ourselves. The cache worked fine for about a day and then
it died from infant mortality. We pulled it out, put back the Unibus jumper
and breathed a sigh of relief when the system booted without further trouble.

The local DEC FS manager then educated us about the advantages of having them
do such installations. They were quite supportive of the project.
We returned the cache and arranged for another installation, this time with
DEC FS and the local Minntronics people in attendence. Unfortunately, the
system would not boot with it inplace. There is a switch on the cache which
isolates it electronically from the Unibus, and it had no effect on the boot
problem, so we figured that we had a DOA board. We sent it back and let the
project rest for a while.

This summer we had funds to purchase the Minntronics cache and decided to
tryd again. Unfortunately the arrival of the cache coincided with the
arrival of our MCA25 upgrade and the installation of the Minntronics was
deferred until our system became stable (-we had some trouble with the MCA25
installation). We kept asking DEC FS about installing the cache, and our CE
at the time was dragging his feet about it. Finally we had a change in CEs and
the new fellow was quite enthusiastic about it.

We made an attempt to get the new cache installed at the end of the fall
semester but the cache turned out to be defective, which cost us 3 hours of
FS charges for the FE diagnosis. The diagnosis was done because we couldn't
believe that we had another DOA board. So our CE got another DEC FS engineer
out here who had experience installing the same cache in the FE of a 1091.
He helped our CE shake out the FE, determining that it was in good shape and
that the cache was at fault.

We called Minntronics and got another module via overnight air express. It
was installed two weeks ago and the system has been running just fine.

You may be wondering "Does it speed up the FE?" I wish I could give you some
numbers, but the only evaluation I can give is subjective. Local terminals
seem to run "faster". But with our beginning of our spring semester rush we
have not had the time to do any benchmarks. We hope to be doing some benchmarks
within the next couple of weeks to see if the cache is doing anything for the
FE. I frankly do not expect to see a dramatic difference. From my discussions
with the DEC10 site systems people I feel that we will see a statistical
improvement under high terminal I/O loads, where the aggregate speed of I/O
will improve rather than users saying "Jeez, the system is faster!". By the
way, the only difference to the standard "B STRING" diagnostics was that one
of the KL clock tests complained that a KL clock was slow when running with
the cache active. The cache can be disabled in software, as well as by flipping
a little switch on its front panel. The DEC10 site has their 11 diagnostics
patched to disable the cache when running the memory diagnostics. Not having
sources, we can't do the same for our FS CE. If you are interested I will let
you know how our benchmarks turn out.
6-Feb-86 16:08:48-PST,972;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Feb 86 16:08:23-PST
Date: Thu 6 Feb 86 18:13:42-CST
From: Clive Dawson <[email protected]>
Subject: Features of TOPS-20 Version 7
To: [email protected]

Folks--
The DECUS Large Systems SIG is putting together some input for DEC
about what features/enhancements/fixes/cleanups they should include
in TOPS-20 version 7. Note that version 7 will likely be the last
official (DEC-released) version of TOPS-20, so this is really our
last chance to give them any input.

The only constraint here is that I need your comments *quickly*,
i.e. within a week. We were planning to give this sort of info to
DEC at Spring DECUS, but it turns out that it will fit into the
planning schedule much better if we give it to them this month.

Please send directly to me at CLIVE@MCC. I'll summarize the results
and post them on the list.

Thanks,

Clive
-------
8-Feb-86 15:20:47-PST,6898;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sat 8 Feb 86 15:20:28-PST
Date: Sat 8 Feb 86 18:26:30-EST
From: Charlie C Kim <[email protected]>
Subject: DEQNAs and NI-20s - an update
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

In a previous message, a problem with communications between TOPS-20
and DEQNA based systems was reported. After further experimentation,
the following has been found.

First, let's emphasize that the problem probably extends to any
system which sends an ARP packet of size 64 or larger (tested on
DEQNA and DECNA (CTI bus)).

Second, though a minimum packet size of 60 on the DEQNA seems to
present a number of problems, a packet size of 62 seems to work
okay.

Third, the solution of using the internet to ethernet mappings
file doesn't work too well when the DEQNA based system is a
SUBARP gateway; this means that you have to put every host on
the other size of gateway in this file!

Fourth, the idea of modifying TOPS-20 to accept ARP packets of
size 64 isn't very good since it is already supposed to do that!
The following describes the problem with TOPS-20.

Problem: The ARP "portal" on TOPS-20 is configured to receive
packets of size 64. Though packets of this size are received,
they seem to be corrupt by the time they reach the IPNIDV
routines. Packets of sizes 60 and 62 are received correctly.
The packets are known not to be corrupt; this is based upon
correct functioning with other systems and actually watching ARP
packets go by on the network. See end for examples of the
corruption.

Diagnosis:

In IPNIDV, AR.WRD is the number of words in a ARP buffer and
AR.MAX is the number of bytes in the buffer which is posted as
usable to the NI-20 for a receive. Both values exclude the
ethernet header. AR.WRD is set to <MINPKT/4>+4 words, AR.MAX is
to MINPKT+4 bytes, and MINPKT is 50 bytes. MINPKT is the number
of data bytes plus 4 bytes for the CRC. (The reasons for
including this in the data buffer isn't clear to me; I think it
has something to do with the internal loopback). The +4 for
AR.MAX is probably the fuzz factor (amount by which we are
willing to receive over the nominal specification). The +4 for
AR.WRD seems to translate into: 1 word for fuzz bytes, 1 word
for rounding, 1 word for the header, and 1 other word (reason
for allowing it not discernable).

AR.MAX specifies 54 bytes. Dropping the four bytes for the CRC,
this should be sufficient to handle an incoming 64 (50+14) byte
packet. AR.WRD seems to be large enough too (as a matter of
fact, it seems to be one word too large). Something goes wrong
though.

Possible the NI-20 driver (module PHYKNI) or NI-20 is
doing something wrong. (Maybe something wraps around????)

Solution: Maybe set ar.max to receive a 66 byte packet?

Appendix: The following information was obtained by reading the
ARP send buffers with XPEEK%. Though there can be no guarantees
to the validity of the data, it seems to be indicative of what
the NI-20 has received.

In the following, the first two packets were send from a DEQNA
based system and the third from a DECNA based system (CTI bus)
with packet sizes set to 62, 64, and 66 respectively. In the
dumps, there are 4 fields. The first is the starting byte. The
second is <left two bytes>,,<right two bytes> in octal. The
third is the 4 bytes in hex. The last is the four bytes in
decimal.

Send buffer with Request opcode, ethernet hardware
Protocol type: INTERNET
Source hardware address: 08-00-2B-02-68-23
Source protocol address: CU-CC.COLUMBIA.EDU (128.59.32.139)
Destination hardware address: 00-00-00-00-00-00
Destination protocol address: CUCCA.COLUMBIA.EDU (128.59.32.134)

Buffer dump:
1/ 4000,,0 08-00-00-00 8.0.0.0
5/ 1,,4000 00-01-08-00 0.1.8.0 ;Hardware type,,protocol
9/ 3004,,1 06-04-00-01 6.4.0.1
13/ 4000,,25402 08-00-2B-02 8.0.43.2
17/ 64043,,100073 68-23-80-3B 104.35.128.59
21/ 20213,,0 20-8B-00-00 32.139.0.0
25/ 0,,0 00-00-00-00 0.0.0.0
29/ 100073,,20206 80-3B-20-86 128.59.32.134
33/ 1507,,150627 03-47-D1-97 3.71.209.151
37/ 50020,,4000 50-10-08-00 80.16.8.0
41/ 46110,,0 4C-48-00-00 76.72.0.0
45/ 61543,,65400 63-63-6B-00 99.99.107.0
49/ 54040,,46101 58-20-4C-41 88.32.76.65
53/ 76602,,172574 7D-82-F5-7C 125.130.245.124
57/ 0,,0 00-00-00-00 0.0.0.0
61/ 0,,0 00-00-00-00 0.0.0.0

Send buffer with Request opcode, unknown hw type - 9491!
Protocol type: 0!
Source hardware address: 08-00-2B-02-34-7B
Source protocol address: CUCCA-WP.COLUMBIA.EDU (128.59.32.138)
Destination hardware address: 00-00-00-00-00-00
Destination protocol address: CU20B.COLUMBIA.EDU (128.59.32.128)

Buffer dump:
1/ 4000,,0 08-00-00-00 8.0.0.0
5/ 22423,,0 25-13-00-00 37.19.0.0 ;Hardware type,,protocol???
9/ 3004,,1 06-04-00-01 6.4.0.1
13/ 4000,,25402 08-00-2B-02 8.0.43.2
17/ 32173,,100073 34-7B-80-3B 52.123.128.59
21/ 20212,,0 20-8A-00-00 32.138.0.0
25/ 0,,0 00-00-00-00 0.0.0.0
29/ 100073,,20200 80-3B-20-80 128.59.32.128
33/ 30031,,314 30-19-00-CC 48.25.0.204
37/ 50020,,3776 50-10-07-FE 80.16.7.254
41/ 102546,,0 85-66-00-00 133.102.0.0
45/ 177775,,447 FF-FD-01-27 255.253.1.39
49/ 100073,,0 80-3B-00-00 128.59.0.0
53/ 1001,,65740 02-01-6B-E0 2.1.107.224
57/ 0,,0 00-00-00-00 0.0.0.0
61/ 0,,0 00-00-00-00 0.0.0.0

Send buffer with Request opcode, unknown hw type - 11301!
Protocol type: 0!
Source hardware address: 08-00-2B-02-30-6D
Source protocol address: PRO-CCK.COLUMBIA.EDU (128.59.32.38)
Destination hardware address: 00-00-00-00-00-00
Destination protocol address: CU20B.COLUMBIA.EDU (128.59.32.128)

Buffer dump:
1/ 4000,,0 08-00-00-00 8.0.0.0
5/ 26045,,0 2C-25-00-00 44.37.0.0 ;hardware,,protocol
9/ 3004,,1 06-04-00-01 6.4.0.1
13/ 4000,,25402 08-00-2B-02 8.0.43.2
17/ 30155,,100073 30-6D-80-3B 48.109.128.59
21/ 20046,,0 20-26-00-00 32.38.0.0
25/ 0,,0 00-00-00-00 0.0.0.0
29/ 100073,,20200 80-3B-20-80 128.59.32.128
33/ 177777,,0 FF-FF-00-00 255.255.0.0
37/ 177777,,0 FF-FF-00-00 255.255.0.0
41/ 177777,,0 FF-FF-00-00 255.255.0.0
45/ 177777,,0 FF-FF-00-00 255.255.0.0
49/ 177777,,0 FF-FF-00-00 255.255.0.0
53/ 177777,,0 FF-FF-00-00 255.255.0.0
57/ 0,,0 00-00-00-00 0.0.0.0
61/ 0,,0 00-00-00-00 0.0.0.0
-------
9-Feb-86 15:06:43-PST,1474;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 9 Feb 86 15:06:34-PST
Date: Sun 9 Feb 86 15:11:22-PST
From: Stu Grossman <[email protected]>
Subject: Re: DEQNAs and NI-20s - an update
To: [email protected]
cc: [email protected]
In-Reply-To: Message from "Charlie C Kim <[email protected]>" of Sat 8 Feb 86 15:56:13-PST

A receive buffer size of ^D50 bytes will allow ARP to receive a datagram
with a maximum of ^D46 bytes of 'user' data. The extra four bytes are
required for receive buffers because the NI-20 microcode wants to put the
datagram's CRC at the end of the data. At the time NISRV was written, it
was not possible to hide this from the higher layers (NISRV's callers),
that is why people have to make accomodations for the CRC (in receive
buffers only).

If an ARP datagram arrives that is too large to fit into the buffer, NISRV
will return the buffer with an error indication. ARP looks at this, and
rejects datagrams that are received in error. This occurs before any other
processing is done.

Is it possible that the DEQNA is transmitting a 'padded' datagram with a
length field at the beginning of the datagram?

Your best bet would be to capture the buffer as soon as possible inside
of ARP (at ARPCDR I think). Also be sure to note the length of the
datagram (as returned in field UNBSZ of the UN block).

Good luck,
Stu
-------
12-Feb-86 13:09:56-PST,550;000000000000
Return-Path: <[email protected]>
Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Wed 12 Feb 86 13:09:31-PST
Date: Wed 12 Feb 86 15:09:40-CST
From: [email protected]
Subject: Patches to run 6.1 EXEC on 5.x Monitor
To: [email protected]
Message-ID: <[email protected]>

Requesting patches for a 5.4 monitor to run 6.1 EXEC.
This will make testing our local changes to the EXEC much easier.
I recall someone from DEC saying there was a patch to do this.

Regards, Don K
-------
12-Feb-86 16:43:50-PST,712;000000000000
Return-Path: <[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Feb 86 16:43:40-PST
Date: Wed 12 Feb 86 16:43:32-PST
From: Bruce Tanner <[email protected]>
Subject: QUEUE% JSYS
To: [email protected]
Message-ID: <[email protected]>

Has anybody used the QUEUE% jsys? I wrote a little program to print a file
and I got no errors and no output request. The only thing I can get it to
do is give a "QUEUX3: Fatal error returned from application" if I ask for a
response to a response block. There must be something I'm doing wrong, but
I don't know what. Does anybody have a sample program that sends a print
request?

-Bruce
-------
12-Feb-86 17:55:56-PST,672;000000000000
Received: from LOTS-B by Score with Pup; Wed 12 Feb 86 17:55:40-PST
Date: Wed 12 Feb 86 17:51:50-PST
From: Paul Hegarty <H.HEGARTY%LOTS-B@LOTS-B>
Subject: Re: QUEUE% JSYS
To: [email protected]
cc: TOPS-20%Score@LOTS-B
In-Reply-To: <[email protected]>
Message-ID: <12182900616.203.H.HEGARTY@LOTS-B>

The QUEUE% JSYS does work (though its error messages are, to say the
least, unhelpful). I suspect that the reason it doesn't work for you
is that you are not specifying the FULL filename (all fields).

If you are interested in a sample program (which just prints a file),
just ask and ye shall receive ...

... Paul
-------
12-Feb-86 18:12:15-PST,1009;000000000001
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Wed 12 Feb 86 18:12:01-PST
Date: 12 Feb 1986 2108-EST
From: Bill Melohn <[email protected]>
To: [email protected], [email protected]
Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224"
Subject: Re: Patches to run 6.1 EXEC on 5.x Monitor
Message-ID: <"MS11(5116)+GLXLIB5(0)" 12182903551.11.108.6572 at MARLBORO.DEC.COM>
References: Message from [email protected]
of 12-Feb-86 1619-EST
In-reply-to: <[email protected]>

I believe you will find that the 6.1 EXEC will run successfully under 5.1
or 5.4. To run the 5.1 EXEC under 6.1, you need to patch the OWGBP at SYSLOS+27
(referenced at EXEC02+31) from 620200,,<whatever> to 160200,,<whatever>.
Otherwise due to the newer KL microcode you will get a section greater than 37
reference and the error TOPS-20 Command processor not properly initialized.

Bill
--------
13-Feb-86 03:16:18-PST,1202;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 03:16:11-PST
Date: Thu 13 Feb 86 00:08:50-PST
From: Mark Crispin <MRC%[email protected]>
Subject: LPTSPL and PLPT0:
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12182969246.8.MRC@PANDA>

LPTSPL doesn't assign its printer on a START command; it waits until there
is something to print. This leaves PLPT0:, etc. available for any random
process that wants to assign it.

Is there some magic command that I'm unaware of that would cause LPTSPL to
assign the printer right away? I'd also like to get BATCON to assign the
PTY's for each of its streams too.

It isn't crucial for my system, but for other systems I would imagine it
would be a security bug. This is also a rather old class of bug; I remember
when I was an undergraduate we used to screw the TOPS-10 LPTSPL by doing
"SYSTAT L" repeatedly to keep it from getting the printer.

DEC, are you listening? Is anybody still working on Galaxy who would
consider a "grab all resources you'd ever need now" command?
-------
13-Feb-86 03:46:03-PST,938;000000000001
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 03:45:56-PST
Date: Thu 13 Feb 86 00:19:42-PST
From: Mark Crispin <MRC%[email protected]>
Subject: DZ11 question for 2020's
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12182971223.8.MRC@PANDA>

Folks, my 2020 has 4 DZ11's for a total of 32 DZ11 ports. I'm using a
grand total of 5 lines now, of which only two are DZ11 ports (the other
three are the KLINIK, CTY, and DECnet lines). Right now I have TTY2 and
TTY21 wired up. TTY2 is a 4800 hardwire connected to a VT100 (that's why
it's 4800 instead of 9600!) while TTY21 is a 1200 baud dialup. I'm going
to add a 9600 Heath-19 soon.

My question is: am I really winning by using separate DZ11's, or would I
be better off having all my lines on a single DZ?
-------
13-Feb-86 03:46:19-PST,1764;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 03:46:04-PST
Date: Thu 13 Feb 86 00:37:12-PST
From: Mark Crispin <MRC%[email protected]>
Subject: TOPS-20 4.1 bug
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12182974408.8.MRC@PANDA>

If anybody on this list if running TOPS-20 4.1 (e.g. has a 2020)
you may want this fix. I SPR'd it to DEC several months ago, but apparently
if you don't have a software contract with DEC your SPR's get circular filed.
Obviously no software person even saw the SPR, since the bug is serious and
obvious (and the fix was included) and it still exists in Autopatch 12.

Problem: HNGU0F and HNGU1F functionality doesn't work in 4.1

Diagnosis: Person who added it doesn't remember how release 4 worked.
There was no RSI; all data that was loaded non-zero was in RSCOD.

Solution: In STG.MAC, replace:
RS HNGU0F,HNGU0
RS HNGU1F,HNGU1
with:
HNGU0F::HNGU0
HNGU1F::HNGU1
in a RESCD area. RESCD is write-allowed in release 4.1, unlike
release 5 and later.

Comment: I mentioned this to a few DEC people, who seemed fairly
perturbed that SWS would fail to pass on an SPR just because it wasn't
submitted by a paying customer. I took the trouble to fill in and mail
the SPR only because I thought DEC would like the bugfix. I don't expect
an answer, much less help in debugging a problem, but if I go to the
trouble of SPR'ing a bug and including the fix, I wish somebody would
take the time to look at it. In general, the TOPS-20 list has been more
effective in passing on bug reports to DEC than SPR'ing.
-------
13-Feb-86 14:03:43-PST,368;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Feb 86 14:03:21-PST
Date: Thu 13 Feb 86 15:47:14-CST
From: Clive Dawson <[email protected]>
Subject: DISCARD server
To: [email protected]

Do any sites out there have ECHO and/or DISCARD TCP servers running
on their TOPS-20 systems?

Thanks,

Clive
-------
14-Feb-86 20:36:37-PST,2564;000000000000
Return-Path: <herber%[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Feb 86 20:36:19-PST
Received: from bgsu by csnet-relay.csnet id ac04021; 14 Feb 86 23:21 EST
Received: by bgsuvax.UUCP (4.12/4.7)
id AA25374; Fri, 14 Feb 86 16:45:59 est
Date: Fri, 14 Feb 86 16:45:59 est
From: Steve Herber <herber%[email protected]>
To: "tops20%su-score.arpa" <@CSNET-RELAY.ARPA,@bgsu.CSNET:tops20%[email protected]>
Subject: Applying local patches with AUTOPATCH
Cc: herber%[email protected]

Does anyone have any experience (or success even) merging local edits
into AUTOPATCH'ed products using the COMPAR, MERGE and UPDATE utilities
in the <AUTOPATCH> directory? We have tried using COMPAR to produce
a file of local edits in 'AUTOPATCH' format from an original DEC source
file and a locally modified file. We then use the MERGE utility to
merge the local edits into the .Cnn file (nn is the Autopatch tape #)
for that particular product. When we then SUBMIT the .CTL file that
PEP uses to AUTOPATCH the product, we usually (depending on the
phases of the MOON, time of day, you get the idea...) get CHECKSUM
errors when UPDATE runs to apply one of the .Cnn AUTOPATCH file's
patches to the product.

For example:

(from the GALAXY-20-V4-2, AUTOPATCH tape 10 log)
@R ASL:UPDATE

**@PAT:GALV42.SUP
...
PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C06 <- this is the file that we
... used the MERGE utility to
... combine our local edits to
... MOUNTR.MAC.
PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C07 <- Worked OK here also
...
PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C08 <- Worked OK
...
PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C09 <- Worked OK
...
PAT:MOUNTR.MAC=ASL:MOUNTR.MAC,PAT:MOUNTR.C10 <- Here the UPDATE program
?UPDSUM Checksum error displays a checksum error
...

We have gone through a number of iterations with TOPS-20 telephone support
on this and they cannot tell us a valid way to merge local patches into
AUTOPATCHable products. There is of course, the good old "edit-the-file-
after-you-autopatch" method of applying local patches (UGH!!). I want to
automate this process as much as possible and what I keep hearing from
DEC is "If you don't have any local patches, you wouldn't have this
problem".

Thanks for the consideration.....

Steve Herber CSNET [email protected]
Sr. Systems Programmer UUCP ...!osu-eddie!bgsuvax!herber
Bowling Green State Univ.

15-Feb-86 13:19:26-PST,1036;000000000000
Mail-From: G.FUSSELL created at 15-Feb-86 13:19:15
Date: Sat 15 Feb 86 13:19:15-PST
From: Carl Fussell <[email protected]>
Subject: autobaud
To: [email protected]
Address: Santa Clara University
Message-ID: <[email protected]>

I was hoping someone on this list might have some experience with what
we are trying to do and can perhaps give us some advice.

We have just recently set up a facility that will permit our users
to dial in on remote lines at speeds up to 9600 baud. As a result,
we would like to set those lines to REMOTE AUTO. Has anyone else
been successful at this?

We are running a 6.0 monitor although withing a week or two, we will
be on 6.1 with new front end code. We just learned that autobauding
300/1200 is broke (it used to work before we ran 6.0 monitor) so that
probably explains 9600 not working. I am just wondering that if we
get the 300/1200 back, will autobauding up to 9600 be possible.

Thanx much for any information...

Carl
-------
16-Feb-86 11:38:13-PST,3313;000000000001
Return-Path: <[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Sun 16 Feb 86 11:37:45-PST
Date: 16 Feb 86 14:41:33 EST
From: Charles Hedrick <[email protected]>
Subject: TCP zero window bug?
To: [email protected]
Message-ID: <[email protected]>

symptom: can't get mail through to our Pyramid 90X (Unix 4.2) system.
FTP's to it hang. We have noticed problems in receiving
mail from at least one TOPS-20 site outside Rutgers.
diagnosis: Unlike TOPS-20, Unix sends acks as soon as it gets TCP
packets. Since it hasn't yet delivered the data to the user,
these packets are still taking up buffer space. Thus the window
size in the ack is small. Indeed in many cases it is zero.
Once the system delivers the data to the user, the buffer
space is freed and the window size increases. At that
point Unix sends another packet announcing the new window.
If the packet containing this window update should be
dropped, the sender is left thinking it has a zero window.
According to the protocol, the sender should probe this
zero window now and then by trying to send one byte.
There is code in TOPS-20 to do this, but apparently it is
not used all the time when it should be. The code is
triggered when the packetizer is asked to send a packet
and notices that the send window is zero. Unfortunatley,
there is code at prcac4-2 which overoptimizes. It fails
to call the packetizer if the window is zero, presumably
on the theory that if there is a zero window, nothing can
be sent. Unfortunately, this means that the probing is
never started. This problem does not show up between 2 TOPS-20
systems, since TOPS-20 does not ack a packet until it has passed
the data to the application. At that point, the buffer space
has been freed, and there is a new window. So the ack and the
window update are in the same packet. If an ack is dropped, the
other end will retransmit until it sees the ack. Thus there is
no way a TOPS-20 window update can be lost.
cure: the following diff is believed to correct this problem. At
least we haven't seen the problem since installing it.
There are other problems with the code that probes zero
windows. They are being worked on at Score. But those
problems are efficiency issues, whereas this one causes
connections to hang. Actually the use of 250 msec. in
the call to encpkt is purely arbitrary. It would probably
be better to use some function of the current round-trip
time.

File 1) TCPTCP.MAC.8,11-Feb-86 20:01:42
File 2) TCPTCP.MAC.9,11-Feb-86 20:38:58

************ following change is above PRCAC4
1)32 IMULI T3,3 ; 3 * Offered window
****
2)32 JUMPE T3,PRCA4A ;[221] if window set to zero, special handling
2) IMULI T3,3 ; 3 * Offered window
**************
1)32 PRCAC4:
1) ;See if packets which might have been made untransmittable due to
****
2)32 JRST PRCAC4 ;[221]
2) PRCA4A: MOVEI T1,^D250 ;[221] here when now have zero window.
2) CALL ENCPKT ;[221] send packet eventually to start
2) ;[221] probe of zero window, in case
2) ;[221] we drop the window update
2) PRCAC4:
2) ;See if packets which might have been made untransmittable due to
**************
-------
17-Feb-86 09:35:49-PST,1570;000000000000
Return-Path: <ridder%[email protected]>
Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Mon 17 Feb 86 09:35:29-PST
Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA11231; Mon, 17 Feb 86 09:39:47 pst
Message-Id: <[email protected]>
Date: Monday, 17 Feb 1986 09:39:57-PST
From: ridder%[email protected] (Hans)
To: tops-20@su-score
Subject: Re: DZ11 question for 2020's

Date: 17 Feb 1986 1039-MST
From: Hans <RIDDER at WARLOK>
To: "tops-20@su-score" at DECWRL
Subject: Re: DZ11 question for 2020's
Message-ID: <"MS10(2137)+GLXLIB5(0)" 12184121795.24.143.60983 at WARLOK.TCP>

Mark, each DZ has a FIFO (they call it a SILO) for all received
characters in an eight line group. An interrupt is generated
whenever the FIFO /is/ non-empty (as opposed to whenever it /goes/
non-empty.) The interrupt handler (DZRDIN in TTDZDV) completely
empties the FIFO before exiting.

My feeling is that if you group your lines on one DZ then you have
a better chance of finding more then one character in the FIFO
and thus saving an interrupt! Since DZs cause alot of them, I would
think anything you can do to help would make your 2020 a little
happier. But then the percentage change might be so small as to
be un-noticable.

As for transmit interrupts, they happen on a priority basis, with
line 7 having a higher priority than line 0. In theory, line 7
would be serviced better (giving better output rate) than line 0.
I wonder if that really happens?

--------
18-Feb-86 09:13:32-PST,436;000000000000
Return-Path: <[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 18 Feb 86 09:13:15-PST
Date: 18 Feb 86 12:18:42 EST
From: Don <[email protected]>
Subject: [NET]STAT source
To: [email protected]
Message-ID: <[email protected]>

Does anybody have a recent source to NETSTAT or any of its successors
(called perhaps TCPSTAT or TSTATS)?

Thanks,
Don
-------
19-Feb-86 02:09:29-PST,586;000000000000
Mail-From: BILLW created at 19-Feb-86 02:09:23
Date: Wed 19 Feb 86 02:09:23-PST
From: William "Chops" Westfield <[email protected]>
Subject: BBN Interne code.
To: [email protected]
Message-ID: <[email protected]>

BBN has let us look at their current version of the
tops20 TCP code. It's currently in <6-1-EXP-MON.BBN>
on score, and includes a "TOPS20-Internetworking.DOC" that
presumably explains how things are supposed to work.

Ill be looking at this, of course, but I thought some other
people might also be interested...

BillW
-------
19-Feb-86 10:15:13-PST,1650;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 19 Feb 86 10:14:48-PST
Date: Wed 19 Feb 86 13:19:26-EST
From: Thomas De Bellis <[email protected]>
Subject: Possible CRDIR% directory page count bug
To: [email protected]
Message-ID: <[email protected]>

Here is something that I have a tough time explaining: A user created a
subdirectory and then killed it causing his allocated directory pages to
go negative. I think I can explain that part, the weird thing was that
after he sent me a note about it, his directory went back to normal (ie, 0
pages instead of -1). Here is a log of it happening, anyone have any ideas?

[Journal begin, HP2621: WS2:CREATE-KILL-BUG.JRN.1, Mon 17 Feb 86 9:07:17PM]
A>i disk
PSA:<OP.ERIC>
0 Pages assigned
+INF Working pages, +INF Permanent pages allowed
51650 Pages free on PSA:, 176350 pages used.
A>^Ecreate /wor 10 /per 10 psa:<op.eric.foo1>
[New]
A>i disk
PSA:<OP.ERIC>
0 Pages assigned
+INF Working pages, +INF Permanent pages allowed
51638 Pages free on PSA:, 176362 pages used.
A>vd

PSA:<OP.ERIC>
FOO1.DIRECTORY.1;P20200 0 0(0) 17-Feb-86 21:07:38 OP.ERIC
A>^Ecreate /kill psa:<op.eric.foo1>
[Old]
[Confirm]
A>i disk
PSA:<OP.ERIC>
-1 Pages assigned
+INF Working pages, +INF Permanent pages allowed
51636 Pages free on PSA:, 176364 pages used.
A>jc
[Journal end: WS2:CREATE-KILL-BUG.JRN.1, Mon 17 Feb 86 9:08:12PM]

Shortly after this, the page count was back at 0!!!

-- Tom De Bellis
Columbia Computer Center
-------
19-Feb-86 19:59:59-PST,748;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 19 Feb 86 19:59:48-PST
Date: Wed 19 Feb 86 23:04:49-EST
From: Ken Rossman <[email protected]>
Subject: Re: Possible CRDIR% directory page count bug
To: [email protected], [email protected]
In-Reply-To: <[email protected]>
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

By sending you a note about it, MM created a MAIL.CPY file, which had to
go through normal TOPS-20 file system allocation, which in turn might have
found the discrepancy and cleaned it up... well, that's my guess.
-------
20-Feb-86 15:59:53-PST,3215;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Feb 86 15:59:29-PST
Date: Thu 20 Feb 86 18:04:33-CST
From: Clive Dawson <[email protected]>
Subject: Recap of ARP bugs
To: [email protected]

A couple of messages earlier this month contained patches to IPNIDV.MAC
which cured problems in TOPS-20's ARP table. Original symptoms of the bugs
included running out of table space due to duplicate entries and failure to
find ARP entries which resulted in unnecessary network ARP traffic. (The
new SYSDPY has an ARP command which allows you to examine your ARP table
and quickly determine whether you are suffering from this.)

One more bug in the binary search routine has since been fixed. I'm still
not convinced these routines are totally sound, however. There are several
places where the ARP search routines return pointers to a given entry.
There is no guarantee, however, that those pointers will still be valid
when they are used, since the table may have been modified in the interim.

In any case our current version has been running for almost two weeks with
no apparent problems. The following .DIF file contains the new fix as well
as the previous ones.

Clive

File 1) <MONITOR.5-4>IPNIDV.MAC created: 1047 03-Mar-1985
File 2) <MONITOR.5-4.MCC>IPNIDV.MAC created: 0724 08-Feb-1986

*****************************************
1)1 ; UPD ID= 419, SNARK:<TCPIP.5.4.MONITOR>IPNIDV.MAC.87, 3-Mar-85 11:47:12 by PAETZOLD
*........................................
2)1 ;<MONITOR.5-4.MCC>IPNIDV.MAC.3, 5-Feb-86 17:26:30, Edit by AI.CLIVE
2) ;[MCC-34] Fix GHT search routines so that duplicate ARP entries don't happen
2) ; and also fix a race condition with ARPUPD.
2) ; UPD ID= 419, SNARK:<TCPIP.5.4.MONITOR>IPNIDV.MAC.87, 3-Mar-85 11:47:12 by PAETZOLD
********ISRCH****************************
1)39 ISRCH: MOVE P2,P3 ;BUILD MIDDLE BY TAKING THE HIGH
*.......INTSRC+7.........................
2)39 IFN MCCSW,< ;[MCC-34]
2) SOS P3 ;HIGH is offset to last entry, not # of entries
2) >;IFN MCCSW ;[MCC-34]
2) ISRCH: MOVE P2,P3 ;BUILD MIDDLE BY TAKING THE HIGH
********ISRCH+11*************************
1)39 JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED
*.......ISRCH+11.........................
2)39 IFN MCCSW,< ;[MCC-34]
2) AOS T1 ;Adjust T1 & P2 to point to correct the
2) AOS P2 ; insertion point in the case where
2) ; the last entry examined is .LT. host.
2) >;IFN MCCSW ;[MCC-34]
2) JRST ISCHK ;CHECK FOR ALL ENTRIES HAVING BEEN SEARCHED
********ARPUPD+4*************************
1)55 MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE
*.......ARPUPD+4.........................
2)55 IFN MCCSW,< ;[MCC-34]
2) MOVE T2,SPADR ;Get internet address
2) CALL INTSRC ;Search table again to ensure pointer is valid
2) SKIPA ;Not found, as expected
2) JRST [OKSKED
2) RET] ;Aha! Somebody else did it for us
2) MOVEM T1,AREA1 ;Save insertion pointers
2) MOVEM T2,AREA2 ;...
2) >;IFN MCCSW ;[MCC-34]
2) MOVE T2,GHTAR1 ;GET ADDRESS OF AREA ONE
********[ END OF FILCOM AT RPC1+20 ]********
-------
21-Feb-86 04:22:31-PST,3556;000000000000
Mail-From: BILLW created at 21-Feb-86 04:22:24
Date: Fri 21 Feb 86 04:22:24-PST
From: William "Chops" Westfield <[email protected]>
Subject: Tops20 TVT performance improvments
To: [email protected], [email protected]
Message-ID: <[email protected]>

BUG: Under certain situations, throughput on TOPS20 TVTs drops to
approximately 0 for long periods of time. I believe that
the problem got worse with v6.1, and may be the reason
that the TVT SMTP server doesn't work well under 6.1.

Reproduce by:
I think this shows up best when trying to run a dialout
type program while logged in on a TVT. However, the
following program will exhibit the problem too:

start: movei 6,^d32
loop: movei 1,"%"
pbout
movei 1,^d30
disms
sojg 6,loop
haltf

Diagnosis:
The tops20 TVT scanner attempts to send characters that are
part of "echoing" immediately. It's criteria for recognizing
"echoes" is that there be fewer than 8 characters in the
terminal output buffer. Since the TCP process runs at a very
high priority, it will probably get to look at the TTY output
buffers if the user process blocks for any reason. In the
case above, therefore, there is a good chance that 32
separate 1 byte packets are queued. And there are certainly
lots of machines that don't like to receive 32 almost
back-to-back short packets. This leads to many retransmissions
and excessive use of CPU time on both systems, not to mention
any gateways that might be in between them.

Fix: Make TOPS20 TCP pickier about what it considers echoing.
In addition to there being only a few characters in the
buffer, have it insist that the retransmission queue for
that connection be empty. (If a person types faster than
the Round trip times, it won't hurt to have his echoing
clumped together a little anyway.) This is much simpler
than having the TCP repacketize retransmissions.

By the way, it turns out that this is "reinventing the
wheel", as almost identical suggestions were made by
John Nagle in RFC896. It is surprising, however, that
this makes such a difference even on local ethernets
with no gateways involved. Admittedly, tops20's
scheduling of TCP provides a pathological case!

The relevant code is in TVTSRV, just before OPSCA7:
[This is from 6.1 sources. There should be an easy
equivalent for 5.x. From SCORE:: <6-1-monitor>TVTSRV.MAC ]

SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT
JRST OPSCA7 ; No.
IFE STANSW,<
MOVX T1,^D200 ; The function to queue for PZ if a lot
MOVX T2,<XCDSEC,,ENCPKT> ; to send - wait a bit, maybe more
CAIGE T4,^D8 ; Less that 8 is echoing so
MOVX T2,<XCDSEC,,FRCPKT> ; Force it now
CALL (T2) ; See Note above
>;IFE STANSW
IFN STANSW,< ;;; there is not going to be any more output if all of the
;;; output buffers are full, so send packets immediately.
CALL TTSOBF ;output buffer full?
CAIGE T4,^D8 ; or looks like echoing.
SKIPA T2,[XCDSEC,,FRCPKT] ; Force it now
MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
LOAD T1,QNEXT,<+TCBRXQ(TCB)> ;check if retranmission queue empty?
CAIE T1,TCBRXQ(TCB) ;skip if RXQ empty
CAIL T4,^D8 ; or if a large packet
TRNA
MOVX T2,<XCDSEC,,ENCPKT> ; otherwise wait for more data
MOVEI T1,^D200 ; for a couple hundred millisecs.
CALL (T2) ;call appropriate packet routine.
>;IFN STANSW
OPSCA7: MOVE T2,LINADR ; Restore address of terminal block
OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT
-------
21-Feb-86 06:46:59-PST,2017;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 21 Feb 86 06:46:51-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 21 Feb 86 06:49:50-PST
Date: Fri 21 Feb 86 06:12:11-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: Tops20 TVT performance improvments
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12185132542.9.MRC@PANDA>

A release 5.4 equivalent of BillW's change is follows. It does make a
difference.

SKIPA T4,T1 ; Yes. Get PZ to call SNDTVT
JRST OPSCA7 ; No.
IFE PANDASW,< ;[5]
MOVX T1,^D200 ; The function to queue for PZ if a lot
XMOVEI T2,ENCPKT ; to send - wait a bit, maybe more
CAIGE T4,^D8 ; Less that 8 is echoing so
XMOVEI T2,FRCPKT ; Queue for PZ promptly
CALL (T2) ; See Note above
>;IFE PANDASW
IFN PANDASW,< ;[5]
;;; FRCPKT is called if:
;;; . There are less than 8 bytes (probably echoing) in the packet and the
;;; retransmission queue is empty
;;; OR
;;; . The terminal output buffer is full
;;; Otherwise ENCPKT is called instead

CALL TTSOBF ; Is output buffer full?
IFSKP.
CALL FRCPKT ; Yes, might as well send it now
ELSE.
CAIL T4,^D8 ; Looks like echoing?
IFSKP.
LOAD T1,QNEXT,<+TCBRXQ(TCB)> ; Yes, get RXQ
CAIE T1,TCBRXQ(TCB) ; Is the retransmission queue empty?
ANSKP.
CALL FRCPKT ; Yes, queue for PZ promptly
ELSE.
MOVX T1,^D200 ; Output not full and not echoing, wait a bit
CALL ENCPKT ; for more to output
ENDIF.
ENDIF.
>;IFN PANDASW
OPSCA7: MOVE T2,LINADR ; Restore address of terminal block
OPSCA8: CALL ULKTTY ; Decrease reference count, OKINT

I don't believe this problem was the cause of the TVT SMTP server problem,
nor will this fix repair it. The TVT SMTP server doesn't echo.
-------
22-Feb-86 02:29:23-PST,1159;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 22 Feb 86 02:29:15-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 22 Feb 86 02:34:33-PST
Date: Sat 22 Feb 86 01:55:10-PST
From: Mark Crispin <MRC%[email protected]>
Subject: PDP-11/20
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12185347898.8.MRC@PANDA>

Through an amusing set of circumstances I have found myself the proud(?)
owner of a PDP-11/20, serial number 1779. According to the bus list on
the back, it has a KA11, a KP11(?), a KL11A, two MM11F's, and a DR11B.
I believe an MM11F is an 8K memory. There was a Unibus cable coming out
of the Unibus backplane between the KP11 (or is it KD11?) and the KL11A;
there are boards there but nothing listed, there was also a zillion wire
cable coming from the DR11B.

Can anybody tell me what use, if any, this boat anchor sitting on my
living room floor is? Apparently it is dysfunctional; in any case none of
the console lights light even when you try to LOAD ADDRESS...
-------
22-Feb-86 09:13:19-PST,509;000000000000
Return-Path: <[email protected]>
Received: from CS.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sat 22 Feb 86 09:13:10-PST
Date: Sat 22 Feb 86 12:16:57-EST
From: Bill Schilit <[email protected]>
Subject: Re: PDP-11/20
To: MRC%[email protected]
cc: [email protected]
In-Reply-To: Message from "Mark Crispin <MRC%[email protected]>" of Sat 22 Feb 86 07:19:51-EST

in any case none of the console lights light even when you try
LOAD ADDRESS...

Try plugging it in.

- Bill
-------
23-Feb-86 06:38:22-PST,820;000000000001
Return-Path: <[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Sun 23 Feb 86 06:38:12-PST
Date: 23 Feb 86 09:21:34 EST
From: Charles Hedrick <[email protected]>
Subject: previous patch for probing zero windows
To: [email protected]
Message-ID: <[email protected]>

A week or soago, I proposed a patch around prcac4 to handle problems
probing zero windows. It has since become clear that there are
more serious problems than this with zero windows. This patch
certainly doesn't solve all ofthe problems. It doesn't seem to
cause any terrible problems, but I suspect that a complete
solution will not involve that patch. So I recommend that you
remove it if you put it in, but there is no great emergency
involved in doing so.
-------
23-Feb-86 17:39:48-PST,1962;000000000001
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 23 Feb 86 17:39:40-PST
Date: Sun 23 Feb 86 17:44:57-PST
From: Kirk Lougheed <[email protected]>
Subject: 6.1 Filesystem Rebuild Screw
To: [email protected]

Problem:

DLUSER fails to properly restore directories when rebuilding the public
structure created by the monitor's filesystem initialization routines.

Analysis:

The DLUSER data was taken from a filesystem that had Release 6.1 password
encryption. Since the monitor does not ask about enabling password
encryption when creating a structure, the new public structure did not
have the encryption bit set in the home blocks. CRDIR% carefully disallows
setting an encrypted password for a directory on a non-encrypted structure,
returning a CRDI27 error code.

Solution(s):

One solution would be to have the monitor ask about password encryption
when the monitor is started from PC 143. This would be preferable.
Note that CHECKD should also ask that question when initializing a
filesystem.

The solution I took was to remove the check in CRDIR%. My feeling is that
if I took the trouble to specify a password encryption version, I should
be allowed to set such an encrypted password, regardless of whether I was
able to, or remembered to, set up an encrypted structure. The relevant
code fragment from JSYSF.MAC follows:

UMOVE T1,.CDPEV(Q2) ;Get user-supplied encryption version
IFE STANSW,<
;; Don't check for password encryption on structure. This can severely
;; hamper efforts to restore a filesystem using DLUSER information.
JUMPE T1,CRDP1A ;Bypass structure check if zero (unencrypted)
MOVE T3,CRDSFL ;Get status flags for the structure
TXNN T3,MS%CRY ;Is password encryption on for this structure?
RETBAD(CRDI27,<CALL CRDIR6
ULKDIR>)
>;IFE STANSW
CRDP1A: CALL CHKPEV ;Test validity of encryption version number
-------
23-Feb-86 20:59:17-PST,874;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 23 Feb 86 20:59:07-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 23 Feb 86 21:04:35-PST
Date: Sun 23 Feb 86 19:48:31-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Bug in DECnet-20 SRV: device
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12185805440.8.MRC@PANDA>

Validity:
All DECnet-20 monitors (6.0 or earlier). DECnet-36 monitors and
non-DECnet monitors don't have this bug.

Problem:
Can't get a TASK SRV: JFN, e.g. SRV:TASK-FOOBAR

Diagnosis:
Fencepost error in test for object type number being out of range.

Solution:
At SRCNAM+13 (FILNSP in 4.x monitors, else NSPSRV), change
SKIPG T1 to SKIPGE T1
-------
24-Feb-86 02:42:00-PST,1978;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Feb 86 02:41:51-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 24 Feb 86 02:45:55-PST
Date: Mon 24 Feb 86 02:17:38-PST
From: Mark Crispin <MRC%[email protected]>
Subject: SMTP over DECnet
To: [email protected]
cc: ridder%[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12185876278.8.MRC@PANDA>

Folks -

It has been pointed out to me that DEC is going to be using SMTP over
DECnet for mail in at least some applications, and that the assigned object
type is named object type "MX-LISTENER". The development MM sources on
PANDA have already been changed to use this instead of the old 125 (which
was an interim object type anyway) and the distribution sources on SIMTEL20
will be updated soon once a flurry of activity with MMailr winds down.

If you are using MM/SMTP over DECnet you may want to change over to
this new object type. In SMTDCN.MAC, the file name is SRV:TASK.MX-LISTENER,
in MMAILR.MAC, the name is DCN:node-TASK-MX-LISTENER. This replaces SRV:125
and DCN:node-125. If you are running a NSPSRV DECnet monitor (pre-6.1), you
will need to patch monitor location SRCNAM+13 from SKIPG T1 to SKIPGE T1 to
run the new SMTDCN.

If anybody at DEC involved with this is listening, please get in touch
with me. My implementation of DECnet/SMTP is in fairly extensive use in the
field and there are various TOPS-10 and VAX systems that talk to TOPS-20
systems using it. That's a strong argument to try to get some degree of
compatibility going; hopefully in these dying days of 36-bits we aren't going
to see much wheel-reinvention and Not-Invented-Here syndrome... Some people
at DEC already have my DECnet/SMTP software, but if you don't please let me
know and I'll make sure you get it post haste.
-------
24-Feb-86 16:39:28-PST,1272;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Feb 86 16:39:14-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 24 Feb 86 16:44:45-PST
Date: Mon 24 Feb 86 16:42:47-PST
From: Mark Crispin <MRC%[email protected]>
Subject: 36 bits at DECUS: the decline continues
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12186033772.9.MRC@PANDA>

I just got my preliminary program for DECUS in Dallas (4/28-5/2). Large
Systems sessions are now only three days. Tuesday morning are the
marketing sessions, Tuesday afternoon are the highend VAX sessions,
Wednesday morning is TOPS-20, Wednesday afternoon is TOPS-10, and most of
Thursday are the migration to VMS sessions except at the very end there
are two hours for a Town Meeting and the Menu.

It's sad and depressing. On the other hand, given the sparse attendance
at the last DECUS it's somewhat amazing that there's even that much in the
way of 36-bit sessions.

On an up note, there will be two Large Systems pre-symposia sessions. The
first one is by Bob McQueen about Ethernet/802.3 planning, the second is by
Len Bosack about TCP/IP.
-------
24-Feb-86 21:07:36-PST,9305;000000000001
Return-Path: <[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Mon 24 Feb 86 21:06:47-PST
Date: 25 Feb 86 00:11:37 EST
From: Charles Hedrick <[email protected]>
Subject: TCP zero window probe patch (2nd try)
To: [email protected]
Message-ID: <[email protected]>

This patch makes TOPS-20 probe zero send windows in TCP. When talking
to a Unix system, if the wrong packet gets dropped (e.g. due to a
congested gateway, or other packet losage) it is possible for a TCP send
to hang. The scenario is this: TOPS-20 is sending data. It sends
enough to have fully used up the window allocation given by the other
end. The other end ACK's these packets, including a zero window in the
ACK. (This would not happen with another 20, but would be the normal
case if the other system is 4.2.) At this point, the 20 will do nothing
until it gets another packet with a non-zero window allocation. If that
packet should be dropped, we have a classic deadlock. Each end is
waiting for the other to do something. In order to prevent this problem,
the TCP spec says that a system looking into a zero window should
"probe" now and then. The simplest kind of probe is a one-byte packet.
As long as the window stays closed, this packet will be ignored, or
ACKed with another ACK containing a zero window. When the other end is
ready to get data again, an ACK with nonzero window will be sent. There
are other kinds of probe possible, including a packet with an
intentionally illegal sequence number. (This has some advantages that I
don't want to talk about here.) But something of this kind is essential
to avoid hangs in dealing with Unix. TOPS-20 uses a different ACK
strategy, so this sort of hang will not show up when talking between two
TOPS-20 systems. Anyway, TOPS-20 does not probe zero windows. It has
some of the code needed to do so, but it is not called at all the right
times. The following patch makes the code work in all of the cases that
I can test. It is not an aesthetically very pleasing implementation.
It uses normal data packets as probes, rather than the special illegal
packet that I would regard as better. After the bad experience with my
previous patch, this time I instrumented a Unix system so that I could
watch packets go by, and tried it under various loading conditions. It
seems to do something reasonable. Anything better would require a
separate mechanism for probes, rather than using the normal packetizing
and retranmission code. There are patterns of traffic which would cause
this code to use a full data packet as a probe. I suspect this would
never happen in practice, and even if it did, I believe such a probe
would still work. (This is the one part of the code that I have not
been able to test, as I can't contrive any circumstance that will
exercise it.) The following patch also includes an unrelated fix from
BillW at Score. Because these two patches are intertwined, it was
impossible to give you mine without his.

In addition to the changes below, I suggest that you might want to
change TCPRXW (in STG.MAC) from 120000 to 30000 (2 min. to 30 sec). This
controls how often probes are sent. The correct value depends upon the
speed of your network and how often packets are dropped. If packet
losssage is at all common, 2 min. seems a bit long to wait to restart
the connection. It would be a bad idea to set it much shorter than 30
sec. Ideally, this time should by adjusted dynamically, but I leave
that for a later project.

This code has been tested only in 5.4. I have glanced only briefly
at the corresponding 6.1 code.

REDIT 1(103) COMPARE by user HEDRICK, 24-Feb-86 23:41:13
File 1: RED:<HEDRICK>TCPTCP.MAC.1
File 2: RED:<HEDRICK>TCPTCP.MAC.3
***** CHANGE #1; PAGE 32, LINE 10; PAGE 32, LINE 10
LOAD T2,TSSEQ,(TCB) ; Get current Send Sequence
SUB T2,T1 ; Bytes used in send window
MODSEQ T2 ; (Must be .ge. 0)
LSH T2,2 ; 4 * Used
LOAD T3,TSWND,(TCB) ; Get new Send Window
IMULI T3,3 ; 3 * Offered window
CAMGE T2,T3 ; If Used/Offered .lt. 3/4
CALL FRCPKT ; Run PZ, but after RA
PRCAC4:

---------------------------------
LOAD T2,TSSEQ,(TCB) ; Get current Send Sequence
SUB T2,T1 ; Bytes used in send window
MODSEQ T2 ; (Must be .ge. 0)
LSH T2,2 ; 4 * Used
LOAD T3,TSWND,(TCB) ; Get new Send Window
JUMPE T3,PRCA4A ;[221] if window set to zero, special handling
IMULI T3,3 ; 3 * Offered window
CAMGE T2,T3 ; If Used/Offered .lt. 3/4
CALL FRCPKT ; Run PZ, but after RA
JRST PRCAC4 ;[221]

PRCA4A: ;[223] here when now have zero window, with window used in T2
;[223] MOVEI T1,^D250 ;[221] here when now have zero window.
MOVE T1,TCPRXW ;[223] probe interval, in msec
SKIPN T2 ;[223] only probe if nothing else outstanding
CALL ENCPKT ;[221] send packet eventually to start
;[221] probe of zero window, in case
;[221] we drop the window update
PRCAC4:

***** CHANGE #2; PAGE 66, LINE 7; PAGE 66, LINE 7
; Compute the amount of window space available to send into as
; provided by the remote end.

LOAD T1,TSLFT,(TCB) ; Send Left
LOAD T3,TSWND,(TCB) ; Send Window offered
SKIPN T3 ; Allow sending if window is shut
MOVX T3,1 ; Need probe to sense remote window openning
LOAD T2,TSSEQ,(TCB) ; Send Sequence
SKIPE PKT ; or
LOAD T2,PESEQ,(PKT) ; Packet end sequence if partial packet
ADD T1,T3 ; Compute Send Right
---------------------------------
; Compute the amount of window space available to send into as
; provided by the remote end.

LOAD T1,TSLFT,(TCB) ; Send Left
LOAD T3,TSWND,(TCB) ; Send Window offered
;[223] SKIPN T3 ; Allow sending if window is shut
;[223] MOVX T3,1 ; Need probe to sense remote window openning
;[223] We treat a zero window specially because the code below is going
;[223] to turn a 1 back into a 0 if we just do MOVX T3,1 at this point.
;[223] If there is already a partially filled packet, then at one point
;[223] there must have been enough data for it. We use that packet as
;[223] a probe instead of the usual 1-byte probe.
IFE. T3 ;[223] if window is shut
LOAD T2,TSSEQ,(TCB) ;[223] and if nothing already outstanding
SUB T2,T1 ;[223]
MODSEQ T2 ;[223] currently used window
JUMPN T2,PKTIZ5 ;[223] something already out, just say 0 window
MOVX WNDSPC,1 ;[223] assume one-char probe
;[223] the following code is here because of the Stanford part of edit 221.
;[223] should it ever be removed, then this might not be right.
JUMPE PKT,PKTIZ6 ;[223] no partial packet, so that's right
LOAD T2,PESEQ,(PKT) ;[223] packet end sequence number
SUB T2,T1 ;[223] Difference is number bytes in pkt
MODSEQ T2 ;[223] Possible wrap
JUMPE T2,PKTIZ6 ;[223] nothing really there, use 1 byte probe
MOVE WNDSPC,T2 ;[223] Use existing packet as probe
JRST PKTIZ6 ;[223]
ENDIF. ;[223]
LOAD T2,TSSEQ,(TCB) ; Send Sequence
;[221] SKIPE PKT ; or
;[221] LOAD T2,PESEQ,(PKT) ; Packet end sequence if partial packet
ADD T1,T3 ; Compute Send Right

***** CHANGE #3; PAGE 66, LINE 42; PAGE 66, LINE 63
; known and the apparent amount of useable window space is known.
; Set XFRCNT to the (maximum) amount which can actually be sent in this
; Pkt. In the case of a TVT, it is not known how much is available
; and we will assume a full packet (or window, etc) is to be sent.

CAML BUFCNT,WNDSPC ; Take min of what is available to be
---------------------------------
; known and the apparent amount of useable window space is known.
; Set XFRCNT to the (maximum) amount which can actually be sent in this
; Pkt. In the case of a TVT, it is not known how much is available
; and we will assume a full packet (or window, etc) is to be sent.

COMMENT | ;[221]
Problem: Large data transfers to some hosts don't work.

Diagnosis: At some point in the transfer, the packetizer (PZ) emptied the
last (currently) available user buffer, which partially filled a packet.
Say that the data in this packet consumes 80% of the advertised send window.
In the absence of a push, the packet was held pending more user data. When
the next user buffer is presented, the PZ tries to resume filling the
current packet. Just before PKTIZ5 (in TCPTCP.MAC), the PZ calculates how
much available window space it has. Since, after taking into account the
data already in the current packet, only 20% of the window is usable, the
silly-window avoidance code holds everything pending a window update or a
push. Since neither of these happens, things hang until the somebody times out.

Cure: The PZ should not include data in the current packet in its silly
window calculations. It does need to account for this data immediately
after that calculation, to prevent overflowing the send window.
|
IFN. PKT ;[221] Have partially filled pkt?
LOAD T2,PESEQ,(PKT) ;[221] Yes, get end seq
LOAD T1,TSSEQ,(TCB) ;[221] and send seq
SUB T2,T1 ;[221] Difference is number bytes in pkt
MODSEQ T2 ;[221] Possible wrap
SUB WNDSPC,T2 ;[221] WNDSPC = #bytes can still put in pkt
ENDIF. ;[221]
CAML BUFCNT,WNDSPC ; Take min of what is available to be

-------
27-Feb-86 17:31:12-PST,564;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 27 Feb 86 17:31:02-PST
Date: Thu, 27 Feb 1986 18:30 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To: [email protected]
Subject: RSCAN in EXEC?

Has anyone modified EXEC so that it can behave like most other
programs and accept a command line via RSCAN? The purpose is to
provide certain EXEC features through a front-end MENU program without
writing a mini-EXEC in the process.

--Frank
1-Mar-86 16:36:01-PST,1294;000000000000
Return-Path: <[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Sat 1 Mar 86 16:35:50-PST
Received: ID <[email protected]>; Sat 1 Mar 86 19:35:43-EST
Date: Sat 1 Mar 86 19:35:40-EST
From: [email protected]
Subject: BAT block editing
To: [email protected]
Message-ID: <[email protected]>

Here's the problem: I have a structure that had a bad drive on it for a short
period of time on which CHECKD was run. The result is that the BAT blocks for
the unit that was on the bad drive are now full. I'd like to delete some of
the bogus BAT block entries rather than rebuild the whole structure, but the
EDIT (BAT blocks) command in my version of CHECKD doesn't work (it allows one
to "edit" the BAT blocks but doesn't update them on exit). Does anyone have a
version of CHECKD (usable on a 5.4 system) on which the EDIT (BAT blocks)
command works properly (or some other program which is capable of editing the
BAT blocks to solve this problem)? Sources would be preferred, since we have
the local mod to allow structures with more than 3 units and the structure in
question has more than 3 units. My alternative is to patch the BAT blocks by
hand in FILDDT, which would be a royal pain...

Thanks in advance,
--Vince
-------
1-Mar-86 17:18:21-PST,552;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Mar 86 17:18:12-PST
Date: Sat 1 Mar 86 18:16:40-MST
From: Randy Frank <[email protected]>
Subject: Re: BAT block editing
To: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

there is a program BATUPD from the sws-kit years ago; I put a copy
on [utah-20]:<anonymous>batupd.exe. No idea if it still works, but it
probably does. Good luck.
-------
2-Mar-86 21:11:49-PST,999;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sun 2 Mar 86 21:11:43-PST
Date: Mon, 3 Mar 1986 00:13 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
cc: [email protected]
Subject: Domain resolver code

The new GTDOM% code has now been up for over a week straight on XX,
and the resolver is still working ok. It looks pretty solid.

Paul Mockapetris has been talking about combining this stuff with the
work he has been doing on the nameserver lately to make up a formal
release, but don't hold your breath.

Anybody out there want to start womping up a 6.1 version (which Paul
isn't going to do anyway)? MKL@NIC has been trying, without much luck
(there's some hairy page mapping code in the initialization routine
that causes him grief). Other than that and some PSECT twiddling, it
should be a pretty easy job. Code is in XX:<DOMAIN.5A>.

--Rob
3-Mar-86 18:17:21-PST,900;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 18:17:01-PST
Date: 3 Mar 1986 2119-EST
From: Bill Melohn <[email protected]>
To: TOPS-20@score
Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224"
Subject: My Intgration/Migration
Message-ID: <"MS11(5136)+GLXLIB5(0)" 12187886310.20.108.28302 at MARLBORO.DEC.COM>

I am leaving the TOPS-20 group as of this Friday. Jim McCollum will
be taking over all of my responsiblities for ARPAnet, LAT, and CTERM
related matters. Jim can be reached at (617) 467-4635
([email protected]).

I have accepted a job working for Sun Microsystems' data
communications group in Mountain View, California.

It has been a pleasure meeting and working with many of you. I will
most likely continue to work with those of you who have Suns in the
future.

Bill
--------
3-Mar-86 21:03:42-PST,605;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 21:03:31-PST
Date: Mon 3 Mar 86 22:03:07-MST
From: Randy Frank <[email protected]>
Subject: Re: My Intgration/Migration
To: [email protected], [email protected]
In-Reply-To: <"MS11(5136)+GLXLIB5(0)" 12187886310.20.108.28302 at MARLBORO.DEC.COM>
Message-ID: <[email protected]>

Reminds me of a saying a while ago in Seattle during one of Boeing's many
downturns:

"Will the last one left using Tops-20 please remember to turn out the
lights..."

-------
3-Mar-86 21:12:51-PST,624;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 21:12:38-PST
Date: 4 Mar 1986 0014-EST
From: John J Purretta <[email protected]>
To: Randy Frank <[email protected]>, [email protected],
[email protected]
Large Systems Marketing: 297-6062
Subject: Re: My Intgration/Migration
Message-ID: <"MS11(5136)+GLXLIB5(0)" 12187918285.13.1021.8725 at MARLBORO.DEC.COM>
References: Message from Randy Frank <[email protected]>
of 4-Mar-86 0013-EST
In-reply-to: <[email protected]>

Ok.
/jp
--------
3-Mar-86 23:07:29-PST,1900;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Mar 86 23:07:19-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 3 Mar 86 23:08:56-PST
Date: Mon 3 Mar 86 22:48:55-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: My Intgration/Migration
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12187935434.8.MRC@PANDA>

Well, since I am planning to keep PANDA running (and to hack
TOPS-20 on it) into the next century, I may well be the last
TOPS-20 user. I'll remember to turn off the lights, unless, of
course, I stop using TOPS-20 when MY lights get turned out!

I sure hope DEC puts TOPS-20 in the public domain once 7.0
(the last DEC TOPS-20) is released. I'd sure like to be able to
release 7.1. By the way, once I finish DECnet-36 on the 2020, I
think I'm going to work on a command editor in the monitor.
What's next? Maybe TP4 (certainly 2020 TCP/IP), maybe command
DWIM,...

Say, let's consider a lighter topic. Assuming all goes well
-- that is, DEC lets go of TOPS-20 -- what should subsequent
versions of our favorite operating system be called? After all,
"TOPS-20" is a DEC trademark and it isn't reasonable or
appropriate to continue using it in the post-DEC era. To
forestall the suggestions for "Twenex", let me point out that
machines other than DEC-20's run TOPS-20. "Viros" probably
doesn't make sense (after all, VM/370 is a *real* "virtual
operation system"); we could have "Snark" but what are we
hunting? Per Hjerppe can explain why "Krans" (yet another
pre-release name) isn't acceptable.

I'm sure there'll be no lack of suggestions.

-- Mark --
-------
4-Mar-86 06:32:56-PST,900;000000000000
Return-Path: <[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 06:32:46-PST
Date: Tue 4 Mar 86 09:48:03-AST
From: Reid Broome <[email protected]>
Subject: Disk Exerciser for TOPS-20
To: [email protected]
Postal-Address: P.O. Box 1012, 9 Grove St., Dartmouth, NS B2Y 3Z7, Canada
Phone: (902) 426-3100 x158
Message-ID: <[email protected]>

During the latter part of this week, Field Service will be installing
an RP07 on our DEC-2060. The current PS: (now on RP06's) will be
moved to this new RP07 drive. I would like to be 100% sure that this
RP07 drive is "virtually" error free before moving PS: to it.

Does anyone have or know of a disk exerciser program written for
TOPS-20? I would expect that such a program would write and read data
to a disk with verification.

Thanks in advance,

Reid Broome
-------
4-Mar-86 11:08:56-PST,1056;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 11:08:37-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 4 Mar 86 11:08:40-PST
Date: Tue 4 Mar 86 10:12:53-PST
From: Mark Crispin <MRC%[email protected]>
Subject: FB%NDF loses disk pages
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12188059946.10.MRC@PANDA>

Problem:
The following sequence loses disk pages:
$COPY TTY: A.A
TESTING...
^Z
$REV A.A
<rev mumble> : SET UNDELETABLE (sets FB%NDL)
$COPY TTY: A.A.1
?File is marked "Never Delete": A.A.1
$
The FDB is still there and its page and byte counts are still set,
however, it no longer has an index block. Both the index block and the
data page are lost, and will show up as lost the next time you run CHECKD.

Diagnosis:
Somebody is clearing the index block pointer prematurely in a
superceding OPENF%

Solution:
None yet.
-------
4-Mar-86 11:11:48-PST,788;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 11:11:11-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 4 Mar 86 11:12:04-PST
Date: Tue 4 Mar 86 10:48:05-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Fix to FB%NDL loses pages bug
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12188066354.10.MRC@PANDA>

At DELFIL+30, add a STOR P3,FBADR,(D) in the literal when the file is FB%NDL:
TXNE A,FB%NDL
JRST [ STOR P3,FBADR,(D) ;PUT ADR BACK INTO FDB
MOVEI A,DELX13 ;YES - RETURN AN ERROR
JRST DELFIX]
This puts the address of the index file back into the FDB prior to returning
the error.
-------
4-Mar-86 13:49:35-PST,1433;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 13:49:07-PST
Date: 4 Mar 1986 1648-EST
From: Jim McCollum <[email protected]>
To: TOPS20@score
Reply-to: [email protected]
Subject: The new kid in town
Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12188099250.130.29.193333 at TOPS20.DEC.COM>

Hello,

At Mark Crispin's urgings I am sending this out to introduce myself
to all of you. My name is Jim McCollum and I'll be taking over Bill
Melohn's TCP/IP responsibilities for TOPS-20. My mailing address is
[email protected].

I may have met some of you at the fall DECUS in Anahiem. If you
don't remember, don't worry, I probably don't remember you either. For
those of you who are planning on attending spring DECUS in Dallas I will be
there too and we'll have a chance to meet. I'm looking forward to that
based on some of the things I've heard about members of this community.

This is my first foray into the world of ARPAnet, but I'm confident
I can meet the needs of the TOPS-20 community. For those of you you are
wondering where things stand with TOPS-20 these days, about all I can say
is that we are starting the planning stage for release 7.0 now. More
details will be available at DECUS and I hope some of you are going to be
there.

See you in Dallas.

Jim
--------
4-Mar-86 17:50:26-PST,550;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Mar 86 17:50:16-PST
Date: Tue 4 Mar 86 17:47:45-PST
From: Stu Grossman <[email protected]>
Subject: Re: My Intgration/Migration
To: MRC%[email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: Message from "Mark Crispin <MRC%[email protected]>" of Tue 4 Mar 86 00:29:09-PST

I think that something put out by PANDA should be called PANDex (or
maybe exPANDex)!

Stu
-------
5-Mar-86 06:21:46-PST,3439;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 06:21:31-PST
Date: Wed 5 Mar 86 09:21:55-EST
From: Thomas De Bellis <[email protected]>
Subject: Re: Disk Exerciser for TOPS-20
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

Reid,

I don't know if you'll find an exerciser per se, but I can give you
a couple of suggestions and let you know what we do here at Columbia
when we want to test out a suspected drive. Basically, all we are
interested in is whether the drive is getting errors or not and we
don't particularly care how we find this out. The only constraint we
have is that we'd like to find the information out without having to
have the system be unavailable for users. We'd also like the testing
procedure to not crash the system nor overly effect system
performance.

This precludes the use of regular diagnostics because either you've
got to have the system running that funny field circus diagnostic
monitor or you've got some other program doing special seeks all over
the place under timesharing and things can get confused.

The following solution was actually thought up by our operations
staff and it is now our standard procedure for verifying disks. The
disk is mounted in a batch job and then set unavailable to new users.
The batch job uses MAKDMP to create a nice *BIG* file. It then spends
the rest of its time copying this file all over the place in the disk.
This is accomplished by a simple batch loop:

FOO:: @COPY DUMP.EXE.0 DUMP.EXE.-1
@BACKTO FOO

When it gets an error (ie, the structure is full), Batcon makes it go
to an error label. Here, all the files except one are deleted and the
entire structure is expunged. If an error occurs during this part, we
assume something is wrong and abort the batch job. Otherwise, we jump
back to the FOO:: label and start all over.

Now for the fun part: we let this batch job run *several days*! By
doing this, we have shaken out marginal drives that have passed
diagnostic tests. Clearly, a lot of disk activity is going on here
that you want to have happen. The drive is being tested under
conditions that are exactly like or worse than normal operating
conditions. Things like the disk bit table get written a lot, FDB's
get created and deleted; yep, lots of good stuff.

To see how the drive is actually doing, we simply run SPEAR and look
at the errors for the drive. This is better than us trying to
interprete some obscure diagnostic's output. We know how to read
SPEAR listings and Field Service knows how to read it also (well,
mostly). There is seldom (if ever) disagreement as to how the drive
is performing.

If you are interested in the batch job, let me know and I'll mail it
to you. If you really want a program to do this, it is pretty easy to
cobble up a macro program that does PMAP%'s until the disk fills up
and then deletes pages. Alternatively, I remember a program called
DIRTST on the SWSKIT that has a verify command that reads from the
disk. You may want to try that.

Hope I've been of some help,

-- Thomas De Bellis
Columbia Computer Center
-------
5-Mar-86 08:32:16-PST,651;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 08:32:04-PST
Date: Wed 5 Mar 86 11:30:02-EST
From: Ken Rossman <[email protected]>
Subject: Re: My Intgration/Migration
To: [email protected], MRC%[email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: Message from "Stu Grossman <[email protected]>" of Wed 5 Mar 86 03:54:06-EST
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

sPANDex? PANDOS? PANDAmonium?
-------
5-Mar-86 12:00:35-PST,737;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 12:00:24-PST
Date: 5 Mar 1986 1459-EST
From: Bill Melohn <[email protected]>
To: Ken Rossman <[email protected]>, [email protected],
MRC%[email protected]
cc: [email protected], [email protected], [email protected]
Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224"
Subject: Re: My Intgration/Migration
Message-ID: <"MS11(5136)+GLXLIB5(0)" 12188341464.17.108.10760 at MARLBORO.DEC.COM>
References: Message from Ken Rossman <[email protected]>
of 5-Mar-86 1142-EST
In-reply-to: <[email protected]>

PANDora?

--------
5-Mar-86 14:29:36-PST,905;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 14:29:00-PST
Date: Wed 5 Mar 86 14:27:25-PST
From: Stu Grossman <[email protected]>
Subject: Re: Disk Exerciser for TOPS-20
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: Message from "Thomas De Bellis <[email protected]>" of Wed 5 Mar 86 07:02:31-PST

There is a program called PAGES that does a fairly good job of testing
disks. I beleive that it comes on the tools tape.

Basically, it can be used to generate and verify the contents of a set
of test files. You can control the number of files, and their size.
It also has some whizzies for controlling the data pattern and other
things.

Additionally, it also returns some performance figures for the set of
operations it was told to do.

Stu
-------
5-Mar-86 16:20:02-PST,742;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 16:19:44-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 5 Mar 86 12:55:30-PST
Date: Wed 5 Mar 86 12:50:12-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: My Intgration/Migration
To: [email protected]
cc: [email protected], MRC%[email protected], [email protected],
[email protected], [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12188350729.8.MRC@PANDA>

Hmm. My 2020's MONNAM.TXT is "4664 Pandamonium Reigns!"...
-------
5-Mar-86 22:15:11-PST,4674;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 22:14:55-PST
Date: Thu 6 Mar 86 01:15:31-EST
From: Ken Rossman <[email protected]>
Subject: DEC20<->VAX DECnet: HELP!!!
To: [email protected]
cc: [email protected], [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

To those of you who enjoy figuring out tough DECnet datacomm problems,
here's a real toughie we've been working on for a long time now.

For the past month and a half, we have been trying to get a VAX 780 and a
DEC-20 (DN20) to talk to each other, but no matter what we try, no matter
what hardware we replace, we aren't able to get them to sign on.

Here is the initial link config information:

- The VAX-780 (CUCHEM) and the DEC-20 (CU20B) HAD been talking very well
for the past few years until this past mid January.
- They used a synchronous link, running at 19.2K baud, over Gandalf
LDS309 modems. A KDP (KMC11/DUP11 combination) is used on the 20
(DN20) end, and a DMR11 is used on the VAX end.
- The modems do the synch clocking.
- The DN20 is still Phase III DECnet (though the TOPS-20 system it is
attached to is TOPS-20 V6.1, Phase IV). The VAX is Phase IV (VMS 4.2).
- As far as we know or remember, no software changes were made to either
the 20 or the VAX across the period during which the link has not been
working.

When the link stopped working, an initial look revealed that the modem at
the VAX end had failed. This was replaced. However, these modems need
tuning for the particular line they are on, and during the tuning process,
special high speed modules (DIP chips) which allow the modems to run at
19.2K baud were damaged. The modems, therefore, had to be run at 9600.

Second round:

- LDS309's tuned for the line, and run at 9600 while new high speed
modules are put on order.
- Modems and wire seem to be working fine on the bit level. Bit error
rate tester shows bit samples over loopback at over a million bits and
no errors.
- DECnet loopback also works fine through both modems (i.e. from the 20
to the VAX's modem, and from the VAX through to the 20's modem).
- All loops are completely clean.
- Although bits and loopback packets seem to go through fine, when the
modems are placed in normal operation mode, the two machines simply
refuse to talk to each other.

Round three:

- We were able to dig up a new set of LDS309 modems which did not need
special high speed modules to run at 19.2K. We put these modems on
both ends of the wire, and are back up to 19.2K baud. This seems to
make a DMR happiest (9600 baud has never worked well with a DMR and
DECnet here for some reason).
- Again, the modems are properly tuned, and pass all bits through without
error, and DECnet loopback test packets just fine.
- While loops work fine, placing the modems in normal mode still does not
cause a proper DECnet signon to happen.

Round four:

- We finally decided to get a little smarter and put a data scope on the
link. We now have records of proper DECnet signon over a working link
and the attempted signon of this 20-VAX link.
- We seem to get the following DDCMP signon sequence:

START
START
STACK
ACK
DATA

after which, for some strange reason, the whole START, START, STACK,
ACK starts over again (no ACK or NAK of the data packet, and no
apparent timeout -- at least it seems to happen fast enough that it
would not seem to be a timeout condition).
- We are also seeing some very short packets coming across (far too short
-- like synchs a character or two, and then idle bits).
- Earlier in the evolution of this problem, we saw short packets also,
though they were only a byte or so short, AND we saw NAK packets, with
bad CRC reason codes (just what you'd expect). This was before today,
when we had the DMR in the VAX replaced. Now I am not sure exactly
what we've got. We haven't analyzed the latest DDCMP signon printouts
we got from the data scope tonight yet.

So there you have about a month and a half's worth of mess.

If ANYONE who has worked with DECnet at all has ANY ideas to offer
(particularly anyone at DEC who has worked with this level of signon, and
with synch modem connections of this type) has anything to offer at all,
PLEASE speak up. We are out of things to try.

/Ken
-------
5-Mar-86 23:41:51-PST,605;000000000000
Return-Path: <@MC.LCS.MIT.EDU:[email protected]>
Received: from MC.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 5 Mar 86 23:41:32-PST
Received: from SPEECH.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 6 MAR 86 02:41:39 EST
Date: Wed 5 Mar 86 14:41:01-EST
From: John Wroclawski <JTW%[email protected]>
Subject: Emulex DH?
To: [email protected]
cc: [email protected]

Anybody know for sure whether you {can,can't} use an Emulex DH replacement
on an unmodified RSX20F FE? Assuming it works at all, can the wonderful (?)
RSX autobaud code deal with it?

thanks,
-john
-------

6-Mar-86 08:11:51-PST,595;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 08:11:36-PST
Date: Thu 6 Mar 86 08:12:10-PST
From: Bob Knight <[email protected]>
Subject: Re: Emulex DH?
To: JTW%[email protected], [email protected]
In-Reply-To: Message from "John Wroclawski <JTW%[email protected]>" of Thu 6 Mar 86 00:14:21-PST
Message-ID: <[email protected]>

I dunno for sure about an Emulex, but I've used Dilog and Able boards with
success. However, this was before the advent of the new autobaud code.

Bob
-------
6-Mar-86 11:22:21-PST,981;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 11:22:10-PST
Date: Thu 6 Mar 86 10:53:20-PST
From: Stu Grossman <[email protected]>
Subject: Re: DEC20<->VAX DECnet: HELP!!!
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: Message from "Ken Rossman <[email protected]>" of Wed 5 Mar 86 23:15:08-PST

You may be getting bitten by Routing passwords verification. I beleive
that the VAX may be requiring a valid password from the DN20's routing
layer before it will talk to it. The command on the VAX that controls
this is in NCP. I beleive that it's called SET CIRCUIT PASSWORD, or
maybe SET EXECUTOR VERIFICATION ON/OFF.

You can also alter the password in the DN20 by hacking one of the
files output by NETGEN. I beleive the file you want is a .M11 (or .MAC)
file, and the password is DECNET-20 or something like that.

Stu
-------
6-Mar-86 12:38:24-PST,885;000000000000
Return-Path: <[email protected]>
Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 12:38:03-PST
Date: Thu 6 Mar 86 15:17:56-EST
From: Eric R. Crane <[email protected]>
Subject: Re: Emulex DH?
To: JTW%[email protected]
cc: [email protected]
In-Reply-To: Message from "John Wroclawski <JTW%[email protected]>" of Thu 6 Mar 86 02:52:07-EST
Office: Ucc 134, (412) 268-3568
Secretary: Ava Ford, (412) 268-2638
Message-ID: <[email protected]>

We are using them on 6 of our 20's here for a total of 80 lines per
system. I did not have to make any changes to V15-15, except for the
supplied patches. We did have some problems with the Unibus terminators
though, I can not remember what, and since the person who did the work is
nolonger around I can not find out what it was.

- Eric Crane
Carnegie Mellon
-------
6-Mar-86 18:03:55-PST,1020;000000000000
Return-Path: <[email protected]>
Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Thu 6 Mar 86 18:03:41-PST
Received: from philabs.UUCP by seismo.CSS.GOV with UUCP; Thu, 6 Mar 86 21:02:28 EST
Received: by philabs.uucp (4.12/3.14)
id AA08175; Thu, 6 Mar 86 07:52:31 est
Date: Thu, 6 Mar 86 07:52:31 est
From: <[email protected]>
Return-Path: <philabs!nyit!rick>
Message-Id: <[email protected]>
To: [email protected]
Subject: FB%NDL fix again

Mark's fix is good, but this fix is probably what DEC would
really want:

In subr DELFIL in DISC.MAC, move the two lines that read

SETZRO FBADR,(D)
CALL UPDDIR

down lower so they follow the lines

TXNE A,FB%NDL
JRST [ MOVEI A,DELX13 ;YES - RETURN AN ERROR
JRST DELFIX]

This performs the test for FB%NDL *before* blasting the index block address
and updating the directory. (It also makes the comments read more sensibly!)

rick ace
[email protected]

7-Mar-86 01:17:08-PST,1114;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 01:16:58-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Fri 7 Mar 86 01:19:01-PST
Date: Fri 7 Mar 86 01:12:40-PST
From: Mark Crispin <MRC%[email protected]>
Subject: another FB%NDL bug
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12188748034.8.MRC@PANDA>

Just when you thought it was safe to twiddle the FDB bits at night...You
have entered the FB%NDL zone!

Problem:
You can rename a file on top of a file that is FB%NDL. The pages of
the former FB%NDL file are lost to the system.

Diagnosis:
The code in DSKREN blithly assumes that it is alright to ignore errors
from DSKDEL because it always fails in the DSKREN case. This is wrong, but
on the other hand by the time we get to that point we have already nuked the
source FDB and we had better go through with the rename or we will nuke the
source file.

Solution:
Coming soon to a mailbox near you.
-------
7-Mar-86 12:03:45-PST,567;000000000000
Return-Path: <HAMMON%[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 12:03:20-PST
Date: Fri, 7 Mar 86 20:02 GMT
From: HAMMON%[email protected]
Subject: RE:DEC20<->VAX: HELP!!!
To: [email protected]

From: Randy Hammon <HAMMON@LLL.MFENET>
To: sy.ken@cu20b.arpa
cc: tops20@SU-SCORE.ARPA

I had some trouble of a similar flavor and had to fix it by( at the vax end )
issuing "set node ""your dn20 node number"" receive password decnet20"
to ncp. Evidently the password it's looking for is DECNET20.
-------
7-Mar-86 12:27:23-PST,648;000000000000
Return-Path: <[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 12:27:06-PST
Received: ID <[email protected]>; Fri 7 Mar 86 15:08:11-EST
Date: Fri 7 Mar 86 15:08:07-EST
From: [email protected]
Subject: Address space query
To: [email protected]
Message-ID: <[email protected]>

Could someone enlighten me as to what is necessary to create a new monitor
section? We have run out of room in MNTSEC for the host table, so I want to
move it to its own section. What data structures do I need to add, what to I
have to tell the pager at initialization, etc.?

--Vince
-------
7-Mar-86 13:05:25-PST,639;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 13:05:11-PST
Date: 7 Mar 1986 1604-EST
From: Tom Blinn <[email protected]>
To: tops20@su-score
Subject: Computervision CADDS 4 workstation query
Message-ID: <"MS11(5136)+GLXLIB5(0)" 12188877637.19.275.6882 at MARLBORO.DEC.COM>

Is anyone out there using a Computervision CADDS 4 workstation with TCP/IP to
network with TOPS-20? If so, was the hookup reasonably straight-forward? What
application support is TOPS-20 providing for the workstation? Any information
will be appreciated.

Tom Blinn
--------
7-Mar-86 14:50:05-PST,1266;000000000000
Return-Path: <budd%[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 14:49:29-PST
Received: from bostonu by csnet-relay.csnet id aj02042; 7 Mar 86 17:22 EST
Received: by bu-cs.ARPA (5.31/4.7)
id AA00290; Fri, 7 Mar 86 16:44:48 EST
Return-Path: <budd@bucsd>
Received: by bucsd.ARPA (5.31/4.7)
id AA00409; Fri, 7 Mar 86 16:45:01 EST
Date: Fri, 7 Mar 86 16:45:01 EST
From: budd%[email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: TOPS-20 vs. Solar Wind

A month ago we installed a pair of SUN-3's; the two systems share
major filesystems via NFS over the "house" ethernet (pending arrival
of additional hardware). Ever since the binary system went into
production (15 users each), we have had problems with our '20. The
twenty is unable to run for more than a day or two (usually about 24
hours) before we are crushed by screaming BUGxxxs. KNIFQE/IPIBLP is
most common among other internet BUGs. This occurs even with a
VANILLA DEC monitor.

The monitor we run is 5.4(1025), which is postively ancient. Has this
problem been previously diagnosed or cured?

Thanks!!
Phil Budne
Boston University / Distributed Systems

7-Mar-86 16:48:10-PST,2204;000000000000
Return-Path: <ridder%[email protected]>
Received: from decwrl.DEC.COM by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 16:47:51-PST
Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.03/4.7.34)
id AA16125; Fri, 7 Mar 86 16:49:45 pst
Message-Id: <[email protected]>
Date: Friday, 7 Mar 1986 16:46:09-PST
From: ridder%[email protected] (Hans)
To: tops20@su-score
Subject: Re: DEC20<->VAX DECnet: HELP!!!

Date: 7 Mar 1986 1741-MST
From: Hans <RIDDER at WARLOK>
To: "TOPS20@SU-SCORE" at DECWRL
Subject: Re: DEC20<->VAX DECnet: HELP!!!
Message-ID: <"MS10(2137)+GLXLIB5(0)" 12188917193.10.143.84173 at WARLOK.TCP>

If it is the vax which starts over with the DDCMP START, then what you
have is a Router Verification rejection. (You might try turning on
logging of DECnet events to the console to verify this.) VMS thinks
that phase III nodes should do verification /even if you tell it NOT
to!/ The DN20 sends a password of DECNET20 by default so what you
want to do is tell the vax about it like this:

NCP> SET NODE DN20:: RECEIVE PASSWORD DECNET20
NCP> DEFINE NODE DN20:: RECEIVE PASSWORD DECNET20

using NCP on the vax (DN20:: is whatever your DN20's name is). Also,
while we're on the subject of phase III/phase IV problems, if you
have a problem with the DN20 setting the circuit state to OFF whenever
it (or the vax) crashes, try this one:

NCP> SET CIRCUIT <circuit to DN20> TRANSPORT TYPE ROUTING 3
NCP> DEFINE CIRCUIT <circuit to DN20> TRANSPORT TYPE ROUTING 3

to the vax also (substitute the proper name of the circuit going TO the
DN20). This tells the vax to never send a phase IV packet to whatever
is on the other end of the circuit. The DN20 code is quite paranoid
and shuts off the circuit whenever it gets a packet it doesn't
understand (contrary to DECnet specifications).

For those who don't understand the difference between SET and DEFINE,
SET changes the "volitile" database which only lasts until the next
re-boot, DEFINE changes the "permanent" database which is used a boot
time to initialize the volitile database (in other words DEFINE makes
it stick!).

-hans
--------
7-Mar-86 17:03:49-PST,740;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 17:03:24-PST
Date: Fri 7 Mar 86 18:02:56-MST
From: Mark Crispin <[email protected]>
Subject: Re: TOPS-20 vs. Solar Wind
To: budd%[email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Telephone: +1 (415) 968-1052
Message-ID: <[email protected]>

KNIFQE/IPIBLP generally indicate a paucity of buffers. Some work was
done in July '84 to alleviate this problem; this was UPD ID 212,
IPNIDV.MAC.68.

It shouldn't be hard to fix this problem. I wonder if your SUNs are
in broadcast-happy mode?
-------
7-Mar-86 17:08:50-PST,1972;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 7 Mar 86 17:08:31-PST
Date: 7 Mar 1986 2007-EST
From: Bob Longo <[email protected]>
To: Ken Rossman <[email protected]>, [email protected]
cc: [email protected]
Mail-Stop: LAO
Phone: 213-417-4240
Subject: Re: DEC20<->VAX DECnet: HELP!!!
Message-ID: <"MS11(5136)+GLXLIB5(0)" 12188921888.14.355.12342 at MARLBORO.DEC.COM>
References: Message from Ken Rossman <[email protected]>
of 6-Mar-86 0151-EST
In-reply-to: <[email protected]>

I have seen situations similar in the past. I would look VERY carefully at the
DMR switch settings. I has the ability to talk to both DDCMP version 4.0 and
(with the switch in the other setting) to prior versions. I had this problem
when I tried to connect a DMR and a DMC together. It took some doing to
get the combinations correct. Here is what I have found to work:

Switch Pack Settings
=========== ========

E134 1-9 off, 10 on

E121 1-8 on, 9 off, 10 on

E39 1-7 off, 8-9 on, 10 off

Another gotcha can be the distribution panel for the DMR. I found that the
panel comes from the factory set so that Field Service can run diagnostics,
but will not work when you try to hook it up to a modem. So, look also
at the H3001 switch settings (field service is supposed to know how to
properly set them).

I have also run up against problems with modems that do not signal properly,
e.g., they work for an IBM system, but not with ours. We had to use some
very fancy equipment to see in what order signals were raised, as the
software in the DN20 waits for a proper sequence before proceeding. I doubt
this is your problem, but you may want to keep it in mind.

Good luck and let me know what the solution turns out to be.
--------
9-Mar-86 11:48:45-PST,6986;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 9 Mar 86 11:48:35-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 9 Mar 86 11:38:11-PST
Date: Sun 9 Mar 86 01:44:50-PST
From: Mark Crispin <MRC%[email protected]>
Subject: FB%NDL: The Final(?) Chapter
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12189278179.2.MRC@PANDA>

After a lot of work, I've come to the conclusion that FB%NDL
was never completely implemented by DEC. It turns out that it
was never set for the root-directory files it was supposed to be
set for, nor were the implications for rename considered, and
it's obvious that the DELFIL (which expunges a file) check for
FB%NDL was never tested.

I have fixed all of these problems in the PANDA monitor. I
won't bother with listing the root-directory files changes, since
setting FB%NDL can always be done by hand. Those changes are
fairly obvious, if tedious, ones to FILINI and DSKALC. All the
other changes below are to DISC.

Fixing DELFIL was fairly simple. I elected to adopt Rick
Ace's suggested fix, which is to move the lines:
SETZRO FBADR,(D) ;REMOVE XB ADR FROM DIR
CALL UPDDIR ;UPDATE DIRECTORY, FILE IS EFFECTIVELY
at DELFIL+16L down so that it comes after the lines:
TXNE A,FB%NDL ;IS THIS FILE MARKED "NEVER DELETE"?
JRST [ MOVEI A,DELX13 ;YES - RETURN AN ERROR
JRST DELFIX]
and before the line
MOVE A,P3 ; GONE AFTER THIS POINT.

Fixing DSKREN was more complicated. First, I decided that a
file that is set FB%NDL should be disallowed as the source or
destination of a rename. There are ways to avoid both of these,
but I felt semantically that a file that you care enough about
that you disallow deletion even by privileged users should not
have its data pages renamed away or destroyed.

If you wish to allow the source file of a rename to be
FB%NDL, then you should not include the check for it or the
RENDF1 bugchk. What will happen if you rename an FB%NDL file
will be that the data pages will be renamed to the destination
file, but the source FDB will not be destroyed and will remain as
an empty file.

If you wish to allow the destination file of a rename to be
FB%NDL, then you should not include the check for it. You will
need to do some work in the DELFIL loop for the destination file;
probably the best way would be to temporarily turn off FB%NDL at
the same time FB%PRM is turned on before the loop, then undo the
mischief after the DELFIL succeeds.

I haven't extensively exercised these possibilities, as I
was more interested in making RNAMF% involving an FB%NDL file not
lose pages from the filesystem and (as noted above) I think that
a file that is "undeleteable" should not be "deleteable" by
allowing its rename elsewhere or its being renamed over.

I should note that an FB%NDL file can be overwritten by a
program that opens that generation for write. Also, a new
generation of the file can be written. This seemed consistant
with my perception of the semantics of FB%NDL -- a file that can
be updated, but cannot be deleted.

The changes to DSKREN follow.

At DSKREA+20L, after:
TXNE B,FB%LNG ;IS IT A LONG FILE
SETOM DSKTYP ;YES - INDICATE
insert:
TXNE B,FB%NDL ;IS DESTINATION FILE MARKED "NEVER DELETE"?
RETBAD (DELX13,<CALL USTDIR>) ;YES, DISALLOW
This will disallow destination files in RNAMF% from having FB%NDL
set.

At DSKREO+2L, after:
MOVE A,SRCFDB ;RESTORE SOURCE FDB
insert:
TMNE FB%NDL,.FBCTL(A) ;IS SOURCE FILE MARKED "NEVER DELETE"?
RETBAD (DELX13,<CALL DSKRE8>) ;YES, DISALLOW
This will disallow source files in RNAMF% from having FB%NDL set.

At DSKRE1+39L, after:
CALL DELFIL ;...
replace:
JFCL ;MIGHT COME HERE IF PERMANENT
with:
IFNSK.
;;; DELFIL failed for a miscellaneous reason (not permanent as DEC's comment
;;;states). This isn't very serious, since the file pages are being moved by
;;;us. However, an old crufty FDB has been left behind, so we log it.
MOVE A,DIRORA ;GET BASE ADDRESS OF DIR
LOAD A,DRNUM,(A) ;GET DIR # OF MAPPED DIR
LOAD B,CURSTR ;GET THE STRUCTURE NUMBER
BUG.(CHK,RENDF1,DISC,SOFT,<DSKREN: DELFIL failed on source file>,<<A,DIR>,<B,STR>>)
ENDIF.
This will bugchk RENDF1 any failure to eliminate the FDB of the
source file (the file pages have already been removed). This
generally will happen only when the archiving system is sick or
in some wierd file opening timing race. It will not happen if
the source FDB is permanent, in spite of the DEC comment.

27 lines further down, replace:
CALL DELFIL ;DELETE OLD CONTENT OF DESTINATION
JFCL ;ALWAYS FAILS SINCE PERMANENT BIT SET
with:
;;; If DELFIL fails, it isn't because the FDB was permanent. Whatever the
;;;condition was, if there is an index block address we had better correct
;;;it otherwise we'll lose disk pages.
DO.
CALL DELFIL ;DELETE OLD CONTENT OF DESTINATION
SKIPN .FBADR(D) ;LOST, IS THERE AN INDEX BLOCK?
EXIT. ;WON OR NO INDEX BLOCK, CONTINUE
MOVX B,FB%NDL ;"HOUSTON, WE HAVE A PROBLEM HERE"
TDNN B,.FBCTL(D) ;DID IT GET MARKED "NEVER DELETE"?
IFSKP.
ANDCAM B,.FBCTL(D) ;YES, MUST BE A TIMING RACE, BUT WE MUST WIN
LOOP. ; IT, SO NUKE THE BIT AND DO IT AGAIN
ENDIF.
IFQN. FBARC,(D) ;HAVE ARCHIVE STATUS?
MOVX B,AR%NDL ;YES, SEE IF PROHIBITED
TDNN B,.FBBBT(D) ;WELL?
ANSKP.
ANDCAM B,.FBBBT(D) ;THAT'S THE PROBLEM, NUKE THAT BIT
LOOP. ;TRY IT AGAIN
ENDIF.
CAIE A,DELFX2 ;DESTINATION FILE BUSY?
BUG.(HLT,RENDF2,DISC,SOFT,<DSKREN: Impossible DELFIL failure>)
MOVX A,^D1000 ;UGH. CAN'T DO MUCH ABOUT THIS
DISMS% ;WAIT A SECOND
LOOP. ;NOW TRY AGAIN
ENDDO.
This catches all the conditions where the destination file's old
index block could not be deleted. The AR%NDL condition is pretty
unlikely since AR%RAR should also be set which would have been
nabbed by ARACCK early on. However, it is possible although
unlikely that a race condition could have set this, as it could
have set FB%NDL. At this point we have already removed the index
block from the source FDB, so we really do want to plop it down
in the destination FDB -- this is why I decided to nuke any
AR%NDL or FB%NDL bits which may have been set by a race since
(1) the condition is unlikely
(2) if it happens it was probably deliberately provoked by a
hacker
(3) the alternative is to lose disk pages
I am less happy about the DELFX2 handler, but if that particular
situation happens there is relatively little that can be done.
I'd still claim that it is highly unlikely to happen in an
uncontrived situation and so again the goal should be to seek for
the means that does not lose disk pages.

-- Mark --
-------
11-Mar-86 16:37:16-PST,1029;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 11 Mar 86 16:37:01-PST
Date: Tue 11 Mar 86 19:39:14-EST
From: Frank da Cruz <[email protected]>
Subject: TOPS-20 LAT Service
To: [email protected]
Message-ID: <[email protected]>

TOPS-20 LAT service apparently does not allow 8-bit transparent terminal
i/o. Binary files cannot be sent to DEC-20 Kermit through a LAT box
(DECserver 100) unless you give SET PARITY commands to Kermit to force it
to use 8th-bit prefixing. The same binary files can be sent to DEC-20 Kermit
through a regular terminal port without having to use 8th-bit prefixing.
In other words, all the SFCOC's, MTOPR's, SFMOD's, STPAR's, and STIW's you
must do to make the terminal transparent just don't work for a LAT terminal.
By contrast, Ultrix LAT service does not pose this problem -- opening a
LAT terminal in raw mode in Ultrix works just like opening a regular terminal
in raw mode.
-------
12-Mar-86 14:08:34-PST,1167;000000000000
Return-Path: <[email protected]>
Received: from anl-mcs.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:08:13-PST
Received: by anl-mcs.ARPA (4.12/4.9)
id AA06095; Wed, 12 Mar 86 16:11:35 cst
Date: Wed, 12 Mar 86 16:11:35 cst
From: [email protected] (Nugent)
Message-Id: <[email protected]>
To: tops-20@su-score
Subject: Tops-20 TCP NVT question
Cc: [email protected]

Problem: The ATNVT% JSYS does not like to attach NVTs to TCP
connections which are not new. However, I want to have
a Deamon read a few characters on a connection and then
start up a job on an NVT depending on what it reads (RSHD).

Does anyone know of a way to work around this? I have tried the obvious
ways:
Open another JFN with a different local port #. Althought
the MCRF says this is possible, the local port is forced to
be the same.

Setting TCP PUSH on receive doesn't help because there are still
buffers allocated.

The BBN code does not like you to close and reopen the connection,
even if I could get the remote host to cooperate.

Various attempts to close and flush buffers with TCOPR% generate
ILPTN1 bughlts.
12-Mar-86 14:19:14-PST,833;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:18:25-PST
Date: Wed, 12 Mar 1986 17:20 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected] (Nugent)
Cc: [email protected]
Subject: Tops-20 TCP NVT question
In-reply-to: Msg of 12 Mar 1986 17:11-EST from [email protected] (Nugent)

I'm pretty sure you can't get there from here, because once you have
read from the connection as a file you have all sorts of buffers
irrevocably allocated (some of them in the layer between the JFN and
JCN interfaces, some of it in the depths of the BBN code).

If you ever figure out how to do this, let me know. I could get
incoming TCP SUPDUP running in ten minutes if I could get around this.
12-Mar-86 14:30:11-PST,716;000000000000
Return-Path: <[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:29:48-PST
Date: Wed 12 Mar 86 15:31:44-MST
From: Walt <[email protected]>
Subject: Re: Tops-20 TCP NVT question
To: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

For my TOPS-20 implementation of the Unix daemons, I eventually punted
on this problem by having the daemon do a passive open, and start a
new copy of itself as soon as the TCP connection completed. This was
done on a straight TCP JFN not an NVT however.

If you come up with a more elegant solution let me know!

Cheers -- Walt
-------
12-Mar-86 14:57:27-PST,1066;000000000000
Return-Path: <[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 14:57:03-PST
Received: ID <[email protected]>; Wed 12 Mar 86 17:59:48-EST
Date: Wed 12 Mar 86 17:59:46-EST
From: [email protected]
Subject: Re: Tops-20 TCP NVT question
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

One hack you could try would be to ATNVT% the jfn and then ASND% the TVT. You
can then read some stuff from the TVT and when you're done, CRJOB% a new job
onto the NVT (doing a RELD% might be sufficient). The problem with this is that
there is a race condition between the ATNVT% and the ASND% and I don't think
that ATNVT% will pick a TVT that has already been ASND%'ed (so you can't assign
it first, and then ATNVT% to avoid the race condition). You could probably hack
it with some small monitor mods (maybe add an argument to ATNVT% that is the
TVT device designator to use?)

--Vince
-------
12-Mar-86 16:09:08-PST,1009;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 16:08:45-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 12 Mar 86 16:13:15-PST
Date: Wed 12 Mar 86 15:34:26-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: Tops-20 TCP NVT question
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12190215633.11.MRC@PANDA>

The easiest way to solve the problem is to have the job being
started do the work. That is, instead of CRJOB%'ing the job to have
an EXEC or whatever CRJOB% it to have a "pre-EXEC" that does your
work and replaces itself with whatever program you want.

Not only does this method work and is the point of least resistance,
it's also the easiest way to do what you want to do even if ATNVT% didn't
have that restriction!
-------
12-Mar-86 16:32:57-PST,2346;000000000000
Return-Path: <[email protected]>
Received: from columbia.edu by SU-SCORE.ARPA with TCP; Wed 12 Mar 86 16:32:34-PST
Received: by columbia.edu (5.31/5.10) id AA05486; Wed, 12 Mar 86 19:35:38 EST
Received: by cucca.columbia.edu; Wed, 12 Mar 86 19:36:46 est
Date: Wed, 12 Mar 86 19:36:46 est
From: Charlie C. Kim <[email protected]>
To: [email protected]
Subject: The DEC-20 KNI and DEQNAs: one last update

The KNI will receive size 64 ARP packets--if you push the minimum
packet that it will accept over that by at least 2. The problem
probably lies with the KNI or the specification for the KNI. It seems
packets which are close to the posted maximum (within 2 bytes) are
corrupted. If so, then the same problem should also occur for IP
packets which have a maximum of 1500 (in our monitor at least), but I
haven't tested this yet (something to look for if you are having
problems with large packets though...).

The following patches to IPNIDV makes tops-20 allow "68" byte ARP
packets (effectively, 66 bytes - better safe than sorry, I hate
rebooting the 20s):

-------
EMINPL==^D46 ;MINIMUM ETHERNET PACKET LENGTH
ncu307,<
MINPKT==EMINPL+4 ;MINIMUM ETHERNET PACKET LENGTH PLUS CRC BYTES
>
cu307,<
MINPKT==EMINPL+4+8 ;MINIMUM ETHERNET PACKET LENGTH PLUS CRC BYTES
;plus 8 spill over bytes for silly machines
>

--------

; If AR.LEN is less than MINPKT (Ethernet minimum packet size
; plus 4 bytes for the CRC) we must make the ARP packets atleast
; that size.

NCU307,<
IFL AR.LEN-EMINPL,<

AR.WRD==<MINPKT/4>+4 ;WORD SIZE OF ARP PACKET (PLUS A COUPLE)
AR.LEN==EMINPL ;BYTES IN ARP PACKET ARE ETHERNET MINIMUM
AR.MAX==MINPKT+4 ;MAX BFR SIZE WITH ETHERNET CRC (PLUS 4)

>
>
CU307,<
IFL AR.LEN-EMINPL,<
ar.wrd==<<minpkt+3>/4>; compute the # of words needed,
AR.LEN==EMINPL ;BYTES IN ARP PACKET ARE ETHERNET MINIMUM
AR.MAX==MINPKT ;max buffer size includes all the junk
;we need
>
>
--------

Phew, glad to get this out the way (seems like every time I ignored it
and fixed the other device, we would get something else that would
send oversized packets and we finally got something we don't have
source code for yet.)

Charlie C. Kim
User Services Group
Academic Information Systems Division
Columbia University
-------

13-Mar-86 11:38:11-PST,2162;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 13 Mar 86 11:37:53-PST
Date: Thu 13 Mar 86 14:40:53-EST
From: Frank da Cruz <[email protected]>
Subject: TOPS-20 LAT service vs Kermit, cont'd
To: [email protected]
Message-ID: <[email protected]>

Disregard last message... Turns out that, unbeknownst to me, the behavior
reported previously occurred from a PC that was connected by LAT to a VAX
Ultrix system that was TELNET'd to a DEC-20 via TCP/IP over Ethernet, and it
was TELNET stripping the high order bit, not LAT. However, there is still a
problem with DEC-20 LAT service. The symptom is that you can't transfer files
of any kind into a DEC-20 through LAT using Kermit or Modem or any similar
protocol. You can, however, transfer files from the DEC-20 to the PC with no
problem. Logging of a file transfer reveals that a typical Kermit data packet
(80-90 characters) is truncated by the LAT box to 30-40 characters. If you
reduce the Kermit packet size to, say, 37, then everything works, even binary
files without 8th-bit prefixing.

The mystery is that everything works fine when the host is a VAX Ultrix
system rather than a DEC-20. Therefore, the LAT box itself is not at fault;
the culprit must the TOPS-20 LAT service.

In fact, the LAT specification says LAT_MIN_RECV_SLOT_SIZE should be in the
range 1-255, and 127 is recommended. The TOPS-20 6.1 monitor's LATSRV module,
however, sets the corresponding symbol MXSLSI to 40 (decimal). We haven't
tried changing the monitor to increase this number, and are not sure what the
consequences would be.

For now, those who want to use Kermit to send files to a DEC-20 through a
LAT box must set their packet size to 37 or less. Those who want to use MODEM
will have to use Kermit instead, since MODEM packet sizes cannot be changed.

This note does not address the other problems we've been having with TOPS-20
LAT service, like random disconnections, etc. We noticed that several of the
other recommended parameter settings are not followed in LATSRV.
-------
14-Mar-86 06:34:13-PST,398;000000000000
Return-Path: <[email protected]>
Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Fri 14 Mar 86 06:34:03-PST
Received: ID <[email protected].#Internet>; Fri 14 Mar 86 09:38:27-EST
Date: Fri 14 Mar 86 09:38:26-EST
From: [email protected]
Subject: edt20
To: [email protected]

Does anyone know where I can find EDT20? I have the manuals but can't
find the executable.
Aaron
-------
15-Mar-86 01:41:26-PST,2135;000000000000
Mail-From: BILLW created at 15-Mar-86 01:41:22
Date: Sat 15 Mar 86 01:41:22-PST
From: William "Chops" Westfield <[email protected]>
Subject: new monitor sources probably ready for RDIST...
To: [email protected]
Message-ID: <[email protected]>

I think that the monitor currently running on Score has shown
itself stable enough to warant distributing the latest changes
to other Stanford tops20 sites. Some important fixes have been
made in the network code, and now that most ethertips are using
TCP, these fixes are becomming quite important:

1) Fix IPGCOL/INTFR6 buginf/bugchk/problems, effectively by
replacing the IPFREE module with a new version from BBN.
2) allow more connections. The defaults are now to have 32
TVTs (score is running with this set to 50 in PARSCO.MAC),
and to have the total number of TCP connections be the
number of TVTs plus 25. A test in STG that complained
about "too many wait bits" has been made more reasonable;
TVTs use many fewer wait bits than a full BBN TCP connection,
and DEC JFN connections use fewer than STG used to assume.
3) TCB used to be looked up for each packet arriving via a
has table hashed off of the local port. When 90% of the
connections were on the same local port (telnet), this
was not such a good idea, so the table is now hashed off
the foreign host and ports also (rewrite CHKADD).
And the hash table was made a lot larger...
4) A bug that may have caused extra empty packets to be sent
to TVTs has been eliminated, I think. The code was not
distinguishing between the case where a packet HAD to
be sent (eg, as an ACK) and the case where a packet
SHOULD be sent (eg because there was data). It does now.
5) Miscellaneous minor fixes...

Modules effected: PARAMS, STG, TVTSRV, TCPTCP, ANAUNV, IPFREE
(On score in <6-1-MONITOR>)

Enjoy
BillW

PS The actual TCP code may remain stable for a while - now that TCP
is not causing daily problems (though it still isn't as efficient
as pup), the next project is to get the ISI/MIT domain code working.
-------
15-Mar-86 17:32:34-PST,2076;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 15 Mar 86 17:32:21-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sat 15 Mar 86 17:34:15-PST
Date: Sat 15 Mar 86 16:48:16-PST
From: Mark Crispin <MRC%[email protected]>
Subject: DTR control patch
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191015506.11.MRC@PANDA>

By popular demand, I am publishing the latest and greatest
DTR control patch. It is in the form of a MIC file. Note the
instructions at the bottom of the patch, which are necessary to
actually enable the patch. You will have to do this manually
since it is different between release 5.1 and release 6.1.

This patch enables two new TTY MTOPR% functions. Function
400003 will hang up the given terminal line, function 400004 will
pick it up. This is compatible with the functions in Stanford
and PANDA monitors, where these functions are given the symbolic
names .MOHUP (hang up) and .MODUP (DTR up).

This patch uses function .DFLDU (15) to DTEQ, which is
supported from the KL to the -11 only in the more recent versions
of RSX-20F. If you have an older version of RSX-20F, you'll get
an 11-HALT (ILF or some such) when you try to use function
400004. In that case, get a new version of RSX-20F from DEC.

@GET SYSTEM:MONITR
@START 140
*FFF/DTRPAT:CAIE T3,400003
*DTRPAT+1/JRST DTRPAT+4
*DTRPAT+2/CALL TTHNGU
*DTRPAT+3/JRST RSKP
*DTRPAT+4/CAIE T3,400004
*DTRPAT+5/RET
*DTRPAT+6/JSP CX,SAVT
*DTRPAT+7/MOVE A,MSTRDT
*DTRPAT+10/MOVS C,B
*DTRPAT+11/SKIPA B,.+1
*DTRPAT+12/15,,.FEDLS
*DTRPAT+13/CALL FIXARG
*DTRPAT+14/HLRZ D,C
*DTRPAT+15/SETZ C,
*DTRPAT+16/CALL DTEQI
*DTRPAT+17/JRST RSKP
*DTRPAT+20/FFF:

! Now look at TTMTOP+7 (release 6.1) or TTMTO1+4 (release 5.1). It
! jumps to a literal which has a MOVEI T1,MTOX1 followed by a RET.
! Patch the RET to JRST DTRPAT. Then type CTRL/Z followed by
! SAVE SYSTEM:MONITR.EXE.
-------
16-Mar-86 00:14:42-PST,730;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 16 Mar 86 00:14:31-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 16 Mar 86 00:16:30-PST
Date: Sat 15 Mar 86 23:25:47-PST
From: Mark Crispin <MRC%[email protected]>
Subject: GFLOAT format
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191087871.11.MRC@PANDA>

It appears that KS10's don't implement GFLOAT format floating point.
Does anybody know of any version of the KS10 microcode that does? I was
under the impression that unlike KL's there was a fair amount of free
microcode space in the KS.
-------
16-Mar-86 00:53:31-PST,591;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 16 Mar 86 00:53:21-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 16 Mar 86 00:35:27-PST
Date: Sun 16 Mar 86 00:01:42-PST
From: Mark Crispin <MRC%[email protected]>
Subject: for your amusement!
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191094411.11.MRC@PANDA>

Get a close look at SPR 20-20966 in the 15 February 86 Dispatch, specifically
at the PHOTO output...
-------
16-Mar-86 01:55:50-PST,1436;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 16 Mar 86 01:55:43-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 16 Mar 86 01:54:42-PST
Date: Sun 16 Mar 86 01:04:55-PST
From: Mark Crispin <MRC%[email protected]>
Subject: SPR 20-19605A (in December '85 CTCO)
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191105920.11.MRC@PANDA>

I am skeptical of DEC's patch for this. Basically, they
have decided that ACJ denials should be respected for logouts due
to the timer after a carrier-off interrupt expiring. They've
decided that if this happens the job should go and wait for
another COFTIM interval and keep on waiting and asking ACJ until
the user attaches or the ACJ says OK.

The problem with DEC's patch is that they glibly eliminate
the entry to JSYS context (which would destroy any possibility of
returning to the interrupted code) in the ACJ check. This might
be alright, but they do a GTDAL% JSYS which probably is *not*
alright to do from exec mode unless you're in JSYS context!
Worse, there are a couple of places that the code can get to
FLOGO1 without entering JSYS context.

I would suggest as a start that the GTDAL% be replaced with
CALL IGTDAL and that the FLOGO1 jumps be made to go through the
MCENTR path.
-------
17-Mar-86 09:22:54-PST,779;000000000000
Return-Path: <[email protected]>
Received: from TE.CC.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 09:22:40-PST
Date: Mon 17 Mar 86 12:24:20-EST
From: Eric R. Crane <[email protected]>
Subject: Integration tools
To: [email protected]
Office: Ucc 134, (412) 268-3568
Secretary: Ava Ford, (412) 268-2638
Message-ID: <[email protected]>

I was going through list of integration tools in the Large Systems News, and
for the first time noticed VMAIL/VMAILR. I went to get the files off of the
tapes and found only the executables. Does anyone have the source to these?
I have an old version of VMAIL that we are using with MMAILR, but I am
interested in also being able to send mail to our Vaxen.

- Eric Crane
Carnegie Mellon
-------
17-Mar-86 10:43:33-PST,1875;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 10:43:15-PST
Date: 17 Mar 1986 1342-EST
From: Tom Blinn <[email protected]>
To: Eric R. Crane <[email protected]>
cc: tops-20@su-score
Subject: Re: Integration tools
Message-ID: <"MS11(5136)+GLXLIB5(0)" 12191473268.17.275.10192 at MARLBORO.DEC.COM>
References: Message from Eric R. Crane <[email protected]>
of 17-Mar-86 1248-EST
In-reply-to: <[email protected]>

Eric,

First, you probably have an older TOOLS tape. On the most recent TOPS-20
tapes, some sources were sent along with the executables. However, there
is no guarantee that the sources correspond to the binaries, or are all
you might need to rebuild the binaries (in fact, I can assure you that is
NOT the case -- sorry about that!).

VMAIL and VMAILR are/were unsupported internal tools for exchanging mail
between TOPS-20 and VMS systems, and were formerly shipped to SWS (Software
Specialists) as part of one of the SWSKIT tapes (I believe it was the DECnet
SWSKIT).

We're on the verge of releasing MS for both TOPS-10 and TOPS-20. It will
include a SUPPORTED mailer agent for exchanging mail with other systems on
a DECnet network, including but not necessarily limited to VAX/VMS systems.
It also works with TCP/IP, although I'm not sure of the details of which
mailer agent we're using. (I'm composing and sending this with our latest
internal field test version of the new MS.)

While I can't offer to send you the new software, I can assure you that you
would be better off just being patient for a little while yet, and waiting
for MS. You'll be glad you did.

Tom

PS: If you really want the VMAIL.MAC and VMAILR.MAC, you can anonymous
FTP them from MARKET, out of TOOLS:<TOOLS.VMAIL>*.MAC.
--------
17-Mar-86 13:01:43-PST,2858;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 13:01:32-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Mon 17 Mar 86 13:03:12-PST
Date: Mon 17 Mar 86 12:57:40-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: Integration tools
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191497816.8.MRC@PANDA>

Here's some information on the MM front re: DECnet mailing to VAXen,
for those of us who have no interest whatsoever in MS.

The primary problem with DECnet mailing to VAXen is that VMS uses a
goofy mail transport protocol called MAIL11 which (like many other DEC
protocols) is almost but not quite usable. I hope the membership of this
list will take my word on this and not require me to go into nauseating
details why.

There are two outs. The first, which I consider the superior approach,
is to use SMTP over DECnet. While SMTP isn't the Ultimate Mail Transport
Protocol either, at least it is usable for 7-bit text. It turns out that
there actually is an assigned DECnet service for it -- object TASK, name
MX-LISTENER. MMailr will deliver DECnet SMTP mail to this service, and the
MM-supplied SMTDCN utility will listen for incoming mail and fire up MAISER's
to handle it.

I know of several sites which have written VMS DECnet SMTP listeners
that talk to MMailr, most using the old interim 127 object (but presumably
easy to fix to use TASK MX-LISTENER). Despite repeated requests, none of
these sites have made their VMS software publicly available. The usual
excuse is "we're still working on it." If I don't get some software from
one of you soon I'll start naming names...

The other out which is barely acceptable as an interim solution is
to use a modified VMAIL/VMAILR to talk MAIL11 to VMS. There is a modified
version of VMAIL on the MM distribution directory ([SIMTEL20]<MM> for you
ARPA folks). There is also a version of VMAILR floating around that will
interact with a slightly modified MMailr (at some loss of MMailr performance).
The main problem with these tools are the protocol related ones and also that
you can only have one message coming into the -20 at a time.

I have been talking with various people at DEC about getting MMailr and
MX (the DEC DECnet equivalent of MMailr) to interact in nice ways. You can
expect progress in this area this year. However, to my thinking this will
only replacce VMAIL/VMAILR. This is great in itself but I still think the
best way is to go SMTP for all DECnet hosts, especially if you are also an
ARPA site. MAIL11 just has too many shortcomings.
-------
17-Mar-86 15:57:41-PST,925;000000000000
Return-Path: <[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 15:57:29-PST
Received: ID <[email protected]>; Mon 17 Mar 86 19:01:08-EST
Date: Mon 17 Mar 86 19:01:07-EST
From: [email protected]
Subject: Domain service query
To: [email protected]
Message-ID: <[email protected]>

Has anyone had any trouble using the ISI/BBN Domain server stuff for TOPS-20?
It was working fine here until a few days ago when some of the hosts suddenly
vanished from DSV's knowledge. MAKEDB gives no errors when processing the
source for our domain database and I can't see anything wrong with the domain
database either, but DSV doesn't think all records matching some pattern
(*.SEI.CMU.EDU, for the curious) exist. Are there any known bugs in the system
that would cause this or, can anyone think of something I might have missed?

Thanks,
--Vince
-------
17-Mar-86 17:03:57-PST,553;000000000000
Return-Path: <TAKANO%[email protected]>
Received: from hplabs.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Mar 86 17:03:43-PST
Received: from HP-HULK by hplabs.ARPA ; Mon, 17 Mar 86 17:04:29 pst
Date: Mon 17 Mar 86 17:04:47-PST
From: Haruka Takano <Takano%[email protected]>
Subject: 4M for rel 5?
To: Tops20%Score@HPLABS

I seem to remember a discussion a while back on this mailing list
about mods to allow 4M of memory on a system. Is this available
for release 5? Is anyone running with 4M? Thanks for any pointers.

--Haruka
-------
18-Mar-86 00:05:38-PST,1134;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Mar 86 00:05:28-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 18 Mar 86 00:07:29-PST
Date: Mon 17 Mar 86 23:28:31-PST
From: Mark Crispin <MRC%[email protected]>
Subject: Re: 4M for rel 5?
To: Takano%[email protected]
cc: [email protected]
In-Reply-To: Message from "Haruka Takano <Takano%[email protected]>" of Mon 17 Mar 86 23:04:55-PST
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191612659.8.MRC@PANDA>

You can't really have 4M on a KL system because the RH20 can't
do I/O to the last page. Leaving that aside, it is difficult to build
a 4M system for release 5 due to the address space eaten up by the
CST's -- you need 64 pages of section 1 address space. That's out of
the question for systems with networks, although it may be possible
to squeeze it for a non-network system that's otherwise intelligently
configured.

Release 6 systems fix this problem since the CST's are out of
section 1.
-------
18-Mar-86 00:41:32-PST,579;000000000000
Return-Path: <TAKANO%[email protected]>
Received: from hplabs.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Mar 86 00:41:16-PST
Received: from HP-HULK by hplabs.ARPA ; Tue, 18 Mar 86 00:41:21 pst
Date: Tue 18 Mar 86 00:41:36-PST
From: Haruka Takano <Takano%[email protected]>
Subject: Re: 4M for rel 5?
To: MRC%[email protected]
Cc: Takano%HP-HULK@HPLABS, [email protected]
In-Reply-To: Message from "Mark Crispin <MRC%[email protected]>" of Tue 18 Mar 86 00:07:19-PST

I thought that might be the case, but I wanted to make sure. Thanks.

--Haruka
-------
18-Mar-86 19:19:50-PST,2322;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Mar 86 19:19:37-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Tue 18 Mar 86 19:15:02-PST
Date: Tue 18 Mar 86 19:09:33-PST
From: Mark Crispin <MRC%[email protected]>
Subject: major change to 1822 (IMP) software
To: [email protected], [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12191827659.11.MRC@PANDA>

All sites should be aware of the changes to the ARPANET, Milnet, DRENET,
and other BBN IMP-based networks using the 1822 protocol that are announced
in RFC 979. This report, "PSN END-TO-END FUNCTIONAL SPECIFICATION" is a MUST
read by the site personnel responsible for the network software for every
host on these networks.

This report succumbs to the popular tradition of changing terminology
just as we've gotten accustomed to the old terminology. Basically, an IMP
is now called a PSN (Packet Switch Node) and the protocol/software that runs
on the IMP is now called EE (End-to-End protocol and module).

The most important changes are as follows:
(1) VDH hosts are no longer supported. If you're still a VDH, you had better
replace your VDH with a pair of ECU boxes, etc. I think VDH's are extinct
animals these days though.
(2) Uncontrolled (subtype 3) regular messages will no longer be supported.
This is being replaced by a new Datagram service.

All the other changes are upwards compatible and in general are wins.

I am concerned about change (2) above. TOPS-20 uses uncontrolled
regular messages and other operating systems may do so as well. For what
TOPS-20 does with uncontrolled regular messages it is alright to substitute
the datagram service for uncontrolled regular messages, but since there will
be no period of overlap between the two I'm concerned about flag days. I
would like to lobby for the new datagram service to be accessed by using a
subtype 3 regular message.

Incidentally, I am wondering whether or not it would be a good idea to
always use datagrams for TCP/IP packets. Perhaps this would increase
performance on the network if 1822 was spared the overhead of reliable
delivery?
-------
19-Mar-86 00:53:41-PST,4745;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 00:53:18-PST
Date: Wed 19 Mar 86 03:46:26-EST
From: Ken Rossman <[email protected]>
Subject: Re: DEC20<->VAX DECnet: HELP!!!
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

Many thanks to those who contributed suggestions on the VAX <-> 20 DECnet
connection problem we've been having here over the past couple of months.
Unfortunately, none of the suggestions worked.

We tried changing the verification password parameters around in various
ways, but to no avail, and there is no SET CIRCUIT DMC-0 ROUTING TYPE III
command anymore on the VAX (if there ever was one).

I have decoded packets a bit further, and I find that we are not even
getting to the router verification packet point in the protocol (which
pretty well eliminates the theory of III/IV router verification passwords
anyway). There are only two data packets thrown out (one from each
system), then about 10 seconds of silence, followed by DDCMP resynch coming
from the VAX (never from the DN20). Neither data packet got ACKed, as far
as I can see from the first sample.

The data packets are router layer init packets. The data scope sample I
have in front of me shows a 10 byte router init packet coming from the
DN20, only some of which I can decode (I don't have proper documentation),
and a 12 byte router init packet coming from the VAX. The VAX packet I
have decoded, and I know it to be a Phase IV format packet (which the DN20
should ignore, since it will see a node number that is far too large, given
that the area field contains a 1). Why the VAX does not read the III
router init from the DN20 and downshift into III emulation I don't know.
Both sides seem to just time out and restart (though why it's only about 10
seconds I don't know -- I don't see any timer values set to 10 secs).

I have compared all of the packets I can from this link to a DN20-VAX link
that is working properly, and except for node numbers, they are pretty much
identical. That is, packets up to the router init are identical.

The working link sequence seems to be:

DN20 VAX
-------------
START ; DN20 throws out a START
START ; VAX throws out a START
STACK ; DN20 sends START ACK
ACK ; VAX sends STACK ACK
DATA ; DN20 sends Phase III router init
ACK ; VAX ACKs router init packet
DATA ; VAX sends Phase III router init
; (VAX now in Phase III mode)
ACK ; Again VAX ACKs 20 router init (???)
ACK ; DN20 ACKs VAX router init
DATA ; DN20 sends router verification, complete
; with "DECNET20" password.
ACK ; VAX ACKs router verification packet
DATA ; VAX sends HELLO/TEST packet
: ; (127 byte test packet, all 252(8) bytes)
:

From here on in, we get into normal traffic patterns, and the nodes have
signed on to each other. A few more HELLO/TEST packets are sent from the
VAX, and ACKed by the DN20.

The bad link looks like this:

DN20 VAX
-------------
START ; DN20 throws out a START
START ; VAX throws out a START
STACK ; DN20 sends START ACK
ACK ; VAX sends STACK ACK
DATA ; DN20 sends Phase III router init
DATA ; VAX sends Phase IV router init (!!!),
; though this could just have been timing.

The VAX sometimes ACKs the DN20's III router init, sometimes it doesn't.
But it then gets quiet here for 10 seconds or so, and DDCMP starts over
with the START, START, STACK, ACK sequence again. The VAX is always the
one to throw off the first START msg after the 10 second dead time, and
this sometimes after it has ACKed the DN20 router init packet, but has NOT
sent its own router init packet.

Incidentally, we swapped the circuit on the VAX so that we were using a
DMF32 for part of the time, and the results were pretty much the same,
except that I NEVER see a VAX router init packet thrown out when we used
the DMF. The VAX does ACK the DN20's III router init packet when it sees
it, but is then silent for awhile, and throws out the START message again.

The only other thing I'd like to know more about at this point is the exact
meaning of the two flag bits in some of these packets (the SELECT flag, and
the QSYNCH flag). Sometimes these flags are set, other times they are not.
Might this have anything to do with the current situation?

Again, any information concerning possible problems would be very much
appreciated! I've run out of things to try. /Ken
-------
19-Mar-86 04:29:48-PST,2878;000000000000
Return-Path: <[email protected]>
Received: from bbnccs.arpa by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 04:29:24-PST
Date: Wed, 19 Mar 86 6:50:40 EST
From: Andrew Malis <[email protected]>
Subject: Re: major change to 1822 (IMP) software
In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST
To: Mark Crispin <MRC%[email protected]>
Cc: [email protected], [email protected], [email protected]

Mark,

Boy, I wrote the thing, and I didn't even receive the
distribution notice! I wonder how many others I've missed ...

I initially (some time ago) resisted some of terminology changes
that you mentioned, but was overruled by many others that prefer
the new terminology (including DCA, by the way). Some of these
changes go back several years now in BBN and DCA literature, but
are just making their way out to the rest of the world. By the
way, the software that runs on the PSN is referred to as PSN
Release x, with the End-to-End being one module of the PSN.
Other modules include, for example, Store-and-Forward, Routing,
and X.25 L3.

VDHs, as you mention, are mostly extinct animals these days.

The story on uncontrolled messages is a bit more complicated. Up
to now, the EE's flow control has been (in the absence of subnet
congestion control) the only governor of the amount of traffic a
host can submit to the network. When you take that away by using
uncontrolled messages, you are really introducing the possibility
of debilitating congestion on the network.

As a result, the use of uncontrolled messages has been, shall we
say, controlled (administratively). There are, I believe, no
hosts on the MILNET that have permission to send them, and only a
small number on the ARPANET (mostly associated with packet
speech). I know of no TOPS-20s that are currently allowed to
submit uncontrolled messages. As an example, neither of the
hosts at SUMEX are enabled, and at the ISI complex, the only
enabled host is ISI-SPEECH11 (I just checked these).

After we decided to upgrade the uncontrolled messages into the
new datagram service, we also found that because of scheduling
constraints, we wouldn't be able to include it in PSN 7.0 (the
first new EE release). Even if we had, its use would (due to the
absence of congestion control) have to be limited to the same
small set of hosts.

The good news is that subnet congestion control is actively under
development, and both it and datagrams are scheduled for PSN
Release 8.0. At that time, we can experiment (on the ARPANET
first, of course) with always using datagrams for TCP/IP traffic.
That was one of the reasons why we decided to upgrade to the new
datagrams - the old uncontrolled messages just weren't useful
enough to support this.

By the way - the datagrams, when included, will be accessed by
good old subtype 3.

Regards,
Andy
19-Mar-86 04:45:29-PST,1181;000000000000
Return-Path: <[email protected]>
Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 04:45:21-PST
Date: 19 Mar 1986 04:28-PST
Sender: [email protected]
Subject: Re: major change to 1822 (IMP) software
From: [email protected]
To: MRC%[email protected]
Cc: [email protected], [email protected]
Message-ID: <[USC-ISI.ARPA]19-Mar-86 04:28:08.CERF>
In-Reply-To: <12191827659.11.MRC@PANDA>

Mark,

I would be very hesitant to put a lot of traffic on "uncontrolled" datagrams.
The term "uncontrolled" meant just that. No flow/congestion control; except
to discard a type 3 datagram if you had nothing else to do with it. When we
ran packetized voice tests on the ARPANET using the current type 3
datagrams, we interfered pretty severely with network performance.

I don't know how far the new end/end would go towards making this any better.
Andy Malis at BBN would be a good person to ask. My assumption for the moment
is that they have reduced the need for RFNM-like behavior (not to zero,
you still need acks on an end/end basis, but not one per packet) but this does
not put control onto the type 3 packets, as far as I know.

Vint
19-Mar-86 17:53:17-PST,3307;000000000000
Return-Path: <[email protected]>
Received: from bbnccs.arpa by SU-SCORE.ARPA with TCP; Wed 19 Mar 86 17:52:34-PST
Date: Wed, 19 Mar 86 20:51:37 EST
From: Andrew Malis <[email protected]>
Subject: Re: major change to 1822 (IMP) software
In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST
To: Mark Crispin <MRC%[email protected]>
Cc: [email protected], [email protected], [email protected]

My apologies if any of you receive this twice - as far as I can
tell, my original message went into a black hole.

Andy
-------
Date: Wed, 19 Mar 86 6:50:40 EST
From: Andrew Malis <[email protected]>
Subject: Re: major change to 1822 (IMP) software
In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST
To: Mark Crispin <MRC%[email protected]>
Cc: [email protected], [email protected], [email protected]

Mark,

Boy, I wrote the thing, and I didn't even receive the
distribution notice! I wonder how many others I've missed ...

I initially (some time ago) resisted some of terminology changes
that you mentioned, but was overruled by many others that prefer
the new terminology (including DCA, by the way). Some of these
changes go back several years now in BBN and DCA literature, but
are just making their way out to the rest of the world. By the
way, the software that runs on the PSN is referred to as PSN
Release x, with the End-to-End being one module of the PSN.
Other modules include, for example, Store-and-Forward, Routing,
and X.25 L3.

VDHs, as you mention, are mostly extinct animals these days.

The story on uncontrolled messages is a bit more complicated. Up
to now, the EE's flow control has been (in the absence of subnet
congestion control) the only governor of the amount of traffic a
host can submit to the network. When you take that away by using
uncontrolled messages, you are really introducing the possibility
of debilitating congestion on the network.

As a result, the use of uncontrolled messages has been, shall we
say, controlled (administratively). There are, I believe, no
hosts on the MILNET that have permission to send them, and only a
small number on the ARPANET (mostly associated with packet
speech). I know of no TOPS-20s that are currently allowed to
submit uncontrolled messages. As an example, neither of the
hosts at SUMEX are enabled, and at the ISI complex, the only
enabled host is ISI-SPEECH11 (I just checked these).

After we decided to upgrade the uncontrolled messages into the
new datagram service, we also found that because of scheduling
constraints, we wouldn't be able to include it in PSN 7.0 (the
first new EE release). Even if we had, its use would (due to the
absence of congestion control) have to be limited to the same
small set of hosts.

The good news is that subnet congestion control is actively under
development, and both it and datagrams are scheduled for PSN
Release 8.0. At that time, we can experiment (on the ARPANET
first, of course) with always using datagrams for TCP/IP traffic.
That was one of the reasons why we decided to upgrade to the new
datagrams - the old uncontrolled messages just weren't useful
enough to support this.

By the way - the datagrams, when included, will be accessed by
good old subtype 3.

Regards,
Andy
20-Mar-86 15:26:03-PST,7571;000000000000
Return-Path: <Alan%DUNDEE-TECH.AC.UK%[email protected]>
Received: from Cs (CS.UCL.AC.UK.#Internet) by SU-SCORE.ARPA with TCP; Thu 20 Mar 86 15:24:26-PST
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a004147; 20 Mar 86 20:23 GMT
Via: DCT; by DUNDEE on Thursday, 20-Mar-86 20:24:23-GMT
Date: Thu 20 Mar 86 20:22:38-GMT
From: Alan Greig <CCD-ARG%[email protected]>
Subject: [Alan Greig <CCD-ARG@DCT>: KA10's never die....]
To: [email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%[email protected]

Never seemed to arrive before so here goes again.

---------------

Mail-From: CCD-ARG created at 28-Feb-86 19:15:15
Date: Fri 28 Feb 86 19:15:15-GMT
From: Alan Greig <CCD-ARG@DCT>
Subject: KA10's never die....
To: [email protected]
cc: alan@DCT
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan@DCT

I found the following message in the Speakers Corner conference at York
University in England. It originated in the Swedish COM system and
found it's way over Janet into York COM (For those who don't know,
COM is the Electronic conferencing system thats an optional part
of the Simula system).

I'm sure some others on the tops20 group might find it interesting.

(Text 16633) 86-02-23 01.54 Per Lindberg QZ @ QZCOM (Per Lindberg QZ) (severa
l receivers)
Subject: Subject: The saga of KATIA
------------------------------------------------------------
%Original date: 21 Feb 86 23:46 +0100. TF: PST010.COM[3,5]
%FROM: Per_Lindberg_QZ@ODEN

Have I told you about the large computer now installed and running at
Stacken, the computer club at the KTH (the Royal Institute of
Technology) in Stockholm? No? Well, then...

A few years ago, DEC (Digital Equipment Corp) in Sweden had a sort of
"white elephant" on their hands, a DECsystem-10 (the same type you are
running COM on), but a very old model with a KA10 CPU, single
transistor logic boards and good old core memory. Big as hell, lots of
blinkenlights, and with an appetite for kiloAmpere that would ruin any
computer hobbyist. The customer that had leased the thing did not want
it any more, and DEC did not even try to find another. But instead of
scrapping it, they gave it to us in Stacken. Sure, we could take care
of it, and even payed the transport (about 3000 SEK). But where would
we house such a beast? Fortunately, KTH promised us a place to run it.
For two years it was kept in a garage at KTH while we lobbyed the KTH
administration to give us that place. (There is a constant shortage of
space at KTH, alas). It was not after a new guy in Stacken, Peter
Lothberg, had renewed the efforts by pestering the Principal himself
for a while that we finally got the promised room to install it in.

Then around last spring (1985) the work started. During the summer of
1985 the place was refitted with a real raised computer room floor,
electrical power, terminal lines, a cooling machine with outdoor
condensors, and everything else needed to make the place a
full-fledged computer center.

Meanwhile, our DEC-10, now named "KATIA" (a pun on "Nadja" which is
the DEC-2020 at KTH and "KA-TIA", where "tia" is 10:er in swedish),
was temporary installed and tested at CCCC (Colossal Cave Computer
Center), Peter:s playroom where he already has a DECsystem-10 going.
That DEC-10, (named KICKI) was used for testing and debuggning Katia.
Without it, it might still be nonfunctional.

When the room was finished, Katia was moved in and re-debugged. (You
don't move such a beast without dislocating at least a few wires). And
then, one night last autumn, the champagne bottle, which had been
bought for just this reason, was opened. Katia was installed, and up
and running! According to the tradition, which begun with the
installing of Kicki a year eariler, the bottle is uncorked when you
can give the command MAKE LOVE on the console, which makes a file
named "LOVE" with the venerable TECO editor, and get the resonse "NOT
WAR?" on the console. (This is a "hack" in TECO, installed for obvious
reasons long ago, probably way back in the sixties).

Then on the 23rd of October 1985 Katia was officially inaugurated as
Stacken was throwing its first Big Party in its 7-year history, where
participants could awe at the extremely rare sight of over 100
computer hobbyists, nerds and hackers in (get this!) ties and jackets
(some of them even pinstriped!) The members and a large number of
specially invited dignitaries met at a splendid Dinner With Everything
at the KTH student corps house. Speeches were held, glasses were
raised, jokes were cracked and the atmosphere was high. After the
coffee everyone walked over to the room where Katia stood happily
humming since a few days, where the Principal inaugurated Katia by
cutting a punched tape spanned across the door.

Such a project can't be done without two things: many highly skilled
enthusiasts and a lot of money. Fortunately, Stacken had both. The
latter came from selling copies of our EMACS workalike editor "AMIS"
for about 500 USD a copy to other installations of DEC-10s, VAXen,
PR1MEs and Norsk Data. AMIS was our first success back in 1980, when
me and six others got fed up with not having a really good editor.
(I'm using it right now for writing this text). So AMIS, aside from
preventing us from going berserk, gave us the means to install Katia.

By the way, we can use more hardware. All sorts of donations are
appreciated. Especially disks, but we'll take anything that could
possibly be connected to a DECsystem-10. Also terminals, cooling
machines... anything. Send inquiries to me, or better still, to:
Datorforeningen Stacken, c/o NADA, KTH, S-10044 Stockholm, SWEDEN.

Katia is a neat hobby computer. Those kids and their daddys with
CBM-64:s can go suck on a BASIC manual. The DEC-10 is a REAL COMPUTER,
36 bit words, real tape, disks, DECtapes and a glorious collection of
blinking lights. It runs the TOPS-10 timesharing operating system, one
of the finest and most user-friendly OS ever made (it beats both VMS
and UNIX singlehandedly), rivalled only by TOPS-20. And the awesome
sight of Katia:s 12 large blue cabinets with the blinking lights, its
designed front panel and the rest of the hardware filling the room
stirs the heart. Katia looks like a computer should! This machine and
its worshippers are not unlike the phenomenon of people lovingly
restoring old steam engines and cars. But while Katia definitely is a
veteran computer, it's still modern. It outperforms a medium-sized VAX
and has a much neater instruction set. (Long live the DECsystem-10
designers!) And there are gigabytes upon gigabytes with highly
sophisticated software which we can run on it. Our only problem so far
is what to do with all those unused CPU cycles.

Anyone wants a million prime numbers?

(Text 16633)------------------------------

[Actually the MAKE LOVE trap is in COMPIL and in the old days when tops20
exec still had the compil interface in it, you could get the not war
response on tops20 as well. Although this code has been conditionalled out
for some time it was only with tops20 version 5 that it went alltogether.
A sad day !! To the maintainers of PCL : If goto hell on the dec10 responds
with get stuffed can't we have something like that or better under tops20 ?
---Alan]
-------
-------

20-Mar-86 16:19:36-PST,376;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Mar 86 16:19:30-PST
Date: Thu 20 Mar 86 16:21:43-PST
From: Frank M. Fujimoto <[email protected]>
Subject: TTYINI
To: [email protected]

I've fixed up TTYINI to know about TCP Tips. Sources are
on Sierra in PS:<FINGER.SOURCES>TTYINI.MAC

-frank
-------
22-Mar-86 00:50:05-PST,2162;000000000001
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SU-SCORE.ARPA with TCP; Sat 22 Mar 86 00:49:54-PST
Date: Sat, 22 Mar 1986 22:21 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Domain service query
In-reply-to: Msg of 17 Mar 1986 19:01-EST from [email protected]

Vince,

I don't know of any reason why DSV should suddenly stop believing in
*.SEI.CMU.EDU. You might check to see if you did something that
caused it to use some previously untested piece of code (like adding
enough RRs that your database is now using both sections of the
database rather than just the low section).

You might want to try copying the V5 stuff from XX and seeing if it
works any better (XX:<DOMAIN.5A>*.*). In the version 5 code DSV comes
in two flavors, NUFORK and NUMAIN, depending on whether or not you are
running it under a JEEVES. NUMAIN is the one you probably want, I'm
not certain it has ever been tested. I know NUFORK works (with a two
section database) because XX is one of the nameservers for
LCS.MIT.EDU.

Paul Mockapetris claims to have a new and wonderful version of the
nameserver with large numbers of bugs fixed (I believe him, but it has
been long enough since I talked to him about it that I no longer
remember what the bugs were). Unfortunately, he has the sources
protected against anybody reading them (his way of enforcing a write
lock), so this doesn't do you any immediate good. The version I have
on XX is from around the end of January, just before Paul started the
massive rewrite.

If you do copy the sources from XX, be warned that the MIT version and
the ISI version have diverged slightly (ISI has the new nameserver
code, MIT has an improved version of GTDOM%). Eventually either Paul
or I will do a merge (and merge in the changes certain brave souls are
making to get the monitor code to run under 6.1), but for now I would
not advise putting any more work into this stuff than you absolutely
have to in order to survive.

--Rob
24-Mar-86 07:12:59-PST,938;000000000000
Return-Path: <MHICKEY%[email protected]>
Received: from WISCVM.WISC.EDU by SU-SCORE.ARPA with TCP; Mon 24 Mar 86 07:12:49-PST
Received: from (MAILER)UDCVM.BITNET by WISCVM.WISC.EDU on 03/24/86 at
09:10:29 CST
Return-path: [email protected]
Received: by UDCVM (Mailer X1.23) id 1540; Mon, 24 Mar 86 10:11:39 EST
Date: Mon, 24 Mar 1986 10:01 EST
From: Mike Hickey <MHICKEY%[email protected]>
Subject: Gosling Emacs info
To: <[email protected]> ,
<[email protected]> ,
<[email protected]>

Greetings!
I've recently unearthed sources for Gosling Emacs and am frantically
searching for the documentation and associated MLISP files. Any help
would be greatly appreciated as I have three ports to do: DEC-2065/TOPS,
VAX 8600/VMS, and IBM-PC/MS-DOS. For those who are interested I will
summarize to the appopriate nets.

Thanks in advance,
/Mike
24-Mar-86 15:04:58-PST,1127;000000000000
Return-Path: <[email protected]>
Received: from hydra.ARPA (RIACS-HYDRA.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Mon 24 Mar 86 15:04:41-PST
From: Barry Leiner <[email protected]>
Message-Id: <[email protected]>
Received: by hydra.ARPA (4.12/4.01)
Mon, 24 Mar 86 15:02:12 pst
Date: 24 Mar 1986 1502-PST (Monday)
To: Mark Crispin <MRC%[email protected]>
Cc: [email protected], [email protected]
Subject: Re: major change to 1822 (IMP) software
In-Reply-To: Your message of Tue 18 Mar 86 19:09:33-PST.
<12191827659.11.MRC@PANDA>

Mark,

You might be interested to know that I have been lobbying with the DDN
and BBN for several years now to run an experiment using IP over
ARpanet uncontrolled packets (subtype 3). My reasoning was that, since
some statistics I saw showed that something like half the packets were
arpanet acknowledgments (RFNMs), it would seem that a significant
amount of traffic loading on the net might be eliminated and we might
actually get better performance. However, thus far that experiment has
not been performed.

Barry

----------
24-Mar-86 22:12:47-PST,1280;000000000000
Return-Path: <[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Mon 24 Mar 86 22:12:35-PST
Date: 20 Mar 86 04:29:46 EST
From: Charles Hedrick <[email protected]>
Subject: more TCP oddities
To: [email protected]
Message-ID: <[email protected]>

It is interesting to see the problems people are having writing
Unix-compatible servers. I just tried to write a user process
that would talk to rexecd on a Unix machine, and had an even
worse problem. I want to ship off
- user information
- a command to execute
- a bunch of text which will be primary input
and then get back a bunch of stuff which will be primary output. If
I am reading the spec correctly, Unix expects to see an end of file
at the end of the primary input. If I am reading the monitor
code correctly, there is no way to generate an end of file on output
without closing the connection entirely. There is a TCOPR call
that says "send a FIN". It turns out to do a close. I looked at
the code in TCPTCP, and it looks to me like the only way of telling
TCPTCP to send a FIN is to clear the bit saying that the connection
is open. If I understand what is going on, this seems to be a
fairly major omission.
-------
25-Mar-86 15:09:36-PST,779;000000000000
Return-Path: <[email protected]>
Received: from A.BBN.COM by SU-SCORE.ARPA with TCP; Tue 25 Mar 86 15:08:36-PST
Date: 25 Mar 1986 10:04-EST
Sender: [email protected]
Subject: Re: more TCP oddities
From: [email protected]
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Message-ID: <[A.BBN.COM]25-Mar-86 10:04:33.CLYNN>
In-Reply-To: <[email protected]>

Have you tried it? The code in TCPJFN does indeed do a "CLOSE%" (without
setting the TCP%WT bit); CLOSE% (in TCPBBN) sends a FIN (as soon as flow
control permits), returning without waiting for the remote end to send its
FIN (since the TCP%WT bit was not set). You should then be able to read
from the JFN until the remote end sends its FIN (causing an EOF error).
26-Mar-86 04:53:59-PST,995;000000000000
Mail-From: BILLW created at 26-Mar-86 04:53:54
Date: Wed 26 Mar 86 04:53:54-PST
From: William "Chops" Westfield <[email protected]>
Subject: Score is running a domain resolver...
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>

(assuming it hasn't crashed since I sent this message) You can play
with the tops20 resolver and stuff using DOMAIN:DQUERY for general
querys, or DOMAIN:DADDR to just look up host addresses using the
domain code instead of the host table code.

Apparently, you can't test it on the stanford domain because that
isn't officially allocated, or some such. Ill try to look into
this to see if the initial database can be tweaked to think that
stanford.edu does exist after all...

Gee, Im sure glad we have domains - we can get rid of that big,
116 page host table and replace it with a domain database that's
only 1024 pages long... (sigh, :-( ? :-)

BillW
-------
26-Mar-86 10:50:13-PST,697;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 26 Mar 86 10:49:36-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Wed 26 Mar 86 10:46:50-PST
Date: Wed 26 Mar 86 10:33:33-PST
From: Mark Crispin <MRC%[email protected]>
Subject: LN03's
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12193830877.7.MRC@PANDA>

I'd like to know what people think about DEC LN03 laser printers. At $3500
with a possible 12% discount that seems like a very attractive price. The
question is, are they merely "inexpensive" or are they also "cheap"?
-------
27-Mar-86 11:28:12-PST,379;000000000000
Return-Path: <[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 27 Mar 86 11:27:54-PST
Date: Thu 27 Mar 86 13:26:15-CST
From: [email protected]
Subject: Eliza
To: [email protected]
cc: [email protected]

Where could I run Eliza (Weizenbaum's program) or get a copy of the
source code? Send reply to [email protected].
H.
-------
27-Mar-86 15:56:09-PST,734;000000000000
Return-Path: <[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Thu 27 Mar 86 15:55:49-PST
Date: 25 Mar 86 11:28:30 EST
From: Charles Hedrick <[email protected]>
Subject: Re: more TCP oddities
To: [email protected]
cc: [email protected]
In-Reply-To: <[A.BBN.COM]25-Mar-86 10:04:33.CLYNN>
Message-ID: <[email protected]>

Yes, I tried it. I got an immediate end of fine on input. I looked
throught the code in the monitor, and more or less convinced myself
that that form of CLOSE clears the UOP bit, thus making it impossible
to read from the channel. Since both you and BillW report being able
to read after doing the TCOPR, I will look again.
-------
27-Mar-86 23:54:11-PST,1850;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 27 Mar 86 23:53:59-PST
Date: Fri 28 Mar 86 02:53:08-EST
From: Ken Rossman <[email protected]>
Subject: Firing up DECnet on an NI
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

We are experiencing problems getting DECnet service to work on a newly
installed NI20. Previously, this DEC-20 talked to the rest of the network
via a CI20. Once the NI was installed, however, I can only get an
"Operation Failure" error message when I attempt to "NCP>SET CIRCUIT NI-0-0
STATE ON".

I believe I am able to verify that the actual NI hardware is working
because we also run TCP/IP service on this machine, and using IPHOST I can
turn off TCP/IP service over the CI, and can still connect to hosts on the
local Ethernet.

I don't have much else to go on. I have a couple of entries from SPEAR
that claim the "component is in the wrong state", though I don't understand
how this could be. SHOW CIRCUIT NI-0-0 STATUS gives me some info about
something called a designated router. The problem system lists itself in
this field, while other systems which have NI's list other machines as
designated routers.

One other point: There is one other machine which serves as a CI/NI
gateway, and has been serving in this capacity for awhile now. Could this
machine somehow be interfering in the NI startup on this new addition to
the NI/CI network? This new machine will be the second machine to have
both a CI and an NI with DECnet service enabled on both circuits. Do I
have to include special NCP commands to limit one of the two machines as a
gateway or something? Any other ideas? /Ken
-------
28-Mar-86 01:07:10-PST,826;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 01:06:57-PST
Date: Fri 28 Mar 86 04:05:58-EST
From: Ken Rossman <[email protected]>
Subject: 8 bit VMS to TOPS-20 file transfers
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

I think this must have been batted around a few times in the past, but
since I don't remember what the answer was, I'll ask again:

Is there any way to do a bare 8-bit file transfer between VMS 4.x and
TOPS-20 V6.1? TOPS-20 NFT has no such option that I can find, and VMS COPY
bombs out with some obscure RMS error message (but then, all VMS RMS error
messages are obscure to me). /Ken
-------
28-Mar-86 07:07:25-PST,1494;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 07:07:16-PST
Date: 28 Mar 1986 1003-EST
From: Tom Blinn <[email protected]>
To: Mark Crispin <MRC%[email protected]>
cc: tops-20@su-score
Subject: Re: LN03's
Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12194316952.14.275.7772 at MARLBORO.DEC.COM>
References: Message from Mark Crispin <MRC%[email protected]>
of 26-Mar-86 1420-EST
In-reply-to: <12193830877.7.MRC@PANDA>

I'm probably somewhat biased, so I'll be interested to see what other
feedback you get.

My impression of the LN03 is that, while it is inexpensive, it is not
a "cheap" printer. It has a number of good features when compared to
other printers in its price class. Some of these are in areas such as
the size of the paper trays (less "out of paper" service), and the way
the paper gets stacked in the output hopper (proper collating sequence).
I'm told that a number of the other printers in its class lack some of
these features; I can't say from personal knowledge, as we (naturally)
don't buy the others.

The LN03 also has very good print quality, and while there isn't much
software on the -10s and -20s to support it (although you CAN hang it
off a regular terminal port), it is quite well supported on the VAX by
VMS. (You can even hang it off a DECserver-100 terminal port and share
it from several VAXes in a cluster.)

Regards,

Tom
--------
28-Mar-86 07:10:26-PST,859;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 07:10:16-PST
Date: 28 Mar 1986 1006-EST
From: Tom Blinn <[email protected]>
To: Ken Rossman <[email protected]>
cc: tops-20@su-score
Subject: Re: Firing up DECnet on an NI
Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12194317493.14.275.10543 at MARLBORO.DEC.COM>
References: Message from Ken Rossman <[email protected]>
of 28-Mar-86 0300-EST
In-reply-to: <[email protected]>

You don't have your machine (the problem child) defined as an end node, do
you? If it is a non-routing end node, you can only have one active circuit
to the outside world.

I realize you probably already realize this, but I figured that it never
hurts to double-check the obvious.

Tom
--------
28-Mar-86 07:25:47-PST,2289;000000000000
Return-Path: <[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 28 Mar 86 07:25:37-PST
Date: 28 Mar 1986 1022-EST
From: Tom Blinn <[email protected]>
To: Ken Rossman <[email protected]>
cc: tops-20@su-score
Subject: Re: 8 bit VMS to TOPS-20 file transfers
Message-ID: <"MS11(5146)+GLXLIB0(4)-4" 12194320296.14.275.20054 at MARLBORO.DEC.COM>
References: Message from Ken Rossman <[email protected]>
of 28-Mar-86 0412-EST
In-reply-to: <[email protected]>

You have two choices:

1) Use the DAP protocol yourself to talk to FAL on the VAX; NFT uses DAP,
but NFT imposes a conversion from the 8-bit bytes that the VAX (and
the TOPS-20 system) exchange over the DECnet link to 7-bit bytes on
the TOPS-20 disk. (The default exchange mode is /ASCII. You could
try using /IMAGE on the destination file, but I'm not sure you'd get
anything useful.)

2) You could write your own software, using the routines in DIL to set
up the link and pass the messages back and forth across the net (or
you can roll your own in MACRO).

The "Network File Transfer Guide" states that "Binary files cannot be copied
from a VAX/VMS or RSX system to a TOPS-20 system;" and then goes on to talk
about using the /MACY11 switch to move MACY11 format object files to VMS or
RSX. This guide also documents the /FIXED and /VARIABLE switch on the NFT
copy commands.

There are certain styles of VMS files that you can't readily copy from the
VAX system to TOPS-20, because the file attributes on VMS are not compatible
with the way TOPS-20 wants to receive the file (which is, by default, as
variable-length ASCII text). If the file is really text (e.g., RUNOFF or
DSR output), you can use TECO to convert the file to a format that can be
"pushed" from the VAX to TOPS-20; just read the file in via EDIT/TECO, then
at the "*" prompt type "EX" and two escapes. There's also a way to change
the file attributes with CONVERT/FDL, but it's more trouble, and TECO is
faster.

If the file is not text, DIL may be your best bet. DIU is supposed to be
on its way, but I don't know for sure when it will be shipping.

Hope this helps!

Tom
--------
29-Mar-86 22:30:08-PST,801;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sat 29 Mar 86 22:30:06-PST
Date: Sat 29 Mar 86 22:30:34-PST
From: Mark Crispin <[email protected]>
Subject: ENVIRONMENT program
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

I got a new version of the ENVIRONMENT program from DEC. The new
version is on SYS: at Score and Epic, <CRISPIN.TOOLS> at SUMEX, and
<M.MRC> at LOTS.

It comprehends 2065's, works on 2020's, and even gives a halfway
reasonable output on an SC-30M (although it doesn't find any memory;
the old one did but the information was wrong).

I'll try to get a copy of the source.
-------
30-Mar-86 01:32:33-PST,735;000000000000
Mail-From: BILLW created at 30-Mar-86 01:32:26
Date: Sun 30 Mar 86 01:32:25-PST
From: William "Chops" Westfield <[email protected]>
Subject: Score now running new mail software.
To: [email protected], [email protected], [email protected]
Message-ID: <[email protected]>

Score is currently running a new version of the mail software
that fully supports domains. The only change that should be
visible to uses is that they should be able to reply to
messages from obscure places (eg vangogh.Berkeley.EDU) that
used to cause an error. Report any strange mailer behavior
to me (If mail REALLY isn't working, drop by MJH030 in
person - the phone isn't working either!)

BillW
-------
30-Mar-86 16:32:08-PST,637;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Mar 86 16:31:54-PST
Date: Sun 30 Mar 86 16:31:28-PST
From: Stu Grossman <[email protected]>
Subject: Re: Firing up DECnet on an NI
To: [email protected]
cc: [email protected]
In-Reply-To: Message from "Ken Rossman <[email protected]>" of Fri 28 Mar 86 08:38:46-PST

Your NI probably has the wrong Ethernet address for use with DECnet. To
fix that, put the line "ETHERNET 0 DECNET" into your 6-1-CONFIG.CMD
file. This line must come after the NODE command in the same file.

Stu
-------
30-Mar-86 16:35:24-PST,617;000000000000
Return-Path: <[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Mar 86 16:35:11-PST
Date: Sun 30 Mar 86 16:34:46-PST
From: Stu Grossman <[email protected]>
Subject: Re: Firing up DECnet on an NI
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: Message from "Tom Blinn <[email protected]>" of Fri 28 Mar 86 07:06:00-PST

His problem is has nothing to do with end node service. 6.1 only supports
end node service on the NI, so therefore it wasn't an end node while it
was talking DECnet through the CI.
-------
30-Mar-86 19:58:25-PST,2524;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 30 Mar 86 19:58:14-PST
Received: from PANDA by SUMEX-AIM.ARPA with Cafard; Sun 30 Mar 86 19:57:55-PST
Date: Sun 30 Mar 86 19:49:38-PST
From: Mark Crispin <MRC%[email protected]>
Subject: GNU Emacs for TOPS-20
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12194980684.8.MRC@PANDA>

I've had some preliminary discussion with Richard Stallman (the
principal developer of TOPS-20 EMACS) about the possibility of porting
his "GNU Emacs" to TOPS-20. For those of you who haven't been following
these things, Stallman is working on a public-domain Unix clone called
GNU, the intent being to have a free version of the Unix environment
available. He already has a version of Emacs written in C that runs
under Unix called GNU Emacs.

Stallman feels that the project of porting GNU Emacs to TOPS-20 is
feasible albeit unexciting; he cautions that the result will probably be
larger and slower than the extant TOPS-20 EMACS. On the other hand, the
prospect of having a common Emacs editor on both TOPS-20 and Unix excites
me, and even more so the prospect of having an Emacs that runs in extended
addressing! I for one am sick and tired of running out of space for new
buffers/files in TOPS-20 EMACS on a daily basis...

I also brought up the issue of the need for a reasonable means to use
Emacs when XON/XOFF flow control cannot be avoided.

Stallman appears willing to take on this project provided there is a
sufficient infusion of funds to his GNU development group (I think it's
called the Free Software Foundation). I may be willing to put in some of
my own money for this project, although if it's only going to run in
extended addressing it won't be of much use to me on my 2020. But you
winners with KL's may benefit by this, and especially by having a common
editor.

In any case, no commitments have been made by anyone in this. I
would like to hear if there is any interest in helping to fund this worthy
project. I don't know what kind of funding level Stallman is thinking of,
but it can't be that much, especially when spread over a community of TOPS-20
sites. Apparently some amount of work would have to be done to get it
running on a PDP-10 since like many C programs it assumes that pointers,
addresses, and integers can be mixed freely.
-------
31-Mar-86 15:32:31-PST,587;000000000000
Return-Path: <[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 31 Mar 86 15:31:45-PST
Date: Mon 31 Mar 86 15:30:21-PST
From: [email protected]
Subject: tcp bug fix
To: [email protected]

Is anyone (other than the NIC) running the bug fix from Charlie Lynn
that Ken Harrenstien described in his message of August 7, 1985 ? The
problem was duplicate data being received on a TCP connection, and had
been blamed on 4.2BSD. Will this (or equivalent) be in DEC's version?
(It would be nice to have it installed and tested.)

Alan
-------
3-Apr-86 11:28:29-PST,588;000000000000
Return-Path: <[email protected]>
Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Thu 3 Apr 86 11:28:16-PST
Date: Thu 3 Apr 86 10:34:59-CST
From: Donald Blais <[email protected]>
Subject: ftp loops for bad host in command line
To: [email protected]
Message-ID: <[email protected]>

@ftp other
?No such host - No string for that Host number - "other"
?H^\^A^Cm
?H^\^A^Cm
?H^\^A^Cm