4-Jan-88 09:52:44-PST,3853;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 09:49:45-PST
Date: Mon 4 Jan 88 10:50:52-MST
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Alternatives to TOPS-20 MAKLIB?
To: [email protected]
cc: [email protected]
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

Under both TOPS-20 and Unix, linkers search load libraries
only once, which makes it desirable to order the library (or
at least its index) in topological order (if B calls A, then
B appears before A in the library).  This order is
non-trivial to determine, though my LIBREF utility
(available on request) will produce a control file to append
REL files into a library in topological order.  It is
completely out of the question to create this order by hand;
the latest release of one of our commercial math libraries
has over 3900 routines.  It would be far easier to just do
"append *.rel foo.lib", then apply a filter to foo.lib to
create an index in topological order.

Under Unix, the `ar' utility supports creation of libraries
of any types of files, and the object file format is
relatively simple.  A separate utility, `ranlib', is usually
applied to the library to produce an index.  Part of the SUN
OS 3.2 Unix man page for the linker, `ld' reads:

    If a named file is a library, it is searched exactly once at
    the  point  it  is  encountered  in the argument list.  Only
    those routines defining an unresolved external reference are
    loaded.  If a routine from a library references another rou-
    tine in the same library, and the library has not been  pro-
    cessed  by  ranlib, the referenced routine must appear after
    the referencing routine in the library.  Thus the  order  of
    programs  within  libraries  may  be  important.   The first
    member of a library should  be  a  file  named  `__.SYMDEF',
    which  is  understood  to be a dictionary for the library as
    produced by ranlib; the dictionary is  searched  iteratively
    to satisfy as many references as possible.

Updating a Unix library is relatively trivial:

       ar r foo.a *.o
       ranlib foo.a

Under VAX VMS,

       library/create foo.olb
       library foo.olb *.obj

suffice to first create, and subsequently update, an object library.

Under TOPS-20, MAKLIB provides a painful alternative:

       MAKLIB
       *foo.rel=foo.rel,a.rel/{append,replace,insert:module}
       *foo.rel=foo.rel/index

requiring before-hand knowledge of whether the module is to
replace an existing one, append to the end of the library,
or be inserted after an existing module.  It also causes a
copy of the library to be made for every `=' processed in
the input stream, which means excessive CPU and disk
requirements.

The TOPS-20 object file format is rather complex, and the
construction of an analogue to Unix `ranlib' is a
non-trivial programming task.  So, the query to the TOPS-20
community is

       ``Has anyone written the equivalent of Unix
       ar/ranlib or VMS LIBRARY for TOPS-20?''

