Hacker Chronicles 1/HACKER1.ISO/phrk3/ph305.txt

Text File | 1992-09-26 | 29KB | 591 lines

                                ==Phrack Inc.==

                     Volume Three, Issue 30, File #5 of 12

                    ()()()()()()()()()()()()()()()()()()()
                    ()                                  ()
                    ()      The DECWRL Mail Gateway     ()
                    ()                                  ()
                    ()         by Dedicated Link        ()
                    ()                                  ()
                    ()        September 20, 1989        ()
                    ()                                  ()
                    ()()()()()()()()()()()()()()()()()()()


INTRODUCTION

DECWRL is a mail gateway computer operated by Digital's Western Research
Laboratory in Palo Alto, California.  Its purpose is to support the interchange
of electronic mail between Digital and the "outside world."

DECWRL is connected to Digital's Easynet, and also to a number of different
outside electronic mail networks.  Digital users can send outside mail by
sending to DECWRL::"outside-address", and digital users can also receive mail
by having your correspondents route it through DECWRL.  The details of incoming
mail are more complex, and are discussed below.

It is vitally important that Digital employees be good citizens of the networks
to which we are connected.  They depend on the integrity of our user community
to ensure that tighter controls over the use of the gateway are not required.
The most important rule is "no chain letters," but there are other rules
depending on whether the connected network that you are using is commercial or
non-commercial.

The current traffic volume (September 1989) is about 10,000 mail messages per
day and about 3,000 USENET messages per day.  Gatewayed mail traffic has
doubled every year since 1983.  DECWRL is currently a Vax 8530 computer with 48
megabytes of main memory, 2500 megabytes of disk space, 8 9600-baud (Telebit)
modem ports, and various network connections.  They will shortly be upgrading
to a Vax 8650 system.  They run Ultrix 3.0 as the base operating system.


ADMINISTRATION

The gateway has engineering staff, but no administrative or clerical staff.
They work hard to keep it running, but they do not have the resources to answer
telephone queries or provide tutorials in its use.

They post periodic status reports to the USENET newsgroup dec.general.  Various
helpful people usually copy these reports to the VAXNOTES "gateways" conference
within a day or two.


HOW TO SEND MAIL

DECWRL is connected to quite a number of different mail networks.  If you were
logged on directly to it, you could type addresses directly, e.g.

    To: strange!foreign!address.

But since you are not logged on directly to the gateway, you must send mail so
that when it arrives at the gateway, it will be sent as if that address had
been typed locally.


* Sending from VMS

If you are a VMS user, you should use NMAIL, because VMS mail does not know how
to requeue and retry mail when the network is congested or disconnected.  From
VMS, address your mail like this:

    To: nm%DECWRL::"strange!foreign!address"

