HDTenEightyP/NetNews huggingface dataset:
From: ctday@randolf.lbl.gov (Christopher T. Day)
Newsgroups: vmsnet.alpha,comp.sys.dec
Subject: Re: No 64-bit OpenVMS soon?
Date: 22 Jan 1993 18:44:16 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Distribution: world
Reply-To: ctday@randolf.lbl.gov (Christopher T. Day)
NNTP-Posting-Host: 128.3.196.7

In article <C19M1B.KHM@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
Hallam-Baker) writes:
|> In article <1993Jan20.001847.1807@eco.twg.com>, reece@eco.twg.com (Reece R.
|> Pollack) writes:
|> 
|> |>In article <C13yJK.CMJ@dscomsa.desy.de>, hallam@zeus02.desy.de (Phill
|> |>Hallam-Baker) writes:
|> |>|>What matters a damn sight less than a 64 bit O/S is a 64 bit
database. When
|> |>will
|> |>|>Rdb be 64 bit is the real question.
|> |>
|> |>Not being sarcastic in the least, what part of RDB needs to be 64 bit?
|> |>Expanding the address space from 32 to 64 bits is not in itself going
|> |>to make things better, unless the application is starved for memory.
|> |>Remember that Alpha/VMS doesn't suffer from the Vax/VMS 512Mb physical
|> |>memory limitation, even though any single process is still limited to
|> |>a 2Gb virtual address space.
|> 
|> Each of our events is approx 100Kb
|> 
|> We take 10 million of them per second.
|> 
|> Even with filtering we take Terabytes of data per month.
|> 
|> 2Gb is small beans, we will be getting machines with that sort of
memory within
|> the next few years. The successor machine to ZEUS will be producing 2 GB
|> events.
|> 
|> 
|> |>|>Although it would be handy to do big transfers of data - the VMS
64K limit
|> |>is
|> |>|>far too small, this is not essential yet. It will become essential once
|> |>alphas
|> |>|>start operating with a 64K page size though!
|> |>
|> |>The limitiation of I/Os to 64Kb was lifted quite some time ago. The
VAX/VMS
|> |>I/O User's Reference Manual: Part 1 for VAX/VMS V4.4 states:
|> |>
|> |>"Non-DSA disk devices can read or write up to 65.535 bytes in a single
|> |> request. DSA devices connected to an HSC50 can transfer up to 4 billion
|> |> bytes in a single request. In all cases, the maximum size of the transfer
|> |> is limited by the number of pages which can be faulted into the process's
|> |> working set and then locked into memory."
|> |>
|> |>The relevant fields of the IRP were expanded to 32 bits during the
V3 -> V4
|> |>enhancements.
|> 
|> Read the device driver manual and look at the format of the QIO. The 16 bit
|> length is hard coded in there.
|> 
|> What I would like to do is to read in single events with single reads.
|> 
|> --
|> 
|> Phill Hallam-Baker

Hmmm, it's been awhile since I've looked at this, but I thought the
16-bit QIO field was a transfer count of _things_, not necessarily
bytes. The driver could convert that number to a larger one for the
IRP's 32-bit field.

Chris Day
Newsgroups: vmsnet.alpha,comp.sys.dec
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Subject: Re: No 64-bit OpenVMS soon?
Organization: Boeing Computer Services
Date: Sat, 23 Jan 1993 07:28:06 GMT

Several people have pointed out to me that the cost of such a RAM would
exceed the national debt by several orders of magnitude.

Oh well.


Newsgroups: vmsnet.alpha
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: striping/shadowing
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Sun, 24 Jan 1993 22:06:56 GMT