While it is perhaps late in the day to ask this, now that I
have `make' running on 6 different O/S's, I am using `make'
for all new projects, and writing makefiles for older
software collections when I go back and work on them.  This
past week, I recompiled over 250K lines of Fortran code
after we made Fortran V10 the default system version.  With
only MAKLIB available, rebuilding libraries requires
execution of a long command file of APPEND and MAKLIB
commands, and requires that the object files be kept
on-line, wasting disk space, and makes it hard to use `make'
for the library update.
-------
4-Jan-88 11:59:03-PST,1360;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 11:58:24-PST
Date: Mon 4 Jan 88 14:30:35-EST
From: Rob Austein <[email protected]>
Subject: Re: Alternatives to TOPS-20 MAKLIB?
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

If anybody does do any work on a replacement for MAKLIB, please make
it handle PSECTs!

The rest of this message is a few suggestions for ways of using the
existing MAKLIB that are less painful than what you describe.

For just creating a new library from .REL files, the following kluge
works, where NULL.REL is produced by feeding an END statement to the
assembler of your choice:

@maklib
*new.lib=null.rel,*.rel/append
*new.lib=new.lib/delete:null
*new.lib=new.lib/index
*^Z

I haven't tried folding the /DELETE and /INDEX steps into one, I
forget whether MAKLIB will allow that.  Doesn't matter much.

For the case of updating an existing library, you might want to
consider writing a trivial filter that takes the output from a MAKLIB
/POINTS command and, based on that and a list of files, produces a
MAKLIB script that will /APPEND or /REPLACE as appropriate.

None of this is pretty, but it's cheap.

--Rob
-------
4-Jan-88 18:24:57-PST,828;000000000000
Return-Path: <[email protected]>
Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Mon 4 Jan 88 18:24:35-PST
Date: Mon 4 Jan 88 18:25:46-PST
From: Greg Satz <[email protected]>
Subject: Re: Alternatives to TOPS-20 MAKLIB?
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Phone: (415) 326-1941
Message-ID: <[email protected]>

A long time ago I wrote a Pascal program that would take a Fortran
generated relocatable file and topologically sort the routines
generating two output files, one that must be loaded and another that
could be searched. This was intended to be run over the larger libraries
like IMSL so that it could be loaded in a more reasonable manner. The
source is free for the asking.
-------
5-Jan-88 09:27:38-PST,676;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Tue 5 Jan 88 09:26:47-PST
Date: Tue 5 Jan 88 10:27:21-MST
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Re: Alternatives to TOPS-20 MAKLIB?
To: [email protected], [email protected]
In-Reply-To: <[email protected]>
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

Yes, I'd like to see what you've done.  I can pick it up via
ANONYMOUS FTP if you tell me where to look.
-------
6-Jan-88 15:15:00-PST,1235;000000000001
Mail-From: GROSSMAN created at  6-Jan-88 15:14:56
Date: Wed 6 Jan 88 15:14:56-PST
From: Stu Grossman <[email protected]>
Subject: Stanford TOPS-20 meeting
To: [email protected]
Message-ID: <[email protected]>

I have scheduled a meeting to discuss the current situation of TOPS-20 at
Stanford.  I expect that the agenda of this meeting will go along the following
lines:

               1) Version 7.0 field test management
               2) Domain name resolvers (ie: JEEVES vs. CHIVES)
               3) Support for large host numbers in the campus network
                  (ie: IP addresses like 36.8.5.123)
               4) GALAXY support
               5) Removal of PUP routing dependancies
               6) Death of Sierra/location of source tree
               7) Other issues...

I have scheduled the meeting for:
       Thursday, January 14th,
       1:00 to 4:00 pm
       in room 352 of Margaret Jacks Hall

Please let me know of any other issues that you feel are important, and I
will add them to the agenda.  Also, the issues listed above are rather
roughly prioritized, so feel free to suggest a better prioritization.

Also, feel free to invite people who may not be on this list, if you think
that they should be at this meeting.

                       Stu Grossman
-------
11-Jan-88 11:58:39-PST,757;000000000000
Return-Path: <[email protected]>
Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 11:55:42-PST
Date: Mon 11 Jan 88 13:57:40-CST
From: Clifford A. Wilkes <[email protected]>
Subject: Setting back-up status
To: [email protected]
Department: Computation Center - A20/R20 staff
Message-ID: <[email protected]>

Surely someone out there has a program to set the back-up status of files.
I don't want to use REV to do entire discs!  We have had to do a lot of
disc restorations and each one causes DUMPER to make very(!) large
incremental back ups.

It's obviously an easy program to write but we have other things pending.
Any help will be appreciated.

                                       <@>
-------
11-Jan-88 15:20:51-PST,6897;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 15:20:02-PST
Date: Mon 11 Jan 88 15:19:48-PST
From: Eric M. Berg <[email protected]>
Subject: Preview of TOPS-20 version 7 (notes from Fall '87 DECUS)
To: [email protected]
Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home)
Message-ID: <[email protected]>

For the benefit of people who weren't at DECUS, here are some notes from
the "TOPS-20 Technical Update" session given by Jim McCollum of DEC on
Thursday, Dec. 10, 1987.  They cover DEC's plans for TOPS-20 version 7.

(These are based on the notes I took at the session.  I apologize for
any errors or misunderstandings; don't blame them on DEC.)

GOALS for TOPS-20 version 7
===========================
  --Improved maintainability, reliability, performance
  --Reduce unanswered SPR backlog to 0
  --Improved user interface (partial filename recognition to ambiguity;
       cluster-wide OPR commands)
  --Meet customer requirements
  --Finish on-going 6.0/6.1 work (make cluster more usable; continue Galaxy
       work)
  --No new major functionality
  --Hold to original schedule.


FEATURES of TOPS-20 version 7
=============================
  --INFO% jsys to allow remote execution of certain system calls across
       cluster (e.g. SYSTAT, ^Esend)
  --"Dump on BUGCHK": ability to  take a crash dump without crashing
  --Cluster-wide ENQ%/DEQ%: extends ENQ%/DEQ% across cluster; user programs
       will have to be re-written to take advantage of this
  --Separate login structure (also known as "non-PS: login"): the BS: ("boot
       structure") will no longer necessarily be the same as PS: (where user
       login directories are found); this allows several systems in a cluster
       to share a PS: structure.
  --Better handling of off-line disk structures: if a disk structure goes
       off-line, certain system calls (e.g. GTJFN, ACESS, OPENF) will
       return errors rather than causing the user's job to hang.  Jobs with
       open files on the off-line structure will still hang.
  --Filename recognition to the point of ambiguity (currently implemented
       in the Stanford monitor): trying to do recognition where filenames with
       similar roots (e.g. "FILE-PART1.TXT","FILE-PART2.TXT") will result in
       the system typing out the unambiguous part (e.g. "FILE-PART") and then
       beeping, rather than doing no recognition at all.
  --Host-initiated LAT connections ("reverse LAT" connections, useful for
       spooling to LAT-connected printers)
  --Cluster-wide dumping (can force a crash-dump on all cluster members
       simultaneously)
  --Increased structure limits (up to 64 structures): adds more section 0/1
       space
  --Support for CFS cluster with up to 4 CPUs
  --CFS transition messages: provides error messages when problems occur with
       a node joining a cluster
  --Timing-out of startup questions: system will wait one minute for an
       answer to startup questions ("Why reload?"), then time out and proceed
       with re-load if no answer is given.
  --PMOVE/PMOVEM instructions: will be implemented in microcode, rather than
       in monitor
  --New GETAB% functions: will return # of jobs and users on the system, also
       the highest & lowest job numbers in current use
  --DELETE subcommands: similar to the subcommands available in the DIRECTORY
       command ("before", "since", "larger", "smaller")
  --general cleanup of EXEC code
  --EMACS-style command editor (as implemented in Stanford EXEC) will be
       distributed as an unsupported product (same as PCL and MIC software)


NEW GALAXY FEATURES
===================
  --Cluster-wide Galaxy: from a single node, give OPR commands which affect
       entire cluster.  "SHOW CLUSTER" counterparts to OPR "SHOW" commands.
  --"Unprivileged OPR": allows holders of the new SEMI-OPR privilege bit to
       execute some subset of OPR commands.  Which commands they can use are
       selectable during GALGEN.
  --Several LPTSPL changes:
       cluster-wide LPTSPL: print from one node to another
       LAT server LPTSPL: print to LAT-attached printers
       TTY LPTSPL: supports any TTY device as a printer
       DQS LPTSPL: allows files to be printed to DQS server on VMS systems
  --EXEC changes to support all this


SCHEDULE
========
    Field tests:       starting January 1988
                       3 (or maybe 2, if things go well) field test tapes
   SDC submission:     June 1988
   Customer shipments: August 1988


DOCUMENTATION
=============
  DEC asked for feedback on their plans to stop producing printed TOPS-10/20
documentation.  Instead, they'd like to distribute the documentation on-line in
RUNOFF .MEM file format.  Each site could then print and distribute the
documentation as it wished.

  A number of users asked why DEC didn't plan to distribute the RUNOFF
sources in .RNO format.  Answer: the documentation is produced using a (Vax)
version of RUNOFF; the sources won't compile using TOPS RUNOFF.

  However, users pointed out that it would be easier to convert the
documentation to another format (like Scribe or LaTeX) if we had the .RNO
sources.  They asked DEC whether, if some site did the work of converting
the documentation to Scribe/LaTeX, that site could then redistribute the
(printed) documentation to other sites (which might not have Scribe/LaTeX).
DEC took the issue under advisement.

  Since no users at the session raised any _major_ objections, my guess
is that TOPS-10/20 documentation printed & distributed by DEC will soon be
a thing of the past.  Sites with subscriptions to the "TOPS-20 Software
Notebooks" update service, take note.


OTHER DISCUSSION
================
  Betsy Ramsey of AMS asked whether DEC planned to make sources available to
non-source licensees once TOPS-10/20 development by DEC was finished.  The
general tenor of the response was "we don't see any need to do that as long
as we are continuing to provide software support, which will be for at least
the next 5 years".

  DEC also mentioned that:
       (1) they are working on improvements to the AUTOPATCH process;
       (2) they are looking into the possibility of supporting older versions
           of the operating system for customers who want to "freeze" at
           earlier versions of the software.  This would include telephone
           advisory service, "best-effort" workarounds, performance analysis,
           but _not_ SPR service.



DECUS Large Systems SIG
=======================
  There was some discussion about the future of the Large Systems SIG
within DECUS at the Large Systems Town Meeting.  I expect there'll be some
reflection of this in the Large Systems section of the next issue of the
DECUS newsletters.  There's also an electronic mailing-list for the
Large Systems SIG steering committee: [email protected].
-------
11-Jan-88 19:57:34-PST,1034;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Mon 11 Jan 88 19:57:08-PST
Date: Mon 11 Jan 88 22:55:03-EST
From: Rob Austein <[email protected]>
Subject: Re: Setting back-up status
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

   Date: Mon 11 Jan 88 13:57:40-CST
   From: Clifford A. Wilkes <[email protected]>

   Surely someone out there has a program to set the back-up status of files.
   I don't want to use REV to do entire discs!  We have had to do a lot of
   disc restorations and each one causes DUMPER to make very(!) large
   incremental back ups.

[XX.LCS.MIT.EDU]SRC:<SYS.SYSYS>FIX-INCREMENTAL.MID may be what you
want.  We find it useful when restoring 5 and 6 pack public structures
from tape.  You'll also need MID:MACSYM.MID and MID:CMD.MID to
assemble it.  All are available via anonymous FTP.

--Rob
-------
12-Jan-88 11:00:02-PST,1185;000000000000
Return-Path: <[email protected]>
Received: from A20.CC.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Tue 12 Jan 88 10:58:01-PST
Date: Tue 12 Jan 88 12:59:56-CST
From: Kay Nettle <[email protected]>
Subject: TCPSPL
To: [email protected]
Message-ID: <[email protected]>

I can get TCPSPL and LPD to work with version 5.4 of the monitor and
4.2 of galaxy, the R20.  When I try using TCPSPL under version 6.1 of
the monitor and 5 of galaxy, the A20,it doesn't work.  LPD will work on both
systems.  I have plpt3: defined on the A20 as tcp:a20-770.r20-515;timeout:60;
connection:active.  On the R20 it's defined as tcp:r20-77-.a20-515;
timeout:60;connection:active.
When I start up printer 3, this is what happens on the A20:

OPR>start printer 3
OPR>
12:35:10        Printer 3  -- Startup Scheduled --
OPR>
12:35:11        Printer 3  -- TCPSPL - Not Started --
               Can't find device TCP:A20-770.R20-515.0;TIMEOUT:60;CONNECTION:AC
TIVE
OPR>
12:35:12        Printer 3  -- TCPSPL - Stream Shutdown --

12:35:12        Printer 3  -- Shutdown --
OPR>ex

Does anyone have any advice or see anything that I'm doing wrong.

-Kay-
-------
14-Jan-88 11:09:07-PST,1155;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 14 Jan 88 11:09:02-PST
Return-Path: <[email protected]>
Received: from A20.CC.UTEXAS.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 14 Jan 88 06:27:05 PST
Date: Wed 13 Jan 88 15:58:34-CST
From: Kay Nettle <[email protected]>
Subject: Quasar modifications
To: [email protected]
Message-ID: <[email protected]>
ReSent-Date: Thu, 14 Jan 88 11:08:58 PST
ReSent-From: Mark Crispin <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

I'm working on TCPSPL and LPD that I got from SIERRA.  In LPDQSR.MAC
is says that it assumes that some modifications have been made to
Quasar and friends.  I have tried writing the Quasar man at Columbia,
but can't get a responce.  I assume that ya'll are using it since it
has stanford local stuff in it.  Could you please tell me what
modifications have to be made, or point me to someone who could tell
me?
Thanks.

-Kay-
-------
16-Jan-88 17:38:46-PST,5784;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Sat 16 Jan 88 17:36:47-PST
Date: Sat 16 Jan 88 18:37:48-MST
From: "Nelson H.F. Beebe" <[email protected]>
Subject: A new PCC-20 bug, and a fix
To: [email protected]
cc: [email protected]
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

I just nailed a bug in PCC-20 (the first found in over 2
years), and since we have compiler sources, was able to fix
it.

Jay Lepreau ([email protected]) originally ported PCC to
TOPS-20 and distributed it to numerous TOPS-20 sites under
license.  He has given me permission to publish this report
and the code fix.  CS sold their DEC-20/60 to SCIENCE last
year, so he is no longer in a position to maintain TOPS-20
software.

The bug may exist in other derivatives of the original PCC;
I checked cc's code generation on CS.UTAH.EDU (4.3BSD VAX
Unix), but found it to be okay there.

The bug is exhibited by the simple program:

char    item_x[ 3][     144] = {
       "",
       "\n    \\subitem ",
       "\n      \\subsubitem "};

main()
{
   int k;
   for (k = 0; k < 3; ++k)
       printf("item_x[%d][] = \"%s\"\n",k,&item_x[k][0]);
}

(a fragment from the Chen/Lamport MakeIndex program for
production of document indexes for TeX, LaTeX, Scribe,
troff, et al)

The generated .S file has

       ...
       entry   item.x
item.x::
       oct     0
       exp     0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
       exp     0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
       exp     0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
       exp     0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
       exp     0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
       exp     0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
       oct     12
       oct     40
       oct     40
       oct     40
       oct     40
       oct     134
       oct     163
       oct     165
       oct     142
       oct     151
       oct     164
       oct     145
       oct     155
       oct     40
       oct     0
       ....

The bug is that the 5 exp lines ending in commas result in
MACRO supplying an extra 0 word, with the result that the
second string begins at offset 144+5 = 149, instead of 144.

The fix involves rewriting zecode() in code.c; 2 years ago
when I last worked on the compiler, I had already worked in
that section to produce a repeat count, instead of repeated
0's, because I wanted to shorten the enormous .REL's that
could be produced if n was large.  The code never got
installed in our production version of PCC-20 because I ran
out of steam on some other modifications.  I just
reactivated that code section, so the .S file now has

item.x::
       oct     0
       xlist
       repeat  ^D143,<exp 0>
       list
       oct     12
       oct     40
       oct     40
       oct     40
       oct     40
       oct     134
       oct     163
       oct     165
       oct     142
       oct     151
       oct     164
       oct     145
       oct     155
       oct     40
       oct     0
       ...

which now produces correct storage assignments.

If you do not want to make source patches to the compiler,
you can grab PCC:C1.EXE via ANONYMOUS FTP to
SCIENCE.UTAH.EDU.  It has enlarged tables for big switch
statements, and PCC:CPP.EXE, the preprocessor, has been
extended to support long symbol names (up from 8 to 63) and
allow more of them (up from 1000 to 20000).  The latter
change allows it to handle a full monsym.h.  With Jay's
permission, the complete source mods for these changes could
be made available too.  I also have a Unix cc-like interface
which avoids the need for PCL or MIC commands to run PCC-20;
ask and ye shall receive.

Here is the replacement code for function zecode() in
<*.CPP.DIST>code.c; the original code is preserved for
reference.  Install it, recompile code.c, and then do

link
@c1.ccl

to make a new C1.EXE which can be installed in PCC:.

zecode( n ){
       /* n integer words of zeros */
       OFFSZ temp;
       register i;

       if( n <= 0 ) return;
#if 0
       /* This code is WRONG-- the extra "," at the end of */
       /* each line causes MACRO to supply an extra zero! */
       printf( ")      exp     " );
       for( i=1; i<n; i++ ) {
               if( i%24 == 0 )                 /* max 24 on a line */
                       printf( "\n)    exp     " );
               printf( "0," );
               }
       printf( "0\n" );
#else
       /* Here is a correct version, which also produces */
       /* much shorter output if n is large */
       if ( n == 1)
           printf( ")\texp\t0\n");
       else
       {
           printf( ")\txlist\n");
           printf( ")\trepeat\t^D%d,<exp 0>\n", n);
           printf( ")\tlist\n");
       }
#endif

       temp = n;
       inoff += temp*SZINT;
}


While you're at it, here  is another fix to code.c:

/* NHFB01: Surround BLT by PUSH/POP to preserve Ac1 -- code generated */
/* for functions which return a "struct" */
efcode(){
       /* code for the end of a function */

       if (strftn) {  /* copy output (in r1) to caller, ie for fxs returning
                                                strucs (pointed to by r1). */
               register struct symtab *p;
               register int stlab;
               register int count;
               int size;

               p = &stab[curftn];

               deflab( retlab );

               stlab = getlab();
               size = tsize(DECREF(p->stype), p->dimoff, p->sizoff) / SZCHAR;
               count = size / NCHPERINT;    /* what if not integral?? fjl */
               printf( ")\thrl $1,$1\n)        hrri    $1,$%d\n", stlab );
/* NHFB01: Ac1 gets clobbered by BLT -- need to save and restore */
/*
               printf( ")\tblt $1,$%d+%d-1\n)  hrrzs   $1,$1\n", stlab,count);
*/
               printf( ")\tpush\t$p,$1\n");
               printf(")\tblt  $1,$%d+%d-1\n",stlab,count);
               printf(")\tpop\t$p,$1\n");
               printf(")\thrrzs\t$1,$1\n");
               printf( ")      reloc\n" );
               printf( ")\tarray\t$%d[%d]\n)   reloc\n", stlab, count );
               /* turn off strftn flag, so return sequence will be generated*/
               strftn = 0;
               }
       branch( retlab );
       printf(")       lit\n");  /* for locality, also make sure in text seg*/

#ifdef ONEPASS
       p2bend();
#else
       printf("]\n");
#endif
       }


-------
16-Jan-88 17:39:02-PST,644;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 16 Jan 88 17:37:00-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 16 Jan 88 17:37:59 PST
Date: Sat, 16 Jan 88 17:15:31 PST
From: Mark Crispin <[email protected]>
Subject: GIGI (a.k.a. VK100) manual
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Hi, does anyone have a GIGI manual they don't need/want and are willing
to send to me?
-------
19-Jan-88 06:55:56-PST,1516;000000000000
Return-Path: <114RONAN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 06:51:51-PST
Received: by lindy.stanford.edu; Tue, 19 Jan 88 06:54:08 PST
Received: by Forsythe.Stanford.EDU; Tue, 19 Jan 88 06:55:29 PST
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 2450; Tue,
19 Jan 88 12:24:56 GMT
Via:      UK.AC.RL.EARN; Tue, 19 Jan 88 12:24:55 GMT
Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2447; Tue, 19
         Jan 88 12:24:54 GM
Via:      UK.AC.LIVPOL.SPOOL; 19 JAN 88 12:24:39 GMT
Date:     19-JAN-1988 12:14:25
From: 114RONAN%[email protected]
To: [email protected]
Subject:  Alternative archiving with request queue wanted.


       Having moved to TOPS-20 6.1, we are disappointed with the time taken
by archive runs of DUMPER on our (very full) RP07 PS:. The computer manager
here thinks that he remembers hearing about a different archiving system
that used a queue of archive requests, (like the queue for retrievals),
rather than having DUMPER scan the whole disk looking for marked files.
This may have been a patch to some standard TOPS-20 utilities, though frankly
I doubt it...
       Does anyone out there know anything about a system like this?
Thanks for any help offered.

Ronan Flood, Liverpool Polytechnic Computer Services.

INTERnet:       114RONAN%[email protected]
BITNET:         114RONAN%[email protected]

(I hope...)
19-Jan-88 10:44:32-PST,1014;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 10:41:36-PST
Date: Tue 19 Jan 88 12:44:49-CST
From: Clive Dawson <[email protected]>
Subject: Re: Alternative archiving with request queue wanted.
To: 114RONAN%[email protected]
cc: [email protected]
In-Reply-To: Message from "114RONAN%[email protected]" of Tue 19 Jan 88 12:14:25-CST
Message-ID: <[email protected]>

Ronan-

There have been several efforts over the years to speed up
archiving.  One of the best was done by Don Watrous at Rutgers,
which makes use of a file called SYSTEM:ARCHIVE-REQUESTS.BIN.
Everytime somebody makes an archive request, a bit corresponding
to the directory is set in this file.  This allows DUMPER to avoid
scanning the whole disk.  More info on this can be found in
the TOPS-20 mailing list archives, or presumably from Don himself.
(Try mail to [email protected].)

Clive
-------
19-Jan-88 11:50:06-PST,1510;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 19 Jan 88 11:44:51-PST
Date: 19 Jan 1988 1447-EST
From: "Jim McCollum" <[email protected]>
To: [email protected]
Reply-to: [email protected]
dtn: 297-4635
Subject: TOPS-20 ARP change proposal
Message-ID: <"MS11(6034)+GLXLIB6(0)" 12367907926.11.34.97083 at TOPS20.DEC.COM>

A question for the  ARPA community concerning TOPS-20  and the way  it
deals with ARP packets:

I have an SPR that states that  all the replies that TOPS-20 sends  to
ARP Request packets are sent to the ARP multicast address. It goes  on
to ask that we change  this so that ARP replies  are sent only to  the
requestor and not the multicast.

Sure enough, this  is TOPS-20's  current behaviour. The  RFC does  not
specifically state where the replies should be sent. The submitter  of
the SPR claims that  UNIX 4.2 does not  send replies to the  multicast
(as an  example). I  can't see  any good  reason for  replying to  the
multicast address and am planning on changing TOPS-20 to reply only to
the requestor. Does anyone have any problems with this?

As an aside, it  appears to me  from looking at the  code that when  a
TOPS-20 system receives a  reply packet on the  multicast that is  not
directed to itself, it  pitches the packet without  any update to  the
ARP tables.  This  seems like  one more  reason that  replying to  the
multicast is useless.

Jim
  --------
21-Jan-88 21:36:31-PST,483;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 21 Jan 88 21:33:29-PST
Date: Thu, 21 Jan 88 21:37:54 PST
From: Mark Lottor <[email protected]>
Subject: markup bug
To: [email protected]
Message-ID: <[email protected]>

The routine MARKUP in IPIPIP that processes ICMP echo and echo replies
doesn't get the host number correctly.  It should do a
 LOAD T1,PISH,(PKT)
instead of what's there.
-------
25-Jan-88 21:54:51-PST,1047;000000000001
Return-Path: <RMF%ADMIN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 21:51:06-PST
Received: by lindy.stanford.edu; Mon, 25 Jan 88 21:56:19 PST
Received: by Forsythe.Stanford.EDU; Mon, 25 Jan 88 21:55:03 PST
Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Mon, 25 Jan 88 20:24:25 MST
Date: Mon 25 Jan 88 20:21:06-MST
From: RMF%ADMIN%[email protected]
Subject: SLIP
To: [email protected]
Phone: (403) 240-6052
Organization: Mount Royal College; Computer Operations
Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6
Message-Id: <12369563393.8.RMF@ADMIN>

       I am looking for a version of SLIP for the 20.  Does
       anyone by chance have a copy they wouldn't mind shareing?

       /Russ

-----
Russell M Forster

DECnet: RMF @ { Admin | Flux | Stasis | Ins }
BITnet: RForster @ UncaEdu.BITnet
ARPA:   Oc.Russ @ CU20B.Columbia.Edu
USEnet: uunet!calgary!vaxd!forster
-------
25-Jan-88 22:12:51-PST,1308;000000000000
Return-Path: <RMF%ADMIN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 25 Jan 88 22:12:33-PST
Received: by lindy.stanford.edu; Mon, 25 Jan 88 22:17:42 PST
Received: by Forsythe.Stanford.EDU; Mon, 25 Jan 88 22:16:24 PST
Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Mon, 25 Jan 88 20:29:00 MST
Date: Mon 25 Jan 88 20:25:46-MST
From: RMF%ADMIN%[email protected]
Subject: MM/Chives
To: [email protected]
Phone: (403) 240-6052
Organization: Mount Royal College; Computer Operations
Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6
Message-Id: <12369564244.8.RMF@ADMIN>

       Does the Chives system work on a *non* TCP/IP site?  We are
       only a DECnet site with an STmail (Software Tools) BITnet
       gateway into the real world.

       Also, does anyone know of anyone that was MM or Chives on
       a BITnet LISTSERVer or some such?  RPICICGE (CICGE.RPI.EDU)
       has some of the SIMTEL's archives but they don't have MM there.

       /Russ

-----
Russell M Forster

DECnet: RMF @ { Admin | Flux | Stasis | Ins }
BITnet: RForster @ UncaEdu.BITnet
ARPA:   Oc.Russ @ CU20B.Columbia.Edu
USEnet: uunet!calgary!vaxd!forster
-------
26-Jan-88 00:14:15-PST,1261;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 00:13:57-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Tue, 26 Jan 88 00:17:26 PST
Date: Mon, 25 Jan 88 23:19:12 PST
From: Mark Crispin <[email protected]>
Subject: Re: MM/Chives
To: RMF%ADMIN%[email protected]
cc: [email protected]
In-Reply-To: <12369564244.8.RMF@ADMIN>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Russell -

    PANDA runs Chives, and PANDA's non-TCP/IP and a 2020 to boot.  In
fact, PANDA has completely replaced its DOMAINS.TXT file with an
appropriate zone file for the top-level (most of which consists of
entries such as "*.ARPA IN MX 10 SUMEX-AIM.Stanford.EDU").  It's a
helluva lot faster than DOMAINS.TXT (not to mention being nice to
being able to reply to all hosts).

    The only guaranteed current MM sources are on PANDA, and so you
have to get them from me.  From time to time SUMEX-AIM's SS:<MM> and
SIMTEL20's SRC:<MM> directories get updated from PANDA, but only
infrequently.

-- Mark --
-------
26-Jan-88 10:46:49-PST,23486;000000000001
Mail-From: VAF created at 26-Jan-88 10:46:05
Date: Tue 26 Jan 88 10:46:04-PST
From: Vince Fuller <[email protected]>
Subject: Re: SLIP (long reply)
To: RMF%ADMIN%[email protected]
cc: [email protected]
In-Reply-To: <12369563393.8.RMF@ADMIN>
Office: 147 Pine Hall (under construction)
Phone:  415-725-1392
Message-ID: <[email protected]>

This has been asked and answered before, so my apologies for repeating it
here again... Anyway, a few years ago, I made some modifications to TOPS-20
to allow it to support IP over a serial line, using the encapsulation scheme
described in the appendix of RFC891. The code worked reasonably well when I
tested it but ended up not being used in production here. I have given it to
other people, but haven't heard whether it's seen any extensive use (though
I'd be interested to hear if you or anyone else gets it running). It should
be noted that as distributed, this code assumes you have sources - it might
be possible to graft it onto a binary-only system, but that would require
some modifications.

       --Vince

(what follows are a copy of my original message about the subject and the
TTYSRV "module" which supports the serial line interface)

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

Modifications to TOPS20AN to support TCP/IP over a serial line interface. This
assumes that you have a 5.3 or 5.4 TOPS20AN monitor as distributed by DEC.

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

Modifications to ANAUNV.MAC
---------------------------

*After the line
MAKNCT(\DV.NUM,\NCTNUM,^D576)>
*Add:
IFNDEF TTYN,<TTYN==0>           ;Default to no TTY interfaces
IFN TTYN,<
NT.TYP==NT.SER                  ;Network is "serial line" network
NT.DEV==NT.TTY                  ;Device type TTY
DV.NUM==0                       ;Start with number 0
MAKNCT(\DV.NUM,\NCTNUM,^D554)   ;Make that type NCT
  >;TTY

*After the line
NT.NUN==:1
*add
NT.SER==:2                      ;Serial line protocol

*After the line
NT.NIN==:2
*add
NT.TTY==:3                      ;TTY line

*After the NCT definition for the NI, add TTY NCT definition:

;Define the TTY internet interface

IFE <<NT.TYP-NT.SER>!<NT.DEV-NT.TTY>>,<

       HALT                    ; CONSZ Input
       HALT                    ; CONSO Input
       HALT                    ; CONO Input
       HALT                    ; CONI Input
       HALT                    ; DATAO Input
       HALT                    ; DATAI Input
       IFIW!TNTINI             ; NTINI - Initialization instruction
       IFIW!TNTKIL             ; NTKILL - Shutdown instruction
       IFIW!TIPON              ; NTRSRT - Restart instruction
       IFIW!R                  ; NTISRT - Start input instruction
       IFIW!TIPOBG             ; NTOSRT - Start output instruction
       IFIW!R                  ; NTIDUN - Input done dispatch
       IFIW!R                  ; NTODUN - Output done dispatch
       IFIW!R                  ; NTLLDR - Make header instruction
       IFIW!TIPOOK             ; NTOTOK - Clear packet for output
       IFIW!R                  ; NTMAIN - Maintainance
       IFIW!R                  ; NTSCHK - Status check instruction
       BLOCK   NTSVAC+17-NTIB  ; Storage
>;TTY

Modifications to GLOBS.MAC
--------------------------
*Add one line (after last DEC QEXT line):
QEXT <TNTINI,TNTKIL,TIPON,TIPOBG,TIPOOK> ;TTY/IP entry points


Modifications to MNETDV.MAC
---------------------------

*After the ADNCP routine, add:

;Prrocess SERIAL keyword

ADDSER: MOVEI T1,NT.SER         ;Protocol is serial line
       STOR T1,NTTYP,(P3)
       RET

*In the INTNAM table, after the line
KEY IPNI,NT.NIP                 ; KLNI Interface
*add one line:
KEY TTY,NT.TTY                  ; Serial line

*In the TYPNAM table, after the line
KEY PREFERRED,ADDPRF            ; This is the 'preferred' address for host
*add one line:
KEY SERIAL,ADDSER               ; Serial line protocol

Modifications to PROLOG.MAC
---------------------------

*After the definition of IFSM, add one line:
DEFINE IPTT,<IFG TTYN>          ;Test for IP/TTY interface

*You will need to modify your PARAMS file to define TTYN==:1*

Modifications to STG.MAC
------------------------

*After the line:
NDG     KNIN,0                  ;NUMBER OF KLNI'S
*Add one line:
NDG     TTYN,0                  ; Number of TTY lines

*After the line:
NDG     ANX0,520                ;ADDRESS FOR FIRST AN20
*Add one line:
%NETS==:ANXN+IPNIN+TTYN         ;TOTAL NUMBER OF IP INTERFACES

Modifications to TTYPHDV.MAC
---------------------------

*At label BIGST2: add two lines:
IPTT,<  CALL TIPCHK             ; IP link line?
        RETSKP>                ; Yes, just take the character

*At TTYDON+3 (after RET) add two lines:
IPTT,<  CALL TIPCHK             ; IP link line?
        JRST TIPDON>           ; Tell it

*At TTDTRM+3 (after SAVET) add one line:
IPTT,<  CALL TIPRST>            ; Reset IP link line

Modifications to TTYSRV.MAC
---------------------------

*After line
       .PTFLG==1               ;ALWAYS INCLUDE PT CODE
*Add one line:
IFNDEF TTYN,<TTYN==:0>          ; default to no IP TTY
*Note: You will need to define this, probably with a one-line file compiled
*with TTYSRV, as TTYN==:1

*At TYINLP-3 (after SETZM TTCQLN) add one line:
IPTT,<  CALL TIPINI>            ; Initialize IP line

*At TTCH7+9 (after MOVEI Q2,0(1)) add 3 lines:
IPTT,<  CALL TIPCHK             ; See if IP link...
        JRST [ CALL TIPCH7     ; Process it there
               JRST TTCH7]>

*At TTCH7X+2 (after CALL TTYQOC) add one line:
IPTT,<  CALL TIPQOC>            ; Start output to IP link line

*At TTYSTC, add two lines:
IPTT,<  CALL TIPCHK             ; IP link?
        RET>                   ; Yes, never XOFF

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

You will also need the TTYSRV submodule TTIPDV.MAC, available via ANONYMOUS
FTP from PS:<VAF.DIST>TTIPDV.MAC on CMU-CS-C. This should be assembled with
TTYSRV before TTPHDV.MAC. Note that as currently written, TTIPDV has the tty
number of the IP link line wired in as "20". This may be set by changing the
value of location TTIPLN, located in TTIPDV (this should really be set by the
INTERNET.ADDRESS file, but since we don't use the tty line interface, I haven't
gotten around to making the necessary changes to MNETDV.MAC). You will need to
add a line to INTERNET.ADDRESS such as:
       TTY#0, 192 5 255 2,SERIAL,PACKET-SIZE:576,LOGICAL-HOST-MASK:0 0 0 0
where you should substitute your site's address for "192 5 255 2".

Please let me know how this works and if you have any problems with it.

       --Vince

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

;<NEWMON.CMU>TTIPDV.MAC.1, 15-Mar-84 11:30:28, Edit by VAF
;This code implements sending and receiving of IP packets over a serial line,
;as described in the appendix of RFC891. It should only be used when no better
;interface is available... This code could stand some optimization, but since
;it needs to be done in a hurry, it will have to do.

       SUBTTL TTIPDV - IP front end terminal device

COMMENT ~
+-----------------------------------------------------------------------+
|                                                                       |
|               Copyright (C) 1984,1987  Vincent A. Fuller              |
|                                                                       |
|  This software, in source and binary form, is distributed free of     |
|  charge. The binary form of this software may be incorporated into    |
|  public-domain software and the source may be used for reference      |
|  purposes.  Copies may be made of the source provided this copyright  |
|  notice is included.  Wholesale copying of the routines in this       |
|  software or usage of this software in proprietary product without    |
|  prior permission is prohibited.                                      |
|                                                                       |
+-----------------------------------------------------------------------+
~

CHDLE==20                       ;DLE character: used to indicate control code
CHSTX==2                        ;STX - start of message
CHETX==3                        ;ETX - end of message

MAXPKZ==<^D576*2+4>             ;Max IP packet + padding + encapsulation
MAXPKX==<<MAXPKZ+3>/4>          ;Word count of it
IPKDAT==:PKTELI-LCLPKT          ;Offset in IP buffer of packet data

RSI TTIPLN,<20>                 ;The IP link line number
RSI TIPLCH,<-1>                 ;Last input character
RSI TIPCCH,<-1>                 ;Current input character

RS TIPIFL                       ;Flag if TTY initialized
RS TIPIPO                       ;Flag if IP interface is on
RS TIPMSZ                       ;Max output packet size of interface
RS TIPNCT                       ;NCT address of interface
RS TIPOQT                       ;Output line quota
RS TIPOSZ                       ;Number of bytes remaining to output
RS TIPOFL                       ;Flag indicating outout done acknowledged ok
RS TIPOWT                       ;Flag indicating output pending
RS TIPOAD                       ;Address of IP output packet
RS TIPOPT                       ;Byte pointer into output packet
RS TIPIAD                       ;Buffer address of input packet
RS TIPIPT                       ;Byte pointer into input packet
RS TIPISZ                       ;Input packet bytes left

RS TIIMNY                       ;Number of input packets received
RS TIQMNY                       ;Number of DTEQ's done
RS TIDMNY                       ;Number of DTE output done interrupts
RS TIOMNY                       ;Number of complete output packets sent
RS TIEMNY                       ;Number of errors
RS TIPINB                       ;Number of times no IP buffers available
RS TIPOBF,MAXPKX                ;Output buffer
RSI TIPSPD,<<POINT 8,TIPSPV>>
RSI TIPSPV,<<BYTE(16) ^D9600,^D9600>,<BYTE(16) 1>>

       SUBTTL TTCH7 processing for IP line

       RESCD                   ;Called from scheduler context

;Called when a character for the IP line is removed from BIGBUF.
;Accepts:
;       T1/ Character
;       T2/ Internal line number (must agree with TIPLIN)

TIPCH7: SKIPE TIPIFL            ;TTY initialized yet?
       SKIPN TIPIPO            ;And IP interface on?
       RET                     ;Nope... Can't do input yet
       ANDI T1,377             ;Only 8 bits, please
       MOVEM T1,TIPCCH         ;Save current character
       MOVE T2,TIPLCH          ;Get last character read
       SKIPN TIPIAD            ;Do we have a input packet yet?
       CALLRET TIPIST          ;Maybe start input now
       MOVEM T1,TIPLCH         ;Update last character now
       CALL TIPCDL             ;Check for DLE
       RET                     ;Yes - handled it, so done
       IDPB T1,TIPIPT          ;Add character to input packet
       SOSL TIPISZ             ;Check for size overflow
       RET                     ;OK
       BUG.(CHK,TIPISX,TTYSRV,HARD,<TTIPDV - input packet too large>)
       CALLRET TIPIRS          ;Reset input


;Checks for DLE as last character and process current character specially.
;Assumes:T1/ Current character, T2/ Previous character
;Returns +2: Normal character - process as pkt data
;        +1: Special processing done.

TIPCDL: CAIN T2,.CHDLE          ;Was last character a DLE?
       IFSKP.                  ;Nope. Probably don't need to do anything
         CAIE T1,.CHDLE        ;If current is DLE, then just eat it
         AOS (P)               ;Nope. Keep the character
         RET
       ENDIF.
       CAIE T1,.CHDLE          ;Is this a quoted DLE?
       IFSKP.                  ;Yes...
         SETZM TIPLCH          ;Fake last character, since not really DLE
         RETSKP                ;Treat it as a normal character
       ENDIF.
       CAIN T1,.CHDEL          ;Delete?
        RET                    ;Yes. Padding - flush it
       CAIN T1,.CHETX          ;End-of-message?
        JRST TIPIDN            ;Yes - input done, then
       BUG.(CHK,TIPICX,TTYSRV,HARD,<TTIPDV - Unexpected ctrl code received>,<<T1,BADCOD>>)
       JRST TIPIRS             ;Reset input

;Come here when received input, but no packet buffer allocated yet. We check
;to see if it looks like there is a packet coming in, and allocate a buffer
;if necessary. Assumes: T1/ input byte, T2/ last input byte

TIPIST: CAIN T2,.CHDLE          ;Was it DLE?
       CAIE T1,.CHSTX          ;And is this start-of-message?
       JRST TTIPNS             ;Not yet... Update last character & quit
       SKIPE TIPIPO            ;Interface on?
       CALL GETBUF             ;Can I get a packet buffer?
       CALLRET TTIPNB          ;Nope. Punt incoming character
       MOVEM T1,TIPIAD         ;Save buffer address
       ADDI T1,IPKDAT          ;Point to data area of pkt buffer
       TLO T1,540000           ;Make an 8-bit global pointer to pkt buffer
       MOVEM T1,TIPIPT         ;And save the pointer
       MOVE T1,TIPMSZ          ;Get max packet size for interface
       MOVEM T1,TIPISZ         ;Save as bytes left in input packet
       MOVE T1,TIPCCH          ;Get current input character
TTIPNS: MOVEM T1,TIPLCH         ;Update last character seen
       RET                     ;And return

;Come here when starting input of a packet, but no IP buffers available.
;We have to drop the packet, in this case.

TTIPNB: SETOM TIPLCH            ;Reset to pre-initial DLE state
;       JRST TIPERR             ;And increment error count

;Record network errors. Increments count of them.

TIPERR: AOS TIEMNY              ;Bump count
       RET                     ;And done

;Check if a line is really the IP line.
;Accepts T2/ Line number
;Returns +1 if it is the IP line (TTIPLN)
;Returns +2 if it isn't, or it isn't turned on

TIPCHK: SAVELN
       HRRZS T2                ;Make line number
       SKIPE TIPIPO            ;Is the IP interface on?
       CAME T2,TTIPLN          ;Is it our line number?
       AOS (P)                 ;Setup skip return...
       RET                     ;Return

;Initialize the IP receive line and associated database. Sets line type and
;turns on multinet interface. Called from main TTYSRV initialization code.

TIPINI: SKIPE FEFLG             ;Not in primary protocol?
       SKIPE TIPIFL            ;Or done this already?
       RET                     ;Then just punt
       SAVEAC <P1>             ;Multinet may need this...
       MOVE T2,TTIPLN          ;Get line number
       BLCAL. TTDTEQ,<[0],[.DFTOL],[0],[.DFTOO]> ;Turn line on
       BLCAL. TTDTEQ,<[0],[.DFMSG],[0],[1]> ;Turn off system messages
       BLCAL. TTDTEQ,<[0],[.DFSPD],[6],TIPSPD> ;Set linespeed
       BLCAL. TTDTEQ,<[0],[.DFXEN],[0],[0]> ;Disable XON/XOFF processing
       LOAD T1,TSFMC,(T2)      ;Get initial line allocation
       MOVEM T1,TIPOQT         ;Remember it for output
       SETONE TTIGI,(T2)       ;TOPS-20 should ignore input on this line
       SETOM TIPIFL            ;Say TTY initialization done
       SKIPE P1,TIPNCT         ;NCT setup yet?
        CALL TIPON             ;Turn on IP interface now
       RET

;Come here when RSX20F reloaded. Need to reset IP line state

TIPRST: EA.ENT                  ;Get into section 1
       SETZM TIPIFL            ;Say not initialized yet
       CALL TIPINI             ;Initialize the line
       CALL RETOU1             ;Flush current output buffer
TIPIRS: SETZ T1,                ;Setup zero
       EXCH T1,TIPIAD          ;Get input buffer & clear it
       CALL RETBUF             ;Return it
       RET                     ;Special processing done

       SUBTTL Multinet interface

       SWAPCD

;TNTINI (NTINI) - Network Initialization
;Set up the NCT for the tty line.
;Takes  P1/ pointer to NCT
;Returns +1 always
;Clobbers T1-T4

TNTINI::MOVE T1,NTPSIZ(P1)      ;Get max packet size for interface
       CAIG T1,MAXPKZ          ;Smaller than our buffer size?
       IFSKP.                  ;Nope
         BUG.(CHK,TIPOSX,TTYSRV,SOFT,<TTIPDV - output buffer too small>)
         RET                   ;Punt
       ENDIF.
       MOVEM T1,TIPMSZ         ;Save max packet size
       MOVEM P1,TIPNCT         ;Save NCT address...
       CALL TIPINI             ;Initialize line, if necessary
       RET

;TNTKIL (NTKILL) - Shutdown the interface
;This routine is a no-op if the interface doesn't exist, or is already off.
;Returns +1 always

TNTKIL::SKIPN TIPIPO            ;Is interface on?
       RET                     ;Nope - don't bother cycling network...
       SETOM NTSTCH(P1)        ;Set cycling flag
       SETZM NETON(P1)         ;State of network is off
       SETZM NTRDY(P1)         ;State of interface is off
       SETZM NTORDY(P1)        ;Output not possible
       SETZM TIPIPO            ;Don't accept any more packets
       RET

;TIPON (NTRSRT) - Network restart instruction
;Set address mask and enable reception
;Takes  P1/ pointer to NCT
;Returns +1 always

TIPON:: SKIPE TIPIPO            ;Already on?
       RET                     ;Don't cycle again
       SKIPE TIPIFL            ;TTY line initialized yet?
       SKIPN TIPNCT            ;And NCT setup?
       RET                     ;Nope - can't turn interface on, then
       SETOM NTSTCH(P1)        ;Set change of state
       SETOM NETON(P1)         ;Network is on
       SETOM NTORDY(P1)        ;Output is on
       SETOM NTRDY(P1)         ;Net is ready
       SETOM TIPIPO            ;Start accepting packets
       CALL RETOU1             ;Get rid of stuck output buffer...
       AOS JB0FLG              ;Tell Multinet to run
       RET

;TIPOOK (NTOTOK) - Net output okay
;Called T1/ (first hop) destination address
;       T2/ pointing to an Internet buffer
;       P1/ address of NCT
;Returns +1 no can do, T1/ ICMP error code
;        +2 success, encapsulation done

;This routine is a NO-OP for now, since there's nothing to do.

TIPOOK::AOS (P)                 ;Make a skip return
       RET                     ;That's it

;TIPOBG (NTOSRT) - Start IP output.
;Get packet from IP output queue and attempt to send it.
;Takes  P1/ pointer to NCT
;Copies packet to section 0 output buffer and DTEQ's first part.
;Returns +1 always

;TIPQOC is alternate entry, called every 20ms from scheduler

       RESCD                   ;Called from interrupt level

TIPQOC::SKIPE TIPOAD            ;Already doing output?
        JRST TIPORT            ;Yes - perhaps waiting to do more
       SAVEAC <P1>             ;Preserve NCT register
       MOVE P1,TIPNCT          ;And set it up
TIPOBG::SKIPN TIPOAD            ;Output already in progress?
       SKIPN NTIOBO(P1)        ;Or nothing queued for output?
       RET                     ;Don't start anything
       NOSKED                  ;Lock out TIPQOC
       CALL GETOUT             ;Get first output packet from output queue
        JRST [ OKSKED          ;Nothing there, or lost timing race - punt
               RET]
       SETZM TIPOFL            ;Clear output flag
       MOVEM T1,TIPOAD         ;Setup output address
       OKSKED
       XMOVEI T2,IPKDAT(T1)    ;Point at IP packet itself
       LOAD T4,PIPL,-LCLPKT(T1) ;Get packet length, in bytes
       TLO T2,540000           ;Make 8-bit global pointer to packet
       MOVNS T4                ;Make negative byte count
       HRLZS T4                ;Make AOBJN
       MOVE T1,[POINT 8,TIPOBF] ;Point at output buffer
       MOVEI T3,.CHDLE         ;DLE pading
       IDPB T3,T1              ;Put at start
       MOVEI T3,.CHSTX         ;Start-of-text
       IDPB T3,T1              ;...
       ADDI T4,2               ;Account for characters
       DO.
         ILDB T3,T2            ;Get char from IP buffer
         IDPB T3,T1            ;Append to output buffer
         CAIE T3,.CHDLE        ;Is this a DLE?
         IFSKP.                ;Yes - must quote it
           ADDI T4,1           ;Account for extra char of output
           IDPB T3,T1          ;And quote the DLE with another DLE
         ENDIF.
         AOBJN T4,TOP.         ;Increment count, decrement IP count, loop
       ENDDO.
       MOVEI T3,.CHDLE         ;Make encapsulation
       IDPB T3,T1              ;Append to output buffer
       MOVEI T3,.CHETX         ;End-of-text
       IDPB T3,T1              ;...
       ADDI T4,2               ;Account for the characters
       HRRZM T4,TIPOSZ         ;Save output byte count
       MOVE T1,[POINT 8,TIPOBF] ;Make output pointer
       MOVEM T1,TIPOPT         ;Set it up

;Routine to send next part of packet. Drops in from above (for first part) and
;called during 20ms scheduler cycle from TIPQOC for successive parts.

TIPOP1: MOVE T3,TIPOSZ          ;Get count of bytes left to send
       MOVE T1,T3              ;Make a copy of the count left
       CAMLE T3,TIPOQT         ;Less than amount of quota left?
        MOVE T3,TIPOQT         ;Nope. Use quota count, then
       SUB T1,T3               ;Compute new count
       MOVEM T1,TIPOSZ         ;And update it
       MOVE T4,T3              ;Copy size we are sending
       ADJBP T4,TIPOPT         ;Compute new pointer
       EXCH T4,TIPOPT          ;Get pointer, update new pointer
       MOVSI T1,TIPODN         ;Output done location
       HRR T1,MSTRDT           ;To master DTE
       MOVX T2,<.DFHSD,,.FEDLS> ;Sending string data, to data link
       HRL T3,TTIPLN           ;Line number (RH has # chars already)
       TXO T3,DTBYTM           ;Force byte mode
                               ;(T4 already setup with byte pointer)
       CALL FIXARG             ;Fix args
       NOSKD1                  ;Force DTEQ to not block
       CALL DTEQ               ;Queue up output string
        JRST TIPOXX            ;Failed...
       OKSKD1
       AOS TIQMNY              ;Increment DTEQ output count
       RET                     ;And done for now

;Here from TIPQOC when output already in progress - maybe time to continue

TIPORT: SKIPN TIPOWT            ;Output waiting?
       RET                     ;Nope. Done
       SETZM TIPOWT            ;Output no longer waiting
       JRST TIPOP1             ;Go send next part of packet

;Come here when output to line complete.
;Called from DTE interupt level.
;Doesn't do anything, since we wait for RSX acknowledge of output done

TIPODN: AOS TIDMNY              ;Increment count of DTE output dones
       SETOM TIPOFL            ;Remember that we saw this
       RET                     ;...

;Output failed. BUGCHK & release packet

TIPOXX: BUG.(CHK,TIPDTX,TTYSRV,SOFT,<TTIPDV - DTEQ failed>)
       OKSKD1                  ;Allow scheduling...
       JRST TIPOAB             ;Abort the packet (what else is there to do?)

;Come here on output buffer empty interrupt from RSX20F
;T2/ internal line number of tty
;Updates TIPOQT to full state and start next segment or next packet of output.

TIPDON: SKIPE TIPOAD            ;Output in progress?
       SKIPN TIPOFL            ;And DTE done seen yet?
       RET                     ;No. Do nothing
       SETZM TIPOFL            ;Clear DTE done seen
       SAVELN                  ;Save tty state
       LOAD T1,TSFMC,(T2)      ;Get allocation
       MOVEM T1,TIPOQT         ;Update it
       SKIPG TIPOSZ            ;Any IP bytes left?
        JRST TIPODD            ;Nope. All done with packet
       SETOM TIPOWT            ;Flag waiting to do output
       RET                     ;And return - 20ms code will do output later
TIPODD: AOS TIOMNY              ;Increment count of sent packets
TIPOAB: EA.ENT                  ;Enter extended section
       CALL RETOU1             ;Release output buffer back to internet
       RET                     ;Done

       SUBTTL Utilities for manipulating IP queues.

;Note: A system which has both an NFE and a TTY interface should not have these
;defined here.

       RESCD                   ;May be called from scheduler level

;Come here when finished reading input packet. Falls through to IPAPP.

TIPIDN: AOS TIIMNY              ;Increment count of input packets
       SETZ T1,                ;Clear
       EXCH T1,TIPIAD          ;Get input buffer address, clear it
;       JRST IPAPP              ;Fall through

;IPAPP - append an IP packet to the IP input queue
;Called in scheduler context
;Takes T1/ pointer to buffer
;Clobbers T1,T3

IPAPP:  PIOFF                   ;Make sure PI system is off (lock out AN20)
       MOVE T3,INTIBI          ;Get input queue tail pointer
       JUMPN T3,IPAPP0         ;Queue not empty, go append packet
       MOVEM T1,INTIBO         ;Was empty.  This is only item now.
       TRNA                    ;Make head and tail be same packet
IPAPP0:  STOR T1,NBQUE,(T3)     ;Make old packet point to newest packet
       MOVEM T1,INTIBI         ;Set new tail pointer
       AOS INTFLG              ;Cause Internet process to notice it
       PION                    ;Turn PI system back on
       RET                     ;Return to caller


;GETBUF - claim and check a free Internet buffer
;Call at interrupt level
;Returns +1 no free buffers, Internet fork prodded
;        +2 good buffer claimed, T1/ pointer to buffer
;Clobbers T1-T4

GETBUF::PIOFF                   ;Lock out rest of machine
       SOSGE INTNFI            ;Any buffers?
        AOSA INTNFI            ;No, fix count
         TRNA                  ;Yes, skip into main code
          JRST GETBFX          ;Go poke Internet fork
       MOVE T1,INTFRI          ;Get first buffer on queue
       TRNN T1,-1              ;Null queue is a bug
        BUG.(HLT,ENTBUF,TTYSRV,SOFT,<TTIPDV - free buffer queue fouled>)
       LOAD T2,NBQUE,(T1)      ;Get pointer to next buffer
       SKIPE T2                ;If non-zero
        SETSEC T2,INTSEC       ;Then make an extended address
       MOVEM T2,INTFRI         ;Update head of free queue
       PION                    ;Let rest of machine run again
       SETZRO NBQUE,(T1)       ;Clear pointer to next buffer
       CAML T1,[XWD INTSEC,INTFRE]     ;Range check the pointer
        CAMLE T1,[XWD INTSEC,INTFRE+INTFSZ-1]  ;...
         BUG.(HLT,ENTBF1,TTYSRV,SOFT,<TTIPDV - bad Internet buffer>)
       RETSKP                  ;Good return to caller

GETBFX: PION                    ;Turn PI system back on
       AOS INTFLG              ;Signal work to do
       SETZ T1,                ;Return 0 pointer
       AOS TIPINB              ;Increment no buffer count
;       BUG.(INF,TIPBFX,TTYSRV,SOFT,<TTIPDV - no free IP buffers>) ;Complain
       RET                     ;Return to caller

;RETBUF - release an Internet buffer to the Internet free pool
;Call at interrupt level
;Takes  T1/ buffer pointer
;Returns +1 always
;Clobbers T1-T2

RETBF0: EA.ENT                  ;Get into section 1
RETBUF::MOVE T2,T1              ;Copy for indexing below
       PIOFF                   ;Maintain queue integrity (lock out AN20)
       EXCH T1,INTFRI          ;Release to Internet
       STOR T1,NBQUE,(T2)      ;...
       AOS INTNFI              ;Count another free buffer
       PION                    ;Let rest of machine run
       RET                     ;Return to caller

;GETOUT - pull a packet off the Internet output queue
;Takes  P1/ pointer to NCT
;Returns +1 no packets to be sent
;        +2 success, T1/ address of packet to send
;Clobbers T1-T2

GETOUT: PIOFF                   ;Interlock with PI system
       SKIPN T1,NTIOBO(P1)     ;Load pointer to head of Internet queue
        JRST GETOU1            ;Nothing to do, quit
       LOAD T2,NBQUE,(T1)      ;Get successor packet
       SKIPE T2                ;Don't extend if nil
        SETSEC T2,INTSEC       ;Make extended address
       MOVEM T2,NTIOBO(P1)     ;Update queue header
       SKIPN T2                ;Now a null queue?
        SETZM NTIOBI(P1)       ;Yes, clear tail pointer as well
       SETZRO NBQUE,(T1)       ;Clear links in dequeued packet
       AOS (P)                 ;Prepare skip return
GETOU1: PION                    ;Reallow PI now that queues are safe
       RET                     ;Good return to caller

;RETOUT - Release current output buffer.
;Returns +1, always, with buffer put on Internet free list

RETOU0: EA.ENT                  ;Get into extended section, first
RETOU1: SKIPN T1,TIPOAD         ;Do we have an output buffer?
        RET                    ;Nope. Nothing to do, then
       SETZM TIPOAD            ;Nuke it
RETOUT: PIOFF                   ;Turn off interrupts through here
       MOVE T2,T1              ;Make a copy of it
       EXCH T1,INTNFB          ;Put this buffer on the free list
       STOR T1,NBQUE,(T2)      ;And link back rest of list
       AOS INTFLG              ;Make internet process notice this
       PION                    ;Allow interrupts again
       RET                     ;And return

       RESCD                   ;Default for TTYSRV
-------
26-Jan-88 13:15:40-PST,781;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jan 88 13:15:16-PST
Date: Tue 26 Jan 88 16:19:43-EST
From: Ken Rossman <[email protected]>
Subject: TOPS FTP update needed
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

I badly need to upgrade my hopelessly outdated TOPS-20 FTP software here on
CU20B.  Last I checked, there were two major versions floating around.  One
was from CMU, and another from Stanford.  Are these still around and
available for pilfering.  If so, where can find them?  Are there any other
versions anywhere worth considering?  Thanks.  /Ken
-------
26-Jan-88 19:05:08-PST,636;000000000001
Mail-From: VAF created at 26-Jan-88 19:04:37
Date: Tue 26 Jan 88 19:04:37-PST
From: Vince Fuller <[email protected]>
Subject: Re: TOPS FTP update needed
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Office: Pine Hall 147
Phone:  415-725-1392
Message-ID: <[email protected]>

The CMU FTP is available for pilferage from PS:<VAF.DST.FTP>*.* on Internet
host C.CS.CMU.EDU. It should probably be noted that I am no longer available
to maintain this program on a regular basis due to a change of employment...

       --Vince
-------
28-Jan-88 00:30:34-PST,2082;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 00:28:45-PST
Date: Thu, 28 Jan 88 00:33:24 PST
From: Mark Lottor <[email protected]>
Subject: another cause of IPFREE bugs
To: [email protected]
Message-ID: <[email protected]>

In IPIPIP in routine RETPKT.  From the comment:

  ;RETPKT      Release packet storage.
  ;If  a full size packet is being released and we are low on IMP input
  ;buffers, the packet will be used as an input  buffer.  Otherwise,  it
  ;gets  released to free storage.

The routine first checks to see if the "FULL SIZE PACKET" bit is on,
and if it is it assumes the packet is full size.  Unfortunately there
is a bug somewhere in the monitor that is either setting the full size
bit incorrectly, or setting the packet length word incorrectly.
We hit this condition today (after having the bugchk installed for many
months), and the supposed full size packet was only 40 words.  If this
packet gets reused as an input buffer it's almost a sure IPFREE bughlt.
The bugchk code follows and will save you from the bughlt.  I have not
found the actual bug yet.  We run a version of the Stanford 6.1 monitor.
----------------------------------------------------------------------

RETPKT::JE PFSIZ,(PKT),RETPK1   ; Is it a full size packet?
       CAML PKT,[INTSEC,,BF1822] ; Is this an NI buffer?
        CAML PKT,[INTSEC,,BF1822+<BF18SZ*INTBSZ>] ; ?
         SKIPA                 ; no
          JRST RETPK2          ; yes.  always release.
       MOVE T1,INTNFI          ; Yes.  Get number currently around
       CAML T1,INTNIB          ; Less than required?
        JRST RETPK1            ; No.
ifn nicsw,<
       push p,t1
       hlrz t1,-1(pkt)         ;get buffer header word (length field)
       trz t1,400000
       caml t1,maxwpm          ;big enough?
        jrst retpk9            ;yes, its ok
       BUG.(CHK,RETSPK,IPIPIP,SOFT,<IPIPIP: Internet buffer wrong size>,<<T1,D>>,<

Cause:  The monitor has detected an input buffer that is not of the
       maximum size required by this routine.

>)
       pop p,t1
       jrst retpk1             ;release bogus packet
retpk9: pop p,t1
>;ifn nicsw
-------
28-Jan-88 08:59:44-PST,1082;000000000000
Return-Path: <@CUNYVM.CUNY.EDU,@WESLEYAN.BITNET:[email protected]>
Received: from CUNYVM.CUNY.EDU by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 08:53:46-PST
Received: from WESLEYAN.BITNET by CUNYVM.CUNY.EDU ; Thu, 28 Jan 88 11:57:32 EST
Date: 28-JAN-1988 11:31:37.08
From: Douglas Bigelow <DBIGELOW%EAGLE.WESLEYAN.EDU%[email protected]>
Subject: Three meg memory upgrade
To: [email protected]

Wesleyan has two 2060s, soon to be reduced to one.  However, we're trying
to get another five years out of the remaining system and we're considering
a mid/end life kicker.  I'm trying to pick up an MCA25 cache upgrade, and
I'm considering a boost from two meg of MG memory to three.

The question is, how much of a performance boost will an extra megaword give
us?  Is it worth the estimated $15K or so it will cost me on the used
market?  I'd appreciate any opinions from anyone who has gone from 2M to
3M and paid any attention to the results.

Second, do any of you have any memory or cache for sale?

Thanks in advance,

Doug

28-Jan-88 09:10:08-PST,752;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 09:05:35-PST
Date: Thu 28 Jan 88 09:07:57-PST
From: Eric M. Berg <[email protected]>
Subject: Re: TOPS FTP update needed
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home)
Message-ID: <[email protected]>

One version of the Stanford sources seem to be in ps:<TCP.FTP> on Score.
You need to be in the appropriate user-group in order to be able to grab
them; most systems staff at other sites with guest accounts on Score appear
to be in that group.
-------
28-Jan-88 11:17:30-PST,1200;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 28 Jan 88 11:16:37-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 28 Jan 88 11:19:42 PST
Date: Thu, 28 Jan 88 09:47:55 PST
From: Mark Crispin <[email protected]>
Subject: Re: another cause of IPFREE bugs
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Good detective work, Mark!  Who knows, maybe this is "the" bug...

I think you may be able to use the following version of your fix, which
is just a little more elegant...

IFN PANDASW,<   ;[2]
       LDB T2,[POINT 17,-1(PKT),17] ; Get length field from buffer header
       CAML T2,MAXWPM          ; Big enough?
       IFSKP.
         BUG.(CHK,RETSPK,IPIPIP,SOFT,<IPIPIP: Internet buffer wrong size>,<<T2,D>>,<

Cause:  The monitor has detected an input buffer that is not of the
       maximum size required by this routine.

>)
         JRST RETPK1           ; Release bogus packet
       ENDIF.
>;IFN PANDASW
-------
29-Jan-88 10:57:47-PST,1452;000000000000
Return-Path: <RMF%ADMIN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 29 Jan 88 10:54:57-PST
Received: by lindy.stanford.edu; Fri, 29 Jan 88 11:00:23 PST
Received: by Forsythe.Stanford.EDU; Fri, 29 Jan 88 10:46:16 PST
Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Fri, 29 Jan 88 09:51:22 MST
Date: Fri 29 Jan 88 09:47:32-MST
From: RMF%ADMIN%[email protected]
Subject: MM
To: [email protected]
Phone: (403) 240-6052
Organization: Mount Royal College; Computer Operations
Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6
Message-Id: <12370496631.46.RMF@ADMIN>

       I am running an old version of MM (v 6.1(1144) and have
       suddenly come across this error '?node name cache overflow'.

       I have been continually updating the domains.txt with BITnet
       nodes as I need them.

       What can I do to get rid of this error message?  (besides
       of course removing nodes from my domains file).

       I know somebody will no doubt say 'get the latest version
       that uses the new domain resolver'.  Don't worry, the
       cheque is in the mail for it.

       /Russ

-----
Russell M Forster

DECnet: RMF @ { Admin | Flux | Stasis | Ins }
BITnet: RForster @ UncaEdu.BITnet
ARPA:   Oc.Russ @ CU20B.Columbia.Edu
USEnet: uunet!calgary!vaxd!forster
-------
5-Feb-88 16:53:56-PST,462;000000000000
Return-Path: <[email protected]>
Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Fri 5 Feb 88 16:52:07-PST
Date: Fri 5 Feb 88 16:57:09-PST
From: Len Bosack <[email protected]>
Subject: Looking for a program: PANTT
To: [email protected]
Message-ID: <[email protected]>

PANTT is a project tracker written by Peter Hurley at DEC. Does anyone
have an FTP-able copy?

Thanks,
Len Bosack
-------
6-Feb-88 20:39:16-PST,1800;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 6 Feb 88 20:36:40-PST
Date: Sat, 6 Feb 1988  21:41 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: BSPLIT - A BBOARD file maintainer

Like most sites, I use a nightly batch job containing a string of MM
steps with a DELETE BEFORE -n setup to keep my BBOARD files down to
"reasonable" sizes.  The value for n has always been an empirical
guess, usually wrong, and sometime a problem if done in one MM process
instead of one for each.

For those of you who keep your BBOARD files in separate subdirs and
keep old messages as well, I suggest getting BBTrim from CU20B.
However, for the rest of us who do not care to keep old messages, I
offer BSPLIT, based on MSPLIT.

BSPLIT steps down through a mail file under exclusive use, message by
message, until it passes through enough messages such that the
remainder of the file is less than some hardwired value, default is
100 disk pages.  The file is then rewritten with that remainder, and
the saved last write date/times are restored.  Files already under the
limit are left alone.

One advantage to this program, besides being small and fast, is the
guesswork for the value of n is gone.  Because it retains the original
last write date/times, the BBOARD program will no longer have to
unnecessarily read in a file to check the messages because the MM
method was the last to update that information.

Source is in SRC:<SOURCES.UNSUPPORTED>BSPLIT.MAC on this host, and is
small enough to mail to off-net requestors.  As usual, please send
back any improvements for redistribution.

--Frank
9-Feb-88 10:29:22-PST,4598;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 10:22:34-PST
Date: Tue 9 Feb 88 11:27:44-MST
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Re: BSPLIT - A BBOARD file maintainer
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

I'd been wondering whether to post this, and Frank Wancho's
submission indicates there may be interest in other places too.

About 6 weeks ago, I wrote a PCL procedure to apply
MSPLIT to our bboards (having tired of doing it by hand).
We always preserve the old contents as bbdname_yymmdd.txt,
where yymmdd is the stamp of the last message in the file,
so a directory listing shows the files chronologically as
well as alphabetically (I never liked schemes like
"bbdname_1st_qtr.txt").

BBDSPLIT runs in a nightly batch job.

COMMAND BBDSPLIT (
       NOISE "large mail file(s)";
       FILELIST (INPUT,
               DEFAULT_DEV "DSK",
               DEFAULT_NAM "*",
               DEFAULT_EXT "TXT")
       );
!-----------------------------------------------------------------------
! Purpose:
!       Split mail or  bulletin board  files which are  larger than  250
!       disk pages.  The MSPLIT utility  will split FOO.TXT into  FOO.1,
!       FOO.2, ... (each of size ~240 pages), + FOO.TXT (the  remainding
!       most recent messages).  FOO.1  is copied to  OLD:FOO_yymmdd.TXT,
!       so that successive such archives will by named  chronologically;
!       yymmdd is the year, month, day  of the first message in  FOO.TXT
!       (and presumably close  to the  last message in  FOO.1).  If  the
!       creation of  the  archive  file is  successful,  then  FOO.1  is
!       expunged.  It is expected that this command will be executed  in
!       a nightly batch job  to ensure that  bulletin board files  never
!       get much over 250 pages.
!
! Usage:
!       BBDSPLIT filelist (default *.TXT)
!
! Remarks:
!       There is no provision  for handling FOO.2 et  al, but if such  a
!       file is found to  exist, the procedure will  abort, and the  job
!       can be handled manually.
!
! Author:
!       Nelson H.F. Beebe, Center for Scientific Computing, South
!       Physics Building, University of Utah, Salt Lake City, UT 84112.
!
! Date:
!       [15-Dec-87]
!
!------------------------------------------------------------------------
BEGIN

INTEGER count;
INTEGER handle;
INTEGER tad_value;  ! internal date and time value;
INTEGER year,month,month_day,week_day,hour,minute;

STRING arc_file;
STRING line;
STRING old_file;
STRING second_file;

DO
   IF $FileInfo_I($FILEL, $FBSIZ) > (5 * 512 * 250) THEN
   BEGIN
       DISPLAY "[Splitting " + $FILES + "]";
       INVOKE "BBD:MSPLIT.EXE";
       TYPEIN $FILEL;
       old_file = $File_Dev($FILEL) + ":" +
           "<" + $File_Dir($FILEL) + ">" +
           $File_Nam($FILEL) + ".1";
       second_file = $File_Dev($FILEL) + ":" +
           "<" + $File_Dir($FILEL) + ">" +
           $File_Nam($FILEL) + ".2";
!       display "%%% Debug: old_file = " + old_file;
       count = 0;
       DO      !Wait for completion; PCL lacks a fork wait, sigh...
           BEGIN
               CALL $Wait(5);
               count = count + 1;
               IF count > 12 THEN
                   ABORT "MSPLIT apparently did not create " + old_file
           END
       UNTIL $IsFile(old_file) <> 0;

       IF $IsFile(second_file) <> 0 THEN
           ABORT "MSPLIT: Cannot handle split into more than one file--found "
               + second_file;

       DOCOMMAND ORIGINAL "UNIX:HEAD -1 " + $FILEL + " >msplit.tmp";

       handle = $Open("msplit.tmp",$Input);
       line = $Read(handle);
       call $Close(handle);
       DOCOMMAND ORIGINAL "delete msplit.tmp";

!       DISPLAY "%%% Debug: first line = " + line;

       call $ExpandTad($InputTad(line),
           year,month,month_day,week_day,hour,minute);

!       DISPLAY "%%% Debug: " +
!           " year: " + $String(year) +
!           " month: " + $String(month) +
!           " month_day: " + $String(month_day) +
!           " week_day: " + $String(week_day) +
!           " hour: " + $String(hour) +
!           " minute: " + $String(minute);

       arc_file = "OLD:" +
           $File_Nam($FILEL) + "_" + $String(year - 1900) +
           $String(100 + month + 1)[2:*] +
           $String(100 + month_day + 1)[2:*] + ".txt";
       DOCOMMAND ORIGINAL "COPY " + old_file + " " + arc_file;
       IF $IsFile(arc_file) <> 0 THEN
           DOCOMMAND ORIGINAL "DELETE " + old_file + ",
EXPUNGE


"
       ELSE
           ABORT "MSPLIT: could not save " + old_file + " as " + arc_file
   END
UNTIL $NextFile = 0
END; ! BBDSPLIT
-------
9-Feb-88 10:31:27-PST,794;000000000000
Return-Path: <[email protected]>
Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 10:22:43-PST
Date: Tue 9 Feb 88 13:11:19-EST
From: Donna Lynch <[email protected]>
Subject: Spell
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

Is there a version of SPELL for TOPS20?

Is anyone familiar with the one we are currently running? I don't know too
much about it.  It was here long before I was. It was apparently
written by Ralph Gorin with mods by CMU.  The EXE file is dated 7-Sep-79.
It has curiously stopped working. I don't know if I deleted a file it might
be looking for or what.  It doesn't stop and show the misspelled word anymore.

Any help?

Thanks,
Donna
-------
9-Feb-88 14:02:10-PST,1340;000000000000
Return-Path: <RMF%ADMIN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 13:59:53-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 14:05:55 PST
Received: by Forsythe.Stanford.EDU; Tue,  9 Feb 88 14:04:24 PST
Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Tue, 9 Feb 88 14:54:48 MST
Date: Tue 9 Feb 88 14:46:37-MST
From: RMF%ADMIN%[email protected]
Subject: Autopatching PEP database
To: [email protected]
Phone: (403) 240-6052
Organization: Mount Royal College; Computer Operations
Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6
Message-Id: <12373434662.45.RMF@ADMIN>

       I have a problem, my PEP database is bge corrupted and lost.
       It seems that due to lack of foresight, I didn't manage to
       get one to tape.  Does anyone have a PEP database to AP15
       that I could get a copy of?  Or, does someone know how to
       convence PEP that I have patches up to AP15 and continue on?

       If not, what was the first autopatch to patch 6.1?

       /Russ

-----
Russell M Forster

DECnet: RMF @ { Admin | Flux | Stasis | Ins }
BITnet: RForster @ UncaEdu.BITnet
ARPA:   Oc.Russ @ CU20B.Columbia.Edu
USEnet: uunet!calgary!vaxd!forster
-------
9-Feb-88 14:26:19-PST,1376;000000000001
Return-Path: <RMF%ADMIN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 14:24:38-PST
Received: by lindy.stanford.edu; Tue, 9 Feb 88 14:30:24 PST
Received: by Forsythe.Stanford.EDU; Tue,  9 Feb 88 14:19:24 PST
Received: from ADMIN by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Tue, 9 Feb 88 15:04:26 MST
Date: Tue 9 Feb 88 14:56:29-MST
From: RMF%ADMIN%[email protected]
Subject: LAT's
To: [email protected]
Phone: (403) 240-6052
Organization: Mount Royal College; Computer Operations
Postal-Address: 4825 Richard Rd. S.W.; Calgary, Alberta, T3E 6K6
Message-Id: <12373436459.45.RMF@ADMIN>

       Is there a JSYS that can be called that will return the LAT
       number and the Port number within that LAT.  We are currently
       running PHOO from Columbia University (thanks Ken :-) ) and
       it does a terminal port to computer port trace back (translation
       we know what physical terminal is being used by whom).  With
       the move to LAT's we lost that capability (or have we?)

       Any info would be appreciated.

       /Russ

-----
Russell M Forster

DECnet: RMF @ { Admin | Flux | Stasis | Ins }
BITnet: RForster @ UncaEdu.BITnet
ARPA:   Oc.Russ @ CU20B.Columbia.Edu
USEnet: uunet!calgary!vaxd!forster
-------
9-Feb-88 15:00:06-PST,721;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Tue 9 Feb 88 14:58:21-PST
Date: Tue 9 Feb 88 18:01:50-EST
From: Ken Rossman <[email protected]>
Subject: Re: LAT's
To: RMF%ADMIN%[email protected], [email protected]
In-Reply-To: <12373436459.45.RMF@ADMIN>
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

I went hunting for a system call that would return the port number on a LAT
box, but never did find one.  Closest I came was the (unsupported) NTINF%
Jsys, but that doesn't tell you port numbers on the box...  /Ken
-------
10-Feb-88 11:42:07-PST,581;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 10 Feb 88 11:38:34-PST
Date: Wed, 10 Feb 88 11:13:56 PST
From: Mark Crispin <[email protected]>
Subject: Horoscope program
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Does anyone have the old old library of Basic games still lying around?
I'm looking for a horoscope program for a friend.
-------
10-Feb-88 17:33:20-PST,788;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 10 Feb 88 17:31:41-PST
Date: Wed 10 Feb 88 19:36:44-CST
From: Clive Dawson <[email protected]>
Subject: TAPELOOK
To: [email protected]
Message-ID: <[email protected]>

Whenever I need to do some quick examination of magnetic
tapes to check things like record lengths, etc., I generally
use a utility called TAPELOOK which has been floating around
various hosts for years.  Now I have a need to look beyond
the first record of each file, so I need to hack it a bit.
Does anybody know where the source to TAPELOOK might be found,
or can anybody recommend another general purpose tape utility
to dump the contents of a random tape?

Thanks,

Clive
-------
11-Feb-88 08:32:15-PST,2844;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 08:30:35-PST
Date: Thu 11 Feb 88 11:33:44-EST
From: Ken Rossman <[email protected]>
Subject: Re: BBTRIM options
To: [email protected], [email protected]
cc: [email protected], [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

 Before the last -20 is shut down, I would hope *someone* there would take
 the time to accumulate all the local mods and neat hacks on to tape for
 the rest of us to continue to use.  If such an archive isn't proposed to
 be kept at SCORE, then I would hope we get the opportunity here (along
 with all our other collections, except the KERMIT stuff which Frank and
 crew is more than welcome to keep current on his machines)...

Since this topic has been touched on, I'd like to make a query to those
remaining TOPS sites before our 20's are gone (in just a precious few
months now).  We have lots of nice things here that we've all spent lots of
time developing, and which I'd sure hate to see die completely (I've spent
a large part of my life developing code that is now on the verge of
becoming totally useless to us here)...

If I were to coordinate things here and group files together nicely into
reasonably organized directory trees, would someone out there like to copy
the whole mess over to their local machine(s) and be the keepers hereafter
of whatever nice archives we have around here?

I can stick them on tape and/or just point networked folks at the places to
look on CU20B to pick things up here.

Any takers?

 I have seem rumors of an MM implementation for Unix-like systems which
 Ken has mentioned on the TOPSUX list.  Will it be made available to the
 world (unlike the SRI version)?  More importantly, will there be an
 MMAILR/SMTJFN/MAISER to round out the package??  Even if it's only MM,
 I'd be interested in reverse porting it to TOPS20 to be able to handle
 arbitrarily large message composition and large mail files using KCC and
 its extended addressing option...

Our C version of MM is still in alpha test here, but is looking pretty good
so far.  Runs fine under Unix at this point, and VMS porting will probably
start within a few months, though I can make no promises about this.

Under Unix, MM talks to sendmail for delivery.  Under VMS, it will need
another type of delivery workhorse to talk to.  Perhaps a separate,
generically written, mail delivery daemon system ought to be written to go
along with MM, such that it could be ported, along with MM, to other OS's.
But so such plans are in the works here at CU at this time.  FYI, /Ken
-------
11-Feb-88 10:49:08-PST,744;000000000000
Return-Path: <[email protected]>
Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 10:49:05-PST
Date: Thu 11 Feb 88 10:49:07-PST
From: Rich Alderson <[email protected]>
Subject: version 7 training session
To: [email protected]
Message-ID: <[email protected]>

Dave Lomatire, Jack Wong, and Ron Anderson of Digital are scheduled to come in
next week (16-18 February) to install FT1.  They want to have a training
session on Thursday afternoon, 3:00 to 5:00, in Sweet 403 (the 4th floor
conference room).

Please let me know if you plan to attend so that we can be assured of handouts
and such.

                                                               Rich Alderson
-------
11-Feb-88 13:22:31-PST,790;000000000000
Mail-From: VAF created at 11-Feb-88 13:21:49
Date: Thu 11 Feb 88 13:21:48-PST
From: Vince Fuller <[email protected]>
Subject: Re: BBTRIM options
To: [email protected]
cc: [email protected], [email protected],
   [email protected], [email protected]
In-Reply-To: <[email protected]>
Office: Pine Hall 147
Phone:  415-725-1392
Message-ID: <[email protected]>

One question - would you be interested in accumulating "nice things" developed
at other sites? I, too, spend a number of years writing code which will soon
be discarded (C.CS.CMU.EDU will probably be shut-off within the next year) and
would be interested in contributing anything people might find useful.

       --Vince
-------
11-Feb-88 16:07:10-PST,786;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 16:06:22-PST
Date: Thu 11 Feb 88 19:09:40-EST
From: Ken Rossman <[email protected]>
Subject: Re: BBTRIM options
To: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

There's certainly no point in our collecting up nice things for 20's here,
since our machines are going out the door soon, but whoever might want to
take over keeping archives of neat 20 things might want to coordinate
collection from various sites.  /Ken
-------
11-Feb-88 18:55:39-PST,475;000000000000
Mail-From: VAF created at 11-Feb-88 18:55:18
Date: Thu 11 Feb 88 18:55:18-PST
From: Vince Fuller <[email protected]>
Subject: Re: BBTRIM options
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Office: Pine Hall 147
Phone:  415-725-1392
Message-ID: <[email protected]>

That's basically what I had in mind... Any volunteers?

       --Vince
-------
11-Feb-88 19:45:50-PST,1220;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 19:45:40-PST
Date: Thu, 11 Feb 1988  20:26 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   Ken Rossman <[email protected]>
Cc:   [email protected], [email protected], [email protected]
Subject: TOPS-20 Collection (The Seattle Project)
In-reply-to: Msg of 11 Feb 1988  17:09-MST from Ken Rossman <sy.Ken at CU20B.COLUMBIA.EDU>

The unattributed extracts quoted in your message were from a message
of mine.  My offer to provide archive space still stands.  However, I
believe that, for historical reasons, SCORE has the right of first
refusal.  Also, last I heard, SCORE will not be going away any time
soon (and neither will this host).  One thing we lack here is a
knowledgable volunteer with sufficient spare time to organize and
maintain the collection.  SCORE may be in a better position on that
aspect.

Did someone at Rutgers dump their structures to tape before they shut
down their 20?  I'd hate to see that material lost...

I hope the title of this project is not too obscure...

--Frank
11-Feb-88 22:11:12-PST,1685;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 11 Feb 88 22:10:40-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 11 Feb 88 22:13:48 PST
Date: Thu, 11 Feb 88 21:39:28 PST
From: Mark Crispin <[email protected]>
Subject: TOPS software repository
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Friends -

    The idea is excellent, and I volunteer to help as much as PANDA and
I are able to.  Unfortunately, I can't recommend PANDA as the primary
repository because (1) PANDA uses RM03's, so even with a dedicated RM03
for the repository the limit would be only 30,000 pages, (2) I am going
through a personal crisis (a messy divorce) which may end up with PANDA
being off the air for some period of time.

    Score seems to be the Stanford DEC-20 that will stay around for a
while, and since the TOPS-20 archive is already located there I hope we
can prevail upon Score's management and systems programmer to agree to
establish a repository there.

    You can help!  Before the plug is pulled on your DEC-20, please
write a tape with your site's goodies and send them to me:
       Mark Crispin
       c/o SUMEX Computer Project
       Medical School Office Building Room 249
       Stanford, CA  94305-5477
[If you send the tape to my home I'll get a yellow slip and have to
pick it up at the Post Awful...]  I'll make sure the files end up at the
right place, and will try to establish a library of the original tapes.
-------
12-Feb-88 07:08:54-PST,1921;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU,@PANDA.PANDA.COM,@XERXES.STACKEN.KTH.SE:JMR%[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 12 Feb 88 07:08:25-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Fri, 12 Feb 88 07:09:27 PST
Received: from XERXES.STACKEN.KTH.SE by PANDA.PANDA.COM with Cafard; Fri, 12 Feb 88 07:04:02 PST
Received: from rtr08b.kth.se (not validated) by XERXES; Fri, 12 Feb 88 15:57:54 A
Received: from KICKI.#DECnet by rtr08b.kth.se; Fri, 12 Feb 88 15:54 MET
Date: 12 Feb 1988 (Friday) 1429-LOC
From: [email protected]
Subject: PDP-6/10 software repository.
To: [email protected], [email protected], [email protected],
To: [email protected], [email protected], [email protected]
Cc: [email protected]

We would love to volunteer as a PDP-6/10 software repository. I saw MRC was
also willing to volunteer, and putting the (same) eggs into two baskets ...

We (the Stacken Computer Club, the students' computer club at the Royal
Institute of Technology in Stockholm, Sweden) are running a number of 10's
and 20's as hobby computers, and we're collecting all sorts of useful hard-
ware and software for the PDP-6/10 (TOPS-10/TOPS-20/TENEX/ITS).

We're not on the ARPA Internet (yet, at least), so we would have to get the
stuff on tape.

Our address:
 Stacken Computer Club,
 c/o Department of Numerical Analysis and Computing Science,
 Royal Institute of Technology,
 S-100 44 Stockholm,
 Sweden.

Yours,
 Jan Michael Rynning (software)        Peter Lothberg (hardware)
 [email protected]                       [email protected]
 +46-8-7906288                         +46-8-699720
                                       ([email protected])

P.S. Do you know anyone who has a PDP-6 to give away? We've got the rest
of them (KA, KI, KL, and KS). We intend to run it if we get one.


16-Feb-88 10:54:03-PST,1902;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 16 Feb 88 10:51:25-PST
Date: 16 Feb 1988 1357-EST
From: "Joe Dempster, DTN 336.2023, AT&T 609.273.2023" <[email protected]>
To: [email protected]
Subject: YIPYIP/2020 HW problems.
Message-ID: <"MS11(6040)+GLXLIB6(0)" 12375238833.283.30.6223 at TOPS20.DEC.COM>

YIPYIP (the DEC10 history project's 2020) is in bad shape.  The
system had a problem a few weeks ago which corrected itself after
being powered down for the night.  I should say the problem went
solid last thursday, powering it down for the night probably
corrected nothing.

The problem:

The system hangs with a the FAULT ligh on (as expected).  On REBOOT
the console attempts to load its BOOT routine.  Nothing really happens,
the only character that gets displayed on the console is a single solid
block.  Approximately 15 seconds later the FAULT light comes on and the
system is hung.

Trouble shooting to date:

I have a complete set of spares (with the exception of a console
board which I think is bad).  I swapped all the KS modules, one at
a time, and the same identical problem reappeared each time.  I
also swapped the 1st and last memory modules, but the problem didn't
change.

Conclusions:

Since the system hangs before anything else can start (the light only
comes on when it hangs, and never blinks) I conclude that the problem is
probably with the console board.

However, before I try to "fix" the console board (don't know how
exactly that will happen) I thought I'd get a second opinion.  There
is a chance that the problem may be with the RH11's, but I haven't
torn into that area yet (and hope I don't have to).

I'd be appreciative of any tips or advice on working this outage.
Anyone know of where a spare KS might be purchased?

/joe
  --------
16-Feb-88 13:19:25-PST,1499;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 16 Feb 88 13:17:20-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Tue, 16 Feb 88 13:20:15 PST
Date: Tue, 16 Feb 88 12:32:04 PST
From: Mark Crispin <[email protected]>
Subject: Re: YIPYIP/2020 HW problems.
To: [email protected]
cc: [email protected]
In-Reply-To: <"MS11(6040)+GLXLIB6(0)" 12375238833.283.30.6223 at TOPS20.DEC.COM>
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Joe -

    This may sound too obvious, but have you checked all the power
supplies?  The 15 second delay sounds suspiciously like a software
timeout.  First check the main KS10 power supply (the Mighty Mite
with zillions of wires attached to it) and make sure the voltages
all look reasonable.  Next, check the BA11 power supply.

    DEC charges $800 to fix the Mighty Mite, but LH Research (the
manufacturer) will charge only $400.  I wouldn't advise trying to
fix it yourself; it's quite hairy.

    You might also want to check your console terminal to make
sure it's OK.

    I don't think it's the RH11's or the memory.  You should be
able to talk to the 8080 console program.  It may be the console
board, but that 15 second timeout suggests that it is happy and
something else is sick.

-- Mark --
-------
18-Feb-88 15:38:15-PST,5351;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 18 Feb 88 15:35:09-PST
Date: Thu 18 Feb 88 17:25:49-CST
From: Clive Dawson <[email protected]>
Subject: [Bill Barns  <[email protected]>: Re: ftp hang while trying to talk to cu20b.columbia.edu]
To: [email protected]
Message-ID: <[email protected]>

I'm forwarding this message for the benefit of those who don't
see the TCP-IP traffic.  It's unclear how much of this is
relevant to the "current" TOPS-20 code, but at least it will
become part of the TOPS-20 archives.
               ---------------

Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by MCC.COM with TCP; Thu 18 Feb 88 17:20:12-CST
Received: from OFFICE-1.ARPA by SRI-NIC.ARPA with TCP; Thu 18 Feb 88 10:57:50-PST
Date: 18 Feb 88 13:50 EST
From: Bill Barns  <[email protected]>
Subject: Re: ftp hang while trying to talk to cu20b.columbia.edu
To: Ken Rossman <[email protected]>
Cc: [email protected]
Message-ID: <TYM-WWB-D59IT@OFFICE-1>
In-reply-to: <[email protected]>

Readers not interested in the guts of TCP implementation might as well skip
this message.

I've had to muck about with Tenex TCP which is "related" to TOPS-20 TCP, and
has much worse constraints with buffer space due to being part of a single
section monitor.  Some of what I've done to try to cope with free storage
problems may be relevant to your monitor, but only you can tell for sure.  I
think there must be a jillion locally-hacked subflavors of this TCP code, and
who knows how much resemblance remains between yours and mine.  I can say that
I do have a copy of "DEC's source" as of about 2.5 years ago and it seems to
have the same problems which I'm about to describe, so maybe you have them too.

Refer to the TCP packetizer near PKTZ10 (in source file TCPPZ or TCPTCP).  The
call on TCPIPK will nonskip-return if you are indeed out of space.  Code in a
literal tries to queue you to retry but as I understand the code, there's a
problem.  Your TCB is not queued anywhere at this instant, but TSFP or TSEP is
very probably on (else why are you here?)  So ENCPKT and/or DLAYPZ will
effectively no-op and you're out of the packetizer without being queued
anywhere.  Any future Force or Encourage will meet the same fate because of
those same bits.  You're trapped in the Twilight Zone.  Cure: SETZRO
<TSFP,TSEP>,(TCB) as the first thing in the literal that calls ENCPKT after
TCPIPK failure.  If this scenario happened, it would be likely to yield the
symptoms described by David Herron; but so might other things.

I made several changes to TCPPRC routine, a little too long to list here.
Basically they are: not to run a free-storage scavenge more than once a second,
so as not to hog the CPU; and don't run TVTOPR on any pass that did a scavenge,
in hopes of making fewer and bigger Telnet packets.

It's better to avoid running out of space in the first place, even if that
takes something drastic.  With an 1822 interface it's absolutely crucial not to
let the input interrupt level run out of buffers, so as to avoid RFNM-related
deadlocks.  Solution: Never give Internet the "last" input buffer.  Put it back
on the input buffer list after processing the 1822 leader.  I suspect this
isn't your problem though, since your addresses are class B/C, thus probably
not 1822.

It would help to have some idea of what most of your space is being used for
when you run out.  Absent specific data, I'd suspect huge retransmit queues
caused by big windows and slow gateways between you and the FTPers.  You can
brute-force cope with this somewhat either by clamping received windows, or by
finagling the packetizer to refuse to packetize for any connection that has
more than n packets on the RX queue, or where the first packet on the RX queue
has actually been retransmitted (a quick test for congestion).  This will slow
things down, but that's what you need to do when you're short of space.  You
can condition this code on INTFSP being less than some threshold and shove it
into the PKTZ10 area too.

If you have a lot of TVT (Telnet) tinygram traffic, you might want to add code
in this same area to ask TCPIPK for only the size of buffer you need, rather
than a max size buffer, when space is below the threshold.  Also in the OPSCAN
routine (TTTVDV or TTANDV source file?) around OPSCA1+10 or so, just after the
JUMPE T3,OPSCA7 you might add JN TSEP,(TCB),OPSCA7 which will prevent this
routine from undoing any delay previously imposed by some other routine.
Further down in this same routine you should also have a change published by
Westfield and Crispin about 2-3 years ago which includes a test on whether the
RX queue is empty.  This change is mainly performance-oriented but will save
free storage too in some situations.

These cover the highlights of things I've done that seem relevant.  You can
talk bits with me further if you're interested, of course.  I wanted to post
this much in case it stirs up any comments from TOPS-20 hackers out there.
Maybe someone out there has already done these changes in a form that will
slide directly into CU20B monitor.  -b

-------
22-Feb-88 21:59:17-PST,886;000000000000
Return-Path: <[email protected]>
Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Mon 22 Feb 88 21:58:12-PST
Date: Mon 22 Feb 88 22:02:43-PST
From: Len Bosack <[email protected]>
Subject: REL Block 1070 (Long Symbol Request)
To: [email protected]
Message-ID: <[email protected]>

Does anyone have an easy (well..) way to get MACRO/FAIL/MIDAS to generate
block type 1070? What I have in mind is something like:

LSDEF VERYLONGSYMBOLNAME,expr-that-MACRO-can-collapse
and
LSEXT symbol-to-be-defined,VERYLONGSYMBOLNAMESTILLNOLOWERCASE

In the first case VERYLONGSYMBOLNAME would be defined by LINK, able to be
referenced by the second case. .LSEXT would define a short symbol to be
the value of the long symbol.

These would make the job of porting C programs written for UN*X much, much
easier.

Len
-------
24-Feb-88 11:16:29-PST,660;000000000000
Return-Path: <[email protected]>
Received: from R20.UTEXAS.EDU by SCORE.STANFORD.EDU with TCP; Wed 24 Feb 88 11:14:10-PST
Date: Wed 24 Feb 88 13:17:57-CST
From: [email protected]
Subject: Bug in IPHOST ethernet status
To: [email protected]
Message-ID: <[email protected]>

       The ethernet status command of IPHOST has been working on
       out V5.4 monitor until I installed 6.1 AP16 version of TCP/IP.
       Now it behaves the same as ov v6.1 machine.  You get three lines
       of channel info then ?JSYS error at user PC 6125.

       Does anybody have a patch for IPHOST ot tcp/ip to fix this.

       Dak
-------
29-Feb-88 16:50:47-PST,1015;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 29 Feb 88 16:47:00-PST
Date: Mon 29 Feb 88 19:00:01-EST
From: Ken Rossman <[email protected]>
Subject: IP bugs & fixes
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

Many thanks to all who helped get me on the right track towards fixing up
the CU20B monitor's IP code (in particular, thanks go to Clive Dawson and
Frank Wancho).  We're running the new patches now, and things "feel" a lot
better so far, though I haven't done any sort of testing to see how much
better things are now.

If some of you who (semi-)regularly FTP things from CU20B could maybe drop
me a note and let me know if things are going better with FTP connections,
I'd really appreciate it.  Particularly those of you who grab Kermit
updates now and then.

Thanks again, /Ken
-------
2-Mar-88 00:36:13-PST,903;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 2 Mar 88 00:33:33-PST
Date: Wed 2 Mar 88 00:38:08-PST
From: Eric M. Berg <[email protected]>
Subject: Job Vacancy: System Programmer at Stanford GSB
To: [email protected]
Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home)
Message-ID: <[email protected]>

The Stanford Graduate School of Business is seeking a system programmer with
experience in EITHER the VAX/VMS, OR the TOP-20, Unix, and TCP/IP computing
environments.

Full details are in the file
 PS:<A.ERIC>Job-Description-Sysprog.TXT
which is available from host GSB-How.Stanford.EDU by Anonymous FTP.

Specific questions may be directed to the undersigned.

                                               Eric M. Berg
                                               Stanford GSB Computer Facility
                                               [email protected]
-------
2-Mar-88 13:06:27-PST,2713;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Wed 2 Mar 88 13:05:42-PST
Date: Wed, 2 Mar 1988  14:10 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: More on TCP performance

Around mid December, I started noticing TCBs in NOT.NOT states
accumulating in the system, all indicating "partial pkt received"
status, and all from incoming FTP connections.  After some arbitrary
time, the load shot up into the 40's and the system no longer
responded and had to be rebooted.  Because we have a high volume of
FTP connections, this sequence repeated about every three days or so.

I tracked down that it was NETSRV causing the load to increase.  I
recompiled NETSRV, commenting out the section which put the program in
Queue 0.  We no longer have problems with wild load factors.  If
enough of those NOT.NOTs accumulated, the system now gets a chance to
eventually garbage collect and the NOT.NOTs vanish.

That was OK for a while.  But, I was receiving complaints from TAC
users of long response times when the load was low (less than .5) and
few, if any, users on the system.  At those times, there were several
of those NOT.NOTs hanging around, not yet enough for garbage
collection to kick in.  So, I trudged through the code and found the
flag word which causes the garbage collection to occur: INTSVR.  When
I set it to -1, the NOT.NOTs vanished, and from personal observation
through a TAC connection, the response time immediately improved every
time this was done.  So far, there have been no side effects noticed.
In fact, until we had one of those rare clock error stops Monday
evening, we had been up for 26 days straight!

There are several open questions concerning these NOT.NOTs:

1.  Is there a pattern?  Well, yes, after a fashion - almost all of
them are from Class B hosts connected through Fuzzball gateways, most
of which are on NSFNET.  This may be purely coincidental.  Apparently
the Fuzzballs are severely congested.

2.  If the TCBs are already in a NOT.NOT state, why should it matter
if there is a "partial packet received" and just flush it?

3.  Why is it that even a small (~5) handful of these NOT.NOTs (as
opposed to the same or higher number of active connections) seem to so
severely impact network response time (20 to 40 second or more for a
character echo)?

I don't have the answers.  Only a handful of hosts probably even see
enough FTP connections to provoke this condition.  If you have some
thoughts or answers, I'd like to hear from you.

--Frank
4-Mar-88 14:10:54-PST,2074;000000000000
Return-Path: <[email protected]>
Received: from SEED.AMS.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Mar 88 14:09:04-PST
Return-Path: <@KL.SRI.COM:[email protected]>
Received: from KL.SRI.COM by SEED.AMS.COM with TCP; Thu 3 Mar 88 04:40:11-EST
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Sat 27 Feb 88 05:11:16-PST
Received: by ucbvax.Berkeley.EDU (5.58/1.26)
       id AA20846; Sat, 27 Feb 88 04:59:03 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
       for [email protected] ([email protected])
       (contact [email protected] if you have questions)
Date: 25 Feb 88 00:49:12 GMT
From: [email protected]  (Val Kartchner)
Subject: VT Trek from DEC system 20
Message-Id: <[email protected]>
Sender: [email protected]
To: [email protected]
ReSent-Date: Fri 4 Mar 88 17:14:17-EST
ReSent-From: Betsy Ramsey <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>


    I have seen a very good real time Star Trek games called VTTREK for DEC
    system 20's.  The person who brought it here had the source, but no
    longer has it.  It was written in FORTRAN and some DEC 20 assembly.
    I'd like to get the complete source to it, and/or any descendants from
    it.  It shows the view from the bridge with a 3-D perspective control
    panel.  I was very impressed.

    I'd also be interested in source for other Star Trek and other games,
    expecially real-time and multi-user games.  We already have the
    Conquest (Star Trek like game), but if you have a more recent version,
    or a version written in C (or FORTRAN), I'd welcome it.

                       Thanks in advance,
                               -=:[ VAL ]:=-
--
---  /\  ------------ Val Kartchner  {UT@WSC} ---- #include <flamesuit.h> -----
   /\/\  .    /\   | "Those who don't understand VMS are condemmed to reinvent
  /    \/ \/\/  \  |  Unix; those who understand VMS and Unix use VMS."
==/ U i n T e c h \====!ihnp4!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!val====
6-Mar-88 11:35:02-PST,700;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Sun 6 Mar 88 11:31:58-PST
Date: Sun 6 Mar 88 13:36:40-CST
From: Clive Dawson <[email protected]>
Subject: AN20/ECU patch
To: [email protected]
Message-ID: <[email protected]>

For several years we've been been running a small program at
boot time which serves to establish proper handshaking between
our AN20 and the ECU which connects us to the Internet PSN.
Without it, the IMP READY signal never comes up because
the ECU is waiting for HOST READY and vice versa.

Does anybody have the equivalent functionality in the form of
a monitor patch?

Thanks,

Clive
-------
10-Mar-88 17:39:38-PST,1081;000000000000
Return-Path: <[email protected]>
Received: from msr.epm.ornl.gov (ORNL-MSR.ARPA.#Internet) by SCORE.STANFORD.EDU with TCP; Thu 10 Mar 88 17:38:33-PST
Received: by msr.epm.ornl.gov (5.51/4.9)
       id AA21627; Thu, 10 Mar 88 20:43:13 EST
Date: Thu, 10 Mar 88 20:43:13 EST
From: [email protected] (Jeff Jones)
Message-Id: <[email protected]>
To: [email protected]
Subject: WANTED - Callable fork code


Folks,

I  am  need  of some FORTRAN callable assembly routines which work like the PCL
commands: INVOKE, TYPEIN, CLEARTYPEOUT, KILLPROGRAM, and GETTYPEOUT. For people
who don't know, these commands permit a PCL procedure to start a program  in  a
lower  fork  and  feed commands to it and retrieve output from it in a somewhat
controlled fashion.

I do have the PCL source for the 5.1 EXEC but I do not care to get into BLISS
source unless I have to.

If someone can point me toward some code, I would be most appreciative.


Thanks in advance,
Jeff Jones
Martin Marietta Energy Systems, Inc.
Oak Ridge, Tn
(615)576-2335
11-Mar-88 13:34:55-PST,1041;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Fri 11 Mar 88 13:34:04-PST
Date: Fri 11 Mar 88 14:35:18-MST
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Re: WANTED - Callable fork code
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

Re: Fortran-callable fork package:

Pick up DOC:FRKPAK.INFO from SCIENCE.UTAH.EDU via ANONYMOUS
FTP and browse through it with Emacs INFO mode (do C-X I
then G(dsk:frkpak)); if you like it, I'll make the sources
available.  You might want to look at DOC:FILEIO.INFO as
well.  I also have a complete JSYS interface with complete
MONSYM symbols for Fortran programs, so you can conveniently
do systems programming in Fortran if you need to.
-------
11-Mar-88 18:13:01-PST,1032;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Fri 11 Mar 88 18:11:05-PST
Date: Fri, 11 Mar 1988  19:14 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
Cc:   "Nelson H.F. Beebe" <[email protected]>,
     [email protected], [email protected]
Subject: WANTED - Callable fork code
In-reply-to: Msg of 11 Mar 1988  14:35-MST from Nelson H.F. Beebe <Beebe at SCIENCE.UTAH.EDU>

Also available via ANONYMOUS FTP from SIMTEL20.ARPA in
SRC:<SOURCES.UNSUPPORTED>FORMAC.* are the sources and documentation
for Sandia's FORTRAN/MACRO library, written by Norm Samuelson in the
FORTRAN V7 days.  Some routines may not apply or are no longer
necessary, especially the extended addressing hack.  Also, the
interface to the EXEC is better done by modifying the EXEC so that it
can read its command line args, a trivial, but useful feature to add
if you have sources.

--Frank
14-Mar-88 05:05:41-PST,2219;000000000000
Return-Path: <[email protected]>
Received: from DREA-XX.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Mar 88 05:04:16-PST
Date: Sat, 12 Mar 88 08:33:54 AST
From: Peter J Gergely <[email protected]>
Subject: WANTED - Callable fork code
To: [email protected]
cc: [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]>

Also availble we have, the following files here at DREA-XX.ARPA.

       PS:<ANONYMOUS>DECLIB.HLP
       PS:<ANONYMOUS>DECLIB.REL
       PS:<ANONYMOUS>DECLIB.DOC

The only request is that I have, is that mail be sent to
[email protected], with your name and mailing address (EMAIL and
SNAIL) saying that you picked up the library.  DECLIB.DOC is the formal
documentation that may be requested in printed form, by sending the
appropriate request to:

       CHIEF, Defence Research Establishment Atlantic
       P.O. Box 1012,
       Dartmouth, NS
       Canada  B2Y 3Z7

Enclosed below is the .HLP available for DECLIB.  The documentation was
originally sent out to a few people on TOPS-20 many years ago.  The HELP
date should probably read 1985.  Have fun.

       - Peter

--
Peter J. Gergely (DREA, P.O. Box 1012, Dartmouth, NS  B2Y 3Z7  Canada)
     ARPANET:  [email protected] (preferred)
or              [email protected]
     DIALNET:  Peter@DIAL|DREA-Griffin
     CSNET:    gergely%[email protected]
     UUCP:     [email protected]
-------------------------------------------------------------------------------

PROGRAM: DECLIB                               HELP DATE: July, 1982

AUTHOR/LOCAL CONTACT:  Peter J. Gergely <[email protected]>

PURPOSE:
       Originally written by C. Mihoff to provide the capability of
performing general magnetic tape operations from FORTRAN (the original
DECLIB).
       The library was extensively modified to include many more
powerful FORTRAN-callable MACRO routines such as general information
functions, subprograms manipulation, binary typeout, and many others.

ADDITONAL REQUIREMENTS:

FURTHER DOCUMENTATION MAY BE FOUND AT:
       DOC:DECLIB.DOC
-------
14-Mar-88 10:12:18-PST,1077;000000000000
Return-Path: <Victor%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 14 Mar 88 10:11:38-PST
Received: by lindy.stanford.edu; Mon, 14 Mar 88 06:35:33 PST
Received: by Forsythe.Stanford.EDU; Mon, 14 Mar 88 10:15:42 PST
Received: from bmc1.uu.se by max.uu.se; Mon, 14 Mar 88 19:13 MET
Received: from TCP-DAEMON by bmc1.UU.SE; Mon, 14 Mar 88 19:13 MET
Date: Mon 14 Mar 88 19:11:57
From: Bj|rn Victor <Victor%[email protected]>
Subject: Messy ARP table
To: [email protected]
Cc: [email protected]
Message-Id: <880314191157.14.VICTOR@AIDA>

Could somebody out there help me and find the patch for messy ARP tables
(duplicates all over, table overflows)?  I know I've seen it passing
by during the last year or three, but now I seem to have lost it.
(A DDT patch would be best, but a source patch will certainly do...)

Yours,
--Bjorn Victor                 [email protected]
Dept. of Computer Systems       or
Uppsala University, SWEDEN     victor%[email protected]
-------
30-Mar-88 09:00:40-PST,1041;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 30 Mar 88 08:58:44-PST
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Wed, 30 Mar 88 09:03:04 PST
Date: Wed, 30 Mar 88 07:51:40 PST
From: Mark Crispin <[email protected]>
Subject: PANDA record uptime
To: [email protected], [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

PANDA died after a 2045 hour run due to a software bug.  I was hacking;
specifically, I had called ULKINI (unlocking EDDT from physical memory)
from MDDT to see how many memory pages I'd get back.  I saw no indication
from INFO MON or SYSDPY that it made any difference, so I went back to
MDDT and was rewarded with a SKDPF1 bughlt.  Since EDDT wasn't in memory,
there was no hope of reviving the system.

I wonder what the current TOPS-20 record uptime is?
-------
4-Apr-88 17:46:10-PDT,1516;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 17:43:28-PDT
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 4 Apr 88 17:48:37 PDT
Date: Mon, 4 Apr 88 17:14:46 PDT
From: Mark Crispin <[email protected]>
Subject: value of a DEC-20?
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 place or organization that puts values on antique
computers?

    I am in the midst of an extremely nasty divorce.  Part of this
consists of my estranged wife claiming that my 2020 system is worth
"between $10K-$20K".  This is patently bullshit (I think a more
realistic value is $2K) but just try to convince the courts of that.
They just see a lot of iron and think it must be worth a lot of money.

    So, I need to get some sort of valuation placed on it from an
authority the courts will accept.  With the used market as volatile
as it is (I've seen $295 to $995 for RM03's), a turkey can really
screw things up but good.  I don't think *any* dealer would buy a
2020 at any price, but $500 seems to be what people have been paying
for them these days.

    The thing that hurts the most is that the system isn't really
legally mine; title was never transferred to me.

    I won't even talk about the alimony.

-- Mark --
-------
4-Apr-88 17:57:03-PDT,979;000000000000
Return-Path: <bzs%[email protected]>
Received: from buita.BU.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 17:56:49-PDT
Received: from bu-it.bu.edu by buita.BU.EDU (4.0/4.7)
       id AA08450; Sat, 5 Mar 88 19:56:55 EST
Received: from bu-cs.bu.edu by bu-it.bu.edu (3.2/4.7)
       id AA01555; Mon, 4 Apr 88 21:00:16 EDT
Return-Path: <[email protected]>
Received: by bu-cs.bu.edu (5.31/4.7)
       id AA19719; Mon, 4 Apr 88 19:58:18 EST
Date: Mon, 4 Apr 88 19:58:18 EST
From: bzs%[email protected] (Barry Shein)
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Mark Crispin's message of Mon, 4 Apr 88 17:14:46 PDT <[email protected]>
Subject: value of a DEC-20?


Why don't you just ask DEC's Traditional Products Group (TPL) what
they would give you or valuate it at if they were interested. Seems
like that would be authoritative enough.

       -Barry Shein, Boston University

4-Apr-88 19:01:00-PDT,1041;000000000000
Mail-From: GROSSMAN created at  4-Apr-88 19:00:17
Date: Mon 4 Apr 88 19:00:16-PDT
From: Stu Grossman <[email protected]>
Subject: Re: value of a DEC-20?
To: bzs%[email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

I think that since Mark takes such good care of his 2020, that the total
system must be worth in the neighborhood of 250,000 -> 300,000 dollars.

Actually, the system is really worth what you can earn with it.  If it is
no longer available, then it's value would be equal to the value of whatever
could equivalently replace it.  I would think that a Sun 3/280 Server with
a couple of Fuji Eagles and a tape drive might be a rough equivalent.  That's
worth about $90,000.  Of course, you have some printers and modems on the
system, so that would push the price up to somewhere in the neighborhood of
$100,000.

See, you really have a pretty decent system after all!!!

                       Stu
-------
4-Apr-88 20:27:14-PDT,742;000000000000
Return-Path: <[email protected]>
Received: from ardvax.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 20:26:34-PDT
Received: by ardvax.stanford.edu; Mon, 4 Apr 88 19:34:10 PST
Date: Mon, 4 Apr 1988 20:34:01 PDT
From: Bill Yeager <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: dec2020

Stu, pure nonsense! Mark's system is worth exactly what he can sell
it for on the open market.

Just like my 68VW squareback. I could replace it with an 88 GTI 16V
that is worth about $16,500 bucks, but certainly cannot sell if
for more than $1K.

2020's are neat to have around just like my ol' reliable VW. But,
gee, have you driven one of those GTI's?


Bill
4-Apr-88 21:33:55-PDT,1019;000000000000
Return-Path: <bzs%[email protected]>
Received: from buita.BU.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 21:33:20-PDT
Received: from bu-it.bu.edu by buita.BU.EDU (4.0/4.7)
       id AA20082; Tue, 5 Apr 88 00:37:12 EDT
Received: from bu-cs.bu.edu by bu-it.bu.edu (3.2/4.7)
       id AA11088; Tue, 5 Apr 88 00:37:09 EDT
Return-Path: <[email protected]>
Received: by bu-cs.bu.edu (5.31/4.7)
       id AA01497; Mon, 4 Apr 88 23:35:20 EST
Date: Mon, 4 Apr 88 23:35:20 EST
From: bzs%[email protected] (Barry Shein)
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
In-Reply-To: Bill Yeager's message of Mon, 4 Apr 1988 20:34:01 PDT <[email protected]>
Subject: dec2020


Actually, I'll relate a comment from an unnamed observer here, not
my particular opinion:

"get the quote from the lawyer then deliver the 2020 and strike half
the claimed value off the rest of the settlement, then buy another"
4-Apr-88 23:28:34-PDT,645;000000000000
Return-Path: <[email protected]>
Received: from CU20B.COLUMBIA.EDU by SCORE.STANFORD.EDU with TCP; Mon 4 Apr 88 23:28:15-PDT
Date: Tue 5 Apr 88 02:33:05-EST
From: Ken Rossman <[email protected]>
Subject: Re: dec2020
To: [email protected], [email protected]
cc: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>

 2020's are neat to have around just like my ol' reliable VW. But, gee,
 have you driven one of those GTI's?

And remember: "It's not a *computer*, it's a *DEC*"
-------
5-Apr-88 06:37:08-PDT,2086;000000000000
Return-Path: <IMHW400%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 5 Apr 88 06:36:36-PDT
Received: by lindy.stanford.edu; Tue, 5 Apr 88 06:41:37 PDT
Received: by Forsythe.Stanford.EDU; Tue,  5 Apr 88 06:39:52 PDT
Received: by INDYCMS (Mailer X1.23b) id 6906; Tue, 05 Apr 88 08:28:40 EST
Date:         Tue, 5 Apr 1988 08:10 EST
From: Mark H. Wood <IMHW400%[email protected]>
Subject:      Re:  value of a DEC-20?
To: <[email protected]>

I would say that a good model for the situation described might be the one
followed when valuing wrecked automobiles for the purpose of recovering one's
loss in a multi-car accident.  (It doesn't sound right yet, but read on.)
Get several estimates from used-computer dealers that you trust, asking for
the price THEY would get for SELLING a comparable system.  Establish a range
of reasonable values and throw out the turkeys.  (Your lawyer can tell you
how to weight your range for the best combination of fairness and tactical
advantage....)

Another place to try might be the Computer Museum in Boston.

A third source of valuation, though it will probably carry less weight, could
be people you know who purchase computers for their businesses' use.  What
would several of your business acquaintances pay for your system, if they
needed it, and would they be willing to offer an expert opinion?

But one should not have to go through all this.  Is there any way you
can *prove* that the 2020 is owned by someone else?  Your posession of the
machine should NOT be significant if someone else can prove ownership.  (I
am rather ignorant here:  do minicomputers have certificates of title, like
automobiles?  If not, you may have to bring in a representative of the owner
as witness to your non-ownership, or at least present an affidavit executed
by the owner.  Just for luck, also be prepared to explain your posession of
somebody else's computer.)

Please check with your lawyer before pursuing any of these avenues.
5-Apr-88 08:42:31-PDT,1454;000000000000
Return-Path: <[email protected]>
Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Tue 5 Apr 88 08:42:03-PDT
Posted-Date: Tue, 5 Apr 88 10:34:31 cdt
Received: by sally.utexas.edu (5.54/5.51)
       id AA18373; Tue, 5 Apr 88 10:47:12 CDT
Date: Tue, 5 Apr 88 10:34:31 cdt
From: [email protected] (Clyde T. Poole)
Message-Id: <8804051534.AA08028@red>
Received: by red (13.1/4.22)
       id AA08028; Tue, 5 Apr 88 10:34:31 cdt
To: [email protected]
Subject: Death of another DECSYSTEM-20

I just posted the following notice here at the University of Texas at Austin.
The actual disposition of the hardware is still unknown.
-----
At a meeting of the Steering Committee for the Research DECSYSTEM-20
on Thursday, March 31, 1988, it was decided to shut down the R20
permanently as of August 31, 1988.  All users of the R20 should begin
to make alternate arrangements for file storage and electronic mail as
soon as possible.  Faculty, staff and students of the Department of
Computer Sciences can contact Karen Schaffer
([email protected]) about alternate arrangements.
-----
Clyde T. Poole -- Technical Coordinator, Facilities and Equipment
Univ. of Texas at Austin        ARPA/CSnet: [email protected]
Dept. of Computer Sciences      UUCP: {uunet,harvard,ihnp4}!ut-sally!ctp
Taylor Hall 2.124               BITNET: ctp@UTADNX      SPAN: UTADNX::CTP
Austin, TX  78712-1188          VOICE: (512) 471-9551

7-Apr-88 06:51:52-PDT,1847;000000000000
Return-Path: <@MITVMA.MIT.EDU,@WESLEYAN.BITNET:[email protected]>
Received: from MITVMA.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 06:47:34-PDT
Received: from WESLEYAN.BITNET by MITVMA.MIT.EDU ; Thu, 07 Apr 88 09:50:12 EDT
Date:  7-APR-1988 09:11:44.28
From: Douglas Bigelow <DBIGELOW%EAGLE.WESLEYAN.EDU%[email protected]>
Subject: KNISCE bugchecks with cisco AGS gateway
To: [email protected]

Got an interesting problem here...

Wesleyan has just joined NSFnet via the new JVNCnet New England loop, which
is a ring of universities joined by cisco AGS routers and 56KB lines.  Our
AGS has an Ethernet interface for our local network, a 56KB serial link to
Yale, and another 56KB link to Brown.  The gateways are still having the
routing configurations tuned, but they'll be in full operation within a week.

Now, starting two days ago, both of our 2060s started issuing KNISCE bugchecks
about once a minute.  They were roughly synchronized on both systems.  We
tried halting and reloading the NIs, disconnecting the tranceivers, etc.
Finally, we started unplugging other network hosts that we were suspicious
of.

Lo and behold, it turns out that the 20s quiet right down when the cisco
AGS is disconnected, and start re-issuing KNISCEs when it's reconnected.

We're running version 150 of the NI microcode (from KNILDR), and haven't
changed any software or hardware on our 20s in two years.

The cisco box had been on our network for a week before any problem started
occurring.  It seems to have popped up about the time that the AGS was
switched from RIP routing to IGRP, but that may be pure coincidence.

Anyone have any ideas?  Need any more information?  Any ideas welcome.
Please reply directly to me so I can see the responses most quickly.

Thanks -- Doug

7-Apr-88 08:58:40-PDT,1307;000000000000
Return-Path: <BRUCE%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 08:57:39-PDT
Received: by lindy.stanford.edu; Thu, 7 Apr 88 09:02:30 PDT
Received: by Forsythe.Stanford.EDU; Thu,  7 Apr 88 09:01:14 PDT
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Received: from locke.hs.washington.edu (SYSTEM@UWALOCKE) by
UWAVM.ACS.WASHINGTON.EDU (Mailer X1.25) with BSMTP id 0378; Thu, 07 Apr 88
09:01:11 PDT
Date: Thu, 7 Apr 88 09:01 PDT
From: BRUCE EDWARDS <BRUCE%[email protected]>
Subject: 2020 console line speed change
To: [email protected]
X-Vms-To: IN%"[email protected]"

       I have a trivial question for those in the know.  Does anyone
know what the switch settings are to change the speed to 1200 baud
for both the CTY and the KLINIK line on the KS10 console board (M8616).
We have finally hooked up a 1200 baud DECWRITER and would like to take
advantage of it.  Thanks in advance.

Bruce Edwards
John Locke Computer Center
University of Washington SB-50
Seattle, WA 98195

Bitnet -   BRUCE@UWALOCKE
Internet - [email protected]  (not sure how well this addr will
                                          work(

7-Apr-88 10:14:45-PDT,1092;000000000000
Return-Path: <BRUCE%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 10:13:54-PDT
Received: by lindy.stanford.edu; Thu, 7 Apr 88 10:18:40 PDT
Received: by Forsythe.Stanford.EDU; Thu,  7 Apr 88 10:15:30 PDT
Date:     Thu, 7 Apr 88 10:11 PDT
From: <BRUCE%[email protected]> (BRUCE EDWARDS)
Subject:  2020 console Line speed change
To: [email protected]
X-Original-To:  edu%"[email protected]", BRUCE

       I have a trivial question for those in the know.  Does anyone
know what the switch settings are to change the speed to 1200 baud
for both the CTY and the KLINIK line on the KS10 console board (M8616).
We have finally hooked up a 1200 baud DECWRITER and would like to take
advantage of it.  Thanks in advance.

Bruce Edwards
John Locke Computer Center
University of Washington SB-50
Seattle, WA 98195

Bitnet -   BRUCE@UWALOCKE
Internet - [email protected]  (not sure how well this addr will
                                          work)

7-Apr-88 14:26:47-PDT,3582;000000000000
Return-Path: <ridder%[email protected]>
Received: from decwrl.dec.com by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 14:25:21-PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
       id AA10889; Thu, 7 Apr 88 14:30:30 PDT
Date: Thu, 7 Apr 88 14:30:30 PDT
Message-Id: <[email protected]>
From: ridder%[email protected]
To: [email protected], [email protected],
       BRUCE%[email protected]
Subject: Re:  2020 console Line speed change

  ========

Date: 7 Apr 1988 1529-MDT
From: Hans <RIDDER@WARLOK>
To: "(BRUCE EDWARDS)  7-Apr-88 1011 PDT" <"BRUCE%[email protected]"@DECWRL>
cc: "[email protected]"@DECWRL, "[email protected]"@DECWRL
Subject: Re:  2020 console Line speed change
Message-ID: <"MS11(6040)+GLXLIB6(0)" 12388635963.74.143.120097 at WARLOK>
References: Message from "(BRUCE EDWARDS)  7-Apr-88 1011 PDT" <"BRUCE%[email protected]"@DECWRL>
             of 7-Apr-88 1332-MDT

2020 console boards come in two types, rev D and rev E, and they look
totally different from each other.  These days you will find mostly rev
E boards, but occasionally you'll find an old one.

The rev E board has a switch pack at the top and bottom edge of the
board (holding it like it would be in the backplane.)  The rev D board
has the two switch packs right next to each other in the center of the
board.

Console terminal (REV E)

             !          E10          !   E173    !
             !  3  !  4  !  5  !  6  !  2  !  3  !
        110  ! Off ! Off ! Off ! Off ! Off ! Off !
        150  ! On  ! Off ! Off ! Off ! Off ! On  !
        300  ! Off ! On  ! Off ! Off ! Off ! On  !
        600  ! Off ! Off ! Off ! On  ! Off ! On  !
       1200  ! Off ! Off ! On  ! Off ! Off ! On  !
       1800  ! On  ! Off ! On  ! Off ! Off ! On  !
       2400  ! On  ! On  ! Off ! Off ! Off ! On  !
       4800  ! Off ! On  ! On  ! Off ! Off ! On  !
       9600  ! On  ! On  ! On  ! Off ! Off ! On  !

KLINIK terminal (REV E)

             !          E10          !   E173    !
             !  1  !  2  !  7  !  8  !  4  !  7  !
        110  ! Off ! Off ! Off ! Off ! Off ! Off !
        150  ! On  ! Off ! Off ! Off ! Off ! On  !
        300  ! Off ! On  ! Off ! Off ! Off ! On  !
        600  ! Off ! Off ! Off ! On  ! Off ! On  !
       1200  ! Off ! Off ! On  ! Off ! Off ! On  !
       1800  ! On  ! Off ! On  ! Off ! Off ! On  !
       2400  ! On  ! On  ! Off ! Off ! Off ! On  !
       4800  ! Off ! On  ! On  ! Off ! Off ! On  !
       9600  ! On  ! On  ! On  ! Off ! Off ! On  !

Console terminal (REV D)

             !              E508                 !
             !  1  !  2  !  3  !  4  !  5  !  6  !
        110  ! Off ! Off ! Off ! Off ! Off ! Off !
        300  ! Off ! Off ! On  ! Off ! On  ! Off !
        600  ! On  ! Off ! Off ! Off ! On  ! Off !
       1200  ! Off ! On  ! Off ! Off ! On  ! Off !
       1800  ! Off ! On  ! Off ! On  ! On  ! Off !
       2400  ! Off ! Off ! On  ! On  ! On  ! Off !
       4800  ! Off ! On  ! On  ! Off ! On  ! Off !
       9600  ! Off ! On  ! On  ! On  ! On  ! Off !

KLINIK terminal (REV D)

             !              E509                 !
             !  1  !  2  !  3  !  4  !  5  !  6  !
        110  ! Off ! Off ! Off ! Off ! Off ! Off !
        300  ! Off ! Off ! On  ! Off ! On  ! Off !
        600  ! On  ! Off ! Off ! Off ! On  ! Off !
       1200  ! Off ! On  ! Off ! Off ! On  ! Off !
       1800  ! Off ! On  ! Off ! On  ! On  ! Off !
       2400  ! Off ! Off ! On  ! On  ! On  ! Off !
       4800  ! Off ! On  ! On  ! Off ! On  ! Off !
       9600  ! Off ! On  ! On  ! On  ! On  ! Off !
  --------
7-Apr-88 17:13:43-PDT,741;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 7 Apr 88 17:13:25-PDT
Date: Thu 7 Apr 88 19:18:17-CDT
From: Clive Dawson <[email protected]>
Subject: Re: KNISCE bugchecks with cisco AGS gateway
To: DBIGELOW%EAGLE.WESLEYAN.EDU%[email protected]
cc: [email protected]
In-Reply-To: Message from "Douglas Bigelow <DBIGELOW%EAGLE.WESLEYAN.EDU%[email protected]>" of Thu 7 Apr 88 09:11:44-CDT
Message-ID: <[email protected]>

Did you say you are running NI Microcode version 150?!  We've been
running version 171 for about a year now.  I would certainly
suggest updating KNILDR as the first step toward solving this
problem.

Clive
-------
28-Apr-88 11:10:04-PDT,2747;000000000000
Return-Path: <114RONAN%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 28 Apr 88 11:05:37-PDT
Received: by lindy.stanford.edu; Thu, 28 Apr 88 10:17:56 PDT
Received: by Forsythe.Stanford.EDU; Thu, 28 Apr 88 10:15:10 PDT
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 5716; Thu,
28 Apr 88 18:01:08 BST
Via:      UK.AC.RL.EARN; Thu, 28 Apr 88 18:01:07 BST
Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 5714; Thu, 28
         Apr 88 18:01:07 BS
Via:      UK.AC.LIVPOL.SPOOL; 28 APR 88 18:01:04 BST
Date:     28-APR-1988 17:58:38
From: 114RONAN%[email protected]
To: [email protected]
Subject:  DUMPER archival nasty - have YOU been bitten?

Here's a problem that MAY be affecting you, but you haven't noticed. Doing
archiving with DUMPER 6(532) under TOPS-20 6.1(7030), we find that
sometimes files appear to have been archived, but in fact have NOT been.
I.e. when we come to retrieve the files from the archive tape they are
supposedly saved on, they're not there. At least one other site in
the U.K. has reported and SPR'd this problem.

The scenario I have seen myself is as follows:- doing the first archival
run onto a 1600 bpi tape in a TU77 drive. The tape had been used before, so
we answer no to "Is this a new tape?". DUMPER then searches the tape for
the end of the last saveset, and proceeds to "save" the files that are
marked for archiving. The tape moves as you would expect, and DUMPER lists
the files as it "saves" them, but when you rewind the tape and print a
listing of it, you find that no files have actually been saved, and EOT is
still where it was when you started.

In this particular example, the only saveset on the tape when we started
was continued from a previous archival tape, and the only file in the
saveset was also continued from the previous tape. This may or may not be
relevant, but I tried several times to archive files to this particular
tape, and had no luck. I eventually used SAVE rather than ARCHIVE to save
one file after the first (only) saveset, and subsequent archives seemed to
work OK, (except that the saveset names were not "ARCHIVE blah blah" as you
would expect, but blank).

I don't know if this is the only time when this happens, but we are now
VERY wary of doing any archivals until we get a solution to this problem...
It might prove an interesting, (or terrifying), exercise to check your
archived files and see if they appear on the archive tapes they're supposed
to :-(

Ronan Flood,                              ([email protected])
Liverpool Polytechnic Computer Services.
28-Apr-88 22:20:13-PDT,783;000000000000
Return-Path: <IMHW400%[email protected]>
Received: from lindy.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 28 Apr 88 22:15:06-PDT
Received: by lindy.stanford.edu; Thu, 28 Apr 88 22:20:53 PDT
Received: by Forsythe.Stanford.EDU; Thu, 28 Apr 88 22:18:14 PDT
Received: by INDYCMS (Mailer X1.23b) id 3501; Thu, 28 Apr 88 17:01:56 EST
Date:         Thu, 28 Apr 1988 17:00 EST
From: Mark H. Wood <IMHW400%[email protected]>
Subject:      Re:  DUMPER archival nasty - have YOU been bitten?
To: <[email protected]>

Since the tape moves "normally", I suspect a positioning problem.  Did you
space the tape past the LEOT and look for the saveset?  The archival logic
may be mispositioning after searching for LEOT.

Good luck!
2-May-88 22:54:47-PDT,916;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 2 May 88 22:54:46-PDT
Date: Mon 2 May 88 22:59:20-PDT
From: Eric M. Berg <[email protected]>
Subject: Master TTYINI file now lives on Score
To: [email protected], [email protected]
Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home)
Message-ID: <[email protected]>

With the demise of the Sierra DECsystem-20, the master copy of the file
TTYINI.NET-BASE now lives in the FINGER: directory on Score.  (This is the
file which is used to general terminal type and location information for
TOPS-20 and Unix hosts on campus.)

I expect that Stu Grossman will make some announcement regarding access to
the FINGER: directory on Score for people who need to update the file but
do not currently have access.  Stay tuned...
-------
5-May-88 17:59:01-PDT,837;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 5 May 88 17:55:58-PDT
Date: Thu 5 May 88 18:00:24-PDT
From: Eric M. Berg <[email protected]>
Subject: LCG Clearance Sale
To: [email protected]
Phone-#s: 415/723-1576 (GSB-CF), 415/329-9940 (home)
Message-ID: <[email protected]>

DEC just sent around a letter announcing an "LCG Inventory Reduction Offer"
(can you say "going out of business sale"?), with sale prices on MG memory,
MCA-25 cache/pager upgrades, CI-20 and NIA-20 port adapters, and even
whole KL-10 systems.

If you're interested, call LCG Marketing at 617/467-4291 or 467-5404.
(Presumably there are two phone lines to handle the tremendous amount of
business they expect to do.  :-} )
-------
9-May-88 19:10:40-PDT,2376;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Mon 9 May 88 19:06:59-PDT
Date: Mon, 9 May 1988  19:35 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: Verify any drives lately?

One of our secondary drives, PD1:, developed a hard error Saturday and
the drive was reformatted and verified by the CE.  Then I CREATEd and
VERIFY'd the drive with CHECKD, but not without a couple of
time-consuming problems.  The CHECKD used came with 6.1 and is
6.1(88).

The first problem we had last November when I did the same thing with
CHECKD on our RP06 boot drive, which caused much wasted time bringing
up the new drives under 6.1.  We found that with 6.1 and the 442
microcode which comes with version 15.50 of RSX20F, we could no longer
ENABLE WRITE-VERIFICATION FILE without causing the system to
continuously reboot due to an ILUUO.  The workaround is to have the
DEC CE reformat and verify, and not ENABLE WRITE... with CHECKD.  We
rediscovered that problem this weekend.  This problem did not occur
with 5.4 and RSX20F version 15.15...

We also discovered that CHECKD will fail at 1,,READ2+5 with a JSYS
error: illegal operation with DSKOP.  After the third time we tried
this, we accidentally discovered the workaround was to repeatedly
CONTINUE CHECKD until it considered the error as a hard error and
finished.  (This was near the end of the disk.)  It was also rather
peculiar that all the errors it found were all preceded by a series of
JSYS error: messages eventually followed by a message from CHECKD that
the soft error was corrected by the ECC mechanism, but considered bad
(because I had ENABLEd SOFT-ERROR-MARKING).

Finally, when CHECKD fails, it leaves the structure in limbo - you
can't DISMOUNT it with either EXEC or OPR commands.  It turned out to
require a combination of SET..  UNAVAILABLE/AVAILABLE OPR commands.
(The exact sequence that finally worked can be made available if
anyone is interested - I need to check the console log.)

Now, the question for today: has anyone experienced the same or
similar problems and has the fix(es) been published.  If it is known
to be fixed in AP#17, I'd like to know so I can go unpack it.

--Frank
16-May-88 01:47:33-PDT,2055;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 16 May 88 01:47:32-PDT
Date: Mon 16 May 88 01:46:17-PDT
From: Jim Lewinson <[email protected]>
Subject: LPTSPL Crashes on CANCEL; Excessive CPU consumption
To: [email protected]
Message-ID: <[email protected]>

Problem #1:
       The TCP version of LPTSPL crashes when a job in progress is canceled.

Diagnosis:
       It turns out that the Galaxy IPCF Interupt code makes an
assuption about the format of the Stack Frame when it mucks with it
in order to make the currently executing routine return right away.
As a result, it returns to a random memory location.

Solution:
       Add a location, TCPCNT, that NETSOU can use to store the bytes
remaining to be sent, and make the code at NETSOU use that space, instead
of allocating a word from the stack and screwing up GLXLIB's Interrupt
routines.

The corrected code is on [GSB-HOW] SP:<6.1.GALAXY.STANFORD>LPTSPL,
and will propagate to LOTS as soon as I find the sources there again.


Problem #2:
       There is code in LPTSPL which starts up a subfork and tries to
READ characters from the JFN that LPTSPL is sending on.  I think this is
intended to handle printers that send ^Q's back which are getting
past the Ethertip and were piling up in the tip and trashing the connection.

       However, this code doesn't seem to work.  The BIN% works when
executed in the parent fork, but it simply returns without an error
code in the subfork.  Needless to say, it loops back right away to
read another "character", and so consumes large amounts of CPU time.

"Solution"
       When it actually manages to read a "character", I made it go
to sleep for a few seconds.  It still consumes a little CPU time, but it
is bearable.

Does anyone understand what is going on here?  I get impression that
the child isn't allowed to touch a TCP: JFN opened by a parent, but
I can't even figure out what the error is.

                                               Jim
-------
16-May-88 12:10:10-PDT,1471;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Mon 16 May 88 12:01:30-PDT
Date: Mon 16 May 88 13:56:56-CDT
From: Clive Dawson <[email protected]>
Subject: SMTP connections refused
To: [email protected]
Message-ID: <[email protected]>

Several months ago there was some discussion about hung SMTP
connections which prevented new SMTP connections from getting
established.  Bill Westfield published a patch to TCPTCP and IPIPIP
which addressed this problem, but our 20 is still experiencing
it even though we have this patch installed.

I modified SMTJFN to print a message on the CTY every time it fails to
open a listening SMTP connection.  These failures happen much more
often than I realized -- about once every 10 minutes on the average.
The problem is that most remote mailers which get a connection refused
will not try again for many minutes, even though an immediate retry
would almost always succeed.  This results in a delay of up to 30
minutes for a small but significant number of messages which would
normally be delivered in seconds.

The CTY messages also show that the error being returned from the
OPENF is "Retransmission timeout".  I don't understand what this
means in the context of a listening connection.

I'm going to start digging into this further, but thought I'd
find out if anybody else has found a way to deal with this.

Thanks,

Clive
-------
18-May-88 15:43:12-PDT,2635;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 May 88 14:22:38-PDT
Date: Wed, 18 May 88 14:06:45 PDT
From: Mark Crispin <[email protected]>
Subject: MMailr bugfix
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Thanks to Clive Dawson, the long-standing (6+ years!) and wierd bug which
caused message notifications or dequeuing after "0 days" has finally been
identified and stomped on.  The problem was a string buffer overflowing
into the notification control cell.  This happened if the From: address
was very long (more than 120 characters).

The fix follows:

REDIT 1(103) COMPARE by user CRISPIN, 18-May-88 14:01:23
File 1: SS:<MM>MMAILR.MAC.521
File 2: SS:<MM>MMAILR.MAC.522
***** CHANGE #1; PAGE 1, LINE 9; PAGE 1, LINE 9
;Version components

MMLWHO==0                       ;Who last edited MMAILR (0=developers)
MMLVER==6                       ;MMAILR's release version (matches monitor's)
MMLMIN==1                       ;MMAILR's minor version
MMLEDT==^D521                   ;MMAILR's edit version

 ---------------------------------
;Version components

MMLWHO==0                       ;Who last edited MMAILR (0=developers)
MMLVER==6                       ;MMAILR's release version (matches monitor's)
MMLMIN==1                       ;MMAILR's minor version
MMLEDT==^D522                   ;MMAILR's edit version


***** CHANGE #2; PAGE 7, LINE 90; PAGE 7, LINE 90
       GTDLEN==.GTDML+10
GTDBLK: BLOCK GTDLEN+1          ;GTDOM% argument block
       RLYBFL==5*HSTBFL
RLYBUF: BLOCK RLYBFL            ;MX relays buffer
USRNUM: BLOCK 1
FRMMSG: BLOCK 30

 ---------------------------------
       GTDLEN==.GTDML+10
GTDBLK: BLOCK GTDLEN+1          ;GTDOM% argument block
       RLYBFL==5*HSTBFL
RLYBUF: BLOCK RLYBFL            ;MX relays buffer
USRNUM: BLOCK 1


***** CHANGE #3; PAGE 7, LINE 114; PAGE 7, LINE 113
PTHLST: BLOCK 40                ;List of host relays that are in the path
STRBSZ==1000                    ;Length of string buffers
STRBUF: BLOCK STRBSZ            ;String buffer, used globally
STRBF1: BLOCK STRBSZ            ;Alternative string buffer, used locally
STRBF2: BLOCK STRBSZ            ;Another alternate buffer used locally
MEMEND==.-1                     ;End of memory initialized at startup
 ---------------------------------
PTHLST: BLOCK 40                ;List of host relays that are in the path
STRBSZ==1000                    ;Length of string buffers
STRBUF: BLOCK STRBSZ            ;String buffer, used globally
STRBF1: BLOCK STRBSZ            ;Alternative string buffer, used locally
STRBF2: BLOCK STRBSZ            ;Another alternate buffer used locally
FRMMSG=STRBF2+<STRBSZ/2>
MEMEND==.-1                     ;End of memory initialized at startup

-------
26-May-88 23:21:24-PDT,1256;000000000000
Return-Path: <[email protected]>
Received: from GSB-WHY.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 May 88 23:18:42-PDT
Date: Thu 26 May 88 23:18:39-PDT
From: Eric M. Berg <[email protected]>
Subject: DECUS Large Systems SIG going out of business...
To: [email protected]
Reply-To: [email protected]
Phone-#s: 415/723-1576 (GSB), 415/329-9940 (home)
Message-ID: <[email protected]>

Excerpted from a recent posting to the INFO-VAX mailing list...
               ---------------

Date: 23 May 88 17:02:30 GMT
From: [email protected]  (Clyde T. Poole)
Subject: DECUS Questions Answered (last modified 23-May-1988)
To: [email protected]

  [....]

4) What is a SIG and a SIC?

  SIGs are Special Interest Groups.  There are many SIGs in DECUS.
  [....]

  SICs are Special Interest Committees.  These are really either new
  SIGs in the making or old SIGs going out of business.  They provide
  the same kinds of services that SIGs provide but are short of
  volunteer leadership.  Currently there is only one SIC, Large
  Systems, which is an old SIG going out of business because of the
  lack of a constituency.

  [....]
-------
27-May-88 07:07:49-PDT,2732;000000000000
Return-Path: <[email protected]>
Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Fri 27 May 88 07:07:16-PDT
Posted-Date: Fri, 27 May 88 08:52:51 cdt
Received: by sally.utexas.edu (5.54/5.51)
       id AA18623; Fri, 27 May 88 09:07:32 CDT
Date: Fri, 27 May 88 08:52:51 cdt
From: [email protected] (Clyde T. Poole)
Message-Id: <8805271352.AA28118@red>
Received: by red (13.1/4.22)
       id AA28118; Fri, 27 May 88 08:52:51 cdt
To: [email protected]
Cc: [email protected]
In-Reply-To: Eric M. Berg's message of Thu 26 May 88 23:18:39-PDT <[email protected]>
Subject: Re: DECUS Large Systems SIG going out of business...

Woops!  I should have posted something to the tops-20 list as soon as I
returned from Spring DECUS.

Because of a lack of volunteer leadership, the continued decline in session
attendance and confusion over which SIG is responsible for what kind of
sessions, the SIG Council declared the Large Systems SIG to be a SIC
(Special Interest Committee) as of the end of Spring DECUS.  This is not
NECESSARILY the death knell for the Large Systems SIG.  It simply means that
an impartial third party from another SIG will be appointed by the SIG
Council to help the SIC meet its obligations.  If the SIC is unable to
field a full complement of volunteer leadership within one year, it is
possible that the SIC will then be dissolved.  It is also possible that it
will be reorganized with a new name and purpose (having nothing to do with
our favorite 36 bit computers).

I am sorry this is happening, but we all had to assume that it would come
to this sooner or latter.  I will continue at my position with the SIC
Steering Committee (Communications Committee Voting Representative) as
long as I can, but because of changes in the installed base of computers
here at the UT Computer Sciences Dept., it will be VERY difficult for me
to justify attending DECUS Symposia and administrative meetings. (When
you don't have any Digital computers, your boss thinks it is strange that
you want to spend University time and money on DECUS meetings.)

Questions should probably be referred to Berkley Shands (SIC Chairman) at:

       BITNET: berkley@wunet
-----
Clyde T. Poole - Technical Coordinator, Facilities and Equipment (in real life)
DECUS U. S. Chapter, VAX and LS SIG, Newsletter Editor (in my spare time)
Univ. of Texas at Austin        ARPA/CSnet/NSFnet: [email protected]
Dept. of Computer Sciences      UUCP: {uunet,harvard,ihnp4}!ut-sally!ctp
Taylor Hall 2.124               BITNET: ctp@UTADNX      SPAN: UTADNX::CTP
Austin, TX  78712-1188          VOICE: (512) 471-9551
     "Life is a bitch ... and then you die"
2-Jun-88 14:02:32-PDT,690;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 2 Jun 88 13:53:10-PDT
Date: Thu 2 Jun 88 16:55:47-EDT
From: Rob Austein <[email protected]>
Subject: End of the Yellow Brick Road
To: [email protected]
Message-ID: <[email protected]>

OZ.AI.MIT.EDU is being shut down, tomorow.  This has been in the works
for so long that the phrase "when OZ goes away" has become a local
joke, but it's finally happening.  The final precipitating factor was
a head crash on the system sources pack.

OZ is survived (for the moment) by 3 Twenex and 4 ITS machines.

And yes, Toto.AI.MIT.EDU too.

--Rob
-------
5-Jun-88 13:04:03-PDT,1785;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sun 5 Jun 88 13:01:07-PDT
Date: Sun, 5 Jun 1988  14:01 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: You've been buffaloed!

Possibly *the* most interesting and subtle piece of news presented by
DEC at the Spring DECUS is the fact that out of the some 1,200 -10 and
-20 installations in existence five years ago, DEC had expected a
great migration would result in around 300 installations left to be
supported at this time.  The news is that far more of us have held on
than expected - we are still over 900 installations strong!!  In other
words, less than a fourth chickened out instead of the three-forths
DEC expected.  The Great Migration Project was a bust!

Now, it seems to me that with over 900 sites still alive and kicking,
we would have more than enough interest in keeping a very active user
group supported, regardless of the direction DEC is taking.  Although
we are greatly outnumbered by the mini sites, 900 is a very large and
substantial number in the mainframe world user group.

Five years ago, for whatever reasons may have been valid at the time,
the large VAX sites were lumped into the LCG SIG, and I believe the
result dilluted our base and interest rather than strengthened it.
Now, that the LCG SIG is being disbanded, we have the opportunity to
reorganize into our own again, just the -10 and -20 sites.  I believe
we can ignore the doomsayers who insist on pointing to those sites
which are planning to abandon their machines and press on.  We still
have the numbers!

What do you say?

--Frank
5-Jun-88 14:50:43-PDT,1477;000000000000
Return-Path: <[email protected]>
Received: from vx2.GBA.NYU.EDU by SCORE.STANFORD.EDU with TCP; Sun 5 Jun 88 14:50:20-PDT
Received: by vx2.GBA.NYU.EDU (5.51/) id AA29383; Sun, 5 Jun 88 17:49:29 EDT
Return-Path: <ittai>
Received: by vx2.GBA.NYU.EDU (5.51/) id AA29341; Sun, 5 Jun 88 17:47:04 EDT
Date: Sun, 5 Jun 1988 17:47:02 EDT
Sender: Ittai Hershman <[email protected]>
From: Ittai Hershman <[email protected]>
To: "Frank J. Wancho"<[email protected]>
Office-Phone: 212-285-6080
Subject: Re: You've been buffaloed!
In-Reply-To: Your message of Sun, 5 Jun 1988 14:01 MDT
Message-Id: <[email protected]>
Resent-To: [email protected]
Resent-Date: Sun, 5 Jun 1988 17:49:26 EDT
Resent-From: Ittai Hershman <[email protected]>
Message-Id: <[email protected]>

Frank, I think this is a case of wishful thinking.  The migration may be
taking longer than DEC expected, but it is definitely happening.

New York, for example, had one of the highest concentrations of DEC-20s.
Many have disappeared; most of the remaining ones will be gone by the
end of the year.

The joke may be on DEC, however, because many of the academic sites that
have migrated (we're 7/8ths done) to 8700s are displeased with them
and beginning to look at Sun-4/280s.

It's really a shame that Systems Concepts couldn't get their act
together.  The PDP-10 is DEAD, DEAD, DEAD.  Sigh!!!

-Ittai

5-Jun-88 16:44:41-PDT,2313;000000000000
Return-Path: <[email protected]>
Received: from MATHOM.CISCO.COM by SCORE.STANFORD.EDU with TCP; Sun 5 Jun 88 16:44:24-PDT
Date: Sun 5 Jun 88 16:44:19-PDT
From: Len Bosack <[email protected]>
Subject: Re: You've been buffaloed!
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

The current state of the 10s and 20s is exactly and only the confluence of
Digital's actions and the fact the we -- the customers -- have collectively
spent several billion dollars on this enterprise. As we imagine ourselves
reasonable people, we desire to get a passing return on our investments.

I expect we will have our 20s here for another 3-5 years and would acquire
more should this prove the best overall solution. Almost all of the capital
spending goes for UN*X boxes, however.

Two thoughts come with the above:

Perhaps there is a need to be filled by a strong 10/20 user group. Such a
group would help Digital to fulfill its support commitment with a bit less
guesswork than now obtains. When last I spoke with the Digital management,
they wanted to give effective support and were willing to spend a significant
amount of money to do so. Their problem was "What is to be done?". There was
no consensus as to what was useful and what was not.

While Digital wants to offer effective end-of-life support, there may yet be a
modest market for a "Service Life Extension Program". Such a thing is clearly
beyond their stated support program. It also presents a risk no reasonable
independent corporation would undertake. It may be that we customers would
find it desirable to undertake some of this project collectively. If there
were to be a fair consensus on what was needed, there are legal vehicles to
accomplish the end.

An Example:
While various power supply project have already been done, another sort of
project is possible. Modern technology makes it possible to provide 4MW of
fast main memory entirely within the processor backplane. The power savings
are comparable to replacing the supplies. The machine would also run 1.5x to
2x faster (wild guess).

A strong, focused user organization could help guide both Digital and any
collective action in the customers' interest.

Len Bosack
-------
6-Jun-88 07:07:50-PDT,1555;000000000000
Return-Path: <[email protected]>
Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 07:06:00-PDT
Posted-Date: Mon, 6 Jun 88 08:55:49 cdt
Received: by sally.utexas.edu (5.54/1.11)
       id AA21031; Mon, 6 Jun 88 09:06:19 CDT
Date: Mon, 6 Jun 88 08:55:49 cdt
From: [email protected] (Clyde T. Poole)
Message-Id: <8806061355.AA07404@red>
Received: by red (13.1/4.22)
       id AA07404; Mon, 6 Jun 88 08:55:49 cdt
To: [email protected]
In-Reply-To: "Frank J. Wancho"'s message of Sun, 5 Jun 1988  14:01 MDT <[email protected]>
Subject: Re: You've been buffaloed!

Let me try again...

The Large Systems SIG is NOT dead, it is just ill.  If enough TOPS-10 and
TOPS-20 people attended DECUS Symposia AND enough of these people were
willing to take over the leadership AND these new leaders could produce
enough volunteers to PRESENT and CHAIR sessions, the Large Systems SIC
could be brought back to health.  If this doesn't happen by the next
Symposium, THEN the SIG will probably die.

Another possibility is something along the line that Bozack (did I spell
it correctly?) suggested.  Maybe a seperate orginazation that meets
occasionally for short periods of time (less expensive than DECUS) and
invites the appropriate management from DEC to meet with them.

Unfortunately The University of Texas at Austin is one of the 900 sites
that is alive and kicking but about to die.  Both the -20's here will
be turned off on August 31, 1988.  So passes a great machine...

ctp
6-Jun-88 07:14:59-PDT,749;000000000000
Return-Path: <bzs%[email protected]>
Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 07:14:01-PDT
Received: from BU-CS.BU.EDU by bu-it.BU.EDU (5.58/4.7)
       id AA24398; Mon, 6 Jun 88 10:12:52 EDT
Return-Path: <[email protected]>
Received: by bu-cs.bu.edu (5.31/4.7)
       id AA17760; Mon, 6 Jun 88 10:15:42 EDT
Date: Mon, 6 Jun 88 10:15:42 EDT
From: bzs%[email protected] (Barry Shein)
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Clyde T. Poole's message of Mon, 6 Jun 88 08:55:49 cdt <8806061355.AA07404@red>
Subject: You've been buffaloed!


Maybe the independent consortium could be called the "Ajar Software
Foundation".

6-Jun-88 07:21:19-PDT,1237;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 07:20:23-PDT
Date: 6 Jun 1988 1018-EDT
From: "Reed B. Powell" <[email protected]>
To: [email protected]
High-Performance-Systems-Marketing: LCG-DEC10-20
Location: "297-4261 MRO2-2/2C (Pole 11B)"
REPLY: "GIDNEY:: or HPSVAX::"
Subject: "you've been buffaloed"
Message-ID: <"MS11(6040)+GLXLIB6(0)" 12404286077.222.64.5861 at TOPS20.DEC.COM>

Two points of clarification (from the source of those numbers, by the
way!):  You are using numbers that represent the numbers of machines,
not sites!  The number of sites peaked at ~830-840, and is now down to
around ~600.  This includes >~100 2020 sites outside of the USA.

Our (digital's) expectation 5 years ago was that 3/4 of the user base
would be on their way, or finished, moving to VAXes, not that the LCG
systems would be all gone by now.  That in fact is how things stand at
this time: most of the 10/20 sites are in the process of moving.

I'm sorry if the numbers and graphs I did for Connie Davis at DECUS
were a bit confusing, and did not clearly state Digital's perception
of events, but ...

-reed powell

  --------
6-Jun-88 11:47:46-PDT,2651;000000000000
Return-Path: <[email protected]>
Received: from ardvax.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 11:47:21-PDT
Received: from KSL-1186-4.Stanford.EDU by ardvax.stanford.edu with TCP; Mon, 6 Jun 88 11:47:22 PDT
Date: Mon, 6 Jun 88 11:41:52 PDT
From: Mark Crispin <[email protected]>
Subject: 10/20 interest group
To: [email protected]
Message-Id: <[email protected]>

    This is in response to Clyde Poole's message about DECUS.

    I created this distribution list 9 years ago.  I am a systems programmer
at a site that has a 2065 and a 2020, and from time to time I update bits on
these machines.  The 2065's plug will be pulled anywhere from 1-3 years from
now.  The 2020 will probably stay around forever.  I've provided software
support for two 2065 systems, one of which has *no* plug-pulling plans and the
other of which has had the date repeatedly pushed back "one more year".  To
top it all off, I personally own two 2020 systems, one of which is operational
and is known to the net as PANDA.PANDA.COM.

    Obviously, I care a helluva lot about 20's.

    The problem with DECUS is that for the most part recent DECUS symposia
have been a collossal waste of time and money.  The VAX sessions are
completely uninteresting to me, and the 10/20 sessions have fallen into one of
these categories:
. bitching and moaning about how rotten DEC has treated us or at Systems
  Concepts for not panning out as the White Knight.  (not too many of these
  recently)
. glassy-eyed DECies talking about how wonderful the next version of the
  operating system is going to be, as if nothing is going on, and dead
  silence if you ask about languages or layered products.
. re-hashing stuff that many of us already know about, e.g. tools, domains,
  etc.
. commiserating our shared fate, typically with generous amounts of alcohol.

    This may be fine and good, but it's damn difficult to economically
justify the (ever-soaring!!) expense of going to a DECUS symposium.  It now
costs more to go to DECUS for one day than it did to go for the entire week a
couple of years ago.

    I think a separate meeting from the mass symposia would be a good idea.
I reject the notion of it being separate from DECUS -- we **ARE** DEC users,
so why the push to kick us out of DECUS (and DECUS support!).

    Therefore, I suggest reviving the old 10/20 symposia.  Maybe it only
needs to be a day or two, and it would be much smaller scale than the VAX-zoo
symposia.  Maybe, it'd even be worthwhile to go to.

6-Jun-88 13:08:04-PDT,4017;000000000000
Return-Path: <[email protected]>
Received: from sally.utexas.edu by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 13:05:51-PDT
Posted-Date: Mon, 6 Jun 88 15:02:31 cdt
Received: by sally.utexas.edu (5.54/1.12)
       id AA28752; Mon, 6 Jun 88 15:06:02 CDT
X-Notice: Mail into the domain CS.UTEXAS.EDU should be routed
       through the relay host CS.UTEXAS.EDU.  SMTP connections
       to our other hosts will be discontinued approximately 1-Aug-88.
Date: Mon, 6 Jun 88 15:02:31 cdt
From: [email protected] (Clyde T. Poole)
Message-Id: <8806062002.AA08096@red>
Received: by red (13.1/4.22)
       id AA08096; Mon, 6 Jun 88 15:02:31 cdt
To: [email protected]
Cc: [email protected]
In-Reply-To: Mark Crispin's message of Mon, 6 Jun 88 11:41:52 PDT <[email protected]>
Subject: Re: 10/20 interest group

Ah...  someone took the bait...

  Posted-Date: Mon, 6 Jun 88 11:41:52 PDT
  Date: Mon, 6 Jun 88 11:41:52 PDT
  From: Mark Crispin <[email protected]>

[lots of stuff deleted]

       Obviously, I care a helluva lot about 20's.

Caring about -20's and caring about DECUS are two VERY different things.
No one gets anything from DECUS if no one puts anything in.

       The problem with DECUS is that for the most part recent DECUS symposia
  have been a collossal waste of time and money.  The VAX sessions are
  completely uninteresting to me, and the 10/20 sessions have fallen into one of
  these categories:
   . bitching and moaning about how rotten DEC has treated us or at Systems
     Concepts for not panning out as the White Knight.  (not too many of these
     recently)
   . glassy-eyed DECies talking about how wonderful the next version of the
     operating system is going to be, as if nothing is going on, and dead
     silence if you ask about languages or layered products.
   . re-hashing stuff that many of us already know about, e.g. tools, domains,
     etc.
   . commiserating our shared fate, typically with generous amounts of alcohol.

Interesting that you should say all of the above.  I agree with it pretty
much.  The question is how did this come about?  Its really VERY simple.
The Large Systems SIG has had VERY LITTLE support from its constituancy.
When was the last time you presented a session at a DECUS Symposium Mark?
The sessions you have seen at DECUS are what the Steering Committee was
able to produce WITHOUT anyone returning a Call For Participation.

       This may be fine and good, but it's damn difficult to economically
  justify the (ever-soaring!!) expense of going to a DECUS symposium.  It now
  costs more to go to DECUS for one day than it did to go for the entire week a
  couple of years ago.

Absolutely correct.  For a couple of years the Steering Committee has tried
to keep all the DEC-10 -20 sessions on 3 consecutive days, so that you
didn't have to pay for the entire 5 day symposium if you didn't want to.

       I think a separate meeting from the mass symposia would be a good idea.
  I reject the notion of it being separate from DECUS -- we **ARE** DEC users,
  so why the push to kick us out of DECUS (and DECUS support!).

       Therefore, I suggest reviving the old 10/20 symposia.  Maybe it only
  needs to be a day or two, and it would be much smaller scale than the VAX-zoo
  symposia.  Maybe, it'd even be worthwhile to go to.

If there were volunteers to GIVE and CHAIR sessions and to man the Steering
Committee, there would be no problem with continuing the SIG.  It isn't
even necessary to have a seperate symposia.  Simply scheduling for one or
two days at the regular meetings would work just fine.  We need to
focus on the REAL problem here, that is the lack of interest in PARTICIPATING
in the DECUS leadership or in preparing and giving interesting and useful
sessions at symposia.  Without volunteers that can and will commit time
and effort, all the complaining in the world will not help.

ctp
6-Jun-88 13:47:14-PDT,2094;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Jun 88 13:47:00-PDT
Received: from KSL-1186-4.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Mon, 6 Jun 88 13:44:52 PDT
Date: Mon, 6 Jun 88 13:39:24 PDT
From: Mark Crispin <[email protected]>
Subject: Re: 10/20 interest group
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
In-Reply-To: <8806062002.AA08096@red>

Clyde -

    You have missed the point completely.

    The current DECUS VAX-zoo is too expensive to go to even for one day
(especially for one day).  I lay a lot of blame for it squarely on DECUS
management's shoulder.  The DECUS symposia have become high-overhead with a
great deal of extraneous frills; what's more, DECUS symposia pricing in recent
years has been established to discourage anything less than full-week
memberships.  Don't deny it, the DECUS staff has admitted as much!

    No matter how interesting any 10/20 session may be at the VAX-zoo, I
cannot justify going to such an expensive symposium in terms of time or money.
I can not/will not spend a week at a symposia for which there is only a day's
worth of sessions which are interesting (I could care less about the
migration-to-VMS sessions).  I can not/will not spend several hundred dollars
for a single day meeting, particularly if it's unlikely I'll hear anything I
don't already know.

    The VAX-zoo is probably perfect as it is for the VAX users, who have an
action-packed week full of fun and thrills.  It is utterly unsuited for us, in
any form.

    Until/unless we have a meeting which is exclusively 10/20 oriented and is
priced towards what we will get out of it, "include me out."  I won't go, much
less consider presenting any sessions.  Is DECUS willing to offer 10/20 sites
1-day attendance at the VAX-zoo for the 10/20 sessions for $100?  I doubt it.
So don't even mention the idea.

-- Mark --

20-Jun-88 06:01:45-PDT,568;000000000000
Return-Path: <[email protected]>
Received: from MATH.AMS.COM by SCORE.STANFORD.EDU with TCP; Mon 20 Jun 88 05:54:27-PDT
Date: Mon 20 Jun 88 08:44:39-EDT
From: Betsy Ramsey <[email protected]>
Subject: IPABFL Bugchks
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

       I'm running a V6.1 AP15 AN monitor, and I'm getting IPABFL
       bugchks about once every ten days.  We're having to reboot to
       clear this.

       Anyone else have this problem or know of a fix for it?  I'm
       not a source site.

       Thanks.
-------
23-Jun-88 14:32:32-PDT,847;000000000000
Return-Path: <[email protected]>
Received: from research.att.com by SCORE.STANFORD.EDU with TCP; Thu 23 Jun 88 14:21:24-PDT
From: [email protected]
Date: Thu, 23 Jun 88 17:20:05 EST
>From: [email protected] (Jim Supplee, Physics Dept.)
To: tms%[email protected]
Subject: Is this working?
X-VMS-To: TOMS
Message-Id: <8852317206.20200973.FS$JSUPPLEE>

Tom,

    Hello, Hello.

    After many attempts, I finally found an address for you that does not
give any immediate error messages;  maybe we're connected??  If you do
really get this, please let me know-- either by electronic reply or (if
that fails) call 420-5705 or 653-8286.

    Hope you're having a good summer.  I'll be working at Drew beginning
July 25.
                                                Jim

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

27-Jun-88 16:32:03-PDT,428;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 27 Jun 88 16:28:05-PDT
Date: Mon, 27 Jun 88 16:25:12 PDT
From: Susan Kahn <[email protected]>
Subject: Version numbers on UNIX
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

Does anyone know of an implementation of file version numbers on UNIX?

Susan
-------
10-Jul-88 20:21:39-PDT,3202;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Sun 10 Jul 88 20:19:52-PDT
Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
       id AA28541; Sun, 10 Jul 88 23:19:28 EDT
Message-Id: <[email protected]>
Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5)
       id AA13813; Mon, 11 Jul 88 13:00:35 EST
       (from [email protected] for [email protected])
Date: Mon, 11 Jul 88 09:02:34 EST
From: [email protected] (Craig Warren)
Received: by kokab.cc.deakin.oz (4.0)
       id AA05610; Mon, 11 Jul 88 09:02:34 EST
X-Mailer: Mail User's Shell (6.3 6/25/88)
To: [email protected]
Subject: Problems with DBMS And Cobol-13


I have just upgraded to Tops20 6.1 (At last!), and have
installed Cobol-V13 and DBMS 6.1. Unfortunately something is
wrong. I have rebuilt the Cobol runtime system to include
support for DBMS, but I am having trouble with loading
routines that include DBMS verbs:

12:55:58 MONTR   $@Load/NOSY PRBSOC,PRDPRM,PPRMVL,PZNMPD,PWKDAY,A:A/LIB,Z:Z/LIB,NAME,%"VERSION:0(3744)"
12:56:20 USER   MACRO:  NAME
12:56:21 USER   LINK:   Loading
12:56:28 USER   ?LNKUGS 4 undefined global symbols
12:56:28 USER           CLOSED  405666
12:56:28 USER           FIND5   405257
12:56:28 USER           GETS    405354
12:56:28 USER           JBTRAN  405566
12:56:28 MONTR   $
...

Here are some size details:

13:01:15 MONTR  @Vdirectory Subsys:Cobol,Subsys:Coblib,Subsys:Cobots-v13,Subsys:dbms
13:01:16 MONTR
13:01:16 MONTR     PS:<SUBSYS>
13:01:16 MONTR   COBOL.EXE.2;P777752      203 103936(36)  9-Jul-88 17:35:37 OPERATOR
13:01:16 MONTR     .HLP.1;P777752           2 4802(7)    30-Jun-83 04:51:48 NIXON
13:01:16 MONTR   COBLIB.REL.5;P777752     127 64626(36)  10-Jul-88 11:32:52 OPERATOR
13:01:17 MONTR   COBOTS-V13.EXE.2;P777752  85 43520(36)   9-Jul-88 17:00:28 OPERATOR
13:01:17 MONTR   DBMS.REL.3;P777752        69 35328(36)   9-Jul-88 17:00:00 OPERATOR
13:01:17 MONTR
13:01:17 MONTR   Total of 486 pages in 5 files
13:01:17 MONTR   $@Get Subsys:Link
13:01:17 MONTR
13:01:17 MONTR   $@Information Version
13:01:17 MONTR   Snark - "The Last DECsystem-20", TOPS-20 Monitor 6.1(7030)
13:01:17 MONTR   TOPS-20 Command processor 6.1(273)
13:01:17 MONTR   Program is LINK, version is 6(2364)
13:01:17 MONTR  PDVs:   Program name LINK, version 6(2364)
13:01:17 MONTR   $@Get Subsys:Cobol
13:01:18 MONTR
13:01:18 MONTR   $@Information Version
13:01:18 MONTR   Snark - "The Last DECsystem-20", TOPS-20 Monitor 6.1(7030)
13:01:18 MONTR   TOPS-20 Command processor 6.1(273)
13:01:18 MONTR   Program is COBOL, version is 13(1515)
13:01:18 MONTR   $
13:01:19 MONTR  Killed by OPERATOR, TTY 173
13:01:19 MONTR  Killed Job 11, User OPERATOR, Account , TTY 203,
13:01:19 MONTR    at 10-Jul-88 13:01:19,  Used 0:00:02 in 0:00:05

I have read fairly carefully the installation instructions
in both Installing Cobol and Installing DBMS, and I expect
that I have done something wrong in one of these steps. Can
anyone provide any insight?

Craig Warren            ARPA:   ccw%[email protected]
                       UUCP:   ...!uunet!munnari!charlie.oz!ccw


13-Jul-88 10:00:02-PDT,658;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Wed 13 Jul 88 09:56:53-PDT
Mail-From: SKAHN created at 27-Jun-88 16:25:12
Date: Mon, 27 Jun 88 16:25:12 PDT
From: Susan Kahn <[email protected]>
Subject: Version numbers on UNIX
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
ReSent-Date: Wed, 13 Jul 88 09:43:52 PDT
ReSent-From: Susan Kahn <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

Does anyone know of an implementation of file version numbers on UNIX?

Susan
-------
13-Jul-88 15:18:13-PDT,1962;000000000000
Return-Path: <[email protected]>
Received: from unix.SRI.COM by SCORE.STANFORD.EDU with TCP; Wed 13 Jul 88 15:17:05-PDT
Received: by unix.SRI.COM (5.31/5.14)
       id AA11040; Wed, 13 Jul 88 15:17:18 PDT
Received: by orc.olivetti.com (3.2/SMI-3.2)
       id AA06455; Wed, 13 Jul 88 15:11:50 PDT
Date: Wed, 13 Jul 88 15:11:50 PDT
From: [email protected] (David Roode)
Message-Id: <[email protected]>
To: [email protected]
Subject: DECsystem30

A story in today's San Jose Mercury says that DEC is preparing to
launch an entire range of machines based on the MIPS processor design.
I have heard quietly that a new "MicroVax" is about to be released,
and that it may well be a multiprocessor design.

Given their current product positioning, I was having a hard time
seeing how they could introduce something interesting without it
competing with their existing VAX business.  It seems rather soon for
an additional MicroVax product such as this one is supposed to
be--significantly more processor power and better price/performance
than the MicroVAX 3000 series, not just a new package like the most
recent Sun announcement.

If DEC were to introduce a non-VAX processor system, it would avoid
all of these pitfalls.  It would also open up many cans of worms, and
would be very interesting to watch.  Supposedly DEC is feeling
increased competition from non-VAX processors.  In some senses, what
they would like to do is to sell VAX to those who will pay for it, yet
have something else to sell to the customers who are awake.  Recall
that they dropped the PDP-10/DEC-20 line ostensibly because it was
uneconomical for them to support two different architectures.

If DEC makes VMS run on the new processor series, and creates source
level compatibility for compilers, they could have multiple architectures.
Then though, they would start to impact  their lucratively priced
sales of VAX processors.
14-Jul-88 10:59:12-PDT,3001;000000000000
Return-Path: <bzs%[email protected]>
Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Thu 14 Jul 88 10:53:36-PDT
Received: from BU-CS.BU.EDU by bu-it.BU.EDU (5.58/4.7)
       id AA20378; Wed, 13 Jul 88 22:53:44 EDT
Return-Path:  <bzs>
Received:  by bu-cs.bu.edu (5.31/4.7)
       id AA17591; Wed, 13 Jul 88 22:57:02 EDT
Date:  Wed, 13 Jul 88 22:57:02 EDT
From: bzs%[email protected] (Barry Shein)
Message-Id:  <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: David Roode's message of Wed, 13 Jul 88 15:11:50 PDT <[email protected]>
Subject: DECsystem30


Interesting, I recently heard just this as a rumor, guess it was
true.

I've heard rumors of some attempts (internally) to make VMS portable
but I've never given them much credence (I believe fully that someone
had the job to evaluate how hard that would be to do, but I doubt
strongly that the conclusion was affirmative, I think it's architected
for the Vax in many ways, nothing is impossible, but I'd be shocked.)
Pieces could start to show up (like the VMS Fortran compiler), but
that's neither here nor there.

So that leaves one with the conclusion that this new MIPS chip based
processor runs only Unix (Ultrix? MIPSix [they have a Unix themselves
that's supposed to be very good]? AIX? [OSF])

That makes some sense.  The current major MIPS VAR is Silicon Graphics
(other than MIPS which doesn't make workstations with graphics/bitmap
heads.) They (SGIC) tend to market high end graphics workstations tho
they'll be announcing something soon in a lower price range, could be
pretty head-on (or, put another way, I wonder what Silicon Graphics'
future is, particularly in terms of obtaining MIPS chips.)

I thought about the possibility of a dual architecture model with a
MIPS chip and a uVax chip, able to run Unix and VMS, but it really
doesn't make any sense (I only mention it to see if someone else can
come up with a reasoning for that, just a speculation.) One major
problem would be that you'd probably need 1GB of disk to get
everything on, and administration would be a nightmare (not to mention
communications between the two systems), yet somehow it seems worth
pondering for a moment.

I do think the old comment is coming true about the Vax, they couldn't
make it fast and they couldn't make it cheap (not to completely malign
a company with $10B in sales...)

An interesting data point is that the last I checked the R3000
(current MIPS chip) ran the Dhrystone benchmark (non-floating pt,
non-IO) a little faster than the IBM3090 (well, the 3090 we have here,
I think there's a little faster 3090 out now, still in the same
ballpark.) I think FP is around 3.5MFlops (nothing to be ashamed of,
but not a super-computer), not sure what it would rate on I/O, but an
*expensive* one is only around $50K. This is from memory.

Interesting.

       -Barry Shein, Boston University

15-Jul-88 05:57:42-PDT,1080;000000000000
Return-Path: <IMHW400%[email protected]>
Received: from lindy.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 05:57:10-PDT
Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 15 Jul 88 05:57:37 PDT
Received: by Forsythe.Stanford.EDU; Fri, 15 Jul 88 05:59:25 PDT
Received: by INDYCMS (Mailer X1.25) id 7649; Fri, 15 Jul 88 07:51:21 EST
Date:         Fri, 15 Jul 1988 07:40 EST
From: Mark H. Wood <IMHW400%[email protected]>
Subject:      Re:  DECsystem30
To: <[email protected]>

I'd read about the MIPS deal in the trade papers, and I wonder if the MIPS
chips aren't destined to hide inside some kind of dedicated X-window client
system; that is, a very-high-performance terminal that speaks DECwindows
but provides no local processing to the user.  I really don't see DEC
introducing another architecture at this time, *especially* one that would
run Un*x before they could have VMS ready!  I don't think we'll see the MIPS
chips in an independent, general-purpose computer from DEC, for some time
to come.
15-Jul-88 06:34:51-PDT,2144;000000000000
Return-Path: <bzs%[email protected]>
Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 06:34:36-PDT
Received: from BU-CS.BU.EDU by bu-it.BU.EDU (5.58/4.7)
       id AA05371; Fri, 15 Jul 88 09:24:26 EDT
Return-Path:  <bzs>
Received:  by bu-cs.bu.edu (5.31/4.7)
       id AA07581; Fri, 15 Jul 88 09:27:47 EDT
Date:  Fri, 15 Jul 88 09:27:47 EDT
From: bzs%[email protected] (Barry Shein)
Message-Id:  <[email protected]>
To: IMHW400%[email protected]
Cc: [email protected]
In-Reply-To: Mark H. Wood's message of Fri, 15 Jul 1988 07:40 EST <[email protected]>
Subject:  DECsystem30


>I'd read about the MIPS deal in the trade papers, and I wonder if the MIPS
>chips aren't destined to hide inside some kind of dedicated X-window client
>system; that is, a very-high-performance terminal that speaks DECwindows
>but provides no local processing to the user.  I really don't see DEC
>introducing another architecture at this time, *especially* one that would
>run Un*x before they could have VMS ready!  I don't think we'll see the MIPS
>chips in an independent, general-purpose computer from DEC, for some time
>to come.

I wouldn't discount anything (neither does DEC, heh heh, joke), but
putting a ~12MIPs or more general purpose CPU in just to run X-windows
would seem like a strange approach to me, why not just add a good
graphics co-processor? They exist.

DEC released the GPX with Unix before VMS, it has happened,
particularly in the workstation arena (wasn't the "calypso", a four
CPU vax, recently released Unix-first? Not sure, it may have been
simultaneous tho the people I've heard of being approached before
official announcement were only talking about Unix.)

It's quite possible that Unix is just that much stronger in areas like
CAD/CAM that it's justified to emphasize it over VMS within such
product lines, even in DEC's mind. I don't think anyone has accused
VMS of being a particularly attractive graphics *workstation*
environment, unless you happen to already be committed to it.

       -Barry Shein

15-Jul-88 06:51:01-PDT,1623;000000000000
Return-Path: <[email protected]>
Received: from vx2.GBA.NYU.EDU by SCORE.STANFORD.EDU with TCP; Fri 15 Jul 88 06:50:48-PDT
Received: by vx2.GBA.NYU.EDU (5.51/) id AA08711; Fri, 15 Jul 88 09:49:08 EDT
Date: Fri, 15 Jul 1988 9:49:06 EDT
Sender: Ittai Hershman <[email protected]>
From: Ittai Hershman <[email protected]>
To: Mark H.Wood <IMHW400%[email protected]>
Cc: <[email protected]>
Office-Phone: 212-285-6080
Subject: Re: DECsystem30
In-Reply-To: Your message of Fri, 15 Jul 1988 07:40 EST
Message-Id: <[email protected]>

   I'd read about the MIPS deal in the trade papers, and I wonder if the MIPS
   chips aren't destined to hide inside some kind of dedicated X-window client
   system; that is, a very-high-performance terminal that speaks DECwindows
   but provides no local processing to the user.

I find that hard to swallow.  After all a 68020 could easily handle that,
and no one would blink an eyelash if Digital bought into that technology.
It would also be *much* cheaper.

Actually, I think that Digital is making a serious mistake.  They have
spent the last 5 years putting all their eggs in one basket for strategic
marketing reasons (the ubiquitous "Digital has it now" coupled with the
single architecture concept).  Its bad enough for them to have to admit
that we were all correct when we told them that the VAX is not going to
be able to sustain them, but to go out and buy someone elses technology
-- that's really makes them look bad.

Personally, I'd rather buy into the SUN-4...

-Ittai
16-Jul-88 08:18:43-PDT,549;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sat 16 Jul 88 08:15:26-PDT
Date: Sat, 16 Jul 1988  09:15 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: PING for TOPS-20?

Does anyone have a working TOPS20 version of the Unix "ping" program?
Unfortunately, the statistics gathering programs which use the hooks
in the BBN TCP monitors won't help here.

--Frank
18-Jul-88 17:51:36-PDT,1414;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET ([192.12.141.129].#Internet) by SCORE.STANFORD.EDU with TCP; Mon 18 Jul 88 16:42:13-PDT
Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
       id AA14185; Mon, 18 Jul 88 19:41:19 EDT
Message-Id: <[email protected]>
Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5)
       id AA05523; Tue, 19 Jul 88 08:59:00 EST
       (from [email protected] for [email protected])
Date: Tue, 19 Jul 88 08:44:23 EST
From: [email protected] (Craig Warren)
Received: by kokab.cc.deakin.oz (4.0)
       id AA05468; Tue, 19 Jul 88 08:44:23 EST
X-Mailer: Mail User's Shell (6.3 6/25/88)
To: [email protected]
Subject: 6.1 Upgrade problems



Problem:        Many TTYSTP BUGINF's
               Occasional TTYBBO BUGCHK's
                       Big Buffer Overflow's
               Many Front-End crashes
                       Somtimes proceeded by DTESUI BUGINF's
                       often just get 11-HALT
                                      B03

Scenario:       Just upgraded to 6.1 + RSX-20F VB15-21

Suspects:       We do block data input from a number of our
               terminals, which seems to cause the
               Front-End a great amount of difficulty.

Solution:       ? - Anyone seen a similar problem?

Craig Warren    ARPA:   ccw%[email protected]
               UUCP:   ...!uunet!munnari!charlie.oz!ccw


20-Jul-88 16:26:10-PDT,876;000000000000
Return-Path: <[email protected]>
Received: from dorsai.ics.hawaii.edu by SCORE.STANFORD.EDU with TCP; Wed 20 Jul 88 16:24:30-PDT
Received: from uhccux.uhcc.hawaii.edu by dorsai.ics.hawaii.edu with SMTP id 4201; Wed, 20 Jul 88 13:25:56 HST
Date:   Wed, 20 Jul 88 10:16:00 HST
From:   Jeffrey Blomberg <[email protected]>
To:     [email protected]
Subject: Telnet
Message-Id: <[email protected]>

Aloha!   We are running telnet 6.1(935) and occasionally encounter IPIBLP
bugchks when a user runs telnet to login to our Ultrix system.  I was
wondering if anyone else has encountered these bugchks?  Is there a newer
(should I venture to say 'better') version of telnet floating around.

                                                               -Jeff

ps: We have already rebuilt the monitor to increase the buffer size.  Also,
   we are communicating over an NI.

20-Jul-88 17:40:55-PDT,1330;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 20 Jul 88 17:40:31-PDT
Received: from KSL-1186-4.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Wed, 20 Jul 88 17:36:22 PDT
Date: Wed, 20 Jul 88 17:34:17 PDT
From: Mark Crispin <[email protected]>
Subject: re: Telnet
To: Jeffrey Blomberg <[email protected]>
cc: [email protected]
Message-ID: <[email protected]>

Jeff -

    Your message's headers had linefeeds instead of CR/LF's in it.  Perhaps
there is a bug in the mail program you are using on uhccux.uhcc.hawaii.edu;
you may want to check up on that.

    My current version of TELNET (I wrote it) is 6.1(959).  However, none of
the changes between 935 and 959 would correct your problem, and anyway, the
problem is a monitor not a Telnet problem.

    I suggest that you try to increase the value of NNIPIB (in STG.MAC, this
is the number of buffers to keep around) from ^D40 to some higher value,
rebuild your monitor, and see if that doesn't make the problem go away.  You
may also want to put on a network line monitor to see if you aren't getting
something like a broadcast storm or other strange behavior.

-- Mark --

20-Jul-88 18:48:19-PDT,1752;000000000000
Return-Path: <rmf%Stasis.MRC.AdhocNet.CA%[email protected]>
Received: from lindy.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 20 Jul 88 18:47:59-PDT
Received: by lindy.Stanford.EDU (4.0/4.7); Wed, 20 Jul 88 18:48:36 PDT
Received: by Forsythe.Stanford.EDU; Wed, 20 Jul 88 18:50:25 PDT
Date: Wed, 20 Jul 88 18:50:25 PDT
From: <rmf%Stasis.MRC.AdhocNet.CA%[email protected]>
To: [email protected]
Subject: Re: 6.1 Upgrade problems

Received: from Stasis.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Wed, 20 Jul 88 08:59:47 MDT
Date:     Wed, 20 Jul 88 08:58:15 MDT
From:     rmf%Ins.MRC.AdhocNet.CA%Stasis.MRC.AdhocNet.CA@UNCAEDU.
        BITnet (Russ Forster)
Message-Id: <[email protected]>
Subject:  Re: 6.1 Upgrade problems
In-Reply-To: Your message <[email protected]> dated 19-Jul-1988
To:       [email protected]



> Problem:        Many TTYSTP BUGINF's
>                 Occasional TTYBBO BUGCHK's
>                         Big Buffer Overflow's
>                 Many Front-End crashes
>                         Somtimes proceeded by DTESUI BUGINF's
>                         often just get 11-HALT
>                                        B03

> Scenario:       Just upgraded to 6.1 + RSX-20F VB15-21

       The released version of RS-20F for 6.1 is 15-50.  Maybe
       you should start there.

       /Russ

-----
Russell M. Forster

Mount Royal College        DECnet: RMF @ { Flux | Stasis | Ins }
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      USEnet: uunet!calgary!vaxa!forster
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
22-Jul-88 19:59:24-PDT,1020;000000000000
Return-Path: <MAILER%[email protected]>
Received: from lindy.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 22 Jul 88 19:58:40-PDT
Received: by lindy.Stanford.EDU (4.0/4.7); Fri, 22 Jul 88 19:59:03 PDT
Received: by Forsythe.Stanford.EDU; Fri, 22 Jul 88 20:00:40 PDT
Received: from kth.se by KTH-BITNET-GATEWAY ; 23 Jul 88 02:52:35 GMT
Received: from kicki.stacken.kth.se by kth.se (5.57+IDA+KTH/3.0)
       id AA27051; Sat, 23 Jul 88 04:52:26 +0200
Date: Sat, 23 Jul 88 04:54:56 +0200
From: ROLL%[email protected] (Peter Lothberg)
To: [email protected]
Subject: Ethernet interface for KL10
Message-Id: <[email protected]>



In these days when everyone gets rid of their KL processors, we are
out trying to find a Ethernet interface. A NIA-20 or a MEIS or anything
else that might work.

Anyone out there that knews one that is just colecting dust or so?

Peter Lothberg, Stacken Computer Club, [email protected], [email protected]



24-Jul-88 01:39:56-PDT,1323;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARPA by SCORE.STANFORD.EDU with TCP; Sun 24 Jul 88 01:38:26-PDT
Date: Sun, 24 Jul 1988  02:38 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: Wanted: Excess DECSYSTEM-20 equipment

This is a repeat request.  If any other goverment agency is about to
excess their DECSYSTEM-20, particularly if it is a Model 2065, please
contact me via netmail or at AV 258-6258 (505-678-6258) between 10am
and 5pm MST.  We are also interested in certain other equipment such
as RP07-AA disk drives to support our every growing "public domain"
collections, and any of the following:

RP07-C Dual Access Kits - we can use four now, more later as we add
drives.

CI20-AA - we can use two to interconnect the second machine whenever
it appears.

SC-0008 - Star coupler to go with the CI20-AA.

NIA20 - Ethernet Interface - grandious plans for an alternate path...

DELNI - just one for now.

A LAT box - maybe...

We are also willing to consider indefinite loans of any of the above
equipment.  Any of the equipment must be DEC deinstalled so that it
can qualify for continuing DEC maintenance once installed here.

--Frank
26-Jul-88 23:45:48-PDT,1367;000000000000
Return-Path: <[email protected]>
Received: from MACBETH.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 26 Jul 88 23:45:46-PDT
Date: Sun 24 Jul 88 13:05:16-PDT
From: Sean L. Welsh <[email protected]>
Subject: Othello Retired from Service
To: [email protected]
Message-ID: <[email protected]>
ReSent-Date: Tue 26 Jul 88 23:43:39-PDT
ReSent-From: Eric M. Berg  <[email protected]>
ReSent-To: [email protected]
ReSent-Message-ID: <[email protected]>

Due to an air-conditioning malfunction in the AIR computer room,
Othello is down.  AIR Facilities and Operations had planned to
announce Othello's imminent retirement this week; we are instead
taking the opportunity of this unplanned outage to remove Othello from
service permanently.  We will re-assign the network address "Othello"
to Macbeth presently, in order that mail addressed to Othello will be
delivered; however, we would like to advise you at this time to inform
your correspondents to use one of the other AIR TOPS-20 addresses for
mail.  The Othello address will be retired eventually as well; AIR
will endeavor to make this change with as little impact as
practicable.

                                       Sean L. Welsh, Director
                                       Facilities and Operations
                                       Academic Information Resources
-------
7-Aug-88 11:59:56-PDT,1810;000000000000
Return-Path: <[email protected]>
Received: from VAX02.AMS.COM by SCORE.STANFORD.EDU with TCP; Sun 7 Aug 88 11:57:47-PDT
Return-Path: <@SEED.AMS.COM,@MATH.AMS.COM:[email protected]>
Received: from SEED.AMS.COM by VAX01.AMS.COM via SMTP with TCP; Sat,
         6 Aug 88 01:50:10-EDT
Received: from MATH.AMS.COM by SEED.AMS.COM with TCP; Sat 6 Aug 88
         01:49:10-EDT
Received: from CRVAX.SRI.COM by MATH.AMS.COM with TCP; Sat 6 Aug 88
         01:49:11-EDT
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Thu,
         4 AUG 88 22:49:20 PDT
Received: from ucbvax.berkeley.edu by KL.sri.com with TCP; Thu,
         4 Aug 88 05:38:30 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28) id AA13467; Wed,
         3 Aug 88 21:09:16 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
         [email protected] ([email protected]) (contact
         [email protected] if you have questions)
Date: 3 Aug 88 09:54:56 GMT
From: [email protected]
Subject: WHY ARE (were) THERE 36 BITS?
Message-Id: <[email protected]>
Sender: [email protected]
To: [email protected]
ReSent-date: Sun 7 Aug 88 14:58:07-EDT
ReSent-from: Betsy Ramsey <[email protected]>
ReSent-to: [email protected]


  Some time ago there was a video called "Why are there 36 bits?"
(or someting like that) shown at DECUS.  I never saw it - too many
other things going on I guess.  Anyone remember it?
  Anyway, we are planning a "wake" for our KL which will me retired
at the end of the month.  Seems like a suitable presentation for such
a solemn occasion.  Assuming it exists, could I get a copy?  And soon!
Please reply to me with any hints you may have.  If you would like to
see it too, I'll post again about where I find it (if I do).  Thanks.
Brent.

-------
7-Aug-88 12:09:52-PDT,845;000000000000
Return-Path: <[email protected]>
Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Sun 7 Aug 88 12:09:19-PDT
Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7)
       id AA23880; Sun, 7 Aug 88 15:10:31 EDT
Return-Path:  <[email protected]>
Received:  by buita (5.58/4.7)
       id AA10641; Sun, 7 Aug 88 15:10:34 EDT
Date:  Sun, 7 Aug 88 15:10:34 EDT
From: [email protected]
Message-Id:  <8808071910.AA10641@buita>
To: [email protected], [email protected], [email protected]
Subject: Re:  WHY ARE (were) THERE 36 BITS?

I was once asked a similar question when I was at a party of VMS types
and it came out that I worked for LCG.  Someone asked "what do you use
the extra 4 bits for?".  Before I could compose a better answer some
semi-enlightened soul shouted "no-ops!!"

I guess you had to be there.
                       -Phil

8-Aug-88 09:08:51-PDT,1386;000000000001
Return-Path: <[email protected]>
Received: from VAX02.AMS.COM ([130.44.1.5].#Internet) by SCORE.STANFORD.EDU with TCP; Mon 8 Aug 88 09:06:07-PDT
Date: Mon 8 Aug 88 12:05:29-EDT
From: Reed Powell <Powell%[email protected]>
Subject: Re: 36-bit Tape
Sender: [email protected]
To: [email protected], [email protected]
Cc: Powell%[email protected]
Reply-To: Powell%[email protected]
Message-ID: <[email protected]>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(132)+PONY(205)@VAX02.AMS.COM>

From:   HPSVAX::POWELL       "Reed B Powell HPS Mktg"
Date:   8-AUG-1988 08:57
Subj:   RE: WHY ARE (were) THERE 36 BITS?

Assuming this makes it through the gateways (and anyone sees this)...

The video in question was run at the 25th Anniversary of 36 bits in
DECUS celebration.  The video itself is an internal DEC video, and was
presented after receiving special dispensations, etc., from the Powers
That Be (now the Powers That Been).  I doubt if I can get the OK to
send out random copies.

The direct answer to your question is "so we could store 2 addresses
in one word for handling linked lists in LISP, and 18-bits was enough
to hold the highest possible address anyone would ever conceivably
want to address."  Remember that a lot of the motivation for the
architecture was from LISP needs.

-reed
-------
10-Aug-88 15:12:09-PDT,475;000000000000
Return-Path: <[email protected]>
Received: from SPAR-20.SPAR.SLB.COM by SCORE.STANFORD.EDU with TCP; Wed 10 Aug 88 15:10:24-PDT
Date: Wed 10 Aug 88 15:14:00-PDT
From: Doug Faunt <[email protected]>
Subject: MF20 power supply
To: [email protected]
Message-ID: <[email protected]>

I have a broken one (as well as two running and a spare), and am wondering i
anyone knows where I can get this one repaired.
-------
10-Aug-88 18:32:17-PDT,896;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 10 Aug 88 18:31:46-PDT
Date: Wed, 10 Aug 88 18:28:40 PDT
From: Mark Crispin <[email protected]>
Subject: KL10 request
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

A couple of hackers out in New Jersey have done some preliminary design
work in the area of KL service life extension.  One product they are
thinking of is a 4MW memory board which will set inside the CPU cabinet.

They are looking to acquire a KL10 for their hardware hacking efforts,
since obviously you can't do this on a production machine.

Does anybody have a KL they are willing to part with for this noble effort?

-- Mark --
-------
15-Aug-88 17:53:19-PDT,1264;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 15 Aug 88 17:47:15-PDT
Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
       id AA21699; Mon, 15 Aug 88 20:46:55 EDT
Message-Id: <[email protected]>
Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5)
       id AA20774; Tue, 16 Aug 88 10:30:42 EST
       (from [email protected] for [email protected])
Date: Tue, 16 Aug 88 10:25:58 EST
From: [email protected] (Craig Warren)
Received: by kokab.cc.deakin.oz (4.0)
       id AA06900; Tue, 16 Aug 88 10:25:58 EST
X-Mailer: Mail User's Shell (6.3 6/25/88)
To: [email protected]
Subject: Problem with Isam after upgrading to 6.1

I have a problem with Isam after upgrading to 6.1. Programs
that access 2 Isam files eventually die with a

       ?PA1050: Illegal instruction 6,,0 at user 0

after running sometimes for several minutes. The programs
dont necessarily have both Isam files open at the same time.
If I change the programs to use only a single Isam file,
they run correctly.

What monitor resource does Isam require?

Craig Warren                            ccw%[email protected]
22-Aug-88 15:42:54-PDT,2798;000000000000
Return-Path: <[email protected]>
Received: from columbia.edu by SCORE.STANFORD.EDU with TCP; Mon 22 Aug 88 15:39:27-PDT
Received: from cunixc.cc.columbia.edu by columbia.edu (5.54/1.14)
       id AA13274; Mon, 22 Aug 88 15:59:03 EDT
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA16346; Mon, 22 Aug 88 15:58:25 EDT
Date: Mon, 22 Aug 1988 15:58:18 EDT
From: Melissa <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Columbia-MM for Unix
Message-Id: <[email protected]>

In September, if things go as planned, the Columbia Computer Center is
getting rid of CU20B, our last DEC20.  We're mostly moving to UNIX
systems.  I suspect there are a lot of sites like us out there, and I
thought I should mention some good news for those moving to UNIX.

Most of you have probably heard about CCMD, the COMND jsys package
written in C.  The first major program written using CCMD is MM, which
is right now in Beta testing.  We had hoped to be out of Beta testing
by the end of the summer, but it looks like we won't make it. However,
anyone who would like MM now is welcome to it.  (See copyright notice
below.)

Whether you want MM now, or want it after Beta testing, send some mail
to [email protected] and we'll send you more info and put
you on the announcement mailing list.  If you grab a copy for testing,
please register with us, so you'll get bug reports and patches.

Columbia-MM is available via anonymous ftp from cunixc.cc.columbia.edu
(128.59.40.130 since August 15).  You'll have to cd to the mm
subdirectory, from which you can get mm-intro.txt, which will explain
the other files available.

Versions of MM are being run on Ultrix, BSD 4.2/4.3, SunOS 3.2, SunOS
4.0, Pyramid, DYNIX 2.0 (Sequent Balance 21000), and Celerity systems.
The HP-UX and System V ports are currently in progress.  (At Columbia
we only test MM under Ultrix 2.0 and SunOS 4.0, and rely on our beta
testers for the other ports.)

Hope this warms your little TOPS20 hearts :-)...

                                       --Melissa


MM is:

Copyright (c) 1986, 1987, 1988, The Trustees of Columbia University in
the City of New York.  Chris Maio, Computer Research Facilities,
Computer Science Department, Fuat C. Baran, Howard Kaye, Melissa Metz,
Academic Systems Group, Center for Computing Activities.

Permission is granted to any individual or institution to use, copy,
or redistribute this software so long as it is not sold for profit,
provided that this notice and the original copyright notices are
retained.  Columbia University makes no representations about the
suitability of this software for any purpose.  It is provided "as is"
without express or implied warranty.
22-Aug-88 16:08:50-PDT,947;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Mon 22 Aug 88 16:07:56-PDT
Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
       id AA09250; Mon, 22 Aug 88 04:41:52 EDT
Message-Id: <[email protected]>
Received: from kokab.cc.deakin.oz (via mulga) by munnari.oz with SunIII (5.5)
       id AA28464; Mon, 22 Aug 88 17:34:31 EST
       (from [email protected] for [email protected])
Received: by kokab.cc.deakin.oz (4.0)
       id AA06886; Mon, 22 Aug 88 15:42:37 EST
To: Tops20 People  <[email protected]>
Subject: Ethernet/Tcp utilities
Date: Mon, 22 Aug 88 15:40:35 +1000
From: Craig Warren <[email protected]>


Having just attached our 20 to our backbone Ethernet, we are
now in the market for utilities. I currently have Telnet,
FTP and NFS. What other utilities can people offer?


26-Aug-88 01:42:37-PDT,566;000000000000
Return-Path: <[email protected]>
Received: from STL-HOST1.ARPA by SCORE.STANFORD.EDU with TCP; Fri 26 Aug 88 01:40:49-PDT
Date: Fri, 26 Aug 88 03:39:47 CDT
From: Frank J. Wancho <[email protected]>
Subject: ACTGEN in reverse?
To: [email protected]
Message-ID: <[email protected]>

I seem to recall seeing a description of a program designed to
create an ACCOUNTS.CMD file from SYSTEM:ACCOUNTS-TABLE.BIN, probably
on a recent DECUS tape.  Does anyone have a copy of it online
and available via FTP?

--Frank
-------
2-Sep-88 05:59:23-PDT,1403;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Fri 2 Sep 88 05:56:48-PDT
Date: Fri 2 Sep 88 07:56:02-CDT
From: Clive Dawson <[email protected]>
Subject: Monitor Symbol Table Problems
To: [email protected]
Message-ID: <[email protected]>

A recent monitor I built (5.4) insists on trashing at least one entry
in its symbol table after it is booted.  I discovered this when
SYSDPY started producing very strange output, since the symbol involved
was NUFKS (number of forks allowed per job).  Other than this, the
system behaves normally.  A spot-check of various other symbols
showed they were ok.

Has anybody seen anything like this before?

Thanks,

Clive
------------------------------------

[PHOTO:  Recording initiated  Thu 18-Aug-88 11:11PM]

Link from AI.CLIVE, TTY 71

Tops-20 Command processor 5.1(121700)
2$;System has just been booted...
2$sy
Thu 18-Aug-88 23:11:23  Up 0:05:11
1+9 Jobs   Load av   1.49   0.84   0.37

No operator in attendance

Job  Line Program  User              Foreign host
  6*   71  Systat  Ai.Clive

  1   106  Sysjb1  Operator
  2   105  Ptycon  Operator
  3   110  Dsv     Operato^C
2$get system:monitr
2$st 140
DDT
nufks=30   ^C
2$^C
2$mddt
MDDT
nufks=777777,,777777   ^C
2$pop

[PHOTO:  Recording terminated  Thu 18-Aug-88 11:12PM]
-------
6-Sep-88 07:20:09-PDT,3432;000000000000
Return-Path: <[email protected]>
Received: from VAX02.AMS.COM ([130.44.1.5].#Internet) by SCORE.STANFORD.EDU with TCP; Tue 6 Sep 88 07:13:26-PDT
Return-Path: <@SEED.AMS.COM,@GIZMO.SRI.COM:[email protected]>
Received: from SEED.AMS.COM by VAX01.AMS.COM via SMTP with TCP; Sat,
         3 Sep 88 09:56:29-EDT
Received: from GIZMO.SRI.COM by SEED.AMS.COM with TCP; Sat 3 Sep 88
         09:56:02-EDT
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Sat,
         3 SEP 88 06:10:08 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Sat,
         3 Sep 88 05:51:23 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31) id AA04074; Sat,
         3 Sep 88 04:01:52 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
         [email protected] ([email protected]) (contact
         [email protected] if you have questions)
Date: 2 Sep 88 12:05:57 GMT
From: att!chinet!mcdchg!clyde!watmath!julian!uwovax!brent@ucbvax.Berkeley.EDU
Subject: DECsystem-10 Wake - A Summary
Message-Id: <[email protected]>
Sender: [email protected]
To: [email protected]
ReSent-date: Tue 6 Sep 88 10:12:28-EDT
ReSent-from: Betsy Ramsey <[email protected]>
ReSent-to: [email protected]


               DECsystem-10 Wake - A Summary
               =============================

  In memory of our life and strife with 36 bits, our site
held a wake/celebration on August 31.  Invitations were
sent far and wide, although no one came from further than
Toronto (200 km).  Local staff managed to locate various
memorabelia for the event, including an RP02 disk, paper
tape, DECtapes, and PDP-10 manuals in various flavours.
One attendee provided a real DECsystem-10 name bar from
the top of a 1090.  Black armbands were worn and a registry
was available to be signed.  Wake cake and coffee was served.

  To help with atmosphere, recorded music was provided:
       "Requiem in d-moll, KV 626" by Wolfgang Amadeus Mozart
               followed by
       "Symphonie 2 'Resurrection'" by Gustav Mahler

  Those who wished had their picture taken with the processor
coffin, on which the 1964-1985 "Nobody did it Better" poster
was prominently displayed.  The sailboat poster "Chart your
course with Digital's Large Systems" was prominently posted
(upright to begin, upside-down later).

  Perhaps 50 people attended.  A suitable tribute to a very
fine system.  b.

       "Dies irae, Dies illa
       Solvet DEC-10 in favilla
       Teste Bobby cum Monilla."

       "Quantus VAXen est futurus,
       Quando DCL est venturus,
       Cuncta stricte discussurus!"

  PS: Throughout our "migration, we used a logo which may be
"borrowed", consisting of a clock (circle), 10 o'clock marked
as "10", and 12 o'clock marked as "VAX".  (Reverse block letters
below the hands indicate that this is a  d i g i t a l clock.)
The hands of the clock face indicate the time is "10 to VAX".

  I'll mail a master of the logo to any interested parties if you
drop me a line indicting your snail-mail address.  (Coming from
Canada with a pseudo strike may take a while, however.)  BTW,
the time at our site is now "10 past VAX - do you know where your
files are?"

--
Brent Sterner
Technical Support Manager, Academic Systems
Network    <[email protected]>
Telephone  (519)661-2151 x6036
Last Gasp  Computing & Communications Services, Natural Sciences Building
          The University of Western Ontario, London, Ontario, Canada  N6A 5B7

-------
7-Sep-88 15:42:48-PDT,1943;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Wed 7 Sep 88 15:38:11-PDT
Date: Wed, 7 Sep 1988  16:37 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: NOT.NOT fix!

Back around the middle of December, we were getting plagued with stuck
NOT.NOT connections with "partial packet received" conditions, and
NETSRV causing the load to go through the roof.  The quick fix was to
remove NETSRV from putting itself in Queue 0 so that garbage
collection could run and flush those stuck NOT.NOTs.

Unfortunately, garbage collections didn't occur often enough.  So, I
fished through the code and found that by setting INTSVR to some
non-zero value via MDDT, I could release those NOT.NOTs.  Doing that
once or twice a day seemed to keep the lines open.  (I also noticed
that when I did this while coming in through a TAC, the response
noticably improved.)

Now, what's strange is that all these NOT.NOTs were residual FTPSRT
jobs.  Last week, I started playing with FTPSRT, ignoring the caveat
that you can't use the BIGBUF option with DEC monitors, only BBN
versions.  Nothing changed - you still can't use the BIGBUF option.
However, I decided to recompile and relink a new version of FTPSRT
(which I hadn't done since well before we moved to 6.1), and put up
that version.  Stranger things have happened in the life of this
machine, and I've waited almost a week to make sure before sending
this message, but we've had not one stuck NOT.NOT since putting up
that recompiled and relinked FTPSRT!

Bottom line: if you haven't rebuilt your network utilities, such as
FTPSRT/FTPSER, FTP, WHOIS, FINGER, SMTJFN, NETSRV, MMAILR, etc., since
moving to 6.1, do so.  You can't loose, and may even gain, as I just
did.

--Frank
8-Sep-88 19:53:54-PDT,2478;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 8 Sep 88 19:50:58-PDT
Date: Thu 8 Sep 88 22:51:39-EDT
From: Rob Austein <[email protected]>
Subject: [Pandora B. Berman: The end of the world as we used to know it]
To: [email protected]
Message-ID: <[email protected]>

Date: Thu,  8 Sep 88 21:39:25 EDT
From: "Pandora B. Berman" <[email protected]>
Subject: The end of the world as we used to know it

"The time has come," said LCS,
   "MX at last must go.
Its day has gone.  We need that space
   Most urgently."  And so
Before we crate it, let us give
   A final cheerio.

Once there was a KL-10 called MIT-MC which belonged to the Macsyma
Consortium.  It provided Macsyma, the symbolic algebra system, to
researchers all over the world, and mail gatewaying and mailing list
support to a large fraction of the Arpanet.  Things continued in this
fashion from 1975 to 1983.

When the Macsyma Consortium dissolved in 1983, MC turned to providing
cycles for MIT's Laboratory for Computer Science, and continued supporting
much of the Arpanet's mail service.  But the machine itself was growing old
and cranky.  In 1986, the mail services were moved to a smaller, more
maintainable machine (a KS-10), and the name "MC" was moved with them.
But the KL-10 continued to run under the new name "MX".

Now the end has come.  MX was down cold for several months, and has only
been revived recently to copy some old 7-track tapes.  LCS can't keep MX
any longer -- it needs the space for other purposes.  So the KL is being
sent to the Home for Aged But Beloved PDP-10s; a crack team of hardware
hackers will arrive next week to dismantle it and take it back with them to
Sweden.

In celebration of this momentous event, we are holding a small farewell
gathering:
                        Friday, 16 September 1988
                                  16:00
                         NE43-8th floor playroom
                 (545 Technology Square, Cambridge, MA)

Reservations are strenuously requested (though not strictly necessary) --
we need a head count so we can figure out how many trays of institutional
brownies to order.  Send yours to:
                           [email protected]

Offers of refreshement are also very welcome -- do you think we have any
budget for this kind of thing?  Send all such offers also to CENT as above.

-------
9-Sep-88 07:56:34-PDT,630;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Fri 9 Sep 88 07:52:16-PDT
Date: 9 Sep 1988 1052-EDT
From: [email protected]
To: [email protected]
Subject: Anybody know of a working copy of BSYS on TOPS-20?
Message-ID: <"MS11(6041)+GLXLIB6(0)" 12429195874.83.428.56920 at TOPS20.DEC.COM>

I got a request from a customer want to read very o-o-o-l-d tapes that
were backed up on a TENEX system using BSYS (something pre-DUMPER).

I would appreciate a pointer to a working copy or to documentation on
the tape format.

thanks
dave
  --------
12-Sep-88 17:30:24-PDT,1080;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 12 Sep 88 17:12:28-PDT
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 12 Sep 88 12:12:44 PDT
Date: Mon, 12 Sep 88 11:31:16 PDT
From: Mark Crispin <[email protected]>
Subject: SPR 20-21691 in the 1 July Software Dispatch
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

I am very suspicious of this patch.  The whole point of the code as
written with the XOR's is to update SPTH with the new status of
FILWB+THAWB+OFNDUD+OFN2XB.  After the ANDX, T2 acquires those four
bits which are different between T2 and SPTH.  The XORM updates SPTH
with the new state.  With the IORM, SPTH ends up with those bits set
if they were set either in T2 or SPTH.

This code is also in 5.1 and its function looks very straightforward
there.

Anyone else have any insights about this?
-------
12-Sep-88 17:32:57-PDT,654;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 12 Sep 88 17:13:03-PDT
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 12 Sep 88 13:27:36 PDT
Date: Mon, 12 Sep 88 12:17:49 PDT
From: Mark Crispin <[email protected]>
Subject: SPR 20-21881
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

I think there should be a NOINT in the patch for 20-21881 in the
success case, to balance the OKINT in ULKOFN.
-------
13-Sep-88 11:38:24-PDT,2547;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 13 Sep 88 11:36:01-PDT
Date: 13 Sep 1988 1435-EDT
From: "David Lomartire" <[email protected]>
To: MRC%[email protected], [email protected]
DTN: 297-5508
Mailstop: MRO1-2/L14
Pole: MRO1-2/KL21
Subject: Re: SPR 20-21691 in the 1 July Software Dispatch
Message-ID: <"MS11(6041)+GLXLIB6(0)" 12430285148.81.209.65477 at TOPS20.DEC.COM>
References: Message from Mark Crispin <[email protected]>
             of 12-Sep-88 2041-EDT
In-reply-to: <[email protected]>

    The intent of the code in this area is to insure that, upon the first
real  open  of  an unrestricted file, the access bits in SPTH are accurate
based on the new opening. Further, this code is called upon the opening of
a long file and it will insure that the page-table-zero (PT0) access  will
match the page-table-table (PTT) access.

    When  this code is executed, it is insured that FILUB is set and that
FILWB  and  THAWB  are  not.  This  is  because  the  OFN  represents   an
unrestricted  file  and  so  only  FILUB  should be present. OFN2XB may be
present in the flags of the OFN and OFNDUD should not  (although,  I  have
just  discovered  a  case in which OFNDUD is incorrectly set; more on this
later) since the file was open for read. So, only  OFN2XB  should  be  set
when this code is entered.

    The code will take the access bits from the real open and set them in
SPTH. An IORM is used so that OFN2XB is not inadvertanly cleared. The XORM
will  clear OFN2XB if it happens to be set and this caused OFJFBD BUGHLTs.
None of the other bits (FILWB, THAWB, OFNDUD) should be in SPTH before the
IORM is done since the file was an unrestricted  one.  However,  the  IORM
will  insure that they appear in SPTH if they appear as part of the "real"
opening.

    But, there is a bug which I happened to find while looking this over.
It  is  possible to have OFNDUD set in SPTH when entering CHKLAC. Thus, it
will remain set in SPTH even  if  the  real  opener  is  not  OF%DUD.  The
solution  is  to  clear OFNDUD in RELOF6 after an OFN is released and only
unrestricted  openers  remain.  Note  that,  if  a  file  is  opened  with
OF%RD+OF%RDU+OF%DUD, OFNDUD will not be set. So, it is  correct  to  clear
OFNDUD in RELOF6.

Hopefully, this clears up any confusion.

                                               David Lomartire
                                               LSBU Software Engineering
                                               TOPS-20 Group
  --------
14-Sep-88 16:32:26-PDT,2892;000000000000
Return-Path: <[email protected]>
Received: from sierra.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Wed 14 Sep 88 16:30:52-PDT
Received: from columbia.edu by sierra.STANFORD.EDU (3.2/4.7); Wed, 14 Sep 88 16:29:05 PDT
Received: from cunixc.cc.columbia.edu by columbia.edu (5.54/1.14)
       id AA18183; Wed, 14 Sep 88 19:30:31 EDT
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA00792; Wed, 14 Sep 88 19:26:44 EDT
Date: Wed, 14 Sep 1988 19:26:43 EDT
From: Melissa Metz <[email protected]>
To: tops-20%[email protected]
Subject: Manuals
Message-Id: <[email protected]>

Our last DEC20 is going away this month, and I have a whole pile of
manuals.  Some are even still in their original shrink-wrap!  Some of
them are pretty old, but I thought that in case ANYONE might want them
I might as well offer.  Of course, I'm not charging for them, though I
might have to ask for shipping if I send out a lot and someone
notices...  See the list below.

                                       --Melissa

               --------------------------------------
RSX-11:
Manager's Implementation Guide

TOPS-10/TOPS-20 or DECSYSTEM-10/DECSYSTEM-20:
User Environment Test Package Procedures/Reference Manual
#2 RSX-20F System Reference Manual
#2 Batch Reference Manual
#3 Hardware Reference Manual -- Volume I: Central Processor
#7 SAIL manuals
#2 DDT Reference Card
KL System Reference Card
USAGE File Specification
Syserr Manual
OPR Commands Reference Card
SPEAR Reference Card

DECSYSTEM-10:
Algol Programmer's Reference Manual
System Reference Card

TOPS-20 or DECSYSTEM-20:
Error Detection, Recovery and Reporting Reference Manual
COBOL Utilities Manual
COBOL Programmer's Reference Manual
Getting Started with Runoff Text Formatting Program
DBMS-20 User's Guide
TOPS-20AN User's Guide
#6 MACRO Assembler Reference Manual
#3 Link Reference Manual
#2 Operator's Guide
#3 Operator's Command Language Reference Manual
User Utilities Guide
DECnet-20 Programmer's Guide and Operations Manual
IBM Emulation/Termination
#3 Monitor Calls Reference Manual -- Version 4
Monitor Calls User's Guide -- Version 4 (?)
Monitor Calls User's Guide -- Version 6 (?)
Fortran Reference Manual
User's Guide -- Version 1
Batch Operator's Guide
Sort User's Guide
Getting Started with Batch (TOPS-20)
Introduction to DECSYSTEM-20 Assembly Language Programming, by Ralph Gorin
Monitor Internals Course Guide
Guide to Measuring Uptime
System Manager's Guide
KL Model B Installation Guide
Update Notice (9/85) for User Utilities Guide
#2 Monitor Calls Quick Reference Guide (6.1)
Commands Reference Manual (Exec v.4)
#2 DDT Reference Card
Commands Reference Card
Monitor Calls Reference Manual (v.3A)
DDT Manual

PDP11:
Introduction to DECnet
Macro-11 Language Reference Manual

14-Sep-88 18:28:40-PDT,1157;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 14 Sep 88 18:27:19-PDT
Date: Wed, 14 Sep 88 18:23:16 PDT
From: Mark Crispin <[email protected]>
Subject: 2020 and TU78
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Hi -

    The question came up here (SUMEX) about whether or not a 2020 could
drive a TU78.  As I understand it, you couldn't put an RP07 on a 2020
because the RP07 was too fast for the RH11.  However, I never heard any
definite word about the TU78.  Even though the TU78 transport itself is
capable of fast transfers (faster than the RP07, isn't it?) the question
is can the RH11 talk to a TM78.

    Of course, I know that 2020's can talk to TU77/TM03's.

    If it is merely a small matter of programming (e.g. building a monitor
with PHYM78) this may keep electrons flowing to a 2020 system here as the
machine to read our large library of Tenex/TOPS-20 archive tapes.

-- Mark --
-------
15-Sep-88 14:04:21-PDT,2396;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Sep 88 14:02:37-PDT
Date: Thu, 15 Sep 1988  16:58 EDT
Message-ID: <[email protected]>
Sender: [email protected]
From: Rob Austein <[email protected]>
To:   [email protected]
cc: [email protected]
Subject: Chives version 1.0 now available
Reply-To: [email protected]

After most of a year of beta-testing and further development, version
1.0 of the Chives system is now available.  Chives is an
implementation of the Domain Name System protcols for TOPS-20 (and
other systems), and supports/is supported by the MM/MMAILR mail system
distributed by Mark Crispin.

Small bugfixes and improvements are generally merged into the existing
sources without a lot of fanfare, so the current sources should be
viewed as a snapshot rather than as something carved in stone.

The reason we are doing a full-blown release at this point is that as
of a few weeks ago:
(1) All of the known outstanding bugs had been fixed,
(2) A lot of low-level code had changed since the last update to the
    distribution sources, and
(3) The general design of RESOLV and GTDOM% had been proven to be
    stable and reliable over a period of an entire year's use on XX
    and a few other machines.

Some highlights of the new release:

- A memory manager to eliminate the fragmentation problems that Chives
 used to suffer from.
- A garbage collector to reclaim space occupied by RRs with expired
 TTLs.
- More/better telemetry, lots of little bugfixes.
- Support for negative caching.
- Better support for multi-homed hosts.
- Convergence of the version of KCC used to compile Chives with the
 version of KCC maintained by SRI.
- Support for TOPS-20 7.0.  I believe that DEC intends to distribute
 the necessary monitor hooks to support GTDOM% on an upcoming
 autopatch tape, contact [email protected] if you care about
 this.

There are undoubtably other fixes/improvements that I've forgotten
about, it's been a long time since the last source distribution.

Chives is available via ANONYMOUS FTP from XX.LCS.MIT.EDU.  You want
the directory XX:<CHIVES> and the directory tree XX:<CHIVES.V1*>.

Please send queries, bug reports, et cetera, to
[email protected] rather than to me directly.

--Rob
15-Sep-88 14:59:04-PDT,1940;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Sep 88 14:57:56-PDT
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Thu, 15 Sep 88 14:53:04 PDT
Date: Thu, 15 Sep 88 11:32:34 PDT
From: Mark Crispin <[email protected]>
Subject: XJRST for 2020's
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

Some user-mode software is starting to appear which uses the XJRST
instruction.  In particular, user-mode versions of monitor code (e.g.
GTDOM%) which lives in the skyseg (section 6) is likely to use the
XNENT/XRENT etc. macros which will generate an XJRST to fly from
section 1 to section 6 if you use a 6.x or 7.0 PROLOG.

Rather than fight, I elected to switch.  Implementing XJRST in the
KS10 microcode adds one microinstruction.  If you have ucode sources
for your KS (you lucky devil), you can add XJRST to as follows:


;COMPARISON OF MRC:<KS10>SIMPLE.MIC.2 AND MRC:<KS10>SIMPLE.MIC.3
;OPTIONS ARE    /3

**** FILE MRC:<KS10>SIMPLE.MIC.2, 38-31 (30268)
1535:   UUO                     ;(15)
**** FILE MRC:<KS10>SIMPLE.MIC.3, 38-31 (30268)
1535:   VMA_[AR], START READ,   ;(15) XJRST
       J/XJRST
***************

**** FILE MRC:<KS10>SIMPLE.MIC.2, 41-11 (31862)
**** FILE MRC:<KS10>SIMPLE.MIC.3, 41-11 (31894)
XJRST:  MEM READ, [PC]_MEM,     ;PUT DATA IN PC
       HOLD LEFT,              ;IGNORE SECTION NUMBER
       J/PIEXIT                ;JOIN XJRSTF CASE
***************

I added the XJRST routine just in front of the XJRSTF routine.

To remind you what XJRST FOO is, it's like JRST @FOO except that
the former case merely sets the PC to the contents of FOO while
the latter case sets the PC to the results of an effective address
calculation done on the contents of FOO (hence indexing and
indirection are possible).
-------
15-Sep-88 20:50:33-PDT,750;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Sep 88 20:49:10-PDT
Date: Thu, 15 Sep 1988  21:29 EDT
Message-ID: <[email protected]>
From: [email protected]
To:   [email protected], [email protected]
Subject: Got an extra KS10?


Hi there.

We're looking for a cheap, working KS10. You know, 0 <= x <= $500ish.
Good home, friends to play with, etc. Northeast US preferred, but
don't let that stop you. Oh, if you're one of those strange people who
once field-stripped a KS and stuffed the parts into a corner of the
basement, but you can't quite remember why anymore, we'd like to talk
to you, too. Thank you for your support...

               -john
18-Sep-88 13:28:07-PDT,951;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 18 Sep 88 13:23:39-PDT
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 17 Sep 88 22:25:25 PDT
Date: Sat, 17 Sep 88 21:19:28 PDT
From: Mark Crispin <[email protected]>
Subject: UMOVE/UMOVEM instructions
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

On the KS, building a monitor with the UMOVEx macros replaced with
the machine instructions (which are in all KS's) saves 2 pages of
non-resident code space.  It should also be faster, since the macro
simply generates XCTU [MOVEx ac,user] which has to do an additional
memory fetch plus the cost of executing the XCT -- perhaps 3 usecs
or so.

Is the KL ucode still too full to add these?
-------
20-Sep-88 11:54:05-PDT,829;000000000000
Return-Path: <[email protected]>
Received: from emx.utexas.edu by SCORE.STANFORD.EDU with TCP; Tue 20 Sep 88 11:47:22-PDT
Date: Tue, 20 Sep 88 13:48:31 CDT
From: [email protected] (Donald E. Blais)
Posted-Date: Tue, 20 Sep 88 13:48:31 CDT
Message-Id: <[email protected]>
Received: by emx.utexas.edu (5.54/5.51)
       id AA04980; Tue, 20 Sep 88 13:48:31 CDT
To: [email protected]
Cc: [email protected]
In-Reply-To: Rob Austein's message of Thu, 15 Sep 1988  16:58 EDT <[email protected]>
Subject: Chives version 1.0 now available

Host R20.UTEXAS.EDU is no longer in service.  Please take my name
off the Info-Chives distribution if I am on it.  You may also want
to check for other people at R20.

-- Donald Blais               [email protected]
21-Sep-88 07:00:50-PDT,2395;000000000000
Return-Path: <[email protected]>
Received: from VAX01.AMS.COM by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 06:57:59-PDT
Return-Path: <@SEED.AMS.COM,@MATH.AMS.COM,@GIZMO.SRI.COM:[email protected]>
Received: from SEED.AMS.COM by VAX01.AMS.COM via SMTP with TCP; Wed,
         21 Sep 88 08:51:20-EDT
Received: from MATH.AMS.COM by SEED.AMS.COM with TCP; Wed 21 Sep 88
         08:52:25-EDT
Received: from GIZMO.SRI.COM by MATH.AMS.COM with TCP; Wed 21 Sep 88
         08:50:09-EDT
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Tue,
         20 SEP 88 22:00:07 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Tue,
         20 Sep 88 21:44:01 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31) id AA17142; Tue,
         20 Sep 88 09:55:58 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews for
         [email protected] ([email protected]) (contact
         [email protected] if you have questions)
Date: 20 Sep 88 14:11:32 GMT
From: [email protected] (Edward J. Ede)
Organization: The MITRE Corporation, Bedford, Mass.
Subject: Re: Wanted: MTREK/GALAXY/VAXTREK (a similar request)
Message-Id: <[email protected]>
References: <[email protected]>
Sender: [email protected]
To: [email protected]
ReSent-date: Wed 21 Sep 88 09:34:25-EDT
ReSent-from: Betsy Ramsey <[email protected]>
ReSent-to: [email protected]

In article <[email protected]> [email protected] () writes:
>A few years ago I enjoyed playing a game called MTREK or GALAXY
>on VMS.  It was a really great, multi-player star-wars type game.
>Up to 8 players could control their own ship and fire phasers,
>torpedoes, and seekers at the other players.

Speaking of multi-player trek games, does anyone remember VTTREK for
Tops-20.  Its neatest features were the use of VT100 Advanced Video
Option graphics for the "viewport", and the ability to use the keypad
to play.

Does anyone know what happened to this game?  Was it ever ported to
VMS?  If not, does anyone have the Tops-20 source?

Just curious, ted

Ted Ede -- [email protected] -- The MITRE Corporation -- Burlington Road
| linus!mbunix!ted -- Bedford MA, 01730 -- Mail Stop B015 -- (617) 271-2524 |
|                   - this line intentionally left blank -                  |
+---------------------------------------------------------------------------+

-------
21-Sep-88 13:13:37-PDT,715;000000000000
Return-Path: <[email protected]>
Received: from bu-it.BU.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 13:11:42-PDT
Received: from BUIT2.BU.EDU by bu-it.BU.EDU (5.58/4.7)
       id AA23402; Wed, 21 Sep 88 16:11:04 EDT
Return-Path:  <[email protected]>
Received:  by buit2 (5.58/4.7)
       id AA20036; Wed, 21 Sep 88 16:10:57 EDT
Date:  Wed, 21 Sep 88 16:10:57 EDT
From: [email protected]
Message-Id:  <8809212010.AA20036@buit2>
To: [email protected], [email protected]
Subject: Re: Wanted: MTREK/GALAXY/VAXTREK (a similar request)
Cc: [email protected]

Re: VTTREK.MAC

I have them; check bu-it (anonymous ftp), dir "bucs20", its in
games.tar.Z (a compressed tar archive)

       -Phil Budne
21-Sep-88 18:45:15-PDT,1244;000000000000
Return-Path: <[email protected]>
Received: from jessica.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 18:43:09-PDT
Received: by jessica.Stanford.EDU; Wed, 21 Sep 88 18:41:40 PDT
Date: 21 Sep 1988 1841-PDT (Wednesday)
From: Philip Almquist <[email protected]>
To: Clive Dawson <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Monitor Symbol Table Problems
In-Reply-To: Clive Dawson <[email protected]> / Fri 2 Sep 88 07:56:02-CDT.
            <[email protected]>

Clive,
       It took me a while to find my old TOPS-20 notes, but I may have
a hint as to your trashed symbols problem.  I had a similar problem in
the field test 5.1 monitor.

       In 5.1 (and presumably in 5.4 as well), the symbol table starts
its life on top of tne RSVAR PSECT.  During system startup the symbol
table gets copied elsewhere, but if RSVAR variables are used early in
in the initialization code you get exactly the symptoms you saw: a trashed
symbol which, if you are unlucky, is one of the ones Sysdpy expects to
find.

       The fix is to figure out which RSVAR variable(s) need to get moved
to RSDAT (in 5.1 they were CASHF and CONOPG).

                                                       Philip
21-Sep-88 19:21:26-PDT,702;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Wed 21 Sep 88 19:19:58-PDT
Date: Wed 21 Sep 88 21:18:43-CDT
From: Clive Dawson <[email protected]>
Subject: Monitor Symbol Table problems
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>

Charlie and Philip--

Regarding the tip you both gave me on my monitor symbol table problem,
where the value of NUFKS was getting trashed, I checked the address of
the CASHF word in my monitor, and it corresponded exactly with the
spot where the value of NUFKS was stored in the virgin symbol table!

Many thanks!!

Clive
-------
22-Sep-88 07:50:27-PDT,676;000000000000
Return-Path: <[email protected]>
Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Thu 22 Sep 88 07:47:20-PDT
Date: Thu 22 Sep 88 10:47:01-EDT
From: Donna Lynch <[email protected]>
Subject: IMPINC
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>

Yes, we are still running 5.4.  I thought we were going to get rid of
this machine, so I have not upgraded.

Anyway, I am getting tons of "BUGINF IMPINC" from 10.4.0.15
(arpa-gw.cc.rochester.edu).  Are they doing something they shouldn't be
doing?  Am I doing something I shouldn't be doing?

Can you help?

--Donna
-------
22-Sep-88 09:56:50-PDT,491;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Thu 22 Sep 88 09:54:11-PDT
Date: Thu 22 Sep 88 11:41:01-CDT
From: Clive Dawson <[email protected]>
Subject: Re: IMPINC
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

I got tired of IMPINC's long ago and disabled them by inserting
a RET at IMPEC9 (module IMPDV).

Clive
-------
22-Sep-88 11:01:26-PDT,1336;000000000000
Return-Path: <[email protected]>
Received: from clash.cisco.com by SCORE.STANFORD.EDU with TCP; Thu 22 Sep 88 10:58:00-PDT
Received: from clash.cisco.com by clash.cisco.com with TCP; Thu, 22 Sep 88 10:53:47 PDT
To: Donna Lynch <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: IMPINC
In-Reply-To: Your message of Thu, 22 Sep 88 10:47:01 -0400.
            <[email protected]>
Date: Thu, 22 Sep 88 10:53:44 PDT
From: [email protected]

10.4.0.15 is a cisco gateway running DDN X.25. What is interesting is that
a Sun behind that gateway is sending IP packets with something other then
the default type of service (TOS) field. The cisco X.25 implementation will
open new virtual circuits depending on the type of service field indicated.
If I remember the explaination I got from BBN correctly, only the top two
bits of precedence is carried across from DDN X.25 to 1822. I am not sure
what ramifications this has on the incoming 1822 leader but I suspect
something is different then normal and the -20 is not prepared for it.

The NYSERNET people will hopefully be running new software this evening
which will prevent the opening of new virtual circuits based on the IP
precedence field. Your problem may go away then.

Greg Satz
cisco

26-Sep-88 11:37:10-PDT,872;000000000000
Return-Path: <[email protected]>
Received: from VAX02.AMS.COM by SCORE.STANFORD.EDU with TCP; Mon 26 Sep 88 11:33:47-PDT
Date: Mon 26 Sep 88 14:34:29-EDT
From: Betsy Ramsey <[email protected]>
Subject: PSI-20
To: [email protected]
Message-ID: <[email protected]>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(132)+PONY(205)@VAX02.AMS.COM>

Is anyone out there running PSI-20?  Ziff-Davis Technical Information
has inherited a DEC-20, and they'd like to hear from some sites that are
using PSI.  If you can help them, please contact

               Cliff Hafen
               Ziff-Davis Technical Information
               Boston, MA
               617-273-5500

If you'd rather, you can reply to me, and I'll have Cliff give you a
call.  (He's not on a network.)  Thanks.

Betsy Ramsey                            [email protected]
American Mathematical Society           Phone: 401-272-9500
Providence, RI
-------
27-Sep-88 01:26:45-PDT,1167;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Tue 27 Sep 88 01:24:55-PDT
Date: Tue, 27 Sep 88 01:25:25 PDT
From: Mark Lottor <[email protected]>
Subject: NFS-20 Version 1
To: [email protected]
Message-ID: <[email protected]>

I'm now releasing NFS-20 version 1.  The code isn't as clean as I'd like
it to be, and it hasn't been tested as much as I hoped too, and there
are still some things I'd like to add someday, but since I don't know
when I'm ever going to get around to it I though I'd better get a
version out now.

This version adds lots of changes made by Lon Willet, whom I haven't
been able to contact in a long time.  He took the original release
and made it more useable as a real NFS server.  It handles filename
munging better, handles version numbering better, handles undeleting
and expunging, and lots of other gross unix workarounds.  It still
doesn't handle unix userid to tops-20 userid mapping.

The documentation notes briefly describe how to use it.
To get your copy, just anonymous FTP the whole directory.
SRI-NIC.ARPA::  PS:<MKL.NFS.V1>
-------
3-Oct-88 10:32:09-PDT,1124;000000000000
Return-Path: <@SUMEX-AIM.Stanford.EDU:[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 3 Oct 88 10:29:33-PDT
Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 3 Oct 88 10:10:39 PDT
Date: Mon, 3 Oct 88 10:09:44 PDT
From: Mark Crispin <[email protected]>
Subject: another member of an endangered species dies...
To: [email protected]
Postal-Address: 1802 Hackett Ave.; Mountain View, CA  94043-4431
Phone: +1 (415) 968-1052
Message-ID: <[email protected]>

    This is likely to be the last message sent from PANDA.PANDA.COM,
my "in-house" 2020, for a long time.  Shortly after the next Cafard
run, PANDA will be shut down and its plug will be pulled, in preparation
for it to be moved into storage.

    There is a chance that like the proverbial phoenix PANDA will rise
again from the dead, assuming that I manage to get another house.  But
for now, a moment of silence for a very special DEC-20...

-- Mark --

PS: My primary net address will be [email protected] until further
notice.
-------
10-Oct-88 20:22:51-PDT,766;000000000000
Mail-From: G.CLIVE created at 10-Oct-88 17:14:24
Date: Mon 10 Oct 88 17:14:24-PDT
From: Clive Dawson <[email protected]>
Subject: INTFR1 BUGHLT
To: [email protected]
Reply-To: [email protected]
Message-ID: <[email protected]>

We had an INTFR1 BUGHLT today, months after I hoped I'd never
seen one of those again...An examination of the crash dump
reveals that the same IP buffer was returned to free space
twice in quick succession.  First, by the Internet fork (INTRBF
routine in IPIPIP), and then by the user job doing an ABORT
which eventually ends up in ABTCOA (TCPTCP).

Has anybody seen anything like this?  I wonder if there might
be a race condition involving the PINTL flag?

Tnx,

Clive
-------
10-Oct-88 20:39:20-PDT,635;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Mon 10 Oct 88 11:36:40-PDT
Date: 10 Oct 1988 1438-EDT
From: "Rocket J. Squirrel" <[email protected]>
To: [email protected]
Loc/MS: "MRO1-2/L14 (Pole KL21)"
Phone: "DTN 297-2346 (508-467-2346)"
Subject: SEAL
Message-ID: <"MS11(6044)+GLXLIB6(0)" 12437363498.92.61.184934 at TOPS20.DEC.COM>

From what I understand, SEAL has been released into the public
domain. Does anyone know where the homebase of the source and
documentation files exist?

Thanks,
Mike Raspuzzi
DEC TOPS-20 Monitor Group
  --------
11-Oct-88 14:29:16-PDT,880;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 11 Oct 88 14:26:41-PDT
Date: Tue, 11 Oct 88 14:22:38 PDT
From: Andrew Sweer <[email protected]>
Subject: Re: INTFR1 BUGHLT
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

Clive,
       I still see INTFR1s approximately once/month. Of the last 4, 3 were
MMAILR forks in .ABORT, and 1 was when I restarted NETSRV. Alas, we are
migrating to that other operating system at the end of this month, so
I have no real plans or expectations for exterminating this bug, at least
at our site. If there is anything I can do to help your hunt, like sending
a crash dump for comparison, I'd be more than happy to oblige.

Andy
-------
12-Oct-88 13:16:12-PDT,625;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 12 Oct 88 13:16:10-PDT
Date: Wed 12 Oct 88 13:16:00-PDT
From: Eric M. Berg <[email protected]>
Subject: Load on LOTS
To: [email protected]
Organization: Price Waterhouse Technology Centre, Menlo Park, CA
Phone-#s: 415/322-0606 (PWTC), 415/329-9940 (home)
Message-ID: <[email protected]>

Portia[1]: uptime
 1:06pm  up 4 days,  2:36,  62 users,  load average: 65.41, 62.07, 58.42

It's enough to make one nostalgic for the bad old days...
-------
13-Oct-88 17:50:13-PDT,829;000000000000
Return-Path: <[email protected]>
Received: from OSU-20.IRCC.OHIO-STATE.EDU by SCORE.STANFORD.EDU with TCP; Thu 13 Oct 88 17:47:24-PDT
Date: Thu 13 Oct 88 19:54:52-EDT
From: Lum Johnson <[email protected]>
Subject: Is anyone out there supporting the Bliss portion of PCL now?
To: [email protected]

If anyone is willing to accept it, I have a bug report for the PCL compiler.
Complex PARSE statements specifying additional types to try after a FIELD type
seem to be incorrectly assembled.  I have a short demonstration command and
detailed observations for anyone who wishes to request them.  If so, thanks.
--
Lum Johnson    [email protected]    [email protected]
"You got it kid -- the large print giveth and the small print taketh away."
-------
17-Oct-88 04:31:23-PDT,1388;000000000000
Return-Path: <076RONAN%[email protected]>
Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 17 Oct 88 04:26:22-PDT
Received: by Forsythe.Stanford.EDU; Mon, 17 Oct 88 04:30:33 PDT
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 1161; Mon,
17 Oct 88 12:22:22 BST
Received:
Via:           UK.AC.LIVPOL.SPOOL; 17 OCT 88 12:22:18 BST
Date:          17-OCT-1988 12:22:03
From:          076RONAN%[email protected]
To:            [email protected]
Subject:       Bypassing LEOT on tapes.
Sender:        JANET "[email protected]" <076RONAN%[email protected]
              >
Originally-to: EARN%"[email protected]",076RONAN
Mailer:        Janet_Mailshr V3.1 (19-Aug-1988)
Name:          Ronan P. Flood, Senior Analyst/Programmer (systems)
Address:       Liverpool Polytechnic, Computer Services Department,
              Byrom Street, Liverpool, L3 3AF, U.K
Telephone:     (051) 207-3581 extension 2101

       Given that I "know" there is a DUMPER save-set on a tape beyond
the logical EOT, (some of you may remember my previous message concerning
DUMPER), how can I get to read it? DUMPER will obey the LEOT mark and not
read any further.
       Is there any way I can get past the LEOT and read what's on the
tape there?

Ronan.
17-Oct-88 17:07:56-PDT,1079;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Mon 17 Oct 88 17:06:02-PDT
Date: Mon 17 Oct 88 10:16:16-MDT
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Re: Bypassing LEOT on tapes.
To: 076RONAN%[email protected],
   [email protected]
cc: [email protected]
In-Reply-To: Message from "076RONAN%[email protected]" of Mon 17 Oct 88 12:22:03-MDT
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

An EOT is just two adjacent tapemarks; that is, it looks
just like an empty file.  When you have read an EOT, the
read head is positioned between the two tapemarks.  You can
usually just do a SKIP dev: 1 file to move over the second,
then CONTINUE DUMPER to carry on reading the tape.  The one
caveat is that you can run the tape off the reel if you do
this at the real EOT.
-------
18-Oct-88 11:49:04-PDT,837;000000000000
Return-Path: <[email protected]>
Received: from SUMEX-AIM.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 18 Oct 88 11:46:31-PDT
Date: Tue, 18 Oct 88 11:44:37 PDT
From: Mark Crispin <[email protected]>
Subject: fiche?
To: [email protected]
Postal-Address: P.O. Box 2652; Seattle, WA  98111-2652 USA
Message-ID: <[email protected]>

    A long while ago, DEC listed TOPS-20 source fiche as being
available for purchase, and my LCG catalog even gives an order
number.  However, the DEC Electronic Store has no listing for
those products.

    The fiche I have is for vanilla DEC 5.4; with 7.0 out I
would like an updated fiche set.  It's a non-trivial amount of
effort to make fiche; I'd prefer to buy a pre-made set if
possible...

-- Mark --
-------
20-Oct-88 10:13:25-PDT,977;000000000000
Return-Path: <[email protected]>
Received: from rcca.bbn.com by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 10:10:38-PDT
Date: Thu, 20 Oct 88 13:07
From: Regis McEwen <[email protected]>
Subject: VMS DUMPER program
To: [email protected], [email protected]


       I'm looking for information on a VMS DUMPER program that reads
       TOPS-20 DUMPER tapes and recreates them on VMS.  I have DUMPER
       version 1.1 written by the Stevens Institute of Technology,
       however I was wondering if there is a more up-to-date version
       of the program (this version was written in BLISS around the
       25th of September in 1986.).

       This version doesn't handle some record-type files on the tape
       graciously and bombs out unceremoniously.  SELECTing each file
       is not viable option as to the multitude of files.  EXCLUDing
       of files or file-types is not available.

       Any other implentations would be helpful.

       Thanks to all who respond.

                                                               -Regis

20-Oct-88 11:18:02-PDT,686;000000000000
Return-Path: <[email protected]>
Received: from SPAR-20.SPAR.SLB.COM by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 11:16:54-PDT
Date: Thu 20 Oct 88 11:18:36-PDT
From: Doug Faunt <[email protected]>
Subject: re:  VMS DUMPER program
To: [email protected]
Message-ID: <[email protected]>

Speaking of DUMPER tapes on other machines, is there a DUMPER reader
for UNIX systems?
Schlumberger is moving this lab to Austin Texas, and SPAR-20 is not
going, but will be shut down for good.

Also, is the '20 history project still going on?  A pointer to it, if
it's still happening would be appreciated.

               Thanks,
-------
20-Oct-88 12:23:41-PDT,565;000000000000
Return-Path: <[email protected]>
Received: from SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 12:22:36-PDT
Date: Thu, 20 Oct 1988  13:16 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   Doug Faunt <[email protected]>
Cc:   [email protected], [email protected]
Subject: Unix DUMPER reader
In-reply-to: Msg of 20 Oct 1988  12:18-MDT from Doug Faunt <FAUNT at SPAR-20.SPAR.SLB.COM>

Doug,

See PD2:<UNIX-C.TAPES>READ20.SHAR.

--Frank
20-Oct-88 13:36:14-PDT,623;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Thu 20 Oct 88 13:35:04-PDT
Date: 20 Oct 1988 1635-EDT
From: "Joe Dempster, DTN 336.2023, AT&T 609.273.2023" <[email protected]>
To: [email protected]
cc: [email protected]
Subject: TOPS history project.
Message-ID: <"MS11(6044)+GLXLIB6(0)" 12440006250.71.30.6242 at TOPS20.DEC.COM>

Things are progressing well, but a little slow.  Les Earnest and I have
identified some 25+ odd chapters and have contributors lined up for most
of them.  Do you have a contribution?

/joe
  --------
24-Oct-88 07:44:16-PDT,960;000000000000
Return-Path: <I_MCDONALD%[email protected]>
Received: from forsythe.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 24 Oct 88 07:41:43-PDT
Received: by Forsythe.Stanford.EDU; Mon, 24 Oct 88 07:43:48 PDT
Received: from RL.IB by UKACRL.BITNET (Mailer X1.25) with BSMTP id 2056; Mon,
24 Oct 88 14:37:07 GMT
Received: from RL.IB by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2682; Mon, 24
         Oct 88 14:37:06 GM
Via:      UK.AC.OU.ACSVAX
Date:     24-OCT-1988 14:34:20 GMT
From:     I_MCDONALD%[email protected]
To:       [email protected]
Subject:  Farewell

       It is with regret that I announce the demise 2 weeks prematurely
       of the surviving Open University Dec-20 triplet on 14-Oct-1988.

       The cause was certified to be "convulsions due to respiratory
       circulation failure".

       Regards and farewell,
                               Ian McD

       PS: It died through lack of a fan not through lack of FANS....

27-Oct-88 08:35:27-PDT,603;000000000000
Return-Path: <[email protected]>
Received: from RADC-TOPS20.ARPA by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 08:27:39-PDT
Date: Thu 27 Oct 88 08:27:04-EDT
From: Donna Lynch <[email protected]>
Subject: MM
To: [email protected]
Message-ID: <[email protected]>

I have been working on a VAX running VMS.  I am unfamiliar with the
MAIL system there. I hestitate to say hate, I just haven't found its
good points yet.  I thought there used to be an MM for the VAX. If
this is true, can someone point me to where I might get it?

Thanks,
Donna
-------
27-Oct-88 11:06:13-PDT,1423;000000000000
Return-Path: <[email protected]>
Received: from GSB-HOW.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 27 Oct 88 11:01:12-PDT
Date: Thu 27 Oct 88 10:58:48-PDT
From: Eric M. Berg <[email protected]>
Subject: Re: MM
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Organization: Price Waterhouse Technology Centre, Menlo Park, CA
Phone-#s: 415/322-0606 (PWTC), 415/329-9940 (home)
Message-ID: <[email protected]>

There's a version of MM for VAX/VMS called "MM-32" which was done by
David Kashtan at SRI and is distributed alone or as part of the MultiNet+
TCP/IP package for VAX/VMS.  It's now available for purchase from either
SRI (contact [email protected]), Kashtan (contact [email protected]), or
Excelan.

The folks at Columbia have another version of MM which runs on Unix systems
and uses their CCMD library (COMND% jsys in C), but it hasn't been ported to
VMS and I don't know if anyone has plans to do so.  Contact
[email protected] for more information.

At Stanford GSB, we're running MM-32 on our VMS system, and it seems to
work quite reasonably.

                                               Eric Berg
                                               former staff member
                                               Stanford GSB Computer Facility
-------
29-Oct-88 08:27:00-PDT,6713;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SCORE.STANFORD.EDU with TCP; Sat 29 Oct 88 08:24:29-PDT
Date: Sat 29 Oct 88 09:23:42-MDT
From: "Nelson H.F. Beebe" <[email protected]>
Subject: PCL command to loop over file lists
To: [email protected]
cc: [email protected]
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>

Here is a PCL command to loop over lists of files, much like
the Unix csh 'foreach' command.

COMMAND FOREACH (
       NOISE "filename reference token (FOO is used as $FOO in commands)";
       FIELD;
       NOISE "filelist";
       FILELIST (INPUT,
       HELP "give list of files,
followed by commands to work on them (with $FOO representing file name),
followed by ""end"" to terminate the command list",
               DEFAULT_DEV "DSK",
               DEFAULT_NAM "*",
               DEFAULT_EXT "*")
       );
!------------------------------------------------------------------------
! Purpose:
!       Given a  file substitution  name, and  a list  of  files,
!       execute  a  sequence  of  commands.   The  commands   are
!       prompted  for,  and   will  usually   contain  the   file
!       substitution name prefixed by  $; such instances will  be
!       replaced by the full filename.   Letter case in the  file
!       substitution name is not significant.
!
!       The command sequence is ended  by a line containing  only
!       the word  "end"  (letter case  is  insignificant).   This
!       command is inspired by the Unix csh foreach command.   As
!       a  bonus,   several  additional   escape  sequences   are
!       recognized in the  command text, and  substituted for  as
!       follows:
!
!       \1      file device field (e.g. "DSK")
!       \2      file directory field (e.g "MA.561.MA-JONES")
!       \3      file name field (e.g. "MYPROG")
!       \4      file extension field (e.g. "FOR")
!       \5      file generation number field (e.g. "23")
!       \D      current date in the form "dd-mon-yy"
!       \F      the complete filename (same as $FOO)
!       \P      page mark (ASCII formfeed)
!       \R      last read date and time of the current file
!       \T      current time in the form "hh:mm:ss"
!       \W      last write date and time of the current file
!       \\      single backslash
!
!       The   complete   filename   can   be   reconstructed   as
!       "\1:<\2>\3.\4.\5" The case  of the  letter following  the
!       backslash is not significant; \W and \w are equivalent.
!
!       For convenience in  communication with  Unix, file  names
!       are converted to lower-case  in the output; TOPS-20  does
!       not mind.
!
! Examples:
!       @foreach F a*.for
!       cmd>echo $F
!       cmd>copy $F scr:
!       cmd>end
!
!       @foreach F a*.for
!       cmd>echo $F
!       cmd>copy $F scr:b-\3.new
!       cmd>end
!
!       @foreach F a*.for
!       cmd>echo $f -- last read on \r
!       cmd>end
!
! Author:
!       Nelson H.F. Beebe, Department of Physics, University of Utah,
!       Salt Lake City, UT 84112.
!
! Date:
!       [24-Sep-88]
!
!------------------------------------------------------------------------
BEGIN
EXTERNAL STRING PROCEDURE strlower, strsub;
STRING  commands,
       filename,
       filelist,
       keyname,
       line,
       this_command;
INTEGER k;

keyname = "$" + $Atom;

commands = "";

!
! Because we need to use PARSE to read the commands ($READ does not allow
! command-line editing), we save the file list with CR LF separators;
!
filelist = "";
DO
       filelist = filelist + $FILEL + $CRLF
UNTIL $NextFile = 0;

!
! Collect the command lines in a single string with CR LF separators
!
PROMPT "cmd>";
PARSE TEXT;
PARSE EOL;
line = $Atom;
WHILE strlower(line) <> "end" DO
       BEGIN
               commands = commands + line + $CRLF;
               PROMPT "cmd>";
               PARSE TEXT;
               PARSE EOL;
               line = $Atom
       END;
!
! Perform filename-independent escape substitutions outside of
! file loop.
!
commands = strsub(commands,"\D",$Date);
commands = strsub(commands,"\T",$Time);
commands = strsub(commands,"\P",$CVITC(12));
commands = strsub(commands,"\\","\");

!
! Main loop over files.
!

filelist = strlower(filelist);  ! make lower-case for Unix;
DO
BEGIN
       k = $SEARCH(filelist,$CRLF);
       IF k > 0 THEN
       BEGIN
          filename = filelist[1:k-1];
          filelist = filelist[k+2:*];

          this_command = strsub(commands,keyname,filename);
          this_command = strsub(this_command,"\F",filename);
          this_command = strsub(this_command,"\1",
              strlower($File_Dev(filename)));
          this_command = strsub(this_command,"\2",
              strlower($File_Dir(filename)));
          this_command = strsub(this_command,"\3",
              strlower($File_Nam(filename)));
          this_command = strsub(this_command,"\4",
              strlower($File_Typ(filename)));
          this_command = strsub(this_command,"\5",$File_Gen(filename));
          this_command = strsub(this_command,"\R",
              $OutputTaD($FileInfo_I(filename,$FBREF)));
          this_command = strsub(this_command,"\W",
              $OutputTaD($FileInfo_I(filename,$FBWRT)));
          DOCOMMAND this_command
       END
END
UNTIL k = 0;
END; !foreach
!-----------------------------------------------------------------------
! Miscellaneous string procedures:
!       strlower(s)             return lower-case copy of s
!       strupper(s)             return upper-case copy of s
!       strsub(s,old,new)       return copy of s with all substrings old
!                               changed to new
! [25-Sep-88]
!-----------------------------------------------------------------------
STRING PROCEDURE
strlower(STRING s);     ! Return a lower-cased copy of s, leaving s intact;
BEGIN
   STRING scopy;
   INTEGER index;

   scopy = s;
   index = 1;
   WHILE index <= $Length(scopy) DO
   BEGIN
       IF scopy[index:1] >= "A" THEN
       IF scopy[index:1] <= "Z" THEN
           scopy = scopy[1:index-1] + $CvItC($CvCtI(scopy[index:1]) + 32) +
               scopy[index+1:*];
       index = index + 1
   END;
   RETURN scopy
END; !strlower

! Return a copy of s with instances of old replaced by new.  Letter case
! in old is ignored; letter case of new is preserved.
STRING PROCEDURE
strsub(STRING s; STRING old; STRING new);
BEGIN
   STRING scopy;
   INTEGER index;

   scopy = s;
   index = $SEARCHRAISED(scopy,old);
   WHILE index > 0 DO
       BEGIN
           scopy = scopy[1:index-1] + new + scopy[index+$Length(old):*];
           index = $SEARCHRAISED(scopy,old)
       END;
   RETURN scopy
END; !strsub

STRING PROCEDURE
strupper(STRING s);     ! Return an upper-cased copy of s, leaving s intact;
BEGIN
   STRING scopy;
   INTEGER index;

   scopy = s;
   index = 1;
   WHILE index <= $Length(scopy) DO
   BEGIN
       IF scopy[index:1] >= "a" THEN
       IF scopy[index:1] <= "z" THEN
           scopy = scopy[1:index-1] + $CvItC($CvCtI(scopy[index:1]) - 32) +
               scopy[index+1:*];
       index = index + 1
   END;
   RETURN scopy
END; !strupper
-------
1-Nov-88 10:28:37-PST,975;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Tue 1 Nov 88 10:24:51-PST
Date: Tue, 1 Nov 1988  13:23 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To:   [email protected], [email protected]
Subject: Updated domain resolver sources
Reply-To: [email protected]

Anybody using the MIT TOPS-20 domain resolver code (CHIVES) should
consider picking up a new copy from the source directory on XX.  In
the past few weeks we've fixed a few obscure bugs in the search path
code which used to cause "Name does not exist" errors, along with a
few random minor bugfixes.  The search path fixes have been running on
XX for a week or so without apparent problems or any recurrences of
the bugs, but have not been extensively field tested.

As usual, please send any queries/bug reports, etc, to
[email protected], not to me personally.

--Rob
2-Nov-88 08:24:43-PST,1440;000000000000
Return-Path: <[email protected]>
Received: from VAX01.AMS.COM by SCORE.STANFORD.EDU with TCP; Wed 2 Nov 88 08:17:57-PST
Return-Path: <@GIZMO.SRI.COM:[email protected]>
Received: from GIZMO.SRI.COM by VAX01.AMS.COM via SMTP with TCP; Wed,
         2 Nov 88 10:07:01-EDT
Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed,
         2 NOV 88 05:21:12 PDT
Received: from ornl-knsms ([128.219.128.10]) by KL.SRI.COM with TCP;
         Wed, 2 Nov 88 05:15:56 PST
Date: 2 Nov 88 08:14:00 WET DST
From: "M. S. Pung" <pung@ornl-knsms>
Subject: TCP/IP
To: "info-vax" <[email protected]>
cc: pung
ReSent-date: Wed 2 Nov 88 10:27:16-EDT
ReSent-from: Betsy Ramsey <[email protected]>
ReSent-to: [email protected]


Hello,

       This request should probably be directed to another list but this
       topic is discussed heavily on INFO-VAX so I thought I would give
       it a try.

       Does anyone know of any DECsystem-10 TCP/IP implementations ?

       If so, could you expound on the product names and the
       respective companies that offer them ???

       Thanks in advance.

       |------------------------------------------------------------------|
       |          Mike Pung               |       (615) 574-8082          |
       |     Oak Ridge National Lab       | Pung%[email protected] |
       |  Martin Marietta Energy Systems  |        128.219.128.10         |
       |------------------------------------------------------------------|


-------
4-Nov-88 01:26:35-PST,1547;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 01:23:11-PST
Date: Fri 4 Nov 88 04:23:32-EST
From: Clive B. Dawson <[email protected]>
Subject: Network connectivity
To: [email protected], [email protected]
Reply-To: clive%[email protected]
Message-ID: <[email protected]>

MCC.COM (10.3.0.62) has unable to establish connections with a large
percentage of the Internet hosts during the past 24 hours.  I believe
much of this is caused by the fact that a lot of gateways have been
turned off to try and prevent the spread of the Unix virus that's been
going around.  Furthermore it looks like there's a lot of "one-way"
gateways out there.  OUr SMTP listener has had a lot of connections
hanging in SYN.SYN state and timing out, presumably because our SYN's
aren't making it back to the host who is trying to connect to us.

But I really got confused when I discovered that many of the hosts
I couldn't connect to were reachable from other hosts on the 10 net
(e.g. Score and XX).  If anybody can offer one or more explanations for
this, I would very much like to hear about it.  In particular,
what are the possible causes for a host being reachable from 10.a.b.c
but not from 10.x.y.z?  (Note that MCC.COM's "default,preferred"
address IS 10.3.0.62.)  The only explanation I can come up with
is that something is messed up in the PSN routing tables, and that
this is a problem for the NOC.

Thanks,

Clive
-------
4-Nov-88 07:48:54-PST,1431;000000000000
Return-Path: <[email protected]>
Received: from mitre.arpa by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 07:46:34-PST
Full-Name: Steve Goldstein
Message-Id: <[email protected]>
Organization: The MITRE Corp., Washington, D.C.
To: clive%[email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Network connectivity
In-Reply-To: Your message of Fri, 04 Nov 88 04:23:32 -0500.
            <[email protected]>
Date: Fri, 04 Nov 88 09:52:28 EST
From: Steve Goldstein <[email protected]>

Clive,

I have had similar experiences a few weeks ago with a Princeton host on
arpanet and reachable thru nsfnet via jvnc.  The telco line from jvnc to pri
on broke, and there was no way in hell that I could get through to princeton
via my normal methods.  Then, I logged in to a machine in Wisconsin that
happened to be on arpanet and, voila!  there I was getting into the princeton
host!  Seems that the new routes did not age properly on jvnc's EGP-server.
They should have shown the new route to princeton via arpanet, but they did not.

I have no idea in this current swiss cheese Internet whether or not similar
things could be happening, but certainly the gated, EGP and other things that
usually hum must be going bump in the night!

Keep the faith,

Steve Goldstein
normally: [email protected] (which is down!)
4-Nov-88 08:18:23-PST,1354;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 08:15:59-PST
Date: Fri 4 Nov 88 07:47:40-CST
From: Clive Dawson <[email protected]>
Subject: Network Connectivity - Part 2
To: [email protected], [email protected]
Message-ID: <[email protected]>

After sending my previous message in which I wondered what would
cause only some hosts on net 10 to be able to communicate with
a certain other hosts, I began doing some systematic testing
to try and determine what the connectivity was really like.

In the process, I discovered the answer to my own question.  It
turns out that all the prime gateways which my TOPS-20 system
knew about were down!  Some years ago, the NIC assigned certain
MILNET gateways to each Arpanet host.  Up until yesterday,
these gateways have always been sufficient to provide all the
redirect info required.  But since all the Milnet gateways apparently
went down because of this virus, my system had nobody left to
ask.

I've added a couple of other non-Milnet prime gateways to
my INTERNET.GATEWAYS file, and all is well.  I suspect there
may be other TOPS-20 systems out there with the same problem,
since the practice of having only one or two entries in
the gateways file was pretty widespread for a while.

Clive
-------
4-Nov-88 09:44:15-PST,1561;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 09:41:45-PST
Date: Fri 4 Nov 88 12:41:47-EST
From: Rob Austein <[email protected]>
Subject: Re: Network Connectivity - Part 2
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

Clive,

Right.  Here's the rest of the story.  XX and Score are configured
differently than MCC or NIC, because while all four are multi-homed
hosts, XX and Score are not the sole contact points between the nets
to which they are connected.  Eg, XX is connected to nets 10 and 18,
but so is GW.LCS.MIT.EDU.  A multi-homed TOPS-20 in this configuration
needs more entries in its INTERNET.GATEWAYS file than just its IMP's
two assigned "mailbridge" gateways, eg, XX's also lists GW,
KLUDGE.AI.MIT.EDU, SLUDGE.LCS.MIT.EDU, and SEWAGE.MIT.EDU.  Yesterday
XX ended up routing all of its "default" traffic via GW.LCS.MIT.EDU
after it gave up on IMP44's assigned gateways.  I assume something
similar happened to Score.

Is the "eager pinger" problem believed to be fixed?  If I remember
correctly, that's where the practice of having only two live core
gateways known per host came from.  The NIC has a file online (in
NETINFO:, I think) explaining this, but it was never clear to me if
the underlying problem was really fixed or simply toned down to an
acceptable level if everybody stuck to the two gateway rule.

--Rob
-------
4-Nov-88 09:55:59-PST,1360;000000000000
Return-Path: <[email protected]>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 09:53:39-PST
Date: Fri, 4 Nov 1988  10:28 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   Clive Dawson <[email protected]>
Cc:   [email protected], [email protected],
     [email protected]
Subject: Network Connectivity - Part 2
In-reply-to: Msg of 4 Nov 1988  06:47-MST from Clive Dawson <AI.CLIVE at MCC.COM>

Clive,

I discovered the same problem last night caused by the fact that the
prime gateways were down (either deliberately taken down, looped off
the net or powered down by the NOC) in an effort to compartmentalize
the spread of the worm (not virus).  It is not just the TOPS20 hosts
which depend on these gateways for ICMP REDIRECTs - all hosts using
the prime gateways do.  Once I added a couple of other gateways,
everything started flowing again everywhere except across the MIL-ARPA
gateways (as I believe was the intent in shutting off those gateways).

The lesson to be learned from this is that we should have at least one
other non-MIL-ARPA prime gateway in the list of assigned gateways
should it become necessary to isolate those two nets from each other
in the future.

--Frank
4-Nov-88 11:42:04-PST,1574;000000000000
Return-Path: <[email protected]>
Received: from ALEXANDER.BBN.COM by SCORE.STANFORD.EDU with TCP; Fri 4 Nov 88 11:38:48-PST
To: Clive Dawson <[email protected]>
cc: [email protected], [email protected]
Subject: Re: Network Connectivity - Part 2
In-reply-to: Your message of Fri, 04 Nov 88 07:47:40 -0600.
            <[email protected]>
Date: Fri, 04 Nov 88 12:09:39 -0500
From: Frederick E Serr BBNCC 20/666 x2474 <[email protected]>

I would urge TOPS-20 administrators NOT to add more than one or two
other gateways to their gateways file, if any.  The MILNET Mailbridge
Gateways were explicitly turned off yesterday to slow the spread of
the virus.  As you yourself said, their normal reliability is such
that one primary gateway and one backup entry was enough to keep
your host "connected" for several years without running into this
problem.  Presumably, turning off the Mailbridges because of external
circumstances will continue to be a rare event.

The reason for only having one or two entries in the file in the first
place is to reduce the amount of ICMP overhead traffic on Arpanet and
Milnet.  TOPS-20s periodically "ping" all the gateways on their list.
A few years back, this was adding up to a substantial fraction of all
the traffic on the Arpanet.  While one can argue that adding one more
gateway to one host will result in only a small amount of traffic, it
still seems worth avoiding, when the problem one is fixing is so rare.

Fred Serr
Network Analysis Dept.
BBN Communications
5-Nov-88 14:17:04-PST,1708;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Sat 5 Nov 88 14:13:26-PST
Date: Sat 5 Nov 88 16:13:49-CST
From: Clive Dawson <[email protected]>
Subject: Mail problems caused by core gateway outage
To: [email protected]
Message-ID: <[email protected]>

I wanted to mention another effect of the outage of many of the core
gateways on Thursday.  A problem we've been nagged by for a long time
and which most people on this list are familiar with grew many times
worse: attempts to connect to the 20's SMTP server failed due to
"Connection rejected."

It turns out that the SMTP listener (SMTJFN in this case) does an
OPENF to listen for an incoming connection.  As soon as the connection
is established, the OPENF returns and the listener immediately does
another OPENF to keep listening while the first one gets given to
another fork for processing.  In this case, the connection never got
fully established because our SYN's couldn't make it back to the
remote host.  Even though I had previously shortened the timeout
period from 60 to 15 seconds, anybody trying to connect during this
period would get rejected, because another listening port had not
yet been established.  I finally got some relief by firing up about
8 SMTJFN's.

Given that there will always be problem hosts and gateways out there,
I'm wondering if there is a solution to this.  For example, would
it be reasonable to have the OPENF return before the connection is
fully established, so that another listener port could be opened
more quickly?  The waiting time (if any) would then occur during
the first attempt for input.

Clive
-------
6-Nov-88 13:24:23-PST,1140;000000000000
Return-Path: <[email protected]>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Sun 6 Nov 88 13:22:58-PST
Date: Sun, 6 Nov 1988  14:23 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   [email protected]
cc:   [email protected]
Subject: RTS/CTS SPR?

Some time ago I bemoaned the fact that the TTY lines do not honor
out-of-band flow control, a most welcome feature addition in order to
be able to properly use state-of-the-art high-speed modems, stat
muxes, etc.  At that time, I was advised to submit an SPR.  I
procrastinated while other items demanded my attention, hoping that
someone else might have submitted such an SPR.  Has anyone done so?
Is it too late?  If neither, could we band together to submit a joint
SPR?  Send proposed wordings directly to me and I will merge and
submit such an SPR on behalf of all the respondents.  On the other
hand, if someone has submitted an SPR on this subject and it was
rejected, I would like to know the basis for the rejection.

--Frank
14-Nov-88 13:46:18-PST,507;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 13:38:48-PST
Date: Mon, 14 Nov 88 13:40:14 PST
From: Mark Lottor <[email protected]>
Subject: v7 tcp/ip source
To: [email protected]
Message-ID: <[email protected]>

We got our v7 tapes and source a few weeks ago.  One saveset
contains the tcp/ip source in encrypted form.  I can't find the
KEY files to decrypt them with.  Does anyone know where they are?
-------
14-Nov-88 18:18:20-PST,1830;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Mon 14 Nov 88 18:13:23-PST
Date: Mon, 14 Nov 88 17:42:59 PST
From: Mark Lottor <[email protected]>
Subject: faster incrementals
To: [email protected]
Message-ID: <[email protected]>

I made some DUMPER hacks to speed up incremental dumps.  Use them at
your own risk.  The idea of the hack is to only scan directories that
have changes instead of scanning the whole filesystem.  If you have a
structure that doesn't change much, like a source code pack, the whole
incremental dump only takes a few minutes.  On structures where lots
of changes occur daily, the effect will be smaller.

The way the code decides whether something in a directory has changed
or not is by looking at a directory word not available from GTDIR%
(so the code does a GTFDB and 2 DSKOPs to read it; no monitor
changes required).  The word contains the TAD of the last change
to anything in the directory.  It compares that to the time
of the last incremental (saved in a special file) and if nothing
has changed it skips to the next directory, otherwise dumps
the changed one normally.

Some differences to watch out for:
- The new code scans the structure using GTJFN on *.DIRECTORY instead
  of stepping with RCDIR, so things come out in a different order.
- The special files PS:<OPERATOR>FASTINCREMENTAL.structure
- DIRECTORY information is not dumped for all directories
  (we do a DLUSER before each dump so this isn't a problem)
- New dumper command "FAST-INCREMENTAL (of structure) xx:"
- The hack won't begin working until day 2 of using it.

The changes are available via anonymous FTP from SRI-NIC.ARPA
as SRC:<LOC>SUBSYS>DUMPER.MAC, and everything is in a NICSW
marked ";QINC".
-------
15-Nov-88 01:35:29-PST,1007;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SCORE.STANFORD.EDU with TCP; Tue 15 Nov 88 01:30:28-PST
Received: from munnari.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
       id AA11789; Tue, 15 Nov 88 03:06:28 EST
Message-Id: <[email protected]>
Received: from gara.une.oz (via gwydir) by munnari.oz with SunIII (5.5)
       id AA12320; Tue, 15 Nov 88 18:42:41 EST
       (from [email protected] for [email protected])
Received: by gara.une.oz (5.54/5.17)
       id AA19787; Tue, 15 Nov 88 18:41:30 EST
Date: Tue, 15 Nov 88 18:41:30 EST
From: [email protected] (Gordon Smith)
To: [email protected]
Subject: WANTED: VAX utility to read/write DUMPER tapes.

I remember seeing mention of a VAX utility to read/write TOPS-20 DUMPER tapes
a long while ago. Now a friend has need of such a beastie. Any pointers
please.

Thanks.

Gordon Smith, Computer Centre, Uni. of New England, Armidale, Australia 2351.
15-Nov-88 05:39:35-PST,1053;000000000000
Return-Path: <[email protected]>
Received: from TOPS20.DEC.COM by SCORE.STANFORD.EDU with TCP; Tue 15 Nov 88 05:36:08-PST
Date: 15 Nov 1988 0837-EST
From: "David Lomartire" <[email protected]>
To: Mark Lottor <[email protected]>, [email protected]
DTN: 297-5508
Mailstop: MRO1-2/L14
Pole: MRO1-2/KL21
Subject: Re: v7 tcp/ip source
Message-ID: <"MS11(6044)+GLXLIB6(0)" 12446745923.143.209.46840 at TOPS20.DEC.COM>
References: Message from Mark Lottor <[email protected]>
             of 14-Nov-88 1658-EST
In-reply-to: <[email protected]>

    The  keys  for  the  TCP monitor sources are on the TCP Distribution tape.
This tape is part of the QT090 kit. It appears that this kit may not have  been
shipped to every customer with a TCP license. Some of you may remember that the
same  problem occurred with 6.1. Are other customers experiencing this problem?
We are currently investigating this situation.

                                               David Lomartire
                                               LSBU Software Engineering
                                               TOPS-20 Group
  --------
19-Nov-88 21:35:39-PST,2905;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%[email protected]>
Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Sat 19 Nov 88 21:33:39-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 8032; Sun, 20 Nov 88 00:34:47 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Sat, 19 Nov 88 21:29:16 MST
Date:     Sat, 19 Nov 88 21:28:41 MST
From:     rmf%Janus.MRC.AdhocNet.CA%[email protected] (Russ Forster)
Message-Id: <[email protected]>
Subject:  EMACS under TOPS-20 v 7.0
To:       [email protected]

       I'm having a problem moving EMACS from a PS structure to a new
       BS structure.  Once I moved EMACS and redefined the logical
       names,  EMACS would no longer take my login driectories EMACS.INIT
       file.  I tried to rebuild EMACS, but I've come across the errors below.

       I tried to rebuild TWXBTS.MID, but MACCVT.:EJ comes up with an
       error.

       I'm stumped, frustrated, and hopelessly lost.

       Help!

       /Russ


12:35:32 MONTR  @midas
12:35:37 USER   NOTPUR MIDAS.425
12:35:37 USER   **temp_teco/T
12:35:38 USER   TECO
12:35:38 USER   TTY: .INSRTed, end input with ^Z
               ! these switches are only relevant on tops-20's that support mul
tiple structures
12:35:38 USER   *EMCSDV==1
12:35:38 USER   *INFODV==1
12:35:38 USER   *COMNDF==1
12:35:38 USER   *EXITCL==1
12:35:38 USER   *^Z
12:35:38 USER
12:35:39 USER   END OF LOW IMPURE = 4022
               [GTTYP deleted]
12:36:07 USER   TOP OF PURE = 56204
12:36:07 USER   TECO
12:36:20 USER   EJCMD+31        34512    0.   248-034   .FBKEP  Undefined
12:36:22 USER   GTTYP indices for "glass ttys", separated by commas:
               ! Glass tty type codes
12:36:22 USER   *16.
12:36:29 USER   VSCPS+2         50416    1.   336-028   DP%AG1  Undefined in lit
eral
12:36:29 USER   VSCPS+2         50416    1.   336-028   .VTMOV  Undefined in lit
eral
12:36:29 USER   VSSUP+7         50471    1.   336-077   DP%AG1  Undefined in lit
eral
12:36:29 USER   VSSUP+7         50471    1.   336-077   DP%AG2  Undefined in lit
eral
12:36:29 USER   VSSUP+7         50471    1.   336-077   .VTLID  Undefined in lit
eral
12:36:41 USER   Constants area inclusive
12:36:41 USER   From    To
12:36:41 USER   4007    4022
12:36:41 USER   53210   56003
12:36:41 USER   Run time = 45.45
12:36:41 USER   7973 Symbols including initial ones (99% used)
-----
Russell M. Forster, Systems Programmer II.

Mount Royal College        DECnet: RMF @ Janus
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      ICBM:   51 03 N / 114 05 W
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
19-Nov-88 23:35:20-PST,1555;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Sat 19 Nov 88 23:34:22-PST
Date: Sun 20 Nov 88 02:36:14-EST
From: Rob Austein <[email protected]>
Subject: Re: EMACS under TOPS-20 v 7.0
To: rmf%Janus.MRC.AdhocNet.CA%[email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

Russ,

A few things to try:

1) Try rebuilding just EMACS without rebuilding TECO.  If this works
  you have saved yourself trying to figure out what the real problem
  is.

2) Check to make sure you have a consistant version of your sources.
  You should not be seeing references to the symbol .VTLID (a VTSOP%
  opcode) since presumably you are not running the MIT VTS monitor.

3) Try building a new version of MIDAS (with a current TNXDFU.MID,
  generated by running CVTUNV), then comment out the TNXBTS/TWXBTS
  stuff.  MIDAS running on TOPS-20 is supposed to have all the
  MONSYM-ish bits assembled into itself (on ITS MIDAS just gets the
  bits on the fly from the monitor), so loading another set of MONSYM
  symbols on the fly might be confusing some piece of conditional
  assembly code.

If all of this fails, send mail to [email protected] and you
might find some hardy soul with the time and inclination to help you
out.  At the very least you'll brighten up the day for a few people
who thought that list had died due to apathy....

--Rob
-------
21-Nov-88 10:33:49-PST,2371;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%[email protected]>
Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 21 Nov 88 10:31:19-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 9345; Mon, 21 Nov 88 13:32:27 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Mon, 21 Nov 88 11:04:33 MST
Date:     Mon, 21 Nov 88 11:04:00 MST
From:     rmf%Janus.MRC.AdhocNet.CA%[email protected] (Russ Forster)
Message-Id: <[email protected]>
Subject:  Re: EMACS under TOPS-20 v 7.0
In-Reply-To: Your message <[email protected]> dated
       20-Nov-1988
To:       [email protected]
cc:       [email protected]


> .FBKEP undefined is almost undoubtedly due to your TWXBTS.MID being old.
> You can get the definition from the MONSYM.MAC that came with your
> Rel-7 tapes, and edit it into TWXBTS by hand.

       Considering I'm going from 6.1 to 7.0, I'm sure this is the case.
       I'll lay odds on it being a 5.1 version.

> The other errors are all due to the fact that you have somehow asked
> TECO to include support for VTS virtual terminals. These are an MIT-
> only extension to TOPS20. Check your CONFIG.MID file and make sure
> that the VTS terminal type -isn't- defined. I think you are using
> the file just as you got it from MIT, which won't quite work.

       I can't seem to find where this definition takes place.

> What version of EMACS and TECO do you have?

       EMACS 62172
       TECO 1171
       MIDAS 425

       If these are the most receivt copies, and I doubt they are, is
       there a place a non-FTP site can get them from?  Mark, can I get
       tehm from SERVICE@SRI-NIC?

> There really isn't anybody supporting this stuff anymore, but there
> are a couple of us who can try to help you if you get stuck again.
> Good luck...

       Thanks,

> -john

       /Russ
-----
Russell M. Forster, Systems Programmer II.

Mount Royal College        DECnet: RMF @ Janus
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      ICBM:   51 03 N / 114 05 W
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
23-Nov-88 00:25:46-PST,2317;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 00:24:11-PST
Date: Wed 23 Nov 88 03:26:02-EST
From: Rob Austein <[email protected]>
Subject: You've heard of the annual MIT piano drop?  Well...
To: [email protected]
Message-ID: <[email protected]>

 Date: Tue 1 Nov 88 16:46:10-EST
 From: Jan Thomson <[email protected]>

 LCS-Announcement-1/Nov/88

 XX is shutting down on 15/Jan/89

 The primary user services provided by the DEC 2065 system XX are
 (e-mail, Emacs, Scribe, TEX, File backup).  These functions are
 available on other systems at LCS.

 An October 20, 1988 meeting of the Computer Resources Advisory
 Committee carefully reviewed the financial and space costs of XX and
 the technical and social consequences of shutting down XX.  It
 concluded that:

 "Effective January 15, 1989 all user accounts on XX will be
 discontinued and all user level services will be terminated provided a
 system to retrieve XX tape files has been demonstrated."

 This decision has been reviewed and agreed to by the system manager
 (Austein), and the Computer Resources Advisory Committee members
 (Greene, Vezza, Clark, Ward, Rivest, Szolovits).

 Users of XX are asked to transfer their processing to their own group
 systems or their personal workstations.

 Please direct comments/suggestions to [email protected].

 -------

Before anybody panics, we will be doing something to preserve the
hostname XX.LCS.MIT.EDU and the email functions associated with it.
We will also figure out something to do with the CHIVES sources and
other source code that somebody tells us ([email protected])
is important.  But we are unlikely to be doing much more Twenex
development after January, and anybody still using an XX user account
had better find another home.

For those who care, the thing that finally killed the machine was
footprint.  Where it says in the enclosed notice that I agreed to the
decision, it really means that I agreed that the machine probably
would not run too well out in the parking lot.

--Rob

... Three little Indian boys walking in the Zoo;
    A big bear hugged one and then there were two ...
-------
23-Nov-88 09:53:15-PST,1785;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%[email protected]>
Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 09:51:34-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 2667; Wed, 23 Nov 88 12:52:43 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Wed, 23 Nov 88 09:56:51 MST
Date:     Wed, 23 Nov 88 09:56:25 MST
From:     rmf%Janus.MRC.AdhocNet.CA%[email protected] (Russ Forster)
Message-Id: <[email protected]>
Subject:  EMACS on 7.0
To:       [email protected]

       Thanks to all for the suggestions they provided.  I still have
       a problem, most mentioned that virtual-terminal stuff, but I can't
       seem to find it defined anywhere.  Actually, I looked at all the
       code and both TECO and EMACS (and MIDAS for that matter) had no
       machines defined.  I was able to finally bebuild MIDAS, bit now
       none of the monsym entries are defined and nothing compiles.
       I did a '@set trap file' and noticed that DECDFS and TSRTNS are
       both read.  I seem to be really lost here.

       I'm still looking for a place a non-FTP person can get EMACS
       from.  Does anyone know of such a place?  Would someone like
       to e-mail the files? Maybe a uuencoded TAR file or some such.

       /Russ

-----
Russell M. Forster, Systems Programmer II.

Mount Royal College        DECnet: RMF @ Janus
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      ICBM:   51 03 N / 114 05 W
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
23-Nov-88 10:32:03-PST,1113;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 10:31:15-PST
Date: Wed 23 Nov 88 13:32:34-EST
From: Rob Austein <[email protected]>
Subject: Re: EMACS on 7.0
To: rmf%Janus.MRC.AdhocNet.CA%[email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

TSRTNS is ok in a TOPS-20 MIDAS assembly (TS = Time Sharing, ie, not
running on a bare PDP-10).  DECDFS is NOT ok in a TOPS-20 assembly,
it's TOPS-20 UUOs.  Read the comment at the head of MIDAS.MID that
describes assembly options, and assemble it as if you were
cross-assembling it with TOPS-20 as the target system (ie, don't rely
on MIDAS to figure out what opsys you want it to run on).

Most of the VTS code in TECO is under IFN VTS,[] switches in
TECTRM.MID.  There are also some bits and pieces of it that are just
assumed if the right VTS specific jsi are defined in TECO.MID, which
is why it's important to get a coherent version of MIDAS.

--Rob
-------
23-Nov-88 10:34:19-PST,571;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SCORE.STANFORD.EDU with TCP; Wed 23 Nov 88 10:32:51-PST
Date: Wed 23 Nov 88 13:34:27-EST
From: Rob Austein <[email protected]>
Subject: typo in previous message
To: rmf%Janus.MRC.AdhocNet.CA%[email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

That should have been "DECDFS is NOT ok in a TOPS-20 assembly, it's TOPS-10
UUOs" rather than "TOPS-20 UUOs".  Sigh.
-------
25-Nov-88 17:03:14-PST,461;000000000000
Return-Path: <[email protected]>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Fri 25 Nov 88 17:00:13-PST
Date: Fri, 25 Nov 88 18:02:04 MST
From: Mark Crispin <[email protected]>
Subject: GTHST% bug
To: [email protected]
Address: P.O. Box 2652; Seattle, WA  98111-2652
Message-ID: <[email protected]>

In MNETDV, the JUMPL P2,<lit> at GTHHNN+2 should be JUMPL P1,...
-------
28-Nov-88 13:58:23-PST,2808;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%[email protected]>
Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Mon 28 Nov 88 13:53:00-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 9802; Mon, 28 Nov 88 16:52:06 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Mon, 28 Nov 88 14:47:14 MST
Date:     Mon, 28 Nov 88 14:46:38 MST
From:     rmf%Janus.MRC.AdhocNet.CA%[email protected] (Russ Forster)
Message-Id: <[email protected]>
Subject:  Re:  Re:  EMACS under TOPS-20 v 7.0
In-Reply-To: Your message <ms11(6044)+glxlib6(0) 12448854583.144.27.110682 at
       dated 23-Nov-1988
To:       [email protected]

> Is it reading EMACS.VARS from your BS: directory instead of your PS: directory
?

       Not its not, nor is it reading my EMACS.INIT file....

> If so I may able to help with a workaround patch.  I'm not able to get the
> specifics right now, but we have a patched TECPUR.EXE here.  There is a spot i
n
> the code where it is trying to get the logged in corectory number from the
> logged in user number.  It does this by loading 40000 in to the left have of
> AC1 returned by GJINF.  This will mean that you will get the first entry in
> STRTAB for the structure.  Since BS: is always at STRTAB+0 and PS: is always a
t
> STRTAB+1, a cheap way around this is to add 1 to the structure number field.

       ...because according to your scenerio the following happens

       PS:[rmf] -> PS:[4,116]
       BS:[4,116] -> PS:[omega.source.new]

> In our TECPUR, it is at the following addresses.  The GJINF% (JSYS 13) is the
> one at the lowest address in TECPUR.

> 6046/   GJINF%
> 6047/   TLNE 1,777777
> 6050/   TLO 1,40000   TLO 1,40001

> Since you cannot rebuild your EMACS for whatever reason, this patch should mak
e
> it look at PS:<user> instead of BS:<user>.  I'll try to find out more about
> this if you want me to.

       Applying this patch to TECPUR worked!  EMACS is now using my .INIT
       and .VARS files just aa it does on 6.1.  This makes me a very happy
       puppy :-) :-) :-) :-) :-)......

       It concerns me though that the tlo,1,40000 gets broken, I see to
       remember code that I've written that does the same sort of thing.
       Were things always this way or is this new to 7.0.

       /Russ
-----
Russell M. Forster, Systems Programmer II.

Mount Royal College        DECnet: RMF @ Janus
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      ICBM:   51 03 N / 114 05 W
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
28-Nov-88 23:00:58-PST,624;000000000000
Return-Path: <[email protected]>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Mon 28 Nov 88 22:59:14-PST
Date: Mon, 28 Nov 88 19:05:33 MST
From: Mark Crispin <[email protected]>
Subject: RMF's problem with TECO
To: [email protected]
Address: P.O. Box 2652; Seattle, WA  98111-2652
Message-ID: <[email protected]>

The correct way to translate a user number to a PS: directory
number is to use RCDIR%, not TLO ac,40000 for the reason that
can be observed here -- the login structure is not necessarily
the same as structure 0.
-------
29-Nov-88 08:14:06-PST,774;000000000000
Return-Path: <[email protected]>
Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 08:08:27-PST
Date: Tue 29 Nov 88 11:07:39-EST
From: C. P. Yeske <[email protected]>
Subject: Tops20 Utilities Going...
To: [email protected]
Home-Phone: (412)422-4667  (422-GOOP, -IONS, -HOOP)
Office: UCC A72 x2647
Organization: Carnegie Mellon Computing Services, Hardware Systems
Message-ID: <[email protected]>



CMU is in the process of phasing out its DEC 2060's.  In 9 years, I have
accumulated some unique utilities, games, etc that depend on this system.
Most are .exe files, some are source.  Is anyone interested in these before
I delete the files?

Curt

[email protected]
[email protected]

-------
29-Nov-88 09:04:12-PST,1603;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%[email protected]>
Received: from CORNELLC.ccs.cornell.edu (CORNELLC.CIT.CORNELL.EDU.#Internet) by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 08:56:46-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 1016; Tue, 29 Nov 88 11:56:10 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Tue, 29 Nov 88 09:54:20 MST
Date:     Tue, 29 Nov 88 09:53:35 MST
From:     rmf%Janus.MRC.AdhocNet.CA%[email protected] (Russ Forster)
Message-Id: <[email protected]>
Subject:  Re: RMF's problem with TECO
In-Reply-To: Your message <[email protected]> dated
       28-Nov-1988
To:       [email protected]
cc:       [email protected]

> The correct way to translate a user number to a PS: directory
> number is to use RCDIR%, not TLO ac,40000 for the reason that
> can be observed here -- the login structure is not necessarily
> the same as structure 0.

       Yes but the problem remains that I can't rebuild TECO (for whatever
       reason).  I have successfully patched TECPUR and I do have EMACS
       working again.

       Thanks to all for all your help.

       /Russ
-----
Russell M. Forster, Systems Programmer II.

Mount Royal College        DECnet: RMF @ Janus
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      ICBM:   51 03 N / 114 05 W
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
29-Nov-88 14:16:01-PST,589;000000000000
Return-Path: <[email protected]>
Received: from MCC.COM by SCORE.STANFORD.EDU with TCP; Tue 29 Nov 88 14:03:21-PST
Date: Tue 29 Nov 88 16:02:57-CST
From: Clive Dawson <[email protected]>
Subject: Re: Tops20 Utilities Going...
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>

Curt-
 It would be nice if you could put all this stuff into some anonymously
ftp'able directory so that the few of us who remain can do some
browsing.  Is this feasible?

Thanks,

Clive
-------
1-Dec-88 18:34:44-PST,1797;000000000000
Return-Path: <[email protected]>
Received: from WSMR-SIMTEL20.ARMY.MIL by SCORE.STANFORD.EDU with TCP; Thu 1 Dec 88 18:31:19-PST
Date: Thu, 1 Dec 1988  19:30 MST
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To:   "C. P. Yeske" <[email protected]>
Cc:   [email protected], [email protected]
Subject: Tops20 Utilities Going...
In-reply-to: Msg of 29 Nov 1988  09:07-MST from C. P. Yeske <CY13 at TE.CC.CMU.EDU>

In keeping with our reputation in other areas as a repository of all
sorts of software, we request that you and anyone else planning to
phase out their DEC-20 take the time to make a DUMPER tape at 6250 bpi
(preferred), and mail it to me at the address below.  MRC, CLIVE, and
myself will attempt to maintain an organized collection online.  I
already have a tape from Columbia, not yet online due to disk space
availability.  I expect to procure four more RP07s during this FY to
expand the disk space available for our ever-growing collections.

To avoid any possible tape mixups in my office, please use the
following address:

Frank J. Wancho
10560 Lakewood
El Paso, TX 79925

The last time I sent a message on this subject, I gave it the obscure
title of the Seattle Project, and many of you did not make the
connection.  Several years ago, the aerospace industry was
experiencing massive layoffs which particularly affected the Seattle
area.  Rumor has it that that was a billboard on one of the main
arteries leading out of Seattle asking, "Would the last one out please
shut off the lights?"  We plan to hold on to what we got and be that
last one to keep the lights burning...  (I told you it was obscure,
and it still is...)

--Frank
2-Dec-88 06:43:30-PST,1278;000000000000
Return-Path: <[email protected]>
Received: from RADC-MULTICS.ARPA by SCORE.STANFORD.EDU with TCP; Fri 2 Dec 88 06:41:11-PST
Date:  Fri, 2 Dec 88 09:38 EST
From:  [email protected]
Subject:  NETWORK PROBLEMS
To:  [email protected]
cc:  [email protected]
Message-ID:  <[email protected]>


We have been having network problems for the past week.  I think most of
you have had some of the same problems.  First it was the gateways, then
our IMP, then I believe they took the Arpanet down.

Some of it seems to be fixed, but we (RADC-TOPS20.ARPA) are still not
able to communicate with anyone. That's why I am sending this from
RADC-MULTICS.ARPA.

The question:  Is the Arpanet back up and running ?  One of our hosts
can communicate but we can't.  We are getting BUGINF NTOHNG.  Is it the
network still or do we have some hardware or software problems?  I thought
one of you might be more familiar with what is going on and could save
me some time/money on hardware calls.  I don't have a clue as to where
to start.

Thanks,
Donna

Please reply to me directly at [email protected].
RADC-TOPS20.ARPA is on the mailing list, but as I said we aren't
receiving any messages right now.
15-Dec-88 10:57:35-PST,778;000000000000
Return-Path: <[email protected]>
Received: from TE.CC.CMU.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Dec 88 10:53:42-PST
Date: Thu 15 Dec 88 13:51:50-EST
From: C. P. Yeske <[email protected]>
Subject: Re:Tops-20 programs
To: [email protected]
Home-Phone: (412)422-4667  (422-GOOP, -IONS, -HOOP)
Office: UCC A72 x2647
Organization: Carnegie Mellon Computing Services, Hardware Systems
Message-ID: <[email protected]>



Do to overwhelming demand, I have the files available for anonymous FTP
from PS:<cy13>*.*.*@te.cc.cmu.edu.   I can not make a tape of these,
sorry.  These files will be deleted sometime before DEC 20th, so act
quickly...


Let me know of any problems, but I think that this is the best I can do.

Curt
-------
15-Dec-88 13:17:43-PST,712;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Thu 15 Dec 88 13:16:14-PST
Date: Thu, 15 Dec 88 13:16:17 PST
From: Mark Lottor <[email protected]>
Subject: DEC-20 day
To: [email protected]
Message-ID: <[email protected]>

I'm arranging another DEC-20 day for people in the bay area.  This
time it will be lunch in Palo Alto.  Come talk with other 20 hackers
or X-20 hackers about DEC-20's.  There may even be souvenirs and
possibly a showing of a 20 related video tape afterwards.

The date is Tuesday, Dec 20, 1988 at Noon.
The place will be Theo's at 546 University Ave in Palo Alto.
You should RSVP to me by Dec 19.
-------
23-Dec-88 08:59:23-PST,2091;000000000000
Return-Path: <@CORNELLC.ccs.cornell.edu:rmf%[email protected]>
Received: from CORNELLC.ccs.cornell.edu by SCORE.STANFORD.EDU with TCP; Fri 23 Dec 88 08:57:42-PST
Received: from UNCAEDU.BITnet by CORNELLC.ccs.cornell.edu (IBM VM SMTP R1.2) with BSMTP id 6268; Fri, 23 Dec 88 11:58:18 EST
Received: from Janus.MRC.AdhocNet.CA by UcEdu.UNCA.AdhocNet.CA with DECNET ;
         Fri, 23 Dec 88 09:54:24 MST
Date:     Fri, 23 Dec 88 09:52:12 MST
From:     rmf%Janus.MRC.AdhocNet.CA%[email protected] (Russ Forster)
Message-Id: <[email protected]>
Subject:  OPRIAC-CRASHes
To:       [email protected]

       Since moving to 7.0 AP19 we have experenced this type of OPR
       crash.  The crash comes as soon as you issue a SHOW MESSAGES <ret>
       and there are too many message to display.  It appears that there
       canot be more then 10 outstanding messages.  If you go through
       and issue a 'RESPOND n PROCEED' where n=1 to 11 by 1 you will clear
       enough outstanding messages to actually do a SHOW MESSAGES command.

       Why do we have so many messages at boot time you ask?  Well we
       have approx 30 remote printers via LAT what need to be accessable
       from all systems.

       While I'm here, the person that designed the OPR interface for
       defining remote printers must have been on drugs.  That is the
       most convoluted pile of doggie-doo i have ever seen.

       Ok you system managers out there, try and explain that interface
       to your operators!

       Merry Christmas to all and a very Happy New Year!

       /Russ

       ps.  How was DEC-20 day?  Being in Canada its kinda hard to justify
            a lunch in Calafornia!  :-)

-----
Russell M. Forster, Systems Programmer II.

Mount Royal College        DECnet: RMF @ Janus
Computer Operations        BITnet: RForster @ UncaEdu.BITnet
4825 Richard Rd. S.W.      ICBM:   51 03 N / 114 05 W
Calgary, Alberta           Phone:  (403) 240-6052
T3E 6K6
23-Dec-88 20:13:04-PST,783;000000000000
Return-Path: <[email protected]>
Received: from SRI-NIC.ARPA by SCORE.STANFORD.EDU with TCP; Fri 23 Dec 88 20:12:28-PST
Date: Fri, 23 Dec 88 20:12:03 PST
From: Mark Lottor <[email protected]>
Subject: dec-20 day
To: [email protected]
Message-ID: <[email protected]>

DEC-20 day turned out fairly well this year.  Exactly half a word of
people showed up for the lunch.  After lunch there were some bumper
stickers to commemorate the event.  DEC donated a box of DECsystem-4050
3-ring binders as souvenirs.  Later on we watched a video tape of some
DEC-commercial skits, followed by a talk (on tape) by Alan Kotok on
the origins of the PDP-6 and PDP-10.  Thanks to Joe Dempster of DEC
for the binders and Len Bosack of cisco for the tapes.
-------