The quote characters (") are important, to make sure that VMS doesn't try to
interpret strange!foreign!address itself.  If you are typing such an address
inside a mail program, it will work as advertised.  If you are using DCL and
typing directly to the command line, you should beware that DCL likes to remove
quotes, so you will have to enclose the entire address in quotes, and then put
two quotes in every place that one quote should appear in the address:

    $ mail test.msg "nm%DECWRL::""foreign!addr""" /subj="hello"

Note the three quotes in a row after foreign!addr.  The first two of them are
doubled to produce a single quote in the address, and the third ends the
address itself (balancing the quote in front of the nm%).

Here are some typical outgoing mail addresses as used from a VMS system:

    To: nm%DECWRL::"lll-winkin!netsys!phrack"
    To: nm%DECWRL::"[e-mail]"
    To: nm%DECWRL::"netsys![e-mail]"
    To: nm%DECWRL::"[e-mail]"
    To: nm%DECWRL::"[e-mail]"

* Sending from Ultrix

If your Ultrix system has been configured for it, then you can, from your
Ultrix system, just send directly to the foreign address, and the mail software
will take care of all of the gateway routing for you.  Most Ultrix systems in
Corporate Research and in the Palo Alto cluster are configured this way.

To find out whether your Ultrix system has been so configured, just try it and
see what happens.  If it doesn't work, you will receive notification almost
instantly.

    NOTE:  The Ultrix mail system is extremely flexible; it is almost
    completely configurable by the customer.  While this is valuable to
    customers, it makes it very difficult to write global instructions for
    the use of Ultrix mailers, because it is possible that the local changes
    have produced something quite unlike the vendor-delivered mailer.  One of
    the popular changes is to tinker with the meaning of quote characters (")
    in Ultrix addresses.  Some systems consider that these two addresses are
    the same:

        site1!site2![e-mail]

    and

        "site1!site2!user"@host.dec.com

    while others are configured so that one form will work and the other
    will not.  All of these examples use the quotes.  If you have trouble
    getting the examples to work, please try them again without the quotes.
    Perhaps your Ultrix system is interpreting the quotes differently.

If your Ultrix system has an IP link to Palo Alto (type "/etc/ping
decwrl.dec.com" to find out if it does), then you can route your mail to the
gateway via IP.  This has the advantage that your Ultrix mail headers will
reach the gateway directly, instead of being translated into DECNET mail
headers and then back into Ultrix at the other end.  Do this as follows:

    To: "alien!address"@decwrl.dec.com

The quotes are necessary only if the alien address contains a ! character, but
they don't hurt if you use them unnecessarily.  If the alien address contains
an "@" character, you will need to change it into a "%" character.  For
example, to send via IP to [e-mail], you should address the mail

    To: "joe%widget.org"@decwrl.dec.com

If your Ultrix system has only a DECNET link to Palo Alto, then you should
address mail in much the same way that VMS users do, save that you should not
put the nm% in front of the address:

    To: DECWRL::"strange!foreign!address"

Here are some typical outgoing mail addresses as used from an Ultrix system
that has IP access.  Ultrix systems without IP access should use the same
syntax as VMS users, except that the nm% at the front of the address should not
be used.

    To: "lll-winken!netsys!phrack"@decwrl.dec.com
    To: "postmaster%msp.pnet.sc.edu"@decwrl.dec.com
    To: "phrackserv%CUNYVM.bitnet"@decwrl.dec.com
    To: "netsys!phrack%uunet.uu.net"@decwrl.dec.com
    To: "[e-mail]"@decwrl.dec.com


DETAILS OF USING OTHER NETWORKS

All of the world's computer networks are connected together, more or less, so
it is hard to draw exact boundaries between them.  Precisely where the Internet
ends and UUCP begins is a matter of interpretation.

For purposes of sending mail, though, it is convenient to divide the network
universe into these categories:

Easynet         Digital's internal DECNET network.  Characterized by addresses
                of the form NODE::USER.  Easynet can be used for commercial
                purposes.

Internet        A collection of networks including the old ARPAnet, the NSFnet,
                the CSnet, and others.  Most international research,
                development, and educational organizations are connected in
                some fashion to the Internet.  Characterized by addresses of
                the form [e-mail].  The Internet itself
                cannot be used for commercial purposes.

UUCP            A very primitive network with no management, built with
                auto-dialers phoning one computer from another.  Characterized
                by addresses of the form place1!place2!user.  The UUCP network
                can be used for commercial purposes provided that none of the
                sites through which the message is routed objects to that.

USENET          Not a network at all, but a layer of software built on top of
                UUCP and Internet.

BITNET          An IBM-based network linking primarily educational sites.
                Digital users can send to BITNET as if it were part of
                Internet, but BITNET users need special instructions for
                reversing the process.  BITNET cannot be used for commercial
                purposes.

Fidonet         A network of personal computers.  I am unsure of the status of
                using Fidonet for commercial purposes, nor am I sure of its
                efficacy.


DOMAINS AND DOMAIN ADDRESSING

There is a particular network called "the Internet;" it is somewhat related to
what used to be "the ARPAnet."  The Internet style of addressing is flexible
enough that people use it for addressing other networks as well, with the
result that it is quite difficult to look at an address and tell just what
network it is likely to traverse.  But the phrase "Internet address" does not
mean "mail address of some computer on the Internet" but rather "mail address
in the style used by the Internet."  Terminology is even further confused
because the word "address" means one thing to people who build networks and
something entirely different to people who use them.  In this file an "address"
is something like "[e-mail]" and not "192.1.24.177" (which is what
network engineers would call an "internet address").

The Internet naming scheme uses hierarchical domains, which despite their title
are just a bookkeeping trick.  It doesn't really matter whether you say
NODE::USER or USER@NODE, but what happens when you connect two companies'
networks together and they both have a node ANCHOR??  You must, somehow,
specify which ANCHOR you mean.  You could say ANCHOR.DEC::USER or
DEC.ANCHOR::USER or [e-mail] or [e-mail].  The Internet
convention is to say [e-mail], with the owner (DEC) after the name
(ANCHOR).

But there could be several different organizations named DEC.  You could have
Digital Equipment Corporation or Down East College or Disabled Education
Committee.  The technique that the Internet scheme uses to resolve conflicts
like this is to have hierarchical domains.  A normal domain isn't DEC or
STANFORD, but DEC.COM (commercial) and STANFORD.EDU (educational).  These
domains can be further divided into ZK3.DEC.COM or CS.STANFORD.EDU.  This
doesn't resolve conflicts completely, though:  both Central Michigan University
and Carnegie-Mellon University could claim to be CMU.EDU.  The rule is that the
owner of the EDU domain gets to decide, just as the owner of the CMU.EDU gets
to decide whether the Electrical Engineering department or the Elementary
Education department gets subdomain EE.CMU.EDU.

The domain scheme, while not perfect, is completely extensible.  If you have
two addresses that can potentially conflict, you can suffix some domain to the
end of them, thereby making, say, decwrl.UUCP be somehow different from
DECWRL.ENET.

DECWRL's entire mail system is organized according to Internet domains, and in
fact we handle all mail internally as if it were Internet mail.  Incoming mail
is converted into Internet mail, and then routed to the appropriate domain; if
that domain requires some conversion, then the mail is converted to the
requirements of the outbound domain as it passes through the gateway.  For
example, they put Easynet mail into the domain ENET.DEC.COM, and they put
BITNET mail into the domain BITNET.

The "top-level" domains supported by the DECWRL gateway are these:

  .EDU        Educational institutions
  .COM        Commercial institutions
  .GOV        Government institutions
  .MIL        Military institutions
  .ORG        Various organizations
  .NET        Network operations
  .BITNET     The BITNET
  .MAILNET    The MAILNET
  .??         2-character country code for routing to other countries
  .OZ         Part of the Australian (.AU) name space.

2-character country codes include UK (United Kingdom), FR (France), IT (Italy),
CA (Canada), AU (Australia), etc.  These are the standard ISO 2-character
country codes.


MAILING TO EASYNET

To mail to user SPRINTER at node WASH (which is DECNET address WASH::SPRINTER),
Internet mail should be addressed to [e-mail].  Easynet
addresses are not case-dependent; WASH and wash are the same node name and
SPRINTER and sprinter are the same user name.

Sites that are not directly connected to the Internet may have difficulty with
Internet addresses like wash.enet.dec.com.  They can send into the Easynet by
explicitly routing the mail through DECWRL.  From domain-based Internet
mailers, the address would be [e-mail].  From UUCP
mailers, the address would be decwrl!wash.enet!sprinter. Some Internet mailers
require the form <@decwrl.dec.com:[e-mail]>.  (This last form is the
only technically correct form of explicit route, but very few Internet sites
support it.)

The DECWRL gateway also supports various obsolete forms of addressing that are
left over from the past.  In general they support obsolete address forms for
two years after the change, and then remove it.


MAILING TO DIGITAL ALL-IN-1 USERS

Some Easynet users do not have a direct DECNET node address, but instead read
their mail with All-in-1, which uses addresses of the form "Nate State @UCA".
Here "UCA" is a Digital location code name.  To route mail to such people, send
to [e-mail].  Mail received from the All-in-1 mailer is
unreplyable, and in fact unless the respondent tells you his return address in
the body of the message, it is not normally possible even to puzzle out the
return address by studying the message header.  Mail from All-in-1 to Easynet
passes through a gateway program that does not produce valid return addresses.


MAILING TO THE INTERNET

DECWRL's mailer is an Internet mailer, so to mail to an Internet site, just use
its address.  If you are having trouble determining the Internet address, you
might find that the Ultrix host table /etc/hosts.txt is useful.  If you can't
find one anywhere else, there's one on DECWRL.  See the commentvpX1ove under
"how to send mail" for details about making sure that the mail program you are
using has correctly interpreted an address.


MAILING TO UUCP

UUCP mail is manually routed by the sender, using ! as the separator character.
Thus, the address xxx!yyy!zzz!user means to dial machine xxx and relay to it
the mail, with the destination address set to yyy!zzz!user.  That machine in
turn dials yyy, and the process repeats itself.

To correctly address UUCP mail, you must know a working path through the UUCP
network.  The database is sufficiently chaotic that automatic routing does not
work reliably (though many sites perform automatic routing anyhow).  The
information about UUCP connectivity is distributed in the USENET newsgroup
comp.mail.maps; many sites collect this data and permit local queries of it.

At the end of this file is a list of the UUCP nodes to which DECWRL currently
has a working connection.


MAILING TO USENET

Usenet is not a network.  It's a software layer, and it spans several networks.
Many people say "Usenet" when they really mean UUCP.  You can post a message to
a Usenet newsgroup by mailing it to "name@usenet" at DECWRL.  For example,
mailing from VMS to this address:

    nm%DECWRL::"alt.cyberpunk@usenet"

causes the mail message to be posted as an article to the Usenet newsgroup
alt.cyberpunk.  It is better to use Usenet software for posting articles, as
more features are available that way, such as restricted distributions,
crossposting, and cancellation of "wish I hadn't sent that" articles.


MAILING TO BITNET

Legend has it that the "BIT" in BITNET stands for "Because It's There" or
"Because It's Time."  It is a network consisting primarily of IBM computers.  A
native BITNET address is something like "OMAR at STANFORD", but when translated
into our Internet format it becomes [e-mail].  Once translated into
Internet form, a BITNET address is used just like any other Internet address.


MAILING TO FIDONET

By comparison with the other linked networks, Fidonet has an addressing
complexity bordering on the bizarre.  The Fidonet people have provided me with
this description:

Each Fidonet node is a member of a "network," and may have subsidiary nodes
called "point nodes."  A typical Fido address is "1:987/654" or "987/654"; a
typical Fido "point node" address is "1:987/654.32" or "987/654.32".  This is
zone 1, network 987, Fido (node) 654, "point node" 32.  If the zone number is
missing, assume it is zone 1.  The zone number must be supplied in the outgoing
message.

To send a message to Chris Jones on Fidonet address 1:987/654, use the address
[e-mail].  To send a message to Mark Smith at
Fidonet node 987/654.32, use address [e-mail].
Use them just like any other Internet address.

Sometimes the return addresses on messages from Fidonet will look different.
You may or may not be able to reply to them.

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

Appendix:  List of UUCP Neighbor Sites

This table shows most of the sites that DECWRL dials directly via UUCP.  You
may find it useful to help you construct a UUCP route to a particular
destination.  Those sites marked with "*" are major UUCP routing nodes.  You
should prefer UUCP routes that use these sites as the first hop from DECWRL.
Case is significant in UUCP host names.

      3comvax    3Com Corporation, Santa Clara, CA
      abvax      Allen-Bradley Company, Highland Heights, OH
      acad       Autodesk, Inc, Sausalito, CA
      adobe      Adobe Systems Inc., Mountain View, CA
      alberta    University of Alberta, Edmonton, Alberta, Canada
      allegra    AT&T Bell Laboratories, Murray Hill, NJ
     *amdahl     Amdahl Corp., Sunnyvale, CA
      amdcad     Advanced Micro Devices, Sunnyvale, CA
      ames       NASA Ames Research Center, Mountain View, CA
     *apple      Apple Computers, Cupertino, CA
      ardent     Ardent Computer Corp., Sunnyvale, CA
      argosy     MassPar Computer Corp., Sunnyvale, CA
      atha       Athabasca University, Athabasca, Alberta, Canada
      athertn    Atherton Technology, Sunnyvale, CA
     *att        AT&T Bell Laboratories, Columbus, Ohio
      avsd       Ampex Corporation, Redwood City, CA
      cae78""   Tektronix Inc. (Santa Clara Field Office) Santa Clara, CA
      chip       M/A-COM Government Systems, San Diego, CA
      claris     Claris Corporation, Mountain View, CA
      daisy      Daisy Systems, Mountain View, CA
      decuac     DEC/Ultrix Applications Ctr, Landover, MD
     *decvax     DEC/Ultrix Engineering, Nashua, NH
      dsinc      Datacomp Systems, Inc, Huntington Valley, PA
      eda        EDA Systems Inc., Santa Clara, CA
      emerald    Emerald Systems Corp., San Diego, CA
      escd       Evans and Sutherland Computer Division, Mountain View, CA
      esunix     Evans and Sutherland Corp., Salt Lake City, UT
      fluke      John Fluke Manufacturing, Everett, WA
      gryphon    Trailing Edge Technology, Redondo Beach, CA
      handel     Colorodo State Univ., CS Dept., Ft. Collins, CO
      hoptoad    Nebula Consultants, San Francisco, CA
     *hplabs     Hewlett Packard Research Labs, Palo Alto, CA
      ide        Interactive Development Environments, San Francisco, CA
      idi        Intelligent Decisions, Inc., San Jose, CA
      imagen     Imagen Corp., Santa Clara, CA
      intelca    Intel Corp., Santa Clara, CA
      limbo      Intuitive Systems, Los Altos, CA
      logitech   Logitech, Inc., Palo Alto, CA
      megatest   Megatest Corp., San Jose, CA
      metaphor   Metaphor Corp., Mountain View, CA
      microsoft  Microsoft, Bellevue, WA
      mindcrf    Mindcraft Corp., Palo Alto, CA
      mips       MIPS Computer Systems, Mountain View, CA
      mntgfx     Mentor Graphics Corp., Beaverton, OR
      mordor     Lawrence Livermore National Lab, Livermore, CA
      mtu        Michigan Tech Univ., Houghton, MI
      mtxinu     Mt. Xinu, Berkeley, CA
      nsc        National Semiconductor Corp., Sunnyvale, CA
      oli-stl    Olivetti Software Techn. Lab, Menlo Park, CA
      oracle     Oracle Corp., Belmont, CA
     *pacbell    Pacific Bell, San Ramon, CA
      parcplace  Parc Place Systems, Palo Alto, CA
      purdue     Purdue University, West Lafayette, IN
     *pyramid    Pyramid Technology Corporation, Mountain View, CA
      qubix      Qubix Graphic Systems, San Jose, CA
      quintus    Quintus Computer Systems, Mountain View, CA
      research   AT&T Bell Laboratories, Murray Hill, NJ
      riacs      Res.Inst. for Adv. Compu. Sci., Mountain View, CA
      rtech      Relational Technology Inc., Alameda, CA
      sci        Silicon Compilers, San Jose, CA
      sco        Santa Cruz Operation, Santa Cruz, CA
      sequent    Sequent Computer System, Inc., Beaverton, OR
      sgi        Silicon Graphics, Inc., Mountain View, CA
      shell      Shell Development Corp., Houston, TX
      simpact    Simpact Assoc., San Diego, CA
      sjsca4     Schlumberger Technologies, San Jose, CA
      sun        Sun Microsystems, Mountain View, CA
      td2cad     Intel Corp., Santa Clara, CA
      teraida    Teradyne EDA Inc., Santa Clara, CA
      theta      Process Software Inc., Wellesley, MA
      turtlevax  CIMLINC, Inc, Palo Alto, CA
     *ucbvax     University of California, Berkeley, CA
      utcsri     Univ. of Toronto, Computer Science, Toronto, CA
      vlsisj     VLSI Technology Inc., San Jose, CA
      wyse       Wyse Technology, San Jose, CA
      zehntel    Zehntel, Inc., Walnut Creek, CA
_______________________________________________________________________________

                                ==Phrack Inc.==

                     Volume Three, Issue 30, File #6 of 12

                   Decnet Hackola : Remote Turist TTY (RTT)
                   %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

                           A Late-Night Creation Of

                                   *Hobbit*

This VMS network frob is yet another "tell"-type thing.  This one has an
uncommon feature though:  recursion (i.e. you can be connected to some host
and open *another* connection to a third host and it will [attempt to!] "do the
right thing").  Also, you can ^Y out and if you run it again, it will return to
the open connection instead of starting a new one.

_H*

*************************************************************************
$! RTT -- Remote Turist TTY interface.  Do @RTT hostname or @RTT area.node
$! to start; this file must exist in the remote machine's default area.
$! You can ^Y out and the network channel will stick around; invoking RTT
$! again will resume the extant process and ignore arguments.
$! If we are a network object, play server, if not, we must be the client.
$! If we are called while already playing server, recurse to the end host.
$! This recursion in theory can happen infinite times.  Make damn sure
$! what you call this file and the "task=" spec jive, and that they are the
$! same file, or you will fall victim to very vicious timing screws.
$!
$! Another result of *Hobbit* abusing network file jobs until well past dawn.
$!
$! _H*
$set noon
$if f$mode().eqs."NETWORK".and.p1.eqs."" then $goto srv
$! Talking to a luser, go find the net job
$magic=0                        ! assume top level
$if f$trnlnm("nf",,,,,"table_name").nes."" then $goto lread
$sl=f$len(p1)
$dot=f$locate(".",p1)           ! area.node
$if sl.eq.dot then $goto nopen  ! no dot, treat normally
$q=f$loc("""",p1)               ! access control??
$node=f$ext(0,dot,p1)           ! area
$dot=dot+1                      ! point past it now
$node=node*1024+f$ext(dot,q-dot,p1)  ! and pull out the complete node
$rest=""""+f$ext(q,80,p1)+""""  ! superquotify the quotes [yeccchh!]
$p1="''node'''rest'"            ! add remains in stringwise [ack barf]
$! We were called with an argument; but if we're network mode, we're *already*
$! a server, so do special things.
$nopen: $if f$mode().eqs."NETWORK" then $magic=1
$! Top-level user process or recursed here: client connect
$open/read/write/err=yuk nf 'p1'::"0=rtt"
$read/time=5/err=yuk nf hprm    ! let other end tell us where we got
$prm==hprm                      ! global prompt str so we resume correctly
$write sys$output "Connection open"
$if magic then $goto m_setup
$lread: $read/prompt="''prm'$ "/end=lclose sys$command line
$write nf line                  ! send the sucker and go get the stuff
$ltype: $read/time=8/err=tmo/end=lclose nf line
$if line.eqs."%%eoc%%" then $goto lread
$if line.eqs."%%magic%%" then $goto newprm
$write sys$output line
$goto ltype
$newprm: $read nf hprm          ! new prompt gets piped in from servers
$prm==hprm                      ! let us find it
$read nf line                   ! garbola %%eoc%% -- avoid timing fuckup
$if line.nes."%%eoc%%" then $goto hpe  !! oops !!
$goto lread
$tmo: $write sys$output "[Timed out]"   ! supposed to bail out on a fuckup
$goto lread                             ! it doesn't always work, though.
$!
$! Do a special dance when we're recursing
$m_setup: $write nnn "%%magic%%"
$write nnn prm                  ! notify client end of new connection
$signal                         ! flush the inbetweens
$goto rread                     ! and drop to magic server
$!
$srv:                           ! Normal remote task half
$! This is an unbelievable kludge.  You can't just open sys$net: and then
$! have program output go there as well as the control thingies, but you
$! *can* pipe everything to your sys$net-opened-device: and it *works*!
$open/read/write/err=yuk nnn sys$net:
$close sys$output               ! netserver.log?
$close sys$error
$magic=0                        ! not recursing yet
$! Some handy symbols for the far end
$rtt:==@sys$login:rtt           ! make further connects easier
$ncp:==$ncp                     ! for hacking the network
$signal:==write nnn """%%eoc%%""" ! magic sync string
$write nnn f$trnl("sys$node","lnm$system_table")        ! HELO...
$def/pr sys$output nnn:         ! the awful kludge is invoked
$def/pr sys$error nnn:          ! for error handling too
$!
$! Server loop
$rread: $read/end=rclose nnn line
$if magic then $goto passing
$'line'
$m_cmd_end: $signal             ! signal for all completions
$goto rread
$! If we're magically in the middle, handle differently
$passing: $write nf line
$mtype: $read/time=5/err=mclose/end=mclose nf line
$if line.eqs."%%eoc%%" then $goto m_cmd_end
$write nnn line
$goto mtype
$!
$! Closure and error handlers
$! General protocol error catch
$yuk: $write sys$output "Couldn't open network!"
$exit
$! Here if the luser typed ^Z
$lclose: $close nf              ! should signal eof at far end
$exit
$! Here if we got hung up on by the client
$rclose: $if magic then $close nf
$close nnn
$stop/id=0
$! Here if we're magic and our remote server exited: tell client whats flying
$mclose: $close nf
$magic=0
$write nnn "%%magic%%"
$write nnn f$trnl("sys$node","lnm$system_table")
$signal
$goto rread
$! Here if we recursed down the line there and didn't see the right things
$hpe: $write sys$output "!!Hairy protocol error!!"
$close nf
$exit
_______________________________________________________________________________



Downloaded From P-80 International Information Systems 304-744-2253 12yrs+