We have on order a DEC 4000 model 610 alpha system running VMS. Recently, I
spoke to a DEC consultant concerning the configuration of this system. He
suggested that ultimately I might want to use a system disk composed of a
stripe set of two RF35's, shadowed on to a second set of two RF35's (we
already have RF35's). Regardless of whether or not this is a good idea, I
know that it is possible to use a shadow set as a system volume (I've done
it). I also know that shadowing is not supported on the Alphas yet, but
will be. However, I thought that it wasn't possible to stripe a system
volume (which is what the STRIPE020 release notes suggest). What's the
scoop?

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853                  FAX:      (607) 255 9166
---------------------------------------------------------------------------
From: zrepachol@cc.curtin.edu.au
Newsgroups: vmsnet.alpha,comp.sys.dec
Subject: Re: No 64-bit OpenVMS soon?
Date: 23 Jan 93 20:06:10 GMT
Organization: Curtin University of Technology

In article <C18sLv.JwM@bcstec.ca.boeing.com>, silverm@bcstec.ca.boeing.com (Jeff Silverman) writes:
...
> Several people have pointed out that anybody interested in building something
> around an Alpha obviously isn't building a minimal microprocessor.
> 

Why? I have been toying with an alarm clock based on a 21064.
Of course, its main purpose in life is to cause Dec saleks and marketrriods
to throw up. :-)

~Paul

PS Should I put a RS-5?? or an SCI on it? Which has the lower chip count?
Newsgroups: vmsnet.alpha
From: rosenkra@convex.com (William Rosenkranz)
Subject: Re: Convincing the management
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Fri, 22 Jan 1993 23:38:27 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

>In article <1993Jan19.122854.22863@jyu.fi>, HOUGHTON@jylk.jyu.fi (DAVID HOUGHTON, LK) writes:
>	c) SUNs are not the way to go

while SUNs might not be the way to go (SPARC is way behind the RISC curve),
i would put HP up against DEC any day. the PA-7100 chip can easily outperform
the alpha running at a much higher clock speed. considering that an under $50k
HP 735 turns in SPECfp92 of 150 while the $316k DEC 10000 (at 200 MHz) does
only 200 seems like the 21064 is a weak implementation of the basic Alpha
architecture (which does have some interesting aspects). HP is even better
with DP Linpack (40.8 MFLOPS vs the 10000's 42.5 or so). also the 1000x1000
Linpack for alpha is actually lower than HP's (based on DEC's numbers in
the november announcement). this tends to tell me that the tiny on-chip
alpha caches and high latency off-chip cache is weak. also the fact that
I/O busses off the chip run at most half the system clock speed does not
help much either. i would expect a 200 MHz chip to get at least 180 MFLOPS
on 1000x1000 linpack, if it were designed with technical (floating point)
computing in mind. i also think HP has a better graphics story than DEC,
though i am far from an "expert" in graphics.

it really boils down to wanting Unix or VMS, IMHO. since there are lots of
Unix vendors, there is more competition to get continuing improvements in
price, performance, price/performance, features, etc. since only DEC offers
VMS, they don't have as much of a need to continue improvements. while OpenVMS
claims POSIX compliance, i suspect many if not most people will write their
applications with non-POSIX facilities, making it difficult to port to Unix
(on which POSIX is based). and while there are extensions to POSIX on Unix
platforms, it is still generally far easier to port code between real Unix
boxes. i would think that if someone wants a real unix environment, they
would want something other than DEC (OSF/1) since alpha seems pricy for the
real performance you can achieve.

perhaps you should widen your search beyond just Sun and DEC.

just my opinions...

-bill
rosenkra@convex.com

-- 
Bill Rosenkranz            |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp.      |ARPA: rosenkra@convex.com
Newsgroups: vmsnet.alpha
From: michelotto@vaxfpd.pd.infn.it (Michele Michelotto)
Subject: Re: Alpha speed on disk devices
Keywords: FORTRAN,I/O,Alpha
Reply-To: michelot@dxcern.cern.ch
Organization: CERN - European Laboratory for Particle Physics
Date: Tue, 26 Jan 1993 08:11:13 GMT


