2-Jan-85 10:52:45-PST,2077;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 2 Jan 85 10:52:26-PST
Date: 2 Jan 1985 1347-EST
From: Reed B. Powell <POWELL at DEC-MARLBORO>
To: KNUT_SMAALAND_UIO%QZCOM at MIT-MULTICS
cc: TOPS-20 at SU-SCORE
Large-Systems-Marketing: LCG Product Line
Location: "231-4261 MRO2-2/3C (Pole 4A)"
REPLY: "MARKET:: or MRVAX::"
Subject: QUESTIONS ABOUT V6.0 uCODE, DEVICE NUMBERS, etc.
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12076392966.27.146.80099 at DEC-MARLBORO>
Here is the information on Microcode requirements for 2060/2065
under V6.0, and on changing RA81 drive numbers.......
-reed
q1 -- the microcode (400) will work on both 2060 and 2065.
q2 -- according to the "RA81 Disk Drive User Guide" (EK-ORA81-UG-001)
2.3.3 Programming the Drive Unit Address Plug
The READY cover on the operator control panel is also the
drive unit address plug. The drive unit numbers between 0 and 251
must be programmed in this plug. The plug comes as "Unit 0". To
set up a drive unit number other than zero, remove the READY switch
from the control panel and cut off the tabs that add up to the
required number.
The picture shown shows 4 slotted tabs along one long edge
and 4 non-sloted tabs along the other long edge.
With the sloted tabs on top, they correspond (left to right)
to the values
1 2 4 8
the non sloted tabs correspond (left to right with plug
in same position to:
16 32 64 128
The text continues:
For example, if unit number 7 is required for a specific drive, tabs 1
1,2 and 4 would have to be cut off the switch cap (plug). If unit
number 113 is required, tabs 64, 32, 16, and 1 must be removed.
Leave all tabs on if unit number 0 is required.
After the drive unit number has been selected, place the gummed
label with the corresponding number in the recessed area on the
front of the switch cover. Repleace the switch cover on the operator
control panel.
.enough ?
--------
--------
3-Jan-85 06:31:46-PST,2558;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 3 Jan 85 06:31:29-PST
Date: Thu 3 Jan 85 09:31:35-EST
From: Kevin Paetzold <
[email protected]>
Subject: DSK*
To:
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
Here is a fix for the DSK* problems that many of you are having. THis
should fix all problems encountered when PS: is not named PS: and has more
than 4 characters in its name.
File 1) DSK:GTJFN.MAC[4,242] created: 1136 02-Jan-85
File 2) AM51:GTJFN.MAC[4,132] created: 1300 26-Oct-84
1)1 ;Fix DSK*.
1) ;Edit 3175 to GTJFN.MAC by LOMARTIRE on Fri 26-Oct-84, for SPR #20339
****
2)1 ;Edit 3175 to GTJFN.MAC by LOMARTIRE on Fri 26-Oct-84, for SPR #20339
**************
1)16 MOVEM T1,ENDDVS ; SAVE POSSIBLY ALTERED BLOCK POINTER
1) JRST ENDDV0 ; GO SET UP THIS STR
****
2)16 JRST ENDDV0 ; GO SET UP THIS STR
**************
1)17 STKVAR <LPTR,DPTR> ;TEMPS FOR DSK*
1) ANDCAM B,FLAGS(TXT) ;CLEAR IT
****
2)17 ANDCAM B,FLAGS(TXT) ;CLEAR IT
**************
1)17 NOINT ;MAKE SURE ASGFRE DOES NOT GET UPSET
1) CALL GNJFN3 ;MAKE SURE WE HAVE AN UNTRIMMED BLOCK
1) RETBAD (,<OKINT>) ;FROM THE JSB, PASS DOWN FREE SPACE ERROR
1) OKINT
1) MOVX T2,<POINT 7,> ;GET BYTE POINTER LEFT HALF
1) HRRI T2,1(T1) ;GET THE ADDRESS OF THE BLOCK
1) MOVEM T2,DPTR ;SAVE THE TARGET POINTER
1) MOVX T2,<POINT 6,> ;GET SIXBIT BYTE POINTER
1) HRR T2,STRTAB+PSNUM ;GET ADR OF SDB FOR PS
1) MOVEM T2,LPTR ;SAVE THE SOURCE POINTER
1) MOVEI T3,6 ;SIX CHARACTERS
1) STRDE9: ;SIXBIT TO ASCII LOOP
1) ILDB T2,LPTR ;GET A BYTE
1) SKIPN T2 ;NULL?
1) JRST STRD10 ;YES
1) ADDI T2,40 ;CONVERT TO ASCII
1) IDPB T2,DPTR ;STORE THE ASCII
1) SOJG T3,STRDE9 ;LOOP FOR ALL SIX CHARS OR UNTIL NULL
1) STRD10: ;HERE WHEN ALL CHARS CONVERTED
1) SETZ T2, ;GET A NULL BYTE
1) IDPB T2,DPTR ;SAVE THE NULL BYTE
1) MOVEI T2,2(T1) ;DETERMINE A REASONABLE END OF THE BLOCK
1) HRRM T2,FILOPT(JFN) ;MAKE SURE THIS BLOCK DOES NOT GET OVERTRIMMED
1) TQO <STRSF,STEPF> ;REMEMBER THAT THE DEVICE FIELD IS *
****
2)17 MOVE B,[ASCIZ/PS/] ;START AT STRUCTURE 0
2) MOVEM B,1(A) ;STORE NEW STRING OVER OLD ONE
2) TQO <STRSF,STEPF> ;REMEMBER THAT THE DEVICE FIELD IS *
**************
1)24 HRLM A,FILTMP(JFN) ;IN CASE STRDVD CHANGED IT
1) CALL CHKLNM ; SEE IF THIS DEFAULT IS A LOGICAL NAME
****
2)24 CALL CHKLNM ; SEE IF THIS DEFAULT IS A LOGICAL NAME
**************
-------
3-Jan-85 11:53:47-PST,353;000000000000
Mail-From: MRC created at 3-Jan-85 11:53:43
Date: Thu 3 Jan 85 11:53:43-PST
From: Mark Crispin <
[email protected]>
Subject: KWP's DSK* fix
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Is in the 5.3 monitor sources at Score.
-------
6-Jan-85 08:24:34-PST,804;000000000000
Mail-From: MRC created at 6-Jan-85 08:24:27
Date: Sun 6 Jan 85 08:24:27-PST
From: Mark Crispin <
[email protected]>
Subject: ten years ago today
To:
[email protected],
[email protected], BBoard@LOTS-A
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Ten years ago today, the world ended at SAIL and at TOPS-10
systems. The system date for files for these systems was a 12
bit value of the form ((((year-1964)*12)+(month-1))*31)+day-1.
The world began on January 1, 1964 for a small operating system
for an obscure computer, the PDP-6.
On January 5, 1975 the date overflowed.
This was fixed by adding 3 bits to the value in a different
place in the file descriptor block.
-------
6-Jan-85 15:36:52-PST,1225;000000000000
Return-Path: <
[email protected]>
Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Sun 6 Jan 85 15:36:43-PST
Date: Sun 6 Jan 85 15:37:12-PST
From: William "Chops" Westfield <
[email protected]>
Subject: SQ program for tops20 is working....
To:
[email protected],
[email protected],
[email protected]
cc:
[email protected]
I have managed to get the SQ.C program to compile and work under
tops20. (at least, the SQed files can be unsqueezed using GZ's
USQ.MID program). For those of you unfamilliar with SQ and USQ,
they are huffman data compression programs originally written
for CPM, and more recently converted to MSDOS and UNIX. Byte
count reductions of 30-40% are common on typical text files, and
20% or so page count reductions occur even on tops20, where you
lose a byte per word going from 7bit to 8bit bytes.
The files SQ.C and SQ.EXE are available for anonymous FTP from
SRI-AI:<BILLW>. Note that SQ.C is compiled using a C compiler
under development at Stanford that I dont think is available for
distribution yet. Also, an object code patch is required to the
EXE file in order to prevent it from converting CRLFs to unix
style newlines...
Enjoy
BillW
-------
6-Jan-85 15:51:48-PST,633;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Sun 6 Jan 85 15:51:41-PST
Date: Sun 6 Jan 85 15:52:03-PST
From: William "Chops" Westfield <
[email protected]>
Subject: warning on tops20 SQ program...
To:
[email protected],
[email protected],
[email protected],
[email protected]
I just SQ'ed a 500+ page mail file, and found it wouldn't unsqueze
(got a premature end of file message). It would probably be a good
idea to make sure anything you SQ can be USQed before the original
file is deleted... (meanwhile, Ill try to track down the bug...)
BillW
-------
7-Jan-85 15:11:14-PST,684;000000000000
Return-Path: <
[email protected]>
Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Mon 7 Jan 85 15:10:52-PST
Date: Mon 7 Jan 85 15:12:43-PST
From:
[email protected]
Subject: MICRO FILE TRANSFERS THRU THE TAC
To:
[email protected]
Is there a version of MODEM that will support file transfers to/from
the TAC? I tried doing file transfers to/from the 20 from a KAYPRO using
both MODEM and KERMIT... No luck.
KERMIT gets further along than MODEM but the error rate is
quite high. I have read the TAC-USERS.whatever file from the NIC
but still have problems?
Any assistance would be appreciated.
Jim Rallis (805) 277-6990
-------
7-Jan-85 16:07:12-PST,1714;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 7 Jan 85 16:06:17-PST
Date: 7 Jan 1985 17:07 MST (Mon)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: RALLIS@EDWARDS-2060
Cc: TOPS20@SU-SCORE
Subject: MICRO FILE TRANSFERS THRU THE TAC
In-reply-to: Msg of 7 Jan 1985 16:12-MST from RALLIS at EDWARDS-2060.ARPA
Jim,
THE *latest* version of MODEM (and other related CP/M-related programs
for TOPS-20) are kept in MICRO:<CPM.TOPS-20> here. Make sure you have
the current version.
Secondly, you *must* use the "N" secondary option to tell MODEM to
negotiate binary mode with the TAC on your behalf. However, binary
mode negotiations *will* fail without notice if TAC Flow Control is on
in either direction. (It is *not* clear, but supposedly there is a
change in the TAC code that will permit Flow Control in one direction
OR the other to co-exist with binary mode, but you don't want this.)
The TAC port @R command, a host or user @C, or a hangup does NOT clear
any previously invoked Flow Control. Therefore, for insurance, you
must type @F I E<cr> and @F O E<cr> to clear those modes before using
either MODEM or KERMIT.
Lastly, do not expect to upload (to your mainframe) at *any* speed
above 300bps UNLESS the port you're using has been explicitly
reconfigured for an input buffer size of at least 134. The default is
64 (or less in some cases) and both MODEM and KERMIT will overrun that
buffer. KERMIT, however, has an option to control buffer size. Check
directly with Keith Petersen (W8SDZ@SIMTEL20) for specifics on using
KERMIT through a TAC.
--Frank
7-Jan-85 21:03:20-PST,2025;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 7 Jan 85 21:03:07-PST
Date: 7 Jan 1985 22:04 MST (Mon)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To:
[email protected]
Cc: INFO-CPM@AMSAA, INFO-MICRO@BRL, TOPS-20@SCORE
Subject: TOPS-20 SQ and TOPS-20 MODEM
Bill Westfield and I were working on somewhat different versions of C
sources to SQ for TOPS-20 use, using different compilers. My version,
based on SQU-PORT.LBR, a "portable" version, uses the "MIT C" compiler
and runtime package, and was completed shortly after Bill's
announcement, with Eliot Moss' help.
Although there are some significant differences in both versions -
look for an announcement momentarily, both produce files with a byte
size of 8. One difference is that my version produces files with the
ITS Binary header. This caused a problem with MODEM only - the other
CP/M-related programs for TOPS-20, such as USQ, handled this just
fine.
So, there is now a new version of MODEM (310) for TOPS-20 with
reworked automatic file type determination code, and which now also
happens to write ITS Binary files with a bytesize of 8 instead of the
old 36.
Source and a ready-to-run executable are in MICRO:<CPM.TOPS-20>MODEM.*
here.
For those of you wishing to try my version of SQ, you may FTP it from
SYS: here. Sources are not quite ready for release yet.
As Bill noted earlier, both versions of TOPS-20 SQ are capable of
squeezing arbitrarily large TOPS-20 files (hopefully text files as
both programs assume). Unfortunately, USQ/TYPESQ use file memory
mapping techniques which limit the size of the files that can be
handled. (At the time USQ/TYPESQ was written, it wasn't expected to
handle but typically sized CP/M files.) There *may* be a version of
USQ/TYPESQ available to handle such large files in the near future.
In the meantime, be aware of the potential problem.
--Frank
8-Jan-85 07:14:02-PST,1656;000000000000
Return-Path: <SY.FDC%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 07:13:51-PST
Received: from CU20B.ARPA by columbia.arpa; Tue, 8 Jan 85 10:15:35 est
Date: Tue 8 Jan 85 09:48:52-EST
From: Frank da Cruz <SY.FDC%
[email protected]>
Subject: [Jim Guyton <guyton@rand-unix>: Kermit over Arpanet/Milnet TAC's]
To:
[email protected]
Cc:
[email protected]
Here are some hints about use of Kermit thru a TAC. Also note that some
versions of Kermit (including DEC-20 Kermit and version 4 of CP/M-80 Kermit)
have built-in commands for dealing with TACs. It should be noted that once the
TAC is in binary mode, any FF (hex) bytes need to be sent twice, since they are
the TAC intercept character; DEC-20 and CP/M Kermits take care of this, but I
don't think any of the others do. This would only make a difference for binary
files.
---------------
From: Jim Guyton <guyton@rand-unix>
Date: 23 Dec 84 22:17:32 PST (Sun)
To: Info-Kermit-request@columbia-20
Subject: Kermit over Arpanet/Milnet TAC's
Excuse me if this is already documented, but it might be worth a
note in the Kermit user's manual on how to run kermit over TAC's.
What I've read / figured-out is ...
1) Use the "@B O S" and "@B I S" commands to the tac
to get into binary mode, and
2) Reduce the size of the send buffer (by "set send packet-size 25"
to the pc version of kermit).
This combination just worked over a two-network hop (milnet-arpanet-randnet)
but that a packetsize of 96 was too big for the tac took me by surprise.
Anyway, just fyi ...
-- Jim
-------
8-Jan-85 08:15:47-PST,1083;000000000000
Return-Path: <@SRI-CSL:
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 08:15:33-PST
Date: 8 Jan 1985 08:10-PST
Sender: GEOFFM@SRI-CSL
Subject: Re: [Jim Guyton <guyton@rand-unix>: Kermit over Arpanet/Miln...
From: Geoffrey C. Mulligan (USAFA) <GEOFFM@SRI-CSL>
Reply-To: GeoffM@SRI-CSL
To: sy.fdc%cu20b@COLUMBIA-20
Cc: RALLIS@EDWARDS-2060, TOPS-20@SU-SCORE
Message-ID: <[SRI-CSL] 8-Jan-85 08:10:07.GEOFFM>
In-Reply-To: The message of Tue 8 Jan 85 09:48:52-EST from Frank da Cruz <SY.FDC%
[email protected]>
I would not use the TAC commands @b i s and @b o s since you will
not be able to issue any other tac commands after that. If you
use @i <num> (<num> = decimal ascii equivalent) it will change
the TAC's intercept character from @ to whatever you set it to.
I usually use @i 4. This will set the intercept character to
control-d. Since kermit will not send any non-printing
characters any control character will work. Also a packet size
of 25 is much to small. I usually use a packet size of 50.
geoff
8-Jan-85 13:43:41-PST,1516;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 13:43:24-PST
Date: 8 Jan 1985 14:29 MST (Tue)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: INFO-CPM@AMSAA
Cc: TOPS-20@SCORE
Subject: Another TOPS-20 SQ/USQ Available
Yet another version of a TOPS-20 SQ and USQ is now available, based on
the "portable" C version, for ANONYMOUS FTP from MICRO:<CPM.T20-SQUSQ>
here on SIMTEL20. These programs are meant to be compiled with the
"MIT C" compiler. However, ready-to-run executables are available in
the same directory. Note: USQ is a special version, not to be
confused with the more generic and significantly faster version of USQ
by GZ@MC in MICRO:<CPM.TOPS-20>. Please rename this special version
of USQ to LUSQ (for Large file USQ) if you choose to install it on our
system.
SQ differs from Bill Westfield's recently announced version in the
handling of input and output filenames and input and output padding.
This version also writes output files with the ITS Binary header, a
known sore point subject to change.
USQ is different from GZ's USQ in that it will handle any arbitrarily
large file that SQ can produce; it assumes the original file was an
ASCII text file; it is more than three times slower. It also has the
TYPESQ functionality by the use of the -count option for previewing
without actually unsqueezing.
Bug reports to me, please.
--Frank
8-Jan-85 15:06:42-PST,960;000000000000
Mail-From: MRC created at 8-Jan-85 15:06:18
Date: Tue 8 Jan 85 15:06:18-PST
From: Mark Crispin <
[email protected]>
Subject: WARNING re: Kermit and TAC's
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Kermit takes advantage of a BUG in TOPS-20, that is, that 0FFh (or
'377 octal) in the output data stream is not doubled and hence is seen
as the Internet Telnet protocol escape (IAC). This bug is FIXED at
Score and at several other Internet sites, and I imagine that DEC will
have it fixed in a forthcoming release.
I have suggested to Kevin Paetzold that a new TTY MTOPR% be added
which will put the network in binary mode (which is what Kermit wants
to do). I wrote up a description of the interface, but as yet I have
had no answer.
Do NOT trust this misfeature in Kermit! Use @B I S !!!
-- Mark --
-------
8-Jan-85 17:13:36-PST,668;000000000000
Return-Path: <iglesias@uci-750a>
Received: from UCI-750a by SU-SCORE.ARPA with TCP; Tue 8 Jan 85 17:13:22-PST
Date: 08 Jan 85 17:14:15 PST (Tue)
To: tops-20@su-score
Subject: 2020 needed
From: Mike Iglesias <iglesias@uci-750a>
Received: from Localhost by UCI-750a; 08 Jan 85 17:14:27 PST (Tue)
We at the University of California are looking for a 2020 to run
TOPS-10 on. We need the following configuration: 512k memory, TU77 tape
drive, 16-32 ports. If you know of one that is available, please let
me know.
Also, has anybody used ABLE or EMULEX DZ equivalents on a 2020?
Thanks.
Mike Iglesias
University of California, Irvine
iglesias@uci
9-Jan-85 02:15:26-PST,1030;000000000000
Return-Path: <steinar@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Jan 85 02:15:14-PST
Received: by oslo-vax.ARPA (4.12/4.7)
id AA06156; Wed, 9 Jan 85 10:59:43 -0100
Date: Wed, 9 Jan 85 10:59:43 -0100
From: steinar@oslo-vax (Steinar Kj{rnsr|d)
Message-Id: <
[email protected]>
To:
[email protected]
Subject: PCL not working with version 6 TOPS-20 ?
At the Institute of Informatics at the University of Oslo
we are currently installing the CI ( Computer Interconnect )
software to interconnect our two DEC-2065's. To run this
software, V6 TOPS-20 is needed and is now installed.
However, a great problem has arised: Our PCL-EXEC will not
work. This is really a great problem since most of our
local system software depends on PCL, i.e. building of
user directories etc. ( We have approx. 1400 local users,
most of them students!)
Now, have anyone out there heard about a PCL-EXEC running
under V6 ? Does anyone know about cites running V6 ?
-- Steinar.
9-Jan-85 06:23:42-PST,939;000000000000
Return-Path: <SY.FDC%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Wed 9 Jan 85 06:23:34-PST
Received: from CU20B.ARPA by columbia.arpa; Wed, 9 Jan 85 09:25:17 est
Date: Wed 9 Jan 85 09:23:48-EST
From: Frank da Cruz <SY.FDC%
[email protected]>
Subject: Re: WARNING re: Kermit and TAC's
To:
[email protected],
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Tue 8 Jan 85 22:13:33-EST
Mark's right, of course. The TAC support in DEC-20 Kermit was put there at the
insistent urging of many people who wanted it that way. It is only enabled if
you do a SET command to turn it on. If you don't do the SET command, then you
can do "@B I S", "@B O S" yourself, which would be preferable on DEC-20 systems
that DO double IAC's themselves. When DEC decides how it's going to handle
binary mode on TAC's, Kermit will be changed accordingly. - Frank
-------
10-Jan-85 11:55:04-PST,943;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jan 85 11:54:50-PST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 10 Jan 1985 14:49:00 est
Date: 10 Jan 85 18:13 +0100
From: Knut_Smaaland_UiO%
[email protected]
Reply-to: Knut_Smaaland_UiO%
[email protected],
TOPS-10/20_SIG%
[email protected],
steinar_%_OSLO-VAX%
[email protected]
To: TOPS-10/20_SIG%
[email protected],
[email protected],
steinar_%_OSLO-VAX%
[email protected]
Subject: PCL not working with version 6 TOPS-20 ?
Message-ID: <85665@QZCOM>
In-Reply-To: <
[email protected]>
The PCL Exec distributed on the 6.0 Tools tape works
fine with T20/6.0
10-Jan-85 23:32:49-PST,559;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jan 85 23:32:38-PST
Date: 10 Jan 85 23:19:00 EST
From: Charles Hedrick <
[email protected]>
Subject: Unix for the 20?
To:
[email protected]
From "perspective, Digital Equipment Corporation's Computer Newsletter",
p. 9:
With the introduction of PRO/VENIX, Digital becomes the
first major vendor to provide UNIX-based systems for all
of its processors.
Anyone sufficiently tired of Tops-20 that you want to move to
ULTRIX-20?
-------
11-Jan-85 09:29:50-PST,880;000000000001
Return-Path: <eraps1@nadc>
Received: from nadc by SU-SCORE.ARPA with TCP; Fri 11 Jan 85 09:29:36-PST
Date: 11 Jan 1985 12:26:16-EST
From: eraps1@NADC
To: tops-20@su-score
Subject: DUMPER Tape Format
Cc: eraps1@NADC
Hi,
Does anyone know the format (at a bit level) of a tape dumped useing
the TOPS-20 utility DUMPER? I made some tapes useing DUMPER when I
was working under a TOPS-20 system and am now unable to read them.
I am now working under UNIX, and so have been able to read the records
but the data is unitelligable (I believe some type of data compression
algorithm was used). Given the detailed format of the tape I would
be able to write a conversion routine fairly easily, but without it
the task verges on impossible.
Replies directly to me please, as I am not on this net.
Thanks in advance,
Rob Ginn (
[email protected])
11-Jan-85 19:09:31-PST,1073;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 11 Jan 85 19:09:03-PST
Date: Fri 11 Jan 85 22:07:44-EST
From: Clifford Neuman <
[email protected]>
Subject: CRDIR allows negative quotas
To:
[email protected]
It seems that CRDIR allows one to set their logged out (permanent)
quota to a negative value, and that doing so (quite naturally)
increases the quota of the superior. Here is a patch to JSYSF that
will fix the problem. Actually, this fix will also cause an error
when NOT updating ones logged out quota if it is currently negative.
Not wanting to add a new error to CRDIR, I used
CRDI14 - Request exceeds superior directory permanent quota.
-------
CRD3AC: LOAD A,DRLOQ,(Q1) ;GET CURRENT LOQ
UMOVE B,.CDLOQ(Q2) ;GET USERS VALUE
TXNN Q3,CD%LOQ ;SETTING LOQ?
MOVE B,A ;NO - NO CHANGE
;;; Begin 3053 (DON'T ALLOW NEGATIVE LOGGED OUT QUOTA)
SKIPGE B
RETBAD (CRDI14,<CALL USTDIR>) ;CAN'T SET NEGATIVE QUOTA
;;; End 3053
SUB A,B ;COMPUTE DELTA
MOVEM A,CRDDOQ ;SAVE IT
-------
13-Jan-85 20:53:39-PST,947;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 13 Jan 85 20:53:31-PST
Date: 13 Jan 1985 21:55 MST (Sun)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: INFO-CPM@AMSAA
Cc: TOPS-20@SCORE
Subject: TOPS-20 SQ/USQ Update
SQ now accepts wild-card filenames and properly handles ITS Binary and
TOPS-20 Binary input files as well as common ASCII text files.
However, if a file with a bytesize of 36 is not an ITS Binary file, it
blindly assumes the file is ASCII, even though the file may be
something else.
USQ (which should be renamed LUSQ to avoid confusion with GZ's far
superior USQ) now also accepts wild-card filenames and still blindly
assumes the output file is an ASCII text file. (GZ's USQ tries to
guess the output file bytesize.)
Sources and executables are in MICRO:<CPM.T20-SQUSQ> on SIMTEL20.
--Frank
14-Jan-85 15:23:10-PST,549;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Jan 85 15:22:32-PST
Date: Mon 14 Jan 85 15:23:09-PST
From: David Roode <
[email protected]>
Subject: <SPOOL>PRIMARY-MASTER-QUEUE-FILE.QUASAR
To:
[email protected]
Location: EJ286 Phone: (415) 859-2774
Is there a fix for the problem of this file ballooning way
out of proportion to the amount of useful data contained therein?
Specifically, we see it grow to 1200 or 1500 pages where 100 pages
ought to be more than enough.
-------
15-Jan-85 07:30:19-PST,1226;000000000000
Return-Path: <
[email protected]>
Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Jan 85 07:30:08-PST
Date: 15 Jan 1985 10:29-EST
Sender:
[email protected]
Subject: Re: <SPOOL>PRIMARY-MASTER-QUEUE-FILE.QUASAR
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNF.ARPA]15-Jan-85 10:29:50.RBASCH>
In-Reply-To: The message of Mon 14 Jan 85 15:23:09-PST from David Roode <
[email protected]>
We had the same problem, and discovered that the cause was the monitor
sending messages to Quasar every time an archived file was expunged, so
that notification could be sent to the directory owner. Since the queue
file contains one request per page, and can grow to a maximum of only
about 2500 pages, we had to kill off the queue file every time someone
deleted a sizable number of archived files. Our solution was simply to stop
the monitor from sending these messages to Quasar, in the belief that
the notification (which doesn't work that well in any case) is less
important than having a reliable spooling system. Since then, I believe
that our queue files have not grown at all. If you are interested, the
code to be removed is in DELFI3 (DISC.MAC).
Bob Basch
15-Jan-85 15:05:06-PST,1812;000000000000
Return-Path: <SY.SLOGIN%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 15 Jan 85 15:04:22-PST
Received: from CU20B.ARPA by columbia.arpa; Tue, 15 Jan 85 18:05:15 est
Date: Tue 15 Jan 85 18:03:49-EST
From: Thomas De Bellis <Sy.SLogin%
[email protected]>
Subject: Re: <SPOOL>PRIMARY-MASTER-QUEUE-FILE.QUASAR
To:
[email protected]
Cc:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected]" of Tue 15 Jan 85 10:29:00-EST
That is not the whole story. When Quasar deallocates a page in the Q file
(most often when some processor does a RELEASE), it does NOT do a PMAP%
to get rid of the page in the file. It marks the page as not in use and
considers it for usage before allocating another page in the Q file (most
often when a CREATE is requested).
As you can see, this is not exactly a bug as it makes Quasar somewhat more
efficient be virtue of the fact that you cut the number of PMAP%'s (and
associated allocations and DSKBTTBL writes) roughly in half. This is good.
Here, however, we were very tight on disk space so I wrote some code that
tosses the page in the Q file. I don't toss the index pages (for you folks
who know the format of the Q file). This code took me 20 minutes to write
and involved a one line change to QSRFSS (the failsoft module) and the
addition of one routine to QSRT20 (the Tops-20 interface) to handle the
associated PMAP%'s.
It doesn't seem to have slowed Quasar down at all. Our Q files are about
40 pages long on the average. If anyone is interested in this, I will
dust off my sources and post the changes. They are pretty trivial if
you look at QSRFSS; that's why I refrained from saying anything at first.
-- Tom De Bellis
CUCCA Systems Group
-------
16-Jan-85 08:31:49-PST,1688;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Jan 85 08:31:27-PST
Date: 16 Jan 85 11:32:54 EST
From: Charles Hedrick <
[email protected]>
Subject: APL problem
To:
[email protected]
We are having a problem with APLSF. The problem is so basic that
I can't believe it is really present in the distributed version.
The copy that we have is suspect. Somehow we don't seem to get
distributions, and I am not quite sure what the history is of the
copy we have. Anyway, could someone who has an up to date copy,
2(554), please see whether this bug is present in their copy:
A_(.IO20)=(.IO20)
A
A[.IO20]
For those of you who don't know APL, the first statement creates
a vector of 20 1's. The second simply prints it out. You should
see a lie with 20 1's on it. The third prints it out a different
way. In effect it does
for i := 1 to 20 do a[i]
A[15] prints as a 0. You can also simply type A[15], which will
also show as 0. We find that we get different results with
different variable names. That is, if you use D instead of A,
you may get a different failure. In case this is a "magic number"
problem, it might be useful to test this for several different
variable names before telling me it works.
Anyway, if we can find a copy of 554 in which this is not
present, we would like to FTP it from you. If it is present, then
of course we will SPR it. We have looked around the network,
and are surprised how many different, wildly out of date, copies
of APLSF there are. Is there something wrong with APL distribution,
or have people just dropped maintenance on it?
-------
16-Jan-85 22:04:05-PST,457;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Jan 85 22:03:48-PST
Date: 17 Jan 85 01:04:14 EST
From: Charles Hedrick <
[email protected]>
Subject: APLSF problem solved
To:
[email protected]
One of the folks at DEC was kind enough to give me a copy of the
current field image APLSF. It does not have the bug that I
reported. I guess I will never know whether the bug came from.
-------
17-Jan-85 17:54:56-PST,491;000000000000
Mail-From: BILLW created at 17-Jan-85 17:54:48
Date: Thu 17 Jan 85 17:54:48-PST
From: William "Chops" Westfield <
[email protected]>
Subject: SET TER PAUSE CHARACTER
To:
[email protected]
the character you specify for the pause/unpause functions seems to only
have any effect when TER PAUSE END-OF-PAGE is turned on - they have no
effect when TER PAUSE END is off and TER PAUS COMMAND in on. Is this a
bug, or is this the way it is supposed to be?
Thanks
Bill W
-------
17-Jan-85 23:49:55-PST,2087;000000000000
Mail-From: ALMQUIST created at 17-Jan-85 23:49:45
Date: Thu 17 Jan 85 23:49:45-PST
From: Philip Almquist <
[email protected]>
Subject: Re: SET TER PAUSE CHARACTER
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Thu 17 Jan 85 17:55:05-PST
Bill,
As I recall, I puzzled for quite a while over the TER PAUSE CHAR
stuff in the Monitor once upon a time and decided it was a "feature", or
at least that's what the guy who wrote the code thought. My users (at CMU
at that time) thought it damn confusing... Here is the explanation I
garnered from studying the code (perhaps by now a bit confused by
time; I haven't looked at that code since it got out of field test):
TERMINAL PAUSE END controls what the Montitor calls page mode.
In page mode, output is stopped when the page fills up and is resumed
when the user types his "page unpause" character. Also in page mode,
the user can type his "page pause" character to stop output
immediately. Again, output is resumed only when the user types his
page unpause character. This is all very obvious I'm sure. But what
may not have been obvious: in the above cases, the user cannot
restart output with ^Q unless ^Q is the user's "page unpause"
character.
That is because XON/XOFF processing, controlled by TERMINAL
PAUSE COMMAND, is a very different concept. Output stops when the
user types ^S, and resumes when the user types ^Q. As you might have
guessed after the last paragraph, typing the "page unpause" character
is not a substitute for typing ^Q.
The observant reader will note from the above that there is a
bug, though not quite where Bill suspected: the TERMINAL [NO] PAUSE
COMMAND command has no business futzing with the page mode stuff. I
forget whether that is an Exec bug or a Monitor bug. I didn't fix it
at CMU because by the time I figured out all of the above my users had
become so confused they had all decided not to use the new TERMINAL
PAUSE CHAR command...
Philip
-------
18-Jan-85 06:31:22-PST,827;000000000001
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Jan 85 06:31:13-PST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 18 Jan 1985 06:45:02 est
Date: 16 Jan 85 10:04 +0100
From: Klaas_Lingbeek%
[email protected]
Reply-to: Klaas_Lingbeek%
[email protected],
TOPS-10/20_SIG%
[email protected]
To: TOPS-10/20_SIG%
[email protected],
[email protected], eraps1@NADC
Cc: eraps1@NADC
Subject: DUMPER Tape Format
Message-ID: <86438@QZCOM>
In-Reply-To: <85916@QZCOM>
THE FORMAT IS IN DUMPER.MAC IN COMMENTS,TRY TO GE A COPY OF
IT
FROM ONE OF YOUR U.S. COLLEGUES
18-Jan-85 06:32:00-PST,1005;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Jan 85 06:31:52-PST
Date: Fri, 18 Jan 85 14:33 GMT
From: SAMUELSON%
[email protected]
Subject: Re: SET TER PAUSE CHARACTER
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFE>
To: tops-20@SU-SCORE.ARPA
In-Reply-To: Message from "Philip Almquist <
[email protected]>" of Fri 18 Jan 85 00:00:03-PST
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
There is one place where it is very important to know about that
silliness with pause/unpause characters. If you happen to use
DECNET, and you make a virtual terminal connection to a remote
host, and the remote host is in pause on end-of-page mode, then
you MUST use some pause/unpause character that will get thru DECNET.
If I remember correctly, it is set to control-A by default on
DECNET lines.
- Sam -
-------
18-Jan-85 09:28:08-PST,602;000000000000
Mail-From: MRC created at 18-Jan-85 09:27:59
Date: Fri 18 Jan 85 09:27:59-PST
From: Mark Crispin <
[email protected]>
Subject: TER PAUSE
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
If you want to have pausing on a character without pausing at end
of page, all you have to do is set your page length to 0 (infinity). That
is pretty much all the monitor uses that value for. Some utilities such
as EMACS and SYSDPY use it to, but I think they default to 24 if it is 0.
-------
18-Jan-85 14:19:38-PST,785;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 18 Jan 85 14:18:55-PST
Date: 18 Jan 85 17:20:01 EST
From: Charles Hedrick <
[email protected]>
Subject: APLSF: I spoke too soon.
To:
[email protected]
The new version of APLSF I referred to in a previous message (edit 554)
turns out to have its own problem:
A _ 2 2 .RO 0
A
0 0
0 0
A[1;1] _ 1.5
domain error
2 2 .RO 0 creates an integer array, filling it with 0's. In order to
execute A[1;1] _ 1.5, APL has to convert the array to a real array.
Apparently that conversion fails.
This is a fairly serious error. We have now backed up to our old
version of APLSF, edit 435, pending a fix to this. We are issuing a
priority 1 SPR.
-------
18-Jan-85 16:19:36-PST,1448;000000000000
Mail-From: MRC created at 18-Jan-85 16:18:10
Date: Fri 18 Jan 85 16:18:10-PST
From: Mark Crispin <
[email protected]>
Subject: MMAILR maintenance release
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
This is to announce a very important bugfix to MMAILR. All sites
should update their copies of the mailsystem from MRC:<MM> in order to
get this fix.
There have been a number of reports of "hung MMAILRs", but until
recently I haven't gotten enough information to track it down. It
finally happened on Score when I was around. The problem was due to
certain cases of untimed outputs to the network, in particular, when
negotiating protocol.
All network output is now timed; unless there is a special timer
(e.g. the performance timers on message text) the default is 5 minutes.
So if a TCP connection hangs but doesn't cause a JSYS error the longest
that the connection can be hung for is 5 minutes. This timeout is for
the completion of a BOUT%, SOUT%, or SOUTR% system call and is not an
overall performance timeout the way it is when transmitting the text of
the message.
I hope this will remove most of the occurances of hung MMailrs. It
was quite unlikely (NCP didn't have this problem) so it's only now that
TCP is in reliable production that we see this sort of problem.
-------
19-Jan-85 12:41:08-PST,749;000000000000
Mail-From: MRC created at 19-Jan-85 12:41:04
Date: Sat 19 Jan 85 12:41:04-PST
From: Mark Crispin <
[email protected]>
Subject: NICUPD program
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I just saw that the NICUPD program has a flag called INSTAL which will
do the IPOPR% to make the monitor read in HOSTS.TXT. This is *not* a
good idea, due to a monitor bug. GTHST% queries are not locked against
while this is happening, so unless MMailr is stopped you are likely to
have all of your queued mail become bad queued mail.
I patched NICUPD at Score not to do the IPOPR% until somebody decides
to fix the monitor.
-------
19-Jan-85 12:54:12-PST,1265;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 19 Jan 85 12:54:09-PST
Date: Sat 19 Jan 85 12:57:14-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: NICUPD program
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Sat 19 Jan 85 12:46:51-PST
Mark, if you run the program at 6:00AM the chances of screwing up a mail
message or two are neglible. I've been running NICUPD at Sierra for over
a year now without any such problems. The one time I did have a problem
was when I reloaded HOSTS.TXT by hand on a heavily loaded system in the
middle of the day. One message to BBNG ended up queued as "bad" mail.
I have looked at the GTHST interlock bug. The whole damn JSYS needs to be
rewritten. The major problem is that there is at least one MRETN for every
possible function, making interlocking extremely ungraceful. If someone
is interested in some monitor hacking, it would be useful to carve the
existing GTHST% out of the monitor (i.e. create GTHST.MAC) and redo it
in a manner permitting interlocking. The same module would eventually be
replaced or rewritten to handle domain handling.
Kirk
-------
19-Jan-85 14:16:50-PST,1997;000000000000
Mail-From: MRC created at 19-Jan-85 14:16:47
Date: Sat 19 Jan 85 14:16:47-PST
From: Mark Crispin <
[email protected]>
Subject: Re: NICUPD program
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Kirk Lougheed <
[email protected]>" of Sat 19 Jan 85 12:54:15-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Kirk -
The problem is that if MMailr is running through the retransmit
fork NICUPD will kill most or all of the retransmit queue. I suspect
that Sierra has a *much* lighter mail load than Score, although I am
unable to do direct comparisions. However, Score handles 1500 or so
messages daily. A lot of what ends up in the retransmit queue is
BBoard, of course, but Score also has some other, important (like
research related!), mailing lists which tend to get into the retransmit
queue.
Essentially, MMailr on Score is almost always busy, even at 6AM,
and it isn't safe to run NICUPD in install mode at Score.
I too looked at the GTHST% problem once upon a time and came to
similar conclusions. Thank you, Mr. Borchek, for that wonderful JSYS.
Dan Tappan, Paul Mockapetris, and I started on a specification for a
new GTHST% which would include domain support. We came to the conclusion
that several extensions are essential, such as protocol/address mapping
(there are already hosts which have TELNET service on a different address
from SMTP) and otherwise better support for multi-homed hosts. Some of
the earlier extensions, such as your network/gateway additions, had to be
done more cleanly (as in "get gateway" and "get network" functions which
are different from "get host"). It was also clear that indices would
have to be flushed (this would probably affect only ancient software). I
got out of the loop when I left for Europe last summer. I think ISI has
the ball right now.
-- Mark --
-------
19-Jan-85 15:27:16-PST,767;000000000000
Mail-From: BILLW created at 19-Jan-85 15:27:12
Date: 19 Jan 1985 15:27-PST
Sender:
[email protected]
Subject: NICUPD and MMAILR
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Message-ID: <[SU-SCORE.ARPA]19-Jan-85 15:27:11.BILLW>
Since the primary conflict is between NICUPD and MMAILR, perhaps
a user level fix would solve the problems. Perhaps the two programs
can do ENQ/DEQ type operations. For efficiency, I suppose that the
best thing to do would be to use a couple of bits in MAILR.FLAGS,
since MMAILR already has this mapped. One bit for MMAILR to say that
its doing a scan or looking up a host name, one bit for NICUPD to say
that its updating the host tables... I realize this is a kludge.
BillW
19-Jan-85 15:30:14-PST,731;000000000000
Mail-From: MRC created at 19-Jan-85 15:30:09
Date: Sat 19 Jan 85 15:30:09-PST
From: Mark Crispin <
[email protected]>
Subject: Re: NICUPD and MMAILR
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Sat 19 Jan 85 15:27:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Gawd, what a kludge. I'm trying to move away from the MAILER.FLAGS
hack. It won't port too well to a CFS type of environment. I've
been considering an IPCF protocol to pause and resume MMAILR, as
part of the wakeup stuff. However, the right thing is to fix the
monitor.
-------
20-Jan-85 22:48:23-PST,1215;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Jan 85 22:48:14-PST
Date: Sun 20 Jan 85 22:51:21-PST
From: Kirk Lougheed <
[email protected]>
Subject: TCOPR% bugs
To:
[email protected]
It is possible for the monitor to leave a TCP: JFN in a locked state
(i.e, no longer usable) if you use either an unimplemented TCOPR%
function or if you attempt to use TCOPR% on a TCP: JFN that is no longer
associated with a TCB. The problem is caused by using the RETERR macro
without first making sure that the JFN is indeed unlocked. The problem
occurs in two places in TCPJFN.MAC.
;;;
;;; First occurence
;;;
TCOPR2: ;here when we have the jfn and it is tcp
SKIPN TCB,FILTCB(JFN) ;get the TCB address
IFE STANSW,<
RETERR(TCPX36) ;can not reopen a TCP JFN
>;IFE STANSW
IFN STANSW,<
RETERR(TCPX36,<CALL UNLCKF>) ;can not reopen a TCP JFN
>;IFN STANSW
UMOVE T1,T2 ;get the function code back
;;;
;;; Second occurence
;;;
DTCSUB: ;set upper bound for retransmission
IFE STANSW,<
RETERR (TCPX40) ;not yet implemented
>;IFE STANSW
IFN STANSW,<
RETBAD (TCPX40) ;not yet implemented
>;IFN STANSW
-------
20-Jan-85 23:01:08-PST,1422;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 20 Jan 85 23:01:04-PST
Date: Sun 20 Jan 85 23:04:06-PST
From: Kirk Lougheed <
[email protected]>
Subject: TCOPR% bug and MAISER
To:
[email protected]
I found the TCOPR% bug mentioned in my message to the general TOPS-20 list
by attempting to use MRC's latest MAISER. If you run MAISER as an inferior
process of SMTPSV (the Columbia SMTP server), it trys to figure out the
foreign host by executing a currently unimplemented TCOPR% function.
The TCOPR% returns an error which causes alternative code to be executed
to determine the foreign host. The JFN, however, ends up locked and useless.
Mail service comes to a halt.
To run SMTPSV with MRC's latest MAISER, you will need a patched monitor.
I've fixed the 6.0 and 5.3 sources (TCPJFN.MAC) on Sierra.
Release 6.0 appears to have done something bad to TVT-based MAISER service.
I had terrible problems with mail delivery to Sierra until I started using
the Columbia SMTPSV. The GSB apparently also had problems with MAISER when
they went to 6.0; I believe they are also running SMTPSV. The program
itself is a simple minded fork controller that fires up MAISER forks
with primary I/O redirected to network JFNs. It would be very convenient if
SMTPSV's functionality were to be subsumed by NETSRV (hint, hint).
Kirk
-------
21-Jan-85 10:01:32-PST,853;000000000000
Mail-From: ALMQUIST created at 21-Jan-85 10:01:24
Date: Mon 21 Jan 85 10:01:24-PST
From: Philip Almquist <
[email protected]>
Subject: Re: SET TER PAUSE CHARACTER
To: SAMUELSON%
[email protected]
cc:
[email protected]
In-Reply-To: Message from "SAMUELSON%
[email protected]" of Fri 18 Jan 85 06:32:01-PST
^S/^Q go through DECnet just fine, or at least I seem to
recall that I could run Emacs over DECnet without wedging myself every
time I tried to do a search. It's possible that was the result of a
local mod to the HOST program, but I'm not sure anymore. Glenn Marcy
had to beat up the HOST program rather extensively in order to make it
work "right".
We got around the pause/unpause silliness in DECnet by
eliminating the "feature" that sets the pause/unpause characters to ^A
on DECnet terminals.
Philip
-------
21-Jan-85 11:27:02-PST,1013;000000000001
Mail-From: MRC created at 21-Jan-85 11:26:58
Date: Mon 21 Jan 85 11:26:58-PST
From: Mark Crispin <
[email protected]>
Subject: Re: TCOPR% bug and MAISER
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Kirk Lougheed <
[email protected]>" of Sun 20 Jan 85 23:01:09-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I should mention that if you don't use TVT-based MAISER you
lose the functionality of being able to get the local host address
used for TCP connection. This is a feature Score needs. The
purpose of the TCOPR% call Kirk refers to was to get that information.
So far as I can tell there is no way in the current JFN interface to
get the local host address associated with a JFN.
We ought to beat on KWP to do this, and/or do it ourselves. It
is a simple matter to move that cell from the TCB, and that info is
really needed.
-- Mark --
-------
22-Jan-85 21:07:06-PST,5118;000000000001
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 22 Jan 85 21:06:37-PST
Date: 23 Jan 85 00:08:21 EST
From: Charles Hedrick <
[email protected]>
Subject: patches for TCP performance
To:
[email protected]
Here is a set of patches that we have installed in an attempt to
improve TCP performance in Telnet. We are interested both in getting
fast response time and in having the Internet fork not use much CPU
time. Several of them are tradeoffs, i.e. they may have bad as well
as good effects. So please think carefully before installing them.
I. Output buffers
The one patch that seems certainly right is in SETOBF (TTYSRV). This
is setting up terminal output buffers. It checks the speed of the
line and uses 1 buffer for slow speed, 2 for high speed.
Unfortunately, NVT's are unknown speed. It treats them as low speed.
The simplest fix would be at SETOBF+3, after the CAMN. Instead of
RET, use MOVEI T3,^D9600. This would cause NVT's to be treated as
high speed.
IA. Variation of I.
In an attempt to get large TCP packets when typing out files, I am
currently using 3 buffers for NVT's. This may well be unnecessary,
and could have the following bad effects: (1) increased memory usage,
(2) longer for ^C and ^S to take effect. My code is the following:
CAMN T3,[-1] ;KNOWN SPEED?
IFNSK. ;[147] no, assume network
MOVE T4,IBFRC2 ;[147] lots of buffers, to give big TCP packets
ELSE. ;[147]
;[147] RET ;NO. GIVE UP THEN
HRRZS T3 ;YES. GET OUTPUT SPEED
MOVE T4,IBFRC ;ASSUME SLOW SPEED
CAILE T3,LOWSPD ;ACCEPTABLE?
MOVE T4,IBFRC1 ;NO. GET OTHER VALUE
ENDIF. ;[147]
IBFRC2 is set up in STG at the same point as IBFRC1. It uses
3 buffers instead of 2:
File 1) GLOBS.MAC.12,22-Jan-85 02:12:35
File 2) GLOBS.MAC.10,27-Oct-84 10:30:23
1)1 QEXT <I8CAL,I8COP,IBFRC,IBFRC1,IBFRC2,IBPTIM> ;[147] add ibfrc2
1) QEXT <IDCTY,IDVKIL,IDVLCK,IDVLLK,IDXPG,IDXPGA>
****
2)1 QEXT <I8CAL,I8COP,IBFRC,IBFRC1,IBPTIM>
2) QEXT <IDCTY,IDVKIL,IDVLCK,IDVLLK,IDXPG,IDXPGA>
**************
File 1) STG.MAC.3,22-Jan-85 01:48:15
File 2) STG.MAC.2,13-Dec-84 13:26:47
1)2 NDG NTTBL2,3 ;[147] # of buffers for network lines
1) NDG NTTBF,ACTLNS*NTTBL1 ;NUMBER OF TTY BUFFERS
****
2)2 NDG NTTBF,ACTLNS*NTTBL1 ;NUMBER OF TTY BUFFERS
**************
1)54 ;[147] the following is a buffer description for network lines. Give them
1) ;[147] 3 buffers in order to keep TCP packet sizes up.
1) IBFRC2:: EXP <^D100>B7+<NTTBL>B11+<NTTBL2>B15+<NTTBL*NCHBF-1>B25+<NTTBL2*NCHBF-2>B35
1) OVRBCT==:1 ;NUMBER OF EXTRA BUFFERS FOR HIGH SPEED LINES
****
2)54 OVRBCT==:1 ;NUMBER OF EXTRA BUFFERS FOR HIGH SPEED LINES
**************
II. Quick activation of the Internet fork
I am concerned about response time for Telnet connections. A
character echo involves three process activiations:
- the Internet fork coming in
- the process doing the echo
- the Internet fork going out
I have reason to believe that most of the delay in echoing is caused
by these activations. Our response time was noticably worse than Unix
and VMS. The following code speeds up activation of the Internet fork
in both directions. It simply causes incoming packets and outgoing
characters to kick the scheduler. This assumes that the Internet fork
has enough priority that kicking the scheduler will activate it.
Since we run the Internet fork in queue 0, this is true for us. This
patch is one of the questionable ones. It could increase the
scheduler overhead, since it causes reschedules to happen more often.
We have not seen any ill effects so far, but we don't have that many
TCP connections so far. If you do this patch, you should watch your
system very carefully.
In TTANDV.MAC, at TVTCSO, add AOS PSKED before the RETSKP.
In IPNIDV.MAC, at CBDRQ1, add AOS PSKED before the PION.
III. Internet fork scheduling
Now for the most questionable of all. In order to get fast response,
we want to run the Internet fork in high priority. We tried various
things, and are now forcing it into queue 0. Of course this means
that if something goes wrong, the Internet fork can take over the
system. We have not seen that so far. The following change is in
IPIPIP.MAC, in the main loop.
**************
1) movei t1,1 ;[143] run in queue zero
1) MOVEM T1,JOBBIT ;[142] MAKE SURE WE CAN GO FAST
1) MOVE T1,FORKX ; ID of this fork
****
2)16 MOVX T1,JP%SYS ; GET THE SYS BIT
2) MOVEM T1,JOBBIT ; MAKE SURE WE CAN GO FAST
2) MOVE T1,FORKX ; ID of this fork
**************
I believe I have mentioned in individual messages that we have also
changed the HDISMS 1000 at the end of the main loop to HDISMS ^D30000.
The intent was to prevent the Internet fork from being taken out of
the balance set. Kevin tells me that this is a horrible idea, as the
30 sec. will be charged to the fork's quantum. This will cause
performance problems. If anyone has done this on the basis of my
recommendations, you might want to think again.
-------
24-Jan-85 08:21:06-PST,2259;000000000000
Return-Path: <@COLUMBIA-20.ARPA:STAFF.DOBKIN@NYU20>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 24 Jan 85 08:20:49-PST
Received: from NYU20 by CUCS20 with DECnet; 24 Jan 85 11:21:27 EST
Date: Thu 24 Jan 85 11:21:04-EST
From: DBD & Ittai
Subject: Monitor bug fix turns up Fortran bug
Sender: STAFF.DOBKIN@NYU20
To:
[email protected]
cc: Staff.Dobkin@NYU20, staff.hershman@NYU20
Reply-To: Staff.Dobkin@NYU20
X:<SPSSX>REPLY.DEL.1, 24-Jan-85 11:18:33, Edit by DBD
Autopatch tape #7 installs the following patch to RESET% to clear arithmetic
traps set by SWRTP%:
EDIT 3001 FOR MONITR
[SYMPTOM]
Arithmetic traps set by SWTRP% are left set when RESET% JSYS called.
[DIAGNOSIS]
RESET% JSYS does not clear arithmetic traps.
[CURE]
Add code to make RESET% clear arithmetic traps along with the rest of
its duties.
As we just discovered, this has the unfortunate result of making SPSSX (and
who knows what else) produce completely bogus output. The following patch
to SPSSX.EXE will fix the problem:
[PHOTO: Recording initiated Thu 24-Jan-85 10:59AM]
Tops-20 PCL Command Processor 5.1(1762)-2
$filddt
FILDDT>en p
FILDDT>g spssx.exe
[0 symbols loaded from file]
[Looking at file SPSSX.EXE.1]
54231/ JSYS 147 $$<
251120/ 0 JSYS 147 !this RESET% loses arithmetic overflow traps
251121/ 0 movei 1,400000 !so set them again for this process
251122/ 0 setz 2, !function code
251123/ 0 movei 3,242253 !arg block address
251124/ 0 jsys 573 !SWRTP% to set over/underflow traps
251125/ 0 setzb 1,2 !set ACs the way they were
251126/ 0 movei 3,11 !before closing the patch
251127/ 0 $>
251127/ 0 JUMPA 1,54232
251130/ 0 JUMPA 2,54233
54231/ JSYS 147 JUMPA 251120
^Z
$pop
[PHOTO: Recording terminated Thu 24-Jan-85 11:01AM]
A sure way to know if you have this problem is to run the validation suite
supplied with SPSSX. If test SXT3 fails, this patch is for you.
Other Fortran programs may have the same problem; an SPR will go out to DEC
as soon as we have more information.
Daniel B. Dobkin
Ittai Hershman
New York University
-------
24-Jan-85 10:05:31-PST,785;000000000000
Return-Path: <@COLUMBIA-20.ARPA:STAFF.DOBKIN@NYU20>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 24 Jan 85 10:05:16-PST
Received: from NYU20 by CUCS20 with DECnet; 24 Jan 85 13:06:58 EST
Date: Thu 24 Jan 85 13:06:26-EST
From: Daniel B Dobkin <Staff.Dobkin@NYU20>
Subject: more on RESET%/SWTRP% fouling SPSSX results
To:
[email protected]
cc: Staff.Dobkin@NYU20, Staff.Hershman@NYU20
The patch we supplied earlier allows the validation suite to complete, but
apparently does NOT fix all of the problems; there seems to be more than
one of those spurious RESET%s not followed by SWTRP%. We're working with
SPSS, Inc. on the problem and should have an answer by next week, but until
then I'd suggest advising your users....
\dbd
-------
25-Jan-85 07:50:32-PST,755;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Jan 85 07:50:08-PST
Date: Thursday, 24 January 1985 17:48-MST
Message-ID: <
[email protected]>
Sender: Steve Feldman <hplabs!oliveb!tymix!feldman@Ucb-Vax>
From: Steve Feldman <hplabs!oliveb!tymix!feldman@Ucb-Vax>
Subject: TOPS-20 Backup Interchange Program tape reader for UNIX wanted
ReSent-From: WANCHO@SIMTEL20
ReSent-To: TOPS-20@SCORE
ReSent-Date: Fri 25 Jan 1985 08:51-MST
I need to be able to read tapes written on a TOPS-20 system on
our 4.2BSD VAX system. Does anyone have a program to do this?
Thanks,
Steve Feldman
hplabs!oliveb!tymix!feldman
sun!idi!tymix!feldman
feldman@berkeley
25-Jan-85 12:50:35-PST,597;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Jan 85 12:50:24-PST
Received: ID <
[email protected]>; Fri 25 Jan 85 15:52:05-EST
Date: Fri 25 Jan 85 15:52:04-EST
From:
[email protected]
Subject: J0NRUN during system shutdown?
To:
[email protected]
Has anyone else had any trouble of this nature? It appears to be happening
to us with great consistancy now. The system almost all the way shutdown
(past the point of sending out "System down..." to all terminals and then
gets a J0NRUN. Any suggestions?
--Vince
-------
25-Jan-85 23:21:29-PST,1426;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Jan 85 23:21:16-PST
Received: ID <
[email protected]>; Sat 26 Jan 85 02:23:06-EST
Date: Sat 26 Jan 85 02:23:06-EST
From:
[email protected]
Subject: J0NRUN during system shutdown
To:
[email protected]
Well, I figured out the problem at last... We recently started running a
process which links to the console and logs all console I/O to a file for
later reference. During shutdown, the job with this process is logged-out.
This kills the job but leaves the links, which causes fork 0 to block when
the PTY output buffer fills up. Fork 0 is thus left in TCOTST on a nonactive
PTY for all eternity, resulting in a J0NRUN bughalt. This is pretty bogus,
but can easily be fixed.
At CHKHS4+4 make changes as follows (new lines marked "CS139"):
CALL DWNMSG ;SEND LAST MESSAGE
MOVE T1,CTYLNO ;CS139 Get console line number
TXO T1,<TL%CRO!TL%COR!.TTDES> ;CS139 Clear links
SETO T2, ;CS139 All of them, so job 0 doesn't wait on
TLINK% ;CS139 any spy PTY (causes J0NRUN)
ERJMP .+1 ;CS139 Shouldn't happen,
SETOM HSYST1 ;CLEAR FLAGS IN CASE RESTARTED
This problem was rather confusing - it didn't start happening with a new
monitor installation or new hardware, just a small change in operating
procedure which seemed to have little to do with the problem...
--Vince
-------
28-Jan-85 15:48:54-PST,637;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Jan 85 15:48:39-PST
Date: 28 Jan 1985 1846-EST
From: Tom Blinn <BLINN at DEC-MARLBORO>
To: Vince.Fuller at CMU-CS-C, TOPS-20 at SU-SCORE
Subject: Re: J0NRUN during system shutdown
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12083263004.27.275.91881 at DEC-MARLBORO>
Regarding: Message from
[email protected]
of 26-Jan-85 0227-EST
Of course, you could just run the process that does the logging under
JOB 0, and then it wouldn't get logged out, so you wouldn't get the
J0NRUN.
Tom
--------
28-Jan-85 20:52:45-PST,425;000000000001
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Jan 85 20:52:34-PST
Date: Mon 28 Jan 85 20:54:13-PST
From: Ed Pattermann <
[email protected]>
Subject: Reaper
To:
[email protected]
Has anyone modified REAPER to use WRITE dates instead of READ dates? I'd
be interested in those mods, or any others people have made to REAPER.
Thanks, Ed
-------
28-Jan-85 21:18:09-PST,558;000000000000
Return-Path: <
[email protected]>
Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Jan 85 21:17:54-PST
Received: ID <
[email protected].#Internet>; Tue 29 Jan 85 00:18:46-EST
Date: Tue, 29 Jan 1985 00:18 EST
Message-ID: <
[email protected]>
From: "Leonard N. Zubkoff" <
[email protected]>
To:
[email protected]
Subject: X-on/X-off response
Is there any way to get TOPS-20 to respond to X-off's immediately? On our
system, it appears that more than 100 characters may be printed after the X-off
is sent.
29-Jan-85 10:43:51-PST,2261;000000000000
Return-Path: <SY.SLOGIN%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 10:43:21-PST
Received: from CU20B.ARPA by columbia.arpa; Tue, 29 Jan 85 13:45:22 est
Date: Tue 29 Jan 85 13:41:34-EST
From: Thomas De Bellis <Sy.SLogin%
[email protected]>
Subject: TM78-C
To:
[email protected]
Way back in June 17, 1982, Columbia placed an order for a fourth
DECSYSTEM-20. Included in that order was a dual port access kit for
TU78 series tape drives called a TM78-C. We paid about 5,000 dollars
for the kit.
As you've probably guessed by now, DEC has never installed the part!
This wasn't a big deal for us because we didn't need to put the TU78's
on more than one system. We put them on our production machine where
all the big four pack PS's and RP07's are.
These days, however, we are testing RA81's and backing them up one
of them at 1600 BPI is getting to be a chore. More over, we had about
10 more of them shipped to us! There is no way we have enough tapes
or tape storage facilities to back up all those RA81's.
We can't get an additional set of TU78's for the RA81 based system
for awhile yet and we can't put them on our production system where
the TU78's are. The obvious thing to do is to finally use that TM78-C
dual port kit.
DEC, however, is giving us a lot of flack about this. Simply put,
they don't want to install the TM78-C because they say that the
software to support it doesn't work. There was also some mumbling
about hardward incompatibilities and operator scheduling problems.
I don't believe this and our situation on the RA81 systems is
getting worse and worse. It shouldn't crash a system to take a device
offline (it certainly doesn't do this when we switch a disk pack from
system to system using the RP06 dual port kit.)
Is anyone out there running dual-ported TU78 or TU77 tape drives?
Did you have to change your software (such as MOUNTR or the MONITR)?
What did it entail? Does this work? I'd really like to cut through
the smokescreen on this and do something with that 5,000 dollars we
spent instead of having it sit on the floor and gather dust.
-- Tom De Bellis
CUCCA DEC systems group
-------
29-Jan-85 12:54:08-PST,974;000000000001
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 12:53:53-PST
Date: Tue 29 Jan 85 12:55:58-PST
From: Ed Pattermann <
[email protected]>
Subject: Error in REAPER message
To:
[email protected]
My apologies - I meant has anyone modified REAPER to use READ dates instead of
WRITE dates? The problem is that REAPER picks files to be migrated by WRITE
dates, which means files that are read often (like LOGIN.CMD, EMACS.VARS, etc)
are eligible for migration. There are pros and cons for each method, but READ
seems more applicable. Maybe a fix to use both is whats needed.
-- Ed
---------------
From: Ed Pattermann <
[email protected]>
Subject: Reaper
To:
[email protected]
Has anyone modified REAPER to use WRITE dates instead of READ dates? I'd
be interested in those mods, or any others people have made to REAPER.
Thanks, Ed
-------
-------
29-Jan-85 13:26:54-PST,1384;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 13:26:38-PST
Date: 29 Jan 1985 13:23:13 PST
Subject: Re: TM78-C
From: Bob Knight <
[email protected]>
To: Thomas De Bellis <Sy.SLogin%
[email protected]>
cc:
[email protected]
In-Reply-To: (Message from "Thomas De Bellis <Sy.SLogin%
[email protected]>" of Tue 29 Jan 85 13:41:34-EST)
DEC is feeding you a line. First of all, the TM-78C consists of two boards
(the M8956 and M8957), flat cables and two massbus connectors. The cables and
connectors are not required (the cables go from massbus connectors at the
front of the drive to the back). The boards you can get from DECDirect for
about $1400. Install them, and you have dual-ported your TM-78.
At New Mexico Tech, we're running a pair of TU78s dual ported between two
20's under 5.4. We keep the thumbwheels locked on 2 (A/B) on both drives (one
is a slave) and set one unavailable on each system with OPR. Works like a
charm.
When we initially dual-ported our TM78, DFTUI lost with microprocessor
errors. I had a sinking feeling, but we finally traced it to the backplane
which DEC subsequently replaced (at no charge).
Sounds like your DEC people are extremely wedged. If you need further
info, I can be reached at (505) 835-5737.
Bob
-------
29-Jan-85 13:46:27-PST,709;000000000000
Return-Path: <
[email protected]>
Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 13:46:12-PST
Received: ID <
[email protected].#Internet>; Tue 29 Jan 85 16:47:04-EST
Date: Tue, 29 Jan 1985 16:46 EST
Message-ID: <
[email protected]>
From: "Leonard N. Zubkoff" <
[email protected]>
To: Ed Pattermann <
[email protected]>
Cc:
[email protected]
Subject: Error in REAPER message
In-reply-to: Msg of 29 Jan 1985 15:55-EST from Ed Pattermann <PATTERMANN at SUMEX-AIM.ARPA>
Wouldn't using the latest of READ and WRITE dates be most reasonable? If a
file has been either read or written recently, it's probably not a good idea to
migrate it.
29-Jan-85 18:48:02-PST,965;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 18:47:47-PST
Date: 29 Jan 85 21:49:20 EST
From: Charles Hedrick <
[email protected]>
Subject: TU78 dual port
To:
[email protected]
We also use dual-ported TU78's. It is true that your operators
have to know what they are doing. If they get confused, the wrong
system may own the drive. DEC is probably right that ideally there
should be software handshaking between the two machines so that
OPR knows who owns the tape drive, if you switch the drive any
tape mounted on it gets dismounted (or at least the label rechecked),
etc. So it is not total malarky to talk about missing software
and operational problems. However if you explain to your staff
what is going on, they should be able to keep things straight
without great strain. I would certainly rather use dual-porting
than fill my machine room with tape drives.
-------
29-Jan-85 19:54:20-PST,727;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Tue 29 Jan 85 19:54:09-PST
Date: 29 Jan 85 22:54:15 EST
From: Don <
[email protected]>
Subject: Re: Error in REAPER message
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from ""Leonard N. Zubkoff" <
[email protected]>" of 29 Jan 85 16:46:00 EST
REAPER uses CREATE, READ, WRITE, and ARCHIVE dates when determining
the "age" of the file.
For an extensively modified version of REAPER, see the Rutgers file
PS:<WATROUS>REAPER.MAC. Efficiency is improved and several features
are added. The edit history is contained in the beginning of the
source.
Don
-------
30-Jan-85 07:04:48-PST,571;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 07:04:41-PST
Date: 30 Jan 1985 07:04:20 PST
Subject: Re: TU78 dual port
From: Bob Knight <
[email protected]>
To: Charles Hedrick <
[email protected]>
cc:
[email protected]
In-Reply-To: (Message from "Charles Hedrick <
[email protected]>" of 29 Jan 85 21:49:20 EST)
Chuck is right about the missing software aspect. However, as he says,
with an aware operations staff, the problems about drive ownership are
minimal.
Bob
-------
30-Jan-85 10:45:16-PST,1241;000000000000
Return-Path: <SY.KEN%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 10:44:45-PST
Received: from CU20B.ARPA by columbia.arpa; Wed, 30 Jan 85 13:46:56 est
Date: Wed 30 Jan 85 13:44:24-EST
From: Ken Rossman <sy.Ken%
[email protected]>
Subject: Re: TU78 dual port
To:
[email protected]
Cc:
[email protected],
[email protected]
In-Reply-To: Message from "Bob Knight <
[email protected]>" of Wed 30 Jan 85 07:04:20-EST
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Anyone from DEC care to comment as to whether dual ported TU78's will be
supported (i.e. allocation controlled) under CFS in a similar manner that
dual ported massbus disks are supposed to be (allocation negotiations
occurring across the CI)? Looks like we're probably really going to need
to use some dual ported TU78's, and I'm not sure I want to depend on our
operations staff to make sure thumbwheels are set right, and drives are
properly set unavailable.
Which reminds me of something else I wanted to ask: Can the thumbwheels be
left set for either one port or the other, and switched later during
timesharing, with no adverse effects?
/Ken
-------
30-Jan-85 11:25:33-PST,2012;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 11:24:34-PST
Date: Wed, 30 Jan 85 19:24 GMT
From: SAMUELSON%
[email protected]
Subject: sharing tape drives between two systems
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFE>
To: TOPS-20@SU-SCORE.ARPA
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
A few years ago, while working for Ramada Inns in Phoenix, we did something
similar to what folks have been asking for. We had two TOPS-10 systems,
a single KL-10 and a dual KI-10. We had an interesting (neat, simple)
hardware hack that let the KI address some of the KL's memory as though it
were very high addresses on the KI. That allowed us to share some tables
where we kept such things as the time of day, a window for fast file transfers,
and allocation bits for the tape drives. All tapes were online on both systems
all the time. In the code that handled assigning a drive to a user we set
the bit that said "I own this drive", then checked the bit that said the
other system owned it. If he owned it, we turned our bit back off and
said the tape was already assigned (to job 0). That was all that was
required (other than clearing the right bits when a system crashed).
All that was to say that the job is not terribly difficult IF you have
some high-speed path to communicate between systems that can be accessed
inside the monitor. If that link is not there, or is not fast enough,
or cant be accessed at a low enough level, you will have to send messages
back and forth on a regular basis (at least each time a tape assignment
is made). Of course it would be nice if, when mounting a labeled tape,
one system at a time would allocate the drive, check the label, and if
nobody is waiting for it, deallocate the drive assuming the other system
might want it.
- Sam -
-------
30-Jan-85 12:34:07-PST,734;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 12:33:35-PST
Date: 30 Jan 1985 12:30:40 PST
Subject: Re: TU78 dual port
From: Bob Knight <
[email protected]>
To: Ken Rossman <sy.Ken%
[email protected]>
cc:
[email protected],
[email protected],
[email protected]
In-Reply-To: (Message from "Ken Rossman <sy.Ken%
[email protected]>" of Wed 30 Jan 85 13:44:24-EST)
I would guess that the monitor would not have seen a drive not locked on
its RH port at startup, and would not have allocated a UDB for it. So,
even if you switch the drive back, it wouldn't be useable...
However, I may be wrong. Any comments from DEC?
Bob
-------
30-Jan-85 13:00:46-PST,1725;000000000001
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Jan 85 12:59:16-PST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 30 Jan 1985 15:48:57 est
Date: 30 Jan 85 16:01 +0100
From: Kimmo_Laaksonen_HUTCC%
[email protected]
Reply-to: Kimmo_Laaksonen_HUTCC%
[email protected],
TOPS-10/20_SIG%
[email protected]
To: TOPS-10/20_SIG%
[email protected],
[email protected], "Ed Pattermann"
<
[email protected]>
Subject: Lines: 16 Reaper
Message-ID: <88415@QZCOM>
In-Reply-To: <88302@QZCOM>
We are just working on a set of changes to speed up migration/archival.
There are some changes to REAPER included, but I'll have to check with
the person working on it, if the changes affect READ DATE vs. WRITE
DATE (or SYSTEM WRITE DATE). The speeding up of the process should
come from changes to CHKPNT to write separate files containing
pending migration and archival requests. A stripped down version
of DUMPER to use the files for writing the tapes already exists
(all non-migrate/archival stuff is removed). The aim is not to
have DUMPER scan whole disk structures - just scan the directories
containing requests (that's what the files produced by CHKPNT
contain). Since most sites run CHKPNT regularly each night, we
don't feel there's too much delay between the rollout request
and the execution. One has only to schedule the migration/archival
DUMPER run after CHKPNT, first thing in the morning, or use
/START or /DEPENDENCY in batch.
30-Jan-85 15:51:28-PST,800;000000000000
Mail-From: MRC created at 30-Jan-85 15:51:17
Date: Wed 30 Jan 85 15:51:17-PST
From: Mark Crispin <
[email protected]>
Subject: Re: TU78 dual port
To:
[email protected]
cc: sy.Ken%
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "Bob Knight <
[email protected]>" of Wed 30 Jan 85 12:30:40-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
When a device comes online there is an attention interrupt (or
rather, what DEC calls "attention interrupts" -- anything that
isn't a data done interrupt!!). This causes a UDB to be created.
You don't need to have the device there at startup.
As far as I know a UDB, once created, is never destroyed.
-------
31-Jan-85 15:54:13-PST,1640;000000000000
Return-Path: <SY.SLOGIN%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Thu 31 Jan 85 15:53:55-PST
Received: from CU20B.ARPA by columbia.arpa; Thu, 31 Jan 85 18:56:05 est
Date: Thu 31 Jan 85 18:53:06-EST
From: Thomas De Bellis <Sy.SLogin%
[email protected]>
Subject: Re: TM78-C
To:
[email protected]
In-Reply-To: Message from "Kevin Paetzold <
[email protected]>" of Thu 31 Jan 85 14:02:55-EST
Hi All,
It seems that there may be an ambiguity in my previous message about
the TM78-C dual port kit. When I said that, "It shouldn't crash a
system to take a device offline", I was refering to that process of
switching the TU78 tape drives from system to system and noting that
properly switching dual ported RP06's has never caused us any problem.
The "situation on the RA81 systems" that "is getting worse and worse"
is obviously that of having to back these things up at 1600 BPI.
I was not refering to switching RA81's.
In fact, the RA81's, by themselves, are *real* winners. We have
been field testing them for awhile now and they are one of the best,
most well thought out pieces of equipment that I have ever seen.
Since we are still under field test, I really can't say anything
more about them or the software that we're testing so please don't
pester me for gossip. I will say, however, that I don't think I have
ever worked with the kind of resources that they supply. It really is
a whole new aspect of computing for me. They'll be worth the wait
whenever they and the software we are testing is released for general
use.
-- Tom
-------
1-Feb-85 23:30:32-PST,4318;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 1 Feb 85 23:30:18-PST
Date: Fri 1 Feb 85 23:32:18-PST
From: David Roode <
[email protected]>
Subject: [
[email protected]: RA81 unreliability]
To:
[email protected]
Location: EJ286 Phone: (415) 859-2774
A potentially important point on RA81's follows.
---------------
1) 31-Jan
[email protected] RA81 unreliability
2) 1-Feb To:
[email protected] RA81 reliability
Message 1 -- ************************
Return-Path: <
[email protected]>
Received: from BRL-TGR by SRI-NIC.ARPA with TCP; Thu 31 Jan 85 04:59:36-PST
Received: from usenet by BRL-TGR.ARPA id a003933; 30 Jan 85 12:08 EST
From:
[email protected]
Newsgroups: net.unix-wizards
Subject: RA81 unreliability
Message-ID: <
[email protected]>
Date: 29 Jan 85 21:49:00 GMT
Nf-ID: #N:down:2200005:000:2225
Nf-From: down!pep Jan 29 16:49:00 1985
Xref: seismo net.unix-wizards:11731
To:
[email protected]
I've had a LOT of trouble with RA81 discs. I run a facility with eight RA81s
(along with RM80, RA80, RA60, & RL02 discs) distributed among six VAX 11/750s.
Of the eight 81s, I have had to replace four HDAs in the past year, and I may
have another dead one on my hands.
The Symptoms: usually start out with soft errors, status/event codes of
053, 0353, and sometimes 0213 and 0350. Most of the time, these are
followed by hard errors. The errors usually become more severe (more
frequent; proportion of hard errors increases) if the disc is left
in service. The problem has occurred under three versions of UNIX.
The Cause: unknown. I observe that the errors appear on a disc that has
suddenly seen a lot of write activity, after performing reliably for
months (e.g., convert to a new version of UNIX and restore data).
The Diagnosis: DEC diagnostics (EVRLA) sometimes detect a problem (hard
error), sometimes not.
The Remedy: attempt to reformat the disc. This has succeeded (and cured
the problem) four times. To date, reformatting has failed four
times; these HDAs have been replaced. Reformatting has failed in
various ways: usual complaints are failure to format LBN area,
failure to format DBN or XBN area. I have also seen a complaint
that more than 12.5% of a track is bad.
One Field Service Hypothesis: is that UNIX trashes DEC's area of the disc
when it encounters a bad block, clobbering tables needed to reformat.
Only twelve (hard) errors were reported on the latest RA81 before we
attempted to reformat - reformatting still failed.
What I Believe: I've heard that RA81s have been developing bad spots in the
field. (This is consistent with the war stories I've been trading
with friends.) UNIX doesn't forward the bad blocks, so the most
attractive cure (?) is to reformat the disc. Apparently the formatter
used at the factory is more powerful than the one available in the
field; if DEC's area of the disc is bad, the field formatter can't
recover. The HDA must be replaced; the old HDA is returned to the
factory for reformatting, or marked usable for a VMS site (VMS does
dynamic bad block forwarding).
Pat Parseghian
Princeton Univ. EECS Dept.
Message 2 -- ************************
Mail-From: ROODE created at 1-Feb-85 23:22:48
Date: Fri 1 Feb 85 23:22:48-PST
From: David Roode <
[email protected]>
Subject: RA81 reliability
To:
[email protected],
[email protected],
[email protected]
Location: EJ286 Phone: (415) 859-2774
I brought up the issue of RA81 reliability with the DEC disk
specialist installing our new RA81 drives today. This disk
specialist is known to me to be an above average DEC field
service engineer. He stated that there is a known problem
that results from poor attention to Preventive Maintenance.
The RA81 includes a spindle ground device which tends to
flake off with age and to contaminate the HDA. If the ground
device is attended to regularly, much better results can be
attained. I pass this along in the even it explains
some sites' poor experience. He stated that the problem
has been described in recent "Tech Tips" and all field engineers
should be aware of it.
-------
-------
3-Feb-85 12:43:53-PST,1287;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sun 3 Feb 85 12:43:41-PST
Date: Sun 3 Feb 85 15:44:13-EST
From: Kevin Paetzold <
[email protected]>
Subject: 4.0 Meg of memory
To:
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
Allthough 4.0 meg is not supported by any monitor other than 6.1 (which
is in field test) the following patch is needed by anyone attempting to
run with 4.0 meg in their monitor (which i imagine some of you might
be).
Date: Sun 3 Feb 85 15:41:25-EST
From: Kevin Paetzold <
[email protected]>
Subject: ILLGOs from 4.0 meg of memory
To:
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
The following patch is required by any site running with 4.0 meg of
memory. Disk IO to the last possible physical page of memory will cause
an ILLGO. Guess what hardware the monitor group just got?
@GET M61:AN-MONDCN.EXE.10
@DDT
DDT
CKERR2+11/ SUBI T3,T1
CKERR2+12/ CAME T3,T4 FFF$<
FFF/ 0 ANDI 3,17777
FFF+1/ 0 $>
FFF+1/ 0 CAME T3,T4
FFF+2/ 0 JUMPA T1,CKERR2+13
FFF+3/ 0 JUMPA T2,CKERR2+14
CKERR2+12/ CAME T3,T4 JUMPA FFF1
^Z
-------
-------
3-Feb-85 18:57:02-PST,837;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sun 3 Feb 85 18:56:51-PST
Date: Sun 3 Feb 85 19:47:33-MST
From: Randy Frank <
[email protected]>
Subject: Re: TM78-C
To: Sy.SLogin%
[email protected],
[email protected]
In-Reply-To: Message from "Thomas De Bellis <Sy.SLogin%
[email protected]>" of Tue 29 Jan 85 12:52:35-MST
we are running a dual ported set of TU78s (two TU78s on one TM78) with one
end on a DEC-20 and the other end on a VAX 780 running 4.2BSD Unix.
We have had no problems, with the obvious caveat that it is up to users and
operators to manually avoid confusion. We have made no changes to software.
We run the drives in the mode where they are (at any instant in time)
switched to one system or the other, never in the dynamic dual port mode.
-------
3-Feb-85 19:13:05-PST,656;000000000000
Return-Path: <dswindel@bbn-labs-b>
Received: from bbn-labs-b by SU-SCORE.ARPA with TCP; Sun 3 Feb 85 19:12:50-PST
Date: Sun, 3 Feb 85 22:11:30 EST
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: XMODEM for Tops-10
To:
[email protected]
Cc:
[email protected],
[email protected]
I am interested in locating a version of XMODEM for a DEC 10 running
TOPS 10 version 7.01. Any suggestions as to commercial or public
domain packages would be appreciated.
As I am not on your mailing lists, please respond directly to my computer
mail address.
Thanks!
Dave Swindell
BBN Laboratories
Mailbox: dswindell@bbn-unix
6-Feb-85 03:10:14-PST,745;000000000000
Return-Path: <steinar@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 03:09:59-PST
Received: by oslo-vax.ARPA (4.12/4.7)
id AA26301; Wed, 6 Feb 85 12:10:12 -0100
Date: Wed, 6 Feb 85 12:10:12 -0100
From: steinar@oslo-vax (Steinar Kj{rnsr|d)
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Source file libraries under TOPS20
The only source-file-library utility avaiable
at our site is the TOPS10 LIBMAN program which
have to be run by the compatability package
PA1050.
We would very much like to have a TOPS20 native
program for creating and maintaining source
libraries. Does anyone know about such a program,
hopefully avaiable from DEC ?
-- Steinar.
6-Feb-85 05:29:52-PST,1431;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 05:29:43-PST
Date: Wed 6 Feb 85 08:29:57-EST
From:
[email protected]
Subject: Re: Source file libraries under TOPS20
To:
[email protected]
In-Reply-To: Message from "steinar@oslo-vax (Steinar Kj{rnsr|d)" of Wed 6 Feb 85 06:13:02-EST
It sounds like you should look into the following two programs distributed
on the TOPS-20 TOOLS tape. This is what's used in DEC by the TOPS-20
monitor group.
ALU -- Automated Library Utility
ALU is a program which helps keep track of modifications to a
set of program sources in one or more libraries. It is
intended to handle multiple developers working on the same
sources, keeping track of which developer is editing which
source, and preventing inadvertant confusion from simultaneous
edits.
REDIT -- Source update utility
REDIT is used to duplicate changes which have been made in
source files. It is typically used to maintain multiple sets
of sources for different versions of the same program, and can
conveniently allow changes made in one set to be distributed
and selectively incorporated into other sets without the use of
common "grandfather" files.
-------
6-Feb-85 09:51:53-PST,1092;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 09:51:11-PST
Date: Wed 6 Feb 85 12:03:02-EST
From: Rob Austein <
[email protected]>
Subject: Re: Source file libraries under TOPS20
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "steinar@oslo-vax (Steinar Kj{rnsr|d)" of Wed 6 Feb 85 06:15:29-EST
Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341
The ALU and REDIT programs are fairly useful. You might also look
into is the SOUPR package from the autopatch tape. It consists of
three programs, COMPAR, MERGE, and UPDATE, and performs aproximately
the same functions as REDIT. I prefer SOUPR, because the format is
easier for merging multiple edits.
Also, if you have large groups of files that are logically related,
there are some programs that will let you cluster them together into a
single disk file to make it easier to move them around as a unit.
These aren't DEC products (they're mine), but you are welcome to them
if you want them.
--Rob
-------
6-Feb-85 12:17:30-PST,2607;000000000000
Return-Path: <@USC-ISIB.ARPA:Chase@ISIB>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Feb 85 12:17:00-PST
Received: FROM ISI-ALFALFA.ARPA BY USC-ISIB.ARPA WITH TCP ; 6 Feb 85 12:11:52 PST
Date: 6 Feb 85 12:13:54
Sender: Chase@ISIB
From: Dale Chase <Chase@ISIB>
To: Tops-20@SU-SCORE
Cc: Chase@ISIB
Subject: TCP Packetizer bug
Problem: Large data transfers to some hosts don't work. For example,
MMAILR can't deliver a large message.
Symptom: The transfer starts out ok, then stops dead somewhere in the
middle. The user process has filled its buffer(s) and is waiting for
them to empty. All previously sent data has been acked and there is
plenty of window space. But nothing is being sent.
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. So, first the indicated instructions should be removed before
PKTIZ5.
LOAD T1,TSLFT,(TCB) ; Send Left
LOAD T2,TSSEQ,(TCB) ; Send Sequence
LOAD T3,TSWND,(TCB) ; Send window offered
;;; SKIPE PKT ; REMOVE THIS
;;; LOAD T2,PESEQ,(PKT) ; REMOVE THIS
ADD T1,T3 ; Compute Send Right
SUB T1,T2 ; Minus Sequence
...
Then, after PKTIZ7, something along these lines is needed.
SKIPN PKT ; Have partially filled pkt?
IFSKP. ; Yes
LOAD T2,PESEQ,(PKT) ; Get end seq
LOAD T1,TSSEQ,(TCB) ; and send seq
SUB T2,T1 ; Difference is number bytes in pkt
MODSEQ T2 ; Possible wrap
SUB WNDSPC,T2 ; WNDSPC = #bytes can still put in pkt
ENDIF. ;
CAML BUFCNT,WNDSPC ; Take min of what is available to be
SKIPA XFRCNT,WNDSPC ; sent and space allowed to send in
...
This value for WNDSPC is the correct value for subsequent uses of
that AC by the PZ.
6-Feb-85 16:52:14-PST,3510;000000000000
Mail-From: BILLW created at 6-Feb-85 16:52:04
Date: Wed 6 Feb 85 16:52:04-PST
From: William "Chops" Westfield <
[email protected]>
Subject: 6.1 field test school...
To:
[email protected]
Sean Welsh and I attended a class/seminar for TOPS20 v6.1 field test
sites last week. Here are some of the things I learned.
Overview: The whole session was rather interesting. The people from
DEC (mostly members of the monitor development team) seemed a lot more
candid and informal than they tend to be at occasions like DECUS.
6.1 is the next mainline release of tops20. It supports a common
file system, CI and HSC disks, NI ethernet and phase 4 decnet as major
new features. In addition, many of the modifications/options that
Stanford has been using for a long time are now supported by DEC (for
example: encrypted passwords and the PCL multi-forking EXEC).
Attendees included Utah, Columbia, Chicago, Case Western, 3M, Mobil,
and perhaps others that I dont remember.
Good News.
Although official claim is that 6.1 supports only a 2 cpu cluster of
dec20's, it will in fact support more than that. The monitor development
cluster at DEC runs continuously with 3 cpus, and they occacionally add
a forth (normally standalone) cpu. They haven't noticed any problems
or even performance degradations with up to 4 cpus.
They plan to throw a couple vaxes on a CI cluster to see if they
can share an HSC, as long as individual disks are used by only one
cpu type. They don't expect any serious problems with this (!!!!).
Apparently the HSC command to set sector size actually effects only
the MAXIMUM sector size, its a buffer size paramter. If this works,
it will make a lot of customers happy. They did say that such a
configuration may never be officially supported though.
Some things in 6.1 are actually faster than earlier versions. For
example when the directory locking mechanism was re-vamped to handle
multiple cpus, the single cpu case turned out to be faster than the
old method.
DEC sounded pretty confident that there will be a release 7 of TOPS20.
Features will probably include things like non-PS login, and better
operations level support of clusters (cluster wide MOUNTR, GALAXY, etc).
Code is being moved into other sections, greatly relaxing the address
space restrictions that have plagued monitor developers. On the other
hand, multiple section code will help the pager to thrash unless the
new MCA25 pager/cache upgrade is installed.
Bad News.
Despite pressure from almost everyone there, DEC was doubtful that the
LAT protocol (for terminal servers) will be made public anytime soon.
One presenter commented that after the Jupiter cancelation, DEC put a
lot of money into software development, and that this money was now
starting to run out.
Because of the above, the much need re-write of the TCP/IP code will
not be done (at least not by DEC). Kevin said he was looking into
performance, and might be able to get another 25% or so, which is a
far cry from the order of magnitude improvement it needs. Randy Frank
suggested that interested sites contribute a couple $K each, and hire
someone to rewrite the code...
Well, thats a summary. If anyone really want's to know, I can explain
how shared pmaped files under CFS work, or how LAT work, or whatever.
I also have a large box of documents that is on its way, and LOTS should
be receivng the tapes (9) about the same time.
-------
7-Feb-85 00:01:54-PST,799;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Feb 85 00:01:38-PST
Date: Thu 7 Feb 85 01:00:42-MST
From: Jay Lepreau <
[email protected]>
Subject: Re: Source file libraries under TOPS20
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "steinar@oslo-vax (Steinar Kj{rnsr|d)" of Wed 6 Feb 85 04:54:23-MST
Source control: I have (most of) Walter Tichy's RCS (Revision Control System)
running under Tops-20. This is a system which is widely used on Unix systems,
and was distributed as "user-contributed software" in 4.2 BSD.
Source library: have Unix's "ar" utility, which is a rudimentary library
handler.
Need to talk to Walter about giving this out, but if anyone's interested,
could try.
-------
8-Feb-85 13:14:19-PST,2154;000000000000
Mail-From: MRC created at 8-Feb-85 13:14:05
Return-Path: <steinar@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Jan 85 02:36:41-PST
Received: by oslo-vax.ARPA (4.12/4.7)
id AA13534; Thu, 10 Jan 85 11:39:21 -0100
Date: Thu, 10 Jan 85 11:39:21 -0100
From: steinar@oslo-vax (Steinar Kj{rnsr|d)
Message-Id: <
[email protected]>
To: %
[email protected],
[email protected], POWELL@DEC-MARLBORO,
[email protected]
Subject: Re: PCL not working with version 6 TOPS-20 ?
ReSent-Date: Fri 8 Feb 85 13:14:05-PST
ReSent-From: Mark Crispin <
[email protected]>
ReSent-To:
[email protected]
Thanks for quick answer.
1: Our "old" PCL was version 4.1(55) running with
V5 monitor. This version wouldn't even start
with V6 - issuing the message ..
Illegal memory reference, section greater than 37
?TOPS-20 command processor not properly initialised
2: However, after digging some more among the distribution
tapes, we found a program named PCL-MIC-EXEC.EXE, but no
documentation. The old PCL-environment file, had to be
recompiled, but after that our procedures seemed to work
properly. There are several differences among the two
versions - the V4.1 behaving like a program in the way
that @INF VERSION gave the response ..
...
Program is PCL-EXEC, version 4.1(55)
but the new version seems to behave much like a "fresh"
EXEC after issuing @PUSH, i.e. the @INF VERSION
just responds with the version number of the
monitor and command processor.~?
The new version apparently seems to contain much less
features than the V4. However, the most interesting
point is the new version's MIC feature. We would
very much like to know about this - is it TOPS-10
MIC lookalike etc. ? As I mentioned, we have got
no documentation. The most used programming
language in our society is SIMULA, and SIMULA have
interface to MIC - at least TOPS10 MIC.
3: Am I right in thinking PCL is an unsupported
CMU-product ?
I won't bother you more with this stuff,
regards,
-- Steinar.
8-Feb-85 15:23:36-PST,424;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 8 Feb 85 15:23:25-PST
Date: Fri 8 Feb 85 14:19:03-PST
From: Frank <
[email protected]>
Subject: ARCF bug
To:
[email protected]
There's a small bug in the .ARSST (set tape info) function of the ARCF
jsys re setting the 1st tape id. In JSYSF, the CAMN T2,T3 at SET1ST+2
should be a CAMN T2,T1.
-------
9-Feb-85 18:15:57-PST,491;000000000000
Mail-From: BILLW created at 9-Feb-85 18:15:55
Date: Sat 9 Feb 85 18:15:55-PST
From: William "Chops" Westfield <
[email protected]>
Subject: new exec PCL bug?
To:
[email protected]
The new exec seems to have broken the INVOKE command in PCL procedures.
When a PCL procedure does an invoke/typein sequence, the command seems
to hang. An obvious example is PCC, which is broken on both SCORE and
SIERRA. Any body have any ideas? Im pretty new to PCL...
BillW
-------
9-Feb-85 20:08:51-PST,730;000000000000
Mail-From: MRC created at 9-Feb-85 20:08:46
Date: Sat 9 Feb 85 20:08:46-PST
From: Mark Crispin <
[email protected]>
Subject: Re: new exec PCL bug?
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Sat 9 Feb 85 18:15:58-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Drat! That bug (or at least a bug with the same symptoms) was in the
version 5 EXEC, and I fixed it 4 years ago. Did some change not get
merged from Score's EXEC sources into this new EXEC? I forget the
exact details; the change looked strange (even wrong), but it wasn't.
-------
11-Feb-85 16:02:30-PST,777;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Feb 85 16:02:11-PST
Date: Mon 11 Feb 85 15:54:11-PST
From:
[email protected]
Subject: ethernet interfaces
To:
[email protected]
Is there anyone who is running an Ethernet through a front end, or some
method not involving a Stanford MEIS or DEC NI20 interface? We have the
NI20 coming, but I wondered if there was some way I could use the DN20
that came with the machine in the meantime. (I have an Interlan board
that I can put in the DN20 to hook it to the Ethernet.)
I would like something easy to set up if possible, and would even be
happy with a set of patches that made the net run through one of the
terminal lines.
Thanks
Alan Larson
-------
11-Feb-85 17:38:01-PST,819;000000000000
Return-Path: <
[email protected]>
Received: from TL-20B.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Feb 85 17:37:43-PST
Received: ID <
[email protected].#Internet>; Mon 11 Feb 85 20:34:39-EST
Date: Mon, 11 Feb 1985 20:34 EST
Message-ID: <
[email protected]>
From: "Leonard N. Zubkoff" <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Subject: ethernet interfaces
In-reply-to: Msg of 11 Feb 1985 18:54-EST from LARSON at SRI-KL.ARPA
CMU and Tartan Laboratories both use DN-20's running CMU's IP Router code to
interface DEC-20's to the InterNet/EtherNet. I don't know if the IP Router
code supports Interlan boards; we're using 3COM at Tartan. Contact Vince
Fuller (VAF@CMU-CS-C) or Mike Accetta (Mike.Accetta@CMU-CS-IUS) for more
information.
Leonard
11-Feb-85 21:39:32-PST,787;000000000000
Return-Path: <@SRI-CSL:
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Mon 11 Feb 85 21:39:19-PST
Date: 11 Feb 1985 21:38-PST
Sender: GEOFF@SRI-CSL
Subject: TCP/IP Printer Interface/Spooler?
From: the tty of Geoffrey S. Goodfellow <
[email protected]>
To: Tops-20@SCORE
Message-ID: <[SRI-CSL]11-Feb-85 21:38:30.GEOFF>
Does anyone have printer spoolers for TOPS-20 which:
-allow cross spooling of files with TCP/IP between TOPS-20 and/or
other types of dissimilar Systems? (i.e., queue a file for
printing on System A, which is then transferred to System B where
it is queued and printed).
-drives a TCP/IP based Imagen over an Ethernet? (i.e., queue a
file on a TOPS-20 System which then is TCP/IP'd to the Imagen for
printing).
g
12-Feb-85 11:14:17-PST,598;000000000000
Mail-From: MRC created at 12-Feb-85 11:13:39
Date: Tue 12 Feb 85 11:13:39-PST
From: Mark Crispin <
[email protected]>
Subject: Foonly F3 computer
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
What can people tell me about the Foonly F3 computer? What
is its footprint? Power requirements? Cooling requirements?
What is its computational power? Can/Has it been microcoded so
it can run TOPS-20?
I would especially like to hear how it compares to the 2020.
-------
12-Feb-85 12:12:01-PST,1011;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Feb 85 12:11:24-PST
Date: Tue 12 Feb 85 12:20:47-EST
From: Rob Austein <
[email protected]>
Subject: Re: TCP/IP Printer Interface/Spooler?
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "the tty of Geoffrey S. Goodfellow <
[email protected]>" of Tue 12 Feb 85 00:38:00-EST
Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341
I've got a crock that spools files to a Berkelely 4.2 lpd for eventual
shipment to an Imagen (lpd knows how to do this). My program isn't
integrated into GALAXY (yet) or have the ability to queue directly to
the Imagen if the lpd is idle (ditto, although this may never get
added). You're welcome to it if you like, with the above caveats.
You might also check with John Romkey <ROMKEY@MIT-BORAX>, who has
written a program for directly spooling to the Imagen (in C, I
believe) for use on a PC with TCP support.
-------
12-Feb-85 12:32:47-PST,668;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Feb 85 12:32:34-PST
Date: Tue 12 Feb 85 13:31:26-MST
From: The alleged mind of Walt <
[email protected]>
Subject: Re: TCP/IP Printer Interface/Spooler?
To:
[email protected]
cc:
[email protected]
I have a Un*x-style line printer daemon which runs on the 20 and
allows the Un*x systems on our Ethernet to spool files to be
printed on the 20's printers. I also have a program that runs on
the 20 and allows files to be submitted for printing on one Un*x
system. Either are yours for the asking, but I can't offer support.
Cheers -- Walt Haas
-------
12-Feb-85 15:42:04-PST,1164;000000000000
Return-Path: <EC0N@CMU-CC-TE>
Received: from CMU-CC-TE by SU-SCORE.ARPA with TCP; Tue 12 Feb 85 15:41:12-PST
Date: Tue 12 Feb 85 18:38:44-EST
From: Eric Crane <EC0N%CMU-CC-TE@CMU-CC-TE>
Subject: Re: Dn20's and IP support
To:
[email protected]
Office: Ucc 130 x3568
Secretary: x2638
To add a little to Leonard Zubkoff's info, the CMU-Router supports the
following:
Interland 10Mb ethernet
3Com 10Mb ethernet
Proteon 10Mb proNET
Xerox 3Mb experimental ethernet
Dte-20 interface (how we talk to 20's)
DA28-F interface
DZ11
DUP-11 (better than DZs)
Unibus IMP interface (whatever it is called)
DMR-11 (not done yet)
The code is fairly general, we have it running as Network Front Ends on
6 20's (soon to be 9) 2 at Tartan, 4 here. 1 gateway (CMU-GATEWAY) and
between different network cables in a few other places.
We seem to have a maximum throughput of about 60-70Kbytes for a single
FTP connection to another 20. With multiple connections at once we seem
to drop down to about 59Kbytes/connection. These were done on standalone
20's under Tops-20 V5.3.
- Eric Crane
Carnegie-Mellon Univ
-------
12-Feb-85 17:16:08-PST,677;000000000000
Mail-From: MRC created at 12-Feb-85 17:16:02
Date: Tue 12 Feb 85 17:16:02-PST
From: Mark Crispin <
[email protected]>
Subject: V6 EXEC
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
The new wonderful V6 EXEC still has the bug that breaks the MM
build procedures in it. I've patched Score's copy to have the
published workaround, which is to patch CMIND+16 from JRST CMPER to
NOP.
I would appreciate it if this patch (or the right fix) would
propogate to the other instances of this EXEC around Stanford.
Your friendly MM developer
-------
13-Feb-85 15:38:56-PST,1303;000000000000
Mail-From: MRC created at 13-Feb-85 15:38:48
Date: Wed 13 Feb 85 15:38:48-PST
From: Mark Crispin <
[email protected]>
Subject: FREE SHOWING: 36-bit historical videotapes
To:
[email protected], BBoard@LOTS-A
cc:
[email protected],
[email protected],
[email protected],
G.Gorin@LOTS-A
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I have received from DEC a set of videotapes from the December '84
DECUS (DEC User's Society) symposium recording some of the sessions
pertaining to the history of DEC's 36-bit computers, the DECsystem-10
and the DECSYSTEM-20. I have received permission to hold a public
showing of these tapes at Stanford.
Programming on these tapes include the 36-BIT TRIVIA BOWL, the
36-BIT PIONEER'S ROUNDTABLE (find out about the DEC-10 that took a
steambath!), and a special bonus, some comic commercials for things
such as DIGIBITS, DEC-WASH,...
In order to determine what would be the most suitable facility, I
need to know how many people are interested in being there. If you're
thinking of coming, please send mail to
[email protected]. Once we
have some idea of the attendance, we'll reserve some place to hold the
showing.
-------
13-Feb-85 17:34:59-PST,816;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Feb 85 17:34:45-PST
Date: 13 Feb 1985 17:32-PST
Sender:
[email protected]
Subject: Re: TCP/IP Printer Interface/Spooler?
From: Joel Goldberger <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Message-ID: <[USC-ISIB.ARPA]13-Feb-85 17:32:12.JGOLDBERGER>
In-Reply-To: <[SRI-CSL]11-Feb-85 21:38:30.GEOFF>
ISI has been running with network spooling for quite a while, first NCP
and then TCP. Dennis Smith is the author of this code and it is fully
integrated into GALAXY. We have added facilities to accept files from
both VMS (using TWG's TCP) and UNIX (via TFTP). With Dennis's
permission I could make the TOPS-20 components available.
- Joel Goldberger -
13-Feb-85 18:22:08-PST,1948;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Feb 85 18:21:53-PST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 13 Feb 1985 18:45:43 est
Date: 06 Feb 85 02:42 +0100
From: Michel_E_Debar_DECUS%
[email protected]
Reply-to: Michel_E_Debar_DECUS%
[email protected],
TOPS-10/20_SIG%
[email protected],
IPL_Software_Enquiries%
[email protected],
Sven_Olofsson_QZ%
[email protected],
Jurek_Wolodarski_QZ%
[email protected]
To: TOPS-10/20_SIG%
[email protected],
[email protected], "Charles Hedrick"
<
[email protected]>
Cc: IPL_Software_Enquiries%
[email protected],
Sven_Olofsson_QZ%
[email protected],
Jurek_Wolodarski_QZ%
[email protected]
Subject: Lines: 14 is anyone using Macsyma on the 20?
Message-ID: <89472@QZCOM>
In-Reply-To: <71559@QZCOM>
I installed Macsyma on our 20 about a year ago. I do remember having hit the sam
e
problems on installation, or similar. Basically Macsyma is working but:
- line editing is cumbersome, or I lose the automatic evaluation on
expression termination,
- I wanted to use the disk copy of graphics. Unfortunately the format
is totally undocumented (apart from a reference to an info: file which is
not distributed). A call to Symbolics elicited the "unsupported" answer.
I think that we had a couple of other minor problems. Basically the thing is
working, some bells and whistles that I thought easy to port to the 20 are not
working, and the support is non positive. Only answer from Symbolics is
buy maintenance, or get a new tape ($ 1000).
Michel
13-Feb-85 18:39:29-PST,1114;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Feb 85 18:39:16-PST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 13 Feb 1985 19:18:46 est
Date: 30 Jan 85 02:36 +0100
From: Peter_Lothberg_STUPI%
[email protected]
Reply-to: Peter_Lothberg_STUPI%
[email protected],
TOPS-10/20_SIG%
[email protected],
TOPS-10/20_SIG%
[email protected]
To: TOPS-10/20_SIG%
[email protected]
Cc: TOPS-10/20_SIG%
[email protected]
Resent-Cc:
[email protected]
Subject: Lines: 22 Looking for harware..
Message-ID: <88329@QZCOM>
I'm out to find the following flip-chips
2 pcs M171
4 pcs M126
1 pcs M241
1 pcs M321
2 pcs M177
5 pcs M143
1 pcs M172
4 pcs M629
3 pcs M511
1 pcs M243
1 pcs M175
1 pcs M246
1 pcs M170
1 pcs M921
1 pcs W970
1 pcs W990
anybody out there having some ?
14-Feb-85 01:55:06-PST,3000;000000000000
Mail-From: BILLW created at 14-Feb-85 01:55:03
Date: 14 Feb 1985 01:55-PST
Sender:
[email protected]
Subject: new EMACS for testing.
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Message-ID: <[SU-SCORE.ARPA]14-Feb-85 01:55:03.BILLW>
In-Reply-To: The message of Thu 14 Feb 85 01:20:38-PST from David Roode <
[email protected]>
huh? You passing around rumors? there qwasnt much to that message
you forwarded to me.
Anyway, I am working on EMACS right this minute. here is whats in
store:
The TEXTI mods.
Rewrite ALL of the terminal drivers to buffer their output
until the final return, at which point do the -N form of
SOUT (instead of psout), which I have already optimized in
th monitor.
Thats been done. This is whats still in progress:
use CRLF, CR, LF for cursor positoining where possible.
use INSERT MODE terminal MUCH better. Only go in and out of
insert mode when absolutely necessary.
And I'm sort of considering (in order of practicallity):
define an IDEAL terminal type. This would be able to do all
of the emacs functions in a maximum of two bytes. (on a 25x
80 display. Bigger terminals are not "ideal").
make the IDEAL terminal type do the equivilent of TEXTI
locally. This would enable EMACS to use SINs for TTY
input most of the time. (even better than TEXTI)
The above are applicable because many of the "terminals" being
connected to things these days are actually microcomputers, running
terminal emulators. Many of the terminal emulators can be modified.
Perhaps the ethertip can emulate the IDEAL terminal and translate
as appropriate for individual terminals. SUNs can clearly do this.
Do TEXTI locally in ethertip/sun via an extension to TELNET
protocol (is there already a set break mask option? I wish
all of the TELNET options would be collected into one RFC!)
6.1 (decnet phase 4) has a facility for doing TEXTI remotely,
but I suspect that getting it to work over TCP/PUP.etc would
be pretty hairy.
Most of these changes are at the system level - ie they will not
result in a highly visible improvement (like much faster screen
updating) to users, but should lessen the impact of emacs on the
system. (they also assume the TTY IO is one of the most expensive
thing that emacs does, which isn't always or necessarilly true.
For exmaple, Kirk has suggested that one of the UNIX emacs's like
ELLE be brought up under the assumption that it is more efficient
by not having (interpreted) TECO as an intermediate level).
If anyone has any other suggestions, id be happy to take them
into consideration.
The current version of EMACS is in SCORE:<EMACS165>XEMACS.EXE
I don't think its quite up to date in terms of terminal types,
but im working on it... Run it by using:
DEFINE EMACS: PS:<EMACS165>
DEFINE EDITOR: EMACS:XEMACS.EXE
Let me know of any problems
Enjoy
BillW
14-Feb-85 11:57:20-PST,842;000000000000
Return-Path: <
[email protected]>
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 14 Feb 85 11:56:50-PST
Received: from Riesling.ms by ArpaGateway.ms ; 14 FEB 85 11:51:35 PST
Sender: "Randy Gobbel.osbunorth"@XEROX.ARPA
Date: 14 Feb 85 11:47:15 PST (Thursday)
Subject: Re: FREE SHOWING: 36-bit historical videotapes
From:
[email protected]
To:
[email protected]
cc:
[email protected], BBoard%
[email protected],
[email protected],
[email protected],
[email protected],
G.Gorin%
[email protected]
In-Reply-to: -SCORE:ARPA's message of 13 Feb 85 22:14:10 PST
(Wednesday)
Reply-to:
[email protected]
Please add me to the list of possible attendees. I know one or two
people who probably didn't get your message who'd also likely be
interested.
-Randy
15-Feb-85 11:26:23-PST,4492;000000000001
Mail-From: MRC created at 15-Feb-85 11:26:14
Date: Fri 15 Feb 85 11:26:13-PST
From: Mark Crispin <
[email protected]>
Subject: MM support status
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I would like to clarify some questions which have been raised with
regard to MM support since I left Stanford. There have been a number
of rumors floating around. Many of them seem to be coming from DEC,
which apparently is trying to get people to migrate to MS again.
FACT: I am still developing and maintaining MM. This can be easily
ascertained just by following the edits which have been made to the
master MM directory on Score.
FACT: MM is still a free software product.
MYTH: I am charging for all work done on MM.
FACT: I AM accepting voluntary donations. I am also accepting
funding for development of major new functionalities in MM. I will
always listen to requests for new features. If it's something that
can be put in simply I probably will. If it's something that will
take several days of my time I will listen a LOT harder if I'm
offered funding to do it. At the present time my existing funding
for MM work is only about $400/month, yet in reality I am spending
5-10 man-days/month on MM.
MYTH: MM won't run on TOPS-20 release 6 and I'm refusing to fix
it.
FACT: There are a set of known issues with MM and TOPS-20 release
6. I haven't done much about them except collect information since I
do not have a release 6 system to debug on. I REFUSE to put in new
code which would be triggered by a TOPS-20 release unless that code
can be tested. I consider potential "timebombs" unacceptable in a
product as important as MM. The current release 6 issues are:
. MM does not support the release 6 POBOX: functionality which allows
for non-PS: mailbox structures. This is a simple enhancement,
deferred only until its support can be tested. I have a description
of how POBOX: works, but I do not trust DEC not to have a few
surprises in store for an implementor trying to support it.
. Apparently, terminal input performance on TVT's has been broken by
release 6 to the point that incoming SMTP service barely works (if
that). Kirk Lougheed has been distributing an alternative SMTPSV
which uses redirected TCP: JFN's instead of a TVT to get around
this problem. My distributed MAISER now supports this method, as
it was originally designed to. The main problem with a full
migration to this scheme is that there is no way with a TCP: JFN
to get the local host address of the JFN. This is necessary to
support the "local port" feature of ARPANET that many sites take
advantage of. There is a defined TCOPR% to supply this information,
but it is not implemented and DEC refuses to make any commitment to
implement it.
. Due to an enlarged MONSYM and "improvements" made to MACRO, MM no
longer assembles in a release 6 environment. It gets an ?MCRNEC
(not enough core) error, because MACRO's data area is limited to
256 pages. DEC refuses to fix MACRO to allow a larger data area.
I have been working on the rather ardous task of splitting MM into
multiple source files; recently I excised the help texts and pointers
out and I am awaiting word on whether that gained enough space. I
am not getting any funding for this effort, so this project is
proceeding slowly.
. MM doesn't run in extended addressing. Yes, I know there are people
out there who would like 300+ page mail files and don't care how
long it takes. I agree this would be a nice extension, but it is a
lot of work. If I spend a month doing this that's a month that the
rent, electric, phone, credit card, etc. bills don't get paid. It
will undoubtably happen eventually, but I don't consider this to be
a major issue. Fewer than 1% of all MM users want 300+ page mail
files.
I am hoping to have satisfactory solutions to most of these problems
by the time release 6 is actually distributed. It would be nice if DEC
were to: (1) add the TCOPR% function to get the local host and stop
dallying on this, (2) fix MACRO to have a larger symbol and macro area,
(3) fix TVT performance (this could be done instead of (1), but both
should be done).
-- Mark --
-------
15-Feb-85 17:25:51-PST,1396;000000000000
Mail-From: MRC created at 15-Feb-85 17:25:34
Date: Fri 15 Feb 85 17:25:34-PST
From: Mark Crispin <
[email protected]>
Subject: 36-Bit Historical Videotape showing: place, date, time
To: "36-Bit Show Goers": ;
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
FREE SHOWING OF THE 36-BIT HISTORICAL SESSIONS
FROM DECEMBER '84 DECUS
Skilling Auditorium, Stanford University
Thursday, 21 February 1985 6:30PM - 9:30PM
Schedule (all times approximate):
6:30 36-BIT TRIVIA BOWL - see the DEC customer team (the BIT
BUSTERS) decisively win over the DEC team (the STACKED
DEC) in their knowledge of 10/20 trivia. Find out how
it was possible, by software, to power off a Ki-10!
7:30 36-BIT PIONEER'S ROUNDTABLE - several noted figures from
the early days of DEC 10's and 20's discuss what it was
like "back then." Members of the panel include PDP-6/10
designers Alan Kotok and Gordon Bell, Tenex inventor Dan
Murphy, and Stanford's own Ralph Gorin. Hear about the
DEC-10 that took a steambath!!
9:00 DEC COMMERCIALS -- new DIGIBITS, the cereal of all ones
and zeros; new DEC-WASH, the disk detergent that cleans
all those lost blocks, etc...
Thanks to: Digital Equipment Corporation, Stanford CSD Computer
Facilities, and Panda Programming.
-------
16-Feb-85 18:20:05-PST,753;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Sat 16 Feb 85 18:19:55-PST
Date: 16 Feb 85 21:18:13 EST
From: Charles Hedrick <
[email protected]>
Subject: more help needed from a midas wizard
To:
[email protected]
Could someone tell me why the following code generates an error
complaining that there are more constants in pass 2 than pass 1? I
assume this is a bug in Midas.
title test
loc 140
define object(type,val)
<.byte 6,30. ? type ? val> termin
move 1,[object 3,<4,,a>]
move 1,[object 3,<4,,b>]
a: 1
b: 2
end
If you replace the macro calls to OBJECT with their definition, the
error does not occur. Putting () around the call does not help.
-------
17-Feb-85 03:23:28-PST,916;000000000000
Mail-From: BILLW created at 17-Feb-85 03:23:26
Date: 17 Feb 1985 03:23-PST
Sender:
[email protected]
Subject: minor bug fix in TTYSRV...
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Cc:
[email protected], Gingell%
[email protected]
Message-ID: <[SU-SCORE.ARPA]17-Feb-85 03:23:25.BILLW>
Problem: backspace is converted to rubout when this is enabled, even in
"emacs mode". This causes annoying beahvior in the new emacs -
backspace would delete the last character if you were at the
end of the line (and doing a TEXTI), but only backspace if you
were in the middle of the line (and EMACS interpreted the char).
Solution: always leave backspaces alone if TT%WK0 (the emacs mode bit)
is on. At TTRAIS (in TTYSRV) plus a couple (just before the
TXNE T1,MO%BSP), insert a TXNN T3,TT%WK0
The source on SCORE and SIERRA have both been updated.
17-Feb-85 12:08:15-PST,712;000000000000
Mail-From: MRC created at 17-Feb-85 12:08:07
Date: Sun 17 Feb 85 12:08:07-PST
From: Mark Crispin <
[email protected]>
Subject: Re: minor bug fix in TTYSRV...
To:
[email protected]
cc:
[email protected],
[email protected],
Gingell%
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Sun 17 Feb 85 03:23:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
But, but, but...
What if you have EMACS set up so backspace is equivalent to rubout?
Do I lose this then? What about texti's for filenames, etc., or isn't
this affected?
-- Mark --
-------
17-Feb-85 15:36:33-PST,1050;000000000000
Mail-From: BILLW created at 17-Feb-85 15:36:30
Date: 17 Feb 1985 15:36-PST
Sender:
[email protected]
Subject: Re: minor bug fix in TTYSRV...
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Cc:
[email protected],
[email protected]
Cc: Gingell%
[email protected]
Message-ID: <[SU-SCORE.ARPA]17-Feb-85 15:36:29.BILLW>
In-Reply-To: The message of Sun 17 Feb 85 12:08:07-PST from Mark Crispin <
[email protected]>
TEXTI is only invoke with the EMACS bit turned on under special
circumstances. Otherwise, the bit stays off, so that reading
filenames and such will behave "properly" (it isnt really a problem
there - typing a ^H used to get you a "not confirmed" error or some
such).
Note that TEXTI does not process the rubout or backsapce by itself.
Instead it is recognized as a break character and passed to emacs
for processing. Thus rubout or backspace can be bound to any
function, and that function will be executed whether the characer
was read by TEXTI or by PBIN...
BillW
18-Feb-85 18:45:36-PST,646;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Feb 85 18:45:27-PST
Date: Mon 18 Feb 85 17:57:00-PST
From: Ken Olum <KDO@SRI-KL>
Subject: Note for MINITS sites
To: tops-20%SU-SCORE@SRI-KL
If you are running MINITS as a network front-end operating system, I've just
found a bug that causes communications not to resume when the 20 is rebooted.
There needs to be a CLR $DTXBF(R5) somewhere in DT$INI to make sure MINITS
doesn't think a leftover packet is still in progress to the 20. Mail to me
if you want more details on this so we don't bother too many folks.
Ken
-------
18-Feb-85 22:00:28-PST,1130;000000000000
Mail-From: MRC created at 18-Feb-85 22:00:18
Date: Mon 18 Feb 85 22:00:18-PST
From: Mark Crispin <
[email protected]>
Subject: [John Wroclawski <JTW%
[email protected]>: Macro data space]
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I just received this note. This may help release 6 sites
which have been unable to recompile MM due to ?MCRNEC errors.
I don't think there is anything MM can do after the fact to
purge .ERCOD, but if somebody knows of a trick which will induce
MACRO to recover this space I'll put it in MM.
---------------
Return-Path: <@MIT-MC:JTW@MIT-SPEECH>
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Mon 18 Feb 85 13:26:40-PST
Date: Mon 18 Feb 85 16:27:43-EST
From: John Wroclawski <JTW%
[email protected]>
Subject: Macro data space
To:
[email protected]
You can make MONSYM.UNV some 26 pages smaller by adding .ERCOD
to the list of things purged at the very end of MONSYM.MAC. Just
saved me, maybe it will help you too.
-------
-------
18-Feb-85 23:59:10-PST,713;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Feb 85 23:59:02-PST
Date: Mon 18 Feb 85 23:58:00-PST
From: Kirk Lougheed <
[email protected]>
Subject: MM and Release 6
To:
[email protected], jtw%
[email protected]
cc:
[email protected]
Using LINK 5.1(2041), MACRO 53.1(1152), TOPS-20 6.0(6370)-4, and a 6.0
MONSYM modified to purge the .ERCOD macro, I was able to assemble the most
recent MM sources.
Note that there is at least one program, SYSDPY, that makes use of the
ERCOD macro. Since MM is distributed with its own copy of MONSYM, I think
the most expedient thing to do would be to modify that MONSYM.
Kirk
-------
19-Feb-85 06:16:53-PST,740;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 19 Feb 85 06:16:44-PST
Date: Tue 19 Feb 85 09:13:07-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: MM and Release 6
To:
[email protected]
cc:
[email protected], jtw%
[email protected],
[email protected]
In-Reply-To: Message from "Kirk Lougheed <
[email protected]>" of Tue 19 Feb 85 02:59:01-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
macro 53b is in use here even though it has not hit the field yet. among
other things it has polish blocks which are one word larger than they used
to be. this puts mm way over the edge for free space in macro.
-------
19-Feb-85 18:10:10-PST,673;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 19 Feb 85 18:09:55-PST
Date: Tue 19 Feb 85 18:08:05-PST
From: Ken Harrenstien <
[email protected]>
Subject: Re: more help needed from a midas wizard
To:
[email protected],
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Charles Hedrick <
[email protected]>" of Sat 16 Feb 85 21:18:13-PST
Yes, this is a constants over-optimization bug. I have noted it for
future fixing -- thanks for the simple test case. If you remove the
angle brackets from the macro body, your example should work (the
bracketing provided by [] is sufficient).
-------
20-Feb-85 09:08:46-PST,842;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Feb 85 09:08:32-PST
Date: Wed, 17 Nov 58 00:00 GMT
From: SAMUELSON%
[email protected]
Subject: TOPS-20 TeX spooling
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: TeXHax@SU-SCORE.ARPA,
tops-20@SU-SCORE.ARPA
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
Has anyone modified LPTSPL on TOPS-20 to handle .DVI files directly?
We currently have a VERSATEC printer/plotter which has only 100dpi
resolution, we will someday get a QMS-1200 laser printer. We would
like to find a version of LPTSPL with the required hacks to read DVI
files and write rasters to the Versatec.
- Sam -
-------
20-Feb-85 16:28:23-PST,2358;000000000000
Return-Path: <ALAN@MIT-MC>
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Wed 20 Feb 85 16:27:31-PST
Date: 20 February 1985 15:15-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: more help needed from a midas wizard
To: HEDRICK @ RUTGERS
cc: BUG-MIDAS @ MIT-MC, tops-20 @ SU-SCORE
Date: 16 Feb 85 21:18:13 EST
From: Charles Hedrick <HEDRICK at RUTGERS>
Could someone tell me why the following code generates an error
complaining that there are more constants in pass 2 than pass 1? I
assume this is a bug in Midas.
title test
loc 140
define object(type,val)
<.byte 6,30. ? type ? val> termin
move 1,[object 3,<4,,a>]
move 1,[object 3,<4,,b>]
a: 1
b: 2
end
If you replace the macro calls to OBJECT with their definition, the
error does not occur. Putting () around the call does not help.
I replaced the macros calls to OBJECT to obtain the following:
title test
loc 140
move 1,[<.byte 6,30. ? 3 ? <4,,a>>]
move 1,[<.byte 6,30. ? 3 ? <4,,b>>]
a: 1
b: 2
end
Which also gets the "more constants on pass 2" error, so I don't think that
the macro has anything to do with it. (You must have spazzed when you
performed the expansion manually.) Your problem would seem to be just
another instance of a perennial midas screw. This one has probably shafted
everybody at least once.
What is happening is that on pass 1 Midas uses 0 as the value of as-yet
undefined symbols, such as A and B in your example. This causes both
literals to look like they will contain the same one-word quantity. Midas
tries to be clever and optimize one-word literals to share the same
storage. Then on pass 2 they turn out to be different and Midas hasn't
allocated enough constants space.
I don't understand why this one doesn't shaft people -more- than it does
now. Big programs generally generate enough noise in their constants
between pass 1 and pass 2 that they don't get screwed, only small programs
get bit. I guess I would advocate putting in a switch to turn the
constant-sharing hack off so that people can work around this screw when it
happens. Clearly there are better solutions, but that would be sufficient.
21-Feb-85 14:34:36-PST,865;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Feb 85 14:32:47-PST
Received: ID <
[email protected]>; Thu 21 Feb 85 17:32:32-EST
Date: Thu 21 Feb 85 17:32:31-EST
From:
[email protected]
Subject: Bug in my hack for UDP access...
To:
[email protected]
If anyone has imported my changes to IPIPIP which allow non-priviliged users
access to the Internet queues for UDP datagrams, I discovered a bug in that
causes the system to hang. At ASNIQ0+28, there is a RETERR(NETWKX), taken if
a user needs but does not have SC%ANA. This causes ASNIQ% to return with
INTQLK locked, which hangs all jobs which attempt to use the Internet queues
(and all jobss to RELIQ%'s during login/logout). This line should be changed
to a JRST ASNIX1. At ASNIQX+2, add a SKIPA T1,[-1,,NETWKX].
--Vince
-------
21-Feb-85 16:25:57-PST,895;000000000000
Return-Path: <
[email protected]>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Feb 85 16:25:45-PST
Date: Thu 21 Feb 85 19:24:58-EST
From: Chris Maio <
[email protected]>
Subject: Re: Bug in my hack for UDP access...
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 21 Feb 85 17:53:48-EST
I have another patch for system hangs in tcp/ip monitors. The symptoms are the
same as Vince describes (processes hanging uninterruptably during RESET% or
CLZFF% jsyses, or after ^C), and is related to TCP jfns (more specifically,
TCBHLK is more than 10 or so and page zero of INTSEC exists). I don't
recommend installing this patch if it's not needed, since it's really only a
workaround, but if you've had this problem before let me know and I'll mail you
the patch.
- Chris
-------
22-Feb-85 13:06:36-PST,1173;000000000000
Mail-From: MRC created at 22-Feb-85 13:06:11
Date: Fri 22 Feb 85 13:06:11-PST
From: Mark Crispin <
[email protected]>
Subject: DTR control
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I know this issue is getting rather tiresome, but it's time for
another round of the great "how do I set DTR on a dialout modem" series.
I'd like to know what the current popular method is, for a site with
Ven-Tel modems and *no* front-end sources running some version of the
release 5 RSX with some unknown number of patches.
Personally, I feel that having separate jsi to control DTR on
modems (even as MTOPR's) is a crock. DTR should be set on a modem on
creation of a dynamic data block from a user's OPENF% or ASND% and
should be dropped on deletion of the dynamic data block. It even makes
sense. ACJ can be used to enforce any access restrictions to dialout
lines, just as any security-conscious site controls opening ordinary
TTY's as devices.
I tried using DEC's DTRFE.MIC file, but seem to have come up with
a big zero.
-------
22-Feb-85 16:50:31-PST,1225;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Feb 85 16:49:42-PST
Date: Fri 22 Feb 85 17:50:12-MST
From: Randy Frank <
[email protected]>
Subject: Re: DTR control
To:
[email protected],
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Fri 22 Feb 85 14:41:33-MST
The latest release of RSX20F (version 15-xx) finally contains supported
code for controlling DTR from the back end. I believe that 20F 15-15 is
currently in the SDC so it should be available shortly.
Basically the code enables the queued protocol code .DFLDU (line dialed
up) in the to-11 direction, in which case it turns on DTR. Previously
this was only supported in the to-10 direction which was used when a
remote line was connected. (Turning off DTR has always been supported
via .DFLHU (line hang up)).
At the moment there is no supported mtopr function for accessing these, but
at least the front-end is no longer a problem.
I agree with Mark that turning on DTR when a local line become active is a
good idea; however, an MTOPR should also be provided since therre are cases
where controlling DTR for other purpose is needed.
-------
22-Feb-85 17:37:33-PST,1010;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Feb 85 17:37:22-PST
Date: Fri 22 Feb 85 16:31:55-PST
From: Ken Olum <KDO@SRI-KL>
Subject: Re: DTR control
To: MRC%SU-SCORE@SRI-KL
cc: tops-20%SU-SCORE@SRI-KL
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Fri 22 Feb 85 16:12:20-PST
There's two problems -- how to get the front-end to set DTR and how
to get the monitor to tell it. We tell the FE to set DTR on ASND/OPENF and
also with MTOPR and that all works fine. The protocol that TOPS-20 uses
to tell RSX20F what to do is the DIALUP function of the Queued-protocol, which
is handled by some source-level patches to the FE. I've heard that some FE
version from DEC does this without the patches, but no one has confirmed it.
Failing that there's an OBJECT level patch to RSX20F, in use by HP, whereby when
you send a set-speed command to the FE with the remote bit set that it sets
DTR on the line.
Ken
-------
23-Feb-85 10:49:03-PST,623;000000000000
Return-Path: <
[email protected]>
Received: from SU-GSB-WHY.ARPA by SU-SCORE.ARPA with TCP; Sat 23 Feb 85 10:48:55-PST
Date: Sat 23 Feb 85 10:48:53-PST
From: Joel P. Bion <
[email protected]>
Subject: DTR control
To:
[email protected]
Indeed, the new front end does support DTR control. I used to run a modified
front end, but now the new Digital front end standard does everything the
modified one did. Include not working on DEC-DH controlled lines! (It seems
to work on the Able DHs we have; HP had similar problems recently when they
tried to use the new DEC front end.)
Joel
-------
25-Feb-85 10:14:47-PST,753;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Feb 85 10:14:32-PST
Date: Mon 25 Feb 85 10:02:09-PST
From: Haruka Takano <
[email protected]>
Subject: Re: DTR control
To:
[email protected], MRC%
[email protected]
cc: tops-20%
[email protected]
In-Reply-To: Message from "Ken Olum <KDO@SRI-KL>" of Mon 25 Feb 85 00:18:23-PST
Actually, HP no longer uses the FE patch to which Ken Olum referred.
Instead, we are running an unpatched RSX20F VB15-13. Since we were
able to incorporate the monitor changes in use at the Stanford
Graduate School of Business without any other mods, I assume that
DEC is using FE code very similar to that developed by Joel P. Bion
for GSB.
--Haruka
-------
26-Feb-85 13:19:00-PST,2061;000000000000
Mail-From: MRC created at 26-Feb-85 13:18:42
Date: Tue 26 Feb 85 13:18:42-PST
From: Mark Crispin <
[email protected]>
Subject: MAISER status
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I now know of a way to get the local host address for a JFN-based
connection (thank you, JTW) and consequently this interface to MAISER
is now fully supported as an alternative to the TVT-based interface
commonly in use.
There are now two different SMTP listening programs, SMTPSV and
SMTJFN. SMTPSV is as it has been; it listens for SMTP connections and
will fire up MAISER jobs on network terminals to satisfy those requests
without limit. SMTJFN runs MAISER subforks by redirecting the primary
I/O to those subforks, and is assembled with a limit of 8 simultaneous
connections. At the present time, the NETSRV program uses an SMTPSV
style TVT interface; eventually it will be converted to a JFN interface.
Which style of SMTP listener you run is mostly up to you. The TVT
interface is probably less vulnerable to problems which would crash the
JFN interface, because of the former's intrinsic simplicity. The TVT
interface also allows many more simultaneous SMTP connections (assuming
you care). The JFN interface is reputed to perform better, especially
under TOPS-20 release 6. I believe that eventually the focus of support
will migrate to the JFN interface.
Also, contrary to earlier statements by me and some others, it
looks like the SMTP/TVT performance problems are not due to any bug
introduced in TVT service explicitly. In particular, the problem with
"go-ahead" signals at MIT-XX was due to XX's using an unsupported portion
of TVT service which DEC has turned off. So, apparently the "release 6
TVT problem" is a general behavior of release 6 and not some new bug.
We all beat on KWP enough that it's only fair to set the record straight
when it isn't his bug!
-- Mark --
-------
27-Feb-85 14:56:05-PST,1330;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Wed 27 Feb 85 14:55:33-PST
Date: 27 Feb 85 17:55:34 EST
From: Charles Hedrick <
[email protected]>
Subject: I/O performance
To:
[email protected]
We have 3 DEC-20's. They are all 1.25 or 1.5 MW of memory. Two
of them have 3 RP06's for PS:. The third has 1 RP07. The third
one seem to have much worse response for the same load average as
the other two. It certainly has a somewhat different job mix,
but we are beginning to suspect that the disk configuration is a
problem. WATCH seems to show that we are getting about 50 pages/sec
of I/O to PS:. Previous tests suggest that on our other systems,
we get 75 to 100 pages/sec. We are wondering whether this means
that 50 pages/sec is in fact the practical limit for RP07's in
a timesharing mix (i.e. with PS: and paging on it). Does anybody
have enough experience to know how an RP07 compares with 3
RP06's? As you may imagine, we are considering reconfiguring
disks, either swapping drives around so that we use RP06's for
PS: on all systems, going to a 2 RP07 PS:, or moving swapping
to a non-PS: drive. We would be curious whether anyone else has
either experience or measurements that would help us decide whether
this is worth doing.
-------
27-Feb-85 18:20:48-PST,558;000000000000
Mail-From: MRC created at 27-Feb-85 18:20:13
Date: Wed 27 Feb 85 18:20:13-PST
From: Mark Crispin <
[email protected]>
Subject: more Ventel modems
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I have determined that in fact I am getting DTR set and the system
is receiving characters from me. However, I am not getting anything from
the modem. Could there be some problem in the lines being set to autobaud
in the config file?
-------
27-Feb-85 20:54:54-PST,775;000000000000
Mail-From: CRISPIN created at 27-Feb-85 20:54:39
Date: Wed 27 Feb 85 20:54:39-PST
From: Mark Crispin <
[email protected]>
Subject: WARNING to MACREL users!!!
Sender:
[email protected]
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
It appears that the release 6 MACREL now assembles in a DEC
copyright notice into the EXE file. As this may have substantial
legal implications to users of the MACREL library I strongly
suggest not using the release 6 MACREL and/or developing a private
MACREL library for your own software.
I just discovered this myself when debugging one of my programs.
I was amazed to find the DEC copyright...
-------
27-Feb-85 22:42:48-PST,926;000000000000
Mail-From: BILLW created at 27-Feb-85 22:42:43
Date: Wed 27 Feb 85 22:42:43-PST
From: William "Chops" Westfield <
[email protected]>
Subject: bug in EXEC/Sumex GTJFN
To:
[email protected]
When you type something on the order of G? to the exec, It
will respond with a list of exec commands beginning with "G",
followed by a list of FILES IN YOUR DIRECTORY that begin with
"G". Clearly this in wrong. At worst, the files should come
from SYS:, but I don't think that this is what is wanted either
(since it would interfere with defaulting of commands). There
ought to be a way to supress COMND from passing the "?" on to
GTJFN. This could be either a new bit, or could be tied to
CM%SDH and CM%HPP. Any feelings how this should be done?
(I've looked at the code in COMND, and it should be fairly
easy to fix CHKFIL to do the proper thing, once we decide
what "proper" is.)
BillW
-------
28-Feb-85 09:53:42-PST,1146;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Feb 85 09:53:37-PST
Date: Thu 28 Feb 85 09:51:23-PST
From: Andrew Sweer <
[email protected]>
Subject: Re: bug in EXEC/Sumex GTJFN
To:
[email protected]
cc:
[email protected]
Bill,
I'm not sure what you're driving at. Here at Sumex, when
you type something like M? to the exec, you get a list of exec
commands beginning with M, followed by a list of files beginning
with M that are in the 1st directory in your current definition
of SYS:. It sounds like you may have had DSK: in there, whereas
I usually have NEW: as the 1st item in my SYS:. It has been
suggested that GTJFN be smartened up to search all the dirs in the
logical name chain, but that is another story...
Andy
[PHOTO: Recording initiated Thu 28-Feb-85 9:37AM]
@m? Command, one of the following:
MAIL MAP MERGE MODIFY MOUNT
or kept fork name,
MCHECK
MERLIN
MODEM
MTCOPY
@m^C
@v sys:m?
MCHECK
MERLIN
MODEM
MTCOPY
@v sys:m^C
@pop
[PHOTO: Recording terminated Thu 28-Feb-85 9:38AM]
-------
28-Feb-85 10:34:56-PST,682;000000000000
Mail-From: MRC created at 28-Feb-85 10:34:52
Date: Thu 28 Feb 85 10:34:51-PST
From: Mark Crispin <
[email protected]>
Subject: Re: bug in EXEC/Sumex GTJFN
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Wed 27 Feb 85 22:42:49-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
It isn't files in your directory that is output; it's the first directory
in your SYS: search list. I'll bet you redefine SYS:.
I'm not at all sure the present behavior is wrong. Sub-optimal, perhaps,
but not wrong.
-------
28-Feb-85 11:11:13-PST,766;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Feb 85 11:11:08-PST
Date: 28 Feb 1985 10:49 PST (Thu)
Message-ID: <
[email protected]>
From: Bill Palmer <
[email protected]>
To: Andrew Sweer <
[email protected]>
Cc:
[email protected],
[email protected]
Subject: bug in EXEC/Sumex GTJFN
In-reply-to: Msg of 28 Feb 1985 09:51-PST from Andrew Sweer <SWEER at SUMEX-AIM.ARPA>
Stuart Reges posted a 2000+ char gripe/question about this same
behavior to BUG-EXEC at LOTS some time ago. I'll repost it if I have
a chance to hunt it down; it's a look at the problem from another
viewpoint (that of a user who can't really be told to go look at the
sources).
Bill
28-Feb-85 11:30:50-PST,930;000000000000
Mail-From: MRC created at 28-Feb-85 11:30:41
Date: Thu 28 Feb 85 11:30:41-PST
From: Mark Crispin <
[email protected]>
Subject: Re: bug in EXEC/Sumex GTJFN
To:
[email protected]
cc:
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "Bill Palmer <
[email protected]>" of Thu 28 Feb 85 10:49:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
A more serious concern is the apparently bad interaction between the
Sumex GTJFN% and the DSK* code. It seems that if you have the bugfix
to support PS's which aren't named PS, there are various RELBAD bugchks
which can result as well as logical names for DSK* (Score defines ALL:
ala TOPS-10) not working. It isn't reliably reproducable. I imagine
that the block address for the device name is remembered someplace it
shouldn't be.
-------
28-Feb-85 13:27:09-PST,608;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Feb 85 13:26:55-PST
Date: Thu 28 Feb 85 12:09:20-PST
From: Ken Olum <KDO@SRI-KL>
Subject: Re: more Ventel modems
To: MRC%SU-SCORE@SRI-KL
cc: tops-20%SU-SCORE@SRI-KL
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Wed 27 Feb 85 18:52:15-PST
Which part of the system is getting the characters? There's a magic bit
in the FE that you have to set to get it to listen to the line (I think
it is TT.CON) DEC may not have set this bit in their DTR-setting routine.
ken
-------
28-Feb-85 16:53:35-PST,841;000000000000
Mail-From: BILLW created at 28-Feb-85 16:52:48
Date: 28 Feb 1985 16:52-PST
Sender:
[email protected]
Subject: Re: bug in EXEC/Sumex GTJFN
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Message-ID: <[SU-SCORE.ARPA]28-Feb-85 16:52:45.BILLW>
In-Reply-To: The message of Thu 28 Feb 85 09:51:23-PST from Andrew Sweer <
[email protected]>
oops. You are correct. I have DSK: first in my search list.
And the bad interaction that I thought was happening (EXEC
commands not completeing because they conflicted with file
names (as in G$ not completing to GET), turns out to be due
to invisible MIC commands (GOTO) instead, so I guess the
problem isn't really there. (the provided help message
SHOULD be printed, I think ("or system program:")).
Sorry.
Bill W
1-Mar-85 09:59:30-PST,658;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 1 Mar 85 09:59:20-PST
Date: Fri 1 Mar 85 10:00:17-PST
From: Greg Satz <
[email protected]>
Subject: [Ken Harrenstien <
[email protected]>: Filename wildcard lossage]
To:
[email protected]
Phone: (415) 497-1004
Anyone feel like doing this?
--------------------
Date: Fri 1 Feb 85 15:43:41-PST
From: Ken Harrenstien <
[email protected]>
Subject: filename wildcard lossage
It appears that although <X.*> will work to scan all subdirs of x,
<.*> will not, even though you are connected to x. Barf. Something
for the TOPS-20 list?
-------
2-Mar-85 13:42:19-PST,511;000000000000
Return-Path: <
[email protected]>
Received: from nta-vax.ARPA by SU-SCORE.ARPA with TCP; Sat 2 Mar 85 13:41:29-PST
Posted-Date: 2 Mar 1985 22:40-EST
Received: by nta-vax.ARPA (4.12/3.21)
id AA00600; Sat, 2 Mar 85 22:41:39 -0100
Date: 2 Mar 1985 22:40-EST
From:
[email protected]
Subject: oslo-vax address change
To: tops-20@SU-SCORE
Message-Id: <478647614/bassen@nta-vax>
In-Reply-To: bassen's message of 2 Mar 1985 2205-EST
Please change the network addres for oslo-vax to:
128.39.2.2
2-Mar-85 14:11:01-PST,1859;000000000000
Return-Path: <SY.KEN%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Sat 2 Mar 85 14:10:45-PST
Received: from CU20B.ARPA by columbia.arpa; Sat, 2 Mar 85 04:37:52 est
Date: Sat 2 Mar 85 17:10:53-EST
From: Ken Rossman <sy.Ken%
[email protected]>
Subject: Query to Tops sites
To:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Dave asked me to forward this query to TOPS-20 for him. My apologies if it
is inappropriate for this mailing list. /Ken
---------------
Date: Fri 1 Mar 85 01:28:48-EST
From: David Emigh <
[email protected]>
Subject: Query to Tops sites
The University of Saskatchewan is in the process of replacing the campus
Dec-20 and have been wondering what kind of resale value could be expected
on the hardware. The configuration is as follows:
- 1 KL10-B processor, Serial# 2364
- 256Kw MB20 core memory
- 1.5Mw MF20 Mos memory
- 3 RP06 disk drives(1 dual-port)
- 3 RH20 channels(for tapes and disks)
- 1 RTP20 Disk subsystem(including 1 RH20 channel,1 Dx20 interface)
- 96 asynchronous ports(Console Front-End)
- 1 DN20 Front End, with 1 Synchronous line controller(KMC11/DUP11)
- 2 TU45 tape drives with TM03 controller
- 2 TU77 tape drives with TM03 controller
- 1 LP20 900 LPM printer
- 1 CD20 300 Card reader
- 1 La120 console
The system is about 5 years old and is currently running Top-20 Version 5.1.
Replys can be forwarded to myself at the following USENET address:
..!ihnp4!sask!skyward!emigh
or via snail mail address:
David Emigh
Systems Programmer
Academic Computing Services
Room 65, Arts Addtion
Saskatoon, Saskatchewan
Canada, S7N OWO
-------
-------
2-Mar-85 23:18:25-PST,899;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 2 Mar 85 23:18:15-PST
Date: 3 Mar 1985 00:18 MST (Sun)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS20@SCORE
Subject: Front-ending FINGER
One of the features that FINGER lacks is the ability to lookup aliases
(a feature I've been working with in building a finger for our C/70s
under Unix). At first I considered modifying FINGER itself, but the
fact that MMAILBOX loads it, and avoiding the recursive loading of
MMAILBOX when FINGER is called at the normal entry point is possible
although messy.
The "better" solution would be to "front end" FINGER with a variant of
MMAILBOX, which almost nobody knows about nor uses as a standalone
program at its regular entry point. Has somebody already done this?
--Frank
3-Mar-85 14:34:34-PST,1401;000000000000
Mail-From: MRC created at 3-Mar-85 14:34:20
Date: Sun 3 Mar 85 14:34:20-PST
From: Mark Crispin <
[email protected]>
Subject: Re: Front-ending FINGER
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from ""Frank J. Wancho" <
[email protected]>" of Sun 3 Mar 85 00:18:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
One of the technical problems in this is also the fact that the TOPS-20
mailsystem makes no distinction between a mailing list, a mail forwarding,
and a mail alias. All are instances of a mailbox that will deliver to one
or more files/network recipients.
This model has the advantage of being simple and working for most cases
(the ITS mailsystem works similarly). It doesn't work too well when you
really want to distinguish aliases as a separate entity (as in Frank's
Finger project) from mailing lists and forwardings. Some things, such as
"FINGER TOPS-20@SU-SCORE" in a system which can't tell aliases from
mailing lists, would quickly demonstrate the problem. A similar problem
is that it's difficult to have the "mail to mailer" feature that Unix has
to get added to or removed from mailing lists in TOPS-20; there's no way
for it to know that this "mailing list" isn't really an alias where the
user's request should be disallowed.
-------
3-Mar-85 14:59:33-PST,1312;000000000000
Return-Path: <SY.KEN%
[email protected]>
Received: from columbia.arpa by SU-SCORE.ARPA with TCP; Sun 3 Mar 85 14:59:14-PST
Received: from CU20B.ARPA by columbia.arpa; Sat, 2 Mar 85 16:46:14 est
Date: Sun 3 Mar 85 18:00:24-EST
From: Ken Rossman <sy.Ken%
[email protected]>
Subject: Re: Front-ending FINGER
To:
[email protected],
[email protected]
Cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Sun 3 Mar 85 17:41:20-EST
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
As far as I'm concerned, MMAILBOX and Finger should go separate ways now.
I really think the name server support in MMAILBOX should be entirely
different code from Finger (i.e. I think the name lookup routine ought to
be written into MMAILBOX, rather than MMAILBOX forking up Finger). There
are several reasons for this:
- I think the MMAILBOX name lookup code should perform a slightly
different set of functions than Finger's name server code.
- You would save at least three forks in the mailer subjob, depending on
whether you use a multiforking SMTPSV or the job creation version (We
would save a few more than three here at CU).
Why not just make the name server into a separately requireable module?
/Ken
-------
3-Mar-85 15:25:22-PST,794;000000000000
Mail-From: MRC created at 3-Mar-85 15:24:56
Date: Sun 3 Mar 85 15:24:55-PST
From: Mark Crispin <
[email protected]>
Subject: Re: Front-ending FINGER
To: sy.Ken%
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "Ken Rossman <sy.Ken%
[email protected]>" of Sun 3 Mar 85 14:59:32-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
The problem with putting Finger in MMailbox is that there are at least
four distinct Finger programs for TOPS-20 that I know of, each with its
own data base (uh, make that five). That would introduce site dependencies
in MMailbox, something I abhor and have gone to great efforts to yank out
of the entire mailsystem.
-------
4-Mar-85 01:52:39-PST,429;000000000000
Return-Path: <bassen@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 01:52:28-PST
Received: by oslo-vax.ARPA (4.12/4.7)
id AA10384; Mon, 4 Mar 85 10:52:56 -0100
Date: 4 Mar 1985 10:16-EST
From: bassen@oslo-vax (T S Lande)
Subject: oslo-vax address change
To: tops-20@su-score
Message-Id: <478775793/bassen@oslo-vax>
I am sorry for my mistake posting address-change to the list.
4-Mar-85 12:44:59-PST,2482;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 12:44:37-PST
Date: 4 Mar 1985 1537-EST
From: Reed B. Powell <POWELL at DEC-MARLBORO>
To: tops-20 at SU-SCORE, info-vax at SRI-KL
cc: powell at LSMVAX, pomfret at IO
Large-Systems-Marketing: LCG Product Line
Location: "231-4261 MRO2-2/3C (Pole 4A)"
REPLY: "MARKET:: or MRVAX::"
Subject: Connecting Supercomputers to DEC's Cluster Systems
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12092403673.40.146.104167 at DEC-MARLBORO>
We are investigating the methods useful to the market for connecting
the various "supercomputers" in the industry (Cybers, Crays, etc) to
Digital's clustered systems. There are many reasons people have for
desiring this, but usually it falls into the general catagory of
"front-ending" the expensive supercomputers with lower cost
systems used for data-preperation, data-presentation, etc. IE: Keep the
supercomputer busy doing what it is best at.
There are a number method of doing this. Hyperchannel seems to be doing
well in the most general case of connecting anything to anything, but
also seems to be adversely affected by coping with those generalities.
What DEC is looking at is a method of hooking those systems up to
DEC's systems.
The only thing we have pretty much decided -- and even this is not cast
in concrete -- is that is should be oriented around a connection to the
CI bus, which is what connectes the systems of a cluster, as well as
their disk servers, together.
What we are specifically soliciting is information in two broad areas:
1. What functionality does the market want? Should we look into
servers, gateways, rje-s, or what? Should the supercomputers
"look" like another DEC computer on a cluster, or should there
be something in between that performs a "monkey in the middle"
function.
2. Ideas on implementation. It would be best if anyone submitting
ideas in this catagory also include some information from the
above catagory, since we must in the end justify our actions
based on market needs.
Since most of the supercomputers are in sites related to ARPAnet,
this seems to be the best, most effecient way to gather this data.
Anyone wanting to talk directly about this should leave a phone number,
and someone related to this project will be glad to talk.
thanks in advance,
-reed
--------
4-Mar-85 21:53:04-PST,588;000000000000
Return-Path: <
[email protected]>
Received: from SU-CSLI.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 21:52:58-PST
Date: Mon 4 Mar 85 21:28:48-PST
From: Mark Crispin <
[email protected]>
Subject: <..foo[esc]
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I crashed CSLI by doing completion on a subdirectory via "..". I have
been told that this bug is well known but nobody fixed it because it is
fixed in V6 and everybody will be running 6. What is this bull?
-------
4-Mar-85 21:58:10-PST,550;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 21:58:05-PST
Date: Mon 4 Mar 85 21:58:38-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: <..foo[esc]
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 4 Mar 85 21:57:26-PST
That bug was fixed in the Release 5.3 sources as of 2-Oct-84. CSLI must
be running an old monitor.
Read the sources; don't believe what people tell you.
Kirk
-------
4-Mar-85 21:58:24-PST,550;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Mar 85 21:58:05-PST
Date: Mon 4 Mar 85 21:58:38-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: <..foo[esc]
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 4 Mar 85 21:57:26-PST
That bug was fixed in the Release 5.3 sources as of 2-Oct-84. CSLI must
be running an old monitor.
Read the sources; don't believe what people tell you.
Kirk
-------
5-Mar-85 15:16:00-PST,1325;000000000000
Mail-From: MRC created at 5-Mar-85 15:14:08
Date: Tue 5 Mar 85 15:14:07-PST
From: Mark Crispin <
[email protected]>
Subject: Announcing Cafard: TTY mail for TOPS-20
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
The long-awaited Cafard (French for "cockroach") program has at
last been completed. Cafard interfaces through the mailsystem's
Special network interface to provide a mail facility over TTY lines.
The current version of Cafard is Phase I, using a lock-step private
protocol.
I expect that there will be an operational Cafard link between
two of Stanford's timesharing systems (one of which isn't on the campus
Ethernet and won't be soon) sometime in the next week or two.
Cafard's source files are on the usual MM distribution directory.
CAFARD.MAC is the main program and script processor, CAFPRO.MAC contains
the protocol routines, and CAFDTR.MAC is a site-written DTR control
module (since it seems everybody has their own way to control DTR on a
dialout modem). Documentation is on SCO:<MM.DOCUMENTATION>CAFARD.DOC;
you may also want to look at the OPEN-DIALOG.TXT and CLOSE-DIALOG.TXT
files on that directory as well as the SPECIAL-NETWORK.DOC file.
-------
5-Mar-85 22:21:17-PST,1037;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Mar 85 22:20:58-PST
Date: Tue 5 Mar 85 22:21:02-PST
From: Kirk Lougheed <
[email protected]>
Subject: GTHST%/HSTINI interlock
To:
[email protected]
Problem:
While a new copy of the NIC's HOSTS.TXT is being loaded into the monitor,
GTHST% will sometimes fail to find host names and addresses. This usually
results in network mail being lost or dequeued and marked as "bad".
Analysis:
There is no interlocking on access to the monitor's internal host table.
Solution:
Implement a simple lock on the routines (HSTINI and the GTHST% JSYS) that
manipulate the host table. The changes are all local to MNETDV.MAC.
REDIT files for 5.3 and 6.0 monitors may be found on SU-SIERRA in
PS:<ANONYMOUS> as MNETDV-53.RED and MNETDV-60.RED.
Credit:
Bill Palmer (WHP4@SIERRA) is the author of these changes. They have been
running on Sierra under Release 6.0 since last Saturday without incident.
-------
5-Mar-85 22:24:42-PST,500;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 5 Mar 85 22:24:33-PST
Date: Tue 5 Mar 85 22:24:41-PST
From: Kirk Lougheed <
[email protected]>
Subject: extended FORTRAN-77
To:
[email protected]
Could some kind person point me to the changes necessary to create
an extended addressing FORTRAN-77? I know some work was done by
Norm Samuelson at Sandia, but I've lost track of where to get the
changes.
Thanks,
Kirk
-------
6-Mar-85 07:49:11-PST,1474;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 07:48:59-PST
Date: Wed, 6 Mar 85 15:49 GMT
From: SAMUELSON%
[email protected]
Subject: Re: extended FORTRAN-77
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: Lougheed@SU-SIERRA.ARPA
cc: tops-20@SU-SCORE.ARPA
In-Reply-To: Message from "Kirk Lougheed <
[email protected]>" of Wed 6 Mar 85 07:24:24-PST
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
DEC's current FORTRAN compiler (v7) without any modifications produces
code that will run in a non-zero section. With some help from a macro
routine (which I can provide if anyone is interested) you can allocate
memory in other sections and use it in either of two ways:
1) include an OFFSET in EVERY reference to each such extended array
2) pass the starting address of the array in a subroutine call
in the first case the array can be in COMMON, in the second case
the subroutine can access the argument array normally.
Neither of those is absolutely ideal, and I would not put too much
effort into making it work for a big program unless your needs are
to have it working VERY soon. Far be it from me to say anything
proprietary about an ongoing field test, but let me say that if you
can wait a few months you may be VERY HAPPY.
- Sam -
-------
6-Mar-85 08:23:01-PST,1307;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 08:22:50-PST
Date: 6 Mar 1985 10:46-EST
Sender:
[email protected]
Subject: Re: GTHST%/HSTINI interlock
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA] 6-Mar-85 10:46:06.CLYNN>
In-Reply-To: The message of Tue 5 Mar 85 22:21:02-PST from Kirk Lougheed <
[email protected]>
When we installed a lock on the host tables at BBN last year we noted
that things like SYS would hang when trying to translate "foreign host".
We eventually added a GTHST% flag for use by those applications, such
as mail, which really needed a translation; if the flag was not set and
the tables were locked, GTHST% would fail.
We are about to add the name resolver code being developed at ISI;
I expect that the need to consult a foreign name server will make the
problem more apparent. Options being considered include having the
application specify a time that it is willing to wait before GTHST%
should give up, a mode which gives up immediately if the translation
is not in the local cache, and a mode which initiates resolution but
fails if not in the cache. Does anyone have comments or suggestions
about how the problem to be handled?
Charlie
6-Mar-85 13:22:24-PST,846;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 13:21:35-PST
Date: Wednesday, 6 March 1985, 12:40-PST
From: Ken Olum <KDO@SRI-KL>
Subject: Hung TCP connections from remote crash
To: tops-20 at su-score
Message-ID: <
[email protected]>
Here at Schlumberger we have the problem that if a TCP connection is open and
the remote host crashes and remains down that the connection will be hung in
EST.FIN or EST.NOT. No process ever seems to time out on the other host and
declare the connection dead, so it stays around forever, and if it is a TVT
connection then that TVT is wedged.
1. Have other people had this problem? Is there a fix?
2. How is it SUPPOSED to work? I can't find anything in the TCP spec that can
detect the other side having crashed.
Ken
6-Mar-85 15:23:20-PST,1783;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 6 Mar 85 15:23:05-PST
Date: 6 Mar 1985 18:22-EST
Sender:
[email protected]
Subject: Re: Hung TCP connections from remote crash
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA] 6-Mar-85 18:22:02.CLYNN>
In-Reply-To: <
[email protected]>
I am not sure what the protocol designers intended, but one might
argue that the connection should sit there forever because the other
end didn't really crash but chooses not to communicate (and possibly
let everyone know they are still there). In a more commercial
environment there are actions which can be taken.
The TOPS-20 TCP periodically sends probes on inactive connections
(unless the host administrator has disabled it). The probe is a
SYN-ACK with a bad sequence number. The other end, if it has crashed
and restarted, will send a reset reply which will cleanup the half
open connection.
If the other end has crashed and stays down, no resets will be
received so the connection will stay around. The TOPS-20 TCP also has
a timer (it was distributed as an hour) for inactive connections which
reset the connection (a telnet job would be detached).
Some sites, such as ISI, send a warning message on idle telnet
connections; the message will start a retransmission timer which will
kill the connection if the other host remains down.
If the TOPS-20 and the other host are both on an 1822 net which gives
host down messages, or if some ICMP were to send a destination
unreachable message back to the 20, the connection would be aborted
(but I do not think that DEC has the version of TCP which processes
ICMP messages ready for distribution).
Charlie
7-Mar-85 12:46:56-PST,1053;000000000000
Mail-From: CRISPIN created at 7-Mar-85 12:46:39
Date: Thu 7 Mar 85 12:46:39-PST
From: Mark Crispin <
[email protected]>
Subject: Re: GTHST%/HSTINI interlock
Sender:
[email protected]
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected]" of Wed 6 Mar 85 07:46:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
My main concern is that any application doing GTHST% in the traditional
case should block. You should do something extra to get non-blocking.
Upwards compatibility from the existing GTHST% is essential. This means
that if you do a traditional GTHST% it must "work" in the traditional
way -- "get data from host table of all hosts". Since there is no host
table it should block in this case and fail only if there really is no
such name anywhere.
I'd be worried about major disasters with mail otherwise.
Otherwise your plan sounds reasonable.
-- Mark --
-------
7-Mar-85 14:25:39-PST,710;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 14:25:14-PST
Received: ID <
[email protected]>; Thu 7 Mar 85 17:25:06-EST
Date: Thu 7 Mar 85 17:25:05-EST
From:
[email protected]
Subject: TELNET options
To:
[email protected]
Has anyone out there experimented with adding additional TELNET option support
to TOPS-20? The way that TTANDV is written, it would appear extremely difficult
to add any new options - it appears to make rather bogus assumptions about the
number of options in existance, being limited to about 8 of them. I would be
interested to hear from anyone else who has tried to add new options.
--Vince
-------
7-Mar-85 17:17:01-PST,882;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 17:16:41-PST
Date: Thu 7 Mar 85 17:16:44-PST
From:
[email protected]
Subject: autopatch tape 8
To:
[email protected]
Finally, I am getting to working on the 5.4 monitor. I noticed that
the files are based on the autopatch tape #8, however. I have found
that tape, but I don't seem to have tape #7. Did such a tape exist?
If so, are there any files on it that were not superseded by tape 8?
I think the tape 8 I have may be wrong. I have the following:
T20 5.1 AP6EXEC SRC MOD 16MT9 ;ap 6
T20 5.1 AP6 MON SRC MOD 16MT9
T20 5.1 AP8 EXEC SRC MOD 16M9 ;ap 8
T20 4.1 AP8 MON SRC MOD 16MT9
Why do I have a 4.1 MON SRC tape for AP8? I do not have a 2020, so
I would not expect to be running rel4. Is this a typo, or what?
Alan
-------
7-Mar-85 17:42:56-PST,710;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 17:42:38-PST
Date: Thu 7 Mar 85 17:41:09-PST
From: David Roode <
[email protected]>
Subject: Re: autopatch tape 8
To:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 7 Mar 85 17:32:43-PST
Location: EJ286 Phone: (415) 859-2774
You do not have a 2020 but the Q number used for our updates
is for the 2020 updates... I sent a message about this problem to the
TOPS-20 list a while back. You have to change Q numbers to get
the non-2020 monitor distribution, and the former Q number
for "current TOPS-20" means "current 2020 TOPS-20."
-------
7-Mar-85 22:11:38-PST,2736;000000000000
Return-Path: <
[email protected]>
Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Mar 85 22:11:25-PST
Date: Thu 7 Mar 85 23:37:14-CST
From: Clive Dawson <
[email protected]>
Subject: Re: TELNET options
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 7 Mar 85 16:53:53-CST
I'm not sure what I have in mind for TELNET is an "option" of the sort
you're talking about, but as long as we're on the subject... The feature
I need is one which will allow selective TELNET listening based on the
particular Internet network requesting the connection. In particular,
I want to be able to reject TELNET requests from over the Arpanet at
certain times, but continue to accept them from our internal Ethernet-based
network. (We're running 5.4 with an NI.) Clearly ^ESET NO LOGIN ARPA
doesn't suffice in this case, since that will reject all TCP connections,
regardless of the network. There are two main approaches we're considering:
1. Add an argument to the ^ESET LOG ARPA command which will accept
a foreign host "mask" specifying who gets let in. This would
in turn cause a new SMON call to pass this arg to the monitor
so that the Internet fork could use it in the OPEN% call when
listening for a Telnet connection. An arg of 0.0.0.0 would
effectively allow anybody in, an arg of 10.0.0.0 would allow
only ARPA hosts, an arg of 192.5.89.0 would allow only our
internal net, etc.
2. Another approach would be to set a bit in the NCT for a given
interface. The FNDNCT routine could then check for the
bit and fail if it wasn't set. This approach isn't quite
as general since it selects based on an entire net rather
than a set of hosts, but would nevertheless meet our need.
Also it is cleaner in the sense that we don't have to keep
be conscious of changing host addresses, etc.
Has anybody out there already solved this problem in some way? In
any case, I'd be interested in hearing comments from anybody on the
best way to do this.
On a more general level, I think Kevin could certainly use feedback from
all of us regarding features of this sort. Many sites are running into
problems like the one above, only in reverse--e.g. how do you keep
users on internal networks off the Arpanet. It would be nice if we
could reach a consensus regarding what the needs are: ability to
restrict gateway functions based on network/host/port in one or
both directions, ability to define a set of "trusted" or "authorized"
hosts on an internal net for which we will do gatewaying, etc. etc.
Cheers,
Clive
-------
8-Mar-85 00:17:43-PST,541;000000000000
Mail-From: BILLW created at 8-Mar-85 00:17:38
Date: Fri 8 Mar 85 00:17:38-PST
From: William "Chops" Westfield <
[email protected]>
Subject: CLZFF misfeature?
To:
[email protected]
CLZFF will abort any existing TCP connections, even if you
specified that only non-open files should be RLJFNed.
This is because there isn't any check for this flag at
CLZFF1 in JSYSF. Can anyone think of a reason that this
test should not be added, and TCP connections be considered
always "open" for this system call?
BillW
-------
8-Mar-85 13:04:58-PST,590;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 8 Mar 85 13:04:43-PST
Date: Fri 8 Mar 85 16:02:31-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: autopatch tape 8
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 7 Mar 85 20:28:29-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
i think tape 8 has a complete set of sources (right?). i do not know if it
is a typo or not. look at the files and i should be obvious.
-------
8-Mar-85 16:04:01-PST,970;000000000000
Mail-From: CRISPIN created at 8-Mar-85 16:03:44
Date: Fri 8 Mar 85 16:03:44-PST
From: Mark Crispin <
[email protected]>
Subject: Andy Sweer's patch to TCPJFN
Sender:
[email protected]
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Andy's patch to TCPJFN will fix the ILLUUO problems. It will also
cause a byte to be lost from the data stream.
The correct fix is NOT to install Andy's patch. Instead, after the
NOP in TCSQI6, insert a SETZRO <BLKF>. You can clear ERRF too if you
want that last byte before the error. The effect of this patch is NEVER
to block if (1) a byte was read but (2) the system can't get another
buffer just yet. Instead, it will return to the user and block the next
time the user does a BIN%. That is of course if there is still a reason
to block.
-- your friendly programmer of pandas.
-------
9-Mar-85 14:07:26-PST,1041;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 9 Mar 85 14:07:21-PST
Date: Sat 9 Mar 85 14:06:54-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: CLZFF misfeature?
To:
[email protected]
cc:
[email protected]
Bill Palmer took a look at this problem a couple of weeks ago. There turned
out to be two bugs involving CZ%NCL in CLZFF%. One was the obvious
non-checking of the flag near CLZFF6.
The less obvious bug was a call to ABTJCS near CLZFF1. The effect is that
everytime you do a CLZFF% on a process that has any active JCN's, those
JCN's are going to get clobbered. Bill developed a patch for ABTJCS that
fixed the CZ%NCL problem. I don't think anything was ever installed in
sources -- the mixing of JCN's and JFN's really messes up the JFN
interface assumptions of TOPS-20.
So, if this bug needs to be fixed, it needs fixing in two places.
I'm still unsure as to why anyone would want the functionality of CZ%NCL.
Kirk
-------
9-Mar-85 22:11:47-PST,1324;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 9 Mar 85 22:11:13-PST
Date: 9 Mar 1985 23:10 MST (Sat)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: "Non-privileged" BUILD wanted
I have two administrator types who want/need the capability to use
BUILD (and perhaps related utilities like ULIST). The catch is that I
don't want to give them WOPR privileges - another case for being able
to subdivide the current all or nothing situation that I doubt will be
available before version 7 (if there is one, and if that item is still
on the list).
So, I'd like to hear from *anyone* who has given some thought to this
problem of providing a non-privileged BUILD, and maybe even has such a
thing in production use. The prefered technique is a BUILD-like user
program that communicates via IPCF to a wheel program that validates
the requestor, does the actual CRDIR%, and logs the action. I have
already rejected group or password access to <ROOT-DIRECTORY> as not
much better than just giving them WOPR privileges in the first place,
and certainly much less secure. (A "non-privileged" ULIST would also
be of interest, but not as high a priority right now.)
--Frank
12-Mar-85 08:40:26-PST,560;000000000000
Return-Path: <EC0N@CMU-CC-TE>
Received: from CMU-CC-TE by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 08:40:09-PST
Date: Tue 12 Mar 85 11:39:38-EST
From: Eric Crane <EC0N%CMU-CC-TE@CMU-CC-TE>
Subject: Difference between FMP and FMPR
To:
[email protected]
Office: Ucc 130 x3568
Secretary: x2638
Someone asked me what the difference between FMP and FMPR are, it seems that
they could not detect any rounding being done. Can any of you explain to me
when and if rounding will take place? How about a small example.
- Thanks
Eric Crane
-------
12-Mar-85 10:04:17-PST,408;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 10:04:07-PST
Date: Tue 12 Mar 85 12:03:49-CST
From: Clive Dawson <
[email protected]>
Subject: FMP vs FMPR
To:
[email protected]
I just picked a couple of numbers and tried it:
1/ 123456,,123457
2/ 3
FMP 1,2 produces 1/ 271705,,175306
FMPR 1,2 produces 1/ 271705,,175307
-------
12-Mar-85 11:01:41-PST,1364;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 11:01:17-PST
Date: Tue 12 Mar 85 13:59:25-EST
From: Jeff Damens <
[email protected]>
Subject: Re: Difference between FMP and FMPR
To: EC0N%
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Eric Crane <EC0N%CMU-CC-TE@CMU-CC-TE>" of Tue 12 Mar 85 11:46:50-EST
When multiplying floating point numbers, two 27-bit mantissas are
multiplied to form a 54-bit product. This product is normalized (ie,
shifted left until its high-order bit is non-zero), and then must be
stored back into 27 bits. FMP truncates after the 27th bit; FMPR
rounds up before truncating. You'll see a difference when multiplying
numbers whose products have significant bits at the left (so
normalization doesn't leave you with a number that only has 27
significant bits) and near bit 28. Here's an example that shows
a difference (my comments are on the right, preceded by an !).
Jeff
@sddt
DDT
$$f
1/ 0 2.0
2/ 0 3.0
fdv 1,2$x
<>
1/ 6.6666666E-01 ! this is 2/3
move 5,1$x ! save a copy here
<>
2! 0.1
fmp 5,2$x ! multiply by .1
<>
fmpr 1,2$x ! multiply by .1 with rounding
<>
1/ 6.6666666E-02 ! the difference crops up in the
5/ 6.6666665E-02 ! last digit
-------
12-Mar-85 16:41:29-PST,1387;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Mar 85 16:41:04-PST
Date: Tue 12 Mar 85 16:36:30-PST
From: Andrew Sweer <
[email protected]>
Subject: Big Buffer Query
To:
[email protected]
It seems like forever that the Big Buffer (TTBBUF) for holding
characters input from front-end controlled TTY lines has been 128 chars
long. This relatively small size mandates the special handling of
lines that that "seem" to be using a disproportinate share of this
resource, either by sending an XOFF or by setting the input speed of
the line to 0 for some period.
My query comes due to the proliferation of what I hear called
"lock step" protocol programs like XMODEM and MACGET which try to
transfer files over active TTY lines in 128 byte packets (actually
132 bytes if you count the header and checksum). These programs want
to send or receive single packets at a time, and wait for an
acknowledgement from the other end for each packet. Clearly, the
special handling referred to above gets in the way of this.
The changes to increase the Big Buffer to, say, 500 chars,
and at the same time allow a single line up to 132 or so chars seem
straightforward enough, but I thought it was worth checking around
to see if anyone else has tried it, successfully or not.
Andy <
[email protected]>
-------
15-Mar-85 11:53:43-PST,536;000000000000
Mail-From: MRC created at 15-Mar-85 11:53:32
Date: Fri 15 Mar 85 11:53:32-PST
From: Mark Crispin <
[email protected]>
Subject: new version of NETSRV
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
Sites using NETSRV's "log file" capability should get the new version
of NETSRV from SCO:<NETSRV> at Score. A bug where the log file could
get locked up (and hence hang all of NETSRV) has been uncovered and
fixed.
-------
17-Mar-85 16:38:14-PST,1716;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 17 Mar 85 16:38:11-PST
Date: Sun 17 Mar 85 16:38:47-PST
From: Kirk Lougheed <
[email protected]>
Subject: Passwords and 6.0
To:
[email protected]
cc:
[email protected]
One of the hazards in going to a 6.0 system has to do with how password is
handled. From telneting over to CSLI, it appears that they've been having
problems in that respect. This note describes how to fix matters.
Kirk
--------
The format of the directory page is slightly different betweeen Stanford
Release 5 and Release 6 monitors. The principle difference is in how
passwords are flagged as encrypted. Under Release 5 we used a bit in the
CDMOD word; under Release 6 a new version word has been added.
After you've booted the 6.0 system and have managed to login by patching the
LOGIN% JSYS, you need to perform the following actions to make the password
checker interpret the passwords correctly.
Run the new CHECKD and give the following command:
CHECKD>enable password-encryption ps:
Then get into MDDT and patch the location SUFCNV to be -1. It should be
zero beforehand. The SUFCNV cell enables some code in CRDIR% (see JSYSF) to
convert the directory page. Then get a copy of FLUSH.EXE from Sierra
(source is PS:<SU-UTILITIES>FLUSH.FAI) and give the following command:
FLUSH>convert ps:
When FLUSH finishes, your 5.3 filesystem has been converted to 6.0 format.
It is possible to roll back; read the code in JSYSF.
The above procedure is believed to work. Caution is advised, however.
It might be prudent to run DLUSER before mangling your filesystem.
-------
17-Mar-85 19:02:40-PST,863;000000000000
Mail-From: BILLW created at 17-Mar-85 19:02:38
Date: Sun 17 Mar 85 19:02:38-PST
From: William "Chops" Westfield <
[email protected]>
Subject: finger enhancements
To:
[email protected]
I made a couple of changes to FINGER:
/PHYSICAL-LOCATIONS will list Tip names and port numbers
and so on always (/REAL-LOCATIONS used to do this apparently)
This is useful to the people installing and/or fixing
peoples terminal lines, among others.
/WHOIS will now cause a persons plan file to be listed, even
if they are logged in. F/WHOIS<cr> will type the plan files
of everyone logged in... (precedent: MITs finger does this, sort of)
There was also a bug fix to a bug that normally wouldn't show
up since not much was done after a PNTPLN was called.
sources on SCORE in PS:<FINGER.SOURCES>FINGER.MAC
BillW
-------
19-Mar-85 23:29:51-PST,1001;000000000000
Mail-From: MRC created at 19-Mar-85 23:29:36
Date: Tue 19 Mar 85 23:29:35-PST
From: Mark Crispin <
[email protected]>
Subject: New Orleans DECUS
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
I got my copy of the New Orleans DECUS symposium registration kit
and preliminary program. Not only is the price up (now $300 for 5
days), but the hotels are even more expensive than ever (the cheapest
is $74/night) with a $75 deposit.
Then there's the write-up for Large Systems; a tiny 9-liner talking
about the "renewed emphasis on traditional technical sessions" and
"integration sessions for those of us who are converting to VAX/VMS."
It's the smallest SIG writeup in the program.
There are no large systems sessions at all on Friday. The Town Meeting
is a mere 1 hour; most of the sessions are migration-to-VMS sessions.
There is a 1-hour TCP/IP session, however.
-------
20-Mar-85 07:12:18-PST,890;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Mar 85 07:12:09-PST
Date: Wed, 20 Mar 85 15:13 GMT
From: SAMUELSON%
[email protected]
Subject: Re: Connecting Supercomputers to DEC's Cluster Systems
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: Powell@DEC-MARLBORO.ARPA,
tops-20@SU-SCORE.ARPA,
info-vax@SRI-KL.ARPA
In-Reply-To: Message from "Reed B. Powell <POWELL at DEC-MARLBORO>" of Mon 4 Mar 85 12:37:00-PST
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
Since, as you noted, most CRAY sites use HYPERCHANNEL to connect
their CRAYs to each other, you should come up with an interface
from the CI to the HYPERCHANNEL, not try to replace the Hyperchannel.
- Sam -
-------
20-Mar-85 15:12:49-PST,1148;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Mar 85 15:12:17-PST
Date: Wed 20 Mar 85 19:11:27-AST
From: Peter Gergely <
[email protected]>
Subject: Modifications to BBOARD.MAC
To:
[email protected]
I have made some extensions to BBOARD.MAC (based upon edit 67,
22 Oct 82 UT version). These include:
- Allowing the use of wildcards in the bulletin board file
specs omitting any repeats. For example:
BBOARD BBD:,SYSTEM:,*
would try to read BBD:MAIL,SYSTEM:MAIL, and all BBD:*.TXT files
excluding BBD:MAIL as it has already been used.
- Putting the subject on a separate line, if the date, author,
and subject fields will exceed a width of 72 columns.
- A blank line between messages.
- Fixing /ACTION so that the "Reading ..." message always starts
on a new line.
Availability:
The file PS:<ANONYMOUS>BBOARD.MAC is available using ANONYMOUS FTP from
DREA-XX. Note: NIC host tables 433 and greater list DREA-XX.
The code is commented by .DREA.,.CRLF., and .WJFN. switches, and
comments beginning with [PJG].
Peter J. Gergely
-------
20-Mar-85 20:30:15-PST,1251;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Mar 85 20:30:04-PST
Date: 20 Mar 1985 21:29 MST (Wed)
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: Peter Gergely <GERGELY@DREA-XX>
Cc: tops-20@SU-SCORE, WANCHO@SIMTEL20
Subject: Modifications to BBOARD.MAC
In-reply-to: Msg of 20 Mar 1985 16:11-MST from Peter Gergely <GERGELY at DREA-XX.ARPA>
Peter,
I'm glad to see that this program is not dead yet. I also made the
minor change to present the header, but as a real header: From: and
Subject: on separate lines all the time.
Now all we need is someone to make BBOARD use the same "last message
read" files as MM's BBOARD command uses and we'd be all ahead of the
game. The reason is that neither knows about the other's database,
and popping "down" to MM from BBOARD produces inconsistent results as
to which was the last message seen by which program, and ends up
confusing the user. I use a third interface and neither of those two
programs. BABYL's BBOARD uses the user's SWITCH.INI file to keep
track of things... But, I'll settle for two-way consistency between
BBOARD and MM's BBOARD.
--Frank
21-Mar-85 03:20:58-PST,664;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 03:20:48-PST
Date: Thu 21 Mar 85 07:20:10-AST
From: Peter Gergely <
[email protected]>
Subject: Further Extension to BBOARD
To:
[email protected]
Effective with this message, is one more change to BBOARD.MAC.
It is the addition of the "X" command, to "Exit BBOARD, skipping all
remaining bulletin boards". As per the "E" or "Q" command, nothing is
updated from that point on, so you will get to see the bulletin boards
again if requested.
It is available as PS:<ANONYMOUS>BBOARD.MAC, via ANONYMOUS FTP
to DREA-XX.
- Peter
-------
21-Mar-85 06:22:08-PST,1096;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 06:21:58-PST
Date: Thu, 21 Mar 85 14:19 GMT
From: SAMUELSON%
[email protected]
Subject: Re: Modifications to BBOARD.MAC
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: WANCHO@SIMTEL20.ARPA,
Gergely@drea-xx.arpa,
tops-20@SU-SCORE.ARPA
In-Reply-To: Message from ""Frank J. Wancho" <
[email protected]>" of Wed 20 Mar 85 21:29:00-PST
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
I will second Wancho's request that somebody, somewhere, please make
BBOARD and MM use the same file for keeping track of which messages
have been read. While anyone is working on BBOARD, the one addition
that would make BBOARD easier to live with would be some way to tell
it to clear the screen after you say you want to read a message, just
before it starts to type it. Scrolling thru bboards is hard on the
eye muscles.
- Sam -
-------
21-Mar-85 11:24:17-PST,351;000000000000
Mail-From: MRC created at 21-Mar-85 11:22:45
Date: Thu 21 Mar 85 11:22:45-PST
From: Mark Crispin <
[email protected]>
Subject: host tables
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
It's time to increase NHOSTS again! Sigh!
-------
21-Mar-85 13:04:11-PST,1187;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 13:03:53-PST
Date: Thu 21 Mar 85 14:03:41-MST
From: Mark Crispin <
[email protected]>
Subject: avoiding increasing NHOSTS
To:
[email protected]
Problem:
NHOSTS again. Once again the NIC table has outgrown
TOPS-20.
Diagnosis:
The actual host table is 2.25 times larger than the space
used. Only the name space is too small. The calculation of the
name space, based on NHOSTS, is much too conservative. Back in
HSTNAM.TXT days it was appropriate but no longer.
Solution:
In STG.MAC, replace the line:
NDG NHSTN,<NHOSTS*3> ;LENGTH OF HOST NAME TABLE (TEXT)
with:
NDG NHSTN,<NHOSTS*6> ;LENGTH OF HOST NAME TABLE (TEXT)
If you are worried about GTHST% performance it may be a bit
too drastic to use NHOSTS*6 and perhaps NHOSTS*5 would be better.
I think NHOSTS*6 should be alright because at the current NIC
ratio of name sizes to addresses you would still have 12.5% hash
table free space. Right now there is more like 56% hash free
space which is much more than really needed.
Mark Crispin
PANDA PROGRAMMING
-------
21-Mar-85 13:30:35-PST,479;000000000000
Return-Path: <
[email protected]>
Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 13:29:57-PST
Date: Thu 21 Mar 85 13:28:08-PST
From: Richard Furuta <
[email protected]>
Subject: Anyone have an ANSI tape utility?
To:
[email protected]
cc:
[email protected]
I need a utility to allow me to write ANSI labeled tapes, playing
with things like blocking factors, etc. Anyone have one I could have?
Thanks.
--Rick
-------
21-Mar-85 14:08:00-PST,1902;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 14:07:37-PST
Date: 21 Mar 1985 1659-EST
From: Tom Blinn <BLINN at DEC-MARLBORO>
To: Furuta at WASHINGTON, tops-20 at SU-SCORE
Subject: Re: Anyone have an ANSI tape utility?
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12096875040.17.275.17060 at DEC-MARLBORO>
Regarding: Message from Richard Furuta <
[email protected]>
of 21-Mar-85 1642-EST
One approach is to use the TOPS-20 EXEC.
I assume you wish to write regular text files, i.e., stream ASCII,
onto the tapes, and wish to try different blocksizes.
First, get the tape initialized to have ANSI labels, and mount it
for WRITE access. Use, e.g., MT: as the logical name when you
mount the tape. Then define a logical name as the destination
for copying, e.g.,
DEFINE TAPE: MT:*.*.*;FORM:D;RECORD:nnn;BLOCK:mmm
where "nnn" is at least 4 greater than the longest record in the
source files (e.g., 132 if the source lines are at most 128 bytes,
exclusive of the delimiting CR-LF), and "mmm" is the blocksize you
want to use. Then just use the COPY command, with a possibly wild-
carded input disk file and TAPE: as the destination.
(If you let the destination generation default to .-1 as it normally
does for disk files, then every file on the tape will have its
generation number field be the 6-digit decimal value that is 777777
octal, i.e., halfword -1.)
This writes variable-length records on the tape. If you want fixed-
length files, the file on disk must be fixed-length, that is, every
record exactly the number of bytes to be written onto the tape, and
the file's size an exact multiple of the number of bytes in a record.
Try it, you should like it. The secret to success is specifying the
attributes on the destination file specification.
Tom
--------
21-Mar-85 16:58:39-PST,1066;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 16:58:20-PST
Date: Thu 21 Mar 85 17:57:59-MST
From: Mark Crispin <
[email protected]>
Subject: NHOSTS retraction
To:
[email protected]
Contrary to my previous message, the problem is not in the
host name string space. The problem is that there are too many
host names!
Specifically, in the current NIC table there are 1867
addresses and a whopping 4035 names. Surprisingly, those names
only require 10220 words of string space (all numbers decimal
here), so the present setting of NHSTN=3*NHOSTS or KWP's new
setting of NHSTN=4*NHOSTS is quite enough for the present.
The right thing to do is to increase the size of the HOSTN
table, to be, say, 2*NHOSTS. You will also have to modify the
HSTINI routine in MNETDV to know that HOSTN is bigger than the
other tables.
This should allow for a doubling of the NIC table without
increasing NHOSTS from the present 4001.
Mark Crispin
PANDA PROGRAMMING
-------
21-Mar-85 19:43:31-PST,580;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 19:43:09-PST
Date: 21 Mar 1985 19:40:53 PST
Subject: Re: Anyone have an ANSI tape utility?
From: Bob Knight <
[email protected]>
To: Richard Furuta <
[email protected]>
cc:
[email protected]
In-Reply-To: (Message from "Richard Furuta <
[email protected]>" of Thu 21 Mar 85 13:28:08-PST)
Stanford has a utility, TAPEIO, that will tickle you pink. Perhaps Kirk
Lougheed or Bill Westfield could direct you to an FTPable copy.
Bob
-------
21-Mar-85 20:08:35-PST,584;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 20:08:26-PST
Date: 21 Mar 1985 19:59:50 PST
Subject: Re: Anyone have an ANSI tape utility?
From: Bob Knight <
[email protected]>
To:
[email protected]
In-Reply-To: <"MS10(2124)-1+GLXLIB1(1135)" 12096875040.17.275.17060 at DEC-MARLBORO>
Tom's method will work if you have a TM02. However, I do not believe that
the TM03 and TM78 support ANSI-ASCII transfers. Also, if you don't run a
labelled shop, you'll generate a non-labelled tape.
Bob
-------
21-Mar-85 21:39:58-PST,1548;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Mar 85 21:39:46-PST
Date: Fri 22 Mar 85 00:39:48-EST
From: Ken Rossman <
[email protected]>
Subject: Re: Anyone have an ANSI tape utility?
To:
[email protected],
[email protected]
In-Reply-To: Message from "Bob Knight <
[email protected]>" of Thu 21 Mar 85 19:59:50-EST
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
A TM02 is not required to write a standard ANSI-ASCII tape. The ANSI-ASCII
TM02 hardware mode is really just a convenience, and I assume was
eliminated in later versions of tape controllers because it was, in fact
unnecessary. Industry-Compatible mode will do just fine for any tape you
might need to write, since it is capable of reading and writing every bit
in each frame, though some software munging may be necessary.
I personally don't like to use the EXEC for this type of transfer because I
am never quite sure what I'll end up with on the tape. It's never been
obvious to me what the effect of setting different hardware modes, and
using the ASCII or BYTE n subcommands will do.
There are certainly more than a few ANSI tape reader/writer programs
around, some of which provide a few other conveniences in addition to being
able to write the basic tape. TAPEIO is one example -- it covers quite a
range of different tape formats. We use here, I believe, some variation on
a set of programs by Hedrick to write our ANSI Kermit tapes. /Ken
-------
22-Mar-85 00:16:43-PST,1281;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 00:16:21-PST
Date: Fri 22 Mar 85 01:16:10-MST
From: Mark Crispin <
[email protected]>
Subject: NHOSTS: the final word
To:
[email protected]
I doubled the size of HOSTN to 2*NHOSTS (I called this size NHOSTN)
and fixed HSTINI in MNETDV to use this size and tested it at SIMTEL20. It
works like a champ. While I was at it I replaced the loop in HSTINI that
zeros the various tables with a BLT.
The comments are somewhat confusing in HSTINI and STG. Basically,
HOSTN is *not* a hashed table. HOSTNN is, and HOSTPN and HSTSTS are
parallel to this table. HOSTN entries are in the form
BYTE(1)NicknameFlag(17)HSTNAMindex(18)HashIndex
NicknameFlag is set if this name is a nickname
HSTNAMindex is the index into the HSTNAM (host name string space) area
with the name this entry is for
HashIndex is the index into the various parallel hash tables
With this change in place, you can essentially leave NHOSTS set
at the present ^D4001 until the NIC table approximately doubles in size.
What was running out was not the number of hash slots (only 1867 were
in use) but rather the number of names (NIC table 435 has 4035 names).
-------
22-Mar-85 00:29:23-PST,375;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 00:29:04-PST
Date: Fri 22 Mar 85 00:27:40-PST
From: David Roode <
[email protected]>
Subject: IDDT for extended addressing
To:
[email protected]
Location: EJ286 Phone: (415) 859-2774
Has anyone got a modified IDDT to support section addressing?
-------
22-Mar-85 03:18:01-PST,611;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 03:17:52-PST
Date: 22 Mar 1985 0612-EST
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>
To: furuta at WASHINGTON
cc: Tops-20 at SU-SCORE
Subject: Re: Anyone have an ANSI tape utility?
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12097019383.20.249.34685 at DEC-MARLBORO>
The "Rutgers Pascal-based" programs [short and sweet - readable code and
predictable functionality] from Chuck Hedricks are here in TOPS:READ%.*
and TOPS:WRITE%.* - [via anonymous ftp]
Bernie
--------
22-Mar-85 10:26:45-PST,461;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 10:26:33-PST
Received: ID <
[email protected]>; Fri 22 Mar 85 13:26:16-EST
Date: Fri 22 Mar 85 13:26:12-EST
From:
[email protected]
Subject: DTE question
To:
[email protected]
Does anyone know if the DTE will accept an 1-word global byte pointer? In
particular, will giving DTEQ a 1-word global byte pointer work?
--Vince
-------
22-Mar-85 12:52:19-PST,505;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 22 Mar 85 12:52:00-PST
Date: Fri 22 Mar 85 15:50:55-EST
From:
[email protected]
Subject: Re: DTE question
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Fri 22 Mar 85 13:31:24-EST
Nope, the DTE hardware will not accept a one-word global byte pointer. DTEQ
won't accept one either.
Stu Grossman
-------
25-Mar-85 10:14:41-PST,626;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Mar 85 10:14:22-PST
Date: Mon 25 Mar 85 13:09:58-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: DTE question
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Fri 22 Mar 85 13:31:17-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
i do not know if a owgbp will work but I do know that the dte
can not talk to sections other than zero so there is probably
not a good reason to use owgbps.
-------
27-Mar-85 10:54:17-PST,4220;000000000001
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 27 Mar 85 10:53:05-PST
Date: 27 Mar 1985 13:51-EST
Sender:
[email protected]
Subject: ADJBP Fails
From:
[email protected]
To:
[email protected]
Message-ID: <[BBNA.ARPA]27-Mar-85 13:51:41.CLYNN>
Has anyone else observed failures of the ADJBP instruction with global
one-word 8-bit byte pointers which should generate a final pointer of
the form "6000<ss>,,<adr>", when following a DPB instruction using the
same byte pointer, without an intervening memory write? It happens on
all three of our TOPS20's, two of which are using microcode version
326. If an instruction which writes into memory is placed between the
DPB and ADJBP, it works; it might thus be a cache or microcode bug.
It also fails if the byte pointer is in a register.
I.e., DPB 4,200 fails but DPB 4,200 works
ADJBP 4,200 MOVES 500
ADJBP 4,200
Initial BP Count Final BP Correct BP
540020,,1005 13 570020,,1010 570020,,1011
550020,,1005 13 20,,1012 600020,,1011 (540020,,1012)
Below is a log showing the bug from ddt running in section 1.
Charlie
------------------------------
TOPS-20 Command processor 5(725)-1
$get adjBP-BUG.EXE.1 ; a saved ddt
$i mem
11. pages, Entry vector loc 1,,770000 len 1
Section 0 R, W, E, Private
Section 1 R, W, E, Private
1000 ADJBP-BUG.EXE.1 1 R, CW, E
1766 ADJBP-BUG.EXE.1 2 R, CW, E
1770-1777 ADJBP-BUG.EXE.1 3-12 R, E
Section 20 R, W, E, Private
20001 ADJBP-BUG.EXE.1 13 R, CW, E
$start
DDT
1,,76[ 13 ; initial count
1,,200[ 550020,,1005 ; initial byte pointer
20,,1005[ 26000,,0 ; where it points
1,,100/ IBP 200 ; move pointer each time
1,,101/ JFCL 0
1,,102/ MOVE 4,76 ; count for ADJBP
1,,103/ DPB 4,200 ; use the pointer
1,,104/ IBP 4,200 ; ADJBP that fails
1,,105/ JFCL 0 ; end
1,,105$b 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1010 100$g
$2B>>1,,105/ JFCL 0 4[ 560020,,1010 100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1010 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1011 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1011 100$g
$2B>>1,,105/ JFCL 0 4[ 560020,,1011 100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1011 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1012 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1012
76[ 13 12 ; change count to 12
100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1012 100$g
$2B>>1,,105/ JFCL 0 4[ 560020,,1012 100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1012 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1013 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1013 100$g
$2B>>1,,105/ JFCL 0 4[ 560020,,1013 100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1013 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1014 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1014
76[ 12 377 ; try a big number
100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1111 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1112 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1112 100$g
$2B>>1,,105/ JFCL 0 4[ 560020,,1112 100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1112 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1113 100$g
$2B>>1,,105/ JFCL 0 4[ 550020,,1113 100$g
$2B>>1,,105/ JFCL 0 4[ 560020,,1113 100$g
$2B>>1,,105/ JFCL 0 4[ 570020,,1113 100$g
$2B>>1,,105/ JFCL 0 4[ 20,,1114
; force a memory write
1,,100/ IBP 200 ; move pointer each time
1,,101/ JFCL 0
1,,102/ MOVE 4,76 ; count for ADJBP
1,,103/ DPB 4,200 ; use the pointer
1,,104/ IBP 4,200 MOVES 500 ; force memory write
1,,105/ JFCL 0 ADJBP 4,200 ; ADJBP that works
1,,106/ 0 JFCL
$b 0$2b
100$g
$3B>>1,,106/ JFCL 0 4[ 550020,,1114 100$g
$3B>>1,,106/ JFCL 0 4[ 560020,,1114 100$g
$3B>>1,,106/ JFCL 0 4[ 570020,,1114 100$g
$3B>>1,,106/ JFCL 0 4[ 600020,,1114 100$g
$3B>>1,,106/ JFCL 0 4[ 550020,,1115 100$g
$3B>>1,,106/ JFCL 0 4[ 560020,,1115 100$g
$3B>>1,,106/ JFCL 0 4[ 570020,,1115 100$g
$3B>>1,,106/ JFCL 0 4[ 600020,,1115 100$g
$3B>>1,,106/ JFCL 0 4[ 550020,,1116
^Z
$
27-Mar-85 13:35:12-PST,599;000000000001
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 27 Mar 85 13:34:22-PST
Date: Wed 27 Mar 85 16:29:53-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: ADJBP Fails
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Wed 27 Mar 85 13:51:00-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
your microcode is out of date. new microcode should be showing up in the
rsx20f that was shipped recently. this is likely to be fixed in that microcode.
-------
28-Mar-85 13:36:43-PST,430;000000000000
Mail-From: BILLW created at 28-Mar-85 13:36:32
Date: Thu 28 Mar 85 13:36:32-PST
From: William "Chops" Westfield <
[email protected]>
Subject: new DOVER.MAC
To:
[email protected]
Ive modified dover so that the /PAGES switch should work
even on press format files. It seems to work, although
so far no complicated press files have been sent through
it. The new source is SCO:<PUP>DOVER.MAC.71
BillW
-------
28-Mar-85 21:50:04-PST,1382;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 28 Mar 85 21:47:36-PST
Date: Thu 28 Mar 85 22:47:35-MST
From: Mark Crispin <
[email protected]>
Subject: PHYH2 bug - ILLGO bug halts
To:
[email protected]
Problem:
With KWP's patch for systems with 4MW of memory installed in
PHYH2, SIMTEL20 (a 512K 2040) gets ILLGO bug halts.
Diagnosis:
There is a path by which read w/ validity check is called
for page 0 which really is a no-op (your homework: find this
path). The ILLGO code checks for this path and ignores it. The
4MW patch breaks it.
Solution:
In PHYH2, replace the following section of code in CKERR2:
CAME T3,T4 ;BETTER BE THE SAME
JRST [ LDB T1,IRYFCN ;GET THE FUNCTION CODE
CAIN T1,IRFRVC ;READ VALIDITY?
AOSE T3 ;WAS IT FOR PAGE 0 (SKIP FUNCTION)?
BUG(ILLGO)
RETSKP] ;HERE IF READ VALIDITY, AND PAGE 0
RETSKP ;NO
with this code (note that this also incorporates KWP's patch):
ANDX T3,17777 ;CATCH OVERFLOW FROM LAST PHYSICAL MEMORY PAGE
CAMN T3,T4 ;BETTER BE THE SAME
IFSKP.
LOAD T3,LG2DBP,T1 ;GET PAGE NUMBER FROM LOGOUT AGAIN
LDB T1,IRYFCN ;GET THE FUNCTION CODE
CAIN T1,IRFRVC ;READ VALIDITY?
SKIPE T3 ;WAS IT FOR PAGE 0 (SKIP FUNCTION)?
BUG(ILLGO)
ENDIF.
RETSKP ;NO
Mark Crispin
PANDA PROGRAMMING
-------
29-Mar-85 06:11:37-PST,2111;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 06:09:30-PST
Received: from ddxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP
id a005714; 29 Mar 85 14:29 BST
Via: DCT; by DUNDEE on Friday, 29-Mar-85 13:02:28-GMT
Date: Fri 29 Mar 85 12:56:56-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: Aborting mapped pages in KSELF
To:
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Midway through version 4 of TOPS20 a change was introduced by an autopatch
tape (one of the very few that DEC ever bothered to send us) that caused
a lot of our applications programs (and more importantly games) to stop
running correctly. The symptom was that any program that shared memory
through pmap'd files would randomly crash. I tracked this down to a change
in the kill self routine. The addition of the bit pm%abt to a pmap and smap
call to be precise. As far as I can remember there was never an spr for which
this was a fix for. The comment on the autopatch tape I think said something
like
"No problem observed but it might be possible for bad pages to be mapped
to a file..."
The trouble is that when any programs are (for example) emulating a TOPS10
shareable writeable high segment (eg Essex University's MUD) by pmaping in
the high segment pages from a file opened with read/write/thaw/don't update
disk then if one is killed (say by being logged out or CTRL/C reset) then
the monitor drags in the pages back from the original disk copy for every
one still sharing these pages. ie all the data is reinitialised.
At the time I decided there was no point in submitting an SPR assuming
someone else would submit one. Well all this was about 3 years ago and
the problem still exists. It only recently came to light again with the
increased use of shared file programs here. I've ran versions 4,5 and 5.1
with the following patch installed
@get system:monitr.exe
ddt
ksef0+4/<tab>400200,,1000
clnzs1+6/<tab>1
29-Mar-85 07:02:41-PST,926;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 07:00:47-PST
Date: Fri 29 Mar 85 09:53:42-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: PHYH2 bug - ILLGO bug halts
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Fri 29 Mar 85 00:51:35-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
it doesn't matter. the mbox cannot handle channel writes to the last
quadword of the 22 bit physical address. parity errors will result and
corrupted files also. this is going to become a permanent restriction
in the kl and the diagnostics are also being changed accordingly.
the easiest patch is to set nmaxpg to be 17,,777776 instead of 17,777777.
4mw is only supported in rel 6.1 at this time. 6.0 only supports 3.0
meg of memory.
-------
29-Mar-85 10:38:01-PST,826;000000000001
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 10:35:54-PST
Date: 29 Mar 1985 1325-EST
From: Alan H. Martin <AMARTIN at DEC-MARLBORO>
To: CLYNN at BBNA, TOPS-20 at SCORE
DTN: 231-4528
Mail-Stop: MR1-2/L14
Office-location: "MR1-2/M8 (By the cat posters)"
Subject: Re: ADJBP Fails
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12098933210.29.659.23813 at DEC-MARLBORO>
The bug is visible in KL microcode V1(326), which is what has been in
the field for a while. It is fixed in V1(357), which is in SDC, and
is anticipated to be shipping Real Soon Now. V1(357) is for 5.1
monitors; the microcode for later monitors also does not show the bug.
Thanks for reporting the problem, we were glad to find that it was fixed.
/AHM/THX
--------
29-Mar-85 11:28:15-PST,2570;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 11:26:46-PST
Received: from ddxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP
id a006809; 29 Mar 85 17:39 BST
Via: DCT; by DUNDEE on Friday, 29-Mar-85 16:31:12-GMT
Date: Fri 29 Mar 85 12:56:56-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: Aborting mapped pages in KSELF
To:
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
[The end of this got lost somewhere on the first mailing. Here goes again]
Midway through version 4 of TOPS20 a change was introduced by an autopatch
tape (one of the very few that DEC ever bothered to send us) that caused
a lot of our applications programs (and more importantly games) to stop
running correctly. The symptom was that any program that shared memory
through pmap'd files would randomly crash. I tracked this down to a change
in the kill self routine. The addition of the bit pm%abt to a pmap and smap
call to be precise. As far as I can remember there was never an spr for which
this was a fix for. The comment on the autopatch tape I think said something
like
"No problem observed but it might be possible for bad pages to be mapped
to a file..."
The trouble is that when any programs are (for example) emulating a TOPS10
shareable writeable high segment (eg Essex University's MUD) by pmaping in
the high segment pages from a file opened with read/write/thaw/don't update
disk then if one is killed (say by being logged out or CTRL/C reset) then
the monitor drags in the pages back from the original disk copy for every
one still sharing these pages. ie all the data is reinitialised.
At the time I decided there was no point in submitting an SPR assuming
someone else would submit one. Well all this was about 3 years ago and
the problem still exists. It only recently came to light again with the
increased use of shared file programs here. I've ran versions 4,5 and 5.1
with the following patch installed
@get system:monitr.exe
ddt
ksef0+4/<tab>400200,,1000
clnzs1+6/<tab>1
^Z
@save system:monitr
which simply turns off the pm%abt bit as tops20 behaved in virgin release
4 and before. I havn't noticed any ill efects but it bothers me slightly
that the change was originally made for a reason. Has anyone else experienced
this problem or developed a more general soloution, eg abort pages if file
not shared, otherwise don't ?
Alan
-------
29-Mar-85 11:31:04-PST,2570;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from Ucl-Cs by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 11:29:33-PST
Received: from ddxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP
id a006826; 29 Mar 85 17:40 BST
Via: DCT; by DUNDEE on Friday, 29-Mar-85 16:40:22-GMT
Date: Fri 29 Mar 85 12:56:56-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: Aborting mapped pages in KSELF
To:
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
[The end of this got lost somewhere on the first mailing. Here goes again]
Midway through version 4 of TOPS20 a change was introduced by an autopatch
tape (one of the very few that DEC ever bothered to send us) that caused
a lot of our applications programs (and more importantly games) to stop
running correctly. The symptom was that any program that shared memory
through pmap'd files would randomly crash. I tracked this down to a change
in the kill self routine. The addition of the bit pm%abt to a pmap and smap
call to be precise. As far as I can remember there was never an spr for which
this was a fix for. The comment on the autopatch tape I think said something
like
"No problem observed but it might be possible for bad pages to be mapped
to a file..."
The trouble is that when any programs are (for example) emulating a TOPS10
shareable writeable high segment (eg Essex University's MUD) by pmaping in
the high segment pages from a file opened with read/write/thaw/don't update
disk then if one is killed (say by being logged out or CTRL/C reset) then
the monitor drags in the pages back from the original disk copy for every
one still sharing these pages. ie all the data is reinitialised.
At the time I decided there was no point in submitting an SPR assuming
someone else would submit one. Well all this was about 3 years ago and
the problem still exists. It only recently came to light again with the
increased use of shared file programs here. I've ran versions 4,5 and 5.1
with the following patch installed
@get system:monitr.exe
ddt
ksef0+4/<tab>400200,,1000
clnzs1+6/<tab>1
^Z
@save system:monitr
which simply turns off the pm%abt bit as tops20 behaved in virgin release
4 and before. I havn't noticed any ill efects but it bothers me slightly
that the change was originally made for a reason. Has anyone else experienced
this problem or developed a more general soloution, eg abort pages if file
not shared, otherwise don't ?
Alan
-------
29-Mar-85 16:38:21-PST,878;000000000000
Return-Path: <
[email protected]>
Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 16:36:31-PST
Date: Fri 29 Mar 85 16:37:23-PDT
From:
[email protected]
Subject: Request for info on Graduate Programs
To:
[email protected]
I am trying to find out what Universities offer graduate programs, preferably
in the Computer Science Department, but possibly in the Business Department,
in the Management of Computer Resources. Such titles as Data Center Management,
Computer Center Management, Data Systems Management, etc. would probably be
the type of program I am looking for. Or perhaps there are MS programs in
Computer Science with a management bias. I would be particularly grateful for
evaluative comments but any information would be appreciated. Please respond
directly to my mailbox: Dante@Edwards-2060.
-------
29-Mar-85 17:29:35-PST,775;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 17:28:01-PST
Date: Fri 29 Mar 85 18:26:52-MST
From: Mark Crispin <
[email protected]>
Subject: Re: PHYH2 bug - ILLGO bug halts
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Kevin Paetzold <
[email protected]>" of Fri 29 Mar 85 08:00:48-MST
I want to make sure that nobody gets confused by the exchange of
messages between KWP and myself. If you want to install the patch for
4MW of memory, you will also need my patch. Given the latest information
from Kevin, I think it is probably best not to install the original patch
(the ANDI T3,17777) at all, since it is capable of causing ILLGO bughlts.
-------
29-Mar-85 18:00:26-PST,2003;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Mar 85 17:59:45-PST
Date: Fri 29 Mar 85 18:59:38-MST
From: Mark Crispin <
[email protected]>
Subject: Re: Aborting mapped pages in KSELF
To: CCD-ARG%
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Alan Greig <CCD-ARG%
[email protected]>" of Fri 29 Mar 85 13:19:56-MST
Alan -
The PM%ABT bit only makes a difference if OF%DUD is set. What it
is trying to do is this: Suppose you have an application program which
manipulates a database file by pmapping its pages into memory and then
manipulating memory. To be safe, it opens the file OF%DUD because if
the system crashes in the middle of all of this an inconsistant copy
will be left on this disk, with some pages updated and some not. An
UFPGS% is done when things are in a good state, and the application tells
the monitor to update all the necessary pages. MM is one of many programs
which works this way.
Now, suppose you run such a program, and for reasons known only to
you you CTRL/C out and reset the fork. If the application was in the
middle of some critical update the pages would normally be written to
the disk, causing a disaster. MM tries to avoid this problem by disabling
CTRL/C interrupts during the EXPUNGE and "replace message" routines which
move messages around (as opposed to commands such as DELETE which merely
update a bit in place).
Many programs don't have CTRL/C traps, and even more are so critical
that even that isn't adequate protection. So the monitor tries to help
by aborting pages which were OF%DUD.
It isn't clear to me what the right thing to do in this case. The
problem is that I can think of cases where aborting the pages is the
right thing; consider a shared database where interactions are done via
ENQ%. My suggest would be to do a UFPGS% at the end of each major
interaction, and use ENQ% if you aren't already.
-------
30-Mar-85 05:56:05-PST,779;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 30 Mar 85 05:52:04-PST
Date: Sat 30 Mar 85 08:45:25-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: PHYH2 bug - ILLGO bug halts
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Fri 29 Mar 85 20:26:30-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
you should not install any of the 4.0 meg patches. it is not a good idea to
fix problems that you do not have. 4.0 meg is not supported by tops-20 at
this time unless you are running 6.1. in addition to software problems there
are cpu problems in the mbox and channel/rh20 problems to overcome.
-------
30-Mar-85 10:27:55-PST,1704;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Sat 30 Mar 85 10:26:43-PST
Date: 30 Mar 1985 1321-EST
From: Tom Blinn <BLINN at DEC-MARLBORO>
To: MRC at SIMTEL20, CCD-ARG%dct at UCL-CS
cc: TOPS-20 at SU-SCORE
Subject: Re: Aborting mapped pages in KSELF
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12099194611.18.275.28529 at DEC-MARLBORO>
Regarding: Message from Mark Crispin <
[email protected]>
of 29-Mar-85 2101-EST
Mark, you've done a very good job of clarifying the reasons for TOPS-20's
behavior when a program that has a file opened for thawed update with
OF%DUD set gets into trouble when the file gets closed/aborted and the
user expects the file to contain the modified data.
In this case, TOPS-20 is doing the right thing. The problem arises due
to the applications attempting to mimic a TOPS-10 feature (shared writable
high segments, hence shared memory among independent jobs) by using TOPS-20
file system features in a way that does not give identically the same
results.
If no-one opens the file OF%DUD (since it really doesn't matter if the
disk copy of the file gets updated, other than the increase in the disk
and swapping traffic, for this particular case), then when someone gets
blown away (e.g., by being reset after ^C or by being logged out), TOPS-20
won't bother to re-set the in-memory file pages (still shared by other
users of the file) from disk.
For this particular case, changing to use UFPGS% will probably be less
good, since that actually FORCES the file pages out to disk. Simply
letting DDMP do it should be more efficient, overall.
Regards,
Tom
--------
31-Mar-85 02:42:07-PST,1794;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Mar 85 02:41:56-PST
Date: Sun 31 Mar 85 02:42:32-PST
From: Kirk Lougheed <
[email protected]>
Subject: Fix for TCP-related system hangs
To:
[email protected]
Problem:
Internet system hangs, typically with many fork lock timeout bugchks.
Diagnosis:
The fork lock timeouts are being generated every time a fork does a
RESET%. Part of the RESET% code tries to abort JCN's. To do this, the
process must obtain the TCB hash lock (TCBHLK). The hash lock appears
to be overly incremented, hence it is never "released" so that other
processes can have their turn.
It turns out that the Internet background fork is one who owns the lock.
If you look closely at a dump of a hung system, the Internet fork is
busily chasing down a infinite loop of zero pointers on page zero of the
Internet section. It appears that someone called NQ with a nil item
pointer. This piece of detective work comes from Chris Maio of Columbia
University.
Next step is to insert a debugging bughlt at NQ to catch the culprit.
Tracing through the stack, we discover that the BUFHNT routine in
TCPTCP.MAC sets up a pointer to the TCB's receive buffer without
checking if that buffer exists. Elsewhere in TCPTCP the code does make
such checks. We have found our nil pointer.
The fix: Add one line to TCPTCP.MAC as follows:
BUFHNT::
SAVEAC <TCB,BFR>
MOVE TCB,T1 ; put TCB into correct AC
SETZ T1, ; no special flags
LOAD BFR,TRCB,(TCB) ; get the receive buffer
SETZRO TRCB,(TCB) ; no more receive buffer
IFN STANSW,<
JUMPE BFR,R ; return now if no receive buffer
>;IFN STANSW
CALL USRBFF ; user buffer filled
RET ; and return to caller
-------
31-Mar-85 16:38:30-PST,611;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Mar 85 16:38:22-PST
Date: Sun 31 Mar 85 16:38:58-PST
From: Kirk Lougheed <
[email protected]>
Subject: SPEAR and 6.X
To:
[email protected]
In case people running 6.0 and 6.1 systems haven't yet noticed, the Release
5.X SPEAR doesn't work properly on new ERROR.SYS files.
Rather than sprinkle SPEAR support files throughout PS:<SUBSYS>, I've put
them all in PS:<SPEAR> and added that directory to the SYS: search path.
There are about 1600 pages and 38 some files.
Kirk
-------
31-Mar-85 23:44:21-PST,682;000000000001
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Sun 31 Mar 85 23:43:53-PST
Date: Sun 31 Mar 85 23:43:37-PST
From: David Roode <
[email protected]>
Subject: Bug in dumper
To:
[email protected]
cc:
[email protected],
[email protected]
Location: EJ286 Phone: (415) 859-2774
(Sorry no fix yet.)
If DUMPER has just been used to do a RETRIEVE, and then a
SAVE/MIGRATE follows, DUMPER finds itself in a strange state
where it thinks it need not ask for tape id information
but just proceeds to do the migration. Files so migrated
have bad tape information in their FDB's.
Has anyone seen a fix for this yet?
-------
1-Apr-85 11:16:45-PST,617;000000000000
Return-Path: <EC0N@CMU-CC-TE>
Received: from CMU-CC-TE by SU-SCORE.ARPA with TCP; Mon 1 Apr 85 11:16:11-PST
Date: Mon 1 Apr 85 14:13:29-EST
From: Eric Crane <EC0N%CMU-CC-TE@CMU-CC-TE>
Subject: DECnet monitor
To:
[email protected]
Office: Ucc 130 x3568
Secretary: x2638
I have been asked to check if any of you might know of any programs for
checking the status of DECnet links. What we would like to do is have
a program that wakes up every so often and checks the ability to connect
to other nodes. If a connection fails it should give some sort of diagnostic.
- Thanks
Eric Crane
-------
2-Apr-85 12:06:38-PST,600;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Apr 85 12:06:17-PST
Date: Tue 2 Apr 85 15:51:04-AST
From: Peter Gergely <
[email protected]>
Subject: Separating "Digest" style messages
To:
[email protected]
Has anyone got any software for either MM or BBOARD that can
"Undigestify" messages that are in Digest Format. Something in the
order of the "D" command for the UNIX READNEWS would be nice (It
presents digests in separate messages allowing individual selection,
without affection the original message).
- Peter
-------
2-Apr-85 13:47:06-PST,942;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Apr 85 13:46:32-PST
Received: ID <
[email protected]>; Tue 2 Apr 85 16:38:33-EST
Date: Tue 2 Apr 85 16:38:26-EST
From:
[email protected]
Subject: FTPSRT bugfix
To:
[email protected]
It has been suggested that I post this... There is a longstanding bug in
FTPSRT that causes TYPE I/TYPE L 36 (non-paged) retrieves to send extra nulls
at the end of a transfer (this is only noticiable for TOPS-10/ITS sites, since
TOPS-20/TENEX sites usually use paged mode). The problem is that the file byte
count is not being adjusted to account for the 36-bit transfer mode. The fix
is rather trivial and may be found in the most recent version of FTPSRT in
PS:<VAF.FTP> on CMU-CS-C (along with some other changes, among them some,
shall we say, "unique" debugging code needed to debug an active data transfer).
--Vince
-------
3-Apr-85 17:17:46-PST,1805;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Apr 85 17:16:37-PST
Date: Wed 3 Apr 85 21:16:32-AST
From: Peter Gergely <
[email protected]>
Subject: BBOARD.MAC version's (~40 lines long)
To:
[email protected]
Sorry to bother the whole list with this request, but...
About two weeks, I announced some changes to BBOARD that we had made
here at DREA. As ours was based on edit 67 of Rutgers BBOARD, I am
wondering if anyone has a newer version of BBOARD.MAC that has
additional features. Features that I would like to see are (the numbers
are not priorities):
1. Wildcard bulletin boards (i.e. BBOARD *, would get all
BBD:*.TXT files that have corresponding .DATA files, with an error skip
if no .DATA file). I have this change but based on edit 67 as
mentioned.
2. The subject on a separate line if LENGTH(date + from + subject)
is greater than line width. We also have this for a rigid line width of 72.
3. A switch to allow me to check if any bulletin board has new
messages.
4. Common Database with MM. (If anyone has this, please
announce it).
5. A facility to mark all messages as being seen. Something
like the readnews "K" command in Unix.
6. Some method of "undigestifying" digest message, so that the
individual messages act as a bulletin board. This is similar to the
readnews "d" command in Unix.
7. Just about anything else that would ease reading the
bulletin boards (maybe Unix style more processing).
I would appreciate hearing from anyone who may have some or all of
these. Please contact me for more information. I will be more than
happy to help with BBOARD on my spare time in evenings, but cannot
afford to take over maintenance.
- Peter
-------
4-Apr-85 06:31:11-PST,367;000000000000
Return-Path: <
[email protected]>
Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Apr 85 06:26:18-PST
Date: Thu 4 Apr 85 09:26:05-EST
From: Donna Lynch <
[email protected]>
Subject: plot
To:
[email protected]
cc:
[email protected]
Where can I get PLOT10 or PLOT20? Is it available on the net? What is
the cost?
-------
5-Apr-85 22:08:29-PST,575;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Apr 85 22:06:04-PST
Date: Fri 5 Apr 85 23:05:58-MST
From: Mark Crispin <
[email protected]>
Subject: GTJFN% strangeness
To:
[email protected]
Is it a bug or a feature that doing a GTJFN% returns a GJFX20 error
when:
. an explicit generation number is given in the string
. the generation is deleted
. GJ%DEL isn't specified
I don't think GJFX20 should be returned unless GJ%OLD is set. If it
isn't, it should supercede the old version.
-------
7-Apr-85 01:19:27-PST,470;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Sun 7 Apr 85 01:17:25-PST
Date: Sat 6 Apr 85 22:00:38-EST
From: Ken Rossman <
[email protected]>
Subject: Source code for CHANGE program
To:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Does anyone out there know where I can get my hands on the source to CHANGE
(an old character set converter program)? /Ken
-------
9-Apr-85 12:26:44-PST,995;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 12:26:07-PST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 09 Apr 1985 15:22:16 est
Date: 09 Apr 85 09:06 +0100
From: Markku_Suni_Univ._of_Turku%
[email protected]
Reply-to: Markku_Suni_Univ._of_Turku%
[email protected],
TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected],
[email protected]
Subject: J0NRUN during system shutdown?
Message-ID: <99297@QZCOM>
In-Reply-To: <87821@QZCOM>
We here at University of Turku (Dec-2060, monitor 5.1, PCL-EXEC)
have received J0NRUN during shutdown but so irregularly that I
have not been able to notice any logic in it.
9-Apr-85 12:56:49-PST,1720;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 12:54:17-PST
Date: Tue 9 Apr 85 13:54:16-MST
From: Mark Crispin <
[email protected]>
Subject: OPOPAC bughlts
To:
[email protected]
All around the ol' DEC 20
The AC blocks get pushed and popped,
Sometimes it goes just a little to far
Pop! Goes the system %DECSYSTEM-20 NOT RUNNING
Folks, we just got an OPOPAC bughlt here. The same problem happened
at Score a number of times as well. Each time it's happened, it's
been an FTP server job (typically ANONYMOUS) and the UPDL has traces
of TTY input code. However, it no longer has JSYS context:
UPDL/ T1,SLBIN#+4
UPDL+1/ -372,,UPDL+5
UPDL+2/ .JBBLT+13,,TCITST
UPDL+3/ T1,,.TRRET+1
UPDL+4/ CAIA BYTIN1+10
This UPDL wouldn't be all that bad looking if it was higher up on the
stack; clearly the TRVAR return to UDPL+5 from UPDL+1 is bogus, but
would be alright if it happened at, say, UPDL+10. The other less
obvious bogon is that in UPDL+4 there is a section 0 PC.
To me this implicates PSI service; I suspect some PSI came in while
TVT BIN%'s were happening and dismissed back to here in section 0. In
the process, it also managed to nuke the stack. The OPOPAC follows
fairly straightforwardly from here once you recognize how MPP/MRETN/etc.
will interact in this case.
Frank Wancho reports that this problem happens in more-or-less vanilla
DEC monitors too. The monitor we're running now has all the known fixes
to JOBCOF (e.g. saving all AC's including CX, not to mention dismissing
back to section 1). Has anybody else seen this problem, or better yet,
has anybody already come up with a fix for it?
-------
9-Apr-85 13:14:27-PST,872;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 13:12:45-PST
Date: Tue 9 Apr 85 14:12:00-MST
From: Mark Crispin <
[email protected]>
Subject: Re: J0NRUN during system shutdown?
To: Markku_Suni_Univ._of_Turku%
[email protected],
TOPS-20_experts_mailing_list%
[email protected]
cc: TOPS-20_experts_mailing_list%
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "Markku_Suni_Univ._of_Turku%
[email protected]" of Tue 9 Apr 85 09:06:00-MST
Examine the crash dump, and in particular location FKSTAT. That will
give you the scheduler test that fork 0 is blocked on. 9 out of 10
times it will turn out to be hung in TCOTST on a terminal line, often
the CTY if the operator has typed CTRL/S on it.
-------
9-Apr-85 23:30:30-PST,1362;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Apr 85 23:29:11-PST
Date: Wed 10 Apr 85 00:28:55-MST
From: Mark Crispin <
[email protected]>
Subject: IAC doubling: the saga continues
To:
[email protected]
There have been several messages about a correct
implementation of IAC doubling on TVT's to prevent a binary '377
character being output causing spurious interpretation of network
protocol. Unfortunately, none of the previously published
patches are perfect. Typically, the problems are paths which can
cause a non-doubled '377 to go through or paths which could cause
many '377s to go through.
This solution seems to resolve these problems.
In TTYSRV, rewrite TCOU6 to look like:
TCOU6: CAIE T1,377 ;OUTPUT BYTE = IAC?
JRST TCOU6B
TDCALL D,<<TV,TCOU6A>> ;YES, DO TCOU6A TWICE IF A TVT
JRST TCOU6B
TCOU6A: SAVEAC <T1,T2>
TCOU6B: LOAD 3,TOMAX,(2) ;CAPACITY OF OUTPUT BUFFERS
...etc...
At TCOU5-1, replace JRST TCOU3 with JRST TCOU6B
In TTANDV, rewrite TCOBN to look like:
TCOBN: SAVELN ;SAVE LINE NUMBER
TXZE T1,.LHALF ;WANTS IT LITERALLY?
JRST TCOU6B ;YES, NO IAC DOUBLING PLEASE
ANDI T1,377 ;8 BITS OF CHARACTER
CALL TCOU6 ;GO OUTPUT THE CHARACTER WITHOUT ADDING
; PARITY OR DOING LINKS
RET ;RETURN
-------
11-Apr-85 10:15:14-PST,500;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Apr 85 10:14:36-PST
Date: 11 Apr 85 13:13:52 EST
From: Rob Liebschutz <
[email protected]>
Subject: Re: OPOPAC bughlts
To:
[email protected],
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of 9 Apr 85 15:54:16 EST
I can recall seeing this problem once (this past Monday) on our
student machine. We have not looked into it at all though.
-------
11-Apr-85 13:39:14-PST,2189;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Apr 85 13:37:57-PST
Date: Thu 11 Apr 85 17:37:47-AST
From: Peter Gergely <
[email protected]>
Subject: BBOARD and MM share a common database!!! (~45 lines)
To:
[email protected]
-Thanks to all who offered me a BBOARD.MAC to work. I got 3
independent versions, all having good and bad features. There
is still a lot that can be done.
-Thanks to Mark Crispin and Steve Berlin for explaining the .IDX
format to me.
Now:
I have edited the version of BBOARD received from SIERRA (thanks
Kirk), as it was the easiest to merge with our changes, to include the
following features (all have [PJG] in the comments):
- Separate subject line on long headers
- Wildcard bulletin board scanning
- X command to exit BBOARD reading immediately
- /SCROLL-MORE (allows UNIX-style more, SIERRA already had a
/MORE built in
- Sharing of the database with MM. This is done by using MM's
.IDX file, and adding the extra information used by BBOARD at
another page location unreached by MM. MM remains untouched,
with BBOARD using the message read date the same as MM.
- Some cleanup of the flags in BBOARD, and other things
Caveat:
I haven't written a BBCHNG program to merge the .DATA
information with that of the .IDX, but will be glad to suggest how to do
it.
Availability:
The files <ANONYMOUS>BBOARD.MAC, and <ANONYMOUS>CHKBBD.MAC (see
below) are available at DREA-XX via ANONYMOUS FTP. I would appreciate
greatly if you drop me a note saying who picked it up, so I can advise
you of BUGS or Changes.
CHKBBD:
This program reads an individual .IDX file, and (if WOPR) resets
the read date and time for files only, and non-existent directories. It
will also display the read and write date of the BBOARD. It does not
touch the .IDX message map. It is strictly for use with the above
mentioned BBOARD. We run it nightly so that new users don't get
left-overs from somebody before them. I did not know of the existence
of the BBWHO program at the time of writing this years ago.
Peter J. Gergely
-------
11-Apr-85 15:40:25-PST,410;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Apr 85 15:37:26-PST
Date: Thu 11 Apr 85 19:37:17-AST
From: Peter Gergely <
[email protected]>
Subject: BBOARD at DREA
To:
[email protected]
Please make sure that you get <ANONYMOUS>BBOARD.MAC.101 if
and/or when you pick it up. Please send me mail if you get a copy
though.
- Peter
-------
12-Apr-85 09:47:36-PST,962;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 09:46:38-PST
Date: Fri 12 Apr 85 13:46:13-AST
From: Peter Gergely <
[email protected]>
Subject: Bug in MMAIL.EMACS.91
To:
[email protected]
[Symptom]
Editing (E command) a message marked by an "N" while in MMAIL
DIRED puts you into REPLY mode on some message. Upon exit the message
is sent off. It goes as a reply to the last successful message that you
edited while in DIRED.
[Problem]
Message number is not being interpreted on a line containin an
"N".
[Cure]
At !& MMAIL DIRED Type:! and !& MMAIL DIRED Reply:! change the
code RUFAD_ on the first line to NRUFAD_, causing the flag skip to go
over the N flag, and get to the message number.
[[[Aside: If you have problems with the bottom window scrolling (i.e no
overlap, or jumps of many lines on a CTRL-V), contact me as I have a
solution]]]
- Peter
-------
12-Apr-85 09:58:16-PST,1344;000000000000
Return-Path: <
[email protected]>
Received: from BBNG.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 09:51:34-PST
Date: Fri 12 Apr 85 12:51:30-EST
From: Dan Tappan <
[email protected]>
Subject: TCP FTP speed
To:
[email protected]
I recently connected up one of our 20's to an ethernet and did a few
speed comparisons with some of the other hosts on the cable (VMS
Vaxes running Wollongong TCP and 4.2/Ultrix vaxes).
I was shocked to discover that, while the VMS machines could do up to
310KBitsPS between themselves, the best I could get to the 20 was
60-90KBPS (depending on what processor I put in the front-end
connecting it to the ether).
I did some poking around and, to make a long story short, I've managed
- largely by twiddling buffer sizes in the user level FTP code - to
improve things enough that I now see transfer rates up to 382KBPS. At
this point I've run out of machines fast enough to force a higher data
rate - possibly until I get another 20 connected.
The reason I mention this is that there is a generally accepted truism
that "TOPS20 TCP is slow" (which I have been guilty of myself).
Apparently, even at this date, a little tuning can make a big difference.
The changes were to the "BBN interface" FTP code and are available if
anyone wants them. Actual mileage may vary.
Dan
-------
12-Apr-85 16:50:51-PST,511;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 16:49:22-PST
Date: Fri 12 Apr 85 14:01:18-PST
From: Kirk Lougheed <
[email protected]>
Subject: BBN FTP
To:
[email protected]
cc:
[email protected]
The modified version of BBN's TCP FTP is on PS:<TCP.BBN-FTP> on Sierra.
I brought Dan Tappan's changes over this afternoon. Hopefully there are
some clues in the user code as to how to speed up TCPJFN.MAC.
Kirk
-------
12-Apr-85 23:53:31-PST,472;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Apr 85 23:53:12-PST
Received: ID <
[email protected]>; Sat 13 Apr 85 02:23:28-EST
Date: Fri 12 Apr 85 18:01:27-EST
From:
[email protected]
Subject: Re: TCP FTP speed
To:
[email protected]
I have made Dan's changes to the versions of FTP and FTPSRT that I maintain.
Mucho thanks, Dan, for the changes - they really help around here!
--Vince
-------
15-Apr-85 01:49:45-PST,710;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 01:48:20-PST
Date: Mon 15 Apr 85 02:48:32-MST
From: Mark Crispin <
[email protected]>
Subject: altering value of TTSIZ
To:
[email protected]
Has anybody tried upping the value of TTSIZ (currently 40) to,
say, 100? The comment about it having to be a power of 4 is obviously
wrong since 40 isn't a power of 4, but 100 is.
If TTSIZ is 100 this would allow for 252. (decimal) bytes in a TTY
buffer instead of the existing limit of 124. We would like to do this
in an attempt to improve MODEM etc. performance, although it should
improve TTY output performance as well.
-------
15-Apr-85 12:18:26-PST,1565;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 12:17:15-PST
Date: Mon 15 Apr 85 12:17:27-PST
From: Mark Crispin <
[email protected]>
Subject: performance measuring/monitoring
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
What performance measuring/monitoring tools are currently in use
out there? What I am looking for is something which would enable the
performance evaluator to draw somewhat more scientific conclusions
than can be obtained from SYSDPY (which is a good seat-of-the-pants
tool, but less useful for getting quantitative data).
I would also be interested in any tools which read WATCH output
and digest it into more human-readable information. What would be
really great is a tool which spots trends in WATCH output and graphs
those trends as a function of some other trend (e.g. time, load, etc.)
Another tool I would be interested in is one which measures a
particular program's impact upon the system. For example, we know that
as an editor, EMACS is a CPU hog and that Interlisp generates zillions
of page faults. I'm looking for something which can more precisely
measure this sort of impact.
So much for wheel reinvention abatement. I'm also interested in
people's comments about their past experiences in performance measuring;
also in what luck they have had, if any, in tuning the class scheduler.
-- Mark -- (wearer of many hats)
-------
15-Apr-85 12:33:55-PST,794;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 12:33:39-PST
Date: 15 Apr 1985 15:33-EST
Sender:
[email protected]
Subject: Re: altering value of TTSIZ
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA]15-Apr-85 15:33:50.CLYNN>
In-Reply-To: The message of Mon 15 Apr 85 02:48:32-MST from Mark Crispin <
[email protected]>
BBN has been running with TTSIZ equal to 100 for a long time.
I do not really have hard data from the days when it was 40. I seem
to remember that 100 made screen updates in EMACS a lot better. Probing
the local hosts shows that about half of the packets which are not
echos of one or two characters contain enough bytes to be using additional
space.
Charlie
15-Apr-85 12:51:48-PST,690;000000000000
Return-Path: <
[email protected]>
Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 12:50:59-PST
Date: Mon 15 Apr 85 14:49:47-CST
From: Clive Dawson <
[email protected]>
Subject: Re: performance measuring/monitoring
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 15 Apr 85 14:38:10-CST
Although I have no direct experience with it, I've heard good
reports regarding the AMAR-20 system that DEC markets. (There's a
blurb in the March 1 Dispatch about it.) Perhaps someone out there
is in a better position to give a testimonial or a condemnation?
CLive
-------
15-Apr-85 14:42:24-PST,842;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Apr 85 14:41:52-PST
Date: Mon 15 Apr 85 17:41:02-EST
From: Kevin Paetzold <
[email protected]>
Subject: Re: performance measuring/monitoring
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 15 Apr 85 15:22:57-EST
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
any performance measuring effort based on release 5.1/6.0 is almost
certainly a waste of time. release 6.1 has had major and extensive
changes in the performance area. the bottlenecks you find in pre 6.1
monitors will be different than the ones in 6.1.
I am talking about monitor performance and not the performance of
individual programs.
-------
17-Apr-85 14:43:03-PST,551;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 17 Apr 85 14:42:55-PST
Date: Wed 17 Apr 85 14:42:52-PST
From: Andrew Sweer <
[email protected]>
Subject: MERLIN
To:
[email protected]
Who knows where the most recent sources for MERLIN are? We
discovered a problem here dealing with the long file names created
as an offshoot of subdirectories. The most recent sources I found,
along with fixes and a new .EXE file can be found at SUMEX in
SS:<SU-SOURCES>MERLIN.*.
Andy
-------
18-Apr-85 00:20:13-PST,542;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Apr 85 00:18:42-PST
Date: Thu 18 Apr 85 00:18:09-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: MERLIN
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Andrew Sweer <
[email protected]>" of Wed 17 Apr 85 22:25:30-PST
I have recent sources to MERLIN on PS:<SU-UTILITIES>MERLIN.MAC.
Whatshisname at DREA has made a number of bugfixes in the past few
weeks.....
Kirk
-------
18-Apr-85 10:14:51-PST,791;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Apr 85 10:13:16-PST
Date: 18 Apr 1985 1311-EST
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>
To: tops-20 at SU-SCORE
Subject: A "minor" nitbit regarding protections
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12104173665.36.249.136191 at DEC-MARLBORO>
I had the "fun" to "secure" halfways a public account against NITs -
changing LOGIN.CMD from their "standard" settings -- typically these
guys just used COPY TTY: LOGIN.CMD to create an "empty" one. After some
thought we came up with a solution:
Use highest possible generation-Nr AND set protection to 500000 - this
allows to generate a "sticky" CMD-file.
i.e. LOGIN.CMD.131071;P500000
--------
18-Apr-85 10:51:31-PST,1067;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Apr 85 10:50:32-PST
Date: Thu 18 Apr 85 13:50:31-EST
From: Ittai Hershman <
[email protected]>
Subject: Re: A "minor" nitbit regarding protections
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>" of Thu 18 Apr 85 13:11:00-EST
Your method doesn't quite work since, if the generation number is known,
the user can change the protection then delete it. An improvement is to
set the file to the highest generation, then turn on the "undeletable"
flag in the file's fdb -- FB%NDL (word 1, bit 18) -- which was added in
version 5.
There is still a very small window in the exec between the re-allowing
of interrupts after LOGIN% has completed and the LOGIN.CMD file is
executed. If you are really paranoid, you can delay the re-allowing of
interrupts until after the LOGIN.CMD has been processed; but that is not
recommended for obvious reasons.
-Ittai
-------
19-Apr-85 07:00:01-PST,784;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 06:57:38-PST
Date: 19 Apr 1985 0957-EST
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>
To: TOPS-20 at SU-SCORE
cc: lcg.Kramer at DEC-MARLBORO
Subject: SEAL-20 available from here
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12104400512.39.249.41819 at DEC-MARLBORO>
.via ANONYMOUS FTP from DEMO:[SEAL-20]*.*
The software is available on an "AS IS" basis - I would like to request
however that everybody, who plans to use it , drops me a small note - and
[in the same vain] BUG-fixes [its only software written by humans] and/or
enhancements find their way back here too - so that I can notify everybody
of changes in state.
Bernie
--------
19-Apr-85 13:38:12-PST,1087;000000000000
Mail-From: MRC created at 19-Apr-85 13:37:31
Return-Path: <MHICKEY%
[email protected]>
Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 11:06:27-PST
Received: from (MAILER)UDCVM.BITNET by WISCVM.ARPA on 04/19/85 at
13:03:52 CST
Return-path: MHICKEY%
[email protected]
Received: by UDCVM (Mailer X1.20) id 0644; Fri, 19 Apr 85 13:44:24 EST
Date: 19 April 1985, 13:38:17 EST
From: MHICKEY%
[email protected]
To:
[email protected]
ReSent-Date: Fri 19 Apr 85 13:37:31-PST
ReSent-From: Mark Crispin <
[email protected]>
ReSent-To:
[email protected]
Greetings,
My name is Mike Hickey from the Univ. of the District of Columbia.
We have a DEC 2060 (serial 2416) and I am the Systems Programmer
for it. Would it be possible if I could join the TOPS-20 group?
Thanks in advance for your assistance.
This note is coming from a 4341 we also have. Needless to say the first
question I would have for the group is direction on how to interface
BITNET to our TOPS via the 2780/3780 emulation software.
Once again thanks.
19-Apr-85 17:13:02-PST,970;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 17:12:53-PST
Date: Fri 19 Apr 85 17:13:04-PST
From: Mark Crispin <
[email protected]>
Subject: Galaxy bug?
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
I just encountered the following strange behavior. If I'm right,
it's a serious bug in Galaxy. I don't know if the problem is local to
Stanford (local to SUMEX?) or is all over.
I am doing plots. I spool my output file with the /DELETE switch.
I then generate a subsequent plot with the same file name, but with a
greater generation. The previous plot is deleted when I make the new
generation, but it still comes out provided it had started printing
already when I wrote the new generation. But then, when it finishes
printing, it deletes and EXPUNGES the new generation I just wrote!
-------
19-Apr-85 18:29:15-PST,8555;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Apr 85 18:28:41-PST
Date: Fri 19 Apr 85 18:28:49-PST
From: Mark Crispin <
[email protected]>
Subject: WATCH data interpretation tool
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Enclosed is a little program which can be used to interpret WATCH
"data records". Its output is input for the CMU "Plot" program (courtesy
of Ivor.Durham@CMUA). You edit in an appropriate WRITE statement in the
data record reading section to record the data points you want; you also
edit in a FORMAT statement giving the title of the sample on the Y grid.
This program, RDSTAT.FOR, automatically scales the plot to dates or
time depending upon the input range given; if more than a day it marks by
days. It attempts to grade the date/time axis (X) as reasonably as it
can. Since I'm using an Imagen IMPRINT-10 printer in Tektronix mode I
limited it to 8 date/time labels.
I've only tested it for Type 6 WATCH records so far, but have gotten
a lot of good data out of it. If you're wondering why I'm using alphanumeric
interpretation instead of numeric, it's because in some cases certain values
overflow the fields WATCH allocates. That poisons the data if you're reading
it numerically in Fortran. Since I'm not doing any data interpretation yet
in the RDSTAT program this is quite alright.
There isn't anything wonderful in this program; it'll just save somebody
some time if they have to do the same thing I've had to.
-- Mark --
C Program to read WATCH data records and extract useful information
C Mark Crispin
INTEGER TIME, INTRVL, MINTAD, MAXTAD
INTEGER MONTH1, DAY1, YEAR1, HOUR1, MINUT1, SECON1
REAL DATE, FDATE, TAD, BDATE, EDATE, ATAD, ADATE, ATIME
C Record header declarations
INTEGER RECTYP, RECSEQ, MONTH, DAY, YEAR, HOUR, MINUTE, SECOND
REAL*8 INTVL, NJOBS
C Type 1 declarations
REAL*8 USED, IDLE, SWPW, SKED, SUSE, TCOR, FILW, BGND, NTRP, NCOR,
+AJBL, NREM, TRAP, NRUN, NBAL, NWSM, BSWT, DSKR, DSKW, SWPR, NLOD,
+CTXS, UPGS, FPGS, DMRD, DMWR, DKRD, DKWR, TTIN, TTOU, WAKE, TTCC,
+TDIO, RPQS, GCCW, XGCW, KNOB, QDIST(10), NQDIST
C Type 2 declarations
REAL*8 LDAV, HQLDAV, LQLDAV, CLSNUM(32), CLSSHR(32), CLSUTL(32),
+CLSLAV(32), CLSHQL(32), CLSLQL(32), NCLOAD
C Type 3 declarations
REAL*8 JOB, TTY, USER(2), PROG, ERT, EDEMD, EUSED, EGRDY, EBRDY,
+ESWPR, EDSKR, EDSKW, ERPQW, EOTHR, EIMEM, ENLD, ENRSP, ESR, EWSS,
+EUPGS, ESWPR1, EDSKR1, ETPF, EIFA
C Type 4 declarations
REAL*8 DELTAR, NRT, JU, CSH
C Type 5 declarations
REAL*8, HIT, MISSF, MISSN, TOTRC, LOKPGS, SHRPGS, AVAMEM,
+NRUNMN, NRUNMX, SMNRMN, SMNRMX, NRPLMN, NRPLMX, SYMDMD, SWPRAT,
+ACTSWR, MEMUTL, AVWSSZ, AVCPUT, THNKTM, DSKCHN(15), DSKUNT(15),
+SEEKS(15), READS(15), WRITES(15), DSKNAM(15), DSKNUM(15), NDSKIO
C Type 6 declarations
REAL*8 TUSED, TSWPW, TSKED, TCTXS, TWAKE, TTDIO, TNRUN, TNWSM,
+TNLOD, TUSED2, TGRDY, TBRDY, TSWPR, TDSKR, TDSKW, TRPQW, TOTHR,
+TIMEM, TNLD, TNRSP, TRESP, TSR
DATA ADATE, ATIME/'Date','Time'/
C Start of program
C Initialization
MINTAD=99999
MAXTAD=0
C Open files
OPEN (UNIT=20,FILE='WATCH',ACCESS='SEQIN')
OPEN (UNIT=21,FILE='PLOT.CMD',ACCESS='SEQOUT')
C Get date ranges
TYPE 1
1 FORMAT (' Start date in mm/dd/yy hh:mm:ss format: ',$)
ACCEPT 2,MONTH1,DAY1,YEAR1,HOUR1,MINUT1,SECON1
BDATE=T10TAD(MONTH1,DAY1,YEAR1,ITIME(HOUR1,MINUT1,SECON1))
2 FORMAT (I2,1X,I2,1X,I2,1X,I2,1X,I2,1X,I2)
TYPE 3
3 FORMAT (' End date in mm/dd/yy hh:mm:ss format: ',$)
ACCEPT 2,MONTH,DAY,YEAR,HOUR,MINUTE,SECOND
EDATE=T10TAD(MONTH,DAY,YEAR,ITIME(HOUR,MINUTE,SECOND))
C Decide if graph should be by date or time
ATAD=ADATE
IF (EDATE-BDATE.LE.1) ATAD=ATIME
C Write file header
WRITE (21,5) MONTH1, DAY1, YEAR1, HOUR1, MINUT1, SECON1,
+MONTH, DAY, YEAR, HOUR, MINUTE, SECOND
5 FORMAT ('New Graph'/'Graph Title Watch Statistics ',
+I2.2,'/',I2.2,'/',I2.2,' ',I2.2,':',I2.2,':',I2.2,' to ',
+I2.2,'/',I2.2,'/',I2.2,' ',I2.2,':',I2.2,':',I2.2/
+'Graph Font HELVETICA12BI'/
+'Key .0000000,.0000000, Symbol,HELVETICA8'//
+'New Curve'/'Curve Font HELVETICA8'/'Curve Symbol Plus'/
+'Curve Type Solid'/'Curve Interpolation Linear'/'New Points')
C Main loop
10 READ (20,1000,END=9999) RECTYP, RECSEQ, MONTH, DAY, YEAR, HOUR,
+MINUTE, SECOND, INTVL, NJOBS
1000 FORMAT (I2,I3,I2,1X,I2,1X,I2,1X,I2,1X,I2,1X,I2,A7,A3)
C Get time, date, and set TAD to match what graph would be
TIME=ITIME(HOUR,MINUTE,SECOND)
DATE=T10TAD(MONTH,DAY,YEAR,TIME)
C Check TAD for being in range
IF (DATE.LT.BDATE .OR. DATE.GT.EDATE) GO TO 10
C Date is in range, update bounds
IF (FDATE.EQ.0) FDATE=DATE
TAD=DATE
IF (ATAD.EQ.ATIME) TAD=TIME+3600*INT(DATE-FDATE)
IF (TAD.LT.MINTAD) MINTAD=TAD
IF (TAD.GT.MAXTAD) MAXTAD=TAD
C Dispatch based on record type
GO TO (100,200,300,400,500,600) RECTYP
C Unimplemented record type
TYPE 11,RECTYP
11 FORMAT (' %Unknown record type ',I2,' encountered, discarded')
GO TO 10
C Type 1 record - system statistics
100 REREAD 101, USED, IDLE, SWPW, SKED, SUSE, TCOR, FILW, BGND, NTRP,
+NCOR, AJBL, NREM, TRAP, NRUN, NBAL, NWSM, BSWT, DSKR, DSKW, SWPR,
+NLOD, CTXS, UPGS, FPGS, DMRD, DMWR, DKRD, DKWR, TTIN, TTOU, WAKE,
+TTCC, TDIO, RPQS, GCCW, XGCW, KNOB, QDIST, NQDIST
101 FORMAT (32X,36A7,A5,10A7,A2)
GO TO 10
C Type 2 record - load average
200 REREAD 201, LDAV, HQLDAV, LQLDAV,
+(CLSNUM(I),CLSSHR(I),CLSUTL(I),CLSLAV(I),CLSHQL(I),CLSLQL(I),
+I=1,32),NCLOAD
201 FORMAT (32X,9A7,32(A5,5A7),A2)
GO TO 10
C Type 3 record - expanded per-job
300 REREAD 301, JOB, TTY, USER, PROG, ERT, EDEMD, EUSED, EGRDY, EBRDY,
+ESWPR, EDSKR, EDSKW, ERPQW, EOTHR, EIMEM, ENLD, ENRSP, ESR, EWSS,
+EUPGS, ESWPR1, EDSKR1, ETPF, EIFA
301 FORMAT (32X,2A3,2A10,A6,A4,A7,8A5,A6,A4,A5,A6,A3,2A7,2A5,2A4)
GO TO 10
C Type 4 record - normal per-job
400 REREAD 401, JOB, TTY, USER, PROG, DELTAR, NRT, JU, CSH
401 FORMAT (32X,2A3,2A10,A6,A7,A4,2A7)
GO TO 10
C Type 5 record - expanded statistics
500 REREAD 501, HIT, MISSF, MISSN, TOTRC, LOKPGS, SHRPGS, AVAMEM,
+NRUNMN, NRUNMX, SMNRMN, SMNRMX, NRPLMN, NRPLMX, SYMDMD, SWPRAT,
+ACTSWR, MEMUTL, AVWSSZ, AVCPUT, THNKTM, (DSKCHN(I), DSKUNT(I),
+SEEKS(I), READS(I), WRITES(I), DSKNAM(I), DSKNUM(I), I=1,15),
+NDSKIO
501 FORMAT (32X,3A6,10A5,A7,6A8,15(2A2,3A6,A10,A2),A2)
GO TO 10
C Type 6 record - tune mode statistics
600 REREAD 601, TUSED, TSWPW, TSKED, TCTXS, TWAKE, TTDIO, TNRUN,
+TNWSM, TNLOD, TUSED2, TGRDY, TBRDY, TSWPR, TDSKR, TDSKW, TRPQW,
+TOTHR, TIMEM, TNLD, TNRSP, TRESP, TSR
601 FORMAT (32X,9A7,8A5,A6,A4,A5,A6,A3)
write (21,9000) tad, tswpr
9997 format ('Y Label Percent Swap-In Wait (SWPR)')
GO TO 10
C Format for outputting time and data point
9000 FORMAT (F9.3,', ',A10)
C If time, round max and mins to inclusive hour
9999 IF (ATAD.NE.ATIME) GO TO 9991
MINTAD=3600*(MINTAB/3600)
MAXTAD=3600*((MAXTAD+3599)/3600)
C Compute interval - want 8 timestamps at most
9991 INTRVL=MAX0(1,(MAXTAD-MINTAD)/8)
C Write file trailer
WRITE (21,9996) ATAD,INTRVL,ATAD
9996 FORMAT (/'X Label ',A4/'X Font Helvetica10BI'/
+'X Unit 1'/'X Interval ',I5/'X NumberStyle ',A4,' 0')
WRITE (21,9997)
WRITE (21,9998)
9998 FORMAT ('Y Font Helvetica10BI'/'Y NumberStyle Floating 1')
C Das Ende...
STOP
END
C Convert from date/time components to TOPS-10 format date
REAL FUNCTION T10TAD(MONTH,DAY,YEAR,TIME)
INTEGER MONTH, DAY, YEAR, TIME
T10TAD=(((YEAR-64)*12+(MONTH-1))*31+DAY-1)+FLOAT(TIME)/(24*60*60)
RETURN
END
C Convert from time components to time in seconds
INTEGER FUNCTION ITIME(HOUR,MINUTE,SECOND)
INTEGER HOUR, MINUTE, SECOND
ITIME=((HOUR*60+MINUTE)*60)+SECOND
RETURN
END
-------
20-Apr-85 12:43:03-PST,3996;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Sat 20 Apr 85 12:39:55-PST
Date: Sat 20 Apr 85 15:30:58-EST
From: Thomas De Bellis <
[email protected]>
Subject: Re: Galaxy bug?
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Fri 19 Apr 85 20:09:11-EST
Mark,
Here are my suspicions. I havn't observed the behavior that you see
here, so perhaps your EXEC/Galaxy is modified in some way. Normally,
when you issue a queue request, the EXEC puts the entire file name
along with the generation number into the IPCF packet. This is
eventually sent along to the spooler that is responsible for handling
jobs for the requested object type in the original message. The
packet that gets sent to the spooler is pretty much what the EXEC
sends with some minor header munging. Therefore, there are three or
four people who can "get" you.
1) It might be the EXEC. CMU, for example, has modified their EXEC
to not put explicit generation numbers into the IPCF request
packet when an explicit generation number was not typed by the
user. This helped them because certain requests can stay in the
queue for quite a long time (ie, things being spooled off to tape
for the Xerox 9700). If you EXEC is doing things like this, you
might be being zapped because the wrong thing gets deleted (more
on this later). Check the EXECQU module here.
2) It might be Quasar. At every scheduler call, Quasar checks its
delete queue for lists of files to delete. For example, if you
spool a file (in the real sense of the word, having the monitor
do the submit for you, or submit a request with the SPL bit set),
Quasar will toss the file for you if the request is canceled
before it is scheduled. The relevent code is in QSRQUE. This
bug would depend on a modified monitor or EXEC to be tickled.
3) It might be GLXLIB. The file you want to look at is GLXFIL. I
would tend to doubt that it is in GLXLIB, although from what you
describe, it could happen in a modified GLXLIB. The spooler can
issue a F%DREL command which means to delete the file and release
the FOB associated with it. This does the normal thing by doing
a CLOSF% (with CZ%NRJ bit set) and the a DELF% with the expunge
bit set. This is the right thing to do, I believe, since a new
file is not being opened, just the current one being tossed in a
special closing sequence.
4) It might be your spooler. In particular, notice that above I
said to use the F%DREL call. This will delete an open file which
is the right thing to have happen. If you plotter spooler is
closing the file itself by issuing a F%REL and then deleting the
file later by doing a F%DEL, you can have a timing window open up
with a CMU'ish EXEC. The way F%DEL works is to first open the
file up and then call F%DREL to toss it. Thus, without the
explicit generation number information, you could open the first
file, have the file deleted by somebody else, close the file with
a F%REL and then later toss the wrong file with F%DEL because
lack of explicit generation number information has caused you to
open of the most recent file.
The only spooler I really know about, LPTSPL, does do a F%DEL (the
wrong thing). However, since our EXEC is unmodified in that respect
(one of the few respects in which it is unmodified...) we don't suffer
from the problem. I would check your spooler and EXEC see what's
happening. You can find out what is being sent to Quasar by putting a
breakpoint into the EXEC at SNDMS1:: where it does the actual MSEND to
Quasar. The file names are stored around 20 words after the beginning
of the message and can be 0$T'ed.
Hope I've been of some help!
-- Tom
-------
22-Apr-85 18:46:23-PST,684;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Apr 85 18:44:43-PST
Date: Mon 22 Apr 85 18:38:48-PST
From: Kirk Lougheed <
[email protected]>
Subject: MSTR program
To:
[email protected]
The MSTR program is an old LOTS hack that allows a wheel to mount/dismount
structures without the intervention of QUASAR and friends. It is very useful
when working on standalone systems. I've updated (and cleaned up) MSTR for
use under Release 6.X systems. It specifically knows about RA81 disks.
The source is on Sierra as PS:<SU-UTILITIES>MSTR.MAC and the EXE is
PS:<ADMINISTRATION>MSTR.EXE.
Kirk
-------
22-Apr-85 18:56:13-PST,562;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Apr 85 18:56:03-PST
Date: Mon 22 Apr 85 18:55:53-PST
From: Mark Crispin <
[email protected]>
Subject: Re: MSTR program
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Kirk Lougheed <
[email protected]>" of Mon 22 Apr 85 18:47:51-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
What does MSTR do that the STRTST program doesn't do just as well?
-------
23-Apr-85 12:33:16-PST,3771;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 12:31:33-PST
Date: Tue 23 Apr 85 13:31:32-MST
From: Mark Crispin <
[email protected]>
Subject: JOBCOF: The Saga Continues
To:
[email protected]
SIMTEL20 crashed with an ILMNRF due to JOBCOF clobbering context
again. This was in spite of it having all the currently favored patches
including the save of FFL and FPC. From looking at the dump, I think
that MPP needs to be saved as well. The rewritten JOBCOF routine looks
like this:
;DETACH JOB IMMEDIATELY, LOGOUT AFTER 5 MINUTES IF NOT REATTACHED.
;INVOKED ON REQUEST BY PSI SERVICE
JOBCOF::
IFE PANDASW,< ;[19]
SKIPGE SLOWF ;IN JSYS CONTEXT?
JRST [ MCENTR ;NO, GET THERE
PUSH P,[IFIW!MRETN] ;SETUP RETURN
JRST .+1]
SE1ENT ;GET INTO SECTION 1
SAVET
>;IFE PANDASW
IFN PANDASW,< ;[19]
SKIPL SLOWF ;IN JSYS CONTEXT?
IFSKP.
MOVEM CX,UPDL+NUPDL-1 ;NO, SAVE CX OVER THIS JUST IN CASE
MCENTR ;GET TO JSYS CONTEXT
PUSH P,[IFIW!MRETN] ;SETUP RETURN
MOVE CX,UPDL+NUPDL-1 ;RETRIEVE CX FROM THIS KLUDGY PLACE
ENDIF.
SAVEAC <CX> ;SAVE CX BEFORE ACSAV SMASHES IT
ACSAV ;SAVE ALL ACS
SE1ENT ;GET INTO SECTION 1
STKVAR <CFFFL,CFFPC,CFMPP>
MOVE T1,FFL ;PRESERVE FFL
MOVEM T1,CFFFL
MOVE T1,FPC ;PRESERVE FPC
MOVEM T1,CFFPC
MOVE T1,MPP ;PRESERVE MPP
XMOVEI T1,[
MOVE T1,CFFFL ;RESTORE FFL
MOVEM T1,FFL
MOVE T1,CFFPC ;RESTORE FPC
MOVEM T1,FPC
MOVE T1,CFMPP ;RESTORE MPP
MOVEM T1,MPP
RET]
PUSH P,T1 ;ESTABLISH RESTORAL CONTEXT
MOVEM P,MPP ;MAKE SURE THIS IS ALWAYS DONE
>;IFN PANDASW
MOVE 1,JOBNO
SKIPGE B,CTRLTT ;HAVE A CONTROLLING TTY?
JRST JOBCF1 ;NO
CALL GTCJOB ;GET ITS OWNING JOB
JRST JOBCF2 ;NONE. GO ON
CAIN C,0(A) ;SAME AS THIS ONE?
JRST JOBCF1 ;YES. GO ON
JOBCF2: SETOM CTRLTT ;NO. CLEAR THIS ASSIGNMENT
MOVE T1,JOBNO
HRROS JOBPT(T1) ;ALSO CLEAR CONTROLLING TTY HERE
JOBCF1: CALL LDTACH ;DO LOCAL DETACH
MOVE T1,JOBNO
HRRZ 1,JOBDIR(1) ;SEE IF NOW LOGGED IN
IFE. T1
MOVX T1,UMODF ;NO, RESET STACK AND LOGOUT
MOVEM T1,FFL
SETZM FPC
JRST FLOGO
ENDIF.
MOVE T1,BITS+.TICRF ;CHECK TO SEE WHAT THE TOP FORK THINKS
TDNE T1,TTSPSI ; OF TAKING A CARRIER OFF INTERUPT
RET ;IT THINKS SO, SO LET IT TRY
CALL FFORKI ;INDIRECTLY FREEZE ALL INFERIORS
;**;[2941] CHANGE 1 LINE AT JOBCF1:+13L TAM 7-APR-83
MOVE 1,COFTIM ;[2941] GET TIME TO BE DETACHED
CALL SETBKT ;COMPUTE BLOCKT DATA
HRRI 1,COFTST ;SETUP SPECIAL TEST
MOVSI T2,FHV1 ;LOW BLOCK PRIORITY
HDISMS
MOVE 1,JOBNO ;SEE IF NOW ATTACHED
SKIPL JOBPT(1)
IFSKP.
MOVX T1,UMODF ;USER PC FAKE
MOVEM T1,FFL
SETZM FPC
MCENTR ;RESET STACK, INIT JSYS CONTEXT
MOVE T1,JOBNO
HRRZ T1,JOBDIR(T1) ;DIRECTORY
JUMPE T1,FLOGO1 ;DONT CHECK IF NOT LOGGED IN
HRLI T1,USRLH
CALL CNVDIR ;GET THE NUMBER OF THAT DIRECTORY
GTDAL ;GET ALLOCATION
ERJMP FLOGO1 ;DONT TRY ACJ IF THERE IS AN ERROR
SETOM T1 ;FAKE A LOGOUT WITH -1 AS ARG
;**;[2812] CHANGE 1 LINE AT JOBCF1:+33L TAM 14-SEP-82
GTOKM (.GOLGO,<T2,T3,T1>,FLOGO1) ;[2812] ASK ACJ, BUT IN ANYCASE,
;LOG OUT THIS USER. (THIS IS ONLY TO BE NICE
;TO ACJ, WHO MAY NOT BE NICE TO US)
JRST FLOGO1
ENDIF.
NOINT ;KEEP CONTROL
HLRZ T2,JOBPT(T1) ;GET CONTROLLING TTY
MOVEI T3,"C"-100 ;FAKE A CONTROL-C
CALL TTPSRQ ;""
CALL RFORKI ;RESUME ALL INDIRECTLY FROZEN INFERIORS
OKINT ;ALLOW INTS AGAIN
RET
;SCHEDULER TEST FOR ABOVE. WAITS UNTIL JOB ATTACHED OR SPECIFIED TIME
;ELAPSED
RESCD
COFTST: LOAD 2,FKJOBN ;GET JOB NUMBER
SKIPL JOBPT(2) ;NOW ATTACHED?
JRST 1(4) ;YES, WAKEUP
JRST BLOCKT ;NO, GO TEST TIME
SWAPCD
-------
23-Apr-85 12:38:41-PST,594;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 12:37:28-PST
Date: Tue 23 Apr 85 12:36:20-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: MSTR program
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 22 Apr 85 18:56:04-PST
It has a source. It also displays *Release 6* status information regarding
disks and structures. Both will mount/dismount structures; I don't know if
STRTST knows about HSC50 disks.
Kirk
-------
23-Apr-85 16:15:31-PST,894;000000000000
Return-Path: <
[email protected]>
Received: from USC-ECLC.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 16:13:28-PST
Date: Tue 23 Apr 85 16:11:29-PST
From: Maurice J. Wuts <
[email protected]>
Subject: Re: JOBCOF: The Saga Continues
To:
[email protected],
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Tue 23 Apr 85 12:55:26-PST
There seems to be a bug in your patch. The point was to save MPP,
but you seem to forgot to:
MOVE T1,FFL ;PRESERVE FFL
MOVEM T1,CFFFL
MOVE T1,FPC ;PRESERVE FPC
MOVEM T1,CFFPC
MOVE T1,MPP ;PRESERVE MPP
; Shouldn't there be the following instruction here?
MOVEM T1,CFMPP
XMOVEI T1,[
MOVE T1,CFFFL ;RESTORE FFL
MOVEM T1,FFL
MOVE T1,CFFPC ;RESTORE FPC
MOVEM T1,FPC
MOVE T1,CFMPP ;RESTORE MPP
MOVEM T1,MPP
RET]
PUSH P,T1 ;ESTABLISH RESTORAL CONTEXT
Maurice
-------
23-Apr-85 16:18:43-PST,962;000000000000
Return-Path: <
[email protected]>
Received: from USC-ECLB.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Apr 85 16:17:55-PST
Date: 23 Apr 1985 16:12-PST
Sender: MARK@USC-ECLB
Subject: Re: JOBCOF: The Saga Continues
From: Mark A. Brown <Mark@USC-ECLB>
To: MRC@SIMTEL20
Cc: TOPS-20@SU-SCORE
Message-ID: <[USC-ECLB]23-Apr-85 16:12:37.MARK>
In-Reply-To: The message of Tue 23 Apr 85 13:31:32-MST from Mark Crispin <
[email protected]>
I think Mark missed a Movem.. below is the corrected code fragment.
STKVAR <CFFFL,CFFPC,CFMPP>
MOVE T1,FFL ;PRESERVE FFL
MOVEM T1,CFFFL
MOVE T1,FPC ;PRESERVE FPC
MOVEM T1,CFFPC
MOVE T1,MPP ;PRESERVE MPP
Movem T1,CFMPP ;*** Really preserve it ***
XMOVEI T1,[
MOVE T1,CFFFL ;RESTORE FFL
MOVEM T1,FFL
MOVE T1,CFFPC ;RESTORE FPC
MOVEM T1,FPC
MOVE T1,CFMPP ;RESTORE MPP
MOVEM T1,MPP
RET]
PUSH P,T1 ;ESTABLISH RESTORAL CONTEXT
MOVEM P,MPP ;MAKE SURE THIS IS ALWAYS DONE
Mark
24-Apr-85 12:26:50-PST,844;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 12:24:49-PST
Date: Wed 24 Apr 85 13:24:17-MST
From: Mark Crispin <
[email protected]>
Subject: bogus destination node
To:
[email protected]
I am seen this problem at Stanford and at SIMTEL20 now. It isn't
due to any Stanford mods in the EXEC or Galaxy since SIMTEL20 doesn't
run those mods. The problem is that for no apparent reason a destination
node gets set on all the jobs in the batch queue. Very commonly it is
TOPS20::. This is on systems with no DECnet! Modifying all the jobs to
have desination node LOCAL:: clears it.
There seems to be no particular operational impact other than the
annoying extra (twice as large) output from INFO BATCH.
Any ideas on this one, Galaxy Gurus?
-------
24-Apr-85 14:12:55-PST,919;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:12:31-PST
Date: Wed, 24 Apr 85 22:11 GMT
From: SAMUELSON%
[email protected]
Subject: Re: bogus destination node
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: MRC@SIMTEL20.ARPA
cc: tops20@SU-SCORE.ARPA
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Wed 24 Apr 85 12:39:08-PST
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
ALL galaxy requests have a PROCESSING-NODE set.
If you change the local node name (you can set it in n-CONFIG)
all the old requests in the queue will show the old node name.
One easy way to handle it is to use the ROUTE command (in OPR)
to route all jobs for the old node name to the new node name.
- Sam -
-------
24-Apr-85 14:20:15-PST,676;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:19:33-PST
Date: Wed 24 Apr 85 14:10:54-PST
From: Mark Crispin <
[email protected]>
Subject: watch bug
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
My Watch job blew up with an illegal instruction at PRINT+11; the JFN
it was trying to SOUT% on wasn't open.
Does anybody have a reliable version of WATCH that doesn't crap out on
such things? It is irritating (to say the least) to have an attempt to
record a trend over a long period of time blow up like this.
-------
24-Apr-85 14:51:17-PST,1382;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:50:59-PST
Date: 24 Apr 1985 1750-EST
From: Tom Blinn <BLINN at DEC-MARLBORO>
To: TOPS20 at SU-SCORE
Subject: Re: Bogus destination node
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12105797321.31.275.62307 at DEC-MARLBORO>
There is one other piece of information that Sam didn't mention,
but that probably provides the rest of the puzzle, and that is the
default local node name the monitor uses.
If you don't specify it in the n-CONFIG file, and the monitor was
built WITH the DECnet modules included (even if you are not running
DECnet), then the local node name defaults to TOPS20. If your
monitor was built WITHOUT the DECnet modules, the local node name
defaults to LOCAL. Of course, building with/without DECnet is a
flag, either in STG or PARAMS (I forget which, and am too lazy to
look).
Probably the "bogus" entries show up when you reboot a new monitor,
and it was built with the switch in a different state from the old
monitor. You might consider simply putting the NODE command into
the n-CONFIG command file to define your node name as LOCAL whether
the monitor contains DECnet or not. (Make sure SETSPD doesn't fall
on its side if the appropriate DECnet JSYS fails when it trys to
set the nodename.)
Tom
--------
24-Apr-85 14:56:16-PST,1246;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Apr 85 14:54:50-PST
Date: Wed 24 Apr 85 17:54:43-EST
From: Ken Rossman <
[email protected]>
Subject: Dual port tape drive hangups(?)
To:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
We've just recently dual ported our TU78 tape drives between two systems,
though we have not yet gone into production with them switchable between
two systems. I had done initial testing to make sure one could simply
switch a drive from one port to the other (while there was no tape up), and
both systems were able to properly recognize the drives when I put tapes up
after switching.
However, I found one day while one of the two systems was down, that
switching those drives over to the other system which was up did NOT work.
Nothing we did would cause the drives to be recognized by the system that
was up (they had been switched to the system which was down before it went
down). And, yes, we put tapes up and made the drives go ready.
Does anyone know why this is? Do both systems indeed have to be up and
running in order to be able to switch the tape drives over? /Ken
-------
25-Apr-85 06:14:22-PST,1719;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISIB.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 06:13:45-PST
Date: Thu 25 Apr 85 02:32:05-PST
From: The Mailer Daemon <
[email protected]>
To:
[email protected]
Subject: Message of 25-Apr-85 02:30:49
ReSent-To:
[email protected]
ReSent-From: BILKIS at USC-ISIB.ARPA (connected to COMP:<BILKIS>)
ReSent-Date: 25 Apr 1985
Message failed for the following:
sy.Ken@CU20B: 550 Mail from
[email protected] to
[email protected] is not authorized
------------
Date: 25 Apr 1985 02:30:49 PST
Subject: Re: Dual port tape drive hangups(?)
From: David Bilkis <
[email protected]>
To: Ken Rossman <
[email protected]>
In-Reply-To: (Message from "Ken Rossman <
[email protected]>" of Wed 24 Apr 85 17:54:43-EST)
Ken,
If I understand your msg correctly, the problem is that your
system didn't see the Kontroller when it was coming up because the
Master was unavailable to it (for some reason) when it came up. The Add
Unit stuff works just fine, the 'Add Kontroller on Attention Interrupt'
does not. Try reloading with all drives in dual port and not busy.
ISI runs 6 drives configured dual ported as 3 dual port pairs
between 6 systems with the drive select wheelies set to '2 - A/B mode'
all the time. This periodically gets us into the trouble you mention,
and slightly worse variations (unit 0 being mta1, and unit 1 being
mta0 confuses the hell out of operators, especially when you can't
switch unit select designators in order to maintain dual port mode).
In general, being careful about drive operational status on shared
drives during reload may be worth the extra effort.
Love,
Wook
-------
-------
25-Apr-85 08:11:51-PST,3107;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 08:06:40-PST
Date: Thu 25 Apr 85 11:05:16-EST
From: Thomas De Bellis <
[email protected]>
Subject: Re: bogus destination node
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Wed 24 Apr 85 15:36:31-EST
Hi MRC,
I'm a little rusty on that particular area, but here is what I think
is happening: I think you are being subject to a timing problem.
Normally, when the system boots, it sets the its own local DECnet
node name to be 'TOPS20'. That is where your Galaxy is getting this
from. Usually SETSPD will run and then you set your local node name
there. This should all happen before Quasar ever fires up. However,
it is possible to change the node name of the local system *AFTER*
Quasar starts up, in which case the fun begins. Alternatively, SETSPD
may gronk and never set the node name. Running it later can also set
the node name out from underneath Quasar.
When Quasar starts, it rebuilds its internal queues by reading the
failsoft file. The fail soft file contains requests, at lot of which
pretty much look like the original IPCF requests sent from the EXEC.
Quasar does some header munging and then submits them to itself using
the internal bit. The routines that you want to look at are in QSRT20
(the file manipulation stuff), QSRFSS (Fail Soft indexing routines),
QSRSCH (request scheduling and priority link in routines), QSRQSR (the
rebuild routines).
Now then, the request area can have a node specification in it.
This is used if you are running the DN65 software so that you can
schedule requests to IBM nodes. If you are a site that has
implemented DECnet spooling (a lot of us have) or if you have a DN200,
the node name is a DECnet node name. All this information is
eventually used to construct the requested object block. Most users,
particularly on systems that don't run DECnet or DN65, do not
specifify a node name and that slot is left blank.
So, when Quasar rebuilds its internal queues and constructs
requested objects, it will fill in the blank node name with the
current system local node. Later, the system node name gets set
correctly and Quasar notices that and thinks that these jobs are for
another node; that's why they all type /Proc:TOPS20::
I'm a little fuzzy, but I think that having them have different node
names won't affect scheduling batch jobs. The only time it worries
about node names for batch jobs is when the request node name is an
IBM node. Otherwise it ignores the node specifications and sends
everythingt to BATCON. This is different for printer objects where it
really does care about the requested node in all cases. Check the
QSRSCH module for further info in this area. Otherwise drop me a note
and I'll try to remember some more about what happens. You are right
however, it doesn't hurt anything to have these jobs like this.
Hope I've been of some help!
-- Tom
-------
25-Apr-85 09:37:42-PST,886;000000000000
Return-Path: <
[email protected]>
Received: from BBNF.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 09:35:33-PST
Date: 25 Apr 1985 12:35-EST
Sender:
[email protected]
Subject: Trashed symbol table
From:
[email protected]
To:
[email protected]
Message-ID: <[BBNF.ARPA]25-Apr-85 12:35:39.RBASCH>
We have tracked down a bug that caused 2 words in the symbol table to
be trashed at start-up. (The problem came up when running SYSDPY
crashed one of our systems because the value for the symbol OKSKD0 had
been clobbered). The bug is that the XCT IORST at SYSLOD+3 will change
the cells CONOPG and CASHF; these cells are in RSVAR, which overlaps
the initial (pre-hidden) symbol table. Our solution was to move CONOPG
(in STG) and CASHF (APRSRV) to RSDAT; the extra XCT IORST at SYSLD3+6
can probably be removed with this change, although we haven't tested
that yet.
Bob
25-Apr-85 12:14:06-PST,566;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Apr 85 11:51:20-PST
Date: Thu 25 Apr 85 12:50:08-MST
From: Mark Crispin <
[email protected]>
Subject: Re: Trashed symbol table
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 25 Apr 85 10:35:00-MST
Gee, that bug was reported on this list quite a while ago (1 year+).
Maybe somebody ought to collect all the existing currently unfixed (by
DEC) bugs in TOPS-20 and produce a single report out of it.
-------
26-Apr-85 12:51:15-PST,1245;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 26 Apr 85 11:08:21-PST
Date: 26 Apr 1985 11:06 PST (Fri)
Message-ID: <
[email protected]>
From: "Frank M. Fujimoto" <
[email protected]>
To: su-tops-20@score
cc: gergely@drea
Subject: New BBOARD
I've installed a new BBOARD on Sierra with the following changes from
Peter Gergely at DREA:
. BBOARD now uses MM's .IDX files for last message read
instead of its own .DATA file
. If the subject field is too long to fit on the same line as
the date/sender fields, it is printed on the next line
. A /SCROLL-MORE switch now exists, which is similar to /MORE
but it doesn't clear the display before showing a screen of
data
. Wildcard bboard specifications are now allowed
. An X command exists to quit out of all bboards. This
differs from the Q command becuase Q will only quit out of
one bboard
The source to BBOARD is on Sierra as PS:<SU-UTILITIES>BBOARD.MAC.
There is also PS:<SU-UTILITIES>BMERGE.MAC which will take the .DATA
and .IDX files and merge the two into the .IDX file. It will take the
later read date between the two and save it in the .IDX file.
-Frank
26-Apr-85 15:30:18-PST,504;000000000000
Mail-From: MRC created at 26-Apr-85 15:29:55
Date: Fri 26 Apr 85 15:29:55-PST
From: Mark Crispin <
[email protected]>
Subject: MMailbox bug fix
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Rich Alderson has reported a performance bug in MMailbox due to its
supposedly prime hashing value not actually being prime. This is fixed
in the most recent version of MMLBX.MAC on SCO:<MM> at Score. Thanks Rich!
-------
29-Apr-85 15:54:02-PDT,846;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Apr 85 15:49:30-PDT
Received: ID <
[email protected]>; Mon 29 Apr 85 18:49:09-EDT
Date: Mon 29 Apr 85 18:49:08-EDT
From:
[email protected]
Subject: Re: FTP timeouts from simtel20.
To:
[email protected],
[email protected]
In-Reply-To: Message from "Dave Towson (info-cpm-request) <cpmlist@AMSAA>" of Thu 25 Apr 85 16:00:48-EST
I believe there may be a buffering problem in the new FTP with the expanded
buffer sizes. I was using it here and found that for short files, you win a
lot but for long files, the average transfer rate is actually slower (it is
very bursty). I would suggest reverting to the previous versions of FTP and
FTPSRT, particularly if you have been having problems with timeouts.
--Vince
-------
29-Apr-85 16:35:15-PDT,1330;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Mon 29 Apr 85 16:30:29-PDT
Date: Mon, 29 Apr 85 23:24 GMT
From: SAMUELSON%
[email protected]
Subject: goodbye
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: tops-20@SU-SCORE.ARPA
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
As the old saying goes, all good things must end.
For almost twelve years now I have been working with PDP-10s. Thru DECUS
and the ARPANET, I have gotten to know many of you around the country.
I have enjoyed working with you. I enjoyed working with DECUS and with
many DEC employees and customers. It has been a lot of fun.
It is now time for me to move on to other things (Since there is little
of interest coming from DEC these days). I will be leaving the DEC world
after tomorrow, going to work on NLTSS, a new operating system for super
computers. I will keep my net mailing address for some time, although I
will probably not login every day to read my mail from now on.
A couple of DECUS's back I said goodbye to DECUS. Now I am saying goodbye
to all my friends in TOPS-20 land. It has been nice knowing all of you.
- Sam -
-------
30-Apr-85 08:50:21-PDT,594;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Apr 85 08:47:55-PDT
Date: Tue 30 Apr 85 08:44:33-PDT
From: Ed Pattermann <
[email protected]>
Subject: Help on Tops20 -> VMS
To:
[email protected]
Could someone post to the mailing list the details on accessing the info
and software that DEC was collecting and providing on moving users and
programs from Tops20 to VMS. I remember there being a public account back
east somewhere where utilities were being collected and made available.
Thanks!
-- Ed
-------
30-Apr-85 09:12:23-PDT,638;000000000000
Mail-From: ALMQUIST created at 30-Apr-85 09:12:14
Date: Tue 30 Apr 85 09:12:13-PDT
From: Philip Almquist <
[email protected]>
Subject: Re: Trashed symbol table
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 25 Apr 85 09:35:00-PST
Gee, I guess DEC must be a little slow. I reported that bug
during the 5.1 field test. The answer claimed that the fix I had
applied (same as yours - moving CONOPG and CASHF to RSDAT) would work
in 5.1 as an interim solution and that a real fix would be included
in "the next release", which I guess meant 6.0.
Philip
-------
30-Apr-85 09:40:42-PDT,703;000000000000
Return-Path: <SAMUELSON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Apr 85 09:39:24-PDT
Date: Tue, 30 Apr 85 16:38 GMT
From: SAMUELSON%
[email protected]
Subject: Re: Help on Tops20 -> VMS
To:
[email protected]
From: Norm Samuelson <Samuelson@LLL.MFENET>
To: PATTERMANN@SUMEX-AIM.ARPA
cc: TOPS-20@SU-SCORE.ARPA
In-Reply-To: Message from "Ed Pattermann <
[email protected]>" of Tue 30 Apr 85 08:57:48-PDT
Telephone: (415) 422-0661, [FTS 532-0661]
Office-Location: Bldg 543, room 1067
Postal-Address: LLNL, PO Box 5511, L-630, Livermore, CA 94550
Contact Powell@MARKET, he is in charge of that stuff, what there is.
- Sam -
-------
30-Apr-85 10:58:29-PDT,963;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Apr 85 10:57:49-PDT
Date: 30 Apr 1985 1325-EDT
From: Tom Blinn <BLINN at DEC-MARLBORO>
To: PATTERMANN at SUMEX-AIM
cc: TOPS-20 at SU-SCORE
Subject: Re: Help on Tops20 -> VMS
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12107310878.32.275.86274 at DEC-MARLBORO>
You can access DEC-MARLBORO (MARKET) via ARPAnet.
The account on MARKET is LCG.CUSTOMER, password CUSTOMER.
There is also a dial-up account, if you want it, I can
post it, but I don't have it close at hand.
You will be guided to some help files once you log in.
The tools are not presently accessible on-line. We are
working on identifying the right way to make this happen.
In the interim, use MS (MAIL == MS SEND) to mail TO: REQUEST
to get tools tape mailed to you (no charge). Be sure to
answer all the questions in the header (address, etc.)
Tom
--------
1-May-85 22:19:52-PDT,564;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 1 May 85 22:15:46-PDT
Date: Wed 1 May 85 23:15:18-MDT
From: Mark Crispin <
[email protected]>
Subject: yet more JOBCOF
To:
[email protected]
I just got another OPOPAC hit. I am starting to suspect that a nested
JOBCOF call is happening while doing the MCENTR which is early in the
JOBCOF routine. I'm working on yet another rewrite of JOBCOF. Looking
through the code I also found that LDTACH has some totally bogus code
in it. More later...
-------
4-May-85 01:24:31-PDT,574;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Sat 4 May 85 01:24:20-PDT
Date: Fri 3 May 85 13:12:41-ADT
From: Reid Broome <
[email protected]>
Subject: DEC-20 and WANG communications software
To:
[email protected]
We have a requirement to be able transfer files/documents to-and-from
our WANG model OIS-130A word processing system and our DECsystem-20.
Does anyone have or know the whereabouts of a program that runs on
TOPS-20 that will do file transfers with a WANG word processor.
Reid Broome
-------
4-May-85 02:20:30-PDT,1909;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 4 May 85 02:20:26-PDT
Date: Thu 2 May 85 16:54:25-PDT
From: Sean Welsh <
[email protected]>
Subject: Fix to COMND/Sumex GTJFN interface
To:
[email protected]
Problem: COMND provides cryptic help in response to "?" when
.CMFIL is a possible alternate parse for a .CMKEY field,
appearing to include the possible filename completions of
the input in the command table. The EXEC is a case in point:
@d? Command, one of the following:
DAYTIME DDT DEASSIGN DEBUG DECLARE DEFINE
DELETE DEPOSIT DETACH DIRECTORY DISABLE DISCARD
DISMOUNT DO
DBEDIT
DUMPER
@d
Note that DBEDIT and DUMPER are programs in the system
search path.
Diagnosis: COMND passes the "?" on to GTJFN after providing help
for the keyword parse, and GTJFN provides no guidance
beyond a list of possible completions.
Solution: Type out any user-supplied help message before passing
the "?" to GTJFN. In COMND.MAC, in the literal at
CMRAT1+12, replace:
IFN STANSW,<
CALL CHKFIL ;[SMXGTJ] PARSING A FILESPEC?
JRST CMRATR ;[SMXGTJ] YES, PASS THE ? ON TO GTJFN
>;IFN STANSW
with:
IFN STANSW,<
CALL CHKFIL ;[SMXGTJ] PARSING A FILESPEC?
JRST [ TXNN F,CMPS1F ;YES, JUST SCANNING?
CALL DOHLP ;NO, GIVE PROVIDED HELP, IF ANY
JRST CMRATR ] ;[SMXGTJ] NOW PASS THE ? ON TO GTJFN
>;IFN STANSW
This fix is in [Sierra]PS:<6-1-MONITOR>COMND.MAC.
The results in the EXEC look like
@d? Command, one of the following:
DAYTIME DDT DEASSIGN DEBUG DECLARE DEFINE
DELETE DEPOSIT DETACH DIRECTORY DISABLE DISCARD
DISMOUNT DO
or system program name
DBEDIT
DUMPER
@d
The patch can be retrofitted to 5.3 and 6.0 monitors.
Enjoy.
--Sean
-------
5-May-85 13:42:41-PDT,2477;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 5 May 85 13:42:27-PDT
Date: Sun 5 May 85 13:42:00-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Stanford Host tables
To:
[email protected]
The Sierra experiment to merge the NIC host table with the Stanford PUP host
table seems to have worked out quite well. The way this scheme works is to
use PUPUPD to get the latest PUP-NETWORK.DIRECTORY (if any) and write
SYSTEM:HOSTS.PUP, a NIC-style host table. The program NICUPD is then used
to read the official NIC host table and write SYSTEM:HOSTS.NIC. The program
HSTUPD then takes HOSTS.PUP and HOSTS.NIC and if either of those files has a
write date more recent that HOSTS.TXT, it then writes the union of those
files to SYSTEM:HOSTS.TXT and installs the file. HSTUPD also reduces the
size of HOSTS.TXT by leaving out irrelevant protocol information, resulting
in a faster loading host table.
Advantages of this scheme include:
- Ability to send mail to Stanford hosts that are in only the PUP
host table, but do not speak PUP protocols. There are an increasing
number of such hosts at Stanford.
- The MRC mailsystem as distributed assumes IP as the perferred
protocol. At sites like LOTS this means obscure addresses like
L.LOUGHEED@[36.48.0.1] instead of the more readable L.LOUGHEED@LOTS-A.
Disadvantages of this scheme:
- Mail that gets to a host that doesn't have a modified NIC host
table cannot be replied to by Joe Random user. These hosts include
the entire Internet outside of Stanford. DEC-20 hosts at Stanford
that don't use a modified host table will use PUP protocols.
Stanford UNIX hosts already use the scheme that Sierra does.
It is my belief that the advantages of this scheme outweigh the
disadvantages. If a Stanford host not in the NIC table is sending mail
legitimately to an Internet host outside of Stanford, then that host should
either register itself with the NIC or use a mail relay (Score, Sierra,
Sumex).
At Sierra we run a batch job at 6:00AM every morning that has the following
lines for updating host tables.
! Update the host tables
!
@SYSTEM:PUPUPD
@SYSTEM:NICUPD
@SYSTEM:HSTUPD INSTALL
!
The sources are PS:<PUP>PUPUPD.MAC, PS:<TCP>NICUPD.MAC, and PS:<PUP>HSTUPD.C.
Yes, you need a copy of KCC to rebuild HSTUPD.
Frank Fujimoto (FMF@SIERRA) is the author of HSTUPD.
Kirk
-------
7-May-85 01:09:52-PDT,1826;000000000001
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 7 May 85 01:08:44-PDT
Date: Tue 7 May 85 02:08:30-MDT
From: Mark Crispin <
[email protected]>
Subject: JOBCOF once again
To:
[email protected]
I have spent the past few days carefully reviewing all the
code having to do with carrier-off PSI's as well as talking with
various others who have delved into this problem before me. I
believe I have fixed all the known carrier-off PSI bugs.
This was accomplished by rewriting most of LDTACH and JOBCOF
in MEXEC, PIRCOF in SCHED, and writing TTYSRV code to break links
without going through the TLINK% JSYS and maintain "in COF
routines" status bits in the dynamic data to prevent nested
carrier-off calls.
Much of my time was taken in sorting out the confused
nomenclature in the comments and code. In several places it is
clear that somebody patched in something to fix a symptom without
really understanding what was needed to fix the bug. I confess
that some of my previous attempts in fixing JOBCOF bugs were
similarly poorly-thought out.
DEC apparently claims that JOBCOF bugs are fixed in release
6. From the release 6 code at Stanford I can state that this is
not true. DEC has decided to flush entering JSYS level from
monitor mode in release 6, which simplifies much of the code (and
by extension removes many of the failure modes), but a number of
the known JOBCOF bugs are still unfixed in release 6.
I expect to test this code at SIMTEL20 and SUMEX for some
time (they've really been hurting with these problems) before
thinking about releasing it. The changes are quite extensive!
If you're really being badly bit by OPOPAC bughlts and other
JOBCOF related bugs send me mail.
-- Mark --
-------
7-May-85 16:23:28-PDT,1767;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 7 May 85 15:41:47-PDT
Date: Tue 7 May 85 16:41:30-MDT
From: Mark Crispin <
[email protected]>
Subject: Digital Review
To:
[email protected]
I just got sent my first complimentary issue of Digital
Review. As I suspected, it is pretty depressing. There is a
long AI section which would have you believe that most of the
world's AI is being done on VAX 11/780's although a few
organizations have Symbolics Lisp Machines which while a bit
expensive run Lisp applications 20% faster. I guess their point
is that you use Lisp Machines for CPU-bound applications but you
do all your interactive stuff on a VAX.
But!! 10's and 20's ARE mentioned. In the "Logged On"
column, a commentary about "2600" talks quite a bit about them.
Apparently 2600 is the current phone phreak/cracker newsletter;
needless to say the article abuses the term "hacker" even though
the columnist professes to know better. Quite a bit is mentioned
about how the 2600 people break into 10/20 systems, truly
trivial, or so the article implies. Needless to say, all of the
bugs turn out to be of the "known account/personal name, guess
the password from that" sort of thing.
Unix is mentioned as a tougher nut to crack, but there are
ways to find accounts without passwords. I guess they never
heard of Unix's vulnerability to known plaintext attacks.
The paragon of security? VMS, of course, as long as you
remember to change the passwords for the SYSTEM, FIELD, and
SYSTEST accounts. Very "admirable".
Enough to make you gag. Does anybody get this "2600"
newsletter who'd be willing to send me a xerox of the article?
-------
7-May-85 16:25:39-PDT,1600;000000000000
Mail-From: ALMQUIST created at 7-May-85 16:10:28
Date: Tue 7 May 85 16:10:28-PDT
From: Philip Almquist <
[email protected]>
Subject: Re: Fix to COMND/Sumex GTJFN interface
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Sean Welsh <
[email protected]>" of Sat 4 May 85 02:20:32-PDT
Sean,
I looked at the problem you mentioned several months ago and
decided not to fix it because it is a harder problem than your patch
suggests. The remaining bug that I know of is that CM%SDH is not
honored. Although I haven't tried it, I suspect from looking at the
code that it also fails if echoing is off or if one is trying to
parse an output file name or... The real problem is that it is very
hard to make code which is in the wrong place do the right thing in
all cases.
Fixing this right would take more time than I want to spend
on the project, but the basic idea is:
1) Remove all the changes to CMRFLD, since it never should have
been changed in the first place.
2) Remove the change at CMFIL3.
;The next step is the tricky one...
3) At CMFH1-1, replace the existing instruction with roughly the
following:
IFNSK. ;Input filespec?
;Yes...
if question mark first char in the atom
HRROI T1, [ASCIZ " input filespec"]
JRST CMFH1 ;Handle in old way
else
deposit "?" at end of atom buffer
;May be necessary to do other minor
; things here to make world safe for
; democracy...
JRST CMFIL2 ;Handle like "$"
endif
ENDIF.
Philip
-------
8-May-85 06:47:51-PDT,1068;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Wed 8 May 85 06:47:32-PDT
Date: Wed 8 May 85 02:22:38-CDT
From: Clive Dawson <
[email protected]>
Subject: DECUS Pre-symposium seminar on TOPS-20 Release 6
To:
[email protected]
This is just a reminder that a one-day seminar will be held on the Sunday
immediately prior to the DECUS conference in New Orleans (May 26) which
will cover TOPS-20 Rel. 6 Internals. This is a good deal for folks who
want to get at least an intro to this stuff without paying several times as
much for the DEC Ed. Services course. Monitor developers from DEC's
Large Systems Engineering will be the instructors.
I'm not sure what the deadlines are for signing up, but rumor had it
that the seminar registrations was just barely approaching the "break even"
point as of few days ago. It would be a shame if it had to be cancelled,
so if you or anybody you know can benefit from it, I'd suggest calling
the DECUS office at (617)480-6419 ASAP for more information.
Clive
-------
8-May-85 21:17:08-PDT,1107;000000000000
Mail-From: G.FUSSELL created at 8-May-85 21:16:58
Date: Wed 8 May 85 21:16:58-PDT
From: Carl Fussell <
[email protected]>
Subject: CI
To:
[email protected]
Address: Santa Clara University
Our CI/HSC etc has just arrived. I was given to understand that it
would take 2 channels when installed. Our CE has just informed us that
its installation will cause the loss of 4 channels rather than 2.
Apparently (according to him), the problem is that backplane changes
that are made for the CI also affect the next 2 channels (in anticipation
of NI installation). We do not have NI, nor will we be getting it
in the near future. It seems a little strange to me to lose 25%
of our channels for no reason. We have 5 different RH devices currently,
and are going to have to unplug one and no longer use it according
to the CE.
Has anyone else had experience with this? ie. have a CI and no
NI yet not lost slots 5 and 6?
Any comments, advice, suggestions, etc would be greatly appreciated.
Thanx...
Carl
U. of Santa Clara (via SCORE)
-------
8-May-85 21:49:27-PDT,608;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 8 May 85 21:47:35-PDT
Date: Wed 8 May 85 22:47:24-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: CI
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Carl Fussell <
[email protected]>" of Wed 8 May 85 22:42:38-MDT
Carl -
I regret to inform you that the CE is right. I believe that
the electrical characteristics of all 4 internal channels are changed
by the CI upgrade.
By the way, that SCU need any consulting help?
-- Mark --
-------
9-May-85 06:06:43-PDT,982;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 9 May 85 06:03:58-PDT
Date: Thu 9 May 85 09:01:06-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: CI
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Carl Fussell <
[email protected]>" of Thu 9 May 85 00:19:26-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
when you install an ni or a ci you can no longer install rh20s in any
of the top four slots. in reality the rh20 is not the channel it is a
massbuss adapter for the channel. all kl's have 8 channels (or one
depending on how you look at it). the reason for this is that5 the
klipa and the klni use a lot of power. the power system for the io
backplane could not power 6 rh's and klipa and a klni.
we have been "advertising" the rh reduction for a long time now and it
should not be a surprise to anyone.
-------
9-May-85 16:14:52-PDT,891;000000000000
Mail-From: MRC created at 9-May-85 16:14:14
Date: Thu 9 May 85 16:14:14-PDT
From: Mark Crispin <
[email protected]>
Subject: commercial message
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
A private message which had some commercial content was inadvertantly
sent to the TOPS-20 list. This isn't appropriate use of the TOPS-20 list,
even if the origin is the TOPS-20 list's moderator. Said person is highly
embarassed, especially when he is also the MM maintainer and should know
by now the difference between "REPLY SENDER" and "REPLY ALL"!
By the time I realized what had happened, it was too late to stop
the message. I was going to ignore it and hope everybody else did, but
I got enough comments that I feel a public apology is in order.
Mea culpa.
-- Mark --
-------
10-May-85 11:07:18-PDT,1417;000000000000
Return-Path: <raj@uci-icsa>
Received: from UCI-ICSA by SU-SCORE.ARPA with TCP; Fri 10 May 85 11:06:49-PDT
To:
[email protected]
Subject: Removing bad blocks in swap area
Reply-To: raj@uci-icsa
Date: 10 May 85 11:06:10 PDT (Fri)
Message-ID: <376.484596370@uci-icsa>
From: Richard Johnson <raj@uci-icsa>
Received: from Localhost by UCI-ICSA; 10 May 85 11:06:30 PDT (Fri)
We have two DEC 2020's with two RP06's on each. Recently we have
been getting BUGHLT's like "SWPUPT" about once every other week
or so. I looked up this bug halt in the manual and it says
"... the BAT blocks will not be marked". Also since there is
no "Action:" specified, the manual says we should submit an SPR
along with a crash dump to DEC.
I don't think such an SPR or crash dump would be of much
use to DEC since the problem is obviously a bad block on our disks,
thus I have ignored that part.
The real question here is, "Is there a way to find and enter this
bad block into the BAT block tables short of reformatting the
disk?" If not, I guess it's about time to reformat them anyway.
Any help would be appreciated.
(By the way, we don't have sources, in case that matters.)
------------------------------------------------------------------------
Richard Johnson
[email protected] (ARPA)
UCI ICS Research Systems Manager ucbvax!ucivax!raj (UUCP)
13-May-85 07:13:05-PDT,682;000000000000
Return-Path: <
[email protected]>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 07:09:46-PDT
Date: Mon 13 May 85 10:09:40-EDT
From: Rich Cower <
[email protected]>
Subject: support levels
To:
[email protected]
We have two support items here on the CS 20 - (I'll list em)
Qt023-3m - tops 20 for 2040-s/2060-p,9 $277 mo and...
Qt101-4m - tops-20 src pkg up 16 bpi $142 mo
i tried to get rid of the first one since it apparently does nothing
for us and was told we had to have it. anyone know why? (please don't
suggest the obvious moneytary rewards to be gained by such policies,
i understand that).
thanks...rich
-------
13-May-85 07:38:52-PDT,499;000000000000
Return-Path: <
[email protected]>
Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 07:38:43-PDT
Date: Mon 13 May 85 09:38:04-CDT
From:
[email protected]
Subject: FTP spool
To:
[email protected]
Does anyone know about a FTP spooler. We would like to set
something like this up on our local ethetnet to print file on
other systems or just transfer files. All of the system do
know how to speak TCP/IP.
Regards, Don Kassebaum
-------
13-May-85 07:44:45-PDT,851;000000000000
Return-Path: <bassen@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 07:44:18-PDT
Received: by oslo-vax.ARPA (4.12/4.7)
id AA12731; Mon, 13 May 85 16:44:45 -0100
Date: 13 May 1985 16:36-EST
From: bassen@oslo-vax (T S Lande)
Subject: Warning: Don't use CFS!!!!!
To: TOPS-20@SU-SCORE
Message-Id: <484846563/bassen@oslo-vax>
We are running TOPS-20 6.0 using CI and CFS with HSC50
equipped with 2 RA81s. We have one 2060 and one 2065. If you
are trying to do that you'll get a corrupted file-system with
destroyed directory-blocks. Our system are crashing constantly
and the disks must be reformatted and file-system rebuild. So
my advice is: STAY AWAY FROM CI and CFS!!!! (unless you
believe i 6.1.........)
Tor Sverre Lande
Institute of Informatics
University of Oslo
13-May-85 08:26:06-PDT,729;000000000000
Received: from LOTS-B by Score with Pup; Mon 13 May 85 08:25:57-PDT
Date: Mon 13 May 85 08:22:13-PDT
From: Sean L. Welsh <W.Welsh%LOTS-B@LOTS-B>
Subject: Re: Warning: Don't use CFS!!!!!
To:
[email protected]
cc: TOPS-20%Score@LOTS-B
In-Reply-To: Message from "bassen@oslo-vax (T S Lande)" of Mon 13 May 85 14:36:00-PDT
LOTS has had no such problems with three (soon to be four) 2060s
sharing the same filesystems on RA81s. We are running 6.1 Field
Test tape 5. I might point out that release 6.0 *does not* support
CFS.... it only supports one CPU on the CI. To use CFS you MUST be
running release 6.1; perhaps this is your problem.
Sean L. Welsh
Manager, LOTS Computer Facility
-------
13-May-85 09:00:02-PDT,1570;000000000000
Return-Path: <@COLUMBIA-20.ARPA:GINGELL@CWR20B>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 08:57:26-PDT
Received: from CWR20B by CUCS20 with DECnet; 13 May 85 11:57:02 EDT
Date: Mon 13 May 85 11:56:07-EDT
From: Rob Gingell <GINGELL@CWR20B>
Subject: Re: support levels
To: COWER%COLUMBIA-20@CUCS20
cc: tops-20%SU-SCORE@CUCS20
In-Reply-To: Message from "Rich Cower <
[email protected]>" of Mon 13 May 85 10:16:45-EDT
We also get (almost) those maintenance items (we get QT102-4M which
includes the RSX20F sources). This is what I think we get from
these part numbers.
QT101-4M is only the Monitor, and EXEC sources -- i.e., it entitles
you to tapes with those things on it. Because you have this, you
should have recently received the AP#9 5.1 sources for the monitor
and EXEC.
Because you get QT101-4M, QT023-3M is partially unnecessary for you,
since QT101-4M gives you what you need for the monitor and EXEC.
However, QT023-3M is the only part which gives you GALAXY, all the
Utilities, and all the bundled TOPS-20 software.
Now -- a new question. If I understood the announcements at the last
DECUS correctly, to get TCP/IP in the normal 6.1 distribution, we must
either change our QT023 number to something new, or else get an additional
QT number for the TCP/IP stuff. Does anyone know which of these we are
actually supposed to do, and if a new QT number is involved what that
number is? We are not now a "TOPS-20AN" site, though we want to use
TCP/IP over the NI's we've ordered.
-------
13-May-85 09:25:32-PDT,684;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 09:24:38-PDT
Date: Mon 13 May 85 12:23:37-EDT
From: Ken Rossman <
[email protected]>
Subject: Re: Warning: Don't use CFS!!!!!
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Sean L. Welsh <W.Welsh%LOTS-B@LOTS-B>" of Mon 13 May 85 11:29:11-EDT
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
We're running a 2-system (soon to be 3, followed by 4) CFS configuration
here at Columbia, and have not seen anything like the problems you
described. Maybe you have an HDA or two that are deteriorating? /Ken
-------
13-May-85 11:05:21-PDT,592;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 11:05:08-PDT
Date: Mon 13 May 85 12:04:23-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: support levels
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Rich Cower <
[email protected]>" of Mon 13 May 85 10:49:49-MDT
My understanding is that the QT023 is the entire TOPS-20 distribution
including the utilities, while QT101 is just monitor (and EXEC?) sources.
So without QT023, you wouldn't get any of the system software.
-------
13-May-85 11:56:19-PDT,1476;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 11:55:37-PDT
Date: Mon 13 May 85 14:57:22-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: Warning: Don't use CFS!!!!!
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "bassen@oslo-vax (T S Lande)" of Mon 13 May 85 17:36:00-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
First off you are using unsupported functionality of release 6.0. CFS
is not supported in release 6.0 at other than the initial field test
sites. We can not help you if you attempt to cross the ocean in a
rowboat either.
However I can assure you that any problem you might have is not as
straightforward as you believe. I assure you that many development
systems (and multiple clusters) have been running CFS in house for
years (yes i mean multiple years) and it works.
As for your specific problem I would first try to eliminate local
problems. Is your hardware working? Are the systems in the clusters
(specifically the disk drives) at the proper ground with respect to
eachother (i suspect not)? Are your HSCs and RA81s up to rev? did you
turn on any bits in the home blocks (specifically in the flags word)?
Certain bits in the home blocks mark the disk as a don't care disk and
cause the monitor not to do any CFS negotiation.
-------
13-May-85 14:26:54-PDT,3231;000000000000
Mail-From: BILLW created at 13-May-85 14:26:29
Date: 13 May 1985 14:26-PDT
Sender:
[email protected]
Subject: Re: FTP spool
From: William "Chops" Westfield <
[email protected]>
Cc:
[email protected]
Message-ID: <[SU-SCORE.ARPA]13-May-85 14:26:27.BILLW>
In-Reply-To: The message of Mon 13 May 85 09:38:04-CDT from
[email protected]
I have an FTP spooler based on a somewhat out of date version of the
VAF@CMU tops-20 user FTP program. It seems to work pretty well,
assuming that the systems that you are sending to dont hang...
Sources/etc are in SRI-KL:<BILLW.SATZ-TAPE>QFTP.*
Here is QFTP.HLP:
Run the program <ABN.BILLW>QFTP.EXE. It will look like an ordinary
FTP (in fact, It will work as an ordinary FTP). There is one new
command called SPOOL which takes as its argument the name of a control
file (the default is QFTP.CTL). The Control File can contain any of
the following commands:
LOGFILE local-filename
This is the name of the file that will get typeout from the
program, and is optional. If provided, QFTP will continue
in the background, writing its progress to the specified file.
If this command is omitted, QFTP will not transfer to background,
and will write reports to the terminal (this mode is suitable
for running as a batch job, for example).
HOSTINFO hostname username password
The remote host and account.
LOCALFILES wildcard-filespec
The files to send.
FOREIGNFILES wildcard-filespec
What the sent files will be called on the remote system. If
a wildcard is used in a field, then that field will be replaced
with the corresponding field from the source file. A directory
may be specified, in which case it will be sent tops20 style
(enclosed in <>). For example if the file currently being sent
is TEST.OUTPUT, and the FORIEGNFILES argument is <TEST>*.RESULTS,
then FTP will attempt to send the file to <TEST>TEST.RESULTS.
DELIVEREDFILES local-filename
This is what the file should be renamed to on the local system
after it has been successfully sent. It follows the same rules
as FORIEGNFILES in terms of wildcards. Files should be deleted
if no DELIVEREDFILES entry exists in the CTL file. (untested)
SLEEPTIME <time in seconds>
This controls how long the spooler will sleep in between
each scan for files to transmit (or each check while waiting
for the host to come up). The default is 5 minutes.
VERBOSE 0 or 1
A one will cause full (verbose) FTP information messages
to be recorded in the log file or sent to the terminal.
When running as a spooler, QFTP will wake up every SLEEPTIME minutes
to check whether it is possible to transfer some more files (ie, files
to be sent exist, remote host is up).
Some errors are fatal in the sense that QFTP will stop trying -
This includes an error in the control file, or an inability to
log in to the remote host using the username and password provided.
For most of the other possible errors, QFTP will just keep trying.
The spooler can be stopped cleanly by creating a file STOP-QFTP in the
connected directory. The spooler will stop the next time it wakes up.
The STOP-QFTP file is deleted. (COPY NUL: STOP-QFTP. works fine)
13-May-85 16:08:31-PDT,1423;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 13 May 85 16:07:45-PDT
Date: Mon 13 May 85 16:06:51-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: FTP spool
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Mon 13 May 85 07:48:50-PDT
If you want to just print files on a remote UNIX or TOPS-20 system, or to
have those systems print on your local host, we have some remote spooling
software that you might be interested in. The software interfaces to Galaxy
and uses the UNIX 4.2BSD remote lineprinter protocol.
LPD is the name of the program that absorbs print requests. The copy of LPD
we're running at Stanford is a rewrite by Bill Palmer of the LPD written by
Chris Maio at Columbia. The major change was to make LPD multi-forking so
that one busy host wouldn't tie up the entire server. The Sierra DEC-20
currently acts as a remote printer for eight or so UNIX hosts.
TCPSPL is the name of the program that sends print requests to foreign
systems. It was written by Bjorn Lindskog at the University of Washington.
We're using his TCPSPL on Sierra to spool to five laserprinters on UNIX hosts.
Copies of the sources for these programs live in PS:<ANONYMOUS> on Sierra.
The files are LPD.MAC, LPDQSR.MAC, TCPSPL.MAC, and LPFORM.TXT.
Kirk
-------
13-May-85 18:48:14-PDT,973;000000000000
Mail-From: MRC created at 13-May-85 18:47:35
Date: Mon 13 May 85 18:47:35-PDT
From: Mark Crispin <
[email protected]>
Subject: MM/domains
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
I've received a few questions about whether or not MM will
support domains. In a word, YES. Most of the prerequisite code
to make MM "domain ready" is already done; what is needed now is
the actual domain support to interact with the monitor's GTDOM%
software. I also intend to continue support of the non-domain
functionality, so all you Milnet sites won't get cut off.
Also in the works is a project to break up the main MM
module so it assembles under 6.1 MACRO/MACSYM/MONSYM. The claim
is that MACRO is more or less frozen so it ought to be possible
to fix MM and solve this once and for all.
MM isn't dead -- keep those cards and letters coming!
-- Mark --
-------
13-May-85 19:42:58-PDT,490;000000000000
Return-Path: <
[email protected]>
Received: from ucla-locus.arpa by SU-SCORE.ARPA with TCP; Mon 13 May 85 19:40:59-PDT
Date: Mon, 13 May 85 19:35:24 PDT
From: Ted Kim <
[email protected]>
To: TOPS20@su-score
Subject: alias features for the EXEC
Message-ID: <
[email protected]>
Has anyone added alias features to the EXEC like those found
in the UNIX csh? or know of anyone that has?
--------
Ted Kim
14-May-85 14:07:26-PDT,939;000000000000
Return-Path: <
[email protected]>
Received: from BBNF.BBN.COM by SU-SCORE.ARPA with TCP; Tue 14 May 85 14:05:57-PDT
Date: 14 May 1985 17:06-EDT
Sender:
[email protected]
Subject: Re: MM/domains
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNF.BBN.COM]14-May-85 17:06:08.CLYNN>
In-Reply-To: The message of Mon 13 May 85 18:47:35-PDT from Mark Crispin <
[email protected]>
Mark,
We merged ISI's domain code into GTHST% is such a way that
we can use your mail system without changing ANY of the mail code,
including MM, MMAILR, Hermes, et. al. Basically, GTHST% uses the
domain code; if it fails, it then uses the host tables. All of our
utility routines, etc., which used GTHST% now function in the domain
system without any changes to their code. Of course, you might want to
change things to use the added functionality of the new GTHST%, but it
isn't urgent.
Charlie
14-May-85 16:19:14-PDT,1646;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 14 May 85 16:17:25-PDT
Date: Tue 14 May 85 17:15:46-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: MM/domains
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Tue 14 May 85 15:06:00-MDT
Charlie -
That is good news! It fits my expectations, but it is good to
hear it anyway. That at least means we have upwards compatibility
in the same sort of environment, but I'm concerned about the following
issues:
(1) which Internet address has SMTP service? Right now MMailr
assumes that the primary address has SMTP, but I have heard rumblings
about different addresses for different services. Actually, I would
like to have GTJFN% do the right thing, as in
TCP:;FOREIGN-HOST:FOO.BAR.BAZ.COM;FOREIGN-PORT:SMTP
and not worry about it at all in MMailr. Ideally, the monitor would
even be smart enough to try alternative addresses.
(2) translation of nickname to primary name. Right now all my
software accomplishes this by the identity function "address to name
of name to address of given name". I have heard rumblings of multiple
primary names translating to the same address with entirely different
implications once it gets there. It sounds to me like this is in fact
something which needs a GTxxx% function to itself.
(3) mailbox/domain interaction. I'm not sure how this all works
yet or of how much help GTDOM% will provide, but I do want to extend
MMailbox so it can provide full functionality in this area.
-- Mark --
-------
14-May-85 17:51:40-PDT,16538;000000000000
Return-Path: <
[email protected]>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Tue 14 May 85 17:49:34-PDT
Date: Tue 14 May 85 19:55:26-EDT
From: Rich Cower <
[email protected]>
Subject: [
[email protected]: Alice's PDP-10]
To:
[email protected]
i found this interesting. it has a lot to do with pdp-10's and little to
do with everything else. it is also long. i left the header(s) on it to
show where it came from.
.enjoy...rich
---------------
Return-Path: <
[email protected]>
Received: from decwrl.ARPA by COLUMBIA-20.ARPA with TCP; Tue 14 May 85 18:16:08-EDT
Received: by decwrl.ARPA (4.22.01/4.7.34)
id AA16656; Tue, 14 May 85 15:13:59 pdt
From:
[email protected]
Return-Path: <genrad!enmasse!maynard!campbell>
Received: by genrad.uucp (4.12/1.0)
id AA00531; Tue, 14 May 85 08:30:38 edt
Date: Tue, 14 May 85 08:30:38 edt
Message-Id: <
[email protected]>
To:
[email protected]
Subject: Alice's PDP-10
From campbell Wed May 8 23:22:42 1985
>From uuenmass Wed May 8 18:15:39 1985 remote from enmasse
>From decvax!decwrl!dec-rhea!dec-viking!hess Wed May 8 16:55:34 1985 remote from genrad
Received: by genrad.UUCP (4.12/4.7)
id AA21207; Wed, 8 May 85 16:55:34 edt
From: genrad!decvax!decwrl!dec-rhea!dec-viking!hess
Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34)
id AA25100; Wed, 8 May 85 11:29:11 pdt
Message-Id: <
[email protected]>
Date: Wednesday, 8 May 1985 11:17:58-PDT
To: decvax!genrad!enmasse!maynard!campbell
Subject: You can get anything you want....
Status: RO
------------ Begin message from: ELROND::MITTON of 07-May-1985
From: ELROND::MITTON "Dave Mitton 07-May-1985 1556" 7-MAY-1985 16:11
To: SPENCE,BENCE,MIERSWA,BAGELS::ROSENBAUM,VIKING::HESS
Subj: Alice's PDP-10
From: RHEA::DECWRL::"lwa@mit-mrclean" "Larry Allen" 07-May-85 03:26 PM
To: mitton%elrond.dec@decwrl
Subject: Alice's PDP10
Received: from DECWRL by DEC-RHEA with SMTP; Tue, 7 May 85 12:04-PDT
Received: from mit-mrclean.ARPA (mit-mrclean.arpa.ARPA) by decwrl.ARPA (4.22.01/4.7.34)
id AA00826; Tue, 7 May 85 11:01:43 pdt
Received: by mit-mrclean.ARPA (4.12/4.7)
id AA27625; Tue, 7 May 85 11:30:26 edt
Date: 7 May 1985 1130-EDT (Tuesday)
Message-Id: <
[email protected]>
;;; With thanks (and apologies) to Chris Stacy, Alan Wechsler, Noel
;;; Chiappa, Larry Allen, and of course Arlo Guthrie, and particularly
;;; to Ann Marie Finn who is a kind soul and not at all like the
;;; person portrayed herein. --sra 3 May 85
This song is called "Alice's PDP-10". But Alice doesn't own a PDP-10,
in fact Alice isn't even in the song. It's just the name of the song.
That's why I called this song "Alice's PDP-10".
You see, it all started about two incompatible monitor versions ago,
about two months ago on a Tuesday, when my friend and I SUPDUP'd over
to MIT-OZ to pick up some hackers to go out for a Chinese dinner. But
AI hackers don't live on MIT-OZ, they live on various assorted lispms
and such, and seeing as and how they never log in except via the file
server, they hadn't gotten around to doing filesystem garbage
collection for a long time.
We got over there, saw 600 pages free, 10000 pages in use on a 5 pack
PS:, and decided it would be a friendly gesture to run CHECKD for them
and try to reclaim some of that lost space. So we reloaded the system
with the floppies and the switch registers and other implements of
destruction, and answered "Y" to RUN CHECKD?
But when we got the system up and tried to release all the lost pages
there was a loud beeping and a big message flashed up on our screen
saying:
PERMISSION DENIED BY ACJ
Well, we'd never heard of a version of ACJ that would let you go into
MDDT from ANONYMOUS but not run CHECKD, and so, with tears in our
eyes, we headed off over the Chaosnet looking for a filesystem with
enough free pages to write out the LOST-PAGES.BIN file. Didn't find
one...
Until we got to XX-11, and at the other end of XX-11 was another MIT
Twenex, and in PS:<OPERATOR> on that MIT Twenex was another
LOST-PAGES.BIN file. And we decided that one big LOST-PAGES.BIN file
was better than two little LOST-PAGES.BIN file, and rather than page
that one in we thought we'd write ours out. So that's what we did.
Went back to OZ, found some hackers and went out for a Chinese dinner
that couldn't be beat, and didn't get up until the next morning when
we got a SEND from Ann Marie Finn. She said, "Kid, we found you
initials in SIXBIT in the right half of a POPJ at the end of a two
megaword core dump full of garbage, just wanted to know if you had any
information about it". And I said, "Yes ma'am Ann Marie, I cannot tell
a lie, I put that XUNAME into that halfword".
After talking back and forth with Ann for about 45 messages we arrived
at the truth of the matter and Ann said that we had to go rebuild the
bittable and we also had to come down and talk to her in room
NE43-501. Now friends, there was only one of two things that Ann
could of done with us down at room 501, and the first one was that she
could have hired us on the spot for actually knowing enough about
Twenex to screw it up that badly, which wasn't very likely and we
didn't expect it, and the other was that she could have bawled us out
and told us never to be seen hacking filesystems again, which was what
we expected. But when we got to room 501 we discovered that there was
a third possibility that we hadn't even counted upon, and we was both
immediately de-wheeled. CD%DIR'ed. And I said "Ann, I don't think I
can rebuild the bittable with this here FILES-ONLY bit set." And she
said "XOFF, kid, get into this UDP packet" and that's what we did and
rode up to the square bracket asciz slash scene of the crime slash
close square bracket.
Now friends, I want to tell you about the ninth floor of building NE43
where this happened. They got three KL10s, 24 LISPMs, and about 32
VAXen running 4.2 unix. But when we got to the square bracket asciz
slash scene of the crime slash close square bracket there was five
twenex hackers past and present, this being the biggest lossage yet by
an RMS clone and everybody wanted to get in their suggestion for a new
system daemon that would have kept it from ever having happened in the
first place. And they was using up all kinds of debugging equipment
that they had lying around on V3A SWSKIT tapes. They were doing DSs,
MONRDs, and RSTRSHs, and they made 27000 pages of core dumps and photo
files on an RP06 with comments and -READ-.-THIS- files to be used as
evidence against us.
After the ordeal, Ann took us back downstairs and left us with the CLU
hackers. She said "Kid, I'm gonna leave you with the CLU hackers. I
want your jsys manual and your ROLM DTI". I said "Ann, I can
understand your wanting my jsys manual so I won't remind the CLU
hackers of grody things like operating systems, but what do you want
my DTI for?" and she said "Kid, we don't want any VTS errors". I said
"Ann, did you think I was going to try to crash the system for
littering?" Ann said that she was making sure, and friends, Ann was,
'cause she cleared all my left-hand privs bits so I couldn't logout.
And she disabled the TREPLACE command so I couldn't crock in an
XCT [0] instruction, cause an illegal instruction interrupt to MEXEC,
and sneak into MDDT. Yeah, Ann was making sure, and it was about four
or five hours later that Chiappa (remember Chiappa? This song's never
even mentioned Chiappa) Chiappa came by and with a few gratuitous
insults to the CLU hackers bailed us out of there, and we went out and
had another Chinese dinner that couldn't be beat, and didn't get up
until the next morning when we all had to go to LCS Computational
Resources staff meeting.
We walked in, sat down. Ann came in with the RP06 disk pack with the
27000 pages with the comments and the -READ-.-THIS- files and a two
liter coffee mug, sat down. Esther Felix comes in says "All rise", we
stood up, Ann stood up with the 27000 page RP06 pack, and Dave Clark
comes in with an IBM PC. He sits down, we sit down, Ann looks at the
IBM PC. Then at the 27000 page RP06 pack, then at the IBM PC, then at
the 27000 page RP06 pack, and began to cry, because Ann had come to
the realization that it was a typical case of 36%8==4 and that there
was no way to display those last four bits, and that Dave wasn't gonna
look at the 27000 pages of core dumps and photo files on the RP06 pack
with the comments and -READ-.-THIS- files explaining what each one was
to be used as evidence against us.
And we were permanently assigned to the batch dregs queue and had to
rebuild the bittable (in the batch dregs queue). But that's not what
I came here to talk about. I came here to talk about DEC.
======================================================================
They got a building up there in Marlboro where you walk in and get
averted, diverted, inverted, reverted, and perverted. I went up there
one day to pick up a new copy of the tools tape. Drove down to Philly
for a Greatful Dead concert the night before, so I looked and felt my
best when I went in that morning. 'Cause I wanted to look like a real
live twenex hacker from MIT. I wanted to feel like, I wanted to be a
real live twenex hacker from MIT. I walked in and I was hung down,
brung down, hung up, and spaced out. The receptionist hands be a
piece of paper saying "Kid, the EDIT-20 maintainers are polling user
opinions today and would like you to stop by room 604 while you're
here."
I walked in there and I said "Droids, I want to lose. I mean, I want
to lose. I want to see line editors on CRTs and nulls in my files.
Write 36 bit ascii that can't be read except with the monitor
filtering it. I mean LOSE, LOSE, LOSE!" And I started jumping up and
down yelling "LOSE, LOSE", and Kevin Paetzold came in wearing his
moose ear hat and started jumping up and down with me yelling "LOSE,
LOSE", and a DEC sales rep came over, put an arm around my shoulder,
and said "How'd you like me to show you a *real* editor that has
macros and things like that? We have one, it's called TV...."
Didn't feel too good about it.
Proceeded on down the hall getting more diversions and perversions.
Man, I was in there for two hours, three hours, four hours, I was in
there for a long time, and they was doing all kinds of mean nasty ugly
things, and I was just having a tough time there. They was diverting
and inverting every single part of me and they was leaving no bit
untouched.
Finally I got to the very last office (I'd been in all the rest), the
very last desk, after that whole big thing there, and I walk over and
say "what do you want?" and the man says "Kid, we only got one
question: have you ever been dewheeled?"
So I proceeded to tell him the story of the 10600 page five pack PS:
with full orchestration and five part harmony and other phenomena and
he stopped me right there and said "Kid, did you ever get hauled on
the carpet for it?"
So I proceeded to tell him about the 27000 page RP06 pack with the
comments and the -READ-.-THIS- files and he stopped me right there and
said "Kid, I want you to go sit over there on that bench marked Large
Systems SIG. NOW, KID!"
I, I walked over to the bench there... See, the LCG group is where
they put you if they think you may not be compatible with the rest of
DEC's product line.
There was all kinds of mean nasty ugly people there on the bench...
Chaosnet designers... Lisp hackers... TECO hackers. TECO hackers
right there on the bench with me! And the meanest one of them, the
hairiest TECO hacker of them all was coming over to me. And he was
mean and nasty and horrible and undocumented and all kinds of stuff.
And he sat down next to me and said:
.(675041640744.f6w007141004745.f6w643700000000.f6),.fx*[0@ft^]0$w^\
And I said "I didn't get nothing, I had to rebuild the bittable in
queue six" and he said:
.(675041640067.f6w416300715765.f6w004445675045.f6
455445440046.f6w576200535144.f6w370000000000.f6
),.fx*[0@ft^]0$w^\
And I said "Littering". And they all moved away from me on the bench
there, with the hairy eyeball and all kinds of mean nasty ugly stuff
until I said "and making undocumented changes to the default EMACS key
bindings". And they all came back, shook my hand, and we had a great
time on the bench talking about Chaosnet hacking and Lisp interpreters
written in TECO, and everything was fine. And we were eating Peking
ravs and smoking all kinds of things until the guy from DDC came over,
had some paper in his hand, said:
KIDS-THIS-SPR-FORM-HAS-FIFTY-EIGHT-LINES-THIRTY-SEVEN-BOXES-AN'-
SIXTY-EIGHT-QUESTIONS-WE-WANT-TO-KNOW-THE-DETAILS-OF-THE-BUG-THE-
LOAD-FACTOR-WHEN-IT-HAPPENED-AND-ANY-OTHER-KIND-OF-THING-YOU-GOT-
TO-SAY-WE-WANT-TO-KNOW-THE-F-S-GUY'S-NAME-AND-HOW-MANY-TRACKS-ON-
YOUR-TAPE-DRIVE-AND-ANY-OTHER-KIND-OF-THING-YOU-GOT-TO-SAY-
and he talked for forty-five minutes and nobody understood a word
that he said or why we were doing this but we had fun filling out the
forms in triplicate and speculating on why we were filling out SPRs on
unsupported products.
I filled out the special form with the four-level macro defining
macros. Typed it in there just like it was and everything was fine.
And I put down my keyboard, and I switched buffers, and there ... in
the other buffer... centered in the other buffer... away from
everything else in the buffer... in parentheses, capital letters, in
reverse video, read the following words:
"Kid, have you taken the ``VMS for TOPS-20 managers'' course yet?"
I walked over to the man and I said "Mister, you got a lot of damned
gall asking me if I've taken the ``VMS for TOPS-20 managers'' course
yet. I mean... I mean... I mean, I'm sitting here on the bench, I'm
sitting here on the LCG SIG bench, 'cause you want to know if I'm
braindamaged enough trade my PDP-10 for partial credit on a system
that doesn't even handle filename completion after being a litterbug."
He looked at me and said "Kid, the front office don't like your kind,
so we're going to put you on our VAX/VMS mailing list." And friends,
somewhere down in the NE43 receiving room is a large trash barrel with
a big sign on it that says "VAX/VMS documents".
And the only reason I'm singing you the song now is that someday
you may know somebody in a similar situation... or you may be in a
similar situation. And if you're in a situation like that there's
only one thing you can do, and that's call up the Digital Educational
Services office nearest you and sing "You can hack anything you want
with TECO and DDT" and hang up.
You know, if one person, just one person, does it, they may think he's
really dangerous and they won't take his machine.
And if two people do it, in harmony, they may think they're both ITS
hackers and they won't touch either of them.
And if three people do it! Can you imagine three people calling up,
singin' a bar of "Alice's PDP-10" and hanging up? They may think it's
an re-implementation of the Chaosnet protocol.
And can you imagine fifty people a day? I said FIFTY people a day,
calling up, singin' a bar of "Alice's PDP-10" and hanging up?
Friends, they may think it's a MOVEMENT, and that's what it is: THE
36-BIT ANTI-LOSSAGE MOVEMENT! And all you gotta do to join is to sing
it the next time it comes up to the head of the GOLST.
With feelin'.
You can hack anything you want, with TECO and DDT.
You can hack anything you want, with just TECO and DDT.
$U in and begin to hack.
Twiddle bits in a core dump and write it back.
You can hack anything you want, with TECO and DDT.
(But be careful typing <RET>)
Just with TECO and DDT!
------------ End forwarded message
-------
15-May-85 19:41:04-PDT,890;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 15 May 85 19:38:34-PDT
Date: Wed 15 May 85 19:36:31-PDT
From: Mark Crispin <
[email protected]>
Subject: don't run MDDT on a Pup NVT!
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
I've determined that under certain circumstances, Pup input can
eat up all of MDDT's internal stack. This happens if it gets as far
as the CALL CDSCCW(T3) at PHYCCW+3 which is called from BLDCCW in ENET.
I believe that increasing MDDT's NPDL value from ^D100 to ^D150
will still fit and leave the world safe for MDDT'ing on Pup NVT's.
Signed,
-- a person still recovering from the aftermath of having crashed SUMEX
with zillions of users logged in when all he did was type "MDDT<CR>"
-------
16-May-85 12:31:59-PDT,983;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 16 May 85 12:30:16-PDT
Date: Thu 16 May 85 12:29:35-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: don't run MDDT on a Pup NVT!
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Wed 15 May 85 19:42:46-PDT
Very strange. I run MDDT on PUP NVT's all the time. My office terminal
has been an Ethertip line for as long as there have been Ethertips talking
to -20's. I've never seen a crash like you describe. If you have a theory
as to what circumstances would lead to such a crash, please let me know.
I have seen once instance of "MDDT<CR>" crashing a system. It happened at
the University of Washington after they installed Stanford 5.3. The problem
turned out to be building a monitor with overlapping PSECT's. Fixing that
made the problem go away.
Kirk
-------
16-May-85 16:12:33-PDT,5565;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 16 May 85 16:10:48-PDT
Date: Thu 16 May 85 16:09:46-PDT
From: Mark Crispin <
[email protected]>
Subject: [Mark Crispin <
[email protected]>: MDDT on Pup NVT's]
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Kirk -
It does not happen reproducably. But it did happen, to
Frank Gilmurray at Score over a year ago, and to me here at SUMEX
yesterday. Obviously a 1 in 1000 type happenstance. Both
instances were cause for extreme embarassment and injured
feelings. The symbol in DDT is LPDL, not NPDL as I mistakenly
said in the message.
I've enclosed the message showing what happened to MDDT's
PDL. As you can see, all ^D100 locations are in use and
accounted for without any obvious recursion. The conclusion I
took is that MDDT's PDL is just not large enough. Setting it to
^D150 leaves us still with 20 free locations in the MDDT page.
-- Mark --
---------------
Mail-From: CRISPIN created at 15-May-85 19:27:28
Date: Wed 15 May 85 19:27:27-PDT
From: Mark Crispin <
[email protected]>
Subject: MDDT on Pup NVT's
To:
[email protected],
[email protected],
[email protected],
[email protected]
cc:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Folks -
It's confirmed. The crash this afternoon was not due to any
carelessness on my part. It was due to simply running MDDT at
all on a Pup NVT. There simply is not enough MDDT stack space to
support MDDT terminal I/O on a Pup NVT. I really feel bad about
having crashed the system this afternoon, but any of us could
have tripped up against this bug. I'm surprised it hasn't bitten
all of the Stanford systems a lot more often!!
My conclusion is that we need to increase LPDL in DDT.MAC
from ^D100. It looks to me like we can increase it to ^D150 or
so and still have a few words left.
Here's the MDDT stack, from the dump:
FILDDT>get dump.cpy.181
[ACs copied from BUGACS to 0-17]
[Looking at file DUMP.CPY.181]
ep$u
P/ 317667 *** MDDT STACK OVERFLOWED, CAUSE
OF MONPDL BUGHLT ***
*** START OF MDDT STACK ***
317524/ T1,,MDDTX+62 *** MDDT "PUSHJ P,TIN" CALL AT L2 ***
317525/ .JBVER *** MDDT LINSPC ***
317526/ SBSERF+107,,IDXPGA+31 *** MDDT CHINP ***
*** MDDT INTERNAL TEXT% CALLED ***
317527/ -1 *** TEXTI% INTDF ***
317530/ -374,,UPDL+3 *** TEXTI% MPP **
317531/ T1,,707771 *** TEXTI% MONPC **
317532/ CAIA PKOWAI+5 *** TEXTI% CX ***
*** TRVAR IN TEXTI% ***
317533/ T1,,707307 *** FP RESTORE FROM TRVAR ***
317534/ T1,,707734 *** FLG2 ***
317535/ T1,,707521 *** UMSK WD 1 ***
317536/ T1,,IMMAP1#+17 *** UMSK WD 2 ***
317537/ T1,,707307 *** UMSK WD 3 ***
317540/ JSLST+304,,JSLST+53 *** UMSK WD 4 ***
317541/ 341000 *** CCNT ***
317542/ 0 *** CCPTR ***
317543/ T1 *** CRPTR ***
317544/ AOBJP P3,@.BOUT+14(P2) *** COC WD 1 ***
317545/ AOBJP P3,@RXPARS+2(Q1) *** COC WD 2 ***
317546/ AOBJP P3,@.BOUT+14(P2) *** OURCOC WD 1 ***
317547/ OPEN @RXPARS+2(Q1) *** OURCOC WD 2 ***
317550/ AOJN T2,@174162 *** MOD ***
317551/ -104,,317563 *** STKP ***
317552/ T4 *** MASK WD 1 ***
317553/ -20 *** MASK WD 2 ***
317554/ -4,,JSTAB+760 *** MASK WD 3 ***
317555/ SETZ JSLST+355 *** MASK WD 4 ***
317556/ SETZ JSLST+355 *** MASK WD 5 ***
317557/ 0 *** FWTH ***
317560/ -1 *** TTYIND ***
317561/ 0 *** ADDPAR ***
317562/ T1,,.SAV2+3 *** CMDBAS ***
317563/ T1,,.TRRET *** TRVAR UNWIND ***
*** TEXTI% CODE ***
317564/ T1,,NINSR1#+2
317565/ -1
317566/ -135,,317532
317567/ T1,,RDBIN2#+2
317570/ PKOWAI+6
*** ENTERING IO ***
317571/ T1,,SLBIN#+3
317572/ -134,,317533
317573/ GTBSIZ+2
317574/ T1,,.TRRET
317575/ T1,,BYTIN1#+6
317576/ 0
317577/ T1,,T1
317600/ T1,,.STKRT
317601/ T1,,BYTIA1#+2
317602/ T1,,BYTINX#+17
*** ENTERING TTYSRV ***
317603/ T1,,TTYINB#+7
317604/ T1,,TCI3#+11
317605/ AOJ @204162(P1)
317606/ BUTDRT+1
317607/ T1,,TCIECO#+7 *** TTYSRV ECHOING ***
317610/ .JBEDV+2
317611/ T1,,TC1C#
317612/ SBSERF+107,,IDXPGA+30
317613/ SBSERF+107,,IDXPGA+30
317614/ 0
317615/ T1,,RESTQ
317616/ T1,,TCOY3# *** TTYSRV OUTPUT ***
317617/ .JBEDV+2
317620/ T1,,TCOU5#+23
317621/ SBSERF+107,,IDXPGA+30
317622/ TTYDTB
317623/ SBSERF+107,,IDXPGA+30
317624/ PHYPZS+14,,TTYDTB
317625/ 736031
317626/ T1,,PNVBUF+5 *** ENTERING PUP ***
317627/ 736031
317630/ T1,,.SAV22+2
317631/ 0
317632/ 736031
317633/ T2,,T2
317634/ T1,,.STKRT
317635/ T1,,PNVBFF#+11
317636/ T1,,CHKBO4#+4
317637/ T1,,SNDADA#+12
317640/ T1,,SNDPU1#+4
317641/ T1,,PUTPUP#+16
317642/ APRID 420000
317643/ T1,,PUPASC+4
317644/ T1,,PUPOU0#+20
317645/ 0
317646/ T1,,DECIQZ+3
317647/ T1,,BLDIO2#+13 *** ENTERING ENET ***
317650/ .JBBLT+12
317651/ T1,,.SAV1+2
317652/ T1,,ENC3M1#
317653/ P1,,FLSRBX+16
317654/ UTPGS+627
317655/ T3,,T3
317656/ T1,,.STKRT
317657/ T1,,BLDCC0#+7
317660/ T1,,.NCT1
317661/ 777777
317662/ P1,,BADBAT+10
317663/ P1,,FLSRBX+3
317664/ 0
317665/ -75,,317572
317666/ T1,,RESTP *** ENTERING PHYSIO ***
317667/ T1,,PHYCCW+4 *** END OF MDDT STACK!!! ***
-------
-------
16-May-85 16:36:06-PDT,616;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 16 May 85 16:35:28-PDT
Date: Thu 16 May 85 16:34:14-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: [Mark Crispin <
[email protected]>: MDDT on Pup NVT's]
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Thu 16 May 85 16:13:17-PDT
Okay, I believe. I just took a look at the 6.1 DDT -- DEC recently increased
the MDDT stack to 256. words, apparently because of similar problems with
DECNET.
Kirk
-------
17-May-85 17:34:04-PDT,973;000000000000
Return-Path: <
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Fri 17 May 85 16:35:46-PDT
Date: 17 May 1985 1634-PDT
From:
[email protected] (Dwight Hare)
Subject: Misfeature in SAVE/GET
To:
[email protected]
cc:
[email protected]
I have run into a strange problem where a page disappears through a
SAVE and a GET which causes a MACLISP program to blow up. The disappearing
page is empty (all zeros) and there is some code in the save jsys which
implies that empty pages are not saved. Unfortunately, the GET of that
saved image produces a memory map without the page being marked as existing.
A reference to this page causes an ill mem ref from Maclisp (which has
this error interrupt enabled for debugging purposes).
It seems to me that SAVE and GET in conjunction should ensure that all
existant pages are preserved through a SAVE and a GET. Does anyone
know of a simple patch to fix the problem?
Dwight
-------
17-May-85 23:21:37-PDT,859;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 17 May 85 23:21:26-PDT
Date: Fri 17 May 85 23:51:42-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: Misfeature in SAVE/GET
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected] (Dwight Hare)" of Fri 17 May 85 17:34:00-MDT
Dwight -
This is not a monitor bug, nor is it a monitor misfeature. It's
a MacLisp misfeature. MacLisp insists on treating TOPS-20's pager the
same way it treats the ITS pager; MacLisp was poorly ported. Macsyma
is even worse. So far as I can tell, if you want that style of Lisp
you are better off using Chuck Hedrick's Common Lisp implementation,
which not only is a modern Lisp but also was designed with TOPS-20 in
mind.
-- Mark --
-------
18-May-85 17:43:44-PDT,1593;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 18 May 85 17:43:23-PDT
Date: Sat, 18 May 1985 18:43 MDT
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: Another oldie: GUIDE
Back in and around v1 days, there was a program called GUIDE, an
online reference to the Commands Reference Guide. Quite handy back
then for me, and could be quite handy today for the new remote users I
keep adding daily. The problem is that although GUIDE source can be
found, the program that generates COMTAB from GUIDE.MEM seems to be
lost. GUIDE.MEM is still the v1 version, and without the COMTAB
generator, an effort to update GUIDE.MEM would be useless.
Thus, I have two questions: does anybody have the COMTAB generator
stashed away and can make it available, along with, perhaps, a newer
GUIDE.MEM? Secondly, has anyone developed something even better than
GUIDE? I know that there are variants of HELP, including a package
that was presented at the last DECUS in an overlapped session I
couldn't attend. Perhaps someone has that package online?
In short, I'm looking for just about anything available online to help
the new user. I already have "TOPS20" from Rutgers and DOC from
Sandia. And, as they say on the other lists, I'll be glad to
summarize any responses. I'll also provide the disk space for
redistribution of any files you wish to make available. Please reply
directly to me and not burden the whole list.
Thanks,
Frank
19-May-85 18:31:14-PDT,1055;000000000000
Mail-From: BILLW created at 19-May-85 18:31:12
Date: Sun 19 May 85 18:31:12-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: TTYINI - new features plus bug fixes.
To:
[email protected]
Ive done some work on TTYINI.
1) added SUN48 terminal type
2) now knows about TCP hosts in addition to PUP hosts.
3) fixed:: /xxx-DEFAULT didn't work. The line number was never
initialized before calling CHKTVT/CHKPUP/etc.
4) If a host exists (from SETTTY), but was not in TTYINI.NET-BIN,
TTYINI would not change the terminal type. Now it retries
using the local net/host/tty values.
This has been running on Score and Sushi for several days now and
seems to work. Score::<FINGER.SOURCES>TTYINI.MAC and Sierra::
(same) have both been updated. The later has a bunch of other
changes by FMF that haven't been announced yet, and may not
be ready for distribution...
Similar changes have been made to the 6-EXEC, but have not been
installed in the 6-1-exec yet (soon...)
Enjoy
BillW
-------
20-May-85 17:48:18-PDT,1240;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 20 May 85 17:43:33-PDT
Date: Mon 20 May 85 17:40:21-PDT
From: Mark Crispin <
[email protected]>
Subject: TTYDAS routine
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
The TTYDAS routine is intended to be runnable NOSKED; its +1 return
has a scheduler test routine to MDISMS on if 1B0 is set. Unfortunately,
on TVT's TTYDAS calls TVTDET which in turn invokes LCKCAL which gets
to SETLCK which gleefully blocks without any checking. The result is an
NSKDIS bughlt.
The Stanford and PANDA monitors work around this by not going NOSKED
around the TTYDAS call in ATACH% (at ATACHB+nL in MEXEC.MAC) which is the
place this bug is most often hit. At one time Score was cracking on that
problem at least once a day before I put that in.
However, this is a gross and disgusting kludge. You really do want
to be NOSKED in that portion of ATACH. Before I set about to rewrite the
TVTDET routine to use a non-blocking form of LCKCAL/SETLCK, I'd like to
know if anybody else has already solved this problem.
-- Mark --
-------
21-May-85 16:19:10-PDT,821;000000000000
Mail-From: MRC created at 21-May-85 16:14:24
Date: Tue 21 May 85 16:14:24-PDT
From: Mark Crispin <
[email protected]>
Subject: new MAISER on Score
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
With AMES-VMSB's bogus headers floating around, I discovered
that MAISER never correctly handled a-d-l's with more than one
entry in them. In fact, MAISER gleefully tossed away all but the
very first host (e.g. the most recent) in the a-d-l. The problem
was due to an erroneous tying off with a null. I decided that the
way a-d-l's were parsed by MAISER was bogus anyway.
The new version is on SCO:<MM>MAISER.MAC.138. You can get the
EXE from that directory and install it as your SYSTEM:MAISER.EXE.
-- Mark --
-------
23-May-85 05:27:27-PDT,1769;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 23 May 85 05:24:20-PDT
Date: 23 May 1985 0818-EDT
From: Tom Blinn <BLINN at DEC-MARLBORO>
To: tops-20 at SU-SCORE
Subject: DEC-10 hardware for free to a good home..
Message-ID: <"MS10(2124)-1+GLXLIB1(1135)" 12113284321.15.275.22947 at DEC-MARLBORO>
Received from INFO-CPM, seems more likely someone on this list might
know someone who might be interested..
Tom
- - - - - - - Begin message from: "Webb Mike"@LLL-MFE.ARPA
Return-Path: <
[email protected]>
Received: from AMSAA by DEC-MARLBORO.ARPA with TCP; Tue 21 May 85 14:15:14-EDT
Received: from lll-mfe.arpa by AMSAA.ARPA id a025728; 21 May 85 13:06 EDT
Date: Tue, 21 May 85 09:52 PDT
From: "Webb Mike"@LLL-MFE.ARPA
Subject: dec-10 equipment
To:
[email protected]
one of my ex-customers(they just un-plugged it!) has some DECSystem-10
hardware they would like to get rid of. This is OLD stuff and it can be
had for the cost of shipping. the following is a list of the stuff that
is available:
2ea DF10C 22-bit data channel
3ea RH10 Massbuss Interface(use with above)
4ea MG10 128 k-36 bit core memory boxes
10-12 rp04 Disk drives. these have NO PORT MODULES.
All of this equipment was on contract with DEC untill it was turned off
and was in good working order.
if there is a site out there,or if you know of someone who would like
this equipment,please mail me your address and phone number, and i will
put you in touch with the proper people. hope this doesn't violate some
un-spoken rule on advertising on the net,but then it is "FREE TO A GOOD
HOME"!
Mike Webb,
[email protected]
- - - - - - - End forwarded message
--------
23-May-85 08:28:29-PDT,5864;000000000000
Return-Path: <BUDD%BUCS20%
[email protected]>
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Thu 23 May 85 08:28:06-PDT
Received: from bostonu by csnet-relay.csnet id aa04222; 23 May 85 11:09 EDT
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA09502; Thu, 23 May 85 02:34:25 edt
Date: Thu 23 May 85 02:33:10-EDT
From: Phil Budne <BUDD%BUCS20%
[email protected]>
Subject: Changes to SYSDPY for "PEEK" fork display
To: tops-20%
[email protected]
Here is a SRCCOM of changes to SYSDPY (5.4 in this case) to make
it display FORKs indented in a fashion similar to ITS "PEEK".
It makes it much easier to see the tree structure. Appologies
if everyone and their cousin has done this twice, and more cleanly.
And then again more for subjecting you to the SRCCOM, but BostonU
is a CSnet site, and therefore isd hard to FTP from.
===
;COMPARISON OF AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1 AND USR0:<BUDD>SYSDPY.MAC.4
;OPTIONS ARE COMPARE /ALL /ENDLINE /LABEL /MATCH:15
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 1-1 (0)
;<TCPIP.5.1.SYSDPY>SYSDPY.MAC.3, 3-Jan-83 23:29:24, Edit by PAETZOLD
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 1-1 (0)
;USR0:<BUDD>SYSDPYX.MAC.23 4-Feb-85 FM+4H.6M.32S., by BUDD
; Print out FORKs indented tastefully
;<TCPIP.5.1.SYSDPY>SYSDPY.MAC.3, 3-Jan-83 23:29:24, Edit by PAETZOLD
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 1-135 (7326)
SALL ;MAKE FOR NICE MACROS
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 1-138 (7428)
.require sys:macrel
SALL ;MAKE FOR NICE MACROS
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 6-25 (12759)
ND PDLSIZ,40 ;STACK SIZE
ND TMPSIZ,^D50 ;SIZE OF TEMPORARY USE BUFFER
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 6-25 (12883)
ND PDLSIZ,1000 ;[plb] STACK SIZE
ND TMPSIZ,^D50 ;SIZE OF TEMPORARY USE BUFFER
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 20-20 (31295) AFTER DOFORK:
SETOM JOBFRK ;INITIALIZE JOB FORK INDEX
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 20-20 (31427) AFTER DOFORK:
ifn 0,<
SETOM JOBFRK ;INITIALIZE JOB FORK INDEX
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 20-41 (32037) AFTER FRKLOP:
;THE ROUTINES TO HANDLE THE VARIOUS COLUMN OUTPUTS:
XXFORK: MOVE T1,FORK ;GET FORK NUMBER
JRST OCTOUT ;OUTPUT IT AND RETURN
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 20-42 (32178) AFTER FRKLOP:
> ;ifn 0
Setzb t1,t2
Call DoFrk1
Ret
PrFork: Movem t1,JOBFRK
Movem t2,indent
Call Full
Ret ;No more room on screen
Move t2,JOBFRK ;get jfi in t2
MOVE T1,['SYSFK '] ;WANT TO READ SYSTEM FORK TABLE
CALL GETJSB ;READ WORD
Ret
JUMPL T2,R ;IF NEGATIVE, FORK NOT IN USE
MOVEM T2,SYSFK ;SAVE BITS FOR LATER USE
HRRZ T1,T2 ;KEEP ONLY RIGHT HALF
CAIE T1,-1 ;IS THIS FORK ASSIGNED?
SOSL EATNUM ;AND WE HAVE NO LINES TO EAT?
Ret ;NO, DO NEXT ONE
MOVEM T1,FORK ;SAVE SYSTEM FORK NUMBER
SETZM HAVPC ;WE NEED NEW PC'S FOR THE FORK
SETZM HAVID ;AND NEW ID'S FOR THE FORK
CALL DOCOLS ;DO ALL OF THE COLUMNS
Ret
DoFrk1: Stkvar <jfi,ind,inf>
Movem t1,jfi ;save job fork index
Movem t2,ind ;save indentation
Call PrFork ;print me
Move t1,jfi ;get my index back
Call Getinf ;get my inferior list
Ret ; none.
Jumpe t2,Cpopj ;none?
Movem t2,inf ;save
Call FndFrk ;Check it.
Ret
Move t1,inf ;get fork index
Aos t2,ind ;get colm bumped
Pjrst DoFrk2
endsv.
DoFrk2: stkvar <jfi,ind,bro>
Movem t1,jfi
Movem t2,ind
Call GetBro ;get my brother
jrst frk2e
jumpe t2, frk2e ;none?
Movem t2, bro ;save bro jfi
Call FndFrk ;Validate
jrst frk2e ; no go
Move t1,bro
Move t2,ind
Call DoFrk2 ;recurse to end of chain (oldest)
Frk2e: Move t1,jfi ;none older than me
Move t2,ind ;print me and my inferiors
Pjrst DoFrk1
endsv.
;THE ROUTINES TO HANDLE THE VARIOUS COLUMN OUTPUTS:
doind: Skipn t1,indent
Ret
SPACE
sojg t1,.-1
Ret
XXFORK: call doind
MOVE T1,FORK ;GET FORK NUMBER
JRST OCTOUT ;OUTPUT IT AND RETURN
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 28-15 (39878) AFTER TYPPRV:
GETSUP: MOVE T2,T1 ;COPY TO RIGHT AC
MOVE T1,['FKPTRS'] ;THE FORK STRUCTURE TABLE
CALL GETJSB ;READ WORD FROM JSB
RET ;FAILED
LDB T2,[POINT 12,T2,11] ;GET FORK NUMBER OF SUPERIOR
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 28-15 (41522) AFTER TYPPRV:
; [plb] find inferior list -- returns job fork index
GETinf: MOVE T2,T1 ;COPY TO RIGHT AC
MOVE T1,['FKPTRS'] ;THE FORK STRUCTURE TABLE
CALL GETJSB ;READ WORD FROM JSB
RET ;FAILED
LDB T2,[POINT 12,T2,35] ;GET FORK NUMBER OF inferior
pjrst cpopj1
; [plb] find brother list -- returns job fork index
GETbro: MOVE T2,T1 ;COPY TO RIGHT AC
MOVE T1,['FKPTRS'] ;THE FORK STRUCTURE TABLE
CALL GETJSB ;READ WORD FROM JSB
RET ;FAILED
LDB T2,[POINT 12,T2,23] ;GET FORK NUMBER OF brother
pjrst cpopj1
GETSUP: MOVE T2,T1 ;COPY TO RIGHT AC
MOVE T1,['FKPTRS'] ;THE FORK STRUCTURE TABLE
CALL GETJSB ;READ WORD FROM JSB
RET ;FAILED
LDB T2,[POINT 12,T2,11] ;GET FORK NUMBER OF SUPERIOR
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 205-51 (242137) AFTER DISTAB:
XX 10,FRK,3,FORK,FORK,<Frk> ;;THE FORK NUMBER
XX 0,FRK,5,FFLG,FORK-FLAGS,<Flags> ;;FORK FLAGS
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 205-51 (244307) AFTER DISTAB:
XX 10,FRK,8,FORK,FORK,<Frk> ;;THE FORK NUMBER
XX 0,FRK,5,FFLG,FORK-FLAGS,<Flags> ;;FORK FLAGS
***************
**** FILE AP20:<TCPIP.5.4.TOOLS>SYSDPY.MAC.1, 217-14 (253383) AFTER JOBFRK:
FORK: BLOCK 1 ;SYSTEM FORK NUMBER WE ARE ON
**** FILE USR0:<BUDD>SYSDPY.MAC.4, 217-14 (255553) AFTER JOBFRK:
indent: block 1 ;[plb] how far to indent current fork
FORK: BLOCK 1 ;SYSTEM FORK NUMBER WE ARE ON
***************
-------
23-May-85 12:02:55-PDT,473;000000000000
Return-Path: <
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Thu 23 May 85 12:00:11-PDT
Date: 23 May 1985 1200-PDT
From:
[email protected] (Dwight Hare)
Subject: instruction test
To:
[email protected]
I am looking for an instruction test program, especially one which tests
the extend instructions. It would be particularly useful if they tested
them in sections other than zero and possibly across sections.
Dwight
-------
23-May-85 12:52:13-PDT,1436;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Thu 23 May 85 12:51:43-PDT
Date: 23 May 1985 15:51-EDT
Sender:
[email protected]
Subject: Re: TTYDAS routine
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA]23-May-85 15:51:05.CLYNN>
In-Reply-To: The message of Mon 20 May 85 17:40:21-PDT from Mark Crispin <
[email protected]>
Mark,
The NSKDIS bughlt from TVTDET sounds like it might be a
symptom of a different problem, specifically, what left the TCB
locked? A missing unlock is possible, but doesn't seem likely.
A page fault is a second possibility. Another is that some
process is using a lot more time than it should. Do you have a
dump which can show what is actually happening?
You allude to other scenarios which can cause the bughlt;
have you any more information about them. If this is an isolated
problem it might be easier to use an alternate method of faking a
close for the tvt being detached.
One question to consider before spending very much time
changing TVTDET is what "should" happen to users "A" and "B" in
the following scenario:
User A is performing output to a terminal and has
stopped output; the tty buffer fills up and the
process blocks. User B decides to attach to user
A's job. What should happen to the detach message?
Is B blocked until A resumes output?
Charlie
23-May-85 14:10:27-PDT,2033;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Thu 23 May 85 14:07:50-PDT
Date: 23 May 1985 17:07-EDT
Sender:
[email protected]
Subject: Re: MM/domains
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA]23-May-85 17:07:46.CLYNN>
In-Reply-To: The message of Tue 14 May 85 17:15:46-MDT from Mark Crispin <
[email protected]>
Mark,
It is true that the domain system will allow hosts to advertize
different services on each of their addresses using the WKS record. It
would also be nice if the system made sure that the address it returned
was capable of providing the service/protocol you desired. It should
not be very hard to add that functionality to GTHST%, but it "isn't there
now"; trying different addresses could also be added without too much
difficulty, but it may not be as transparent.
I do not know what rumblings of primary names you have
heard, but the potential for problems with the name to number to name
algorithm are certainly there. The "names" are in one set of
authoritative zones (by "organization") and the addresses in another
set (by "network"). So far, the NIC has been delegating zones to
organizations. A few weeks ago BBN requested authority over the
networks which have been assigned to it (net 128.11, 192.1.2, etc.);
we have not yet had a reply (they are probably swamped with requests)
and the NIC's server claims to be authoritative. I assume that the
NIC will retain authority over the "address to name" portion of the
"IN-ADDR.ARPA" domain for networks which span organizations such as
ARPANET. We must make sure that the names that go in the mail are at
least "primary" in the sense that they are not "administratively
limited".
I am do not have anything to say about mailbox/domain
interaction. The domain system certainly supports mail functions.
I think we will wait until we have more experience using the domain
system before using those capabilities.
Charlie
23-May-85 15:00:29-PDT,1886;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 23 May 85 14:59:49-PDT
Date: Thu 23 May 85 14:43:28-PDT
From: Mark Crispin <
[email protected]>
Subject: Re: TTYDAS routine
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 23 May 85 12:51:00-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Charlie -
Thanks for your comments.
I feel that the code at TVTDET is wrong by any criteria.
Either it should do a form of locking that doesn't block (that
is, returns +1 with a scheduler test if it must block), it
shouldn't lock at all because it's NOSKED, or all processes which
locks the TCB should go NOSKED while it is locked.
The problem with the current way is that it leaves the
system vulnerable to a crack due to timing races. I do not like
a model which makes presumptions on who will win timing races
since such models invariably break down during extremely heavy
system loads.
I regret I don't have a dump, since I've had this workaround
in place for quite a while.
To answer your scenario, I believe that an implicit CFOBF%
should be done to user A, but otherwise user B should be blocked
until A gets out. As much as possible should be done to user A
to get him unblocked, including implicit XON'ing, etc.
While we are talking about this, I observed that there are
two levels of locking; first is the TCB locking in TVTDET to get
to CLOSE1 to begin with, and the second is the lock on the
packetizer process to do a signal on from CLOSE1. I'm wondering
if there is any way to avoid the latter. It's gross, because the
$SIGNL macro attempts to avoid running the task if NOSKED in an
obvious attempt to avoid this sort of bug.
-- Mark --
-------
24-May-85 01:02:47-PDT,830;000000000000
Mail-From: BILLW created at 24-May-85 01:02:44
Return-Path: <
[email protected]>
Date: Fri 24 May 85 00:05:39-PDT
From: Jim Lewinson <
[email protected]>
Subject: Amusing Bug...
To:
[email protected]
ReSent-To:
[email protected]
ReSent-From: BILLW at SU-SCORE.ARPA
ReSent-Date: 24 May 1985
I just created <jiml.V> and then <jiml.v.t20>. Actuallly, I think
I created <.v> and <.v.t20>. Guess what the name of the latter directory,
as stored inside it is? You guessed it ".V.T20" - it has no idea who its
grandparent is. Of course, it seems to be perfectly usable, however,
relative directories don't seem to be fully integrated into the monitor.
I don't know why the first one worked. I may have typed the whole thing
in that time. I will recreate them with the right files...
Jim
-------
24-May-85 17:01:09-PDT,1158;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 24 May 85 17:00:29-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 24 May 1985 19:57:58 edt
Date: 24 May 85 18:59 +0100
From: Peter_Lothberg_STUPI%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: DEC-10 hardware for free to a good home..
Message-ID: <106133@QZCOM>
In-Reply-To: <"MS10(2124)-1+GLXLIB1(1135)" 12113284321.15.275.22947 at
DEC-MARLBORO>
Hey,
we are a group of DEC computer fans in Stockholm, running an
KI-10 (no 522) and a KA-10 (no 175), and we ere wery interseted
in the pices of hardware you mentioned (and all other that is
free).
Ansvers to me at Peter_Lothberg_STUPI%
[email protected]
or real world adress: Peter Lothberg, Po box 36041, 100 71 STOCKHOLM
SWEDEN, Phone *46-8-699720
28-May-85 15:59:30-PDT,1820;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 28 May 85 15:58:09-PDT
Date: Tue 28 May 85 15:57:42-PDT
From: Mark Crispin <
[email protected]>
Subject: MILNET/ARPANET performance
To:
[email protected],
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Folks -
I have spent a good bit of time feeling out Telnet
performance to TOPS-20 sites on MILNET, ARPANET, and Canada's
DRENET. I have observed that this performance between Milnet and
ARPANET is, in a word, terrible. There are frequent echo delays
of over a minute in duration. By comparison, ARPANET to DRENET
performance is considerably more tolerable.
In a number of instances, Telnet performance from an
unloaded TOPS-20 system on ARPANET to another unloaded TOPS-20
system on Milnet has been terrible enough to make serious work
nearly impossible, while access to the Milnet TOPS-20 from the
Milnet TAC was smooth and quite usable. At times, the delays
have been long enough for the Telnet user program to declare the
connection dead.
This is a guess, but I believe that the gateways are
throwing out a lot of packets. Unless they've changed it, all
three networks still endeavor reliable delivery of all 1822
messages so TCP reliable delivery is in theory not resorted to.
It is probably traffic-related, since TCP performance between
ARPANET and DRENET is tolerable in spite of the slow lines at
DRENET.
Telnet is a worse case test of this, due to its character at
a time nature. I wonder if the TCP retransmission parameters
need tuning depending upon whether the connection is on a
reliable network (e.g. 1822) or is going through a gateway.
-- Mark --
-------
28-May-85 17:38:33-PDT,743;000000000000
Return-Path: <
[email protected]>
Received: from BRL-SEM.ARPA by SU-SCORE.ARPA with TCP; Tue 28 May 85 17:36:23-PDT
Date: Tue, 28 May 85 20:30:08 EDT
From: Doug Kingston <
[email protected]>
To: Mark Crispin <
[email protected]>
cc:
[email protected],
[email protected]
Subject: Re: MILNET/ARPANET performance
In the dark, no one can hear you scream...
I will add my voice to the list of those who have been silent in
the past about the lousy MILNET/ARPANET gatewaying service provided
by the swamped BBN 11/03 gateways. Supposedly they are to be upgraded
to Butterflys to solve this, but how long must we wait... And will
it really solve the problem?
Using the network for real work,
-Doug-
28-May-85 20:42:16-PDT,1219;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 28 May 85 20:41:24-PDT
Date: Tue 28 May 85 20:39:23-PDT
From: David Roode <
[email protected]>
Subject: Re: MILNET/ARPANET performance
To:
[email protected],
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "Doug Kingston <
[email protected]>" of Tue 28 May 85 17:54:16-PDT
Location: EJ286 Phone: (415) 859-2774
Wasn't the goal of the MILNET/ARPANET mailbridges merely to provide
mail service? People can use a MILNET TAC rather than ARPANET host in
the first place if they want to access a MILNET host--they are located
in more and more locations, and access is essentially added
wherever it is requested. An awful lot of people continue to use
an ARPANET TAC merely because they happen to know its phone number.
I bet there are people on this list who do not know they can
FTP a list of MILNET TAC dialup numbers (those currently
operational) off of the host SRI-NIC.ARPA with the pathname
NETINFO:TAC-PHONES.LIST . In fact, it might be interesting
to see what the effect on load would be if everyone who could used
a TAC on the proper network.
-------
28-May-85 22:17:45-PDT,1398;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 28 May 85 22:17:05-PDT
Date: Tue 28 May 85 22:15:05-PDT
From: Mark Crispin <
[email protected]>
Subject: Re: MILNET/ARPANET performance
To:
[email protected]
cc:
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "David Roode <
[email protected]>" of Tue 28 May 85 20:42:07-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
There are those of us who are "homed" on both Milnet and ARPANET,
and periodically need to telnet from hosts to a host on the other
network, especially when software is being sloshed around all over
the place. This isn't random hacking, either, this is real honest
to goodness Internet business.
It is NOT acceptable to tell us that the Milnet gateways are only
for mail. It is NOT acceptable to tell us to use a TAC until such
time as enough TAC dialups can be guaranteed. Of a number of Milnet
TACs in this area, the only one with posted dialups is the SRI TAC,
which has all lines busy about 50% of the time.
I have local ARPANET host access, so I don't care much about local
ARPANET TAC's, but I should note that as far as I know there aren't
any public 1200 baud dialups on the local ARPANET TAC at Stanford
(and I'm not aware of any others).
-------
28-May-85 22:34:48-PDT,1357;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 28 May 85 22:31:39-PDT
Date: Tue, 28 May 1985 23:30 MDT
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: David Roode <ROODE@SRI-NIC>
Cc: Crispin@SUMEX-AIM, dpk@BRL, TCP-IP@SRI-NIC, TOPS-20@SU-SCORE
Subject: MILNET/ARPANET performance
David,
You have a point. Certainly MILNET host users should use MILNET TACs
where available. (But, given a choice between a local call to an
ARPANET TAC and a long distance call by whatever service, including
Autovon, FTS, or even WATS, to a MILNET TAC, which would you choose?)
However, I *thought* the underlying Internet philosophy is to provide
"full" interconnectivity between networks. I see no reason for
inadequate gateways to be excused on the pretense that they are for
mail only.
The problem is more pervasive when you consider the subnets with their
own inadequate gateways, all following the ARPA/MILNET model. If the
ARPA/MILNET gateways are to be restricted to mail only, then using
them as "proven" developed models for other gateways is misleading, to
put it mildly.
There is something wrong, and just because it is more visible with
ARPA/MILNET "mail" gateways doesn't make it any less of a problem.
--Frank
28-May-85 22:44:12-PDT,4178;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Tue 28 May 85 22:43:44-PDT
Date: Wed 29 May 85 01:44:29-EDT
From: "J. Noel Chiappa" <
[email protected]>
Subject: Re: MILNET/ARPANET performance
To:
[email protected],
[email protected]
cc:
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "Doug Kingston <
[email protected]>" of Tue 28 May 85 21:48:44-EDT
I feel that I really ought to say a few words in defense of the
gateway maintainers at BBN, who I think are possibly being unjustly
maligned. (I'll try to keep this short, but it is a complex topic.
Please excuse cryptic references; I'm not trying to write a paper!)
I'm not so sure that the real problem is in their gateways. I
don't have any exact performance figures for their gateways, but my
long experience with LSI11 gateways and MOS indicates to me that
gateways built with that technology can run at over 200 packets/second,
way fast enough to sink an IMP. I don't know if their gateways go quite
that fast, but they can probably handle packets fast enough to swamp
the ARPANet.
I'm also not sure how much the limited number of buffers in an
LSI11 matters. When the Stanford LSI11 gateway I maintain was upgraded
to use memory mapping and have lots of buffers, the performance was
not greatly improved. (Adding something called RFNM counting did improve
it, but the BBN gateways have had that for a long time.)
I would point at two possible causes for the problems. The
first is that the ARPANet itself is simply not designed to handle the
style of traffic load that gateways present, and I wouldn't be
surprised if it isn't overloaded anyway. (I've heard some comments from
BBN people that indicate it is.) I don't have any load measurements
from before the conversion to TCP (~1980) but I wouldn't be surprised
if it was up from then. Perhaps someone in BBN could look up some
figures? For aficionados of fine details, there is also a problem
called 'resource blocking' that active hosts run into, which there is
no way for host software to guard against. It results in all outbound
traffic freezing for 15 seconds.
Also, there are a limited number of gateways between the two
nets; the largest share of the load is handled by 3, the ones at DCEC,
ISI and BBN. 'Well', you say, 'no problem, the IMP's work fine with the
same number of connections. Why not the gateways?' The answer is that
the IMPs cooperate among themselves much more closely, and in addition
have control over the rate at which traffic is let INTO THE NETWORK!
IMP's can always refuse to take packets from the hosts if the resources
to deal with them are not available. Gateways have no such control; the
get given the packets and have to deal with them as best they can.
This leads on to the final point, which Mark alluded to in
his comment about 'throwing out a lot of packets'. This is precisely
what an overloaded gateway does, and in fact it is about the only
defense mechanism it has. Needless to say, this results in terrible
performance; in addition, network resources are wasted delivering the
packet to the point at which it is discarded.
Sad to say, Mark, adjusting the timers will probably not help
much. The problem is that any retransmission algorithm is guessing
based on incomplete information; things will always be non-optimal (and
there's probably a Shannon theorm that proves it). You'll either have
lots of waits, or waste lots of resources retransmitting when you don't
need to, (and making things worse by using those resources).
What the network really needs to deal with these problems are
better congestion and traffic control (the ability to regulate the
traffic flow in the system better), and a lot more information passed
back to the hosts to allow them to make optimal use of the network.
These are all just symptoms of a deeper truth, which is that
building really big packet switched networks is still emerging
technology. Understanding of problems and proposals of new mechanisms
to handle them are appearing, but there is still a way to go.
Noel
-------
29-May-85 00:04:00-PDT,580;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 29 May 85 00:03:39-PDT
Date: Wed 29 May 85 01:03:03-MDT
From: Mark Crispin <
[email protected]>
Subject: ANLY10 change in PHYM78
To:
[email protected]
DEC fixed the bug in ANLY10 in a different way than Len fixed it.
They made PHYRWD do a SAVEPQ instead of a SAVEQ, in SPR 20-20539.
Somebody who's actively developing monitors for systems with TU78's
probably ought to look into whether or not anything depends on the
existing behavior of PHYRWD.
-------
29-May-85 10:45:38-PDT,2369;000000000000
Return-Path: <
[email protected]>
Received: from BRL-TGR.ARPA by SU-SCORE.ARPA with TCP; Wed 29 May 85 10:43:21-PDT
Date: Wed, 29 May 85 13:23:32 EDT
From: Ron Natalie <
[email protected]>
To: David Roode <
[email protected]>
cc:
[email protected],
[email protected],
[email protected],
[email protected]
Subject: Re: MILNET/ARPANET performance
The goal of the MILNET/ARPANET gateways is to interconnect the two nets.
These are the only authorized ways of getting packets between hosts on
the MILNET side of the DDN backbone to hosts on the ARPANET side. The
reason they are called mail bridges is hopefully obsolete. Originally
certain paranoid elements in DOD thought that those experimental people
on the ARPANET were going to do something to their network, so after spending
years having an internetwork system developed, they decided that they were
going to partition the two halves, with the exception of mail. These
gateways were going to be a kludge that examined the TCP port number to
allow only Mail packets to go through.
Most people have probably realized that this idea is not great. Especially
those of us on the MILNET side who need to talk to the rest of the world.
It is apparent with a little thought that it is a whole lot easier to make
a nuisance out of yourself with mail than anything else, therefore the
blocking gateways would not help. My personal view is that the gateways
remain full IP gateways and in the case of problem or national emergency
someone at the NOC presses the "destruct gateways" button and partitions the
net.
I don't think that the TACs are loading down the gateways. TAC's aren't
that efficient, they just don't make that many packets. The prime TAC
loads are the silly people who are using KERMIT through them, but most
of these people stay on their own side of the chasm. The big load, as
always is mail. The fact that these gateways are pretty much the same
as they were two years ago, and the net load has increased dramatically
is a significant factor. In addition, every since the EGP cutover, they
don't route as efficiently as they used to. In addition, the entire
ARPANET/MILNET IMP complex is getting in trouble. More and more traffic
is being pumped through it but the trunk capacity is not being increased
as rapidly.
-Ron
29-May-85 13:16:53-PDT,3835;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 29 May 85 13:15:53-PDT
Date: 29 May 1985 16:12-EDT
Sender:
[email protected]
Subject: Re: MILNET/ARPANET performance
From:
[email protected]
To:
[email protected]
Cc:
[email protected],
[email protected]
Message-ID: <[BBNA.ARPA]29-May-85 16:12:32.CLYNN>
In-Reply-To: The message of Tue 28 May 85 15:57:42-PDT from Mark Crispin <
[email protected]>
Mark, et.al.,
I have also experienced many lost packets and delays
between Milnet (ISI) and Arpanet (BBN), but I was trying to FTP
800 page data files. They always seemed to timeout. I have
also spent a lot of time trying to make retransmissions and
flow control work a little better than they did (on TOPS20s).
The statement that TCP reliable delivery not being
resorted to is false, theoretically. The Arpanet and Milnet
are both reliable 1822 networks, with a nominal limit of 8
outstanding packets between Imp/port pairs. The gateways
redirect hosts to send packets to the gateway nearest to the
sending host.
To see the problem, consider the following diagram.
Milnet Imp ---Imp--- Milnet ---Imp---- Milnet Imp -- ISIA
| |
BBN GW ISI GW
| |
BBNA -- Arpanet Imp --Imp--- Arpanet --Imp---- Arpanet Imp
Traffic from ISIA to BBNA goes to the local imp, through the ISI GW,
across the Arpanet, to BBNA; traffic to ISI goes through the BBN GW,
cross country via the Milnet to ISIA. The transit time through either
net is (more or less) proportional to number of hops. Thus it takes
longer to go from the BBN GW to ISIA (via Milnet) than from BBNA to
the BBN GW (or from the ISI GW to BBNA (via Arpanet) than from ISIA to
the ISI GW), the points where the 1822 flow control is applied.
Consequently, BBNA can reliably send packets to the BBN GW faster than
the gateway can reliably get them to ISIA -- even if there is NO other
traffic in either net. Eventually, the packets at the gateway will
build up and the gateway will have to discard the excess packets
(sending a source quench back to the host). I.e., assume BBNA to BBN
GW is 50ms or 8 packets per 50 ms = 160 packets per second; BBN GW to
ISIA is about 300ms or 8pkt/300ms = 26 packets per second; thus 134
packets per second down the drain. (Note that simply switching to
faster processors, e.g., a butterfly, will not help.)
What is needed is NOT adjustment of retransmission parameters,
what IS needed is end to end flow control algorithms that work, and
some specific guidelines to those who are implementing the protocols.
There are a few things that could be done to relieve this
particular problem. The gateways could be programmed to redirect the
hosts to the gateway nearest the destination (so called "destination
routing" which the gateway crew is investigating).
It isn't simple, and requires knowledge in the gateways of
many things about topoligies and delays between pairs of
hosts -- a long way from the "stateless" gateway originally
described.
One can also get busy and figure out how to do flow control.
We have added code to our TOPS20s for flow control: it
closes windows, uses estimated baud rates to limit
outstanding packets (instead of just filling a window),
limits the number of packets retransmitted when one is lost,
and it boths sends and processes source quenchs. Even if
this all works, it may not help much until most of the other
hosts take similar actions.
My solution to the FTP problem was to tell it to use a source route
through the ISI GW.
It worked because the data was all flowing in one direction
and because the TCP will automatically invert a received
source route option (the FTP server didn't have to be changed).
Charlie
29-May-85 16:31:42-PDT,1144;000000000000
Return-Path: <
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 29 May 85 16:27:58-PDT
Date: Wed, 29 May 85 19:18 EDT
From: Steve Aliff <
[email protected]>
Subject: Re: MILNET/ARPANET performance
To: David Roode <
[email protected]>
cc:
[email protected],
[email protected],
[email protected],
[email protected]
In-Reply-To: Message of 28 May 85 23:39 EDT from "David Roode"
Message-ID: <
[email protected]>
You're right. The original brain-damaged idea was to limit gateways to
mail only. (Although I saw several iterations with limited Telnet,
etc.) That idea seems to have been abandoned, and rightfully so, in
favor of full inter-net gateways. I can think of several applications,
and even more user environments, where leaving one's favorite terminal
niche to find a dial-up terminal to access a TAC doesn't come close to
being a working solution. Let's find and fix the real problem and not
bring up ghastly ideas from the past.
That's the longest flame I've had recently. Apologies to all innocents
caught in the crossfire.
29-May-85 22:02:38-PDT,1584;000000000000
Return-Path: <chris@gyre>
Received: from gyre.ARPA by SU-SCORE.ARPA with TCP; Wed 29 May 85 22:01:48-PDT
Received: by gyre.ARPA (4.12/4.7)
id AA27858; Wed, 29 May 85 22:17:55 edt
Date: Wed, 29 May 85 22:17:55 edt
From: Chris Torek <chris@gyre>
Message-Id: <
[email protected]>
To:
[email protected],
[email protected],
[email protected]
Subject: Re: MILNET/ARPANET performance
Cc:
[email protected],
[email protected]
I might take this opportunity to note that many 4.2BSD sites are
retransmitting packets once every second, no matter what the actual
round trip ack time is; this doesn't help gateway load at all.
There is a bit of code in /sys/netinet/tcp_output.c that looks like this:
if (SEQ_GT(tp->snd_nxt, tp->snd_max))
tp->snd_max = tp->snd_nxt;
/*
* Time this transmission if not a retransmittion and not
* currently timing anything.
*/
if (SEQ_GT(tp->snd_nxt, tp->snd_max) && tp->t_rtt == 0) {
tp->t_rtt = 1;
tp->t_rtseq = tp->snd_nxt - len;
}
The second SEQ_GT is guaranteed to fail, thus nothing is ever timed; and
the retransmits happen at the maximum rate (1/second).
The code should be changed to:
if (SEQ_GT(tp->snd_nxt, tp->snd_max)) {
tp->snd_max = tp->snd_nxt;
/*
* Time this transmission (it's not a retransmission)
* unless we're already timing something.
*/
if (tp->t_rtt == 0) {
tp->t_rtt = 1;
tp->t_rtseq = tp->snd_nxt - len;
}
}
(Note, Berkeley has fixed this.) I hope most 4.2 arpa sites are reading
this. . . .
Chris
30-May-85 03:34:09-PDT,1873;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISI.ARPA by SU-SCORE.ARPA with TCP; Thu 30 May 85 03:31:22-PDT
Date: 30 May 1985 06:29-EDT
Sender:
[email protected]
Subject: Re: MILNET/ARPANET performance
From:
[email protected]
To:
[email protected]
Cc:
[email protected],
[email protected]
Cc:
[email protected],
[email protected]
Cc:
[email protected]
Message-ID: <[USC-ISI.ARPA]30-May-85 06:29:54.CERF>
In-Reply-To: <
[email protected]>
Folks,
Gateway performance IS important. Especially for DoD where the
whole point of internet was to capitalize on connectivity where
ever it could be found; in a crisis, the traffic goes where it
can.
I think the gateway performance has been decreasingly
satisfactory as the level of traffic has built up. Clearly, the
character-echoplex requirement exacerbates matters a good deal,
and the 8 messages outstanding rule on the ARPANET and MILNET
make the problem more severe since traffic gets throttled below
the TCP/IP level as a result (the new END/END protocol in the
IMPs should help some).
Are there any hard data about gateway throughput - Dave Mills
always seems to have his hands on measurement information - how
about it, Dave?
Can BBN say anything about higher capacity gateways under
development?
Before we tar the LSI-11/03 gateways, let's try to find out where
the bottleneck is - for all I know it is other than the gateway
itself. I remember that in the Ft. Bragg Packet Radio
experiments we found that 8 messages outstanding were the real
bottleneck and quickly went to line at a time application support
to reduce the packet rate. This was particularly acute at Bragg
because nearly every appliation ran on the SAME host and the 8
message limit applied between that host (ISID) and the gateway
qua host on ARPANET.
Vint
30-May-85 09:42:28-PDT,2185;000000000000
Return-Path: <ljs@bbnccv>
Received: from bbnccv.ARPA by SU-SCORE.ARPA with TCP; Thu 30 May 85 09:41:39-PDT
Received: by bbnccv.ARPA (4.12/4.7)
id AA06379; Thu, 30 May 85 12:40:12 edt
Message-Id: <
[email protected]>
To:
[email protected]
Cc:
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected], ljs@bbnccv
Subject: Re: MILNET/ARPANET performance
In-Reply-To: Your message of 30 May 1985 06:29-EDT.
<[USC-ISI.ARPA]30-May-85 06:29:54.CERF>
Date: 30 May 85 12:40:08 EDT (Thu)
From: ljs@bbnccv
The 8 message limit in the Arpanet and Milnet is a major problem for
gateways. Often in our daily statistics I have seen ARPANET (or MILNET)
gateways dropping a high percentage of packets received (20%-30%) at fairly low
throughputs (50-70 packets per second), while other gateways on faster
and non-blocking networks can pass 200 packets per second with
no dropping at all. A quick look at the daily ARPANET log often shows
that the ARPANET (or MILNET) IMPs were blocking their interfaces during
this period.
This says that the processing power of the LSI-11 gateway is not the problem,
at least up to 200 packets per second. Lack of buffers in the LSI-11 is
a problem, however, since short periods of interface blocking could be
smoothed over by a greater buffering capacity. There is a project underway
to provide more buffers for the LSI-11. We are developing a new multiprocessor
gateway which will provide even more buffers and processing
power, in addition to a new interior routing algorithm and a better algorithm
to distribute EGP information internally. This project is being funded by
DARPA, and to my knowledge the DDN PMO has made no commitment to switch.
The new end-to-end algorithm in the IMPs will improve the situation
considerably, since the IMP will no longer block the entire interface
just because one connection is blocked.
In addition, there are plans to put EGP in all of the mailbridges (after
the memory upgrade). This should reduce the EGP-related problems that
MILNET sites have been seeing.
Linda Seamonson
30-May-85 21:27:23-PDT,690;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 30 May 85 21:25:28-PDT
Date: Thu, 30 May 1985 22:24 MDT
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: Equipment Upgrades
If you are a manager of a US Government-owned DEC-20 facility and has
successfully upgraded to a 2065 with additional memory, please contact
me by net mail and include your phone number(s), either AV or FTS, and
times you can be reached.
Also, if you are preparing to release DEC-deinstalled equipment for
excess, I'd like to be among the first to know.
Thanks,
Frank
1-Jun-85 17:18:08-PDT,1377;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 1 Jun 85 17:17:50-PDT
Date: Sat 1 Jun 85 17:17:11-PDT
From: Paul Hegarty <
[email protected]>
Subject: New Stanford SYSJOB command (primarily for CFS sites)
To:
[email protected]
I have added the command MOUNT STR: to the Stanford SYSJOB.
It mounts the given structure with the attributes DOMESTIC/UNREGULATED.
This seems to rather blatantly remove from MOUNTR a function which is
exclusively its domain, but CFS sites will find it to be very useful if
they wish to keep only one copy of their system software (e.g. <SUBSYS>)
out on a common disk. Obviously MOUNTR will not run in time to mount the
structure before other SYSJOB processes start looking for files in system
directories.
Note that it is a rather limited MOUNT command (no aliasing, and no choice
about what attributes it has). This doesn't seem to be a problem though
because MOUNTR will eventually set the structure to the correct attributes
when it gets around to running and since this command will only be used in
the very limited circumstances, it need not be too robust. If someone is
interested in adding more functionality, feel free to do so, but it seems
unnecessary.
Source is in PS:<SU-UTILITIES>SYSJOB.MAC at SU-Sierra ...
... Paul
-------
3-Jun-85 08:15:54-PDT,499;000000000000
Return-Path: <
[email protected]>
Received: from DEC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Jun 85 08:13:41-PDT
Date: Mon 3 Jun 85 10:06:33-EDT
From: Kevin Paetzold <
[email protected]>
Subject: dec-marlboro
To:
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
dec-marlboro (10.1.0.79) is off the air and has been off the air for a week.
unknown when it will return. meanwhile mail for me can be addressed to
dec-tops20.
-------
3-Jun-85 12:03:44-PDT,749;000000000000
Return-Path: <
[email protected]>
Received: from EDWARDS-2060.ARPA by SU-SCORE.ARPA with TCP; Mon 3 Jun 85 11:59:04-PDT
Date: Mon 3 Jun 85 11:59:44-PDT
From: Marc Williams (Williams@Edwards-2060)
Subject: Statistics Packages
Sender:
[email protected]
To:
[email protected]
Reply-To:
[email protected]
The database folks here at Edwards-2060 would like to know if
there are any "public domain" statistics packages out there in
20-land. One that works with 1022 (much as SPSS does) would be
really neat, but one that works with vanilla text data would more
than suffice, since we don't have any statistics stuff at all here.
Any information would be greatly appreciated!
-Marc
-------
4-Jun-85 19:35:08-PDT,2264;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Jun 85 19:35:04-PDT
Date: Tue 4 Jun 85 19:34:37-PDT
From: Mark Crispin <
[email protected]>
Subject: many bug fixes
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
SUMEX's SS:<5-3-MONITOR> has many fixes written by me in the
past few weeks, which I'm releasing to the rest of the Stanford
community. I imagine somebody (Kirk?) will integrate these
changes into the 6.1 Stanford monitor. These changes are
primarily my work to fix carrier off interrupts once and for all.
Many of the changes were developed or co-developed by me in my
PANDA incarnation and so are identified by PANDA change numbers.
If these are passed on to DEC be sure they know it came from me.
DDT increase length local PDL so that MDDT on Pup NVT's
has enough stack space
GLOBS obvious...
IPIPIP INTBZT routine made global so it can be referenced from
TTYSRV (in TVTDEC in TTANDV.MAC)
MEXEC Rewrite LDTACH routine - tighten it up, make sure all
exits detach, call TTYSRV routine instead of doing TLINK%
JSYS. Rewrite start of JOBCOF - tighten it up, preserve
all AC's and page fault context. Restore DEC NOSKED
around the TTYDAS call in ATACHB+nL - was removed by me
years ago to fix NSKDIS cracks on network terminals (now
fixed by TTANDV changes)
PUP Insert missing ECSKED in PNVCLZ. Remove code in PU7NVT
that flushes "abandoned PNV's" - this code yanks PNV's
out from under a job trying to deassign it and causes
multiple jobs on the same PNV. My JOBCOF fixes poke this
bug (and so does 6.1 at LOTS apparently)
SCHED Rewrite PIRCOF routine - tighten up code, be sure that PC
flags are always saved and restored in all instances
STG NHSTN is now NHOSTS*4
TTANDV Rewrite TCP close logic in TVTDET so it doesn't block if
NOSKED - new TVTDEC routine to non-block close
TTYSRV New LDTLNK routine do break links (called by LDTACH in
MEXEC). Fix uninitialized variable bug in TL1C. Add
"detach in progress" and "carrier off PSI in progress"
flags to dynamic data and use them to prevent recursive
COF/detach calls
-------
4-Jun-85 22:32:45-PDT,806;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Tue 4 Jun 85 22:31:22-PDT
Date: Wed 5 Jun 85 00:29:37-CDT
From: Clive Dawson <
[email protected]>
Subject: Calendar program
To:
[email protected]
Does anybody know of a "calendar" program which can be used to remind
people of their daily appointments? What I have in mind is more or less a
cross between the REMIND and NREMIND programs which live on Score (among
other places). That is, it should display items of interest for a given
day whenever it's run by the user (e.g. at login time), but it should also
allow easy updating of the event database in the manner of NREMIND (i.e.
automatic purging of expired items and interactive query mode for entering
new items).
Thanks,
CLive
-------
10-Jun-85 16:42:27-PDT,440;000000000000
Return-Path: <
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Mon 10 Jun 85 16:39:32-PDT
Date: 10 Jun 1985 1556-PDT
From: Mark K. Lottor <
[email protected]>
Subject: TTY0:
To:
[email protected]
What is TTY0:? Where is it? Some parts of the monitor let you
use it and some don't. Is there any reason for the inconsistencies?
Does it have something to do with why TV's start on channel 2?
-------
10-Jun-85 16:59:58-PDT,469;000000000000
Return-Path: <
[email protected]>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 10 Jun 85 16:59:28-PDT
Date: Mon 10 Jun 85 19:58:17-EDT
From: Chris Maio <
[email protected]>
Subject: Re: TTY0:
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark K. Lottor <
[email protected]>" of Mon 10 Jun 85 18:56:00-EDT
If you redirect the CTY: via the front panel switches, the console terminal
becomes TTY0:.
-------
10-Jun-85 18:32:04-PDT,670;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 10 Jun 85 18:30:51-PDT
Date: Mon 10 Jun 85 19:11:42-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: TTY0:
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark K. Lottor <
[email protected]>" of Mon 10 Jun 85 16:56:00-MDT
TTY0: is the LA36/LA120/etc. connected to one of the console 11's
DL11 ports (the other DL11 port goes to the KLINIK modem). Normally,
the CTY is mapped to this line so it appears as the CTY's TTY line
number instead of TTY0. But if you remap the CTY to some other line
that terminal becomes TTY0.
-------
11-Jun-85 11:43:12-PDT,1430;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 11 Jun 85 11:42:38-PDT
Date: Tue 11 Jun 85 11:40:35-PDT
From: Kirk Lougheed <
[email protected]>
Subject: TTLOKB bughlts fixed
To:
[email protected]
I think I may have discovered the reason behind the TTLOKB bughlts that have
come and gone on the various systems around here. The bughlt is a complaint
about an overly incremented TTY lock count and it usually is associated with
a job on a PUP NVT that became detached in the middle of the TCOUT code.
When this happens, the routine TCOU7 is invoked to create a dummy "message
block" so that the monitor can unwind things gracefully. There is a race
whereby a "short block" can be assigned to the line by TTMSG% before the
TCOU7 code does its job. Once that short block is there, the message block
cannot be assigned. The job sits in the TCOU7 code forever or until the
system crashes, often with a TTLOKB bughlt.
The solution for TVT's has been to never assign a short block. Applying
that same solution to PNV's should fix the problem. The code is in TTYSRV
at ASGSHT, as below. I've fixed the 6.1 sources on Sierra.
Kirk
--------
ASGSHT: LOAD T1,TTSTY,(T2) ; Get line type
IFN STANSW&PUPSW,<
CAIE T1,TT.PNV ; PUP NVT?
>;IFN STANSW&PUPSW
CAIN T1,TT.TVT ; NVT?
RET ; Yes, don't do this then
STKVAR <ASGSLN>
-------
11-Jun-85 14:32:55-PDT,439;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 11 Jun 85 14:31:20-PDT
Date: Tue 11 Jun 85 17:29:24-EDT
From: Kevin Paetzold <
[email protected]>
Subject: dec-marlboro
To:
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
dec-marlboro has returned to the arpanet. the hardware problem
(broken ecu) has been fixed.
-------
12-Jun-85 22:41:04-PDT,1940;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Jun 85 22:39:37-PDT
Date: Wed 12 Jun 85 22:39:17-PDT
From: Mark Crispin <
[email protected]>
Subject: new release of MMailr, MMailbox
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
A new release of MMailr and MMailbox is on SU-SCORE.ARPA on the
usual SCO:<MM> directory. This new release implements a major new
functionality in mailboxes, the "&" syntax. "&" before a user name
refers to that user's MAIL.TXT without any forwarding/mailing list
considerations.
This is used to replace kludges such as *PS:<USER>MAIL.TXT.1 when
you want a user's mail to go to his mail file but copied elsewhere.
For example, when before you had
USER= USER-COPY-ELSEWHERE@SOME-OTHER-HOST *PS:<USER>MAIL.TXT.1
you can now have
USER= USER-COPY-ELSEWHERE@SOME-OTHER-HOST &USER
The advantage is that unlike * files, & addresses are not checked
for public append access. So, a user with a copy elsewhere can still
have his mail file protected 770000 and have everything work.
MMailbox is also MUCH fussier about disallowing recursive forwarding
constructs. In particular, things such as
USER= USER-COPY-ELSEWHERE@SOME-OTHER-HOST USER
or
USER= USER@THIS-HOST
are now caught and disallowed. The proper thing to do now for both of
these is to use "&". For example, if you have a MAILING-LISTS.TXT shared
across many hosts and don't want to delete the local users, you can have
something like:
USER= &USER@HOST
which will either forward to that host (assuming it is running the new
release) or if this is the host will deliver it locally.
Be aware that you must shut down and restart MMailr and SMTJFN, as
well as getting the new MMailr and MMailbox EXE's installed, before any
of this will work.
-------
12-Jun-85 23:08:06-PDT,1190;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 12 Jun 85 23:05:51-PDT
Date: Wed 12 Jun 85 23:05:29-PDT
From: Mark Crispin <
[email protected]>
Subject: interesting reading
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
The June 1985 issue of Systems & Software has an interesting
article entitled "Super-minicomputers -- the hottest game in
town" talking about the forthcoming strategies for non-IBM
vendors. The author takes the point of view that non-IBM vendors
must deliver well-tuned general-purpose engines delivering at
least 10 Mips by 1988 to 1990 at under $70,000/Mips.
It reads almost as if a DEC-20 hacker wrote it; the VAX is
talked about in great length, mostly negative. While the author
professes neutrality, it's obvious he's on the RISC bandwagon.
It's an interesting flame in any case. To be honest, I'll
be very surprised if we see a 10 Mips VAX at $70,000/Mips by 1988,
nor (alas!) are we likely to see a PDP-10 of that power. I'm more
skeptical of pricing than of speed.
-- Mark --
-------
13-Jun-85 17:13:00-PDT,1388;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 13 Jun 85 17:12:40-PDT
Date: Thu 13 Jun 85 20:15:14-EDT
From: Rob Austein <
[email protected]>
Subject: DIGEST emacs library
To:
[email protected]
Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341
After searching in vain for Tops-20 digestifying software, I finally
went out and wrote some. It's an EMACS library, called DIGEST. There
is also a prototype of a batch control file to run the digestifier
(horrible word), then run MMAILR to send it off (this is because
outgoing digests tend to wedge network mail for up to half an hour on
XX, so this way the batch job does the load-intensive first pass).
Parameters to the digestifier are set via EMACS variables. The input
format of the message file is the standard Tops-20 MAIL.TXT format, as
MMAILR would write. The list of recipients can be in pretty much any
reasonable form (separated by whitespace or commas, quoted strings are
handled correctly, as is backslash quoting). If you prefer to let
MMAILR handle the parsing, there is a variable you can set to inhibit
the parsing (DIGEST will just insert the name of the file as a local
indirect address). Output is in the format used by MMAILR for queued
messages.
This stuff is in [XX]EMACS:DIGEST.* for them as wants it.
-------
17-Jun-85 00:57:19-PDT,1184;000000000000
Mail-From: G.JOESMITH created at 17-Jun-85 00:57:11
Date: Mon 17 Jun 85 00:57:11-PDT
From: Joe Smith <
[email protected]>
Subject: DEC announces unbundling of TOPS-10 and TOPS-20.
To:
[email protected]
It was announced at the LSM Roadmap Session at DECUS, although most members
did not recognize it as such. Most people thought it meant that the deal,
$80,000 for the first system and $40,000 for each additional system, only
applied to running TOPS-10/TOPS-20 on DEC CPUs that were bought on the used
computer market. When cornered, DEC stated that unbundled monitor could be
purchased for any CPU, whether it was manufactured by DEC or not. The only
stipulation was that to have software support via the SPR mechanism, each
site must have at least 1 DEC PDP-10 to verify that the problem failed on DEC
hardware the same way that it failed on non-DEC hardware.
I expect some sites will sell their expensive-to-maintain KLs, purchase one
KS-2020 as the DEC CPU, and then buy multiple PDP-10 look-alikes from Systems
Concepts and such.
Joe Smith
McDonnell Douglas Field Service Company
39100 Liberty Street
Fremont CA 94538
-------
17-Jun-85 05:56:18-PDT,714;000000000000
Return-Path: <@COLUMBIA-20.ARPA:GINGELL@CWR20B>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Jun 85 05:53:22-PDT
Received: from CWR20B by CUCS20 with DECnet; 17 Jun 85 08:52:46 EDT
Date: Mon 17 Jun 85 08:52:46-EDT
From: Rob Gingell <GINGELL@CWR20B>
Subject: Re: DEC announces unbundling of TOPS-10 and TOPS-20.
To: TOPS-20%SU-SCORE@CUCS20
In-Reply-To: Message from "Joe Smith <
[email protected]>" of Mon 17 Jun 85 04:06:45-EDT
For at least the last several DECUS', a number of people who attended have
posted trip reports to this list which I think were very useful to people
who didn't attend. Would anyone be interested in doing that this time?
Rob Gingell
-------
17-Jun-85 13:16:50-PDT,1370;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Jun 85 13:14:56-PDT
Received: ID <
[email protected]>; Mon 17 Jun 85 16:14:30-EDT
Date: Mon 17 Jun 85 16:14:29-EDT
From:
[email protected]
Subject: New FTPSRT available
To:
[email protected]
This version contains several useful bugfixes, in particular:
* Unrecognized arguments to the SITE command are rejected (currently, this
means any argument to the SITE command). This change was in response to
a bug that some Unix systems have trouble downloading the host table from
SRI-NIC.
* Emulation of CWD commands when returning file lists (for LIST and NLST).
Previously, the full filespec of each file not in the CONNECTED directory
was returned. Now, the name is only qualified sufficiently to identify it
for the currently CWD'ed directory. This should make multiple get work
much better from non-TOPS20 systems.
* Minor change to STAT command - by default, only the highest generation of
a specific file is returned. This allows the FTP user process to expand
and verify partially specified names when doing retrieves.
As usual, this FTPSRT is available from PS:<VAF.FTP> on CMU-CS-C (along with an
FTP that takes advantage of the STAT change).
--Vince
-------
17-Jun-85 19:46:00-PDT,486;000000000001
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Jun 85 19:41:39-PDT
Date: Mon 17 Jun 85 20:15:02-MDT
From: Mark Crispin <
[email protected]>
Subject: STCMP% with OWGBP's
To:
[email protected]
Problem:
STCMP returns bogus results with one word global byte pointers.
Diagnosis:
It thinks it can decrement byte pointers by ADD T2,[7B5]
Solution:
Rewrite STRC2 code in COMND.MAC to use ADJBP.
-------
17-Jun-85 22:53:48-PDT,1056;000000000001
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Jun 85 22:51:54-PDT
Date: Mon, 17 Jun 1985 23:51 MDT
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
cc:
[email protected]
Subject: DUMPER status?
We are running 5.4 with 512KW on this 2040 with a nearly full RP07 PS:
and a full RP06. Our Friday "full incremental" and our Monday
incremental/2 DUMPER runs are currently taking about 35% of the CPU
in excess of seven (!) hours of wall clock time with a TU77. This is
truly absurd!
I know we should get a TU78; we are working on that. I know we should
get more memory and upgrade to a 65; we are working on that, too. We
have an immediate that needs an immediate solution.
My question is: will the 6.n DUMPER help and how much? I was told it
can be built for a 5.4 environment. Has anybody tried it? Are there
other, perhaps more efficient versions available I can use in the
meantime?
--Frank
17-Jun-85 23:51:01-PDT,740;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 17 Jun 85 23:47:03-PDT
Date: Mon 17 Jun 85 23:46:12-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: DUMPER status?
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from ""Frank J. Wancho" <
[email protected]>" of Mon 17 Jun 85 23:07:52-PDT
Beware the rewrite of DUMPER. It is "slightly" imcompatible with the
old DUMPER. The major problem I've encountered is that users have
problems reading tapes with savesets written by both the old and
the new DUMPERs. I ended up rolling back to the old DUMPER, but kept
a copy of the new DUMPER so I could salvage user tapes.
Kirk
-------
18-Jun-85 15:51:19-PDT,1290;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 18 Jun 85 15:50:37-PDT
Date: Tue 18 Jun 85 15:42:19-PDT
From: Mark Crispin <
[email protected]>
Subject: ACJ .GOSUB function
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Folks -
The PANDA monitor has a rewritten version of the ACCSUB routine
in DIRECT which changes the functionality of the .GOSUB ACJ hook.
The Stanford monitor depends upon the ACJ to do the "is it a
subdirectory of the login directory" validation. In the PANDA monitor,
the arguments are changed to eliminate the first argument (str #,,user #)
as unnecessary and the ACJ is called iff the directory has been
validated to be a subdirectory of the login directory on a domestic
structure. .GOSUB in the PANDA monitor is enabled by default.
What this all means is that by default, users have owner access
to their subdirectories on domestic structures without any ACJ
intervention. The ACJ is only used if it is desired to deny such
access.
I feel this approach is superior. If the Stanford community would
like to adopt this version of .GOSUB, I'll be glad to send it.
-- Mark --
-------
19-Jun-85 16:49:57-PDT,2468;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Wed 19 Jun 85 16:49:19-PDT
Date: Wed 19 Jun 85 17:47:13-MDT
From: The alleged mind of Walt <
[email protected]>
Subject: Support for Unix rcp to/from the DEC-20
To:
[email protected]
My package of Unix daemons for the DEC-20 has now been enhanced
by the addition of support for the Unix remote copy program rcp.
The following announcement describes how it works at the U of Utah::
The Unix remote copy function "rcp" now supports copying of files
between Unix and the DEC-20. If you have an account on the 20 you
can run rcp on any Unix system and copy files to or from the 20,
assuming that you have the access rights to do so. In order to use
rcp you must first create a .RHOSTS file in your directory on the 20.
This file must contain the hostname and your username on that host
for each host from which you want to access the 20. Thus my .RHOSTS
file contains:
utah-cs haas
utah-gr haas
utah-sp haas
utah-ug haas
utah-vlsi haas
If your username on the Unix system is different from your username on
the 20, you must specify the 20 username in the rcp command. For example,
if you were logged in as "joe" on utah-cs and your username on the 20 was
JOE-SIXPACK then your .RHOSTS file on the 20 would have to contain the line
utah-cs joe
and your rcp command would have to specify your 20 username as
utah-20.joe-sixpack:
If you want to specify a structure and/or directory on the 20 don't
forget to put it in quotes on the Unix side. For example:
rcp utah-20:"ps:<lists>services.list" .
If your username on the 20 contains a ".", such as OPER.LARSEN for example,
you have a problem - rcp on Unix attempts to parse "utah-20.oper.larsen" as
a hostname of "utah-20.oper" and a username of "larsen" and complains because
it can't find a host named "utah-20.oper". The solution to this problem is
definitely not obvious!
By the way, don't forget the ^V before the "." in .RHOSTS. Ie. type
^V.RHOSTS when you create the file.
The Unix daemon software may be FTPed from UTAH-20 by supplying username
ANONYMOUS and password GUEST. You will find DAEMON.MAC, SATAN.CMD, SATAN.HLP,
SATAN.MAC, LPD.MAC, RSHD.MAC, UGPRT.MAC and UGPRT.HLP in your login directory
there. The current version of the software contains bug fixes and enhancements
to LPD and SATAN since the previous release.
-------
20-Jun-85 15:24:54-PDT,580;000000000000
Return-Path: <cew@isi-hobgoblin>
Received: from isi-hobgoblin.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Jun 85 15:22:27-PDT
Received: by isi-hobgoblin.ARPA (4.12/4.7)
id AA00164; Thu, 20 Jun 85 15:22:09 pdt
Message-Id: <
[email protected]>
Date: 20 Jun 1985 1522-PDT (Thursday)
From: Craig E. Ward <
[email protected]>
To: Tops-20@su-score
Subject: Automatic updates of hosts table
Does anyone have software that queries the NIC to see if a new hosts table
exists and then picks it up if it does? (And then installs it)?
Thanks,
Craig
20-Jun-85 17:22:05-PDT,547;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Jun 85 17:19:46-PDT
Date: Thu 20 Jun 85 17:18:52-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: Automatic updates of hosts table
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Craig E. Ward <
[email protected]>" of Thu 20 Jun 85 15:22:00-PDT
The program PS:<TCP>NICUPD.MAC on SU-Sierra does what you want.
It wants to be linked with PS:<SU-UTILITIES>SNDMAI.MAC.
Kirk
-------
20-Jun-85 21:26:33-PDT,654;000000000000
Return-Path: <iglesias@uci-icsa>
Received: from UCI-ICSA by SU-SCORE.ARPA with TCP; Thu 20 Jun 85 21:23:02-PDT
To: tops-20@su-score
cc: iglesias@uci-icsa
Subject: Rutgers PASCAL for TOPS-10 question
Date: 20 Jun 85 21:22:01 PDT (Thu)
From: Mike Iglesias <iglesias@uci-icsa>
Received: from Localhost by UCI-ICSA for iglesias; 20 Jun 85 21:22:24 PDT (Thu)
Rutgers PASCAL v14(276), when called by the LOAD command in TOPS-10,
calls a program called PLINK. I seem to have mislaid PLINK and
it's not on the distribution tape. Does anyone know where it's
supposed to be? Anybody have a copy?
Mike Iglesias
University of California, Irvine
20-Jun-85 23:30:11-PDT,868;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 20 Jun 85 23:28:05-PDT
Date: Thu 20 Jun 85 23:26:38-PDT
From: Mark Crispin <
[email protected]>
Subject: KL10 performance watcher
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
I have written a little program which uses the KL10 performance
analysis meters to let you monitor things such as cache misses, percent
of the CPU spent in PI's or handling channels, etc. You need WHEEL,
OPERATOR, or MAINTENANCE capability to run the program. It's offered
"as is" with no promises...
You can FTP it from SUMEX-AIM with the ANONYMOUS FTP convention.
The program is called METER, and it is on PS:<CRISPIN.TOOLS>METER.MAC
(and METER.EXE on the same directory).
-------
22-Jun-85 00:09:25-PDT,660;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Sat 22 Jun 85 00:06:46-PDT
Date: Sat 22 Jun 85 03:05:54-EDT
From: Ken Rossman <
[email protected]>
Subject: Looking for TTY display package
To:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Does anyone out there know of a general purpose display terminal subroutine
package I could get my hands on? What I'm looking for is a set of routines
that would provide generic display terminal control functions, something
like the Unix termcap facility. Any pointers would be greatly appreciated.
/Ken
-------
24-Jun-85 11:45:54-PDT,497;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 24 Jun 85 11:45:28-PDT
Date: Mon 24 Jun 85 11:44:14-PDT
From: Bill Westfield <
[email protected]>
Subject: EXEC changes...
To:
[email protected]
Ive edited sierra's master copy of <6-1-exec>EXECSU.MAC to use the
TTYINI database on incomming TCP connections (as well as PUP connections).
I thought I had done this before, but if so, the edits have disappeared...
BillW
-------
26-Jun-85 13:02:47-PDT,871;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 26 Jun 85 13:01:56-PDT
Date: Wed 26 Jun 85 13:01:43-PDT
From: Mark Crispin <
[email protected]>
Subject: release 6.1 bug/misfeature/?
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
I noticed that when you advise a free PTY's terminal that the
PTY is still assignable by any job as of TOPS-20 version 6 and 6.1.
Previously, the PTY would become assigned to job 0, and its output
would be discarded.
It was a useful feature to be able to create a job by advising
a free PTY, but this breakage ruins that feature. Besides the
obvious security problems, it is no longer possible to run PHOTO
on such a PTY.
Anybody have any idea what happened and why?
-------
26-Jun-85 13:08:22-PDT,810;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 26 Jun 85 13:06:15-PDT
Date: Wed 26 Jun 85 13:05:56-PDT
From: Mark Crispin <
[email protected]>
Subject: addendum to previous message
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
To correct my earlier message. There isn't a security problem. What
seems to have changed is that a job created by advising a PTY is now
able (in 6 and 6.1) to assign/open the PTY it is running on. This is
what breaks Photo. The workaround is to advise a higher-numbered free
PTY so Photo will assign a lower-numbered (and hopefully different) one.
I see no reason why a job should ever want to be its own controlling job.
-------
26-Jun-85 20:16:28-PDT,1220;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from ucl-cs by SU-SCORE.ARPA with TCP; Wed 26 Jun 85 20:15:00-PDT
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a013307; 27 Jun 85 4:12 BST
Via: DCT; by DUNDEE on Thursday, 27-Jun-85 04:07:54-GMT
Date: Thu 27 Jun 85 04:06:11-GDT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: Save command can overflow the stack
To:
[email protected]
cc: alan%
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Specifying too many blocks of memory to be saved with the save command
causes a PDL trap in EXEC.
@SAVE,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
for example overflows the stack. Simplest cure I suppose should be to check for
stack full when parsing rather than to erjmp the PUSHes. Anyway, over to
someone with sources.
Afterthought: I guess the same happens with the CSAVE command (the what command)
Alan
-------
27-Jun-85 09:05:49-PDT,403;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 27 Jun 85 09:04:28-PDT
Date: 27 Jun 85 12:03:38 EDT
From: Roy <
[email protected]>
Subject: RATFOR
To:
[email protected]
Does anyone have a RATFOR for TOPS-20? I'm trying to bring up ICON
which is written in it and need to apply some patches to the RatFor
sources. Thanks.
Roy
-------
27-Jun-85 15:58:50-PDT,2852;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 27 Jun 85 15:58:35-PDT
Date: Thu 27 Jun 85 15:52:54-PDT
From:
[email protected]
Subject: retransmission delays
To:
[email protected]
TCP round trip time estimates are unreasonably high.
TCP attempts to delay the transmission of a packet with only an ACK
in order to wait for data to insert in the packet, or more data to arrive
to ACK with the same packet. This confuses the sender, who is trying
to compute round trip delays.
The sender, upon receiving the ack, will compute the round trip time
for every packet in the retransmit queue that is within the window.
All of these individual delays are included in the average time by
the smoothing routine at REMSE5.
This is not a very valid round trip time, since the ack spans much
older packets that have been sitting in the retransmit queue for some
time. These will produce an artificially large estimate of round trip
delay. Also, if there are any packets in the retransmit queue that
have not been included in the ack, they will produce a smaller than
real estimate. Most of the packets in the queue are of the former
(older) variety, and result in an overly large estimate.
A better approach would be to compute the round trip delay from the
time delay from only one packet in the retransmit queue. The correct
packet is actually the one that contains the last byte acked by the
ack packet. This is better, but still not exact, since the returned
ack was probably delayed by the call to FRCPKT.
In searching for this, several interesting things were found. One
was that the instructions at REMSE5+1 and REMSE5+2 are wasted, since
T3 is never used before it is reloaded at REMSE5+4.
It appears that if FRCPKT is called with a delay of, say, 250 ms,
and then immediately afterward with a delay of 100 ms, the JN at
FRCPKT will cause the new shorter delay to be ignored. The correct
thing to do is to set the new signal time to be the sooner of the
two times (new request and old remaining).
The cure I chose was to modify the smoothing function parameters
to make it much slower to change, and then to swap the current time
with the previous average if the current time is less than the old
average -- thus making it almost totally dominant. The nice part
of this fix was that it fit in the two 'wasted' instructions mentioned
above. (I guess there was a use for them, after all.) Here is the kludge
that seems to make it work a lot better:
@mddt
=call swpmwe^[x
*tcptcp^[:
*remse5+1/camge t1,t4
*remse5+2/exch t1,t4
*tcprxf[0,,-6
*tcprxs[77
=call swpmwp^[x
=^Z
One possible problem is that this may beat upon gateways harder,
but it beats speeds of 100 baud on large file transfers.
Alan
-------
28-Jun-85 07:00:21-PDT,730;000000000000
Return-Path: <bassen@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Fri 28 Jun 85 06:58:20-PDT
Received: by oslo-vax.ARPA (4.12/4.7)
id AA14466; Fri, 28 Jun 85 15:59:39 -0100
Date: 28 Jun 1985 15:54-EST
From: bassen@oslo-vax (T S Lande)
Subject: DEC-20 netconnection
To: tops-20@su-score
Cc: bassen@oslo-vax
Message-Id: <488818495/bassen@oslo-vax>
I am looking for a cheap way to hook a DEC-2060 on arpa or
decnet. I regard a ethernet-board expensive. Is it possible to
use a standard terminal-line for TCP/IP or DECNET? On our
vax-11/780 running 4.2bsd we have tcp/ip software for
terminal-lines.
Tor Sverre Lande
Institute of Informatics
University of Oslo
28-Jun-85 08:24:12-PDT,758;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 28 Jun 85 08:21:32-PDT
Received: ID <
[email protected]>; Fri 28 Jun 85 11:21:00-EDT
Date: Fri 28 Jun 85 11:20:56-EDT
From:
[email protected]
Subject: Re: DEC-20 netconnection
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "bassen@oslo-vax (T S Lande)" of Fri 28 Jun 85 16:54:00-EDT
I have TCP/IP interfaces for both a DN20/DTE arrangement and for a standard
terminal line. You probably need to have sources to install this, since it
involves making a few changes to some other monitor modules (notably, TTYSRV
and TTPHDV for the tty interface and DTESRV for the DN20/DTE interface).
--Vince
-------
1-Jul-85 01:45:43-PDT,443;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 1 Jul 85 01:44:48-PDT
Date: Mon 1 Jul 85 01:43:56-PDT
From: David Roode <
[email protected]>
Subject: X.25 PSI Interface for TOPS-20
To:
[email protected]
Location: EJ286 Phone: (415) 859-2774
Has anybody used this? How do you like it? What's the loading
effect with many terminals connect through an X.25 net this way?
-------
1-Jul-85 06:22:12-PDT,705;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 1 Jul 85 06:17:50-PDT
Date: Mon 1 Jul 85 07:14:56-MDT
From: The alleged mind of Walt <
[email protected]>
Subject: Re: X.25 PSI Interface for TOPS-20
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "David Roode <
[email protected]>" of Mon 1 Jul 85 02:54:09-MDT
One of my consulting clients compared it to the X.25 package we
developed here at the U of Utah, and found that the PSI package
would not support a number of logical channels adequate to their
needs (which are considerable). Therefore they are now running
the U of Utah interface.
Cheers -- Walt
-------
1-Jul-85 12:38:54-PDT,1445;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Mon 1 Jul 85 12:33:44-PDT
Date: Mon 1 Jul 85 15:36:18-EDT
From: Rob Austein <
[email protected]>
Subject: two galaxy questions
To:
[email protected]
Office: [NE43-502] 545 Technology Square, Cambridge MA 02139; (617) 253-7341
First question. Does anybody have a tool that displays/extracts all
the useful information from a PRIMARY-MASTER-QUEUE-FILE? Mine is
getting very large (900+ pages) but I'd rather not just toss out the
old data if there is a reasonable alternative.
Second question. Anybody out there ever tried to turn on the code for
spooled lineprinters without actually having physical lineprinters? I
am running Bjorn Lindskog's TCPSPL program and would like to have
devices like LPT0:, LPT1:, etcetera (just plain LPT: is not useful,
the printers are not interchangable). I tried putting these devices
into the monitor (ie, I added them to INIDVT), the monitor booted ok
but the devices were left in a weird state where you couldn't write to
them because they were write-only devices, and QUASAR fell on its face
with a COP error (Can't Open Primary master queue file). Before I a
lot of time investigating this I wanted to check if anybody else has
done this or think they know why I am losing. (Yes, I know this isn't
a supported thing to do, no flames please).
Any help appreciated....
--Rob
-------
1-Jul-85 13:23:39-PDT,714;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 1 Jul 85 13:20:45-PDT
Date: Mon 1 Jul 85 13:21:35-PDT
From: Mark Crispin <
[email protected]>
Subject: Re: DEC-20 netconnection
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected]" of Fri 28 Jun 85 11:00:58-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Vince -
I am interested in your DN20/DTE and TTY line TCP drivers. I was
about to do it myself. I'm also hoping sometime to get TCP running on
a 2020 (or write a TCP that will).
-- Mark --
-------
1-Jul-85 21:59:23-PDT,575;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Mon 1 Jul 85 21:59:01-PDT
Date: Tue 2 Jul 85 00:59:10-EDT
From: Ken Rossman <
[email protected]>
Subject: DECSA routers
To:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Anyone out there using a DECSA DECnet router box with 20s (and NI's)? If
so, what sort of performance are you getting, and what kinds of problems
are you seeing?
Also, do these things really have to be downloaded from VAXen or 11's?
/Ken
-------
2-Jul-85 06:54:52-PDT,1219;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Jul 85 06:49:56-PDT
Date: 2 Jul 1985 0948-EDT
From: Tom Blinn <BLINN at DEC-MARLBORO.ARPA>
To: SY.KEN at CU20B
cc: TOPS-20 at SU-SCORE
Subject: Re: DECSA routers
Message-ID: <"MS10(2124)-2+GLXLIB5(0)" 12123786517.11.275.79049 at DEC-MARLBORO.ARPA>
Regarding: Message from Ken Rossman <
[email protected]>
of 2-Jul-85 0106-EDT
Can't vouch for performance or problems, but the reason you need a VAX
or -11 running DECnet MOP is that the software that is loaded into the
DECnet Router is not currently packaged for 36-bit systems, so you can
not get a software kit to install it on your KL. Also, I believe that
the license for the software does not currently list the KL as one of
the supported systems for loading, so you could not get a license to
put the software on the KL. However, these SHOULD be temporary matters.
By the time the DECnet Router is officially supported for use with TOPS
systems, you should be able to get a license and software kit for down-
line loading the DECSA. ** THIS IS NOT A COMMITMENT ** Just a statement
of the obvious.
Tom
--------
2-Jul-85 07:14:55-PDT,807;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Jul 85 07:13:58-PDT
Date: Tue 2 Jul 85 10:13:50-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: DECSA routers
To:
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "Tom Blinn <BLINN at DEC-MARLBORO.ARPA>" of Tue 2 Jul 85 09:48:00-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
release 6.1 of tops20 (actually nml) can load decsa's. we do it all
the time. the problem is that the configator for the decsa software
does not run on a 20. the configurator is a piece of software
which hacks up the binary load file for desired configurations. the
cofigurator is a piece of bliss however....
-------
2-Jul-85 09:51:34-PDT,1196;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Jul 85 09:49:57-PDT
Received: ID <
[email protected]>; Tue 2 Jul 85 12:50:13-EDT
Date: Tue 2 Jul 85 12:50:09-EDT
From:
[email protected]
Subject: IPCF query
To:
[email protected]
Does anyone have any experience using paged-mode IPCF from monitor context? I
am planning to replace most of the functionality of the GTHST jsys with monitor
internal IPCF requests of a user-mode nameserver. I'd like to know some of the
details and potential problems with doing this, in particular:
- What is the best way to assign a process-relative page in monitor
context? Calling ASGPAG?
- Will MSEND and MRECV re-mapping of message pages screw up the monitor's
view of ASGPAG'ed pages? If so, is there some other way to do this?
I am not familiar with the details of the way that MSEND and MRECV remap the
process address space and would like to find out more from someone who knows...
--Vince
P.S. Note that if at all possible, I'd like to use page-mode IPCF, since some
of the data items that will be passed around may be quite large.
-------
2-Jul-85 12:51:59-PDT,511;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Jul 85 12:47:22-PDT
Date: Tue 2 Jul 85 12:47:10-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: two galaxy questions
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Rob Austein <
[email protected]>" of Mon 1 Jul 85 13:12:15-PDT
The program PS:<SU-UTILITIES>QF.PAS on Sierra will print out the contents
of the QUASAR primary master queue file.
Kirk
-------
2-Jul-85 21:56:39-PDT,964;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Jul 85 21:51:52-PDT
Date: Tue 2 Jul 85 21:51:44-PDT
From: David Roode <
[email protected]>
Subject: CI20/Rel. 6.0 pre-release
To:
[email protected]
Location: EJ286 Phone: (415) 859-2774
In the instructions that come with this, DEC says that in CFS
configurations it is important to give the FE Parser command HALT
following the FE Parser command SHUTDOWN. This is supposed to have
the effect of halting the processor in the CI20 sealing the cluster
off from the particular CI20.
Why doesn't the SHUTDOWN command, which halts the CPU, suffice?
Another note: In the same instructions, DEC gives a patch for pre-6.0
monitor to change the channel mask word for the RH20's. They dropped a
zero on their proposed replacement, giving you something which blocks
access to all channels instead of merely the ones preempted by the
CI20.
-------
2-Jul-85 22:56:28-PDT,491;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 2 Jul 85 22:53:17-PDT
Date: Tue 2 Jul 85 23:53:29-MDT
From: Mark Crispin <
[email protected]>
Subject: release 6.0
To:
[email protected]
According to reliable sources at DEC, you should run 6.0 ONLY if
you have a CI20. 6.0 is not a major release of the monitor and will
only have limited distribution. The next major release of the monitor
is 6.1, which is in field test.
-------
3-Jul-85 00:51:07-PDT,790;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Jul 85 00:48:24-PDT
Date: Wed 3 Jul 85 00:48:09-PDT
From: David Roode <
[email protected]>
Subject: Re: release 6.0
To:
[email protected],
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Tue 2 Jul 85 23:04:08-PDT
Location: EJ286 Phone: (415) 859-2774
Release 6.0 as supplied on "pre-release" status for CI20 purchasers
is field test #3 of TOPS-20 version 6. Quite a few people seem to
feel that field test #5, which is considered to have made the
transition to Release 6.1, is a significant improvement over
the software shipped to CI20 owners. As previously discussed
on this list, 6.0 does not support CFS whereas 6.1 does.
-------
3-Jul-85 13:16:24-PDT,968;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 3 Jul 85 13:14:10-PDT
Date: Wed 3 Jul 85 16:14:07-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: CI20/Rel. 6.0 pre-release
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "David Roode <
[email protected]>" of Wed 3 Jul 85 01:01:42-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
the shutdown command merely deposits a non zero number into location 30.
the halt command causes the parser to take commands from halt.cmd in the
front end file system and they do the cono to stop the klipa. if the
klipa is not stopped it will continue to answer request ids from other
systems and the other systems will assume it is up. the monitor is very
carefull not to talk to disks when a system that appears to be up (via
request ids) is not participating in the cfs protocols.
-------
4-Jul-85 23:59:54-PDT,467;000000000000
Return-Path: <steinar@oslo-vax>
Received: from oslo-vax.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Jul 85 23:58:06-PDT
Received: by oslo-vax.ARPA (4.12/4.7)
id AA21116; Fri, 5 Jul 85 08:59:42 -0100
Date: 5 Jul 1985 08:57-EST
From: steinar@oslo-vax (Steinar Kj{rnsr|d)
Subject: UNV file ANAUNV
To:
[email protected], Steinar@oslo-vax
Message-Id: <489398272/steinar@oslo-vax>
Where can I find ANAUNV (.MAC file ) required by
the FINGER environment ?
5-Jul-85 17:02:12-PDT,1257;000000000000
Return-Path: <
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Jul 85 16:56:57-PDT
Date: 5 Jul 1985 16:54-PDT
Sender: GEOFF@SRI-CSL
Subject: MMAILR & SYSDPY Items.
From: the tty of Geoffrey S. Goodfellow <
[email protected]>
To: tops-20@SCORE
Message-ID: <[SRI-CSL] 5-Jul-85 16:54:56.GEOFF>
Has anyone hacked away at MMAILR to temporarily furlough messages
which are sitting in the queue because disk quote is exceeded for
the intended recipient? Ours goes into moby grind and slosh mode
every 30 mins in attempting to deliver these messages time and
again to users who are over quota. I am thinking about having a
4th queue created -- which all mail which fails due to an over
quota condition would fall into and then have that queue only run
once a day at something like 3AM. In our machine being up 24
hours, MMAILR has used over 2 hours of CPU TIME in trying to
deliver over quota type of messages.
Has anyone hacked SYSDPY to order job's on the screen by %age of
CPU used (with perhaps an optional smoothing of over the last 1,
5 or 15 min period)? it would handyly increase the ability to
see who the cycle gobblers are when you have more than a screen
full worth of jobs logged in.
g
5-Jul-85 20:20:45-PDT,1279;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Jul 85 20:17:46-PDT
Date: Fri 5 Jul 85 21:17:13-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: MMAILR & SYSDPY Items.
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "the tty of Geoffrey S. Goodfellow <
[email protected]>" of Fri 5 Jul 85 17:54:00-MDT
I think you are mistaken about where
MMailr spends its time. Most MMailr
time is spent in MMailbox recompilations
and in normal queue processing.
People who send 120Kchar messages to
net sites which blow up in the middle
of transmission all the time are
rather expensive too.
Something may be badly wrong in your
Foonly-based version of TOPS-20.
MMailr in normal operation is about
5 to 2% of the CPU aggragate. The
8% figure you gave (2 CPU hours in a
day) seems high although I don't know
what kind of mailing list traffic you
do.
I think spreading out over quota
retries to once a day (a very simple
change that does NOT require a new
queue stream) is a horrible idea.
There are users who are regularly
over quota and are irked enough by
having to wait 30 minutes for a
retry. A better solution is more
reasonable disk quotas.
-- Mark --
-------
8-Jul-85 14:31:52-PDT,1139;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Jul 85 14:30:30-PDT
Date: Mon 8 Jul 85 14:31:29-PDT
From: Frank <
[email protected]>
Subject: MCA25 question
To:
[email protected]
Is anybody running a 6/6.1 monitor with an MCA25? We run 5.3 and just
had an MCA25 installed. There is a bit in the APRID word saying the MCA25
exists. On a 5.3 monitor (Ucode version 353), this bit shows up as 1B5.
I've checked this on four systems. 1B5 is in the Ucode options field.
Indeed, the DDT patch from DEC for the release 5 monitors tests bit 5.
However the release 6 monitor checks 1B23 to see if the MCA25 exists. 1B23
is an unused bit in the hardware options field so it seems reasonable to
use this for the MCA25 flag. Somehow this flag moves (or does it?) from the
left to right half for release 6 monitors.
If you're running release 6/6.1 and have an MCA25, I'd like to know if
bit 23 is on in the APRID word. If it isn't, then you're not making use
of the KEEP bit in the pager (see the STKEEP routine in APRSRV).
Thanks much, Frank G.
-------
8-Jul-85 16:03:11-PDT,865;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Jul 85 15:59:44-PDT
Date: Mon 8 Jul 85 15:56:04-PDT
From: David Roode <
[email protected]>
Subject: Re: MCA25 question
To:
[email protected],
[email protected]
In-Reply-To: Message from "Frank <
[email protected]>" of Mon 8 Jul 85 15:07:05-PDT
Location: EJ286 Phone: (415) 859-2774
This is a very interesting question on the MCA25. I have
something completely different! We are still testing 1B5, as in 5.3,
but as you say, the APRID word is returning 0 in 1B5 and 1 in 1B23.
It looks like 1B23 is a better thing to test than 1B5,
and you have inadvertently pointed out a complementary problem
at our site. We are running 6.0, ucode 400. The microcode version
is probably an operant characteristic in which bit to test.
-------
8-Jul-85 22:10:02-PDT,1094;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 8 Jul 85 22:06:13-PDT
Date: Mon 8 Jul 85 23:07:30-MDT
From: Mark Crispin <
[email protected]>
Subject: AP9 bug
To:
[email protected]
In TOPS-20 Autopatch 9, edit 3140 introduces a bug in DIRECT which
breaks SNDMSG-style of message sending. Personally, I think that
SNDMSG-style mailing is a crock and should be flushed, but some
people want it.
Basically, what DEC is trying to do is that if you open a file
with GJ%FOU and GJ%OLD, if the FDB was deleted it should destroy
the deleted FDB and create a new one. Edit 3140 restricts this
so that it happens only if you have create file access to the
directory, so the automatic undeletion of this pair of bits only
works to those directories you have create access.
This is, unfortunately, irreconcilable with the notion of a permanent
FDB.
I have a rewrite of the code if anybody is interested. A part of me
says that anybody who uses SNDMSG deserves to lose, so I'm not
posting it unless somebody wants it.
-------
9-Jul-85 10:37:26-PDT,637;000000000001
Return-Path: <cew@isi-hobgoblin>
Received: from isi-hobgoblin.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Jul 85 10:35:48-PDT
Received: by isi-hobgoblin.ARPA (4.12/4.7)
id AA28105; Tue, 9 Jul 85 10:37:13 pdt
Message-Id: <
[email protected]>
Date: 9 Jul 1985 1037-PDT (Tuesday)
From: Craig E. Ward <
[email protected]>
To: info-vax@sri-kl
Cc: tops-20@su-score
Subject: Tops-20 to VMS
A friend of mine at a non-net site needs to be able to read Tops-20 Dumper
tapes on a VMS 3.6 system. Does anyone have anything which allows VMS
to read Dumper tapes (and is willing to share it)?
Thanks
Craig
9-Jul-85 11:40:23-PDT,651;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Tue 9 Jul 85 11:38:41-PDT
Date: Tue 9 Jul 85 11:15:15-PDT
From: David Roode <
[email protected]>
Subject: Re: Tops-20 to VMS
To:
[email protected],
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Craig E. Ward <
[email protected]>" of Tue 9 Jul 85 10:37:00-PDT
Location: EJ286 Phone: (415) 859-2774
A standard mode of interchange is an ANSI standard labeled magnetic
tape, which both TOPS-20 and VAX/VMS can read. Names are stored
for files on the tape, but no other directory information
is kept.
-------
10-Jul-85 13:36:49-PDT,358;000000000000
Return-Path: <
[email protected]>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Wed 10 Jul 85 13:33:03-PDT
Date: Wed 10 Jul 85 16:34:18-EDT
From: Bill Schilit <
[email protected]>
Subject: looking for ed
To:
[email protected]
Does anyone know of a version of UNIX "ed" for the DEC-20? Yes, I'm
serious.
- Bill
-------
10-Jul-85 19:38:35-PDT,971;000000000000
Mail-From: MRC created at 10-Jul-85 19:38:18
Date: Wed 10 Jul 85 19:38:18-PDT
From: Mark Crispin <
[email protected]>
Subject: new release of MM mailsystem
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
A new release of the MM mailsystem is now available. This release
is on SCO:<MM> at SU-SCORE as usual. The main changes in this new release
are that (1) MM now generates Message-ID's (sigh!) and uses them in an
In-Reply-To field if available (our friends in Europe will appreciate this),
and (2) there are several internal changes to make MM more "domains-ready".
Specifically, the function of canonicalizing a name to the official name of
the node has been moved from the various modules to a new routine, $GTCAN,
in HSTNAM, for the days when names and addresses will not have the tight
association they now have.
-------
10-Jul-85 22:26:27-PDT,950;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 10 Jul 85 22:24:06-PDT
Date: Wed 10 Jul 85 22:24:46-PDT
From: Mark Crispin <
[email protected]>
Subject: warning on new MM
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
In order to support the Message-ID functionality, MM's internal
per-message data structure grew by a word. This temporarily breaks
the format of BBoard IDX files.
The way to work around this problem is to connect to your BBoard
directory and do:
COPY *.TXT.* *.*.*
which will update the write dates on all the BBoard TXT files. Ignore
the error messages (?Can't expunge file because it is currently open)
you will get. The next person to run MM on that BBoard will recompile
the IDX file in the new format.
-------
11-Jul-85 07:15:03-PDT,496;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Jul 85 07:14:29-PDT
Date: Thu 11 Jul 85 09:49:47-EDT
From: Ittai Hershman <
[email protected]>
Subject: The Real Thing
To:
[email protected]
For those who haven't heard, the Coca-Cola company is swallowing its pride
and is returning the old Coke formula under the name "Coca Cola Classic".
DEC, I can see it now -- The "DEClassic" line of 36-bit computers.
:-)
-Ittai
-------
11-Jul-85 08:15:58-PDT,630;000000000000
Return-Path: <MHICKEY%
[email protected]>
Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Jul 85 08:15:01-PDT
Received: from (MAILER)UDCVM.BITNET by WISCVM.ARPA on 07/11/85 at
10:16:33 CDT
Return-path: MHICKEY%
[email protected]
Received: by UDCVM (Mailer X1.21) id 7101; Thu, 11 Jul 85 09:22:36 EST
Date: Thu, 11 Jul 85 09:21 EST
From: Mike Hickey <MHICKEY%
[email protected]>
Subject: Windowing SYSDPY
To: <
[email protected]>
Has anyone else heard of a windowing version of SYSDPY? I've heard vague
hints towards one but have yet to find it. /Mike
11-Jul-85 08:55:48-PDT,616;000000000000
Mail-From: KNIGHT created at 11-Jul-85 08:55:13
Date: Thu 11 Jul 85 08:55:13-PDT
From: Bob Knight <
[email protected]>
Subject: Cheap MG20s.
To:
[email protected]
Message-ID: <
[email protected]>
I have in my possession an MG20E that I purchased for $16,800. Since
its doubtful that I could get another purchase past the powers that be at
New Mexico Tech, I'm willing to pass along the name and number of the
company that I purchased them from, if you mail to me (I'm trying to avoid
anything that might be construed as advertisement on this mailing list).
Bob
-------
11-Jul-85 15:34:12-PDT,641;000000000000
Return-Path: <
[email protected]>
Received: from UTEXAS-20.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Jul 85 15:33:13-PDT
Date: Thu 11 Jul 85 17:35:22-CDT
From:
[email protected]
Subject: Password Expiration under Tops-20
To:
[email protected]
Has anyone considered/investigated/implemented password
expiration under TOPS-20 ? My boss (who has obviously been
VAX-inated) is comfortable with this feature as it exists under
VMS, and would like to see the same feature on our -20s. This is
obviously a "job for ACJ", but I would be interested in others'
opinions/ideas/discussions.
Thanks, David Fordyce
-------
11-Jul-85 15:44:52-PDT,379;000000000000
Mail-From: BILLW created at 11-Jul-85 15:44:37
Date: Thu 11 Jul 85 15:44:37-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: Disk errors...
To:
[email protected]
Message-ID: <
[email protected]>
Does anyone have a program that will find the file name of a file
containing a specific drive/cylinder/surface/sector?
BillW
-------
11-Jul-85 18:28:26-PDT,1624;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 11 Jul 85 18:28:10-PDT
Date: 11 Jul 1985 2125-EDT
From: Tom Blinn <BLINN at DEC-MARLBORO.ARPA>
To: billw at SU-SCORE
cc: tops20 at SU-SCORE
Subject: Program to find file containing disk address
Message-ID: <"MS10(2124)-2+GLXLIB5(0)" 12126272638.12.275.55158 at DEC-MARLBORO.ARPA>
You already have most of such a program. You need to translate the drive/
cylinder/surface/sector information to a relative address on the structure,
which may be what you already have anyway, if the information is coming
from SPEAR. Then you can use the SCAN command in CHECKD to examine the
disk structure. The CHECKD Specification in volume 12 of the TOPS-20
Software Notebook Set explains that this is the use of SCAN, but fails
to document the format of the input file, claiming that Field Service has
programs that generate the input file for SCAN.
I suggest you get out your CHECKD sources and examine the parsing for the
SCAN command. As I recall, it is not difficult to decode the file format
from the input parsing. (I also recall that the code was rather buggy,
but I hope it has been fixed since the last time I looked at it.)
Once you feed CHECKD the disk addresses you want (which can be calculated
from the drive, cylinder, surface, and sector), it will scan the directories
on the disk to identify the file (or files, in the case of a damaged disk
with multiply assigned pages) containing the address in question.
I hope this information is what you're looking for.
Tom
--------
12-Jul-85 05:54:55-PDT,604;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Fri 12 Jul 85 05:52:24-PDT
Date: Fri 12 Jul 85 08:49:48-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: Password Expiration under Tops-20
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Thu 11 Jul 85 18:41:59-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
there is code is the relase 6 and 6.1 monitors for this. it is not a
supported feature but you can use it via the crdir j
-------
14-Jul-85 14:11:48-PDT,1187;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 14 Jul 85 14:11:30-PDT
Date: Sun 14 Jul 85 15:13:08-MDT
From: Mark Crispin <
[email protected]>
Subject: PWRFL bughlts
To:
[email protected]
Message-ID: <
[email protected]>
I am really getting rather sick and tired of PWRFL bughlts. Once
upon a time TOPS-20 could survive brief power failures. This seemed
to end when MF20 memory appeared. First the MF20 backup battery didn't
work and the MF20 configuration got blown away. That was obvious because
of the long wait for the DBE scan. That seems to have gone away more or
less, but now the system is evidentally not completing its power down
sequence.
Is this a software bug? Has anybody rewritten the power fail
interrupt code so that it runs fast enough to finish before the power
completely vanishes? Perhaps there is a hardware bug with MF20 which is
stopping the CPU a few milliseconds too quickly?
I remember the old days when DEC computers survived even very long
power outages without requiring a reload. I don't think the present
situation is an improvement.
-------
15-Jul-85 07:21:26-PDT,2314;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Jul 85 07:20:52-PDT
Date: Mon 15 Jul 85 10:19:18-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: PWRFL bughlts
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 15 Jul 85 08:32:25-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
The Power fail code is very hard to test. using the switchon the kl is
not good ennough as that implies the power sequencer. the only real way
to test this is to have a big breaker somewheres that kills all the
phases at once. we can do this because all our machines are on bus
bars. fs people tend to really dislike your testing the power fail code
with their machine. we have to station people at the doors to the labs
to make sure they do not see us testing it out.
anyways the power fail code was known to work in release 5.0 as shipped
to the sdc. we did a lot of testing and fixed some bugs. at some pont
in release 5.1 it got broke several ways. one of the ways was that the
cpu microcode would no longer allow the monitor to turn off paging once
it was enabled. that would cause the cpu to hang in the microcode. due
to some sprs (from ireland where power seems to be really bad, multiple
failures per day for years) we fixed power fail recovery in 5.1
autopatch.
at this instant power fail recovery does not work in 5.4, 6 and 6.1 due
to the klni and klipa. that code is being fixed as we speak and should
work by 6.1 sdc time.
there are some known problems however (at least known to me). RSX20F
and or the BM873 bootstrap rom seem to have some problems. I have seens
hangs in both 20f and in the bootstrap rom after power fails. they have
not been reproducable but certain real power fails have shown this
problem. it is really interesting to see six different cpus all hung in
the bootstrap after a power fail. at least the hardware is consistant.
in any case you should look at your dumps and find out why the power
fail code did not finish. i suspect physio still had some io in
progress. are you running meis's? do they slow this down for some
reason?
-------
15-Jul-85 12:49:49-PDT,357;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Jul 85 12:46:34-PDT
Date: Mon 15 Jul 85 12:48:25-PDT
From: Harry Sameshima <
[email protected]>
Subject: Orion problem
To:
[email protected]
Deleting files with archive status crashes Orion. Does anyone have
a fix for this problem?
Harry
-------
15-Jul-85 14:51:54-PDT,728;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Jul 85 14:49:29-PDT
Date: 15 Jul 85 17:50:06 EDT
From: Rob Liebschutz <
[email protected]>
Subject: Re: Orion problem
To:
[email protected],
[email protected]
In-Reply-To: Message from "Harry Sameshima <
[email protected]>" of 15 Jul 85 15:48:25 EDT
What version of ARMAIL are you running (Armail is the routine that
sends out mail about expunged/deleted archived files etc)? We have
been having similar problems which we have found to be related to the
non-dec version of ARMAIL that we are running. You can check this
very easily by replacing the entry points in ARMAIL with a "popj p,".
Rob
-------
15-Jul-85 17:06:36-PDT,1237;000000000000
Mail-From: BILLW created at 15-Jul-85 17:06:23
Date: Mon 15 Jul 85 17:06:23-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: 6.1 Exec bug fixes.
To:
[email protected]
Message-ID: <
[email protected]>
Command editing doesn't work properly on TCP virtual terminals under
release 6.1 - the line being edited is printer one space too far to the
left. An identical exec.exe works fine under version 5.3, however.
Diagnosis: IAC doubling was removed from 6.1 TTYSRV. However, The exec
outputs STG cursor control strings terminated by .STP==.IAC, causing
the character after a CLREOL or backspace operation to be eaten as a
telnet option.
Solution: the EXEC should not output the terminating .STP code when
doing cursor commands. (note that this could have messed up terminals
that do something other than padding with "rubout", too). (Whether or
not the monitor should do IAC doubling automatically is another
question!). Add a routine STPOUT that outputs a string without the
terminating .STP
I also re-added the SUN48 terminal type, and changed some messages from
"redo remembers" to "history". The sources or Sushi and Sierra have
been updated.
BillW
-------
15-Jul-85 19:23:34-PDT,1049;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Jul 85 19:23:07-PDT
Date: 15 Jul 85 22:26:56 EDT
From: Charles Hedrick <
[email protected]>
Subject: drilling holes in cement
To:
[email protected]
Some time ago we mentioned a disaster due to somebody drilling holes
in a cement column in our machine room. Cement dust is horrible
stuff. It got in the disk drives and we had head crashes, etc.
At that time I asked what people did to avoid this. One site
responded that when they did dusty things they set up a tent in
the machine room. They would put plastic from floor to ceiling,
taping it to the floor, etc. One of my staff came up with a simpler
solution. He put a wet sponge over the concrete, and they drilled
through that. No observable dust or any other problems. We're
thinking of applying the same solution to people who smoke in the
machine room. They will have to breathe through a wet sponge. We
think that will solve their smoking problem.
-------
15-Jul-85 23:30:16-PDT,1537;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 15 Jul 85 23:25:43-PDT
Date: Tue 16 Jul 85 00:27:24-MDT
From: Mark Crispin <
[email protected]>
Subject: machine room dust
To:
[email protected]
Message-ID: <
[email protected]>
I am interested in this. I am installing a 2020 (yes, I am finally
getting my home computer) in a relative small (7'x15') room which was just
recently built. More specifically, it is part of a larger room which was
converted into several smaller rooms. The walls are sheet rock and the
roof (at 8') plywood. There was an amazing amount of dust from the
construction; I swept and vacuumed up most of this but since there is
carpeting (unavoidable, alas) I couldn't get all of it. Anyway, the
shipping crates for the equipment tracked in more wood dust.
What have people used for wood dust abatement, such as after the
equipment has been decrated? Simply repeated vacuuming? Has anybody
installed a system on carpeting (the short pile of the sort you see in
heavily-travelled hallways), and if so what have you done to abate the
problems carpeting introduces? Static mats have already been suggested;
where can I get them and how much do they cost?
Anybody have experience with RM03's? How often would you change the
filters? How would you weigh the expense ($500 or so) and risk of changing
a filter vs. not changing filters and buying a new drive ($1750) when the
drive finally dies?
-------
17-Jul-85 16:50:40-PDT,1115;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Wed 17 Jul 85 16:50:23-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 17 Jul 1985 19:43:20 edt
Date: 17 Jul 85 19:58 +0100
From: Peter_Lothberg_STUPI%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: machine room dust
Message-ID: <114363@QZCOM>
In-Reply-To: <
[email protected]>
I have a simular problem running an 1070 as a pc, with rp06 and rp04:s,
in the pricelist i found the rm03 filters are listed at
36$. The RM03 is a very stable drive, manufactured by cdc and
used by a lot of different computer manufacturers, so finding
spare parts would not cause any problems. Has anybody tried
to put the DEC massbuss interface from an rm03 to a 300 meg cdc
drive, they have the same drive interface.
18-Jul-85 06:32:50-PDT,1443;000000000000
Return-Path: <
[email protected]>
Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Thu 18 Jul 85 06:30:12-PDT
Return-Path: <
[email protected]>
Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Thu, 18 Jul 85 09:32:03 EDT
Received: by enea.UUCP; Thu, 18 Jul 85 02:01:50 -0200
Received: by enea.UUCP; Thu, 18 Jul 85 02:01:46 -0200
Received: by kuling.UUCP; Thu, 18 Jul 85 00:42:36 -0200
Message-Id: <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Subject: Lost monitor edits
Date: 18 Jul 85 00:42:31 N (Thu)
From: Bjorn Victor <
[email protected]>
Has anybody got an idea about how to find the following edits for the
5.1 monitor (yes, we haven't got higher yet)? I found them while
browsing through the Autopatch edit descriptions, but I can't find the
edits in my Dispatches, CTCOs or in the CUPID database.
The one most disturbing not to have (2839) is for bad bytepointers,
since I need it badly (we use g2bpt's and g1bpt's a lot, and it's
annoying to trace down a 77xxxx,,yyyyyy-pointer to psout in a dump).
The edits I'm looking for is: 2821, 2839, 2841, 2842, 2845, 2850, 2870,
2878, 2886, 2888, 2904, 2905, 2906, 2916, 2934,2935,2940, 3036 and 3984.
Help!
Bjorn Victor UUCP: {mcvax,decvax,seismo}!enea!kuling!victor
Computing Science Dept., Uppsala University
PO Box 2059, S-750 02 UPPSALA, SWEDEN
18-Jul-85 14:15:38-PDT,954;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Jul 85 14:14:53-PDT
Date: Thu, 18 Jul 1985 15:16 MDT
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: AP#10 letter
Just received in today's USPS, which I fortunately get at home or it
would have been ANOTHER week... It was postmarked 15 JUL 1985... Can
we get someone at Stow to also get such things posted on the net in a
timely manner, please? (I presume this applies only to the big tape
and NOT the EXEC and MONITR source update tapes, right?)
--Frank
--------------------
12 July 1985
Dear TOPS-20 V5.1 Customer:
Please do not use the Autopatch tape 10. We will shortly
redistribute a new Autopatch tape 10.
I am very sorry for this inconvenience.
Sincerely,
Don Fitzgerald
Software Product Service (LCG)
====================
18-Jul-85 15:07:15-PDT,987;000000000001
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Jul 85 15:06:56-PDT
Date: Thu 18 Jul 85 18:08:29-EDT
From: Ittai Hershman <
[email protected]>
Subject: Re: AP#10 letter
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from ""Frank J. Wancho" <
[email protected]>" of Thu 18 Jul 85 17:49:14-EDT
Last week I mounted the binary tape and tryed to print it in Dumper. It
barfed. I tried interchange format -- success. I figured some idiot in
SDC decided that would be a good idea, so I went on. I restored the
README.010 file and realized that it was a TOPS-10 distribution!!! Went
into the machine room and checked the label --it said TOPS-20. I was
about to ask if this happened to everyone when I got the letter. Notice
there was no explanation in the letter. Well, now you know why...
Imagine how much this cost DEC!!! I bet that's one less person working
in SDC.
-Ittai
-------
18-Jul-85 21:24:28-PDT,645;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 18 Jul 85 21:24:18-PDT
Date: Thu 18 Jul 85 22:00:49-MDT
From: Mark Crispin <
[email protected]>
Subject: bug which causes INTFRx bughlts
To:
[email protected]
Message-ID: <
[email protected]>
In module TCPTCP, routine BUFHNT, the following two instructions:
JUMPE BFR,R ; return if none
SETSEC BFR,INTSEC ; make global address
should be in the code before the call to USRBFF. Some people have neither
instruction, some have only the JUMPE. Bill Westfield at Stanford
originally noticed the anomality.
-------
19-Jul-85 08:35:05-PDT,1123;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 19 Jul 85 08:33:56-PDT
Date: 19 Jul 85 11:35:42 EDT
From: Roy <
[email protected]>
Subject: TCP/UDP echo ...
To:
[email protected],
[email protected]
cc:
[email protected]
Does anyone have user level code that will be an Echo user (UDP and/or
TCP)? I have a server for UNIX and want a corresponding user program
for it. I'd like it to run on 4.2BSD UNIX (Pyramid 90x and Sun),
Tops-20, VMS (Wollongon TCP software), and an IBM-PC running the MIT
TCP/IP code; but an willing to transport code if need be. I'd also like
to be able to use the character generator (infinite source) and
character eater (infinite sink) services. I want to test our network
(reachability) with this and also (if possible) get a measure of delays
between various machines and through various routes and some kind of
throughput figure. Thanks for any help, pointers, whatever. Please
feel free to pass this on to anyone who might be helpful. I'll post a
summary of responses if someone wants them.
Roy
-------
19-Jul-85 08:40:58-PDT,486;000000000000
Return-Path: <iglesias@uci-icsa>
Received: from UCI-ICSA by SU-SCORE.ARPA with TCP; Fri 19 Jul 85 08:36:39-PDT
To: tops-20@su-score
Subject: Used equipment
Date: 19 Jul 85 08:38:35 PDT (Fri)
From: Mike Iglesias <iglesias@uci-icsa>
Received: from Localhost by UCI-ICSA; 19 Jul 85 08:38:46 PDT (Fri)
If anybody is interested in a used KI-10 system (minus the disks), please
contact me ASAP.
Mike Iglesias
University of California, Irvine
iglesias@uci-icsa
(714) 856-6926
19-Jul-85 12:54:44-PDT,925;000000000000
Return-Path: <JSOL%BUCS20%
[email protected]>
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Fri 19 Jul 85 12:54:20-PDT
Received: from bostonu by csnet-relay.csnet id al18241; 19 Jul 85 15:25 EDT
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA02716; Fri, 19 Jul 85 13:07:33 edt
Date: Fri, 19 Jul 1985 13:06 EDT
Message-Id: <[BUCS20].JSOL.19-Jul-85 13:06:51>
From: Jon Solomon <JSOL%BUCS20%
[email protected]>
To: Ittai Hershman <
[email protected]>
Cc:
[email protected],
[email protected]
Subject: AP#10 letter
Phase-Of-The-Moon: NM+2D.11H.47M.17S.
In-Reply-To: Msg of 18 Jul 1985 18:08-EDT from Ittai Hershman <NYU.ITTAI at CU20B.ARPA>
The same thing happened here at BU. I was frantically installing all
of the software I had in preparation for the latest AUTOPATCH, and
lo' and behold! It was a TOPS-10 tape in a TOPS-20 box!!
--JSol
19-Jul-85 15:56:47-PDT,574;000000000000
Return-Path: <root%
[email protected]>
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Fri 19 Jul 85 15:54:34-PDT
Received: from bostonu by csnet-relay.csnet id ak18905; 19 Jul 85 17:26 EDT
Received: by bu-cs.ARPA (4.12/4.7)
id AA06009; Fri, 19 Jul 85 16:19:56 edt
Date: Fri, 19 Jul 85 16:19:56 edt
From: BostonU SysMgr <root%
[email protected]>
To:
[email protected]
Subject: Re: AP#10 letter
Gee, I don't know what the complaints are all about...keep those
scratch tapes coming...
-Barry Shein, Boston University
22-Jul-85 02:58:10-PDT,698;000000000000
Mail-From: MRC created at 22-Jul-85 02:58:03
Date: Mon 22 Jul 85 02:58:03-PDT
From: Mark Crispin <
[email protected]>
Subject: new version of TELNET available
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
A new version of TELNET has been released. The major change
to this version is a fix to network interrupt handling for TCP and
Pup. Network interrupts (ie fast response to CTRL/O) won't work
without monitor fixes -- more on that in another message.
The new version of TELNET is on SCO:<TELNET> at SU-SCORE,
available via ANONYMOUS FTP.
-------
22-Jul-85 03:23:05-PDT,2375;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Jul 85 03:18:05-PDT
Date: Mon 22 Jul 85 04:19:54-MDT
From: Mark Crispin <
[email protected]>
Subject: bug in .TCSPC function of TCOPR%
To:
[email protected]
Message-ID: <
[email protected]>
Problem:
The .TCSPC function of TCOPR% doesn't work worth
diddlysquat.
Diagnosis:
The DTCSPC routine in TCPJFN neglects to set up the forks
which want the PSI in the TCB when setting up the PSI channel.
Solution:
Set up the forks. I choose to do this the way CHANL% works,
that is, setting the channel to 77 means "do not change the
channel for this condition" rather than "turn off PSI for this
condition". While this removes the ability to turn off PSI's for
a condition I think it is more useful to be able to have PSI's
for more than one fork on a TCB.
In TCPJFN.MAC, delete the code which is IFE PANDASW and
insert the code which is IFN PANDASW:
DTCSPC: ;set PSI channels
UMOVE T1,3 ;get users AC3
SETCA T1,T1 ;complement the AC
TXNE T1,<TC%TXX> ;any bad bits on?
JRST DTSPC2 ;yes
SETCA T1,T1 ;get the AC back
IFE PANDASW,< ;[3]
LDB T3,[POINTR T1,TC%TPU] ;get the urgent channel
STOR T3,TPICU,(TCB) ;store away the urgent channel
LDB T3,[POINTR T1,TC%TER] ;get the error channel
STOR T3,TPICE,(TCB) ;store away the error channel
LDB T3,[POINTR T1,TC%TSC] ;get the state change channel
STOR T3,TPICX,(TCB) ;store away the state change channel
>;IFE PANDASW
IFN PANDASW,< ;[3]
MOVE FX,FORKX ;get fork number
LDB T3,[POINTR T1,TC%TPU] ;get the urgent channel
CAIN T3,77 ;making any change?
IFSKP.
STOR T3,TPICU,(TCB) ;no, store away the urgent channel
STOR FX,TPIFU,(TCB) ;set the urgent fork handle
ENDIF.
LDB T3,[POINTR T1,TC%TER] ;get the error channel
CAIN T3,77 ;making any change?
IFSKP.
STOR T3,TPICE,(TCB) ;store away the error channel
STOR FX,TPIFE,(TCB) ;set the error fork handle
ENDIF.
LDB T3,[POINTR T1,TC%TSC] ;get the state change channel
CAIN T3,77 ;making any change?
IFSKP.
STOR T3,TPICX,(TCB) ;store away the state change channel
STOR FX,TPIFX,(TCB)
ENDIF.
>;IFN PANDASW
RETSKP ;return success
NOTE: With this fix in and the latest version of TELNET CTRL/O
ought to work over the network!
-------
22-Jul-85 18:41:17-PDT,2143;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Jul 85 18:38:39-PDT
Date: Mon 22 Jul 85 18:38:49-PDT
From: Mark Crispin <
[email protected]>
Subject: MM for CFS clusters
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
I am beta-testing a new version of the mailsystem in a CFS
cluster environment, using DEC's POBOX: definition as well as
having various other fixes. I have encountered the following two
questions and am soliciting comments from the community and from
DEC:
Right now, MMailbox will recompile the binary file any time
it is privileged and notices that the MAILING-LISTS.TXT file has
been updated. This has occasionally caused a "battling MMailbox"
problem which might be made worse if MAIL: is shared between
different CPUs in a CFS cluster. I am considering a change to
MMailbox which will recompile the binary file only when MMailbox
is explicitly run by a privileged user and not as an inferior
under MM or MMailr. This means that when MAILING-LISTS.TXT is
edited, the person who did the editing would have to run MMailbox
for the changes to "take". Is this seriously objectionable?
There is some question as to what the special SYSTEM mailbox
should be. Apparently some programs believe that SYSTEM should
be SYSTEM:MAIL.TXT. The present implementation of MM uses
POBOX:<SYSTEM>MAIL.TXT (which is what it would be in any case if
SYSTEM was not files-only). Since SYSTEM: can be redefined to be
things such as <NEW-SYSTEM>, etc. yet its mail has always been
on PS:<SYSTEM> before, I that POBOX:<SYSTEM>MAIL.TXT is correct.
I am soliciting comments on this question, since there are
some good arguments for both. Specifically, should SYSTEM mail
be for an individual CPU, or should it be for the entire cluster?
DEC's opinion on the latter issue (since the mailsystem does
have to interact with DEC's mail products) is especially solicited.
-- Mark --
-------
22-Jul-85 22:58:23-PDT,3410;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Mon 22 Jul 85 22:57:28-PDT
Date: Tue 23 Jul 85 01:58:06-EDT
From: Ken Rossman <
[email protected]>
Subject: Re: MM for CFS clusters
To:
[email protected],
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Mon 22 Jul 85 21:46:44-EDT
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
We're already working along certain lines to make the mailer "work right"
under CFS, since we already have a 2-system CFS, a third on the way later
this week, and the fourth to come before the summer is out.
Right now, MMailbox will recompile the binary file any time it is
privileged and notices that the MAILING-LISTS.TXT file has been updated.
This has occasionally caused a "battling MMailbox" problem which might be
made worse if MAIL: is shared between different CPUs in a CFS cluster.
First off, I think it's bad news to have a common queue for all systems in
a CFS cluster. Keep them all separate, and keep separate MAILING-LISTS.*
files, that's my vote. It doesn't make a whole lot of sense to merge mail
queues (i.e. have a single shared MAIL: directory) anyway. It makes more
sense, and least to me, to only use the CFS features when you find that you
are delivering "network mail" between two CFS systems, and do local
delivery to the receiving user's MAIL.TXT using CFS instead of the usual
network delivery path. This is already working on CU20D here (MAIL.TXT
lives on a separate working structure (an RA81 structure), and PS's (or
more generally, nonshared massbus structures) are used for almost nothing
as far as most normal users are concerned.
I am considering a change to MMailbox which will recompile the binary
file only when MMailbox is explicitly run by a privileged user and not as
an inferior under MM or MMailr.
I don't see any need to do this really (that is, unless the multi-MMAILBOX
race condition on a single system described earlier is really a bad one,
which I don't think it is here). I don't think I'd find the change
"objectionable" though.
There is some question as to what the special SYSTEM mailbox should be.
Apparently some programs believe that SYSTEM should be SYSTEM:MAIL.TXT.
The present implementation of MM uses POBOX:<SYSTEM>MAIL.TXT (which is what
it would be in any case if SYSTEM was not files-only). Since SYSTEM: can
be redefined to be things such as <NEW-SYSTEM>, etc. yet its mail has
always been on PS:<SYSTEM> before, I that POBOX:<SYSTEM>MAIL.TXT is
correct.
I'd go for leaving SYSTEM mail defined as POBOX:<SYSTEM>MAIL.TXT. If you
want to be able to deliver to PS:<SYSTEM>MAIL.TXT specifically, you can set
up special aliases for it (although it might also require some special
coding in MMAILR to prevent nonprivved users from posting in that file).
What we'd like to be able to do is be able to post SYSTEM mail into a
common system mail file (POBOX:<SYSTEM>MAIL.TXT), say, 90% of the time, so
that it's always a local delivery job, and individual user access can be
checked directly, but we'd also like to be able to post separate system
notices in PS:<SYSTEM>MAIL.TXT every now and then. If I had to pick one or
the other, though, I'd still go for the POBOX:<SYSTEM>MAIL.TXT as default.
/Ken
-------
23-Jul-85 13:04:40-PDT,2349;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 23 Jul 85 13:01:23-PDT
Date: Tue 23 Jul 85 14:01:19-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: MM for CFS clusters
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "Ken Rossman <
[email protected]>" of Tue 23 Jul 85 00:45:50-MDT
Message-ID: <
[email protected]>
Ken -
You can stop work on your CFS mailer project. It is done
already, and the software will be released once beta testing is
finished. LOTS has a very complicated case, because they have
modified their monitor to have logins happen from a CFS structure
separate from the system structure. This required divorcing PS:
in zillions of cases when the "login structure" was intended,
although after some discussion about semantics it was decided
that PS: really should be the login structure and not the system
structure (where the system is booted and where swapping happens
from).
The mailsystem will work with any set of MAIL:, MAILQ:,
and/or POBOX: shared. LOTS wants all of them shared. There is
no administrative difference between the machines there other
than for load-balancing considerations. They would like to have
login automatically put the logging-in user on the least loaded
machine at login time, so it can change each time the user logs
in.
I realize that there is also the case where the are
administrative boundaries between machines, as at Columbia. The
mailsystem supports this type of setup as well. The main
difference is whether you want to have POBOX: shared. There is
really no reason not to share MAIL: now that the "&" construct
exists and MAILQ: sharing is useful primarily to avoid the file
lockout problems on a shared POBOX:.
On the other hand there is the release 5 case where none are
shared. The mailsystem is fully upwards and downwards compatible
with release 5 and release 4 (it will be run in vanilla form on
my 2020).
The main hurdle to be overcome right now is the question of
documentation, since there are so many configuration options and
semantics in using the various options that I will have to write
up a small document describing how to do the various options.
-- Mark --
-------
23-Jul-85 19:49:14-PDT,753;000000000000
Return-Path: <JSOL%BUCS20%
[email protected]>
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Tue 23 Jul 85 19:47:10-PDT
Received: from bostonu by csnet-relay.csnet id ae13573; 23 Jul 85 22:27 EDT
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA24599; Tue, 23 Jul 85 17:27:07 edt
Date: Tue, 23 Jul 1985 17:27 EDT
Message-Id: <[BUCS20].JSOL.23-Jul-85 17:27:23>
From: Jon Solomon <JSOL%BUCS20%
[email protected]>
To:
[email protected]
Subject: EXEC source part number
Phase-Of-The-Moon: NM+6D.16H.7M.37S.
Does anyone know the part number for the TOPS-20 EXEC sources off hand?
Also, what does it cost to obtain said source (we are a university
if that helps).
Thanks,
--JSol
24-Jul-85 05:48:11-PDT,799;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Jul 85 05:43:42-PDT
Date: Wed 24 Jul 85 08:35:59-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Changing of the guard
To:
[email protected],
[email protected],
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
I am leaving Digital Equipment to accept a position at another computer
manufacturer effective August 9. My replacement for the ARPANET and
TCP/IP responsibilities is Bill Melohn (MELOHN@DEC-MARLBORO). Bill has
been involved in the ARPANET community previously at ECLB.
Please direct communications and problem reporting to Bill as well as
me until August 9 and Bill after August 9.
-------
24-Jul-85 14:56:50-PDT,640;000000000000
Mail-From: MRC created at 24-Jul-85 14:56:34
Date: Wed 24 Jul 85 14:56:34-PDT
From: Mark Crispin <
[email protected]>
Subject: output aborts
To:
[email protected], Bug-TELNET@LOTS-B
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
I have determined that the 6.1 monitor no longer sends an Interrupt
and Data Mark when you do a CTRL/O or CTRL/C. The 5.3 systems work
fine. This has caused some complaints at LOTS about CTRL/O not
stopping TIP output fast enough.
Could somebody hacking 6.1 at Stanford look into it?
-------
24-Jul-85 15:14:13-PDT,751;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Jul 85 15:13:27-PDT
Date: Wed 24 Jul 85 18:14:09-EDT
From: Bill Melohn <
[email protected]>
Subject: Re: MM for CFS clusters
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Wed 24 Jul 85 09:00:40-EDT
MS considers system mail to be POBOX:<SYSTEM>MAIL.TXT. This has the advanatage
of displaying system mail to all users on all cluster systems, but the
disadvantage of seeing old new system mail each time you login on another system
in the cluster. LOTS probably doesn't have this problem if they login on a
non PS: common structure.
Bill
-------
24-Jul-85 15:49:20-PDT,1086;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 24 Jul 85 15:47:15-PDT
Date: Wed 24 Jul 85 15:47:03-PDT
From: Mark Crispin <
[email protected]>
Subject: SYSTEM mail
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
Apparently DEC has independently decided that SYSTEM mail is
on POBOX:<SYSTEM>MAIL.TXT. Since MM and MS both agree on this, I
would like to ask the implementors of all other mail software to
join the bandwagon. This would include BBOARD, Babyl, Hermes, etc.
Mail files (and any index files) now live on POBOX: instead of PS:.
If POBOX: is undefined it should be defined as the login structure.
MMailr now has code to do this. POBOX: is a standard logical name
in TOPS-20 starting with version 6.0.
The main catch is that SYSTEM mail is on POBOX:<SYSTEM>MAIL.TXT
and ***NOT*** on SYSTEM:MAIL.TXT. BBoards are located on POBOX:<BBOARD>.
-- Mark --
-------
25-Jul-85 08:00:36-PDT,770;000000000000
Return-Path: <JSOL%BUCS20%
[email protected]>
Received: from csnet-relay by SU-SCORE.ARPA with TCP; Thu 25 Jul 85 08:00:21-PDT
Received: from bostonu by csnet-relay.csnet id ac23902; 25 Jul 85 10:56 EDT
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA17158; Thu, 25 Jul 85 00:00:18 edt
Date: Thu, 25 Jul 1985 00:00 EDT
Message-Id: <[BUCS20].JSOL.25-Jul-85 00:00:23>
From: Jon Solomon <JSOL%BUCS20%
[email protected]>
To:
[email protected]
Subject: DBUGSW and TCP/TELNET
Phase-Of-The-Moon: FQ+13H.25M.54S.
When we set EDDTF/1 and DBUGSW/<non-zero> or DBUGIP/1, We can't use
the net. TELNET says "TCP specification attribute not known to TCP"
(i.e. TCPXX5)
Does anyone have a fix for this?
--JSol
25-Jul-85 11:31:11-PDT,479;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Jul 85 11:30:47-PDT
Date: Thu 25 Jul 85 11:30:48-PDT
From: Andrew Sweer <
[email protected]>
Subject: 2400 baud service
To:
[email protected]
Message-ID: <
[email protected]>
Hi,
At Sumex we are checking out some 2400 baud modems. I wonder
if any of you have any 2400 baud answer service we could check for
compatibility?
Andy
-------
25-Jul-85 11:48:55-PDT,638;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Jul 85 11:47:36-PDT
Date: Thu 25 Jul 85 14:48:39-EDT
From: Kevin Paetzold <
[email protected]>
Subject: Re: DBUGSW and TCP/TELNET
To: JSOL%BUCS20%
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Jon Solomon <JSOL%BUCS20%
[email protected]>" of Thu 25 Jul 85 11:08:52-EDT
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
this is not a bug. dbugsw and dbugip cause things to happen. if you
do not understand what they do read the code.
-------
25-Jul-85 16:39:34-PDT,1132;000000000001
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 25 Jul 85 16:39:01-PDT
Date: Thu 25 Jul 85 16:39:01-PDT
From: Mark Crispin <
[email protected]>
Subject: question re: MCA25
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
SUMEX is running 5.3(1354), a TCP monitor based on AP6 (Stanford
stopped developing monitors at AP6 to go to release 6). Recently, we
installed the MCA25 upgrade and haven't noticed any improvements in
cache performance (according to the KL performance meters) or any of
the famous improvements to DUMPER performance.
Is it that these massive performance improvements only happen in
6.1 monitors? We have all the monitor patches for the keep bit (and
found that DEC had missed a wire in the MCA25 installation which broke
a keep bit monitor). Is it possible that somehow the extra cache isn't
being used, due to a hardware/software bug?
KLI does report the MCA25 as being present.
-------
30-Jul-85 13:58:29-PDT,509;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Jul 85 13:57:07-PDT
Date: Tue 30 Jul 85 13:58:07-PDT
From:
[email protected]
Subject: mca 25 speed improvements
To:
[email protected]
There has been talk at DECUS about the amount of speed improvement
that a MCA25 (2065 upgrade) will deliver over a 2060. We are looking
for any references to the improvement availiable with this upgrade.
Does anyone have any figures?
Thanks,
Alan
-------
30-Jul-85 19:28:55-PDT,737;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Jul 85 19:28:46-PDT
Date: Tue 30 Jul 85 19:29:41-PDT
From: Mark Crispin <
[email protected]>
Subject: VT100
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
I have acquired a VT100. Before everybody starts groaning, I
should state that I didn't pay for it and I'm using it while my Z-19
is in the shop. What I wanted to know is if anyone has developed an
alternative ROM that fixes the obvious deficiencies in the VT100, such
as the lack of insert/delete mode...
-- Mark --
-------
30-Jul-85 19:41:51-PDT,531;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 30 Jul 85 19:40:43-PDT
Date: Tue 30 Jul 85 20:41:56-MDT
From: Mark Crispin <
[email protected]>
Subject: DECUS Western Regional Conference 10/4/85 in SF
To:
[email protected]
Message-ID: <
[email protected]>
DECUS is holding a Western Regional Conference on 4 October at
the Holiday Inn on Union Square in San Francisco. Are any 10/20
folks going? Is anybody planning on holding any sessions?
-------
2-Aug-85 10:08:23-PDT,739;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 2 Aug 85 10:06:54-PDT
Date: Fri 2 Aug 85 11:07:52-MDT
From: Mark Crispin <
[email protected]>
Subject: 1200 baud modems
To:
[email protected]
Message-ID: <
[email protected]>
I think that a lot of the problems with 1200 baud modems, especially
the infamous "endless U disease" are due to the modem getting into a
remote diagnosis situation. At least on the DEC DF112 there is a dip
switch which disables remote diagnosis. I tried doing this and it seems
to have helped a great deal. You need to do it at both ends, since either
end can get a glitch that looks like the "go into test mode" signal.
-------
2-Aug-85 16:03:21-PDT,1389;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 2 Aug 85 16:01:29-PDT
Date: Fri 2 Aug 85 16:01:39-PDT
From: Mark Crispin <
[email protected]>
Subject: crocks, damned crocks, and bughlts
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
SUMEX this afternoon was bit by a scheduler page fault which
happened in the middle of the bughlt code. You guessed it -- it was
trying to type out the name of the user who was running at the time.
I think bughlts should ONLY type out the bughlt name and the time.
This sort of crack (which destroys what the real bughlt was) has
happened before. You can always get the additional information from
reading the dump. There really is no good reason for outputting the
user name on the CTY on a bughlt; as far as I can tell its sole purpose
is to give fascist computer centers with Rambo operators "evidence" to
persecute some poor user who probably didn't do anything to cause the
crack but just happened to be running at the time.
I'd be interested to hear if anybody has actually found it useful
to have the user name output on a bughlt (considering how *dangerous*
it is) and couldn't just have gotten it from the dump.
-------
2-Aug-85 16:18:19-PDT,815;000000000000
Return-Path: <
[email protected]>
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 2 Aug 85 16:17:46-PDT
Received: ID <
[email protected]>; Fri 2 Aug 85 19:19:58-EDT
Date: Fri 2 Aug 85 19:19:57-EDT
From:
[email protected]
Subject: Re: crocks, damned crocks, and bughlts
To:
[email protected]
In-Reply-To: Message from "Mark Crispin <
[email protected]>" of Fri 2 Aug 85 19:11:08-EDT
CMU implemented a simple fix for this long ago. Whether or not this
information is useful is for others to decide.
After the JSR BUGMSG at BUGH5+13 add:
MAP T3,USRNAM ;CMB2 Is the USRNAM in core?
TLNE T3,360000 ;CMB2
TLNE T3,200000 ;CMB2 Hard page fail code?
JRST [ MOVEI T1,[SIXBIT \*NAME NOT IN CORE*/\] ;CMB2
JSR BUGMSG ;CMB2
JRST BUGH7] ;CMB2
--Vince
-------
2-Aug-85 23:00:51-PDT,4327;000000000000
Return-Path: <
[email protected]>
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 2 Aug 85 22:57:59-PDT
Date: 3 Aug 85 01:59:01 EDT
From: Charles Hedrick <
[email protected]>
Subject: logical host mask for the NI
To:
[email protected]
The Logical Host Mask parameter was never implemented for the NI. In
general it would be useless there. But we have a special problem: The
Protocol Police are about to outlaw 0 subnet numbers. This means that we
will have to change all of our addresses from 128.6.0.x to 128.6.4.x. We
want an interim during which both addresses will work. By setting
LOGICAL-HOST-MASK:0 0 4 0, we ignore the bit that is being changed, thus
allowing us to recognize both addresses. I have also made a patch to
MNETDV that should allow this code to work after our real address is set
to 128.6.4.2. (The original code assumed that the actual address was
zero in the bits covered by the logical host mask.) I haven't tried
setting up an address of 128.6.4.x yet, but the code will almost
certainly work. I am including these patches on the off chance that
someone else might have the same problem some time.
PS: Any of you who like to communicate with RUTGERS.ARPA should make
sure that you change your host table entry for us from
10.1.0.89, 128.6.0.2
to
128.6.4.2
The change will work now, and will be essential within a couple of
weeks.
File 1) IPNIDV.MAC.9, 3-Aug-85 01:00:15
File 2) IPNIDV.MAC.7, 3-Mar-85 11:47:11
1)47 MOVE T2,NTLADR(NCT) ;[206] GET OUR INTERNET HOST NUMBER
1) LSHC T2,-^D16 ;[206] HIGH 2 BYTES IN T2
1) LSH T3,-^D20 ;[206] LOW 2 BYTES IN T3
1) STOR T2,AR$P1,(ARP) ;[206]
1) STOR T3,AR$P2,(ARP) ;[206]
1) ARPSD1: DMOVE T2,ETHADR ;GET OUR CURRENT ETHERNET ADDRESS
****
2)47 ARPSD1: DMOVE T2,ETHADR ;GET OUR CURRENT ETHERNET ADDRESS
**************
1)47 ;[206] MOVE T2,NTLADR(NCT) ;GET OUR INTERNET HOST NUMBER
1) ;[206] LSHC T2,-^D16 ;HIGH 2 BYTES IN T2
1) ;[206] LSH T3,-^D20 ;LOW 2 BYTES IN T3
1) ;[206] STOR T2,AR$P1,(ARP)
1) ;[206] STOR T3,AR$P2,(ARP)
1) NOSKED ;DON'T LET OTHERS IN HERE
****
2)47 MOVE T2,NTLADR(NCT) ;GET OUR INTERNET HOST NUMBER
2) LSHC T2,-^D16 ;HIGH 2 BYTES IN T2
2) LSH T3,-^D20 ;LOW 2 BYTES IN T3
2) STOR T2,AR$P1,(ARP)
2) STOR T3,AR$P2,(ARP)
2) NOSKED ;DON'T LET OTHERS IN HERE
**************
1)53 ARPRCV: TRVAR <AREA1,AREA2,SPADR,<SHADR,2>,RPADR> ;[206]
1) SAVEAC <ARP> ;SAVE THE CURRENT ARP POINTER
****
2)53 ARPRCV: TRVAR <AREA1,AREA2,SPADR,<SHADR,2>>
2) SAVEAC <ARP> ;SAVE THE CURRENT ARP POINTER
**************
1)54 movem t1,rpadr ;[206] save as address he thinks we are
1) xor t1,ntladr(nct) ;[206] is it us?
1) tdz t1,ntnlhm(nct) ;[206] ignoreing logical host field
1) jumpn t1,r ;[206] no, ignore it
1) ;[206] CAME T1,NTLADR(NCT) ;WAS THE PACKET FOR US ?
1) ;[206] RET ;NO, IGNORE IT
1) SKIPE AREA2 ;SHOULD THIS INFORMATION BE INSERTED ?
****
2)54 CAME T1,NTLADR(NCT) ;WAS THE PACKET FOR US ?
2) RET ;NO, IGNORE IT
2) SKIPE AREA2 ;SHOULD THIS INFORMATION BE INSERTED ?
**************
1)54 ; RPADR/ receiver protocol address ;[206]
1) ; UNB/ address of the UN block given to us by NISRV
****
2)54 ; UNB/ address of the UN block given to us by NISRV
**************
1)54 move t2,rpadr ;[206] address he thinks we are
1) LSHC T2,-^D16 ;[206] HIGH 2 BYTES IN T2
1) LSH T3,-^D20 ;[206] LOW 2 BYTES IN T3
1) STOR T2,AR$P1,(ARP) ;[206] use it as our addr
1) STOR T3,AR$P2,(ARP) ;[206]
1) MOVEI T1,AR.REP ;SET OPCODE TO REPLY
****
2)54 MOVEI T1,AR.REP ;SET OPCODE TO REPLY
**************
File 1) MNETDV.MAC.7, 3-Aug-85 00:55:09
File 2) MNETDV.MAC.6,24-Jun-85 07:44:44
1)14 ;[206] ANDCM T1,NTNLHM(P1) ; without logical host field
1) ;[206] CAME T1,NTLADR(P1) ; Is this one of ours?
1) ;[206] JRST LCLHS0 ; No, loop through all
1) xor t1,ntladr(p1) ;[206] one of ours?
1) tdz t1,ntnlhm(p1) ;[206] ignore logical host field
1) jumpn t1,lclhs0 ;[206] no, loop through all
1) AOS -1(P) ; Success! it's me, skip return
****
2)14 ANDCM T1,NTNLHM(P1) ; without logical host field
2) CAME T1,NTLADR(P1) ; Is this one of ours?
2) JRST LCLHS0 ; No, loop through all
2) AOS -1(P) ; Success! it's me, skip return
**************
-------
4-Aug-85 18:30:23-PDT,917;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Sun 4 Aug 85 18:25:47-PDT
Date: Sun 4 Aug 85 21:26:59-EDT
From: Ken Rossman <
[email protected]>
Subject: Primary DTE protocol: Fooling RSX
To:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
I would like to be able to patch RSX-20F from TOPS-20 with DDT11, shut down
the system, and do a SAV on the new RSX image. However, when I try to do
this, SAV comes back with an error message indicating primary DTE protocol
is sitll in effect. Awhile back, someone informed me that one could fake
out RSX by simply zeroing some memory location in the running 11, which
would indicate that primary protocol was no longer in effect, which in
turn, would allow SAV to properly do its job.
I have since forgotten what this location was. Anyone else know? /Ken
-------
5-Aug-85 20:52:22-PDT,535;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 5 Aug 85 20:50:34-PDT
Date: Mon 5 Aug 85 21:51:43-MDT
From: Mark Crispin <
[email protected]>
Subject: bogus CTCO answer
To:
[email protected]
Message-ID: <
[email protected]>
DEC's new answer to SPR 20-20656, published as CTCO 672.1 (update from
CTCO 670.1) is still wrong. As written, the patch will enter MSETP1,
go NOSKED, call RELMP5, go OKSKED, and exit through MSETP1+14. It will
never succeed.
-------
6-Aug-85 20:40:53-PDT,1157;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 6 Aug 85 20:39:34-PDT
Date: Tue 6 Aug 85 21:37:23-MDT
From: Mark Crispin <
[email protected]>
Subject: MM distribution
To:
[email protected]
Message-ID: <
[email protected]>
Effective immediately, the distribution of MM has moved from Score
to SIMTEL20. The directories are:
PS:<MM> sources
PS:<MM.BINARIES> EXE, REL, UNV files
PS:<MM.DOCUMENTATION> documentation files
PS:<MM.SPELL> SPELL.EXE for use with MM's SPELL command
SIMTEL20 supports the ANONYMOUS FTP convention. The former MM
directory on Score is now Score's private copy of MM, which may or may
not be up to date and which may or may not have Score-only changes.
Sites which are not on Internet can continue to get MM tapes from
me. I am hoping to have a formal distribution means with 1-day turnaround
in place in the next couple of weeks. Send me mail for more information.
Thanks to the management of Score for providing a distribution point
for MM and tolerate the rigors of being the alpha test site for so long!
-------
7-Aug-85 14:20:20-PDT,1346;000000000000
Return-Path: <
[email protected]>
Received: from DEC-MARLBORO.ARPA by SU-SCORE.ARPA with TCP; Wed 7 Aug 85 14:19:23-PDT
Date: Wed 7 Aug 85 17:17:43-EDT
From: Kevin Paetzold <
[email protected]>
Subject: goodbye
To:
[email protected]
Telephone: 617-467-7430 (DTN: 231-7430)
Mail-stop: MRO1-2/L10
As i annouced previously i am leaving DEC. my new mailing address is
(if anyone cares):
Kevin W. Paetzold
Stratus Computer Inc.
55 Fairbanks Blvd
Marlboro, MA 01752
617-460-2000
I will still be receiving arpanet mail at DEC-MARLBORO.
Stratus builds fault tolerant systems. They are a competitor of Tandem.
I have been interested in fault tolerant stuff for a long time (hard to
tell from tops20). I will be working on a new set of io hardware and i
am sure on their operating system in general.
I have been involved in TOPS20 and the ARPANET since 1978 at RADC. I
always figured that if I left DEC it would be to join some other
organization on the network. That turned out not to be the case
(although i will eventually be working a tcp/ip implementation for
Stratus). I have enjoyed being involved with the community on the
ARPANET. It is truly a special environment. If I can ever help any of
you out please don't hesitate to give me a call.
-------
7-Aug-85 14:44:14-PDT,5399;000000000001
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 7 Aug 85 14:43:05-PDT
Date: Wed 7 Aug 85 14:43:29-PDT
From: Ken Harrenstien <
[email protected]>
Subject: [
[email protected]: Re: [Ken Harrenstien <
[email protected]>: It's definite - TOP...]
To:
[email protected]
cc:
[email protected]
Here is another TOPS-20 TCP/IP bug fix, thanks to Charlie
Lynn. We have been running the fixes at SRI-NIC for a couple days and
I haven't seen any instances yet of the lossage that previously
plagued us - sometimes duplicate data would be received on a TCP
connection. This is annoying for TELNET, and highly dangerous for
FTP! I believe this bug also explains the phenomenon of duplicate
text being received on a telnet connection to 4.2BSD systems, which
some time ago was mentioned and was blamed (wrongly, it appears) on a
defective 4.2BSD server telnet implementation.
Proof of TOPS-20 lossage came from testing connections to MIT-MC
while using the ITS packet logging features.
--KLH
---------------
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SRI-NIC.ARPA with TCP; Thu 1 Aug 85 10:46:33-PDT
Date: 1 Aug 1985 13:49-EDT
Sender:
[email protected]
Subject: Re: [Ken Harrenstien <
[email protected]>: It's definite - TOP...
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA] 1-Aug-85 13:49:21.CLYNN>
In-Reply-To: The message of Sun 28 Jul 85 05:05:02-PDT from Ken Harrenstien <
[email protected]>
Ken,
Enough of the pieces fit for me to conclude that the duplication
problem you documented is an instance of an old bug (it was fixed by the
time BBN gave DEC updated files in October '84, but they haven't been
distributed).
The scenario of what is happening is that when a packet (e.g., ID
77475 in your example) is emptied and a buffer is simultaneously
filled (e.g., PUSH was set) and another packet is available (77476)
but there are no available buffers, then the "partial packet" flag
(TRPP) is being set with a "processed byte count" (TRCBY) of zero.
Then, when no buffer has yet been made available (e.g., slow
net/output to a terminal in TN) by the time a retransmission arrives
which includes "old" data before the sequence number in the partial
packet (e.g., 77500), PRCPKT replaces the original packet with the
larger retransmitted packet. Unfortunately, it fails to modify TRCBY,
so that when a buffer finally arrives, data is removed beginning at the
wrong offset. (The comment 'N.B. It works to replace a "partial
packet" with a bigger one' is a lie.) The solution is to forget about
TRCBY.
Patches to fix the problem are:
REASM3: LOAD RCVLFT,TRLFT,(TCB)
JE TRPP,(TCB),REASM4 ; Jump if not continuing a p
(jfcl) LOAD BYTNUM,TRCBY,(TCB) ; Where to resume in this pa
jrst reas11 JRST REAS13 ; Go process the remainder
-----------
; Setup BYTNUM to be the byte number within the packet where
; handling should start.
reas11: LOAD RCVLFT,TRLFT,(TCB) ; Get updated copy
MOVE BYTNUM,RCVLFT ; Next to be reassembled
LOAD T1,PSEQ,(TPKT) ; Start of packet
SUB BYTNUM,T1 ; Offset into data
JUMPLE BYTNUM,REAS12 ; No control to worry about
LOAD T1,PSYN,(TPKT) ; Get value of SYN bit
SUBI BYTNUM,0(1) ; Discount space taken by SY
REAS12:
; Setup XFRCNT to be the number of bytes to transfer out of
; packet into the user buffer.
jrst pat REAS13: LOAD XFRCNT,PIPL,(PKT) ; Get total length
LOAD T1,PIDO,(PKT) ; Number of words in Interne
pat: tlz q1,740000 (=MODSEQ BYTNUM , which should be at reas12, but here is ok)
LOAD XFRCNT,PIPL,(PKT) ; Get total length
jrst reas13+1
---------------
REAS19:
; Save the partial packet for the next time through.
SETONE TRPP,(TCB) ; Set the partial packet wai
ADD RCVLFT,XFRCNT MOVE T1,XFRCNT ; Number transferred
STOR RCVLFT,TRLFT,(TCB) ADD T1,BYTNUM ; Where the transfer started
jfcl STOR T1,TRCBY,(TCB) ; Is where to resume in the
JUMPN BYTNUM,REAS20 ; First time we have
JE PSYN,(TPKT),REAS20 ; Seen a packet with a SYN i
jfcl ADD RCVLFT,XFRCNT ; Yes. Update Left
jfcl STOR RCVLFT,TRLFT,(TCB)
MOVX T1,^D500
-----------
The sources could be cleaned up to eliminate now unused instructions, etc.
While you are making changes, check the SNDTVT routine in TTANDV.MAC as
the initial value of PKTPTR was computed incorrectly, it should look
something like
SNDTVT::
ACVAR <XFRCNT,LINBLK,PKTPTR,CNT>
PUSH P,[-1] ; Last octet
DMOVEM T1,XFRCNT ; T1,2 to XFRCNT and LINBLK
MNTM5 AOS CELL(TCVST,0,,TCV) ; SNDTVT calls
** LOAD PKTPTR,PIPL,(PKT) ; Current packet length is next byte to insert
** ADJBP PKTPTR,[POINT 8,PKTELI(PKT)] ; Byte pointer there
MOVEI CNT,0 ; Init number moved to packet
where the ** instructions were (incorrectly)
LOAD PKTPTR,PTDO,(TPKT) ; Get TCP data offset
HRLI PKTPTR,(<POINT 8,.-.(TPKT)>) ; Pointer to data area
----------------------------------------
also, after TVTDTT:
PUSH P,P2 ; BFR
PUSH P,FR
** SETZB FR,T3 ; No flags, nor JCN
XMOVEI T1,TCBLCK(TCB) ; Lock to lock
XMOVEI T2,CLOSE1 ; Function to call
CALL LCKCAL ; Do a cross-job close
POP P,FR
POP P,P2 ; BFR
where the ** was
SETZ FR, ; No flags
Charlie
-------
8-Aug-85 07:10:39-PDT,1399;000000000000
Return-Path: <
[email protected]>
Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Thu 8 Aug 85 07:08:16-PDT
Date: Thu 8 Aug 85 10:10:06-EDT
From: Donna Lynch <
[email protected]>
Subject: Fortran program
To:
[email protected]
cc:
[email protected]
We have a FORTRAN user who wants to call another program from his
FORTRAN program. Is this possible in FORTRAN? I did not see a
way to do this other than calling a MACRO subroutine to run
the inferior process. Worked fine. The next thing is he
wants this invisible to the user. This means he gets the input
for this process from a file and outputs to a file. (SPJFN?)
It seems to output to a file okay, but when I try to get the input
from a file rather than the terminal, it does not return correctly
to the calling FORTRAN program, as a matter of fact it restarts the
fortran program from the beginning. Next problem, whenever DDT is
used with or without any breakpoints or if I set address breaks at
the EXEC level, the program returns correctly.
I must admit that I all the monitor calls I used in the MACRO
program I have not used before, so I may be doing something
obviously wrong to you but not to me (CFORK,SPJFN,GET,SFRKV,RFORK,
WFORK,RFSTS,KFORK).
Any other ideas of how to approach this, suggestions of what I might
be doing wrong, or help in debugging?
--Donna
-------
8-Aug-85 19:16:45-PDT,963;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 8 Aug 85 19:13:26-PDT
Date: Thu 8 Aug 85 20:15:07-MDT
From: Mark Crispin <
[email protected]>
Subject: mailsystem performance improvement
To:
[email protected]
Message-ID: <
[email protected]>
Problem:
Incoming net mail and queued sends not delivered promptly.
Diagnosis:
The WAKEUP module caches its PID for use later. Unfortunately,
some programs (e.g. MAISER) can do a RESET% when restarted. The problem
with modules which have states with restarted is that to do things right
you need an initialization routine to reset the state.
Solution:
Take the easy way out. Introduce an error handler for "Sender's
PID invalid" which discards the cached PID and retries creating a new
one. The new version of WAKEUP.MAC is on SIMTEL20.ARPA on PS:<MM>.
SIMTEL20 supports the ANONYMOUS FTP login convention.
-------
9-Aug-85 17:20:49-PDT,1065;000000000000
Return-Path: <@MIT-MULTICS.ARPA:John_O'
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Fri 9 Aug 85 17:20:15-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 09 Aug 1985 20:21:53 edt
Date: 09 Aug 85 12:02 +0100
From: John_O'Connor_UCD%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: Fortran program
Message-ID: <117458@QZCOM>
In-Reply-To: <117412@QZCOM>
Check how how are handling the stack in the MACRO subroutine.
I seem to remeber some similar problems to this some time
ago, where I had reset the stack pointer. Otherwise everything you are doing see
m
s fine.
I have not tried the SPJFN in the context of a Fortran program, but
I have used it in other situations without difficulty, though
I am not sure how to handle EOF for the inferior process.
18-Aug-85 23:52:15-PDT,1734;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 18 Aug 85 23:52:05-PDT
Date: Mon, 19 Aug 1985 00:54 MDT
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: AP#8 to AP#10 performance question
Last month we installed the AP#10-based MONITR on our sister host in a
jump from an AP#8-based MONITR. Meanwhile, we had stepped through
AP#9 and noticed nothing much out of the ordinary in the process.
However, our sister site, which normally never saw load averages peak
above 5 or 10 at the worst, was now seeing peaks above 15 and at times
above 30, with phone calls coming in complaining about the poor
performance and response time. After tolerating about a week and a
half of this, we had them revert to the AP#8-based MONITR to see if
the user/job mix had changed. Apparently, it hadn't as the loads and
response times also reverted to their previous tolerable state.
The configuration in question is a 2040T with 768K memory and a 3 RP06
PS:. The users are almost all coming in from various TACs, mostly
running HERMES and a couple of BASICs (not DEC's), a couple
MSG/SNDMSG, several MM jobs, and no batch jobs during the day.
Whatever the mix, it is fairly repeatable from day to day with
patterns from week to week and has not changed significantly during
this period.
Now for the question to this group: has anyone else noticed such a
performance change, and if so, what did you do about it, or what did
you determine to be the cause, and is there a fix? We would like to
move them up to the current AP#10-based MONITR, but we are stymied at
this point.
--Frank
19-Aug-85 16:58:26-PDT,1736;000000000000
Mail-From: BILLW created at 19-Aug-85 16:58:11
Date: Mon 19 Aug 85 16:58:11-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: tops20 TVTs and interactive punishment through gateways.
To:
[email protected]
Message-ID: <
[email protected]>
People have complained bitterly about poor interactive performance
when telneting through gateways to tops20 milnet hosts, and about
tops20 TVT performance in general. Since Stanford may shortly
be using TCP ethertips (LOTS of TVT connections!), I have been
looking at the TVT code, and have discovered something interesting.
A basic assumption is that a system should send the minimum possible
number of packets, especially short packets. However, the DEC TOPS20
contains code to "optimize" echoing of user type-in. It reads
something like "If there are less than 8 characters to be transmitted,
it is probably echoing, so send a packet immediately. Otherwise, wait
a while to see if there is going to be even more output." No doubt
they meant well, but this seems sort of backwards, and in the case of
a path that goes through many gateways, probably anti-social. Didn't
John Nagel discover that it was a good idea to wait for a round trip
delay time for more characters (or some such)?
Anyway, a suggested patch is:
OPSCA7-2! TRN
Which replaces an XMOVEI T2,FRCPKT or a MOVX T2,FRCPKT, depending on
whether you have 5.x or 6.x. This causes OPSCAN to always wait the
200 ms for more data to appear, regardless of the amount of data
waiting. I am curious as to whether this will improve the MILNet
problems - it does not seem to adversely affect echoing on local
connections (not much, anyway).
BillW
-------
22-Aug-85 14:10:56-PDT,535;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 22 Aug 85 14:10:44-PDT
Date: Thu 22 Aug 85 14:10:31-PDT
From: Mark Lottor <
[email protected]>
Subject: spy links hanging ttys
To:
[email protected]
cc:
[email protected]
We have a problem here: Our Operators (and others) tend to make
spy links to the CTY and then walk away from their terminal.
Eventually their terminal hits the pause-at-end-of-page and
starts hanging CTY output. Does someone have a fix for this?
-------
23-Aug-85 08:38:47-PDT,862;000000000000
Return-Path: <
[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Fri 23 Aug 85 08:38:39-PDT
Date: Fri 23 Aug 85 08:40:04-PDT
From: Ted Shapin <
[email protected]>
Subject: AP#10
To:
[email protected]
Postal-address: Beckman Instruments, Inc.
Postal-address: 2500 Harbor X-11, Fullerton, CA 92634
Phone: (714)961-3393
Date: 19 Aug 1985 1557-PDT
From: SP.WOOD
Subject: Re: AP#8 to AP#10 performance question
>From: "Frank J. Wancho" <
[email protected]>
>To: TOPS-20@SCORE
>Subject: AP#8 to AP#10 performance question
>Last month we installed the AP#10-based MONITR on our sister host ...
TELL HIM THAT THERE ARE TWO RELEASES OF THE AP#10 TAPE,
ONE WAS BAD (BAD PATCHES I ASSUME) THE OTHER ONE (WHICH WAS
JUST RECEIVED LAST WEEK HERE) IS GOOD.
Will Wood, BECKMAN.
-------
27-Aug-85 13:46:03-PDT,1202;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Tue 27 Aug 85 13:45:58-PDT
Date: Tue 27 Aug 85 13:46:40-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Misc Server Fixes
To:
[email protected]
cc:
[email protected], powell%
[email protected]
In response to complaints that the TOPS-20 miscellaneous server will
occasionally hang while booting tips and gateways, I've taken a look at the
code and fixed a couple of problems.
I think the major problem was that the EFTP code could get into an untimed
loop under certain unusual circumstances. It will now timeout of such a loop.
The second problem was that the misc server itself would not create another
boot process until the first went away. This is to protect against a tip or
gateway making multiple boot requests. Now the server will kill any boot
process that has been "active" for more than 2 minutes.
The changed sources are EFTP.MAC and PUPMSV.MAC on PS:<PUP> on Sierra. A
copy of the binary may be found on SYSTEM:PUPMSV.EXE and should be runnable
on any 6.1 system. It is highly recommended that this change be installed.
Kirk
-------
1-Sep-85 16:37:10-PDT,450;000000000000
Mail-From: BILLW created at 1-Sep-85 16:37:08
Date: Sun 1 Sep 85 16:37:08-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: NREMIND bug fix.
To:
[email protected]
Message-ID: <
[email protected]>
NREMIND was missing a non-skip return handler for a gthst, causing
it to not create a correct FROM field in mail messages. The fixed
sources are on Sierra in <SU-UTILITIES>REMIND.MAC
BillW
-------
2-Sep-85 10:31:12-PDT,1121;000000000000
Return-Path: <
[email protected]>
Received: from COLUMBIA-20.ARPA by SU-SCORE.ARPA with TCP; Mon 2 Sep 85 10:31:08-PDT
Date: Mon 2 Sep 85 13:34:26-EDT
From: David Eppstein <
[email protected]>
Subject: FTPSER lossage
To:
[email protected],
[email protected]
[Journal begin, AVT: <EPPSTEIN>FTP.LOG.1, Mon 2 Sep 85 1:32:02PM]
CUCS20!continue (fork)
FTP>infORMATION (about) conNECTION
Connected to TCP host SU-SIERRA.ARPA
U: STAT
S: 211-SU-SIERRA.ARPA FTP Server Process 5Z(26)-7
S: 211-The current data transfer parameters are:
S: 211- MODE S
S: 211- STRU F
S: 211- TYPE A N
S: 211-A connection is open to host COLUMBIA-20.ARPA
S: 211 The data connection is CLOSED.
FTP>v emacs:babyl.*
U: STAT emacs:babyl.*.*
S: 212-PS:<EMACS165>
S: 212-BABYL.^V:EJ.773
S: 212-BABYL.EMACS.773
S: 212-BABYL.USE-MMAILR.1
S: 212 BABYL.VARS.1
U: STAT PS:<EMACS165>BABYL.^V:EJ.773
S: 550 ? Not found.
FTP>exit
U: QUIT
S: 221 QUIT command received. Goodbye.
CUCS20!journal close (and end journal session)
[Journal end: <EPPSTEIN>FTP.LOG.1, Mon 2 Sep 85 1:32:51PM]
-------
3-Sep-85 09:01:31-PDT,533;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Tue 3 Sep 85 09:01:12-PDT
Date: Tue 3 Sep 85 11:02:01-CDT
From: Clive Dawson <
[email protected]>
Subject: Plotting routines
To:
[email protected]
I'm looking for graphics/plotting software runnable under TOPS-20
which will take simple (x,y) pairs and plot them on a terminal
(e.g. VT240, Tektronix, etc.) Similar to PLOT and GRAPH which I'm
told exist on Unix systems. Can anybody supply any pointers?
Thanks,
CLive
-------
3-Sep-85 14:56:37-PDT,1357;000000000000
Return-Path: <
[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Tue 3 Sep 85 14:56:16-PDT
Date: Tue 3 Sep 85 14:57:44-PDT
From: Ted Shapin <
[email protected]>
Subject: Hack to define inferior dirs
To:
[email protected]
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
For a limited time, INFDEF.MAC is available for FTP from my dir on ECLA.
Ted.
INFDEF is a program that generates logical names based on the inferior
directory setup of the currently connected directory. The number of
logical names generated, varies with the number of inferior directories
which are present for the currently connected directory. To run INFDEF
at EXEC or in a .CMD file do:
RUN SYS:INFDEF
INFDEF
INFDEF will then start generating the logical names.
NOTE: INFDEF will only generate logical names for those directories
which you have access to!
EXAMPLE:
you are connected to XX:<FOO>
XX:<FOO> has the inferiors: <FOO.BASIC>,<FOO.BASIC.SOURCE>,
<FOO.PRODUCTION>.
INFDEF creates the following logical names:
* HD: XX:<FOO>
BASIC: XX:<FOO.BASIC>
BASIC-SOURCE: XX:<FOO.BASIC.SOURCE>
PRODUCTION: XX:<FOO.PRODUCTION>
* ALL: HD:,BASIC:,BASIC-SOURCE:,PRODUCTION:
*note: HD: and ALL: are always created.
-------
3-Sep-85 16:05:07-PDT,628;000000000000
Return-Path: <
[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 3 Sep 85 16:04:54-PDT
Date: 3 Sep 85 19:04:58 EDT
From: Don <
[email protected]>
Subject: My TOPS20 tutorial
To:
[email protected]
Over the past few years, several people have gotten copies of the
tutorial program I wrote to introduce new users to TOPS20 (a la
TEACH-EMACS). Those who have (and even those who have not) may be
interested in picking up a new copy. I've made a few changes
recently (including polishing a few of the rough edges).
It's [RUTGERS]RED:<WATROUS>TOPS20.MAC.
Don
-------
5-Sep-85 11:03:29-PDT,487;000000000000
Return-Path: <
[email protected]>
Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Thu 5 Sep 85 11:03:17-PDT
Date: Thu 5 Sep 85 13:04:01-CDT
From:
[email protected]
Subject: Name Server
To:
[email protected]
Has anyone got a name server working on Tops20 yet. At DECUS
it was anounced that USC-ISI expected to have one running by the
end of June. What is the current status of a name server for
tops20?
Regards, Don Kassebaum
-------
5-Sep-85 11:56:47-PDT,712;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Sep 85 11:56:38-PDT
Date: Thu, 5 Sep 1985 14:56 EDT
Message-ID: <SRA.12140881910.BABYL@MIT-XX>
From: Rob Austein <SRA@MIT-XX>
To:
[email protected]
Cc:
[email protected]
Subject: Name Server
In-reply-to: Msg of 5 Sep 1985 14:04-EDT from CC.KASSEBAUM at R20.UTEXAS.EDU
There is a working name server for twenex. Look in <DOMAIN> and
<DOMAIN.VERSION4> on ISIF. What's currently missing is the resolver
code. This was "under testing" the last time I checked (a couple
weeks ago). The version of the code with the resolver stuff will
probably be version5 of the domain system.
--Rob
5-Sep-85 14:31:57-PDT,999;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Sep 85 14:31:23-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 05 Sep 1985 17:18:27 edt
Date: 05 Sep 85 10:09 +0100
From: W._Michael_Terenyi%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: Subject: Changing Parity
Message-ID: <121399@QZCOM>
How can the parity of DZ-11 lines within the PDP-11 front-end
be changed ?
I am no TOPS-20 expert, but from my knowledge of RSX I can remember
that
it could be done withe OPE command, directly by setting some harware registers o
f
the
DZ-11. Is this also possible in the front-end or is there a more elegant
way to acheive this ?
Michael
8-Sep-85 15:03:26-PDT,486;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Sun 8 Sep 85 15:03:18-PDT
Received: ID <
[email protected]>; Sun 8 Sep 85 18:05:52-EDT
Date: Sun 8 Sep 85 18:05:52-EDT
From:
[email protected]
Subject: PAGLCK bughlts
To:
[email protected]
Has anyone out there had any success at debugging PAGLCK bughlts? If so, I
would be interested in hearing from you - I would like to hear what methods
have been used.
--Vince
-------
8-Sep-85 22:09:50-PDT,1389;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 8 Sep 85 22:09:44-PDT
Date: Sun 8 Sep 85 22:10:11-PDT
From: Stu Grossman <
[email protected]>
Subject: Re: PAGLCK bughlts
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "
[email protected]" of Sun 8 Sep 85 15:16:04-PDT
PAGLCKs are quite often caused by the (erroneous) creation of private pages in
the special PSB map slots (such as CPTPGA and friends). These pages are used
for things like mapping another forks PSB, or jobs JSB, and must always be
indirect or shared pages when they exist. What usually happens is that
something touches one of these pages and makes it exist without going through
SETPSB or SETJSB (or whatever). When a private page exists in these map slots,
the SPT share counts for the executing fork get messed up (this only happens
when the private page gets unmapped via a call to SETPSB/JSB). The really
insidious thing about this is that the PAGLCK (or ILULKx) may not occur until
fork or job destruction time.
This scenario is pretty easy to see when analyzing a dump.
You should determine from the crash if this occurred during fork or job
destruction. Additionally, what SPT slot was being decremented? Was it for
the PSB of the currently dying fork?
Stu Grossman
-------
9-Sep-85 10:20:07-PDT,1215;000000000000
Return-Path: <@DREA-XX.ARPA:
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Sep 85 10:19:53-PDT
Received: from DREA-GRIFFIN.ARPA by DREA-XX.ARPA with TCP; Mon 9 Sep 85 14:20:33-ADT
Date: Mon, 9 Sep 85 14:17 ADT
From: Peter Gergely <
[email protected]>
Subject: Possible TCP/FTP problem
To: tops-20%
[email protected]
cc:
[email protected]
Message-ID: <
[email protected]>
Reply-To: Peter%
[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]
Before I get into the problem, let me mention a little
background to it. We have six Symbolics Lisp Machines (2 x 3600,
4 x 3640) connected via Ethernet to DREA-XX using TCP/IP protocols.
When a close connection is requested from the side of the lisp machine,
the lisp machine connection closes but the DEC-20 one never does. I talked
to Symbolics about this but they claim it is a 20 problem. Any clues to
what might be happening. This is a LOW priority problem, but a major
annoyance as TCP connections are being used at a dramatic rate.
- Peter
-------
9-Sep-85 15:04:38-PDT,613;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Sep 85 15:04:27-PDT
Date: Mon 9 Sep 85 17:06:03-CDT
From: Clive Dawson <
[email protected]>
Subject: Host tables
To:
[email protected]
Attempts to load the last few versions of NIC's host tables manually
via the IPHOST LOAD command produce complaints such as "Duplicate
host name CORNELL-ARPA" and other similar messages which seem to have
no connection with reality. Has anybody else seen this and found a
reason for it? Other than these random messages, everything is
behaving nicely.
Clive
-------
9-Sep-85 15:41:18-PDT,500;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Mon 9 Sep 85 15:41:09-PDT
Date: Mon 9 Sep 85 16:39:06-MDT
From: Randy Frank <
[email protected]>
Subject: Re: Host tables
To:
[email protected],
[email protected]
In-Reply-To: Message from "Clive Dawson <
[email protected]>" of Mon 9 Sep 85 16:24:18-MDT
Message-ID: <
[email protected]>
I've seen the cornell one also, but haven;t had the energy to track down
the cause...
-------
9-Sep-85 15:54:35-PDT,500;000000000000
Mail-From: BILLW created at 9-Sep-85 15:54:26
Date: Mon 9 Sep 85 15:54:26-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: host tables...
To:
[email protected]
Message-ID: <
[email protected]>
Stanford, running the 6.1 Field test monitor, is getting more
reasonable "Host space full before end of file" messages. I think
it's time to increase NHSTN to NHOSTS*5 (it is now NHOSTS*4). Sigh.
Ill let the world know if this works...
BillW
-------
10-Sep-85 09:22:37-PDT,491;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Sep 85 09:22:29-PDT
Date: Tue 10 Sep 85 10:24:15-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: host tables...
To:
[email protected]
cc:
[email protected]
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
I increased NHSTN to NHOSTS*6. With all those domain names 6 is a
more reasonably multiplier these days.
-------
10-Sep-85 12:58:22-PDT,1018;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from ucl-cs by SU-SCORE.ARPA with TCP; Tue 10 Sep 85 12:57:51-PDT
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a012900; 10 Sep 85 11:00 BST
Via: DCT; by DUNDEE on Tuesday, 10-Sep-85 11:00:53-BST
Date: Tue 10 Sep 85 10:57:40-GDT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: Asynch net drivers for tops20
To:
[email protected]
cc: alan%
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Does anyone know of either an x25 server for tops20 (KL10 based) using
asynchronous front end tty lines for communication or even an ANF-10
(yuck) server doing the same thing. I've seen ANF-10 on VAX/VMS and
Unix but never on a 20. I suppose someone might have done it ?
Alan Greig
Computer Centre
Dundee College of Technology
Dundee
Scotland
Janet: Alan%DCT@DUNDEE
Arpa: Alan%
[email protected]
-------
10-Sep-85 13:39:15-PDT,1080;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Tue 10 Sep 85 13:39:06-PDT
Date: Tue 10 Sep 85 14:36:44-MDT
From: The alleged mind of Walt <
[email protected]>
Subject: Re: Asynch net drivers for tops20
To: CCD-ARG%
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Alan Greig <CCD-ARG%
[email protected]>" of Tue 10 Sep 85 14:31:23-MDT
Message-ID: <
[email protected]>
You cannot by definition have X.25 over an async line HOWEVER you can
do something like what Telenet did in the early days, use the same sort
of character framing that bisync did. Ie the frame starts
DLE STX and ends DLE ETX and if there happens to be a byte in the middle
that has the value DLE then it is byte stuffed to DLE DLE. My X.25
implementation for the DEC-20 was originally written to do this, then
when real HDLC became available on Telenet I replaced that with real
HDLC. It would not be unreasonably difficult to hack it back into my
code if you were sufficiently masochistic.
Cheers -- Walt
-------
13-Sep-85 09:31:36-PDT,851;000000000000
Return-Path: <
[email protected]>
Received: from BBNF.BBN.COM by SU-SCORE.ARPA with TCP; Fri 13 Sep 85 09:31:28-PDT
Date: 13 Sep 1985 12:31-EDT
Sender:
[email protected]
Subject: EXEC Bug
From:
[email protected]
To:
[email protected]
Message-ID: <[BBNF.BBN.COM]13-Sep-85 12:31:58.RBASCH>
Symptoms:
A user has 2 (or more) versions of a file, e.g. FOO.BAR.1
and FOO.BAR.2, and FOO.BAR.1 has been requested to be
archived (but is still visible). The user does DELETE FOO.BAR,
KEEP 1, and the EXEC falsely claims that FOO.BAR.1 has been
deleted.
Cause:
In determining which versions of a file will be deleted by
DELNF%, the EXEC reads the wrong word from the FDB to check
the "archive requested" bit.
Cure:
In EXEC1, at KEEPD1 + 11 lines, change:
MOVE B,[1,,.FBBK0]
to:
MOVE B,[1,,.FBBBT]
Bob
13-Sep-85 16:15:12-PDT,5237;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Sep 85 16:14:56-PDT
Date: Fri 13 Sep 85 18:17:18-CDT
From: Clive Dawson <
[email protected]>
Subject: A Tough Nut to Crack
To:
[email protected],
[email protected]
Hi Folks--
I'm in the process of trying to solve one of the most bizarre
problems I've ever come across. Since I've now reached the
straw-grasping stage, I thought I'd share it with the DEC-20/CHAOSNET
community and see if anybody has seen something like this before
or has any suggestions.
Scenario:
A DEC-2065 which is connected via Ethernet to several
dozen Lisp machine workstations, VMS- and UNIX-based
VAXen, etc. We are running both TCP/IP over an NI
and also have a DN-20 running MIT's CHAOSnet software.
(i.e. there are two separate connections to the
Ethernet cable.)
Problem:
The problem occurs when we FTP files over Chaosnet
from the DEC-20 to any of the other hosts in the network.
The file will arrive with a random number of pairs of
bytes swapped. My standard "diagnostic" is to send
and retrieve a large file (~ 266 KBytes) and then compare
the original with the file that made the round trip.
In about half the tests, the file returns intact. Here
are sample FILCOM's from two of the other tests:
TEST 1:
**** FILE PS:<AI.CLIVE>TOPS20.MAN.1, 35-17 (74016)
normally used with a special input spooler that allows you to create
**** FILE PS:<AI.CLIVE>TOPS20.MUN.1, 35-17 (74016)
normally used with a special input spoloret ah tlalows you to create
***************
TEST 2:
**** FILE PS:<AI.CLIVE>TOPS20.MAN.1, 130-6 (263989)
13.6.3 Using the BUILD Command 93
13.6.4 REPLACE and TREPLACE 94
14. Logical Devices 96
15. How to recover if 98
15.1 A Terminal Won't Respond When You Try to Log In 98
**** FILE PS:<AI.CLIVE>TOPS20.MAN2.1, 130-6 (263989)
13.6.3 Using the BUILD Command 9
3 1 .3.6 4ERLPCA Ena dRTPEALEC 49
41 .oLigac leDivec s 69
51 .oH wotr cevorei f 89
511.A T reiman loW'n teRpsno dhWneY uoT yrt ooL gnI 89
***************
Cute, huh?! Here are some possibly relevant observations:
a) the number of swapped pairs varies widely. If seen
as few as six (e.g. Test 1) to a couple of hundred
pairs.
b) the position within the file where this happens
appears to be completely random
c) I have never seen more than a single contiguous
sequence of swapped bytes in the file.
d) Examination of the file on the remote host shows
that the problem is already there. I have not
been able to reproduce the problem for data going
the other way (i.e. IN to the DEC-20).
e) The Symbolics Lisp Machines were suspects for a
brief time when I heard about a related hardware
bug on the I/O Rev6 boards used on 3640's and 3670's.
However I have since reproduced the problem on 3600's
as well as Unix and VMS based VAXen.
Diagnosis (so far):
Here is a list of the different things we've tried. None
have succeeded in fixing the problem.
First, we tried replacing the Interlan Ethernet controller board
in the DN-20.
Both the NI (TCP/IP) connection as well as the DN-20 (Chaosnet)
connection are using DELNI units as Ethernet transceivers. We
tried swapping the two DELNI's. (This was very far-fetched!)
The best theory (suggested by several people including Symbolics
Chaos hackers) was that the problem was in the DTE hardware,
which connects the DEC-20 to its front-end PDP-11 (the DN-20).
This was especially plausible because the DTE apparently
transmits pairs of bytes in one of two different orders depending
on whether the address is odd or even. Also the swapping didn't
seem to correspond to any buffer or packet sizes/boundaries.
When DEC initially ran DTE and PDP-11 memory diagnostics, several
of them failed. They all worked when one of the DTE boards was
replaced, and we thought the problem was solved. Unfortunately
the test file transfers still failed, and we ended up replacing
all three boards of the DTE. This didn't work either.
Next we replaced all the PDP-11 memory (the 128K board), but
the problem remained.
At this point about all that remains to be replaced is the
PDP-11 processor itself, though it is very hard to believe
that a processor problem would show up only as pairs of
swapped bytes on file transfers. (Nobody has reported any Chaos
TELNET or MAIL problems, the PDP-11 boots with no difficulty, etc.)
We will probably try this anyway on Monday, as well as
try bypassing the ruggedized UNIBUS cable between the DTE and
the PDP-11. After that....I'm stumped!!
Solution:
In the immortal word of T. Blinn: Please!
Many thanks in advance,
Clive
-------
14-Sep-85 21:26:01-PDT,381;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Sep 85 21:25:54-PDT
Date: Sat 14 Sep 85 22:28:03-MDT
From: Mark Crispin <
[email protected]>
Subject: correction to previous message
To:
[email protected]
Message-ID: <
[email protected]>
In a vanilla DEC monitor, the location is MOVEI T1,INTBP0+4.
-------
14-Sep-85 21:27:12-PDT,372;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Sep 85 21:27:04-PDT
Date: Sat 14 Sep 85 22:29:22-MDT
From: Mark Crispin <
[email protected]>
Subject: correction to previous message
To:
[email protected]
Message-ID: <
[email protected]>
In a vanilla DEC monitor, the location is INTBP0+4.
-------
14-Sep-85 21:40:45-PDT,1150;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Sep 85 21:40:37-PDT
Date: Sat 14 Sep 85 22:26:35-MDT
From: Mark Crispin <
[email protected]>
Subject: AP10 TCP performance problem
To:
[email protected]
Message-ID: <
[email protected]>
Problem:
768K 2040 system which does a lot of TCP mail traffic and has a
large user community has terrible performance with the Autopatch 10
version of TOPS-20 5.4. With the Autopatch 8 version performance is
merely poor.
Diagnosis:
Between Autopatch 8 and Autopatch 10, DEC adopted the change several
large systems have of running the TCP fork in queue 0. This is alright
for large 2060's, but is a disaster for small systems. It's even worse
when you're in the business of doing database query and retrieval via mail
and have hundreds or thousands of messages coming in...
Solution:
If you have this problem, patch INTBP0+6 from MOVEI T1,400001 to
MOVEI T1,400000. This will make the TCP fork run as a "system" fork but
not in queue 0 where it can stop all other processes from running.
-------
15-Sep-85 10:20:11-PDT,696;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 15 Sep 85 10:20:04-PDT
Date: Sun 15 Sep 85 10:23:17-PDT
From: Mark Crispin <
[email protected]>
Subject: Unibus video board?
To:
[email protected],
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
Does anybody know of the existance of a Unibus board that
will deliver RGB output suitable for use in an RGB monitor?
I'd like to hook a DEC 2020 (which has a Unibus) up to a Sony
Profeel Triniton monitor. I'm interested in vendors and prices.
-------
16-Sep-85 18:04:33-PDT,744;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Mon 16 Sep 85 18:04:25-PDT
Date: Mon 16 Sep 85 21:16:04-EDT
From: Rob Austein <
[email protected]>
Subject: Whoops
To:
[email protected]
Office: [NE43-503] 545 Technology Square, Cambridge MA 02139; (617) 253-7341
For some reason that I have not yet figure out, my entire mail file
got sent to TOPS20@SCORE (would you believe random line noise being
interpreted by BABYL as a series of valid commands to do this? I
don't). I certainly didn't do it intentionally! My apologies to
everybody, particularly those people who discovered that their mail
files had become unreadable by having 100+ pages of garbage added to
them.
--Rob
-------
17-Sep-85 13:33:13-PDT,434;000000000000
Return-Path: <
[email protected]>
Received: from BRL-TGR.ARPA by SU-SCORE.ARPA with TCP; Tue 17 Sep 85 13:33:01-PDT
Date: Tue, 17 Sep 85 16:12:34 EDT
From: Ron Natalie <
[email protected]>
To: Mark Crispin <
[email protected]>
cc:
[email protected],
[email protected]
Subject: Re: Unibus video board?
WARNING: The Profeel RGB video inputs are not analog. There is a
schmidt trigger on them.
-Ron
20-Sep-85 09:23:34-PDT,764;000000000000
Return-Path: <BUDD%BUCS20%
[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Sep 85 09:23:19-PDT
Received: from bostonu by csnet-relay.csnet id a006136; 20 Sep 85 12:13 EDT
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA10980; Fri, 20 Sep 85 11:41:06 edt
Date: Fri 20 Sep 85 11:38:28-EDT
From: Phil Budne <BUDD%BUCS20%
[email protected]>
Subject: TCPSTAT
To: TOPS-20%
[email protected]
Message-Id: <12144778076.22.BUDD@BUCS20>
Can anyone help us with the whereabouts of the TCPSTAT program?
We are a 5.4 site (not on the Internet), and we currently have
no NETSTAT equivalent program.
Thanks!
Phil Budne
Boston University / Distributed Systems
-------
20-Sep-85 13:24:04-PDT,538;000000000000
Mail-From: KNIGHT created at 20-Sep-85 13:23:49
Date: Fri 20 Sep 85 13:23:49-PDT
From: Bob Knight <
[email protected]>
Subject: NI% bug
To:
[email protected]
Message-ID: <
[email protected]>
If you're trying to use the NI% JSYS to collect stats, and find it hanging,
this fix is for you. In RCCTST, in NIUSR.MAC, change the RETs and RETSKPs
to JRST (T4) and JRST 1(T4), respectively.
Bob
PS: If you try to ^C out of the hung state, you'll crash with a GLFNF BUGHLT,
or something similar.
-------
20-Sep-85 15:15:48-PDT,708;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Sep 85 15:15:41-PDT
Date: Fri 20 Sep 85 15:13:46-PDT
From: Mark Crispin <
[email protected]>
Subject: 6.1 PITRAP bughlts in IMP code
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
I talked BillW through a crash dump analysis of one of Score's
PITRAPs. The problem is that the page that IMPEIN is sitting on isn't
locked! Apparently the code declares it to be XRESCD but it sure as
hell ain't or at least it ain't when it cracks.
--- Mark --
-------
20-Sep-85 20:08:46-PDT,1134;000000000000
Mail-From: BILLW created at 20-Sep-85 20:08:44
Date: 20 Sep 1985 20:08-PDT
Sender:
[email protected]
Subject: Re: 6.1 PITRAP bughlts in IMP code
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Message-ID: <[SU-SCORE.ARPA]20-Sep-85 20:08:44.BILLW>
In-Reply-To: <
[email protected]>
Well, a little looking at the monitor showed that the IMPDV code that
is carefully declared to be XRESCD wasn't really inside the boundries
of what the monitor though was actually resident. More staring at
the source showed other strangness, such as compiling IMPDV yielded
a load module with only 24 words inside of XRESCD. I was about ready
to complain about obscure bugs in macro, when I noticed that there
were a number of XNENT FOO,BAR type entry points. That extra "N"
looked suspicious, and indeed, XNENT carefully puts you in XSWAPCD,
regardless whether it is immediately proceded by an XRESCD macro
or not. Sigh. I changed a couple of them to XRENT's, and the
monitor is compiling now - Im pretty sure this was the problem.
BillW
20-Sep-85 20:16:35-PDT,1759;000000000000
Mail-From: BILLW created at 20-Sep-85 20:16:28
Date: 20 Sep 1985 20:16-PDT
Sender:
[email protected]
Subject: PITRAP bughlts from IMP code in v6.1
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Message-ID: <[SU-SCORE.ARPA]20-Sep-85 20:16:28.BILLW>
Score and Sierra have been experiencing occasional PITRAP bughalts from
the IMP driver in tops20 6.1 FT5, getting worse with apparently unrelated
monitor edits, and with FT6. The problems turned out to be due to a
misuse of XNENT macros in IMPDV, where XRENT macros should have been
used. The updated source code should be available from SU-SIERRA:
<6-1-MONITOR> sometime in the near future. Many thanks to Mark Crispin,
who instantly recognized that the trap was occuring on the instruction
fetch rather than on the data reference, saving many hours of useless
dump analysis. (How emabarassing not to have noticed this myself).
BillW
Begin forwarded message
Well, a little looking at the monitor showed that the IMPDV code that
is carefully declared to be XRESCD wasn't really inside the boundries
of what the monitor though was actually resident. More staring at
the source showed other strangness, such as compiling IMPDV yielded
a load module with only 24 words inside of XRESCD. I was about ready
to complain about obscure bugs in macro, when I noticed that there
were a number of XNENT FOO,BAR type entry points. That extra "N"
looked suspicious, and indeed, XNENT carefully puts you in XSWAPCD,
regardless whether it is immediately proceded by an XRESCD macro
or not. Sigh. I changed a couple of them to XRENT's, and the
monitor is compiling now - Im pretty sure this was the problem.
BillW
End forwarded message
22-Sep-85 00:36:57-PDT,521;000000000000
Mail-From: BILLW created at 22-Sep-85 00:36:55
Date: Sun 22 Sep 85 00:36:55-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: new EMACS
To:
[email protected]
Message-ID: <
[email protected]>
Ive fixed some bugs in the Concept-100 code, and added the AJ510
terminal. Pick up a new TECO.MID, TECTRM.MID, and TRMTYP.* from
Score. Note that EMACS essentially has to be reassembled on each
system it is installed on, as it uses absolute version numbers.
BillW
-------
26-Sep-85 14:43:06-PDT,2077;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 26 Sep 85 14:42:54-PDT
Date: Thu 26 Sep 85 12:58:53-PDT
From: Mark Crispin <
[email protected]>
Subject: Disneyland DECUS
To:
[email protected]
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: 1 (415) 968-1052
Message-ID: <
[email protected]>
According to the preliminary program, Disneyland DECUS looks like
this for 36-bitters:
. Monday - nothing
. Tuesday - Product Panel, Migration to VAX
. Wednesday - Layered Products, Lisp, TOPS-10 technical
. Thursday - TOPS-20 technical
. Friday - TOPS-20 networks -- TCP/IP scheduled at 1PM!!!
Perhaps what annoys me the most is that there are two sessions
"TOPS-20 V6.1 FOR USERS" and "TOPS-20 V6.1 USER PANEL" which sound
alike (presumably the latter is where you hear from the field test
sites). I wish that one of these could have been moved to Friday so
that TOPS-20 TCP/IP could be on the same day as all the other TOPS-20
technical sessions.
Otherwise, Thursday (Wednesday for you 10 folks) is just about
the only day worth going. I doubt there'll be much new in the migration
sessions or in the product panel; most of us have made our migration
decisions by now and anyway we can buy audio tapes of those sessions.
What disturbs me the most is the cost this time around. One day
at DECUS is now $235! It goes up in $40/day chunks from there. Only
5-day attendees get tickets for the reception. Incidentally, unlike all
past DECUSes the reception is a night at Disneyland. The only bar and
d'oerves reception is the Sunday night SIG reception before the symposium.
Disneyland is fun and it's good that DECUS is renting the park for a night,
but it does not replace a regular reception. It is simply impractical to
discuss business matters in Space Mountain or the Haunted House.
Hotels range from $48 to $108/night, depending on whether you get a
single or double room and where.
-------
26-Sep-85 14:46:07-PDT,1543;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 26 Sep 85 14:45:59-PDT
Date: Thu 26 Sep 85 14:48:52-PDT
From: Ken Harrenstien <
[email protected]>
Subject: Double-buffering for disk?
To:
[email protected]
cc:
[email protected]
Is there any reasonable way for a user program to coerce TOPS-20 into
doing double buffering when reading from the disk?
The ITS system does automatic read-ahead when a program is reading a disk
file sequentially; while the program is grovelling over one block, the
system is reading in the next block (page) in the reasonable expectation
that it will be needed pretty soon. I have always been given to understand
that TENEX/TOPS-20 never did anything of the sort, and that for this reason
the only way to improve efficiency was to do direct page-map I/O which
at least bypasses the buffer handling.
However, this is still only a marginal improvement which falls a long
way short of that possible with true parallelism. It appears that with
PMAP, the pages are not loaded until they are actually referenced (page
fault), and the program is forced to sit idle while the trap is handled.
What is needed is a way to force loading while the program is busy doing
other things.
I've looked at the PM%PLD bit, but this doesn't appear to work the way
it should. Instead of returning immediately, the PMAP call appears to hang
until all of the pages are actually loaded! This, of course, is hardly
an improvement.
Any suggestions?
-------
26-Sep-85 18:14:38-PDT,1332;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Thu 26 Sep 85 18:14:27-PDT
Date: Thu 26 Sep 85 22:17:13-ADT
From: Peter Gergely <
[email protected]>
Subject: Modified ^R MMAIL YANK in the MMAIL.EMACS Library
To: BUG-EMACS%
[email protected],
[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]>
I know that this may not be the right forum, but I have modified
the ^R MMAIL YANK command in the MMAIL.EMACS Library to do the
following:
!^R MMAIL Yank:! !^R Insert the current message (one being replied to)
Indents arg spaces (default 4). Leaves point and mark around inserted text.
If the variable MMAIL PRUNE HEADERS is nonzero, a cleanup of the
headers is performed leaving only the Date, From, and Subject fields.!
The message can be yanked in the middle of text and the original
text will not be modified or indented at all. With all the headers in
mail messages, I found this feature to be very useful. Maybe the
default should be to prune headers.
If anyone is interested in this modification, it is available via
ANONYMOUS FTP from <ANONYMOUS>MMAIL.* at DREA-XX.
- Peter
-------
27-Sep-85 18:56:52-PDT,1823;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 27 Sep 85 18:56:41-PDT
Date: Fri 27 Sep 85 23:00:58-ADT
From: Peter Gergely <
[email protected]>
Subject: New EMACS Library: MM-MAIL to fix mail files
To:
[email protected], bug-emacs%
[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]>
Available at DREA-XX on PS:<ANONYMOUS>MM-MAIL.* is an EMACS library for
fixing random mail files into a format suitable to be read by MM. It is
available via ANONYMOUS FTP to all who would like it. I have been using
it regularly over the last six months. Included here is a listing of
the commands contained in the library. Please notify me if you change
something in it.
- Peter
========================================================================
Library File Name: MM-MAIL
Macros for fixing various mail files to MM format
Commands in file MM-MAIL:
Fix Babyl Mail File
C Fix Babyl mail files to look like MMs.
A numeric argument prevents the buffer being saved for Undo.
Fix MAIL file
C Patches up a text copy of mail to look like MM mail file.
A numeric argument does not save for Undo. A pre-comma
argument says to use the current date and time
Fix Message
C Patches up the message defined by the region
Fix Usenet Messages
C Fixes readnews messages.
A Numeric argument says to use the date it was sent
Subroutines in file MM-MAIL:
& Flush Usenet Lines
S Flush unwanted lines
& Setup MM-MAIL Library
S Initialization code for MM-MAIL.
========================================================================
-------
29-Sep-85 05:41:02-PDT,823;000000000000
Return-Path: <
[email protected]>
Received: from DREA-XX.ARPA by SU-SCORE.ARPA with TCP; Sun 29 Sep 85 05:40:53-PDT
Date: Sun 29 Sep 85 09:44:54-ADT
From: Peter Gergely <
[email protected]>
Subject: EMACS Library from DREA-XX: MM-MAIL
To: bug-emacs%
[email protected],
[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]>
I have made one small change to the library so please get the
latest one from here again. I would appreciate if you could drop me a
note saying who has FTP'ed both MM-MAIL, and MMAIL libraries so I can
create a mailing list for updates and changes rather than bothering the
whole list. Thanks.
- Peter
-------
29-Sep-85 10:25:12-PDT,2324;000000000000
Mail-From: KRONJ created at 29-Sep-85 10:25:09
Date: Sun 29 Sep 85 10:25:09-PDT
From: David Eppstein <
[email protected]>
Subject: Strange FORK 0/NAME interaction breaks EXEC
To:
[email protected]
Message-ID: <
[email protected]>
If I do FORK 0 and then try to NAME the resulting handle, I get an
internal illegal instruction. This wouldn't be so bad, but after this
the EXEC can't run non-ephemerons. The journal below shows it with no
other forks complicating the INFO FORK listings, but the result is the
same in that case too.
I had to log out when I screwed my top level EXEC in this way. I
could have fixed things up from the minibuffer but that's almost as
drastic. I used to have a PCL command that would fix things up with a
^Ereplace (after hacking COMAND.CMD to fix up fork names and such) but
I no longer keep it automatically defined so I couldn't use it either.
[PHOTO: Recording initiated Sun 29-Sep-85 10:12AM]
Score!info fork
Score!fork 0
Score!info fork
=> Fork 0: EXEC, 0:00:00.5
Score!name EXEC
?Internal illegal instruction at 1 - Undefined operation code
Score!info fork
=> 2 (0): EXEC, 0:00:00.6
Score!v sys:mmailbox.exe,sys:hstinf.exe
PS:<SU-SUBSYS>
MMAILBOX.EXE.52;P777752;E 11 5632(36) 10-Jul-85 16:25:04 MRC
.53;P777752 11 5632(36) 6-Sep-85 19:09:49 BILLW
HSTINF.EXE.1;P777752;E 4 2048(36) 2-Dec-82 21:07:10 MRC
Total of 26 pages in 3 files
Score!hstinf score
Score, SU-SCORE = CSD-Net+303#, MJH-10MB-Net+56#; Location: "MJH 020",
Owner: "CSD", Function: "Server", Networks: "PUP+IP", Op-Sys: "TOPS20",
CPU: "DEC-2060"
Score!info fork
=> 2 (0): EXEC, 0:00:01.1
Score!mmailbox
?Exec free space exhausted
Score!info fork
Score!hstinf score
Score, SU-SCORE = CSD-Net+303#, MJH-10MB-Net+56#; Location: "MJH 020",
Owner: "CSD", Function: "Server", Networks: "PUP+IP", Op-Sys: "TOPS20",
CPU: "DEC-2060"
Score!mmailbox
?Exec free space exhausted
Score!reset
Score!hstinf score
Score, SU-SCORE = CSD-Net+303#, MJH-10MB-Net+56#; Location: "MJH 020",
Owner: "CSD", Function: "Server", Networks: "PUP+IP", Op-Sys: "TOPS20",
CPU: "DEC-2060"
Score!mmailbox
?Exec free space exhausted
Score!pop
[PHOTO: Recording terminated Sun 29-Sep-85 10:14AM]
-------
30-Sep-85 07:38:17-PDT,1259;000000000000
Return-Path: <
[email protected]>
Received: from CU-ARPA.CS.CORNELL.EDU by SU-SCORE.ARPA with TCP; Mon 30 Sep 85 07:37:59-PDT
Received: from gvax.cs.cornell.edu by CU-ARPA.CS.CORNELL.EDU (5.5/4.30)
id AA20961; Mon, 30 Sep 85 10:41:36 EDT
Date: Mon, 30 Sep 85 10:41:24 edt
From:
[email protected] (George R. Boyce)
Message-Id: <
[email protected]>
Received: by gvax.cs.cornell.edu (4.30/4.30)
id AA06653; Mon, 30 Sep 85 10:41:24 edt
To:
[email protected]
Subject: accounting survey and rfc
Excuse this if the subject has already been discussed but I am knew to
the list...
I'm wondering how many sites turn accounting off and if so, why. Someone once
told me that the cpu drain was significant; my only concern is about the
programming support required since I have to interface with an accounting
system on a remote (IBM) system. I run tops-20 on a 2065 supporting student
course work. Does anyone have any comments on accounting? Thanks.
(The reason why this is an issue at such a late date in the life of our
tops system is that 'they' are changing the accounting system on the remote
system I interface with and are requesting that I change my programs to
meet the new specs... Sigh.)
30-Sep-85 13:10:23-PDT,1563;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Sep 85 13:10:16-PDT
Date: Mon, 30 Sep 1985 13:08 PDT
Message-ID: <IAN.12147448759.BABYL@SRI-NIC>
From: Ian Macky <Ian@SRI-NIC>
To: tops-20@su-score
Subject: Do these long-file woes ring a bell?
We have been having trouble with long files; it seems that when a
file is converted on the fly over to long format while other processes
concurrently have the file mapped in, problems sometimes result.
The first and worst problem is that sometimes after all processes have
released all JFNs on the file, a new open-for-write OPENF% will fail
with Invalid Simultaneous Access. It seems that an OFN (or SPT entry,
or whatever) is being left around for the long file even tho noone has
it open. We haven't been able to reproduce this at will, altho it
happens with some regularity on our machine, when database files are
extended past 512 pages while other users are reading it.
The second is something we came across while trying to pin down the
first: GTJFN% for read on a file that is in the process of becoming
long (e.g. another process has it open for write, and has pushed it
above 512 pages) will sometimes fail with GFJX24 (File not found), and
OPENF% with OPNX2 (File does not exist), apparently because the entry
(FDB?) for the "new" file (the long version of the original one) is
being found before the old (short) one, and the new one has FB%NXF
(file does not exist) set. Note that the new, long file has not yet
been closed.
30-Sep-85 13:51:39-PDT,1528;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Sep 85 13:51:18-PDT
Date: Mon 30 Sep 85 14:41:39-MDT
From: Mark Crispin <
[email protected]>
Subject: Re: Do these long-file woes ring a bell?
To:
[email protected]
cc:
[email protected]
In-Reply-To: <IAN.12147448759.BABYL@SRI-NIC>
Message-ID: <
[email protected]>
Long file bugs have been with us for a long long time. DEC's canned
answer to requests for short files has been "we have so many long
file bugs we'd rather make all files be long files and be done with
it."
If you want to try to debug it, I suggest trying to put in a bugtrap
where you think it is blowing it, check the OFN share count (by the
way, all OFN's are SPT slots, but not all SPT slots are OFN's) and
see if you can't find any pointers. I wonder if perhaps DDMP might
be hanging on to the OFN.
Another thing to consider is to run some other version of the monitor
than release 6. Release 6 was never generally released, it has several
known bugs that were fixed in 5.1 and 6.1. I think the NIC would be
better off either running 5.4 at 5.1 Autopatch 10 level or a recent
version of 6.1.
A simple workaround to the problem is to make all your database files
long, perhaps by having some funky data in page 512^2-1 or by starting
your databases on page 512. The few disk pages you waste in extra
index blocks are a minor consideration compared to the headaches of
trying to debug the problem.
-------
30-Sep-85 15:38:00-PDT,1151;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Sep 85 15:37:48-PDT
Date: Mon 30 Sep 85 18:40:38-EDT
From: Ken Rossman <
[email protected]>
Subject: DECSA DECnet router box
To:
[email protected]
cc:
[email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <
[email protected]>
Does anyone out there run a DECSA DECnet router, or have any experience
working with one? How about a DECnet/SNA gateway router? We are about to
try to bring up the DECnet router here, but we're not sure if we have the
right equipment. What we have is something called a DECSA-FA, which is the
hardware for the SNA gateway. What we *should* have is a DECSA-EA, which
is the DECnet router hardware. Near as I can tell from the descriptions of
each of these boxes, they're very close to being the same hardware. I'm
wondering if they only differ in software. Since we haven't ordered the
software yet, we may still be able to use this box for DECnet service.
Anyone know anything about either of these boxes? /Ken
-------
2-Oct-85 20:06:51-PDT,1009;000000000000
Mail-From: BILLW created at 2-Oct-85 20:06:49
Date: Wed 2 Oct 85 20:06:49-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: TCPSPL bug fixed...
To:
[email protected]
cc:
[email protected],
[email protected]
Message-ID: <
[email protected]>
Well, after all the flack I received from Kirk about my QUASAR patch
to distinguish between TCPSPL and LPTSPL printers not handling more
than single digit unit numbers, it turns out that TCPSPL never worked
with more than single digit unit numbers anyway!
I fixed verion of TCPSPL is on sierra in <5-1-galaxy>, and EXEs have
been installed on Score and Sushi (which just got unit 10, obviously).
By the way, there seems to be some confusion as to whether unit numbers
are octal or decimal. Most places in galaxy and the exec seem to expect
decimal numbers, but SHOW DEFAULT assumes octal unit numbers. Sigh -
who in their right mind would ever have more than 8 printers anyway!
BillW
-------
2-Oct-85 22:09:17-PDT,711;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 2 Oct 85 22:09:13-PDT
Date: Wed 2 Oct 85 22:16:32-PDT
From: Kirk Lougheed <
[email protected]>
Subject: Re: TCPSPL bug fixed...
To:
[email protected]
cc:
[email protected],
[email protected],
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Wed 2 Oct 85 21:01:35-PDT
My understanding is that for compatibility with VMS, the Galaxy developers
used decimal unit numbers in the Release 6.1 software. I believe the only
remaining instance of octal unit numbers in TOPS-20 is terminal line
numbers.
flack, flack
Kirk
-------
3-Oct-85 02:33:02-PDT,738;000000000000
Return-Path: <reid@glacier>
Received: from glacier by SU-SCORE.ARPA with TCP; Thu 3 Oct 85 02:32:59-PDT
Received: by glacier with Sendmail; Thu, 3 Oct 85 02:35:10 pdt
Date: 3 Oct 1985 0235-PDT (Thursday)
From: Brian Reid <reid@glacier>
To: William "Chops" Westfield <
[email protected]>
Cc:
[email protected],
[email protected],
[email protected]
Subject: Re: TCPSPL bug fixed...
In-Reply-To: William "Chops" Westfield <
[email protected]> /
Wed 2 Oct 85 20:06:49-PDT.
<
[email protected]>
More than 10 printers? We have 10 printers in one building (CIS), plus
network access to maybe 10 more around campus. And just this morning I
signed a purchase order for another one.
4-Oct-85 01:28:04-PDT,562;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 4 Oct 85 01:27:58-PDT
Date: Fri 4 Oct 85 01:31:33-PDT
From: David Roode <
[email protected]>
Subject: MEIS vs. NI
To:
[email protected]
Message-ID: <
[email protected]>
I am trying to decide which is best, and would appreciate
votes from the network. If the results are interesting,
I will tally and report it to the list. Of concern are maintenance,
ease of installation, reliability and quality of software support.
-------
8-Oct-85 18:33:34-PDT,2083;000000000000
Mail-From: BILLW created at 8-Oct-85 18:33:26
Date: Tue 8 Oct 85 18:33:26-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: MEIS vs NI ethernet interfaces.
To:
[email protected]
Message-ID: <
[email protected]>
Since no one has answered yet, here is a quick comparison:
MEIS: Designed by Stanford University. A Massbus device. Software
from Stanford will support TCP/IP and PUP (versions 5.3, 6.0, 6.1 of
tops20). The MEIS consists of an 8 slot unibus sized backplane
designed to be mounted in the front end, and power by a FE power
supply. There are 4 cards (for a single 10Mb interface), plus massbus
tranceivers. An additional Ethernet interface can be added via 2 more
cards (10Mb) or one more card (3Mb).
Advantages
- More than on interface on any given 20.
- Does not use ANY channels - a MEIS can be daisy chained behind a
disk or tape drive (altough if the ethernet is heavilly used, it
is a good idea for the MEIS to have its own channel).
- Both 3 an 10 Mb networks supported.
- Installation is trivial.
- Slightly faster than an NI (as if it mattered).
Disadvantages
- No DEC field service support. Maintenance is via "Board swap".
- No DECNet or LAT software.
NI: Designed by DEC. Supported by DEC distributions (5.4, 6.1) of
tops20. Uses 3 standard hex modules occupying RH20 position 5, plus a
seperate card cage mounted in one of the KL cabinets containing an
additional card (extended hex module), and an additional power supply.
Advantages
- Supported by DEC field service. (This is an advantage ? :-)
- Supports DECNet and LAT.
Disadvantages
- Only one interface per 20.
- Installation also requires preparation of installation of CI20,
causing a loss of a total of 4 RH20 slots (channels). This
isn't so bad if you are planning on a CI anyway.
Oh. I'm not sure about prices, and in any case that might be inappropriate.
I beleive that the MEIS is somewhat more expensive than the NI.
BillW
-------
9-Oct-85 21:00:34-PDT,1888;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Wed 9 Oct 85 21:00:24-PDT
Date: Wed 9 Oct 85 22:02:59-MDT
From: Mark Crispin <
[email protected]>
Subject: Sherlock Hacker in: The File That Would Not Go Away
To:
[email protected]
Message-ID: <
[email protected]>
Problem:
Strange problem in Autopatch 10. Unable to expunge
directories. Unable to kill directories. Upset users. Upset
system programmer being blamed for introducing a filesystem bug.
Funky error message:
"% FDB formatted incorrectly; file not deleted".
This translates to error code DELFX7, which only occurs in two
places: in DIRECT.MAC in the DELFDB routine. Very confusing since
they occur at calls to FDBCHK/R. The FDB's in question pass
FDBCHK with flying colors.
Diagnosis:
DELFDB (which was calling FDBCHK) wasn't being called with
the FDB; it was being called with 0 in A. The AC's don't make a
very good FDB. It turns out that D (which holds the FDB in the
DELF% code in DISC) was being smashed by the call to ARCMSG which
was called iff the file has archive status. Unless the file was
being expunged nothing would happen.
Once upon a time ARCMSG (in IPCF.MAC) saved all AC's, since
it used AC's with reckless abandon. Recently, a DEC programmer
with initials DSG (last name GUNN) decided it would be cute if he
made ARCMSG return an error code in A. To this end he changed
the ACSAV at ARCMSG+1 to SAVEPQ, forgetting that B, C, and D are
also temporary AC's that callers may have expected to be
preserved.
Solution:
In DISC.MAC, at DELF31-1, insert:
MOVE D,(P) ;RESTORE FDB
in front of
MOVE B,.FBCTL(D) ;RECOVER CTL BITS
It would also help if DEC's programmers were taught to check
ALL callers of a routine before changing its calling sequence!!
-------
10-Oct-85 04:25:16-PDT,2347;000000000001
Return-Path: <BUDD%BUCS20%
[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Oct 85 04:25:05-PDT
Received: from bostonu by csnet-relay.csnet id ad08315; 10 Oct 85 6:07 EDT
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA02101; Wed, 9 Oct 85 22:57:36 edt
Date: Wed 9 Oct 85 22:55:55-EDT
From: Philip Budne <BUDD%BUCS20%
[email protected]>
Subject: TCP local socket numbers
To: TOPS-20%
[email protected]
Message-Id: <12149882137.13.BUDD@BUCS20>
In the BSD 4.2 implementation of TCP/IP it would seem that local
TCP sockets are system wide, while in the TOPS-20 implementation, local
socket numbers are only guaranteed to be unique within a job.
This behavior is troublesome for implementing the BSD RSH (rcmd())
protocol which specifies that the server establish a reciprocal link
back to the remove host for transmission of stderr. This can lead to
multiple copies of the same remote (from Un*x's point of view) ports
with the same number, which 4.2 looks at and replies "address in use".
The following code comes from routine CHKADD in TCPTCP.MAC;
JCN is non-zero when called from a JSYS (ie; on an OPEN(F)%).
The widgeted (>) lines of code are responsible for the observed behavior.
In my implementation of the UDP: device I removed this 'feature'.
CHKAD4:
............
LOAD T1,TOWNR,(TCB) ; Get Job number which owns this tcb
> SKIPE JCN ; Any job ok if called from net side
> CAMN T1,JOBNO ; Must stay in this job
> CAIA ; OK to think about this TCB
> JRST CHKAD4 ; Skip it and try next
LOAD T1,TLP,(TCB) ; Get the Local Port from this TCB
CAME T1,LP ; Does it match what we are looking for?
JRST CHKAD4 ; No. Try next TCB
QUESTIONs:
How much of the world is likely to break by removing the marked lines?
(FTP for example?)
Is my diagnosis about the error from Un*x correct?
P.S.
As I mentioned I have implemented a UDP: device for TOPS-20. If there
is sufficient interest I can place the code in a public are (we're on
PhoneNet). The code is not bug free, but I have not worked on it in a
while either.
Any program that uses special queues to RECEIVE UDP packets must be
modified to use UDP:, while special queues may still be used to send
UDP packets.
-------
10-Oct-85 15:23:02-PDT,1942;000000000001
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Thu 10 Oct 85 15:22:49-PDT
Date: Thu 10 Oct 85 14:46:38-PDT
From: Mark Crispin <
[email protected]>
Subject: Re: TCP local socket numbers
To: BUDD%BUCS20%
[email protected]
cc:
[email protected]
In-Reply-To: <12149882137.13.BUDD@BUCS20>
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041-1869
Phone: +1 (415) 968-1052
Message-ID: <
[email protected]>
A TCP connection is uniquely identified by the host/port pairs
on both sides of the connection. In other words, multiple connections
can exist to the same port on a host as long as each of the host/port
pairs at the other end are unique.
The TOPS-20 TCP: device assigns a port number as follows. First
it checks to see if the user is attempting to specify a port number.
If so, if the port number is .LE. 0.127 (a server port) or .GE.
128.0 (in the system-assigned port range), the program must have
indicated its intention to use one of these special ports by placing
a # after the number. Ports between 1.0 and 127.127 can be freely
assigned by any process.
If no local port was specified, the system assigns the port number
by adding 128.0 to the job number left-shifted 6 bits (allowing for a
full 9-bit job number) plus the low-order 6 bits of a "job unique
number" which is AOS'd every time it is used.
A bug in the code (due to its somewhat funky logic) causes two
increments of the job unique number and so there's really only 32
system-assignable ports/job before it wraps around. This is usually
enough.
Processes using UDP or the BBN interface are responsible for
assigning a unique port number of their own; it's generally recommended
to use a convention similar to the TCP: device's only using the "freely
assignable" range between 1.0 and 127.127.
-------
11-Oct-85 17:46:51-PDT,701;000000000000
Return-Path: <
[email protected]>
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Fri 11 Oct 85 17:46:34-PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 11 OCT 85 17:49:10 PDT
Date: 11 Oct 85 17:49:05 PDT (Friday)
From:
[email protected]
Subject: HP to KL
To:
[email protected]
cc: ,
[email protected]
Message-ID: <851011-174910-3142@Xerox>
We have some tapes we need to dump down to our 2065s (running 6.2) that
are from a HP machine and the only other information we have about them
is that they are written in "HP ASCII".
Can anyone give us a clue on how to convert these tapes into some kind
of a readable format?
Thanks in advance
Gary
11-Oct-85 22:14:56-PDT,954;000000000000
Return-Path: <
[email protected]>
Received: from SU-SUSHI.ARPA by SU-SCORE.ARPA with TCP; Fri 11 Oct 85 22:14:44-PDT
Date: Fri 11 Oct 85 22:14:19-PDT
From: Joel P. Bion <
[email protected]>
Subject: Re: HP to KL
To:
[email protected],
[email protected]
In-Reply-To: Message from "
[email protected]" of Fri 11 Oct 85 17:49:05-PDT
If your tapes were written on an HP2000, and are the "Freeze" or "Hibernation"
tapes, I have a set of programs that MAY be of help. A few years ago, Stan-
ford's GSB got rid of its HP2000, and wanted to have the ability to read
files as needed off these hibernation tapes. Few files were seen to be needed,
so after poking around the tapes for a while, I wrote a set of programs which,
while very slow, get the job done. You may feel free to get these programs;
they will tell you the format of the 2000 tapes, at least, although they
are indeed very, very slow.
Joel
-------
12-Oct-85 02:00:32-PDT,442;000000000000
Mail-From: BILLW created at 12-Oct-85 02:00:25
Date: Sat 12 Oct 85 02:00:25-PDT
From: William "Chops" Westfield <
[email protected]>
Subject: New version of FTP.
To:
[email protected]
Message-ID: <
[email protected]>
Ive added MKDIR and RMDIR commands to the Stanford FTP. As far
as I know, these commands areonly implemented by UNIX TCP Servers.
The new sources are on Sierra in <FTP>
BillW
-------
14-Oct-85 11:01:20-PDT,3472;000000000000
Return-Path: <RAMSEY%
[email protected]>
Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Oct 85 11:01:08-PDT
Received: from (SYSTEM)WESLYN.BITNET by WISCVM.ARPA on 10/14/85 at
13:02:13 CDT
Date: Fri 11 Oct 85 13:13:03-EDT
From: Betsy Ramsey <
[email protected]>
Reply-To: RAMSEY%
[email protected]
Subject: Fall DECUS
To:
[email protected]
Address: American Math. Society, PO Box 6248, Providence RI 02940
Net-Address: Ramsey%
[email protected]
DECUS-Title: Systems Software Coordinator, Large Systems SIG
I wanted to comment on some points Mark Crispin made a
couple of weeks ago in his "Disneyland DECUS" mail.
Large Systems sessions were not scheduled on Monday at the
request of a number of our members who a) want to attend
other SIG's road map sessions and b) want to attend the VAX
sessions dealing with high-end issues. The VAX SIG worked
with us in accommodating these requests by scheduling their
high-end VAX and cluster sessions on Monday.
Because of the crowded facilities at the Disneyland hotel,
sessions are running from 9am to 11pm three nights (Monday,
Wednesday and Thursday) instead of two in Anaheim. Many
SIGs have sessions on Friday. The VAX SIG's "VMS Advanced
Q&A" is among the Friday sessions.
On Thursday morning, DEC will present three sessions back-
to-back that will cover the area of TOPS-20 systems
software. Rather than present the V6.1 changes in a
comprehensive "TOPS-20 V5.1 to V6.1 Technical Comparison"
session as they did in New Orleans, DEC has elected to break
up the material into three different sessions.
"TOPS-20 V6.1 for System Managers" will discuss how V6.1
changes will impact system management and operations.
"TOPS-20 V6.1 for Users" will discuss the impact on general
users, and will focus primarily on EXEC changes. "TOPS-20
V6.1 for Systems Programmers" will focus on internal changes
to the monitor in V6.1.
"TOPS-20 V6.1 User Panel" is the session in which repre-
sentatives from V6.1 Field Test sites discuss their
experiences with the new release.
DEC has decided not to participate in the "TOPS-20 TCP/IP"
session on Friday. Some of that material will be covered in
"TOPS-20 V6.1 for Systems Programmers" on Thursday, however.
The single day price of the symposium covers the actual
costs of supporting a single person at the symposium for one
day. The price in previous years didn't reflect the real
costs.
Mark's point about the Tuesday night reception in Disneyland
is well-taken. I don't expect to be able to conduct a great
deal of business there myself.
The Large Systems SIG coordinators try to do the best job we
can at getting sessions submitted, scheduled and chaired.
Often the task is difficult because we have no input from
members of the SIG. DECUS is, after all, the Digital
Equipment Computer USERS Society. If you are doing some
interesting work on a DEC-20, submit a Call for
Participation. If you think your work is fun and
interesting, chances are other users will, too. Talk to DEC
and to the SIG Steering Committee about topics you would
like DEC to cover at the symposia. We need your ideas.
-------
14-Oct-85 11:38:29-PDT,764;000000000000
Return-Path: <
[email protected]>
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Oct 85 11:38:05-PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 14 OCT 85 11:40:50 PDT
Date: 14 Oct 85 11:40:46 PDT (Monday)
From:
[email protected]
Subject: Re: HP to KL
In-reply-to: JPBion's message of Fri, 11 Oct 85 22:14:19 PDT
To: Joel P. Bion <
[email protected]>
cc:
[email protected],
[email protected]
Message-ID: <851014-114050-4431@Xerox>
Joel:
We may very well need these programs in order to figure out the problem.
I am writing for my wife who is located at Hughes Radar in ElSegundo
CA. and who does not have ARPA net access. What do you think would be
the best to get these files to her?
Gary
14-Oct-85 12:25:31-PDT,1294;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 14 Oct 85 12:25:21-PDT
Date: 14 Oct 1985 1530-EDT
From: Reed B. Powell <
[email protected]>
To: TOPS20@SU-SCORE
Large-Systems-Marketing: LCG Product Line
Location: "297-4261 MRO2-2/3C (Pole 5A)"
REPLY: "MARKET:: or MRVAX::"
Subject: ANAHEIM DECUS SESSIONS
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12151111732.21.146.14177 at MARLBORO.DEC.COM>
As the DEC person responsible for coordinating DECUS sessions, I'd like to
thank Betsy for her recent ARPA mail explaining some of the details of
the scheduling and the TOPS20 monitor sessions.
A note, however, on the TCP/IP session scheduled for Friday: Although Digital
is not sponsoring this session, we will in fact participate at the session if
it is scheduled as a user session. We feel strongly that this session fits
squarely under the heading of USER sessions, and that it should be treated as
such. Digital routinely participates in most user sessions, both to collect
useful information, as well as to bring up relevant points and pieces of
information that would otherwise be buried in another session.
So, if you attend the TCP session, you will certainly see DEC there.
thanks,
-reed
--------
15-Oct-85 11:18:32-PDT,1162;000000000000
Return-Path: <root%
[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Oct 85 11:18:20-PDT
Received: from bostonu by csnet-relay.csnet id ak14174; 15 Oct 85 14:04 EDT
Received: by bu-cs.ARPA (4.12/4.7)
id AA21607; Mon, 14 Oct 85 16:39:35 edt
Date: Mon, 14 Oct 85 16:39:35 edt
From: BostonU SysMgr <root%
[email protected]>
To:
[email protected]
Subject: 2060 for sale
Boston University is interested in selling their 2060, briefly:
2060-PH, S/N 3047
KL10E, 1536KW MF20, 2 RP06, 2 RP07, TU78, DN20 + 2 DMR11-AC,
32 Async lines (DH11-AD), KLNI (ethernet), LP20 (600LPM/96),
TOPS-20.
This machine has always been under full service by DEC/LCG since its
installation as new equipment in June 1983. The original list (w/o the
KLNI) was $840,364.00. All reasonable offers considered, contact:
Barry Shein ARPA: bzs%bu-cs@csnet-relay
Academic Computing Center CSNET: bzs@bu-cs
Boston University BITNET: ccbs@bostonu
111 Cummington Street UUCP: ..!harvard!bu-cs!bzs
Boston, MA 02215
(617) 353-2780
Inquiries for further details welcome, e-mail preferred.
15-Oct-85 13:51:21-PDT,1224;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Oct 85 13:51:08-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 15 Oct 1985 16:43:29 edt
Date: 15 Oct 85 09:08 +0100
From: W._Michael_Terenyi%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: HP to KL
Message-ID: <127804@QZCOM>
In-Reply-To: <851011-174910-3142@Xerox>
If the tapes had been written on a HP1000 it is likely that
they are unblocked, that is one record per block with variable
record length. I could read such tapes with a small Fortran program
on a VAX very easily, but I cannot remember what the parameter settings in
the OPEN statement were. As far as I know I used most of the default
values.
If the tapes are written by some HP tape utility (there are about
6 different) it is hopeless. In this case I recommend to go to a
HP installation somewhere to get it converted.
Regards, Michael
15-Oct-85 13:51:51-PDT,906;000000000000
Return-Path: <@MIT-MULTICS.ARPA:Niall_O'
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Tue 15 Oct 85 13:51:33-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 15 Oct 1985 16:44:08 edt
Date: 15 Oct 85 16:22 +0100
From: Niall_O'Reilly_UCD%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: HP to KL
Message-ID: <127851@QZCOM>
In-Reply-To: <127804@QZCOM>
There is a utility program which runs on 10's and 20's called
CHANGE, which knows about a fairly wide range of tape formats
and how to read them. I think it should be available through
DECUS. I know that HPASCII is an option in one of the menus.
16-Oct-85 06:05:44-PDT,1074;000000000000
Return-Path: <
[email protected]>
Received: from seismo.CSS.GOV by SU-SCORE.ARPA with TCP; Wed 16 Oct 85 06:05:33-PDT
Return-Path: <enea!kuling!victor>
Received: from enea.UUCP by seismo.CSS.GOV with UUCP; Wed, 16 Oct 85 08:57:40 EDT
Received: by enea.UUCP; Wed, 16 Oct 85 11:04:37 -0100 (MET)
Received: by enea.UUCP; Wed, 16 Oct 85 11:04:29 -0100 (MET)
Received: by kuling.UUCP; Wed, 16 Oct 85 09:49:06 -0200
Message-Id: <
[email protected]>
To:
[email protected]
Cc:
[email protected]
Subject: RSCS on TOPS-20?
Date: 16 Oct 85 09:49:02 N (Wed)
From: Bjorn Victor <
[email protected]>
Has anybody heard of a TOPS-20 implementation of RSCS?
Our department, having two 2060's, has been given an
oppurtunity to join the EARN (European Academic Research
Network), with connections to BITNET in the US.
Any information whatsoever is interesting!
--Bjorn Victor UUCP: {mcvax,seismo}!enea!kuling!victor
Computing Science Dept/UPMAIL
Uppsala University, PO Box 2059, S-750 02 UPPSALA, SWEDEN
16-Oct-85 14:14:54-PDT,1492;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 16 Oct 85 14:14:29-PDT
Return-Path: <@MIT-MULTICS.ARPA:Niall_O'
[email protected]>
Received: from MIT-MULTICS.ARPA by SUMEX-AIM.ARPA with TCP; Wed 16 Oct 85 13:25:26-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 16 Oct 1985 15:52:19 edt
Date: 15 Oct 85 16:32 +0100
From: Niall_O'Reilly_UCD%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected]
Resent-Cc: "Mark Crispin" <
[email protected]>, "Mark Crispin"
<
[email protected]>
Subject: Subject: RSX-20F Autobaud Problem - WARNING
Message-ID: <127857@QZCOM>
ReSent-Date: Wed 16 Oct 85 13:57:07-PDT
ReSent-From: Mark Crispin <
[email protected]>
ReSent-To:
[email protected]
ReSent-Message-ID: <
[email protected]>
To anyone thinking of applying the patch to RSX-20F supplied in
"Answer to SPR #:10-34838", PCO # 10-RSX20F-019, beware. I just
have, and this has provoked an 11-HALT/T04 on the next attempt
to log in on a REMOTE AUTOBAUD terminal. RSX then re-boots,
and TOPS-20 is continued.
We have a KL model B processor configured as a DECSYSTEM-20/65,
and use version 15-13 of RSX.
We are now running vanilla 15-13 as found on the floppies again
17-Oct-85 12:38:43-PDT,1306;000000000000
Return-Path: <@MIT-MULTICS.ARPA:Niall_O'
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Thu 17 Oct 85 12:38:29-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 17 Oct 1985 15:13:12 edt
Date: 17 Oct 85 16:11 +0100
From: Niall_O'Reilly_UCD%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: RSCS on TOPS-20?
Message-ID: <128350@QZCOM>
In-Reply-To: <
[email protected]>
There is a TOPS-20 2780 Emulation/Termination software subsystem
which uses a DN20 with KDP/DUP as a synchronous communications
controller. This subsystem allows the TOPS-20 system to appear
as a lineprinter/cardreader remote terminal to RSCS.
This configuration would allow files to be sent to EARN without
great difficulty, but some work would have to be done to handle
transfers in the other direction properly. Moreover, the TOPS-20
system could function only as an END node.
I don't know of any other solution, but if you find one, I should
like to hear of it. Mats Brunell of QZ might also be interested.
18-Oct-85 15:14:44-PDT,1178;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 18 Oct 85 15:14:25-PDT
Received: ID <
[email protected]>; Fri 18 Oct 85 18:14:13-EDT
Date: Fri 18 Oct 85 18:14:12-EDT
From:
[email protected]
Subject: TCP non-feature
To:
[email protected]
I have been seeing the following undesirable behavior in the TOPS-20 TCP
implementation. Here's the scenario:
- User TELNET's to a remote system, and escapes back to the local system.
- User receives some amount of output on the remote system. It need not be
a large amount of output as one would expect to excede TCP buffers.
- When the user continues the TELNET short time later (5 minutes?) the
connection is discovered to be closed.
My question is: is this a bug or a fact of life in the TCP world? If a bug,
does anyone have a fix for it? It does not appear to occur with certain other
OS's, so I must assume that it is an attribute ot the TOPS-20 implementation.
If necessary, I can obtain a more information (i.e. description of the TCP
states, etc.) from someone here who knows more of the details of this problem.
--Vince
-------
21-Oct-85 08:55:35-PDT,5672;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Mon 21 Oct 85 08:55:19-PDT
Date: 21 Oct 1985 10:54-EDT
Sender:
[email protected]
Subject: Re: TCP non-feature
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA]21-Oct-85 10:54:46.CLYNN>
In-Reply-To: The message of Fri 18 Oct 85 18:14:12-EDT from
[email protected]
Vince,
Re your message:
I have been seeing the following undesirable behavior in the
TOPS-20 TCP implementation. Here's the scenario:
- User TELNET's to a remote system, and escapes back to the
local system.
- User receives some amount of output on the remote system.
It need not be a large amount of output as one would expect to
excede TCP buffers.
- When the user continues the TELNET short time later (5
minutes?) the connection is discovered to be closed.
First, what I think is happening:
User TELNET is using the JFN interface to TCP. It hides the BBN interface
by setting up and using two internal buffers. The local TCP is told of the
size of buffers, and then informs the remote TCP of the amount of data that
it is willing to accept using an appropriate window.
The remote TCP receives the window information and sends the data when the
application generates it.
Before the data has been sent, however, you escape from TELNET, causing it
to stop reading from the remote connection.
The remote application generates some data and sends it, using the advertized
window size. But since it is a TELNET connection, it sets the PUSH flag to
make your local TCP deliver the data to user TELNET on a packet by packet basis
(not when the JFN interface's buffers become full).
When the packets arrive, the TCP places the data into TELNET's buffers,
filling them both (probably with one character in each).
The remote end does not know anything about the JFN interface's buffers
and sends more data, as the window is not yet full.
TELNET isn't reading any data, and the JFN interface has no outstanding
buffers to hold the data, so it waits in the received packets. The policy
used by the TOPS-20 for acknowledging data is that it is acked when placed
into a user's buffer (one of several possible policies which conforms to
the TCP specification).
Since the TOPS-20 isn't acking the data, the remote host retransmits it.
Eventually the timeout is reached, and the remote host "notifies the user",
i.e., server telnet, whose policy is to abort the connection.
When your TELNET starts reading data, it gets the two buffers and finds
that the connection has been closed.
Now for your questions:
My question is: is this a bug or a fact of life in the TCP world?
In one sense, probably both. The part of the layered protocol model of
interest is shown below.
User <-- some "process --> Remote host process
| control" protocol |
User TELNET <-- Telnet Protocol --> Server Telnet
| |
TCP <-- TCP Protocol --> TCP
| |
... ...
The fact of life in the TCP world is that TCP is not intended to know
what the higher level layers are doing. The "problem" could be "fixed"
at the TCP level if all implementations used a particular set of policy
decisions, including: choice of timeouts, action taken on timeout policy,
acking policy, window management policy, window closing policy, and
retransmission into closed window policy. Unfortunately, the policies
which "fix" the problem are not necessairly those that would be best in
other cases. E.g., the "never abort a connection on transmission timeout
policy" (by server telnet) leads to "no free connections", "no available
TVT's", "no free job slots", and "hung TCP connections that never go away"
(in the TOPS-20 context).
If a bug, does anyone have a fix for it?
I think that the problem should be fixed at a higher protocol level.
At the TELNET level, user telnet should inform the other end to stop
sending data. It could be part of the escape mechanism. There are
some good reasons for not doing it here, however. The telnet protocol
does not define a "stop sending" function (it might be possible to use
Go-Ahead, but it would probably not work as the Go-Ahead would be given
before user telnet knew that you wanted to escape).
Most OSs have a notion of XON and XOFF. The user telnet escape
mechanism could send the (remote OS and logged-in user dependent) XOFF
character to the remote system and wait until the transmission channel
is empty before escaping (the dependencies make automating this more
challenging). Poping back to TELNET should invoke the XON sequence
for the remote system.
Finally, the user (you) are in the best position to know the proper
incantation to XOFF the remote system. Use it before escaping from
TELNET (making sure that it isn't consumed by your local system). Send
the XON sequence after you pop back.
It does not appear to occur with certain other OS's, so I must
assume that it is an attribute ot the TOPS-20 implementation.
Each OS and application is free to select its own policies and defaults,
so it is an attribute of the combination of systems.
If necessary, I can obtain a more information (i.e. description of the
TCP states, etc.) from someone here who knows more of the details
of this problem.
If my theory of the problem is wrong and none of the suggestions above work,
it will be time for more details.
Charlie
21-Oct-85 14:55:02-PDT,2189;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 21 Oct 85 14:54:49-PDT
Date: Mon 21 Oct 85 16:53:26-CDT
From: Clive Dawson <
[email protected]>
Subject: Field service question
To:
[email protected]
I'd like to ask for some advice from any sites who have recently
had DEC field service de-install/install equipment. In fact, I'd
love it if any DEC folks would stick their necks out on this one
(confidentiality guaranteed!)
We are making plans to move an RP07 from one of our VAX systems to
our DEC-20. We plan to have DEC field service de-install the drive.
We will then roll it out the door of one machine room, into an elevator,
up one floor, and into another machine room. DEC will then re-install it.
The drive has been continuously covered by DEC maintenance, etc...
We've gotten into a debate with FS over how much this should cost.
There are two basic options: a fixed-fee cost (~$864) or an hourly time
(~$115/hr) plus supplies cost . Our original idea was to de-install it as
cheaply as possible (i.e.pay the hourly rate) and then install it for a
fixed-fee cost to cover the risks of the drive getting sick on its elevator
trip. Our local FS manager informed me, however, that DEC requires the
SAME payment method on BOTH de-installation and installation. This
means that if we opt for fixed-fee, we would have to pay a total of $1728!
This seems like a total crock to me. Consider the fact that just
a couple of months ago, we moved our entire DEC-20 from one building to
another for a fixed-fee which was calculated at three times the monthly
maintenance cost of the system. For an RP07, this would amount to a total
cost of 3 x $180 = $540.
My questions are: 1) Can anybody supply any recent counter-examples to
DEC's policy as stated above? 2) Does anybody know of a reason why the
"3 x monthly maintenance" charge couldn't be applied here? True, the
drive is being moved to a different system and maintenance contract,
but in fact both systems in question are owned by the same company.
Does that rule only apply to moving entire systems?
Many thanks,
Clive
-------
21-Oct-85 19:42:50-PDT,1511;000000000000
Return-Path: <
[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Mon 21 Oct 85 19:42:37-PDT
Date: 21 Oct 85 22:41:53 EDT
From: Charles Hedrick <
[email protected]>
Subject: tcp misfeature
To:
[email protected]
Message-ID: <
[email protected]>
We have the reciprocal problem. Most of our system staff use
terminal servers that run TCP/IP Telnet. These servers allow you
to maintain more than one session. You can escape back to the
server command level and then move to a different session.
It is fairly typical that when you return to your TOPS-20 job, you
find that the session has gone away. This does not happen with
jobs on Unix. Evidence suggests that the problem happens when
TOPS-20 has output for the terminal, but the terminal server is
not listening. It appears that TOPS-20 gives up at some point.
There is some leeway here because there is buffering within the
terminal server, but eventually the buffer does fill. I'm not sure
why Unix does not have this problem. Possibly our usage of TOPS-20
and Unix is enough different that Unix never fills the buffer when
we are talking to somebody else. At any rate, I consider this
an annoying misfeature. However I agree that it is hard to see
how to fix it. My theory is that when you escape from a telnet
connection, the telnet user process should reduce the window
size to 0. However sending XOFF might be better, as someone else
suggested.
-------
22-Oct-85 13:36:03-PDT,731;000000000000
Return-Path: <
[email protected]>
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Tue 22 Oct 85 13:35:35-PDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 22 OCT 85 13:34:07 PDT
Date: 22 Oct 85 13:34:04 PDT (Tuesday)
From:
[email protected]
Subject: How to do it
To:
[email protected]
cc: ,
[email protected]
Message-ID: <851022-133407-1364@Xerox>
I am passing this on for folks from Hughes Acrft who are not on the net.
We need a method of passing variables, specifying file names and key
parameters to the TOPS20 Sort/Merge software package.
I do not know the exact application my friends have in mind but would
appreciate any help from TOPS20 experts on the net.
Gary
22-Oct-85 14:20:38-PDT,863;000000000000
Return-Path: <@MIT-MULTICS.ARPA:
[email protected]>
Received: from MIT-MULTICS.ARPA by SU-SCORE.ARPA with TCP; Tue 22 Oct 85 14:20:19-PDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <
[email protected]>; 22 Oct 1985 17:10:07 edt
Date: 22 Oct 85 18:04 +0100
From: Jacob_Palme_QZ%
[email protected]
Reply-to: TOPS-20_experts_mailing_list%
[email protected]
To: TOPS-20_experts_mailing_list%
[email protected],
[email protected]
Subject: Subject: XMODEM for TOPS-10
Message-ID: <129330@QZCOM>
Does anyone know of a good and reliable program for the XMODEM
protocol for message interchange between a PC and a mainframe,
running preferably under TOPS-10, or possibly under TOPS-20 if
it could be converted to TOPS-10.
22-Oct-85 17:30:05-PDT,946;000000000000
Return-Path: <
[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 22 Oct 85 17:29:53-PDT
Date: 22 Oct 85 20:29:20 EDT
From: Charles Hedrick <
[email protected]>
Subject: calling sort/merge
To:
[email protected]
Message-ID: <
[email protected]>
Pascal has an interface to sort/merge. Every year or so it breaks,
because of changes in SORT. It has just broken again. The moral
of the story seems to be that there is no version-independent
interface to SORT. Fortran does have an interface, which they
seem to keep up to date. So you might try using a Fortran
subroutine. Pascal has one, which will work again within a day or
two. The file is rutgers::s:<pascal>passrt.mac. The current creation
date is 9-May-82. When it becomes xx-Oct-85, it can be presumed to
work again. You should be able to massage the Pascal interface
to do what you want.
-------
22-Oct-85 21:49:43-PDT,2562;000000000000
Return-Path: <
[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 22 Oct 85 21:49:29-PDT
Date: 23 Oct 85 00:48:56 EDT
From: Charles Hedrick <
[email protected]>
Subject: sort interface
To:
[email protected]
Message-ID: <
[email protected]>
I just got the Pascal SORT interface working, so I can tell you most of
what is going on. This assumes that you have merged SORT.EXE into your
program, which is in section 0. I don't know how it works in non-zero
sections. Note that Fortran seems to put it into section 1. Since SORT
plus its buffers takes up space, I do recommend putting it somewhere
other than where your code is. I use a subfork for Pascal, because not
all the sites that use it can handle extended addressing, and I am too
lazy to maintain two versions. But if you know the machine can handle
it, I would certainly use extended addressing instead. I suspect the
interface is similar, but it may not behave identically.
Anyway, Sort is called with the following arguments:
AC 1 - address of your FUNCT. routine. SORT will call this to
get memory, most of the time. See the LINK manual for
documentation. You seem to need to implement at least
allocation and deallocation of blocks of memory.
AC 4 - an address to which it will jump to exit. I think this
is used for error conditions, but it could be the normal
exit.
AC 16 - a Fortran argument block, in the usual format. Assume
ARGSTR is the address of an ASCIZ string containing the
command to SORT:
XWD -1,0 ;number of args
SRTARG: EXP 17B12!ARGSTR ;ASCIZ
You should call it at the + 3 location in the entry vector, which is the
Fortran entry point.
Memory allocation seems slightly wierd. You must supply a routine
FUNCT., which it uses to get most of its memory. It will return all of
this memory via FUNCT. when it is done. However it seems to get its
stack at .JBFF, and it does not update .JBFF to show the memory it has
taken. From looking a the code a little bit, it may assume that all
memory between .JBFF and the start of the high segment is free for its
use, though I would bet that it actually only uses the first few pages
of it. It finds the high segment by starting at 400000 and looking for
the first page that exists. So you had better have something up there,
or it will bomb out with an illegal page number in an RPACS.
It would certainly be a nice idea if the SORT manual documented a user
calling sequence for SORT.
-------
23-Oct-85 14:17:52-PDT,5737;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Wed 23 Oct 85 14:17:30-PDT
Date: 23 Oct 1985 17:19-EDT
Sender:
[email protected]
Subject: Re: tcp misfeature
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA]23-Oct-85 17:19:08.CLYNN>
In-Reply-To: <
[email protected]>
Charles,
Re your message:
We have the reciprocal problem. Most of our system staff use
terminal servers that run TCP/IP Telnet. These servers allow
you to maintain more than one session. You can escape back to
the server command level and then move to a different session.
It is fairly typical that when you return to your TOPS-20 job,
you find that the session has gone away. This does not happen
with jobs on Unix. Evidence suggests that the problem happens
when TOPS-20 has output for the terminal, but the terminal
server is not listening. It appears that TOPS-20 gives up at
some point. There is some leeway here because there is buffering
within the terminal server, but eventually the buffer does fill.
I'm not sure why Unix does not have this problem. Possibly our
usage of TOPS-20 and Unix is enough different that Unix never
fills the buffer when we are talking to somebody else. At any
rate, I consider this an annoying misfeature. However I agree
that it is hard to see how to fix it. My theory is that when
you escape from a telnet connection, the telnet user process
should reduce the window size to 0. However sending XOFF might
be better, as someone else suggested.
Yes, the window size should be set to zero by the terminal server.
I ran a few experiments to try to see what is happening. They are not
conclusive, but are interesting. The experimental setup is shown below.
Local F.BBN.COM Host
Terminal <- internet -> Packet <- internet -> being
Server Tracer tested
The Local Terminal Server is a device which is conservative in its
window policy (never advertizes more buffer space than it has, never
shrinks the window, but will report a zero window when the buffer
space allocated to a connection is full), and always acks data which
fits into the (advertized) window. When the advertized window is
zero, it sends an ack-only packet every 30 seconds with the window set
to zero.
The F.BBN.COM Packet Tracer is a user-level program using a TOPS-20
logical host to allow it access to all IP packets addressed to it. It
writes a copy of received packets to a file before sending them on.
It thus introduces delay and may drop packets when flooded.
The Host being tested is one of the following TOPS-20s: BBNA, SU-SCORE,
RED.RUTGERS.EDU, and TE.CC.CMU.EDU, and the BBN-LABS-B running Unix 4.2.
Host Comments
--------------- ------------------------------------------------------
BBNA Used to make sure the test setup worked and that the
local machine is working as expected. The TCP/IP code
it is running has many differences from the code being
distributed by DEC.
BBN-LABS-B A Unix system.
SU-SCORE Its TCP/IP code is, I believe, based on the DEC
distribution but with several bug fixes, etc., that
may not have reached other sites.
RED.RUTGERS.EDU The host which I assume is the causing the reported
problem. Lack of an account on this system effected
the results (the TOPS-20 Autologout feature).
TE.CC.CMU.EDU Added to the test set after the others were tested to try
get another "opinion". The results are also effected by
the TOPS-20 Autologout feature.
The test procedure involved connecting to the host's telnet server, logging
in if an account was available, starting output to the terminal (TTYTST,
SYS CLA, or typing a file), and "escaping" which caused the terminal server's
buffer to fill and the window to go to zero.
The results of the experiments show: (H = host being tested)
Logged
Host In What happened when window reached zero
--------------- ------ -----------------------------------------------
BBNA Yes H sent data-less probes; still waiting an after
hour; returning to the connection continued from
point of escape.
BBN-LABS-B Yes H sent a one-octet probe (beyond the window) every
5 seconds; returning to the connection continued from
point of escape.
SU-SCORE Yes H sent a one-octet probe (beyond the window) every
two seconds. A reset was received after 5 minutes.
RED.RUTGERS.EDU No H still appears to have the "runaway ack" problem
(sends a data-less packet every scheduling cycle
during which data cannot be sent due to a closed
window); the flood of packets (one every few
hundred msec) caused the tracing program to drop
packets. H sent a one-octet probes (beyond the
window) "every few" seconds (too much missing data).
After about 11 minutes a reset was received
(probably due to the Autologout feature).
TE.CC.CMU.EDU No H sent a one-octet probe (beyond the window) every
minute. An urgent was received after 5 minutes;
subsequent probes all contained the urgent.
Returning to the connection after 15 minutes revealed
the customary Autologout message. Then Fins were
exchanged to close the connection.
It is interesting that each of the four TOPS-20 systems behaved differently.
Variations in terminal server characteristics were not investigated. It is
not known how the last two hosts would act if the test were performed while
logged in.
Charlie
23-Oct-85 15:16:50-PDT,2143;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 23 Oct 85 15:16:38-PDT
Date: Wed 23 Oct 85 15:16:04-PDT
From: Ken Harrenstien <
[email protected]>
Subject: Re: tcp misfeature
To:
[email protected],
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: <[BBNA.ARPA]23-Oct-85 17:19:08.CLYNN>
Message-ID: <
[email protected]>
Technically, you are not supposed to shrink your window except to
reflect the amount of data you have received, and you cannot expect
the sending host to realize that you have breached your promise of
sock-it-to-me buffers. So having the receiver reduce its window to 0
when it is not running is not really a solution, especially as the
quantum jump from lots of room to no room really does happen in one
quantum (the interval between two datagrams) and you are likely to
have stuff already on the retransmit queue. Doing this while the
connection is quiescent is more likely to work, but is still risky.
The real problem with TOPS-20 TCP is that it envisions the receive
window as lying within the user program rather than within the
system's own buffers. This causes all kinds of pain and grief. I
maintain the user program should be insulated from this kind of stuff,
just as programs should not have to know the seek latency of a disk
drive. NCP software never had to put up with this, and there is no
reason in this case that TCP software should either. I should be able
to interrupt any network program at any point without having the
connection vanish by itself; only a higher-level protocol decision at
the remote site can legitimately cause this.
This same problem applies to the Rutgers "terminal server" (a misnomer
from some aspects); it evidently advertised a receive window of a certain
size and then was caught in a lie.
Note that Clynn's test applies to TOPS-20 as a SENDER when faced with
a window shrunken to zero; some sites appear to behave properly, however
this is still not a reason to expect window-shrinking to work; this is
not really part of the protocol.
-------
23-Oct-85 20:33:38-PDT,2696;000000000000
Mail-From: BILLW created at 23-Oct-85 20:33:31
Date: 23 Oct 1985 20:33-PDT
Sender:
[email protected]
Subject: tcp performance improvements/retransmission bogosities.
From: William "Chops" Westfield <
[email protected]>
To:
[email protected]
Message-ID: <[SU-SCORE.ARPA]23-Oct-85 20:33:30.BILLW>
Symptoms:
A couple of times a day, Score and Sushi (tops20 systems connected to
arpanet and or ethernet(s)) would suddenly "pause", the load average
would shoot up to 60 or so (from single digit values), users didn't
get much response at all, and tcp connections stopped completely.
The front end showed that the internet work was running like crazy.
A couple of minutes would pass, and then things would return to normal.
Analysis:
We went so far as to crash the system so that a dump could be
obtained. It showed that the TCP process was running the
retransmitter. SYSDPY showed that the number of retransmissions was
about 30% of the total number of packets sent, so there certainly
appeared to be a problem here!
The "smoothed round trip time" calculation parameters were recently
changed (By LARSON@SRI-KL on 27-Jun-85). One of things changed was the
scaling factor (TCPRXF). Unfortunately, only one of the parameters
scaled by this factor was changed with it (TCPRXF). The multiplier for
the retransmission interval (TCPRXV) went from greater than one to
being less than one (from 1.5 to .375) causing:
The intial restransmission interval to be less that the
calculated round trip time.
If the packet was retranmitted, the new retranmission
interval was even smaller. On our ethernet, we see
RTTs of 50 mS, the retransmission interval would
apparently become 0, in which case the TCP process
would run continuously (being in queue 0) until
the other end finally acked the packet. Systems
with only arpanet interfaces didn't start out
with such low RTTs, and have fewer problems.
Fix:
Scale TCPRXV too:
@mddt
TCPRXV[ 140 (was 30)
^Z
The sources (v6.1) at Stanford have other changes too, like a BUGCHK
in REXMIT to detect "unreasonable" intervals.
Comments:
There are more bugs here than meet the eye. It looks like Alan's
patches are not a good fix in the first place, but tops20 DOES
seem to calcualte unreasonable RTTs. I expect to have some more
extensive performance improvments in a couple of days. In particular:
It looks like TSMRT is never initialized.
There is a minumum retranmission interval of one second
that is probably too small if you are on a LAN.
There is a "default" retransmission interval of 3 seconds
that is probably too small regardless.
More later
Bill W
23-Oct-85 23:25:50-PDT,1164;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Wed 23 Oct 85 23:25:47-PDT
Date: Wed 23 Oct 85 23:29:19-PDT
From: Kirk Lougheed <
[email protected]>
Subject: TOPS-20 TFTP server
To:
[email protected]
cc:
[email protected]
I've fixed the TOPS-20 TFTP server as distributed by CMU to be useful in
booting SUN Ethertips and Gateways. TFTPSR now understands broadcast requests
and will default filenames in the same manner as the PUP miscellaneous server,
e.g. "SUNBOOT13" maps to "PS:<SUN-BOOTFILES>SUNBOOT13.BOOT". The source is
PS:<TCP>TFTPSR.MAC on Sierra.
The next release of the EECF Ethertip/Gateway software (sometime early next
week) will start relying on the existence of a TFTP server to boot
configuration files. The automatic configuration will still be done using
EFTP, however the privileged command "configure" will invoke TFTP to load the
configuration file. Future releases of the Ethertip/Gateway may not have any
EFTP support at all.
I strongly recommend that any TOPS-20 that is acting as a boot server run
the modified TFTP server.
Kirk
-------
25-Oct-85 15:30:15-PDT,934;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Oct 85 15:30:07-PDT
Date: Fri 25 Oct 85 14:59:17-PDT
From: Mark Crispin <
[email protected]>
Subject: non-0 section programs
To:
[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <
[email protected]>
I am trying to write a program that will assemble and load into a
non-zero section instead of requiring a boot-up routine or use of the
EXEC's /USE-SECTION switch. I haven't been able to determine which
magic does this yet; I've tried having the PSECT set to 1010000, but
instead of page 10 in section 1 I get page 10 in section 0.
I want to eliminate section 0 entirely and have the EXE file as
written by LINK be section 1 exclusively. Does anybody have any ideas
on how to accomplish this?
-------
25-Oct-85 15:39:44-PDT,803;000000000000
Return-Path: <
[email protected]>
Received: from MIT-XX.ARPA by SU-SCORE.ARPA with TCP; Fri 25 Oct 85 15:39:32-PDT
Date: Fri, 25 Oct 1985 18:38 EDT
Message-ID: <
[email protected]>
From: Rob Austein <
[email protected]>
To: Mark Crispin <
[email protected]>
Cc:
[email protected],
[email protected]
Subject: non-0 section programs
In-reply-to: Msg of 25 Oct 1985 17:59-EDT from Mark Crispin <
[email protected]>
I'm not sure if this can be done directly (maybe one of the new v6
link switches will do this). I would probably just make a section
zero exe file, then do @GET/USE-SECTION, @SET ENTRY-VECTOR, @SAVE.
Crufty, but does pretty much what you want and should be fast enough.
If you figure out a better way, I'd be interested in hearing it....
--Rob
25-Oct-85 16:27:19-PDT,1923;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 25 Oct 85 16:27:08-PDT
Date: 25 Oct 1985 1928-EDT
From: Tom Blinn <
[email protected]>
To: Mark Crispin <
[email protected]>
cc: tops-20@su-score
Subject: Re: non-0 section programs
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12154038588.18.275.42471 at MARLBORO.DEC.COM>
References: Message from Mark Crispin <
[email protected]>
of 25-Oct-85 1834-EDT
In-reply-to: <
[email protected]>
It sounds like you're not specifying the PSECTs in the MACRO code. The
technique for doing this is documented in the MACRO manual.
If you've got a TWOSEG style MACRO program that already exists as a REL
file, you can tell LINK to load the LOWSEG and HISEG into PSECTs with
the /REDIRECT switch to link. This is documented on page 3-74 in the
LINK manual (for LINK V6.0). Assume you want to load the low-segment
code into a PSECT called .LO. and the high-segment code into a PSECT
called .HI.. Then you'd use a switch of "/REDIRECT:.LO.:.HI." in the
command line to LINK.
I've just got through building a large statistical package (PSTAT, over
1200 Fortran subroutines and functions) as a multi-section program, and
discovered several LINK features in the process. I've not had to use
the /REDIRECT feature, since by using the /EXTEND switch in Fortran I
got a MAIN program with code being loaded into PSECTs (.CODE. and .DATA.
with COMMON loaded into .LARG.), so the assembly code got PSECTed by LINK
automatically. (In this case, low-segment stuff gets loaded into .DATA.
and high-segment stuff into .CODE., which is write-protected by LINK by
default.) The whole process was relatively painless, and the program
would be running except for problems in the assembler code (which needs
to be converted to run in a non-zero section).
Tom
--------
28-Oct-85 11:03:23-PST,619;000000000000
Received: from LOTS-A by Score with Pup; Mon 28 Oct 85 11:03:20-PST
Date: Mon 28 Oct 85 11:02:09-PST
From: Rich Alderson <A.ALDERSON%LOTS-A@LOTS-A>
Subject: ACJ
To: su-tops-20%Score@LOTS-A
Message-ID: <12154776626.106.A.ALDERSON@LOTS-A>
I would like to conditionalize the ACJ so that the old LOTS-style queuing
system, DLINE and family, is left out of the code for those who, like LOTS, do
not need it. This will result in somewhat smaller .EXE files for most sites.
What sites would be adversely affected by this? Does anyone still use the old-
style queuing system?
Rich Alderson
-------
28-Oct-85 11:56:20-PST,877;000000000000
Received: from LOTS-C by Score with Pup; Mon 28 Oct 85 11:56:17-PST
Date: Mon 28 Oct 85 11:55:07-PST
From: Rich Alderson <A.ALDERSON%LOTS-C@LOTS-C>
Subject: Re: ACJ
To: su-tops-20%Score@LOTS-C
In-Reply-To: Message from "Jim Lewinson <
[email protected]>" of Mon 28 Oct 85 11:41:06-PST
Message-ID: <12154786269.212.A.ALDERSON@LOTS-C>
Date: Mon 28 Oct 85 11:40:43-PST
From: Jim Lewinson <
[email protected]>
In-Reply-To: Message from "Rich Alderson <A.ALDERSON%LOTS-A@LOTS-A>" of Mon
28 Oct 85 11:02:57-PST
I think we are the only other site that ever used the Queue, and I don't
think that we will be again.
Jim
If that's the case, I'll strengthen what I asked for before. Does anyone see
any problem with removing the old DLINE-style LOTS queue service from the
sources to the Stanford ACJ?
Rich
-------
28-Oct-85 20:36:33-PST,1044;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Mon 28 Oct 85 20:36:23-PST
Date: Mon 28 Oct 85 20:14:07-PST
From: Mark Crispin <
[email protected]>
Subject: new versions of MMailr/MAISER
To:
[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <
[email protected]>
A new version of MMailr and MAISER are now available in the MM package
on SIMTEL20's PS:<MM> directory. This new version now sets the
DISCARD-ON-ERROR flag for any incoming Internet mail which has a null
Return-Path instead of attempting to determine the sender by parsing
the message header. Messages with the DISCARD-ON-ERROR flag will be
sent in outgoing SMTP transactions with a null Return-Path instead of
the sender information.
Messages which were delivered to the TOPS-20 system from a non-Internet
network (e.g. Pup) will continue to be parsed to determine a sender to
be used as a Return-Path.
-------
29-Oct-85 01:21:54-PST,2223;000000000000
Return-Path: <
[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 29 Oct 85 01:21:36-PST
Date: 29 Oct 85 04:21:05 EST
From: Charles Hedrick <
[email protected]>
Subject: problem getting programs into non-zero sections
To:
[email protected]
Message-ID: <
[email protected]>
MACRO has a bug in it that causes it to truncate PSECT starting
addresses to 18 bits. I discovered this bug 3 years ago in preparing
for a DECUS talk. I SPR'ed it shortly thereafter. Apparently the fix
is not present in 53.1(1152), which is what Sumex has, and is in fact
also our most recent DEC source. Here is the patch I developed at the
time:
;This patch fixes MACRO to accept PSECT origins that are greater than
;18 bits. It is more complex than it should be because MACRO uses
;SGORIG for two different things. We leave it alone in its old uses
;and add a new variable SGFWOR that get the full 30-bit origin.
File 1) MACRO.MAC.2,30-Aug-82 23:00:47
File 2) MACRO.MAC.1,19-Jul-79 13:17:00
1)2 IFNDEF TOPS20,<TOPS20==1> ;[clh]
1) IFNDEF UUOSYM,<UUOSYM==^-TOPS20>
****
2)2 IFNDEF TOPS20,<TOPS20==0>
2) IFNDEF UUOSYM,<UUOSYM==^-TOPS20>
**************
1)79 ; HRRZ AC0,SGORIG(C) ;GET ORIGIN IF SPECIFIED
1) MOVE AC0,SGFWOR(C) ;[clh]
1) SGOUT1: CALL COUT ;[1020]
****
2)79 HRRZ AC0,SGORIG(C) ;GET ORIGIN IF SPECIFIED
2) SGOUT1: CALL COUT ;[1020]
**************
1)110 ;[SEGM9+7]
1) MOVEM AC0,SGFWOR(AC1) ;[clh] and full word version
1) SKIPL AC2,SGATTR(AC1) ;[1030][1021] RELOCATABLE PSECT?
****
2)110 SKIPL AC2,SGATTR(AC1) ;[1030][1021] RELOCATABLE PSECT?
**************
1)137 ADD V,SGNMAX ;[clh]
1) PSEND7: ;[1052]
****
2)137 PSEND7: ;[1052]
**************
1)137 ;[PSEND8+10]
1) MOVE AC0,SGFWOR(AC2) ;[clh]
1) CALL STORIT ;[clh]
1) SOJGE AC2,PSEND8 ;[1052]
****
2)137 SOJGE AC2,PSEND8 ;[1052]
**************
1)138 ;[PSEND9+10]
1) CALL GETIT ;[clh]
1) MOVEM AC0,SGFWOR(AC2) ;[clh]
1) SOJGE AC2,PSEND9 ;[1052]
****
2)138 SOJGE AC2,PSEND9 ;[1052]
**************
1)240 SGFWOR: BLOCK SGNSGS+1 ;[clh]
1) SGSBOT: BLOCK 1
****
2)240 SGSBOT: BLOCK 1
**************
-------
30-Oct-85 09:00:50-PST,1263;000000000000
Return-Path: <HAMMON%
[email protected]>
Received: from LLL-MFE.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Oct 85 09:00:39-PST
Date: Wed, 30 Oct 85 17:00 GMT
From: HAMMON%
[email protected]
Subject: Decnet tops-20(dn20)=> vax/vms4.1(phase IV) question.
To:
[email protected]
From: Randy Hammon <HAMMON@LLL.MFENET>
To: tops20@SU-SCORE.ARPA
Situation:
We have a KL running 5.1 and a DN20 talking to a 780 running vms 4.1.
The KL is a considered a phase III node and of course the vax is a phase IV
node.
Problem:
We use HOST.exe found in <decnet-tools> to do remote logins
from the Dec-20 to the vax.
HOST doesn't allow very much functionality. One can't change terminal params,
except terminal type( it complains about that but does it ) and many
control and escape characters don't get through, making it impossible to get
any work done this way. I was told by DEC telephone support that the
reason for this is that phase III doesn't have the functionality of phase IV.
Question: Has anyone out there gotten around this and either modified HOST
or written anything decent?
Thanks,
Randy Hammon /* I took over Norm Samuelson's machine. He's alive and
well writing system code on Crays here at the lab. */
-------
30-Oct-85 12:31:27-PST,861;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Wed 30 Oct 85 12:31:14-PST
Date: 30 Oct 1985 1532-EST
From: Bill Melohn <
[email protected]>
To: HAMMON%
[email protected]
cc: tops20@score
Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224"
Subject: Re: Decnet tops-20(dn20)=> vax/vms4.1(phase IV) question.
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12155317271.26.108.8044 at MARLBORO.DEC.COM>
References: Message from HAMMON%
[email protected] of 30-Oct-85 1207-EST
TOPS-20 V6.1 has support for CTERM, the new DECnet NVT protocol. CTERM has
the ability to do TEXTI% functionality on the local host, making it feel more
responsive over slow DECnet links. Almost everything (with the exception of
FMS/TDMS and some complex QIOs) works over TOPS-20 -> VMS CTERM connections.
Bill
--------
30-Oct-85 13:32:25-PST,2109;000000000001
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Oct 85 13:32:12-PST
Date: Wed 30 Oct 85 13:28:10-PST
From: Mark Crispin <
[email protected]>
Subject: CRJOB% non-zero section bug
To:
[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <
[email protected]>
Problem:
You can't CRJOB% invoke a program whose entry vector is in a
non-zero section.
Diagnosis:
This was never implemented.
Solution:
In MEXEC, replace the following section of code:
GEVEC ;GET THE ENTRY VECTOR
TLNN T2,777000 ;TOPS10 STYLE?
JRST STCJ2A ;NO. TOPS20 STYLE, IF ANYTHING.
HRRZ T3,CRJEVO ;OLD STYLE. WHERE DOES START POINT?
CAILE T3,1 ;START OR REENTER, I HOPE.
JRST SCJXX3 ;NO. FAIL.
UMOVE T2,120 ;GET JOBSA
TRNE T3,-1 ;OR IF 1,
UMOVE T2,124 ;GET JOBREN
SKIPA
STCJ2A: ADD T2,CRJEVO ;NEW STYLE, ADD OFFSET TO BASE.
HRRZM T2,-1(P) ;WHERE MRETN WILL GO.
with:
XGVEC% ;GET THE ENTRY VECTOR
IFXN. T2,777000 ;TOPS10 STYLE?
HRRZ T3,CRJEVO ;OLD STYLE. WHERE DOES START POINT?
CAILE T3,1 ;START OR REENTER, I HOPE.
JRST SCJXX3 ;NO. FAIL.
XCTU [HRRZ T2,120] ;GET JOBSA
TRNE T3,-1 ;OR IF 1,
UMOVE [HRRZ T2,124] ;GET JOBREN
ELSE.
MOVE T2,CRJEVO ;NEW STYLE, GET OFFSET
ADD T2,T3 ;AND BASE
ENDIF.
MOVEM T2,-1(P) ;WHERE MRETN WILL GO.
A DDT patch follows:
$GET SYSTEM:MONITR
$START 140
DDT
1,,FFF/ 0 XGVEC%
1,,FFF2+1/ 0 TRNN T2,777000
1,,FFF2+2/ 0 JRST FFF2+12
1,,FFF2+3/ 0 HRRZ T3,CRJEVO
1,,FFF2+4/ 0 CAILE T3,T1
1,,FFF2+5/ 0 JRST SCJXX3
1,,FFF2+6/ 0 XCTU FFF2+16
1,,FFF2+7/ 0 TRNE T3,777777
1,,FFF2+10/ 0 XCTU FFF2+17
1,,FFF2+11/ 0 JRST FFF2+14
1,,FFF2+12/ 0 MOVE T2,CRJEVO
1,,FFF2+13/ 0 ADD T2,T3
1,,FFF2+14/ 0 MOVEM T2,-1(P)
1,,FFF2+15/ 0 JRST STCJ2A+2
1,,FFF2+16/ 0 HRRZ T2,.JBSA
1,,FFF2+17/ 0 HRRZ T2,.JBREN
STCJ2A-12/ 0 GEVEC JRST FFF
^Z
$SAVE SYSTEM:MONITR.EXE
-------
30-Oct-85 17:47:04-PST,1617;000000000000
Return-Path: <BUDD%BUCS20%
[email protected]>
Received: from CSNET-RELAY.ARPA by SU-SCORE.ARPA with TCP; Wed 30 Oct 85 17:46:53-PST
Received: from bostonu by csnet-relay.csnet id ac23922; 30 Oct 85 20:42 EST
Received: from BUCS20 (bucs20.ARPA) by bu-cs.ARPA (4.12/4.7)
id AA08530; Wed, 30 Oct 85 18:52:00 est
Date: Wed 30 Oct 85 18:48:48-EST
From: Philip Budne <BUDD%BUCS20%
[email protected]>
Subject: Mysterious crashes
To: tops-20%
[email protected]
Message-Id: <12155353098.16.BUDD@BUCS20>
We have been seeing a large number of ILULK2 BUGHLTs (tried to unlock
page not locked) -- about one every two days;
We are running 5.4(1025) with some local changes. No recent changes
have been made to IPIPIP or the build procedure.
The internet fork is current, at PC INTBP6+15; at the HDISMS (JSP
CX,EXMSH). Page fail word has the same address, as does PC of last
page fail.
The monitor build shows no new or unusual address space problems.
An unrelated but annoying bug that has also stumped me; every now and
then, one of the NETSRV subforks starts recieving spurious interrupts
on the timer channel while waiting in the initial OPENF%. The result
is that the fork halts, and gets restarted, all to have this happen
all over again.
I would appreciate suggestions on where to look for either problem.
Also -- Our operations staff has been looking for a way to do a
pack-to-pack backup of PS (an RP06), but we have found no TOPS-20
utility which performs this function.
Thanks
Phil Budne
Boston University / Distributed Systems
-------
30-Oct-85 19:04:12-PST,1668;000000000000
Return-Path: <
[email protected]>
Received: from CS.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Wed 30 Oct 85 19:04:00-PST
Date: Wed 30 Oct 85 22:03:10-EST
From: Jonathan S. Intner <
[email protected]>
Subject: Re: Decnet tops-20(dn20)=> vax/vms4.1(phase IV) question.
To:
[email protected]
In answer to Randy Hammon's question about connecting a V5.1 system to
a VAX running VMS 4.x Bill Melohn talks about using TOPS-20 V6.1 which
has CTERM.
Now, this is great for those people who will be running 6.1...indeed,
I have HOSTed from a TOPS-20 V6.1 system to a VMS 4.x system and it
works very well, but we have a DEC 2060, running TOPS-20 V5.1, that
will remain a 2060, and, unless I hear that 6.1 has no loss in
performance for a 2060, will probably continue to run V5.1, so HOSTing
from the V5.1 2060 to the V4.x 750 is my only choice, and it isn't too
good. So hopefully there is something out there that works better
that HOST.
I guess there are 2 questions here, both pretty old:
1) is there a way to communicate between a TOPS-20 *V5.1*
system and a VMS 4.1 system.
which brings up a second question:
2) what have people heard/felt/learned about running TOPS-20
V6.x on a 2060? Everything I have heard (at Spring DECUS and
around here at Columbia) is that without having a 2065 (the
pager, etc) there is a significant loss in performance. Is
this true?
Jonathan Intner
Systems Programmer, CCIMS.
ARPAnet: G.Intner@Columbia-20 (or is it CS.Columbia.EDU?)
BITnet: INTNER@CUTCV1 (the 750 running 4.x DECnet Phase IV)
CCnet: CCIMS.Intner@CUTC20 (the 2060 running 5.1 DECnet Phase III)
-------
31-Oct-85 01:32:06-PST,3685;000000000000
Mail-From: BILLW created at 31-Oct-85 01:31:59
Date: Thu 31 Oct 85 01:31:59-PST
From: William "Chops" Westfield <
[email protected]>
Subject: Improving TCP throughput.
To:
[email protected],
[email protected],
[email protected]
Message-ID: <
[email protected]>
The Tops20 TCP implementation attempts to be "sociable" by not
sending bare ACKs. In order to do this, whenever it receives
a packet that requires an ACK, it tells itself to wait for 250
milliseconds for some data to appear that is going in the opposite
direction so that the ACK can go with it. On something like
a telnet connection, this can essentially half the number of
packets being sent, and so it is an excellent and widely
implemented idea.
Unfortunately, Many TCP connections are essentially "one-way".
There is never going to be any data to send in the reverse
direction to piggyback the ACK on, and the system ends up
waiting when it should send and ack immediately.
Furthermore, some TCPs (including TOPS20's) calculate their
retransmission interval based on how long it takes them to receive the
ACK for a packet they have sent. Delaying your ACK waiting for data
disturbs this calculation, as pointed out by Alan Larson on
the TOPS20 mailing list (27-Jun-85).
Now, if the time it takes the other system to fill the window
(presumably including data transmission time) is less than the
time that your system waits to send the ACK, transmission
becomes bursty, and you get serious performance degradation.
This is aggravated by fast networks and small windows.
Such was the case on Stanford Tops20 systems (which are on ethernets)
running programs using the DEC JFN interface to TCP (which advertises
a maximum 1456 byte window). Using FTP, for example, getting a file
transfer speed of greater than 30K bps was rare. Using a BBN/CMU FTP
(which advertises much larger windows), higher throughputs could be
achieved (up to over 300Kbps, if irratically, and in extreme cases),
which provided additional frustration. PUP FTP regularly beat 150Kbps.
To improve upon this situation, I have implemented a concept I call
"Interactivity". A connection is maximally interactive if a packet is
sent every time a packet is received, and minimally interactive if it
never sends any packets. In the first case, you want to wait a bit to
try to piggyback acks on the outgoing data, but in the second case
this introduces delays, and you want to send acks immediately.
"Inverse interactivity" can be approximated by counting the number of
packets received between each one sent. If greater than N, it is
probably a good idea to send ACKs immediately. [Note: Immediately in
this case mean AFTER to have chosen not to avoid sending the ACK to
prevent the Silly Window Syndrome].
After performing this operation on the local tops20 systems, FTP data
rates (using the JFN interface) as high as 150kbps were seen on the
local ethernet. As might be expected from the above discussion, little
increase in performance was seen on connections to hosts "further
away" or on connections that used very large windows.
I am CCing this message to various mailing lists besides TOPS20 since
the idea may be useful within other TCP implementations.
[The new tops20 sources (ANAUNV, TCPBBN, TCPTCP, STG) are available
from Sierra in <6-1-monitor>, although these modules include some
additional TCP fixes of a less general nature. They are also on
Score, though those sources may be in transitory states. This
monitor has been running on Score and Sushi since last friday
without any apparent ill effects.]
BillW
-------
31-Oct-85 02:07:02-PST,3029;000000000000
Mail-From: BILLW created at 31-Oct-85 02:06:54
Date: Thu 31 Oct 85 02:06:54-PST
From: William "Chops" Westfield <
[email protected]>
Subject: more TCP improvements
To:
[email protected]
Message-ID: <
[email protected]>
This message describes some of the other improvements, mentioned in
the preivious message, that are in the latest sources at Stanford.
TVTSRV.MAC
The TVT service was assuming that if there was a large amount of data
in the TTY output buffers, there would soon be more, and delayed
tranmission of a packet for a little while. This resulted in rather
jerky output if your terminal was fast enough (a rather rare
occurance, actually). The new code checks to see if the output
buffers are full (in which case they aren't going to get any more data
added to them!), and if so it decides to send the packet immediately.
It should probably also check for there being enough data to fill
the window or the current packet, and/or it would be nice if tty
buffers were at least as large as a network packet, but my current
thinking is that TVTSRV needs a rather complete rewrite, rather
than a collection of patches. Sigh.
TCPTCP.MAC
Create a BUGCHK for calculatyed retranmission intervals under 80 ms,
and set it to TCPRXN instead. This should probably be a BUGINF or
just the test. We see minimum round trip times of less than 20 ms.
Keep track of minimum and maximum RTTs in the TCB, regardless of
the initial retranmission time algorithm used. Update TCPRXI
when using new method. There is a new SYSDY in SCORE:<6-SYSDPY>
that displays this info.
Remove Alan Larson's code that set the Smoothed RTT to the minimum
RTT. The new acking code,along with the changes to the RX params in
STG, should remove the need for this. It is a bad idea on local area
nets, or when you are talking to a host that doesn't delay its acks.
Transmit ACKs without waiting for data when connection isn't two way.
ANAUNV.MAC
Make TMNRT (min RTT) and TSMRT (smoothed RTT) be seperate halfwords.
(they used to overlap). Snarf some bits from the TSTO word to use
for counting the "inverse interactivity". Define a bit TSOPS (One
packet Sent) to mean that at least one SEND% jsys has been done.
(This was replaced by the interactivity concept.)
TCPBBN.MAC
Initialize TSMRT in ACTTCB. See TSOPS in SEND.
STG.MAC
Change the retransmission parameters. Set TCPRX0 (initial retransmission
interval) to 1.5 seconds. Set TCPRXN ("minimum") to 200 ms. Set
TCPRXS to 60 (.75) so that retransmission will adapt to changes
in RTT's more quickly. Fix TCPDXI to be in milliseconds instead of
seconds (though it isn't used often).
Again, the latest "fully tested" version of the software is on
SU-SIERRA in PS:<6-1-MONITOR>. These are 6.1 sources, but in
theory have conditional assembly code to work with 5.4. All
Stanford changes are enclosed in IFN STASWN,<> conditionals.
More work is in progress.
Bill Westfield
-------
31-Oct-85 07:39:27-PST,1461;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Thu 31 Oct 85 07:39:18-PST
Date: 31 Oct 1985 1039-EST
From: Tom Blinn <
[email protected]>
To: HAMMON%
[email protected],
[email protected]
Subject: Re: Decnet tops-20(dn20)=> vax/vms4.1(phase IV) question.
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12155526209.27.275.10214 at MARLBORO.DEC.COM>
References: Message from HAMMON%
[email protected] of 30-Oct-85 1208-EST
There is an "enhanced" version of HOST in the Integration Tools Clearinghouse.
It allegedly addresses SOME of the problems you cite.
The real solution is CTERM protocol, which is the supported way for Phase IV
systems to talk to one another. This is included in the TOPS-20 V6.1 DECnet
software, which should be shipping from the Software Distribution Center "any
day now", and certainly no later than mid-December.
You MAY be able to copy the HOST via ANONYMOUS FTP from TOOLS:[TOOLS.HOST] on
MARKET. (I don't routinely use FTP, and I don't know whether MARKET is set
up to allow ANONYMOUS access, and I'm too lazy to try it.) The TOOLS: disk
is usually mounted. We'll probably be moving this stuff onto an RA81 next
week, at which time it will be available ALL the time. (You could also use
the LCG.KERMIT account to KERMIT it.) It is on the TOPS-20 Tools tape, if
you have one (at least, on the Version 5 tape).
Hope this is of some help.
Tom
--------
31-Oct-85 11:04:24-PST,967;000000000000
Return-Path: <
[email protected]>
Received: from R20.UTEXAS.EDU by SU-SCORE.ARPA with TCP; Thu 31 Oct 85 11:03:59-PST
Date: Thu 31 Oct 85 13:03:05-CST
From: Pete Galvin <
[email protected]>
Subject: Fall DECUS session chairpeople
To:
[email protected]
Hello,
I am writing this as the current TOPS-20 coordinator of the
DECUS Large Systems SIG Steering Committee. The reason is to
find DECUS attendees who would be interested in chairing one or
more Large Systems sessions at the upcoming symposium.
Briefly, a session chair introduces the session and the
speakers, "controls" the session, and produces a session summary
to be included in the symposium proceedings.
If you are interested in chairing a session, please let me
know. The sooner you respond, the better the selection of
sessions to be chaired.
Thanks,
Pete Galvin
-------
31-Oct-85 21:32:46-PST,1642;000000000000
Return-Path: <
[email protected]>
Received: from USC-ISID.ARPA by SU-SCORE.ARPA with TCP; Thu 31 Oct 85 21:32:33-PST
Date: 1 Nov 1985 00:31:27 EST
From:
[email protected]
Subject: Re: Improving TCP throughput.
To:
[email protected],
[email protected],
To:
[email protected],
[email protected]
cc:
[email protected]
In response to the message sent Thu 31 Oct 85 01:31:59-PST from
[email protected]
Bill,
It's refreshing to see that somebody is still brave enough to keep hacking
at TCP trying to improve performance. We have seem some awful broken
things wandering by our gateway, some of which caused massive congestion
due imappropriate choices of retransmission timeouts, packetization, etc.
Our darling fuzzballs were taught a very similar trick some time back for
the same reason - to improve throughput on low-delay nets while sustaining
good packetization efficiency on long-delay ones. However, we took a slightly
different approach. If the left window edge moves an ACK will be guaranteed
after no more than a nominal delay (about the same as yours). If the right
window edge moves more than MSS octets since the last ACK, an ACK is
forced immediately. Thus, high-volume traffic with max-size packets is
not delayed, while interactive traffic with tinygrams is delayed for
piggybacking opportunities. Using the Nagle Algorithm together with this
technique, a typist can twinkle on a keyboard with a TOPS-20 or fuzzball
(but not a 4.2) and result in one segment flipping end-for-end picking
up data, remote-echoes and ACKs as it flips. The gateways love it.
Dave
-------
1-Nov-85 12:36:04-PST,1086;000000000000
Return-Path: <
[email protected]>
Received: from SRI-STRIPE.ARPA by SU-SCORE.ARPA with TCP; Fri 1 Nov 85 12:35:47-PST
Date: Fri 1 Nov 85 12:35:20-PST
From:
[email protected]
Subject: .sawa
To:
[email protected]
Would someone please tell me what the .SAWA parameter to the .SKSCS
function of the SKED% jsys does? It looks like it specifys windfall
allocation (wa = windfall allocation ?) for classes. It even does some
things in sched (at NEWUT1 + a few) to slow down classes that are
ahead of their fair share. It looks like it will not prevent a class
from running with windfall, but will cause it to be slowed down.
However, the scheduler uses CLASSF greater than 0 as an indication
of windfall not being allocated. It does this is the balance set
loading and adjustment section. The two seem completely separated.
The .SAWA parameter is not mentioned in my monitor calls manual. It
is listed in monsym.mac, but it is listed under .SKSCJ (set class of
job), instead of .SKSCS (set class parameters) where it belongs.
Alan
-------
1-Nov-85 12:57:26-PST,825;000000000000
Mail-From: G.DAIR created at 1-Nov-85 12:57:15
Date: Fri 1 Nov 85 12:57:13-PST
From: Willis Dair <
[email protected]>
Subject: Re: .sawa
To:
[email protected]
In-Reply-To: Message from "
[email protected]" of Fri 1 Nov 85 12:36:11-PST
Phones: Work - 408/554-4082; Home - 408/923-BRIM
Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053
Message-ID: <
[email protected]>
I was working on a windfall per class project and could not figure out
the .SAWA word either. The SKED% documentation is all muffed up. I have
so many scribbles on that page, it is not funny. Anyway, if you need
something that will do windfall per class you can get the files SCHED.MOD,
SKED.DOC and WIND.MAC from [SU-SCORE]<G.DAIR>. It was written for a V5.0
monitor.
Willis
-------
1-Nov-85 12:59:48-PST,980;000000000000
Mail-From: G.DAIR created at 1-Nov-85 12:59:41
Date: Fri 1 Nov 85 12:59:41-PST
From: Willis Dair <
[email protected]>
Subject: internal job number question
To:
[email protected]
Phones: Work - 408/554-4082; Home - 408/923-BRIM
Address: Santa Clara Univ.; Kenna Comp. Ctr.; Santa Clara, Ca., 95053
Message-ID: <
[email protected]>
I have a question for those that are running V6 monitors:
I've noticed that the job numbers on the system do not correlate with
the job numbers in the internal monitor tables. For example, if
looking for the TTY for job 7, one would look in JOBPT+7. However,
the information does not jive. I suspect that it has to do with the
CFS stuff. My question is: Is there a monitor translation table, or
monitor procedure that will give me the right internal job number?
Note: We got 2 bad V6 documentation tapes. At this time we have no
information on the V6 "features".
Thanks-
Willis
-------
2-Nov-85 17:18:38-PST,841;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sat 2 Nov 85 17:18:29-PST
Date: Sat 2 Nov 85 17:18:08-PST
From: Stu Grossman <
[email protected]>
Subject: Re: internal job number question
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Willis Dair <
[email protected]>" of Fri 1 Nov 85 13:24:55-PST
I don't remember the table name, but there are two routines that you
can call from MDDT. They are GL2LCL and LCL2GL. The names are pretty
self explanatory. They both take an argument in T1 and return the result
there too.
Regarding cluster wide job numbers: Do not ever make the assumption
that there is a direct mapping between the internal and external job
numbers, even if the external job number is pretty low.
Stu
-------
3-Nov-85 08:19:42-PST,2183;000000000000
Return-Path: <
[email protected]>
Received: from CS.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sun 3 Nov 85 08:19:32-PST
Date: Sun 3 Nov 85 11:16:58-EST
From: Charlie C. Kim <
[email protected]>
Subject: Re: internal job number question
To:
[email protected]
cc:
[email protected],
[email protected],
[email protected]
The mapping is pretty straightforward though, as Stu Grossman points
out you should never expect global job numbers and local job indices
to match. Caveat: local job index 0 is always global job number 0
(and vice versa :-).
From global to local jobs, the move is easy since getji% incoporates
this functionality. The relevant index is 030 (.JILJI - local job
index). The mapping the other ways is easy too, though not
particularly elegant, you use brute force to go through the global
jobs until you find the matching local job (if it exists).
The monitor keeps the map in a table called JOBGBL. It's a direct
map, but the size of the elements isn't word integral. I don't
remember the size, but you can probably make a reasonable guess based
upon the fact that the elements must be big enough to hold the largest
local job index.
Interestingly, the monitor keeps its tables (at least a good number of
them) indexed by the local job index. All user (e.g. jsys) interfaces
specify and receive global job numbers (except as contraindicated -
e.g. .JILJI).
By the way, the base for (and theoretically the range of) global job
numbers is negotiated, so you can't expect a machine on a CFS machine
to always have the same range of job numbers. Though you can be sure
of the maximum global job number - look at the symbol MXGLBS.
At least one of the reasons behind this move was to mitigate problems
in a CFS environment with programs like LINK which create temporary
files which are supposed unique on the basis of job's number.
(Certainly easier changing the monitor than LINK :-)
Finally, I wouldn't recommend calling LCL2GL unless you know that the
local job index is in use - it'll print out a bugchk if it isn't.
Charlie C. Kim
User Services
Columbia Univ. Computer Center
-------
4-Nov-85 13:10:04-PST,876;000000000000
Return-Path: <MHICKEY%
[email protected]>
Received: from WISCVM.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 13:09:35-PST
Received: from (MAILER)UDCVM.BITNET by WISCVM.ARPA on 11/04/85 at
15:08:42 CST
Return-path: MHICKEY%
[email protected]
Received: by UDCVM (Mailer X1.21) id 5247; Mon, 04 Nov 85 16:02:41 EST
Date: Mon, 4 Nov 85 15:57 EST
From: Mike Hickey <MHICKEY%
[email protected]>
Subject: cpio for the -20
To: <
[email protected]>
Does anyone have a version of cpio that runs on the -20? We're licensed
for unix and there isn't a version for our machine but I'd like to be
able to dump the tapes we got from AT&T. It'd be nice if the program
was written in assembly (no C compiler yet). If there is no such program
could someone let me know what the cpio format is so I can write one myself?
/Mike
4-Nov-85 14:30:03-PST,676;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 14:29:39-PST
Date: Mon 4 Nov 85 14:29:20-PST
From: Haruka Takano <
[email protected]>
Subject: "user-defined" gateway/hosts tables
To:
[email protected]
Has anyone implemented or has ideas for implementing user-defined
gateway/hosts tables? Say you have a local network of workstations
and a potential gateway machine and you want to be able to access
this network via standard network programs but you don't want to
allow public access. It would be nice to be able to define your
own network and gateway with a couple of init files.
--Haruka
-------
4-Nov-85 15:17:50-PST,742;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 15:17:33-PST
Date: Mon 4 Nov 85 15:13:21-PST
From: Kirk Lougheed <
[email protected]>
Subject: Re: "user-defined" gateway/hosts tables
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Haruka Takano <
[email protected]>" of Mon 4 Nov 85 15:01:10-PST
The Stanford 5.3 monitor that you are running should have ACJ hooks for
access to the TCP: and PUP: devices based on foreign host and socket. It is
trivial to add a hook for the CHA: device. The standard 6.1 monitor has the
same ACJ hooks for TCP:.
At least, I think that's the answer to the question you're asking.
Kirk
-------
4-Nov-85 16:29:14-PST,584;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 16:28:48-PST
Date: Mon 4 Nov 85 16:26:58-PST
From: Haruka Takano <
[email protected]>
Subject: Re: "user-defined" gateway/hosts tables
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Kirk Lougheed <
[email protected]>" of Mon 4 Nov 85 15:30:55-PST
Actually, what I was looking for was something along the lines of
being able to specify "supplemental"or "alternate" tables for
TELNET, FTP, etc. to read and use.
--Haruka
-------
4-Nov-85 18:07:31-PST,986;000000000000
Mail-From: JPBION created at 4-Nov-85 18:07:19
Date: Mon 4 Nov 85 18:07:19-PST
From: Joel P. Bion <
[email protected]>
Subject: Link Info Needed (long symbols in particular)
To:
[email protected]
Message-ID: <
[email protected]>
Hi -
I am writing a Modula-2 compiler for the DEC-20s, and I am at the
point where I have assembler code, but I really want to generate .REL files.
I have never found myself at "this end" of link before. What I hope to find
from some of you are:
1) Info about programs to print/analyze REL files.
I know about GRUMP, circa 1980. Any newer
programs would be useful.
2) Info about long symbol names.
I do not want to limit IMPORT and the like to six
character limits! In general, I would prefer the
longer names.
3) General "here is how to write a REL file" documentation.
Even scraps from programs which generate REL files
would be welcome.
Thanks for your help.
Joel
-------
4-Nov-85 20:10:16-PST,822;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 4 Nov 85 20:10:01-PST
Date: 4 Nov 1985 2310-EST
From: Bill Melohn <
[email protected]>
To: Philip Budne <BUDD%BUCS20%
[email protected]>
cc: tops20@score
Loc/MS: "MR01-2/P13 Phone:(617)467-2224, DTN: 297-2224"
Subject: Re: Mysterious crashes
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12156711518.13.108.19513 at MARLBORO.DEC.COM>
References: Message from Philip Budne <BUDD%BUCS20%
[email protected]>
of 30-Oct-85 2054-EST
In-reply-to: <12155353098.16.BUDD@BUCS20>
This bug was most likely the BIG ILULK2 bug fixed as of 5.4(1034), which was
distributed last spring. The current version of 5.4 is 1043, which corresponds
to Autopatch tape 10.
Bill
--------
5-Nov-85 07:27:36-PST,3814;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Tue 5 Nov 85 07:27:21-PST
Date: Tue 5 Nov 85 10:26:35-EST
From: Thomas De Bellis <
[email protected]>
Subject: Re: Link Info Needed (long symbols in particular)
To:
[email protected]
cc:
[email protected]
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
I don't know the answers to these questions, but I am interested in
them. I know some partial answers and where to look for more info.
Here it is, I hope it helps in some way.
I don't know exactly what LINK wants as input. However, there are a
number of ways to learn more about this. A .REL file seems to be made
of a series of blocks, each with header descriptors. All the kinds of
blocks that it is supposed to be able to take are described in the
LINK reference manual which is part of the set of Tops-20 manuals. If
you read this, you will start to get an idea of what it is that LINK
wants. If you then spend some time FILDDT'ing a .REL file, you will
probably then start to have a good idea about what's going on.
A good thing to then look at would to look at the source to MACRO.
Then you will be able to see in a language you know what is being
generated. I assume that since you can hack compilers, understand the
lexical analysis and parsing code shouldn't be overwhelming (just
drudgework). Then you can start having fun with the code generator
part.
Also an option in the ALGOL compiler which every Tops-20 site should
run. It is kind of like Modula-2 and allows long symbol names in the
source. These get resolved before an .EXE file is made and I think
before the .REL file is made.
Here is most of I can remember about symbols. I know that by the
time you get to an .EXE file, symbols are not even sixbit. They are
converted in to RADIX50 format. RADIX50 format is mumbled about
someplace in the LINK reference manual and the MACRO manaul. RADIX50
allows them to put 6 characters in a word and then have a couple of
bits left over to handle things like module scoping. There is some
mumbling about module names and all that which I don't remember
exactly. DDT the symbol table of an .EXE file to find this out.
So, by the time you get to an .EXE, symbols have to be able to fit
in a word. If this doesn't happen, then DDT might not be able to type
out the symbol and I have rarely seen this happen. I have glanced at
the DDT source very briefly and I don't remember anything in it about
long symbol names.
What has to happen in that case is that either LINK sees a symbol
conflict and would then make up a different symbol or the compiler has
to guarantee unique symbols. I think the later case is the true one.
I have seen output from the Bliss-36 compiler which does handle long
symbol names in the textual input. I remember looking at the output
REL and listing files. They did use long symbol names in the macro
listing, but these always seemed to be unique up to the first 6
characters. So, that might just have been syntactic handwaving.
Bliss-36 is a good thing to look at if you've got it. In spite of
the fact that you can't get sources and that it is cumbersome to learn
to use use, Bliss-36 does lots of things. If it can be done on a 20,
the chances are that Bliss can do it.
In summary, the obvious: looking at the .REL files and .LST files
can be informative. I think it is the compiler's responsibilty to
resolve long symbol names, not LINK's. If you find out more, I'd like
it if you could let me know as I've wondered about this from time to
time.
-- Thomas De Bellis
Columbia DEC20 Systems Group
-------
5-Nov-85 21:36:47-PST,2844;000000000000
Return-Path: <
[email protected]>
Received: from RED.RUTGERS.EDU by SU-SCORE.ARPA with TCP; Tue 5 Nov 85 21:36:31-PST
Date: 6 Nov 85 00:36:13 EST
From: Charles Hedrick <
[email protected]>
Subject: .REL files
To:
[email protected]
Message-ID: <
[email protected]>
There are two .REL file formats, new and old. The old format is
intended to support 6 character names, and dates back to the KA-10,
with two segments and no extended addressing. The new format is
intended to support long names, has nicely integrated support for
multiple psects, and has some support for extended addressing.
Actually, these formats aren't totally separate, there are just
two sets of .REL block types, old and new. A new format file uses
new .REL block types (those above 1000) where possible. Alas, not
all of the new features are implemented yet. I have this nasty
suspicion that long symbol names are allowed, but LINK ignores
everything beyond the 6th character. However a language that
wants to use long symbols should probably still generate these
block types. As far as I know, only Fortran version 10 and
Pascal (the version for LINK 6) generate the new block types.
You might find it useful to take a look at the Pascal source. The
code that emits .REL blocks is all in one section, and at least
the low level routines are fairly well documented. The overall
structure of that section goes back to the original Pascal-10
compiler, and I take no responsbility for it. I believe the person
who asked this question was at a site that has our Pascal, so ask
your local wizards where the source is. You want the file PASCMP.PAS.
If it is not edit 335 (17-Nov-84), ask them to get a new version.
Since Pascal is fairly close to Modula, you may find our .REL file
generation helpful. We do not use long symbol names, but changing
to that block type shouldn't be hard once you understand what is
going on. There is a certain amount of trial and error involved in
generating .REL files. Not all documented things work, and some
that work don't work the way you might think. Particular things to
stay away from: If you use Psects (and you probably should for
new compilers), psect indices mean different things in the new and
old .REL block types. I try to use the new block types alll the
time, but there are a couple of places where you have to use the
old ones. Some of the documented Polish operators don't work.
The ones I recall are the conditional branching ones. I believe
that even if they did what they are documented as doing, they
couldn't possibly be used for anything, but they don't even do
that (or didn't the last time I tested). If you decide to use
the new block types, be sure you have an up to date LINK. We
have version 6(2364).
-------
6-Nov-85 03:52:35-PST,515;000000000000
Mail-From: BILLW created at 6-Nov-85 03:52:33
Date: Wed 6 Nov 85 03:52:33-PST
From: William "Chops" Westfield <
[email protected]>
Subject: Hyper: on hyperion
To:
[email protected]
Message-ID: <
[email protected]>
Does anyone have anything important on HYPER:?
Id like to make it into a pack taht would be more
easilly be usable without CFS turned on (eg overwrite
the startup and config files), and update things
like <6-1-sources> with the current versions.
BillW
-------
7-Nov-85 13:20:28-PST,859;000000000000
Return-Path: <
[email protected]>
Received: from anl-mcs.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Nov 85 13:20:14-PST
Received: by anl-mcs.ARPA (4.12/4.9)
id AA02578; Thu, 7 Nov 85 15:19:49 cst
Date: Thu, 7 Nov 85 15:19:49 cst
From:
[email protected] (Nugent)
Message-Id: <
[email protected]>
To: TCP/
[email protected], tops-20@su-score
Subject: Tops-20
I just got a little note from our friendly DEC sales office that we
needed to pay the following for Tops-20 TCP/IP:
qt 090-am TCP/IP v 4.0 $5000
qt 090-dz TCP/IP v 4.0 liscense only $1000
The explanation I heard last fall was that DEC would need a new q
number so that they could start distributing TCP/IP, but it wasn't
supposed to cost anything. Is our local office confused, or is
SDC so inefficient that it costs DEC $5K to mail out a few tapes?
Todd
7-Nov-85 13:23:08-PST,872;000000000000
Return-Path: <
[email protected]>
Received: from anl-mcs.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Nov 85 13:22:24-PST
Received: by anl-mcs.ARPA (4.12/4.9)
id AA02631; Thu, 7 Nov 85 15:21:44 cst
Date: Thu, 7 Nov 85 15:21:44 cst
From:
[email protected] (Nugent)
Message-Id: <
[email protected]>
To: tops-20@su-score
Subject: Tops-20 TCP/IP
Cc:
[email protected]
I just got a little note from our friendly DEC sales office that we
needed to pay the following for Tops-20 TCP/IP:
qt 090-am TCP/IP v 4.0 $5000
qt 090-dz TCP/IP v 4.0 liscense only $1000
The explanation I heard last fall was that DEC would need a new q
number so that they could start distributing TCP/IP, but it wasn't
supposed to cost anything. Is our local office confused, or is
SDC so inefficient that it costs DEC $5K to mail out a few tapes?
Todd
7-Nov-85 15:30:12-PST,423;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Thu 7 Nov 85 15:29:56-PST
Date: Thu 7 Nov 85 17:29:56-CST
From: Clive Dawson <
[email protected]>
Subject: FORMAT
To:
[email protected]
Does anybody have a version of FORMAT which will work for RP07's?
(Or can somebody say whether the one which only asks about RP04's
5's and 6's can be fooled?)
Thanks,
CLive
-------
7-Nov-85 15:41:08-PST,2392;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Thu 7 Nov 85 15:40:51-PST
Date: 7 Nov 1985 1838-EST
From: Tom Blinn <
[email protected]>
To:
[email protected]
cc: tops-20@su-score
Subject: Re: Tops-20 TCP/IP
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12157448437.13.275.10031 at MARLBORO.DEC.COM>
References: Message from
[email protected] (Nugent)
of 7-Nov-85 1724-EST
In-reply-to: <
[email protected]>
Todd (and all the rest of you),
I believe you are correct, that your local office is confused, but I'm
not 100% sure. I believe that what should have happened is that, if you
had a valid TOPS-20 ARPA monitor license, under support, that you should
have been transferred (at no charge) to the combination of the "regular"
TOPS-20 license PLUS the TCP/IP extensions license, and of course if you
have DECnet support you should also receive the Phase IV DECnet stuff.
If you're not under software support at the present time, then the local
office may be right in asking you to purchase the TCP/IP license.
In any event, DON'T PANIC. I'm forwarding your message to the responsible
parties (the people who make the policies and are responsible for seeing
that they get implemented). I'm also going to point out what I understood
the policy to be (as outlined above).
In the meantime, be sure to check the status of your software support, and
make sure it hasn't accidentally lapsed. Then, once we get clarification
on the policy, we should be able to make you happy.
The principal reasons for separating out the TCP/IP support into a package
similar to the DECnet package was to simplify distribution and maintenance,
as well as ordering. As you realize, in the past, having the TCP/IP stuff
was almost always equivalent to being on the "real ARPAnet". More and more,
customers are using the TCP/IP software to communicate with Ultrix and
other UNIX systems on local area nets (through the NIA20). The new way of
selling, distributing, and maintaining the software makes it easier for
both us and our customers to provide this capability.
When I get a clarification on this, I'll try to put the "official" answer
here, taking into account the policies on commercialism. I'm sure we'll
have a definitive answer BEFORE Anaheim DECUS.
Tom
--------
7-Nov-85 15:52:08-PST,1183;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Thu 7 Nov 85 15:51:52-PST
Date: 7 Nov 1985 1849-EST
From: Tom Blinn <
[email protected]>
To: Clive Dawson <
[email protected]>
cc:
[email protected]
Subject: Re: FORMAT
Message-ID: <"MS11(2447)+GLXLIB5(0)" 12157450448.13.275.66693 at MARLBORO.DEC.COM>
References: Message from Clive Dawson <
[email protected]>
of 7-Nov-85 1845-EST
I believe the "approved" way to FORMAT an RP07 for use on TOPS-20 is to
use the "offline" formatter that is microcoded into the RP07 controller.
Field Service should know how to do this, and you might be able to get
them to teach you how. The "vanilla" RP07 drive's controller knows how
to format the media both for 32-bit and 36-bit system operation.
I'm not even sure there is a host-based formatter for the RP07s, since
with the "smart" controller, one really isn't needed, and it would be
a shame to waste host cycles formatting disk media when the disk has
a controller that can do it without host intervention.
You'll still need to run CHECKD to initialize the home blocks, etc.
Tom
--------
8-Nov-85 08:23:00-PST,763;000000000000
Mail-From: BILLW created at 8-Nov-85 08:22:51
Date: Wed 3 Apr 85 19:00:49-PST
From: Len Bosack <
[email protected]>
Subject: Re: formatting RP07's
To:
[email protected]
In-Reply-To: Message from "William "Chops" Westfield <
[email protected]>" of Wed 3 Apr 85 17:47:03-PST
ReSent-To:
[email protected]
ReSent-From: BILLW at SU-SCORE.ARPA
ReSent-Date: 8 Nov 1985
Ah yes, the diagnosis of Digital. You have to do the following:
- Boot KLDCP the usual way
- run BT to get the machine initialized
- P D20MON$
This is a program that reads the -20 side of the KLAD filesystem and
runs programs. When it asks What Dir? just hit return.
- type DFRPM to the CMD prompt
The diag will load and start and look normal.
Len
-------
10-Nov-85 13:17:46-PST,986;000000000000
Mail-From: G.ROODE created at 10-Nov-85 13:17:36
Date: Sun 10 Nov 85 13:17:36-PST
From: David Roode <
[email protected]>
Subject: software support
To:
[email protected]
Message-ID: <
[email protected]>
I recently checked the price of monitor source maintenance
and found it to be $8000 per month. This is quite a jump over
the more recent price of around $1K per year. Has anyone
recently renewed their software maintenance and found this to be
so? When DEC promised to continue support for the 5 year
and 10 year periods following the no-Jupiter announcement,
did they say anything about holding prices in line?
Will it cost $25,000 next year?
Also, on the TCP/IP license, was there not a committment that
this would be bundled in with TOPS-20 proper? Considering that
most of the development work was done on DARPA funding by BBN,
it seems atrocious to talk of $5000 to license it. What
will the separate support cost be?
-------
10-Nov-85 17:32:43-PST,1398;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 10 Nov 85 17:32:33-PST
Date: Sun 10 Nov 85 17:11:46-PST
From: Joel P. Bion <
[email protected]>
Subject: Bug in LINK, Block 1070 support
To:
[email protected]
At least in FT6, most certainly other versions with block 1070 support.
Symptom:
Using long symbol names between 7-12 characters in length in
type 1070 (Long Symbol name blocks) causes .GETSP overflow
errors.
Cause:
Really, a local problem and a more global one. Locally, an
AOBJN loop does not check before its entrace whether or
not it should be entered. More globally, values are placed
on the stack in this module with no concern as to if they
are ever popped off. Even worse, no error messages are
generated when the block format is bad - LINK just attempts
to ignore them.
The global problem is a big mess, but here is a "fix" for the local
trouble. In LNGNM, you will find this sequence:
HLRZ T2,W2 ;[2305] get the count to t2
SUBI T2,2 ;[2305] minus the words already done
MOVNS T2 ;[2305] -count
HRLS T2
...
enter the loop.
Insert these lines after the SUBI T2,2:
SKIPG T2 ;are we already done?
JRST [POP P,W1 ;remove the pushed element!!
POPJ P,]
The JRST into the literal is a kludge, but then again so is...
Have fun,
Joel
-------
10-Nov-85 18:33:12-PST,536;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Sun 10 Nov 85 18:33:04-PST
Date: Sun 10 Nov 85 18:32:40-PST
From: Joel P. Bion <
[email protected]>
Subject: Re: LINK bug (foot in mouth disease)
To:
[email protected]
After tirading about not keeping trace of the stack correctly, I gave you
a version of the code which didn't treat it right!!
Anyway, you people want to put just a POPJ 17, after the SKIP, not the
JRST [...].
Sorry about that one...
Joel
-------
12-Nov-85 11:07:49-PST,1901;000000000001
Mail-From: G.GREIG created at 12-Nov-85 11:07:31
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from ucl-cs by SU-SCORE.ARPA with TCP; Mon 11 Nov 85 07:33:07-PST
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002687; 11 Nov 85 2:31 GMT
Via: DCT; by DUNDEE on Monday, 11-Nov-85 02:05:23-GMT
Date: Mon 11 Nov 85 01:46:14-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: [Alan Greig <CCD-ARG@DCT>: Problem with magtape GET/SAVE of Exe files with PDV]
To: "g.greig" <g.greig%
[email protected]>
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
ReSent-Date: Tue 12 Nov 85 11:07:31-PST
ReSent-From: Alan Greig <
[email protected]>
ReSent-To:
[email protected]
ReSent-Message-ID: <
[email protected]>
Mail-From: CCD-ARG created at 29-Oct-85 12:50:01
Date: Tue 29 Oct 85 12:50:01-GMT
From: Alan Greig <CCD-ARG@DCT>
Subject: Problem with magtape GET/SAVE of Exe files with PDV
To:
[email protected]
cc: alan@DCT
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan@DCT
It seems we've been writing useless system backup tapes under 5.1.
MX>get mta0:
MX>start
gives Interrupt at 7001
Now 7000 and 7001 should be JRST REE. What is actually there is zero.
The missing instructions appear at 7002 and 7003. In fact the entire
exe file has been shifted 2 words up. Save and get normally work ok
from tape and indeed files such as dluser and dumper on the same tape
are ok. The only difference seems to be that our EXEC.EXE file has
a Program Data Vector set up.
Anyone seen this problem ? I can only guess that the GET/SAVE code
for tape doesnt know about PDV info in the directory page and gets
confused as GET/SAVE of the same file on disk works ok.
Alan
-------
-------
12-Nov-85 18:57:53-PST,879;000000000000
Mail-From: BILLW created at 12-Nov-85 18:57:51
Date: Tue 12 Nov 85 18:57:50-PST
From: William "Chops" Westfield <
[email protected]>
Subject: new sysdpy
To:
[email protected]
Message-ID: <
[email protected]>
There is a new SYSDPY on Score in <6-SYSDPY>. New features include:
o ANCnn display clean up. Things like precedence and security
level are displayed only if they are non-0.
o "A" command advances to the next TCB in ANCnn displays, and to
the next port in PUnn displays.
o "A" command in ANC display causes only Active connections to
be displayed (which remains in effect for ANCnn, A)
o ANC display has new columns for Min-RTT, Max-RTT, S-RTT, and
the per connection Retranmission count. Some of this wont
work unless you have the latest monitor, and you also need
a new ANADPY.
Enjoy
BillW
-------
12-Nov-85 19:57:18-PST,475;000000000000
Return-Path: <
[email protected]>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Tue 12 Nov 85 19:57:10-PST
Date: Tue 12 Nov 85 19:56:32-PST
From: Mark Crispin <
[email protected]>
Subject: SMAP%
To:
[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <
[email protected]>
Is there any good reason why SMAP%'ing a file doesn't allow preloading?
-------
13-Nov-85 02:31:24-PST,1692;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from ucl-cs by SU-SCORE.ARPA with TCP; Wed 13 Nov 85 02:30:30-PST
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000146; 12 Nov 85 19:00 GMT
Via: DCT; by DUNDEE on Tuesday, 12-Nov-85 18:45:53-GMT
Date: Tue 12 Nov 85 18:29:20-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: rsx20 15-15 accessing front end file system
To:
[email protected]
cc: alan%
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Since putting up RSX20 version 15-15 we have been plagued with
problem on device rp06 error messages caused by the front end
accessing the front end file system on PS: roughly for periods of
a few secs evry 30 secs or so. Although this doesnt seem to be having
an serious impact on system performance it obviously is slowing things
up a bit. Field service physically disconnected the 11 from the drive
to try and force a crash but the system would not oblige. The access
can't be vital as if it can't get to the files then it doesnt even
complain. The only possibly related change we have made is that with
the change to 15-15 we have set all our lines to REMOTE AUTO via a micom
port selector as 15-15 has autobaud support up to 9600 baud. We have
not installed the autobaud patches in the bwr file as we do not experience
any problems with speed detection.
Anybody else seen this problem and/or have a solution to it ?
Alan Greig
Computer Centre
Dundee College of Technology
Dundee
Scotland
Janet: Alan%DCT@DDXA
Arpa: Alan%
[email protected]
-------
13-Nov-85 17:57:53-PST,786;000000000000
Return-Path: <
[email protected]>
Received: from SRI-STRIPE.ARPA by SU-SCORE.ARPA with TCP; Wed 13 Nov 85 17:20:02-PST
Date: Wed 13 Nov 85 17:18:18-PST
From:
[email protected]
Subject: b.d.
To:
[email protected]
In a message dated 21 Jun 1983, Charlie Lynn described the proper
code for the end of the IMPHDR routine (then in 1822DV.MAC, now in
IMPDV.MAC). He noted that two instructions must be removed if present.
Unfortunately, DEC removed an extra instruction. After the MOVX T1,STY%FC
there should be one more instruction:
STOR T1,IHSTY,(T2) ; Message sub-type
This note may be found in the file NETINFO:INTERNET.PINGING at the NIC.
(By the way, does anyone know how to set the routing cache timeout that
he refers to?)
Alan
-------
14-Nov-85 03:14:41-PST,1316;000000000000
Return-Path: <LARSON%
[email protected]>
Received: from SRI-STRIPE.ARPA by SU-SCORE.ARPA with TCP; Thu 14 Nov 85 03:14:33-PST
Date: Wed 13 Nov 85 10:07:56-PST
From:
[email protected]
Subject: Re: rsx20 15-15 accessing front end file system
To: CCD-ARG%
[email protected]
cc:
[email protected], alan%
[email protected]
In-Reply-To: Message from "Alan Greig <CCD-ARG%
[email protected]>" of Wed 13 Nov 85 02:40:25-PST
The front end seems to fetch something from the disk when it autobauds.
This can be verified by running from the floppies and listening to them
when someone starts on a remote line.
The autobaud code seems to work great. Contrary to other claims, we
have not had trouble with it picking the wrong speed, and the patches
that 'fix' this problem seem to be just reductions in capabilities.
The autobaud routine loader is brain-damaged. If autobaud is already
running (or being loaded, or whatever), the second user to come in on
the remote line will be 'lost'. He will not get autobaud. His line will
be dead.
The front end action causes the disk to seek away from the 20 area
of the disk, making the next access by the 20 even slower than if the
11 had only done a transfer.
These problems were sent to DEC. They never responded.
Alan
-------
14-Nov-85 19:20:02-PST,2684;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Thu 14 Nov 85 19:19:49-PST
Date: Thu 14 Nov 85 21:29:45-EST
From: Thomas De Bellis <
[email protected]>
Subject: KNILDR inducing CHKRNR bughlt's
To:
[email protected]
Message-ID: <
[email protected]>
We've gotten hit with a couple of these bughlts lately and I've been
paging through the related PHYKNI and KNILDR code to try to figure out
why. The KNILDR program gets invoked under job 0 when the monitor
decides that an NI needs to get dumped or reloaded. A symptom of this
being necessary would be a KNICAE bugchk, for example.
KNILDR gets invoked and started at the second location in its entry
vector which causes it to set a flag which puts it into automagic
mode. In this mode, it doesn't ask for user input--it just goes off
and does `the right thing' for the all the NI's it can find.
Gosh this all seems to be pretty dandy, but sometimes it doesn't
seem do the right thing and for some reason the ATOFLG (automagic
flag) gets set to 0 and this cause KNILDR to go into user mode input
wait from job 0. After it doesn't get any input for awhile, the SCHED
module decides that something is deeply wrong with job 0 and we go
away with a CHKRNR.
I think I see from the code in PHYKNI how the KNILDR fork is started
at entry 1 (the relevant code for this is around KNIJB0). It also
looks like the system keeps the fork around if it needs to reload the
NI in the future. This sounds like a pretty reasonable thing to do
since you then save yourself the fork startup time, etc... However, I
don't see how it is continuing or starting KNILDR after it has
allready been run. It it were to start the fork at entry vector 0,
then ATOFLG would get smashed and the KNILDR could never work and you
would always crash.
Additionally, I am seeing other error messages from KNILDR in this
mode on the console such as ?File not found. Since we never seem to
get dump files, I assume this means that it can't OPENF% the dump file
that it creates. All the OPENF%'s seem to have the right things
loaded into their ac's but I can't be sure of that just right now
since I can't tell exactly where the error happens.
I am pretty sure that we are running the latest 6.1 stuff; at least
the third tape. So, has anybody seen this? If not, I'll start
rewriting the error handling routines in KNILDR to give me some more
information like the ATOFLG and the location of the error. Any other
ideas are also welcome.
Thomas De Bellis
Columbia DEC Systems Group
-------
15-Nov-85 11:53:23-PST,3552;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from ucl-cs by SU-SCORE.ARPA with TCP; Fri 15 Nov 85 11:52:00-PST
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002058; 14 Nov 85 19:45 GMT
Via: DCT; by DUNDEE on Thursday, 14-Nov-85 15:05:09-GMT
Date: Thu 14 Nov 85 14:55:09-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: [banks < (Dawn Banks)banks%
[email protected]>: re: RSX20F 15-15 accessing front end file system]
To:
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Here's what I got back on the autobaud problem. The response was
to me and not the tops-20 list but as others have mailed me saying they have
seen a similiar problem, I am forwarding it on.
---------------
Via: DUNDEE
Via: UCL.CS; by DUNDEE on Wednesday, 13-Nov-85 18:39:53-GMT
Received: from decwrl.dec.com by 44d.Cs.Ucl.AC.UK via Satnet with SMTP
id a001012; 13 Nov 85 16:17 GMT
Received: from DEC-RHEA.ARPA (dec-rhea) by decwrl.DEC.COM (4.22.01/4.7.34)
id AA25447; Wed, 13 Nov 85 07:15:26 pst
Message-Id: <
[email protected]>
Date: Wednesday, 13 Nov 1985 07:11:49-PST
From: banks < (Dawn Banks)banks%
[email protected]>
To: CCD-ARG <CCD-ARG%
[email protected]>,
banks <banks%
[email protected]>
Subject: re: RSX20F 15-15 accessing front end file system
Hi. Couldn't help but notice your mail about RSX-20F accessing the front end
file system regularly. I've got a guess as to what that might be:
Whenever someone connects to an autobaud line, and performs autobaud detection,
the front end (20F) must send the detected speed to the back end.
Unfortunately, the RSX-20F executive itself only knows the DH-11 hardware
format bits that induced the line to work, so it invokes SETSPD.TSK from the
front end file system to decode these bits, and send a more readable (decimal)
baud rate to the back end. Thus, you'd expect to see the front end disk get
dinged everytime someone connects to an autobaud line. There's not much you
can do about this other than un-autobauding your lines.
---------
Coments: running setspd might be ok for a site with only one or two
autobaud lines but for sites like DCT where we now have over 100 auto
lines with about 70 in use at any one time and a high job turnover rate,
I'm not sure the performance degradation is acceptable. Going back to
fixed speed lines would mean a return to the Queue=5 ,Wait Y/N? message
that would often occur when the demand for lines at a set speed outripped
the number we had preset to that speed. Although there are definite
advantages in tops-20 knowing the correct line speed, we would prefer
to forgo that for the moment until the rsx20-f exec is taught to
inform the kl10 itself. An unsupported front end patch to do this
would be helpful. At the very least the problem on device messages
should be in the beware file as any unsuspecting site is likely to
call field service. Although, I must admit, it is fun to watch an
rp06 try to breakdance across the m/c room floor when a class of 50 people
on autobaud lines hit <return> to log in ! You even get a nice sound
to light sequence as the CONTROL A/B lights punch it out on the drives
control panel.
Horrible thought: What about some tops-10 site booting from dectape. Just
imagine the system going out to the tape every time someone logged in !
Alan
-------
15-Nov-85 15:13:02-PST,1699;000000000000
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 15 Nov 85 15:12:47-PST
Date: Fri 15 Nov 85 15:11:56-PST
From: Stu Grossman <
[email protected]>
Subject: Re: KNILDR inducing CHKRNR bughlt's
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Thomas De Bellis <
[email protected]>" of Thu 14 Nov 85 19:59:40-PST
Here is how KNILDR/PHYKNI REALLY works:
When PHYKNI decides that KNILDR needs to run, it invokes it's job 0 code
at KNIJB0. This code then runs KNILDR via RUNDII (in MEXEC). RUNDII
blocks until the requested program halts for any reason. This means that
when KNILDR is done, it's fork is also destroyed. New requests for KNILDR
always result in a new invocation of the program.
When KNILDR is run in this fashion, it is in 'automagic' mode. In that
mode, it will not attempt to get input from the terminal, as that would
hang the system. Unfortunately, when I wrote KNILDR I forgot about checking
for 'automagic' mode in some of the error recovery routines. Specifically,
if the OPENF% JSYS gets an error when trying to open the dump file, it
goes to the routine BADFIL which then prints a message, and promptly goes
back to the top level command input loop.
This bug was found by Chris Mayo and Bill Schilit at Columbia University
some time ago. They told me about it, and I beleive that I fixed it prior
to FT6 of 6.1.
The real question is: Why did the OPENF% fail? You probably have a disk
problem, or the directory you want to write the dump file into is sick.
Stu Grossman
Senior Software Jesus, Systems Concepts Inc.
-------
16-Nov-85 13:34:15-PST,969;000000000000
Mail-From: G.FUSSELL created at 16-Nov-85 13:34:03
Date: Sat 16 Nov 85 13:34:03-PST
From: Carl Fussell <
[email protected]>
Subject: Re: FORMAT
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: <"MS11(2447)+GLXLIB5(0)" 12157450448.13.275.66693 at MARLBORO.DEC.COM>
Address: Santa Clara University
Message-ID: <
[email protected]>
> The "vanilla" RP07 drive's controller knows how to format the media
> both for 32-bit and 36-bit system operation.
Would it be possible for someone (from DEC on this list) to verify this?
We have been told exactly the opposite from our field service folks. They
say the HDA must be removed and mailed back to "who knows where" to a
"special machine" to do the formatting. We were asking them in light
of the acquisition of a VAX and moving the RP07s from our '20 to the
Vax and what that would entail.
Thanx for any info...
Carl Fussell
-------
16-Nov-85 15:52:04-PST,727;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Sat 16 Nov 85 15:51:56-PST
Date: Sat 16 Nov 85 16:50:38-MST
From: Randy Frank <
[email protected]>
Subject: Re: FORMAT
To:
[email protected],
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: <
[email protected]>
Message-ID: <
[email protected]>
We have switched from 16 bit to 18 bit IN THE FIELD with no problems. There
are a few back plane jumpers on the rp07 that need to be changed.
The confusion may be that RA80/81 HDAs need to be factory re-formatted to
switch between 16 and 18 bit mode. RP07s can be easily changed in the field.
-------
17-Nov-85 22:38:11-PST,1122;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Sun 17 Nov 85 22:37:59-PST
Date: Mon 18 Nov 85 00:37:24-CST
From: Clive Dawson <
[email protected]>
Subject: Re: FORMAT
To:
[email protected]
cc:
[email protected],
[email protected]
In-Reply-To: Message from "Carl Fussell <
[email protected]>" of Sat 16 Nov 85 15:34:21-CST
I too asked our field service people to verify Tom's comment about
RP07's being able to format themselves and they denied that this
was possible. But it is certainly NOT the case that the HDA needs
to be removed and sent somewhere! One of the standard KLAD diagnostics
(forget which) was capable of formatting an RP07 which had just been
moved to our 20 from a VAX. As Randy mentioned, a few jumpers which
control interleaving needed to be changed since the bus speeds are different.
Now fortunately I've never had occasion to move an RP07 FROM a 20 TO a VAX.
However if you tell me that a VAX is not capable of doing the formatting
job in reverse, I'll believe it (but please excuse my chuckles!)
Clive
-------
18-Nov-85 13:32:31-PST,683;000000000000
Return-Path: <@rand-unix.ARPA:guyton%
[email protected]>
Received: from rand-unix.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Nov 85 13:32:15-PST
Return-Path: <guyton@condor>
Received: from condor.arpa (condor) by rand-unix.ARPA; Mon, 18 Nov 85 13:26:59 pst
Received: by condor.arpa; Mon, 18 Nov 85 13:25:33 pst
Message-Id: <
[email protected]>
To: tops-20@score
Cc:
[email protected]
Subject: tar for twenex?
Date: 18 Nov 85 13:25:28 PST (Mon)
From: guyton%
[email protected]
I seem to remember someone doing a TAR for twenex
a few years back. Anyone got a copy they can
ship me? Thanks.
-- Jim
p.s. please mail to me, I'm not on this list.
18-Nov-85 13:39:19-PST,3740;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 18 Nov 85 13:38:57-PST
Received: ID <
[email protected]>; Mon 18 Nov 85 16:38:23-EST
Date: Mon 18 Nov 85 16:38:18-EST
From:
[email protected]
Subject: ["Frank J. Wancho" <
[email protected]>: [W8SDZ: Tops-20 poor handling of TCP connections]]
To:
[email protected]
Message-ID: <
[email protected]>
Does anyone have any experience with or explanation for this behavior? The
message seems to indicate that this is a problem with TOPS-20 TCP in general
and not just FTP in particular.
--Vince
---------------
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by C.CS.CMU.EDU with TCP; Sun 17 Nov 85 12:41:07-EST
Date: Sun, 17 Nov 1985 10:41 MST
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: VAF@CMU-CS-C
Subject: [W8SDZ: Tops-20 poor handling of TCP connections]
Vince,
I just double-checked, and T.BFSB is 1200, not 10000, so that is not
the problem this time. Any comments to Keith, Mark, myself, and the
author of the included message would be appreciated.
--Frank
--------------------
Date: Sunday, 17 November 1985 08:02-MST
From: Keith Petersen <W8SDZ>
Sender: KPETERSEN
To: WANCHO, MRC
cc: W8SDZ
Re: Tops-20 poor handling of TCP connections
I have had several complaints recently about SIMTEL20 timing out on
long FTP file transfers. While the message below explains that the
main problem is at sdcsvax (because of their 2400 bps connection), it
does point out "a well-known" problem with Tops-20. This has directly
affected military users of our system. One in particular is an Army
Communications officer in Germany who is legitimately trying to
transfer files for his work assignment. His host has a 9600 bps
network connection. Frequently FTP times out on transfers of long
files.
I personally have had similar problems with our FTP when connected
across the Milnet<-->Arpanet gateway to a host on the Arpa side. It
stops about half way through the transfer and just hangs there. I
have to ^C out of it and start a new FTP.
--Keith
Date: Sunday, 17 November 1985 07:07-MST
From: brian at sdcsvax.arpa (Brian Kantor)
To: w8sdz
Currently the only way I can get files larger than about 10K or so
from SIMTEL is to log onto a more-directly-connected host (i.e., one
with their own IMP) and transfer the file there. I can then compress
it with the Lempel-Ziv squeezer and then use Unix's RCP (remote copy)
command to move it to our system.
There is a problem in that TOPS-20 doesn't handle slow tcp connections
well, and often times out. At 1200 baud, we lose continuously. At
9600 baud, all goes well unless several connections are multiplexing
on the link. At our current 2400 baud, things go well until any other
connection opens. Since sdcsvax is the main campus gateway for mail,
and we handle an average of some 1500 messages a day, the probability
of the link being idle is small. Thus many ftp transfers START ok,
but then just sort of wimper out - they just get idle as far as the
user can tell on this end. Kill it and restart it, and it will dies
somewhere else.
We don't have that problem with Berkeley Unix systems. Evidently
their timing parameters are different. I'm told that this TOPS-20
system problem is well known, and maybe even someday somebody will fix
it.
Brian Kantor UCSD Office of Academic Computing
Network Services Group (619) 452-6865
UCSD B-028, La Jolla, CA 92093
decvax\
[email protected]
akgua >--- sdcsvax --- brian
ucbvax/ Kantor@Nosc
-------
18-Nov-85 15:48:46-PST,511;000000000000
Return-Path: <
[email protected]>
Received: from USC-ECL.ARPA by SU-SCORE.ARPA with TCP; Mon 18 Nov 85 15:48:34-PST
Date: Mon 18 Nov 85 15:46:19-PST
From: Bruce Tanner <
[email protected]>
Subject: Tops-20 ADA?
To:
[email protected]
Message-ID: <
[email protected]>
Someone in our CS Dept. wants to start teaching ADA. Are there any
Tops-20 ADA implementations being sold (or given away)? If so, I'd
like to know who and how much it costs.
Thanks,
-Bruce
-------
19-Nov-85 15:36:05-PST,1361;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Tue 19 Nov 85 15:35:51-PST
Date: 19 Nov 1985 18:33-EST
Sender:
[email protected]
Subject: Re: b.d.
From:
[email protected]
To:
[email protected]
Cc:
[email protected]
Message-ID: <[BBNA.ARPA]19-Nov-85 18:33:50.CLYNN>
In-Reply-To: The message of Wed 13 Nov 85 17:18:18-PST from
[email protected]
ALan,
I think that the routing cache timeout that you mentioned is
NETHT0[ 6,,673500 $10r;1800000. (i.e., 30 minutes in the file
AN-MONLND.EXE.1;P777700 418 214016(36) 8-Sep-84 17:27:25 PAETZOLD ).
Note that all routes are simultaneously flushed when the timer expires.
Flushing a route can cause problems on hosts with interfaces on more
than one network due to the "try a random gateway" algorithm. It
causes a transient as the routes are reestablished. Increasing the
interval reduces the transients while reducing the probability that
a failed gateway will be detected either in time to preserve an
active connection or to force selection by the host of an alternate
route. Decreasing the interval increases the changes for a "quick"
recovery from a failed gateway. (Note that setting the timer, NETHTM,
to zero, e.g., via MDDT, will flush the routes; there probably ought
to be an IPOPR% function to do it...)
Charlie
20-Nov-85 11:47:30-PST,660;000000000001
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Wed 20 Nov 85 11:47:17-PST
Date: Wed 20 Nov 85 11:46:30-PST
From: Bob Knight <
[email protected]>
Subject: R 6.1 bug
To:
[email protected]
Message-ID: <
[email protected]>
Symptom:
Strange crashes (ILMNRF) and BUGCHKs (DIRFDB) that appear to be disk-related.
No data in the dumps makes much sense when correlated against disk activity.
Cause:
TCP "push"es cause jump into disk code in section 1 instead of push code in
section 6.
Cure:
In TCPJFN, at DTCPSH+3 or so, replace CALL TCSQO1 with CALLX (XCDSEC,TCSQO1)
-------
21-Nov-85 08:55:11-PST,454;000000000001
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Nov 85 08:54:53-PST
Date: Thu 21 Nov 85 08:53:29-PST
From: Bob Knight <
[email protected]>
Subject: ILMNRF bug
To:
[email protected]
Message-ID: <
[email protected]>
Symptom:
Expunging a long file sometimes causes ILMNRF BUGHLT
Cause:
Superfluous HRRZ A,FILOFN(JFN) at DELFI6-2
Cure:
Remove said instruction
-------
21-Nov-85 09:00:34-PST,401;000000000000
Return-Path: <
[email protected]>
Received: from SRI-NIC.ARPA by SU-SCORE.ARPA with TCP; Thu 21 Nov 85 09:00:20-PST
Date: Thu 21 Nov 85 08:58:59-PST
From: Bob Knight <
[email protected]>
Subject: Previous message
To:
[email protected]
Message-ID: <
[email protected]>
Sorry, forgot to mention that the patch applies only to Release 6.1 of the
monitor.
Bob
-------
22-Nov-85 16:12:23-PST,561;000000000000
Mail-From: BILLW created at 22-Nov-85 16:12:18
Date: Fri 22 Nov 85 16:12:18-PST
From: William "Chops" Westfield <
[email protected]>
Subject: new emacs
To:
[email protected]
Message-ID: <
[email protected]>
A new version of TECTRM.MID is available from Score and Sushi.
This version provides a workaround in the SUN terminal type
for a bug in the SUNWindows terminal emulation.
Because of the way EMACS uses absolute version number, each
site must essentially build their own set of TECO based programs.
BilLW
-------
25-Nov-85 16:35:16-PST,1646;000000000000
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Mon 25 Nov 85 16:34:47-PST
Date: 25 Nov 1985 1931-EST
From: Tom Blinn <
[email protected]>
To: Carl Fussell <
[email protected]>,
[email protected]
cc:
[email protected],
[email protected]
Subject: Re: FORMAT
Message-ID: <"MS11(2502)+GLXLIB5(0)" 12162176592.12.275.30292 at MARLBORO.DEC.COM>
References: Message from Carl Fussell <
[email protected]>
of 16-Nov-85 1708-EST
In-reply-to: <
[email protected]>
Carl,
I assume you want someone else from DEC, besides myself, to verify that
the vanilla RP07 contains the smarts to format its own HDA for either
36-bit or 32-bit operation.
It is true that the RA series disks can not be reformatted in the field.
However, the RP series (other than the RP20, a special case) can be, and
in the case of the RP07, the reformatting operation is done by the disk
controller, without host intervention.
While I was still a customer (at Bankers Trust) we purchased some RP07
drives at a "special sale price" for use on the -20s, and they came with
32-bit formatting (since they were being sold for "VAX" use). Our Field
Service people had no problem reading and following the documentation to
get the drives to reformat themselves. It is probably documented in the
RP07 User's Guide; if I had a copy, I'd check. I believe copies were sent
to you along with the drives, although Field Service may not have given
them to you. Similarly, the RP07 can reformat its media for use on a VAX.
Regards,
Tom
--------
25-Nov-85 20:38:20-PST,576;000000000000
Return-Path: <
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Mon 25 Nov 85 20:38:10-PST
Date: 25 Nov 1985 20:37-PST
Sender:
[email protected]
Subject: Account file auditing software?
From: the tty of Geoffrey S. Goodfellow <
[email protected]>
To:
[email protected]
Message-ID: <[SRI-CSL.ARPA]25-Nov-85 20:37:48.GEOFF>
Any have a user affectionate program which allows you to audit
your accounting file and do things like find out all the
Login's/Logout's for user FOO between Date X and Y or all
logins/outs on terminal X?
g
25-Nov-85 21:06:51-PST,739;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 25 Nov 85 21:06:41-PST
Received: ID <
[email protected]>; Tue 26 Nov 85 00:06:06-EST
Date: Tue 26 Nov 85 00:06:05-EST
From:
[email protected]
Subject: Re: Account file auditing software?
To:
[email protected]
cc:
[email protected]
In-Reply-To: <[SRI-CSL.ARPA]25-Nov-85 20:37:48.GEOFF>
Message-ID: <
[email protected]>
I have a small program which reads the <ACCOUNTS>SYSTEM-DATA.BIN file and
allows searching for any account record by user during some data period. I
will put the source in PS:<VAF.DIST>RDUSG.MAC as soon as it is retrieved
from migration tapes, if anyone is interested.
--Vince
-------
29-Nov-85 02:44:16-PST,1202;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Nov 85 02:44:07-PST
Date: Fri 29 Nov 85 03:43:56-MST
From: Mark Crispin <
[email protected]>
Subject: 2929 dialout question
To:
[email protected]
Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Telephone: +1 (415) 968-1052
Message-ID: <
[email protected]>
Folks -
I have been trying to get dialout to work on my 2020 with less than
complete success. Specifically, I have an MTOPR% which ends up calling
the following routine (line number in T2):
JE TTFEM,(T2),R ;RETURN IF NO DATASET
SAVET
CALL GETEXA ;GET EXTERNAL ADDRESS
BSIOB T1,DZLPR(T2) ;SET LINE ENABLE
BSIOB T1,DZDTR(T3) ;SET DTR
RET
The problem is that I can raise DTR by calling this routine (the
light on the modem lights), and I can send to the modem, but I don't see
any response back from the modem from my dialing commands. I can dial,
and once a remote modem is dialed two-way communication starts, but it
is annoying to have to dial blind.
I can only assume that something is checking for carrier being down
and ignoring data if so. Any ideas?
-------
29-Nov-85 09:57:45-PST,1402;000000000001
Return-Path: <
[email protected]>
Received: from MARLBORO.DEC.COM by SU-SCORE.ARPA with TCP; Fri 29 Nov 85 09:57:34-PST
Date: 29 Nov 1985 1255-EST
From: Tom Blinn <
[email protected]>
To: Mark Crispin <
[email protected]>,
[email protected]
Subject: Re: 2929 dialout question
Message-ID: <"MS11(2502)+GLXLIB5(0)" 12163153047.14.275.9679 at MARLBORO.DEC.COM>
References: Message from Mark Crispin <
[email protected]>
of 29-Nov-85 0548-EST
In-reply-to: <
[email protected]>
If you have a "blue box", stick it between the 2020's DZ port and the modem
and make sure data is getting out to the modem. (Symptom -- flashing lights
on the TXD line, if bits are getting asserted.) If so, then it is not a
problem with the DZ11 suppressing data to the modem when you don't have
carrier.
If you are getting data transmitted to the modem, then it is probably a
problem with the character sequence you are sending to the modem. If you
are using the sequence for a DF03 modem, but in fact have a DF112 or some
other modem, that would probably explain the problem. I know for sure that
the DF112 does NOT respond in any useful way to the DF03 dial sequences.
Have you tried using the modem with a "dumb" terminal, such as a VT100? If
you can get it to work in that mode, you ought to be able to get it to work
with the 2020.
Tom
--------
29-Nov-85 13:14:17-PST,1201;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Fri 29 Nov 85 13:14:08-PST
Date: Fri 29 Nov 85 14:13:56-MST
From: Mark Crispin <
[email protected]>
Subject: 2020 dialout solved
To:
[email protected]
Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Telephone: +1 (415) 968-1052
Message-ID: <
[email protected]>
I found out what my problem was. I am using DEC DF112 modems, which
can run at 300 or 1200 baud. One of the dip switch options controls whether
the modem will operate in dual speed or at high speed only. Since 2020's
can't autobaud, I set the dip switch to high speed only. It seems that an
undocumented side effect of setting the switch to high speed only is that
the dialer will NOT send any text back to the terminal.
I also discovered to my great dismay that the dialer on the DF112
is quite happy to talk to you whether or not DTR is asserted! If you dial
with DTR dropped, it will place the call, and as soon as the call is answered
it'll hang up.
I consider these behaviors to be design flaws in the DF112; does anybody
have any idea why it should be this way?
-------
1-Dec-85 00:23:22-PST,1142;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sun 1 Dec 85 00:23:09-PST
Date: Sun, 1 Dec 1985 01:22 MST
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: Catch-22 - Penril Datalink 2400
I have a couple of the subject modems as part of a much larger batch
for which I have eagerly volunteered to help acceptance test. My
problem is that I have yet to find the right combination of setup
options so that it will reliably answer a call and subsequently hang
up when the DEC drops DTR. (It will answer the first call if DTR is
set TRUE. But, of course, it will not hang up to be available for
subsequent calls.)
All I have done is plugged the unit in in place of an existing and
working Racal-Vadic 3451. In other words, I have made no changes to
the cable/pin configuration.
If you have experience with these modems connected to your front-end
ports, please send me a readout of your setup options, RS-232 pin
configuration on each end of the cable, and any pin jumpers.
Thanks,
Frank
3-Dec-85 14:49:53-PST,1236;000000000000
Mail-From: BILLW created at 3-Dec-85 14:49:50
Date: Tue 3 Dec 85 14:49:50-PST
From: William "Chops" Westfield <
[email protected]>
Subject: TCP FTPSER improvements
To:
[email protected]
cc:
[email protected],
[email protected]
Message-ID: <
[email protected]>
As I have improved the dec20 TCP code, I have run into new
bottlenecks. In particular, the tops20 FTP server program
goes to sleep for a full second in between checks for input
or output data, which is much too unfrequent on a fast net.
Ideally, FTPSRT/FTPSER should use CHANL% or something so
that it wakes up as soon as a buffer is filled. I tried
this but couldn't get it to work, but I did improve things
quite a bit by changing the sleep time to 1/8 second.
The relevant file is SCORE:<SYSTEM>FTPSER.EXE, and
SCORE: <BILLW.FTP.CMU>TCPSIM.MAC. (yeah, the CMU user FTP
ought to benifit from this too). <BILLW.FTP.CMU>FTPSRT.MAC
also contains the (unworking) CHANL% code, if someone else
wants to play with it. Changes are in STANSW, but STANSW
in FTPSRT is forced to 0, since the code isn't working.
Ive actually achieved SUSHI(FTPSER) ==> SCORE(SU-FTP) transfer
rates of over 150 Kbps... Oh wow.
BillW
-------
5-Dec-85 06:49:35-PST,769;000000000000
Return-Path: <
[email protected]>
Received: from RADC-TOPS20.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 06:49:27-PST
Date: Thu 5 Dec 85 09:46:45-EST
From: Donna Lynch <
[email protected]>
Subject: flow control
To:
[email protected]
cc:
[email protected]
Message-ID: <
[email protected]>
Is there a way to set flow control on input? I have a user
who is using a micro (HZ100) as a terminal. When sending a
file from the floppy to a file on the 20, it continually beeps.
I assume the 20's buffers are filling up, but the micro is not
being told to stop. Is there anything from the 20's side that
can be done?
I am told that the procedure he is using does work on other
systems, ie. MULTICS.
--Donna
-------
5-Dec-85 10:55:35-PST,619;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 10:55:21-PST
Date: Thu 5 Dec 85 11:56:16-MST
From: Walt <
[email protected]>
Subject: Re: flow control
To:
[email protected],
[email protected]
Message-ID: <
[email protected]>
TOPS-20 terminal input has serious design problems in this area.
In the process of implementing X.25 for TOPS-20 I documented the
problem and worked up the fix. For a description FTP file
PS:<ANONYMOUS>HOW.LPT from UTAH-20. Log in with username
ANONYMOUS and password GUEST.
Cheers -- Walt
-------
5-Dec-85 12:22:56-PST,789;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 12:22:45-PST
Date: Thu 5 Dec 85 13:25:04-MST
From: Mark Crispin <
[email protected]>
Subject: Re: flow control
To:
[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]>
TOPS-20 sends XOFF characters when the input buffer for that line is
in danger of filling up. The transmitter is expected to cease and
desist transmitting PROMPTLY until TOPS-20 sends an XON.
I recommend using a program such as Kermit which has more sophisticated
flow control, and error correction to boot.
-------
5-Dec-85 16:18:38-PST,16518;000000000000
Return-Path: <
[email protected]>
Received: from BBNA.ARPA by SU-SCORE.ARPA with TCP; Thu 5 Dec 85 16:18:11-PST
Date: 5 Dec 1985 19:20-EST
Sender:
[email protected]
Subject: Re: ["Frank J. Wancho" <
[email protected]>: [W8SDZ: Tops-...
From:
[email protected]
To:
[email protected]
Cc:
[email protected],
[email protected],
[email protected]
Cc:
[email protected],
[email protected]
Message-ID: <[BBNA.ARPA] 5-Dec-85 19:20:00.CLYNN>
In-Reply-To: <
[email protected]>
nA few comments concerning: host xxx "timing out on long file
transfers", a transfer across "the Milnet<-->Arpanet gateway" ...
"just hangs", and "TOPS-20 doesn't handle slow tcp connections".
First, these phrases are probably not describing a single problem.
One unambiguous symptom is a connection timing out; but "hanging"
could mean two things: that the connection is in fact hung, i.e., no
data is flowing; or that the data is flowing, but very slowly. Users
may not have available, or be familiar with, the tools needed to
distinguish the latter two cases, so might describe both as "hung
connections". It is not clear whether the slow connection problem is
distinct from the other two symptoms or just another way of phrasing
them.
Second, these problems are not limited to TOPS-20s -- they have also
been observed between two Vax Unix systems (connected by an 1822 net,
where "lost RFNMs" are a factor); and, when separated by a gateway,
between two Suns and between two lisp machines (where fragmentation in
the gateway seems to be a factor). However, I do not think that those
are significant factors for the TOPS-20.
One can examine the symptoms, and even "cure" some of them. Some can
be changed into other symptoms (which may be more, or less, visible).
For example,
1. A TOPS-20 connection times out when:
a. the user (application program) has enabled a timeout (by not
explicitly disabling it),
AND
b. the user (application program) has not indicated that it is
capable of performing recovery actions (by enabling the timeout
interrupt),
AND
c. a packet (which contains send-left) has not been acknowledged
within the specified timeout interval.
By changing any of the three clauses, connection timing out can be
"cured" (but probably changed into a "hung connection"). Changes to
user and server FTP can alter a) or b); but that will not help other
applications such as mail (but messages are usually short) or telnet
(many packets). Finding the "best" overall solution to the problem
thus leads to understanding/attacking c). But first consider the
other symptoms.
2. Connections may become hung (no data flow) in a few ways:
a. the path between the two ends becomes broken, either through a
hardware problem, OR a gateway failure (without alternate routing),
OR <one of the ends crashes AND the connection is in a state where
the breakage wouldn't be noticed>,
OR
b. there are bugs related to window management,
OR
c. the send window is "full" and the sender is not being informed when
it opens,
POSSIBLY BECAUSE
d. the receiving host is not getting packets into the net (network
flow control error) (note that such packets do not contain anything
which requires acknowledgement - otherwise they would probably
cause a timeout).
Case a) can usually be quickly eliminated: if a new connection can be
created the path is probably not broken (although the possibility of a
subtle routing problem cannot be totally ignored). Cases b) and c)
are easily checked using, for example, the TOPS-20 TSTATS program to
observe a connection's send and receive windows. Case d) is also a
possibility, but not as easy (for a TOPS-20 user) to check. I do not
think that the problem is any of 2) -- at least until some hard
evidence indicates otherwise. There is much more evidence for
slowness.
3. Slow transfer of data may be due to:
a. a low bandwidth path (or a path with higher bandwidth which is
being "fully consumed"),
OR
b. slowness of the user (application program) at one or both ends,
OR
c. network flow control,
OR
d. (excessive) packet loss (which may be exasperated by failure to
retransmit data in a timely manner).
Again, users would usually know if either a) or b) were a significant
factor in their environment. In case c), the TOPS-20 TCP does not
usually inform the user of network flow control restraints; but it does
seem to be a contributing factor, in a roundabout way. Digressing ...
Specifically, the delay between the time that TCP/IP places a
packet into the output queue for a network and the time that the
packet has been accepted by the network has been observed, on
occasion, to be on the order of a few seconds. This seemingly
random queueing delay can cause problems if TCP is using the
submission time in its computation of either the time the packet
should be retransmitted or the round trip delay. Our TOPS20s
record the number of times that the TCP retransmiter tried to
retransmit a packet (here a minimum 1 second interval), and the
number of times that it didn't because the packet was still in the
network output queue; the percentages (now) are 25% of the
attempted retransmissions were suppressed (1.8% of all packets
formed over a period of 31 hours) on one system and 32% (2.9% in
57 hours) and 42% (2.8% in 54 hours) on the other two. Do any
other implementations collect such information? What the numbers
mean is debatable, maybe only that the queueing delay is in the
same range as the usual round trip time. What about the cases
where the packet just made it out before the timer went off (think
about this when you get to 4g) below). End of digression ...
On the TOPS-20, case 3d) frequently leads to case 1.
Most of the evidence I have seen indicates that the basic problem on
the TOPS-20 involves both parts of 3d). It is easier for a TOPS-20
site to confront the second part, failure to retransmit in a timely
manner, since it is a "local matter" which can be changed, while the
first part, excessive packet loss, is a more global problem requiring
work and cooperation by several groups.
4. Excessive packet loss may occur through several mechanisms:
a. excessive error rates on a network link or between the network
and a host/gateway,
OR
b. inability of a host/gateway to accept packets at the rate they
are being made available by a network,
(a question for those familiar with ethernet or other network
interfaces: are there any statistics kept (by the hardware)
that indicate how many packets for the host were lost because
the interface/host was not prepared to accept them?)
OR
c. gateways which cannot support the steady-state load,
POSSIBLY BECAUSE OF/OR
d. bandwidth mismatch at a gateway,
OR
e. insufficient buffering in a gateway/host to support the transient
load,
POSSIBLY BECAUSE OF/OR
f. hosts generating "bursts of packets" instead of "spreading them out"
(aka "bang-bang" mode),
OR
g. hosts sending many more packets than are "necessary" (e.g., two acks
per received packet [one to ack data, one to increase the window], not
combining [data] acks, "too many" retransmissions ["bad" combination
of queueing delays, the "smoothed round trip time", and/or "beta"],
retransmitting "too much" [i.e., retransmitting all {many packets of}
unacknowledged data when the retransmission timer goes off -- leading
back to 4e)], probing "too frequently").
Use of large TCP windows (e.g., in FTP) can lead to instances of 4f)
(there was a message a while back about increasing FTP buffer
sizes to obtain higher throughput actually causing poorer
performance -- 4f) leading to 4e) and then to 3d) [and maybe even
to 1)] is probably the reason).
I think that the area where the most leverage can be applied is to the
failure by TOPS-20 to retransmit in a "timely" manner. There are two
basic reasons why a packet might not be "promptly" acked: the packet
was lost, or the packet was delayed. If lost, the packet must be
retransmitted, but the retransmission variables probably should not be
changed very much (if at all). If delayed, the packet should not be
retransmitted and the round trip estimate should probably be increased
a little. As has often been noted, given the current TCP protocol,
there is no way for a host, by itself, to determine what is happening
from the acks that it receives and to do the "right thing" in all
cases.
[But I think that things could be improved through additional
guidelines for use of TCP header fields and even use of the "not
always significant" bits in the TCP header.]
5. Failure by TOPS-20 to retransmit in a "timely" manner is basically
due to the smoothed round trip time estimate growing
"unreasonably" large, for several reasons:
a. The measurement of round trip time is biased toward packet delay
instead of packet loss (which was valid back when the algorithm
was developed, but is no longer valid),
AND
b. retransmitted packets were included in the estimate of round trip
time (in a weighted manner), but there is a
CATCH
c. the measured round trip time (given initial packet loss) included
beta times the smoothed round trip time -- during which nothing was
happening -- introducing positive feedback which tends to make the
estimated round trip time grow until it reaches some upper bound.
Not using retransmitted packets in the estimate of round trip time
is not sufficient, however, because there is
ANOTHER CATCH
d. if multiple packets (say 1 to 5) were originally sent and one or
more were lost (say 3), any packets (following the lost ones)
which made it to the other end (4 and 5) cannot be acked until the
lost packets (3) are retransmitted. If only some of the packets
are retransmitted (3, maybe 4, but not 5), then not only should
the retransmitted packets be ignored, but also all those that were
sent before the retransmitted packets were acked (5, maybe 4)
since their measured round trip time will include (possibly multiple)
beta times the smoothed round trip time intervals during which
nothing was happening.
e. The round trip time smoothing described in the TCP spec is not
"symmetric". A single large ("bad") measured round trip time
causes the smoothed estimate to grow by a larger absolute value
than a single small ("good") measured value will cause the
smoothed estimate to grow smaller. If packets are infrequently
lost, there are many good samples between the bad so the smoothed
value behaves well. When the number of good and bad samples are
about the same, the smoothed value tends to grow (especially given
the positive feedback of 5c) and d)). Dave Mills has suggested
two "alpha"s, one for samples larger than the estimate and another
for samples smaller than the estimate; it is hard to determine
experimentally how well they are working.
f. As the retransmission interval grows, there are fewer and fewer
chances for a packet to get through before the retransmission
timeout is reached -- if the timeout (less than TCPPTM sec) is
five minutes and the upper bound on the retransmission interval
(TCPRXX msec) is a minute, there are at most 5 retransmissions.
Empirical evidence (timedout connections) suggests that loss of
all transmissions is frequently happening.
5c), d), and e) thus all tend to make the smoothed round trip time
grow when it "shouldn't". The net effect when packets are being lost
is that throughput drops to something on the order of one window per
retransmission interval -- which would probably be called a "hung
connection".
(There are a few assumptions here: 1) the window is big enough to
generate (a burst of) several packets, 2) one of those packets is
lost, 3) the other packets get through and are held until the lost
packet is retransmitted. Things may be worse if several packets
have to be retransmitted or out of sequence packets are discarded.)
When in the "hung" state, the effect of 5f) is to increase the
probability that the connection will timeout.
Several things can be done to improve the situation; there are even a
few that can be done by a (determined) user (at least while we are
fixing the problem).
Probably the most effective fix, for most situations, is to not use
the retransmitted packets (or questionable ones) in the round trip
time computation; packets which look like they were victims of
queueing delays could also be ignored. This may cause excessive
retransmissions on low bandwidth connections (if the initial estimate
is lower than the time required to get a packet acked, there will
"never" be any good samples to update the estimate), but that is not
"highly visible" to anyone who doesn't go looking for trouble or
doesn't have to pay by the packet. I have written (and BBN gave to
DEC back in '84) code to do it, but it can still use some more work.
A quick fix would be to add code at REMSE5 (if you have the same
source) to jump to REMSE6 if PRXD,(PKT) is set; that would still
include the questionable packets, however. They can be identified by
keeping a counter per connection, or flag per packet, or even the
TODCLK when the last retransmitted packet was acked, but they are not
simple patches as they need additional flag bits in the packet or
another variable in the TCB. A stack flag to indicate "no more
estimates" is probably patchable and would help for any questionable
packets which were also acked with the retransmitted packet (and if
the receiver is combining acks).
The administrator could also choose to reduce TCPRXX, the maximum time
between retransmissions (I think the DEC distribution uses 1 minute).
Even at 300 baud, a kilobyte only needs about 25 seconds (one way) so
setting it in the 10 to 20 second range may not be unreasonable; once
again, it may generate excessive retransmissions in some cases.
Our current code has the notion of a maximum baud rate -- packets
are generated in time separated by an interval appropriate for the
packet size and baud rate -- but it is only setable by the SET
TERMINAL SPEED function. Adding another TCOPR function would be
easy.
One can also choose to use the "old" retransmission algorithm in a
constant retransmission rate mode.
Backoff seems to be a nice idea, but it can give poor performance
when only a few are using it -- at least until the gateways get
smarter. For now, the more copies of a packet you send the greater
your chances of getting it through.
The DEC TCOPR persist function could be used to set the retransmission
rate (the ;persist attribute code has a bug in it) but I do not think
that it is used (unless you have made local modifications). The BBN
interface OPEN will use the retransmission parameters -- T3/ 1001,,n
will cause a packet to be retransmitted every n seconds. A user can
easily GET SYS:FTP and patch the OPEN call with an appropriate value.
Digressing again... This raises another issue: allowing the user
to specify parameters. While doing so may be contrary to the
internet design philosophy which promotes the idea that the hosts
don't need to know about the underlying networks and neither do
the users, a user frequently does have some idea of what to expect
in a given environment. Application writers could make things
easier for a user by allowing the user to specify parameters
(instead of patching the application); this assumes, of course,
that the network implementor has made them available to the
application writer. The transmission timeout and retransmission
parameters are obvious candidates; I have even found specifying a
source route helpful to get around Arpanet <-> Milnet problems.
Of course, such capabilities could be abused. ...End digression.
The system administrator could similarly patch the server with a
"reasonable" value.
6-Dec-85 15:10:39-PST,1186;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from Cs (CS.UCL.AC.UK.#Internet) by SU-SCORE.ARPA with TCP; Fri 6 Dec 85 15:10:20-PST
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a002423; 5 Dec 85 16:44 GMT
Via: DCT; by DUNDEE on Thursday, 5-Dec-85 16:39:31-GMT
Date: Thu 5 Dec 85 16:34:57-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: Re: flow control
To:
[email protected],
[email protected]
cc: CCD-ARG%
[email protected]
In-Reply-To: Message from "Donna Lynch <
[email protected]>" of Thu 5 Dec 85 16:09:13-GMT
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Tops-20 should be sending xoff to the micro if its input buffer gets
near to overflowing. Does the micro stop sending when it gets an
xoff ? What protocol (if any) are you using. Are you just sending
blind to an editor input. Not very reliable ! I would suggest that
kermit is used to transfer files between any two machines. It makes
things much simpler and its available for the dec20 and (I think) the
hz100 and its free.
Alan
-------
10-Dec-85 07:59:27-PST,2128;000000000000
Return-Path: <Alan%DCT.AC.UK%
[email protected]>
Received: from Cs (CS.UCL.AC.UK.#Internet) by SU-SCORE.ARPA with TCP; Tue 10 Dec 85 07:59:01-PST
Received: from dundee.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000585; 9 Dec 85 20:59 GMT
Via: DCT; by DUNDEE on Monday, 9-Dec-85 20:58:32-GMT
Date: Mon 9 Dec 85 20:54:06-GMT
From: Alan Greig <CCD-ARG%
[email protected]>
Subject: More on TOPS20 autobaud
To:
[email protected]
cc: alan%
[email protected]
Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland
Sender: Alan%
[email protected]
Ok, I can now stop SETSPD being run every few seconds by just skipping
the EMT instruction requesting setspd which means that we get full range
autobaud but that tops-20 doesn't get the correct line speed. We can live
with that but it would be neater if I could get the speed across some
other way. The best way to do this would probably be to to do a to-10
with function set speed. This has the disadvantage that I know virtually
nothing of RSX20-F and only have disassembled code to work from. Users
would not put up with constantly being detached whilst I try to learn it !
I also doubt that I have enough room to patch the code in. So this is
what I'd like to do. Just send the two bytes indicating the line speed
to the KL as if they were 2 characters typed at the terminal. Then
in TTYSRV on the 20 when starting a job instead of checking for CR,LF
or CTRL/C take the first 2 bytes on an autobaud line, decode them
and set the speed and remove the call to .STTYD in $DHINP. I have
the KL code running but don't know exactly where to call in the 11
to send the characters.
So the question is any RSX20-F expert out there willing to point me
in the right direction.
I also have a vague recollection that some time in the last few years,
DEC sent out an assembler listing of the front end source code on
some tape or other. Am I imagining this ? Even having an old commented
listing would help. If anybody knows what tape that was on I can go
and look for it.
Alan
-------
12-Dec-85 18:31:17-PST,583;000000000000
Return-Path: <
[email protected]>
Received: from SRI-KL.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Dec 85 18:31:08-PST
Date: Thu, 12 Dec 85 15:56 PST
From: Ken Olum <KDO@SRI-KL>
Subject: New Chaosnet mail-server
To: tops-20@score
Message-ID: <851212155650.5.KDO@BEETLE>
For anyone that runs CHAOSNET -- I have almost completely rewritten the
chaosnet mailserver to use MM's HSTNAM and RELAY modules instead of reading
HOSTS2, so it is compatible with domains and such cruft. The new source is
(or shortly will be) available by FTP from {SRI-KL}PS:<KDO>MAISER.MAC
Ken
12-Dec-85 19:09:25-PST,1638;000000000001
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Dec 85 19:09:12-PST
Date: Thu 12 Dec 85 20:10:52-MST
From: Randy Frank <
[email protected]>
Subject: confusion reigns...
To:
[email protected]
Message-ID: <
[email protected]>
Anyone want to take a stab at this situation?
In virtually all of our recent crashes, the apparent (console) reason for
the crash is a KEEP ALIVE FAILURE. (Release 6.1 FT6)
However, when one looks at the dump, in all cases BUGHLT/ is non-zero. My
understanding is that the only way that BUGHLT can be non-zero is if the
monitor has attempted to BUGHLT. (Correct?). However, even stranger, is
that sometimes BUGACS are zero, and other times they look like a true
BUGHLT has taken place.
Even stranger, looking at the 20F collected error packet at the time of
the KEEP ALIVE FAILURE, the PC that the front-end thinks the KL was at
at the time of the failure has nothing to do with any BUGHLT code, so the
notion that a KEEP ALIVE occurred during BUGHLT processing doesn't seem
to hold water. (The KEEP ALIVE PC address is not, however, credible in terms
of a place where a keep alive could likely occur, short of a hardware
failure).
In many dumps (but not all) the current fork is INTFRK. However, the potential
BUGHLTs are all over the place (ILLUUO, ILMNRF, MONPDL) and the dumps seem
to have virtually nothing in common aside from the console KEEP ALIVE message.
We are running the most recent TCP changes from Stanford. Anyone who can shed
any light on this KEEP ALIVE vs. BUGHLT mystery?
-------
12-Dec-85 19:40:02-PST,923;000000000000
Return-Path: <
[email protected]>
Received: from UTAH-20.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Dec 85 19:39:53-PST
Date: Thu 12 Dec 85 20:15:56-MST
From: Randy Frank <
[email protected]>
Subject: uVax Ultrix 1.2 vs. DEC-20 TCP
To:
[email protected]
Message-ID: <
[email protected]>
Does anyone out there has uVaxen running Ultrix release 1.2 (or 1.1) talking
over an Ethernet to a DEC-20. We have several, and they don't seem to be able
to talk to the 20 on the same Ethernet (unable to open connections). However,
they seem to have no problems talking to 20s gatewayed to the Ethernet (e.g.,
other Internet hosts). The gateway is a VAX running 4.2. Our theory is that
it isn't a TCP problem, but a lower level Ethernet or ARP problem. I'm just
wondering if anyone else has seen this or if they are sucessfully talking
between uVaxen and their DEC-20 on the same Ethernet.
-------
12-Dec-85 21:32:03-PST,1111;000000000000
Return-Path: <
[email protected]>
Received: from SRI-CSL.ARPA by SU-SCORE.ARPA with TCP; Thu 12 Dec 85 21:31:54-PST
Date: 12 Dec 1985 19:59-PST
Sender:
[email protected]
Subject: It's Been Real.
From: the tty of Geoffrey S. Goodfellow <
[email protected]>
To:
[email protected]
Message-ID: <[SRI-CSL.ARPA]12-Dec-85 19:59:02.GEOFF>
It is with a good bit of reluctance that I announce my departure from
the ivory walls of SRI on the West Coast in late January. I will be
taking a position in the private sector at the Cellular Radio Corp in
the Washington D.C. area. In my new position, I hope to be able to
influence the ubiquitous and ever burgeoning untethered communication
industry's realization of the paramount importance of security, privacy
and integrity considerations in technology development.
I plan to remain active on the ARPANET through a part-time relationship
with SRI Washington D.C.
I am very proud to have been associated with the considerable cadre of
wonderful people on The Network who brought about the packet switching
and Internet (r)evolution.
g
13-Dec-85 12:01:27-PST,1247;000000000001
Return-Path: <
[email protected]>
Received: from SU-SIERRA.ARPA by SU-SCORE.ARPA with TCP; Fri 13 Dec 85 12:01:09-PST
Date: Fri 13 Dec 85 12:02:56-PST
From: Stu Grossman <
[email protected]>
Subject: Re: confusion reigns...
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Randy Frank <
[email protected]>" of Thu 12 Dec 85 19:49:43-PST
Randy, I think that you have been bitten by one of the command files that
RSX20F invokes under exception conditions. The specific file in your case
is called KPALIV.CMD. It contains a set of PARSER commands which generate
KLERR output (which is text). Unfortunately, one of the commands in there
changes the current AC set to get some info, but it doesn't halt the
processor while doing so.
Can you imagine what would happen to your program if somebody switched all
of your ACs and didn't tell you? That's right, confusion reigns, and
programmers go crazy! The real screw is that the ACs are set back to their
original value shortly afterwards, and as a result, SOME of the crashes
look reasonable.
The cure is to fix the command file to remove the AC block switching commands.
This will make your crashes more palatable.
Stu
-------
14-Dec-85 09:23:22-PST,2351;000000000000
Return-Path: <
[email protected]>
Received: from SIMTEL20.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Dec 85 09:23:12-PST
Date: Sat, 14 Dec 1985 10:24 MST
Message-ID: <
[email protected]>
From: "Frank J. Wancho" <
[email protected]>
To: TOPS-20@SCORE
Subject: Making and copying ANSI tapes
I have, perhaps quite prematurely, made an offer to the Ada community
to make ANSI labelled tapes of our rather large and growing collection
of public domain Ada software. (All the filenames are already within
the prescribed limits and are ASCII files.)
The problem has turned out to be that it takes some three to four
hours (depending on system load) to make a copy using Hedrick's WRITEL
program and two tapes at 1600 bpi, while it takes about 20 minutes to
write a single Unix tar format tape of the same set of files. I
didn't use the EXEC COPY command because I was informed that COPY will
always write one record per block, quickly wasting tape in the
process!
So, next I figured that I'd make a "Master" tape using WRITEL, and
make a "raw" copy using MTACPY. Well, I must have had my wires
crossed somewhere along the way. Bypassing MOUNTR *might* have been
the "right" thing to do, but MTACPY doesn't know how to ask for the
next tape on its own. Even if it did, it would not know how to write
a continuation file on the current tape and set up the header on the
next tape. Besides, this was taking almost as long to copy the tape
as to make the original...
The third try was to use the EXEC COPY anyway to copy the master tape
with MOUNTR in the picture, and the appropriate SET TAPE commands.
Maybe I had a chance this time, I thought. Wrong again. The job
bombed with a "file data error" on the master that MTACPY had earlier
successfully read past. Either COPY does not know how to back up and
try again for error recovery or MTACPY did or ignored the error.
Now I'm stuck. I need help from anyone who has successfully made ANSI
labelled tapes of such a large collection of files with similar
optimum tape packing in a time frame approaching that of writing tar
format tapes. I'll even consider mods to the EXEC to make COPY work
"right" in this case. Likewise, I'm open for help in how to properly
make tape-to-tape copies of ANSI labelled tapes.
Thanks,
Frank
14-Dec-85 12:11:26-PST,1069;000000000000
Return-Path: <
[email protected]>
Received: from WASHINGTON.ARPA by SU-SCORE.ARPA with TCP; Sat 14 Dec 85 12:11:13-PST
Date: Sat 14 Dec 85 12:11:39-PST
From: Bob Albrightson <
[email protected]>
Subject: Re: uVax Ultrix 1.2 vs. DEC-20 TCP
To:
[email protected]
cc:
[email protected]
In-Reply-To: Message from "Randy Frank <
[email protected]>" of Thu 12 Dec 85 20:23:49-PST
That sounds very similar to the problem we are having with the same
config. of uVaxII running ultrix on the same net as a dec-20. I am
able to make connections either way but they are extremely unreliable.
In fact, for any connection the results are precicely reproducable.
For example when the uVax connects to the 20's smtp port, it starts up
ok but when the 20 sends a request to start sending the body of the
message and end with dot (.), the uVax never sees that message and
hence it bombs. There are other problems too, but that is one that I
have looked into more than others.
What type of ethernet controller are you running on your 20?
-bob
-------
15-Dec-85 18:39:42-PST,2148;000000000000
Return-Path: <
[email protected]>
Received: from CU20B.COLUMBIA.EDU by SU-SCORE.ARPA with TCP; Sun 15 Dec 85 18:39:31-PST
Date: Sun 15 Dec 85 21:41:08-EST
From: Charlie C Kim <
[email protected]>
Subject: DEQNAs and KNIs
To:
[email protected]
cc:
[email protected],
[email protected]
Message-ID: <
[email protected]>
For those of you with MicroVaxen and Tops-20 machines.
PROBLEM: Q-Bus Ultrix-32m systems (specifically MicroVax I's &
II's) using the DEQNA will not initiate IP protocols with
TOPS-20 V6.1 systems using an NI.
DIAGNOSIS: TOPS-20 V6.1 sets the incoming ethernet packets size
for the ARP port on the KNI to 60 bytes; this happens to be the
minumum ethernet packet size. For some reason, the DEQNA driver
in Ultrix-32 is forced to set the minimum packet it sends out to
64 bytes. Coincidentally, 64 bytes is the real size of an
ethernet packet: 60 bytes of data + 4 bytes of CRC. In any
event, a TOPS-20 V6.1 system will not accept an ARP packet from
a Ultrix-32 DEQNA host running the standard DEC software.
SOLUTION: Optimally, change the DEQNA driver on the Ultrix-32
host so it sends out 60 byte packets properly. Unfortunately,
the use of 64 octets as a minumum instead of 60 was done for a
reason. Dropping this down to 60 octets in the standard
Ultrix-32 driver results in the following problems: very
sluggish performace and an inability to establish protocols with
certain devices, such as the DECServer-100.
Alternatively or at the same time, modify the ARP port on the
KNI to accept packets in the range 60 to 64. Since the data is
checked for validity (e.g. proper packet type), this should not
present any problems.
In the interim, use the "arp" program provided with Ultrix-32m
to establish the ethernet to internet mappings on the unix host
and set the proper addresses in
system:internet-ethernet-mappings.txt with "/noarp" on the
tops-20 host. This, of course, bypasses, the address resolution
protocol entirely.
Charlie C. Kim
User Services
Center for Computing Activities
Columbia University
-------
16-Dec-85 22:15:44-PST,1061;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Mon 16 Dec 85 22:15:34-PST
Received: ID <
[email protected]>; Tue 17 Dec 85 01:18:12-EST
Date: Tue 17 Dec 85 01:18:12-EST
From:
[email protected]
Subject: Strange MACRO bug
To:
[email protected]
Message-ID: <
[email protected]>
Occaisionally, it seems that MACRO seems to screw up when trying to resolve
certain references. For example, when compiling the monitor module TCPJFN.MAC,
the reference to DISB18 at IPOPDM+7 is, for some reason, left as 0. No error
is given, the value of DISB18 is just given as zero for this reference. The
result is an ILLUUO BUGHLT whenever this IPOPR% function is executed, since
this reference is used to form a scheduler test. Who knows how many other
bad references there are floating around in there... Has anyone seen this
sort of behavior before and can someone suggest a fix, please? It is very hard
to get something working when the assembler refuses to work correctly...
--Vince
-------
20-Dec-85 12:34:26-PST,1582;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Fri 20 Dec 85 12:34:22-PST
Date: Fri 20 Dec 85 11:42:25-PST
From: Mark Crispin <MRC%
[email protected]>
Subject: [Rob Austein <
[email protected]>: Well Known Ports]
To:
[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12168677588.7.MRC@PANDA>
I recently asked about the TOPS-20 domainsolving situation. Here's the
latest word. It isn't pleasant.
---------------
Return-Path: <@SUMEX-AIM:
[email protected]>
Received: from XX.LCS.MIT.EDU by SUMEX-AIM.ARPA with TCP; Fri 20 Dec 85 11:05:52-PST
Date: Fri, 20 Dec 1985 14:05 EST
Message-ID: <
[email protected]>
From: Rob Austein <
[email protected]>
To: Mark Crispin <MRC%
[email protected]>
Cc:
[email protected]
Subject: Well Known Ports
In-reply-to: Msg of 20 Dec 1985 03:30-EST from Mark Crispin <MRC%
[email protected]>
Well, since you ask, although I am not Paul, I can tell you. Losing
my ass is what is currently happening with T20 resolving. Paul's
resolver seems to be overly critical of incoming packets (I think it
is a checksum problem, am investigating). Net result is that MMAILR
is spending about 15 minutes out of every half hour waiting for the
resolver. I will send a more detailed note to both you and Paul
later, since to some extent what I am seeing is a fatal interaction
between JEEVES and MMAILR, but that's the short answer.
--Rob
-------
20-Dec-85 12:40:53-PST,1399;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 20 Dec 85 12:40:40-PST
Received: ID <
[email protected]>; Fri 20 Dec 85 15:43:39-EST
Date: Fri 20 Dec 85 15:43:38-EST
From:
[email protected]
Subject: TTMSG% and REFUSE SYSTEM MESSAGES functionality
To:
[email protected]
Message-ID: <
[email protected]>
Can anyone think of a good reason why this has no effect on messages sent to
a particular line? According to the code, the REFUSE SYSTEM MESSAGES setting
is only obeyed for send-alls. The FTP server refuses system messages in the
hopes of avoiding things such as "[You have mail from...", which are badly
handle by dumb FTP user agents. Also, I dimly remember a special case in the
handling of refused system messages that always allowed the "System going down
in one minute!!!" message to get through, but can find no reference to such
functionality in the code. I'd like to change TTMSG so that it obeys properly
refuses system messages unless some flag ("when it absolutely, positively, has
to be there...") is set in T3. However, the comments at the beginning of TTMSG
would lead one to believe that T3 is used as a magical argument with timeout
when T1 is 0. The code seems to indicate that this option is unimplemented.
Anyone know if it is, or if DEC is planning to implement it?
--Vince
-------
20-Dec-85 21:13:01-PST,1422;000000000000
Return-Path: <
[email protected]>
Received: from C.CS.CMU.EDU by SU-SCORE.ARPA with TCP; Fri 20 Dec 85 21:12:52-PST
Received: ID <
[email protected]>; Sat 21 Dec 85 00:15:51-EST
Date: Sat 21 Dec 85 00:15:49-EST
From:
[email protected]
Subject: Weird MACRO bug solved
To:
[email protected]
Message-ID: <
[email protected]>
Evidentally, this is a bug in MACRO 53.1(1152) that we, and at least a few
other sites are still using. It really had me going for a while, though. I
managed to isolate the bug to a simple test case, but it appeared that the
bug wouldn't occur on SCORE, but would on CMUC even using SCORE's MACRO.EXE
and LINK.EXE. Well, it turns out that the SYS: definition used by SCORE's
ANONYMOUS FTP service and that used by default by logged-in users are not
the same, so the version of MACRO I was stealing and trying locally was not
the same as the one (53.2(1242)) that I was trying on SCORE. This should
teach me to be more precise when tracking down bugs... In any case, I would
reccomend that people use a more up-to-date version of MACRO than 53.1(1152)
if at all available, since that version has the potential (realized for me)
of causing a great deal of grief with this strange bug. My thanks to the
people at SCORE and RUTGERS (you guys also have this potential problem) for
my access there - it was vital to tracking this bug down.
--Vince
-------
22-Dec-85 02:39:29-PST,1658;000000000000
Return-Path: <@SUMEX-AIM.ARPA:MRC@PANDA>
Received: from SUMEX-AIM.ARPA by SU-SCORE.ARPA with TCP; Sun 22 Dec 85 02:39:19-PST
Date: Sun 22 Dec 85 02:09:39-PST
From: Mark Crispin <MRC%
[email protected]>
Subject: PDP-10 memorabilia
To:
[email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431
Phone: +1 (415) 968-1052
Message-ID: <12169097608.9.MRC@PANDA>
Folks -
I am looking to get a console panel from a PDP-10 in the
days when they had neat blinking lights (that actually let a
wizard see at a glance what the state of the machine was) and
switches. In other words, I'm looking for either a KA10 or KI10
front panel, although of course I'd be delighted to take a PDP-6
panel off your hands!
Over the past year or so I've had a few leads, but nothing
has panned out so far. If anybody is planning on retiring a KA
or KI for scrap, please let me know. I am willing to pay for
shipping and perhaps could even be induced to part with some
additional bucks (obviously, I'll pay more for one in good
condition).
I am also looking for other memorabilia from the past. I
seem to remember that Peter Hurley (or some other DEC person)
still has a set of PDP-6 distribution DECtapes; if true it would
be neat if those files could be read onto some reasonably
accessable system (e.g. DEC-MARLBORO/MARKET) so that we can all
see what the TOPS-10 monitor sources looked like in those days.
I already have a 6205 board (from Berkeley's PDP-6, which
was running TOPS-10 5.07 when it was finally retired), so save it
for some other deserving(?) hacker.
-- Mark --
-------
30-Dec-85 12:25:48-PST,1166;000000000000
Return-Path: <
[email protected]>
Received: from MCC.ARPA by SU-SCORE.ARPA with TCP; Mon 30 Dec 85 12:25:36-PST
Date: Mon 30 Dec 85 14:28:48-CST
From: Clive Dawson <
[email protected]>
Subject: Excerpts from the TOPS-20 mailing list
To:
[email protected]
Somebody suggested that it would be useful to publish selected messages
from this mailing list in "AT LARGE", the newsletter of the Large Systems
SIG, published monthly by DECUS.
I propose to start selecting messages for this purpose from the existing
archives as well as future submissions. The messages chosen will be those
of general interest to TOPS-20 sites, and therefore will usually not
include Arpanet-related messages. A disclaimer will be included which
states that patches are not guaranteed, etc.
Due to space limitations, the messages may be edited. Names of the
submitters will generally be preserved, but this is not guaranteed,
especially in the case of multiple messages on the same subject.
If you object to your messages being used in this manner, or if you
insist that credit (blame?!) be given in all cases, please let me know.
Thanks,
Clive
-------
31-Dec-85 17:00:54-PST,753;000000000000
Received: from LOTS-C by Score with Pup; Tue 31 Dec 85 17:00:51-PST
Date: Tue 31 Dec 85 17:03:21-PST
From: Paul Hegarty <H.HEGARTY%LOTS-C@LOTS-C>
Subject: SYSJOB
To: SU-TOPS-20%Score@LOTS-C
Message-ID: <12171619595.9.H.HEGARTY@LOTS-C>
The MOUNT command (which I recently transcribed from the MSTR program
into Stanford's SYSJOB) had a bug in it which was discovered and repaired
by Ralph Gorin. The new source is in PS:<SU-UTILITIES>SYSJOB.MAC.
The code was presenting the units to the MSTR% JSYS in the order they
were found rather than in the correct order (unit 0 first, then 1, etc.).
Please also repair any copy of MSTR that you have floating around (and
any other programs which have this ailment).
... Paul
-------