In article <1jpojvINNin@fnnews.fnal.gov>, kreymer@fnsg01.fnal.gov (Art Kreymer) writes:
|>    There was earlier discussion of I/O problems on some Alpha systems.
|>    Fortran unformatted I/O to disk seems to be somewhat slower than
|>    expected, and, surprisingly, is CPU limited. That is, the CPU is
|>    running at 100% utilization in USER mode while the I/O is in progress.
|>
|>    The I/O problem is almost certainly related to the Fortran Compiler.
|>    Note the following timings, writing a 32,000 block (16 Mbyte) file
|>    composed of records of length 8000 words (32 Kbytes)
|>
|>    Formatted writes and VESTed images use much less CPU than native
|>    unformatted writes. Implied I/O do loops suffer no or negative
|>    overhead.
|>
|>    Elapsed    CPU    Method
|>      15         1.   UNFORMATTED  WRITE (1) DATA  (vested image from VAX)
|>      25.        1.   FORMATTED    WRITE (1,'(A32000)') CDATA
|>      20.       15.   UNFORMATTED  WRITE (1) DATA  (native image)
|>      15.       15.   UNFORMATTED  WRITE (1) (DATA(J),J=1,8000)
|>
|>    Here's the test program:
.. deleted...

There is another strange behaviour: On the VAX you obtain moreless the same
results (in KB/s) if you declare DATA as integer*1(character),integer*2,
integer*4, integer*8;if you do unformatted write. This is normal because
the write are buffered. This happens also with the VESTed images omn the
Alpha.

With native code on the Alpha you obtain very good result with i*8
(and low cpu/elapsed ratio) and very bad result with i*1 (with cpu/elaps
that is close to 1.).

OK. Now I can declare an equivalence of my character buffer with a REAL*16
buffer, I can do all my operation with the character buffer and then do the
I/O with the REAL*16 buffer. I can achieve very good performance but

WHY ON THE VAX I DON'T NEED TO DO THESE TRICKS?
--
						Ciao, Michele
******************************************************************************
* Michele Michelotto, INFN Padova, Delphi group.                             *
* Internet: michelot@dxcern.cern.ch     BITNET: MICHELOTTO@IPDINFN           *
* Tel (+39).49.844347                   HEPNET: VAXFPD::MICHELOTTO           *
*                     "Ho bevuto CHE COSA ?"   (Socrate)                     *
******************************************************************************
Newsgroups: vmsnet.alpha
From: reece@eco.twg.com (Reece R. Pollack)
Subject: Re: User-written device drivers on Alpha/VMS
Reply-To: reece@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Wed, 27 Jan 93 19:58:53 GMT


In article <1993Jan26.125545.1@ssrl01.slac.stanford.edu>, tcox@ssrl01.slac.stanford.edu (Tony Cox - (415)926-3105) writes:
|>A specific concern for me is porting my home grown pseudodriver. On VAX/VMS,
|>this driver processes a series of QIO's from application programs,
|>originally written to control a CAMAC serial highway driver. For compatibility
|>with existing systems, these applications cannot be rewritten. The QIO's
|>come down from the application specifying (in p1-p6) three buffers in 
|>user space. The driver locks these pages in memory, using the usual
|>exe$write/read/modify routines, and then passes the request off to a
|>user-written ACP using EXE$QIOACPPKT.
|>The ACP interprets the information (in this case, generating network requests
|>to uVAXIII systems running VAX/ELN), returns information and status into the
|>buffers in the requesting user process, and then completes the request
|>using COM$POST.
|>
|>So this driver/ACP combination is relatively simple (no hardware access, except
|>via supported network drivers), but it _does_ do some things which I would have
|>thought would require some (possibly extensive) code changes when running on
|>the Alpha.

If you're familiar with designing and implementing this on VAX/VMS, you
shouldn't have too much difficulty porting it to AXP/VMS. At least for
the Stage 1 drivers, the code is quite similar, with mainly such things as
structure member size promotions and physical page size issues to deal with.
I ported a pseudo-driver and ACP combination which sounds pretty similar
to yours a few months ago, and didn't have too much trouble with it.

--
Reece R. Pollack
Senior Software Engineer
The Wollongong Group, Inc.
Newsgroups: vmsnet.alpha,comp.sys.dec
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: No 64-bit OpenVMS soon?
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Sun, 24 Jan 93 19:43:20 GMT


In article <1993Jan22.172623.15644@oracle.pnl.gov>, jordan@warped.pnl.gov (Randy Jordan) writes:
|>|>We take 10 million of them per second.
|>|>
|>	1MB per second?
|>|>
|>|>Even with filtering we take Terabytes of data per month.
|>|>
|>	Wrong...you take in 3.6TB per hour at the rate stated!

Right.. but read what he said.. "with filtering...", ie, he filters the data
and still ends up with terabytes of data..

-Larry.
From: vchow@helios.UUCP (Victor Chow)
Newsgroups: vmsnet.alpha
Subject: (re-posted) cpu time measurement on VMS.
Date: 22 Jan 93 17:29:52 GMT
Organization: Consilium Inc, Mountain View, CA

In article <C164Hn.223@dscomsa.desy.de> you write:
|> In article <1993Jan20.164619.8700@eecs.nwu.edu>, shil@eecs.nwu.edu 
|>   (Lei Shi) writes:
|> 
|> |>
|> |>Hi: 
|> |>  ... My question is how I can measure the total CPU used by the 
|> |> execution of the program ... in VMS ...
|> |>					Your Sincerely,
|> |>
|> |>					Lei Shi
|> 
|> The are various alternatives. The simplest way is to run your program as 
|> a batch job.   ...   Otherwise, you can use
|> the $ SHOW PROC /ACC for an interactive session but that cannot (as far as
|> I am aware) be zeroed before execution of a program. Finally, if this is not
|> sufficient you should investigate the run time library timer routine
|> LIB$SHOW_TIMER, LIB$STAT_TIMER ... (try $ HELP RTL LIB$ *TIMER*.
|> 

Lei Shi,

Using LIB$ or SYS$ calls allow you to get accurate accounting information about
a process the way you want.  The disadvantage is that you have to modify your
source code to do so (and provided that you still have the source code).

Submitting an image to a batch job and get the accounting information from the 
log file should get what you need.  However your LOGIN.COM and the system
SYLOGIN.COM should be relatively short and do not run resource hogging command
s or images (relative to your actual image).  Otherwise the accouting info of
the batch job does not accurately reflect the resources used by your image
only. Remember that a VMS batch job includes not only the images/commands you
want run, but also other commands or images (such as LOGIN.COM and SYLOGIN.COM,
etc) that are executed as part of the batch job.

Another simple alternative that requires no modification to your code and LOGIN/SYLOGIN.COM is to do the following steps:

1. create a file, say, your_image.COM like this:
    $ run your_image.EXE        or (@ your_dcl.COM)
    $ logout/full

2. then at the DCL prompt, enter
    SPAWN @your_image.COM

The SPAWN starts a child process which starts with "zeroed" accounting info to 
run your image and the "logout/full" command.  The "Accounting information" 
that logout/full prints should be very close to what "your_image" needs (plus 
the overhead needed by the SPAWN(?), @your_image.COM, and "logout/full",etc).  
(I assume your program takes a lot more resources to run than a simple SPAWN
command.) 

As long as you are not trying to precisely measure a tiny image that uses very 
little resource and that you don't need to get the process' accounting info at 
different parts of your image, this simple method should be adequate. 

Good luck!  8-)

Victor






Newsgroups: vmsnet.alpha
From: jim@accelr8.com (Jim Reiss)
Subject: Re: Convincing the management
Organization: Accelr8 Technology Corporation
Date: Fri, 22 Jan 1993 18:55:18 GMT

In article <1993Jan21.143909.5254@mksol.dseg.ti.com> pyron@skndiv.dseg.ti.com writes:
>>We are hoping to obtain a DEC 3000/400 AXP but have to convince
>>our management that this is going to be a good buy. There are
>>those amongst us that would rather invest in SUN Microsystems.
>>We already possess a VAX4000 and several SUNs, both systems
>>support SAS/SPSX and a bunch of maths packages for graphics,
>>simulation and optimisation.

>We've used the following arguments:
>  6) If the decision is made to run Unix or OSF, the AXP can.  The SPARC can't
>     run VMS.
No, but there is a VMS library emulation available on Suns from our company,
as well as a DCL interpreter to preserve the same user environment.
>  7) VMS is compliant with all final POSIX specs (and in line with most of the
>     preliminary ones).
But VMS POSIX is slow, at last account.

I know this doesn't help your argument, but I figured some other readers
of this might want to know.
-- 
 Jim Reiss (jim@accelr8.com)    Accelr8 Technology, Denver, Colorado, USA
 Opinions expressed above are mine.  Who else would have them?
Newsgroups: vmsnet.alpha
From: yooho@ursula.ic.cmc.ca (Yoo Ho Cho)
Subject: Operating Systems for Alpha
Organization: Canadian Microelectronics Corporation
Distribution: na
Date: Tue, 26 Jan 1993 19:46:48 GMT

I'd appreciate it if I can get some info on the stablity/availabilty of
 the three OS's for alpha ( VMS, OSF/1, NT ) ?

Thanks
Yoo Ho Cho
Canadian Microelectronics Corporation
Newsgroups: vmsnet.uucp
Subject: Re: DECUS UUCP on Alpha
From: "David L. Cathey" <davidc@montagar.com>
Date: Fri, 22 Jan 93 06:51:11 CDT
Reply-To: synful+vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: The Internet
Return-Path: <synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU>
Errors-To: synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU
X-Vms-Mail-To: vn%"synful+vmsnet@drycas.club.cc.cmu.edu"

>please . What is UUCP ????
>Can you answer  me?

	UUCP stands for Unix-to-Unix Communications Protocol.  It is "network"
software that allows file copies, mail, and Usenet news (such as vmsnet.uucp!)
to be transfered.  Typically, this is done using telephone lines.  The
computers call each other up and pass along any traffic that they may have.

	If you have a direct link to Internet, then you probably don't need
UUCP.  You already have something better!  However, with UUCP, you could allow
other local computers to dial in to your system and pass mail along, and
have your system gateway it to the Internet for them.  There are many sites
in the U.S. that do this.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey		                |INET: davidc@montagar.com
Montagar Software Concepts              |UUCP: ...!montagar!davidc
P. O. Box 260772, Plano TX  75026-0772  |Fone: (214)-618-2117
Newsgroups: vmsnet.uucp
Subject: Re: Ultrix/VMS link needed
From: allebrandi@inland.com (Tom Allebrandi)
Date: 27 Jan 93 21:26:36 CST
Organization: Inland Steel Company; East Chicago, IN

In article <1993Jan20.195937.4780@verifone.com>, jimmy_t@verifone.com writes:
> If I have a VMS and Ultrix machine on the same Ethernet,
> can I configure Decus UUCP to transfer mail back and forth
> between the two systems over Ethernet?  (There is no TCP/IP
> software on the VMS system)

Without putting a whole lot of thought into this...

Are you running LATMonster on your VMS system? (Optional in 5.4, standard
in 5.5) If so, how about creating a LAT forwarding port assigned to a
LAT service offered by the Ultrix system?

Under LATMonster after you create an LTA device using LATCP's CREATE PORT
command, you can assign it to a service by doing

	SET PORT/APPLICATION/NODE=HOST/SERVICE=SERVE

Just a thought.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
From: goathunter@wkuvx1.bitnet
Newsgroups: vmsnet.uucp
Subject: Re: Ultrix/VMS link needed
Date: 22 Jan 93 15:17:25 CDT
Followup-To: vmsnet.uucp
Distribution: world
Organization: Western Kentucky University, Bowling Green, KY

In article <1jnsnpINNq9a@CS.UTK.EDU>, shuford@cs.utk.edu (Richard Shuford) writes:
>
> If you decide to use this, do not use the old-style CMU SMTP; you'll
> have significantly fewer headaches if you use Matt Madison's MX mail
> package with CMU-OpenFriendlyDontWorryBeHappyVMS IP.  MX is available
> from "ftp.spc.edu" by anonymous FTP or by MAILSERV from WKUVX1.BITNET.
> 
Actually, it's FILESERV@WKUVX1.BITNET.  Send the following commands in
the body of a mail message:

SEND MX031
SEND FILESERV_TOOLS

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU)
Newsgroups: vmsnet.uucp
Subject: Re: DECUS UUCP on Alpha
From: allebrandi@inland.com (Tom Allebrandi)
Date: 27 Jan 93 21:19:36 CST
Organization: Inland Steel Company; East Chicago, IN

In article <1993Jan16.145248.1204@cmkrnl.com>, jeh@cmkrnl.com writes:
> In article <1993Jan14.103439.17179@crash>,
>  jav@crash.cts.com (Javier Henderson) writes:
>> Has anyone tried the DECUS UUCP package on Alpha machines yet? We're about
>> to receive our two Alpha boxes, and I plan on install UUCP 2.0 on them.
>
> I'd put this plan on hold if I were you.
>
> I tried VESTing uucico, and the code would not run on an Alpha.  I suspect
> data alignment problems ("word tearing") in the protocol module.

Ditto.

Last Spring we VESTed UUCP_MAILSHR and it wouldn't run either. I think
I know why but I have not had an opportunity to try it since.

I can't make a native image since the current code uses LIB$tparse() which
is not available on OpenVMS/Alpha, and, I don't think that the Pascal
compiler is out yet.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
From: Steve_Cole@forge.uucp (Steve Cole)
Newsgroups: vmsnet.uucp
Subject: Re: uupc, mailers, and news reader FAQ
Date: 26 Jan 93 23:50:10 GMT
Organization: Forge BBS (Student non-profit BBS - No E-mail replies please!)

Re: your post about the FAQ where you requested some info on Amiga UUCP
stuff:

Grn
DLG Pro
TIN
DLGQwk
DUUCP (Dillon's UUCP)
CNet 

are all UUCP stuff... I know there are more but these are the ones I'm
aware of at the moment.  Sorry for not replying email but you can't email
me back...

-- Via DLG Pro v0.995

  Sysop - The Forge BBS (2.3 Gig, 12 lines, CD ROM, Dual 16.8k HSTs, et al)
  ------------------------------
  Dial (613) 544-6448 HST Multiline
  forge.uucp (No e-mail access yet-please do not reply e-mail)
Newsgroups: vmsnet.uucp
Subject: Re: Ultrix/VMS link needed
From: tp@mccall.com (Terry Poot)
Date: Thu, 21 Jan 1993 13:19:35 CST
Reply-To: tp@mccall.com (Terry Poot)
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <1993Jan20.195937.4780@verifone.com>, jimmy_t@verifone.com writes:
>If I have a VMS and Ultrix machine on the same Ethernet,
>can I configure Decus UUCP to transfer mail back and forth
>between the two systems over Ethernet?  (There is no TCP/IP
>software on the VMS system)

I suppose you could write communications software that sent raw packets to
absolute ethernet addresses (i.e. program it at the data link layer) on both
sides, and then hack that into DECUS uucp, if you are so inclined. :-)

>Is there some other solution I should consider?

CMU-TEK TCP/IP (or whatever it's called this week).
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA