HDTenEightyP/NetNews huggingface dataset:
From: jarnold@tixel.mv.com (Jon Arnold)
Newsgroups: vmsnet.employment
Subject: Job Wanted: ALL-IN-1 / VMS / Tech Skills
Distribution: world
Date: Mon, 14 Dec 92 15:23:47 GMT
Organization: 
Reply-To: jarnold@tixel.mv.com

I am looking for a job, either full time or short/long term contracting
position; 11 years of experience with Digital Equipment Corp, almost
20 total years in the computer industry.  Specific skills include:

   *  ALL-IN-1 development, applications programming, internals.
   *  Familiarity with most VMS layered software products.
   *  Extensive knowledge of VAX/VMS operating system.
   *  Experience in determining user needs, defining requirements.
   *  Knowledgeable on PC's (MS/DOS), some Windows experience.
   *  Fluent in Cobol, PL/1, Basic.
   *  Working knowledge of Pascal, Bliss, Macro, Fortran.
   *  Teaching experience in computer technical subjects/software.
   *  Project leader/manager experience in a variety of projects.
   *  Industry experience in a wide variety of industries.
   *  Experience in creation of and response to RFP's/RFQ's.
   *  Excellent verbal and written communications skills.
   *  Technical evaluations of complimentary solutions; hardware & software.
   *  Relationship management with external companies and third-party
      marketing partners.
   *  Able to comfortably do effective presentations to a wide variety of
      audience types, from highly technical to high-level management.

If you have or know of a position opening where these skills would be a
match, please do not hesitate to contact me; weekdays 603-883-1233, fax
603-883-7350, home telephone 603-595-0365, home fax 603-883-6371.  I
would be more than happy to fax or mail you a complete copy of my resume
and a reference letter.

Jon Arnold                        Phone: W: 603-883-1233
Nashua, New Hampshire                    H: 603-595-0365
                                  Fax:   W: 603-883-7350
                                         H: 603-883-6371
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: porting Unix code to Wollongong
Date: 16 Dec 1992 22:59:26 GMT
Organization: University of Oregon Network Services
Distribution: world
NNTP-Posting-Host: duff.uoregon.edu

I'm in the process of porting some moderately complex Unix networking
code to Wollongong, and would like to solicit some advice from the
community.  My problem is with netread(), netwrite(), and netclose().

The code I'm working with makes the assumption that local fds (generated
by VAXC open()) and remote sockets (generated by Wollongong socket())
can be treated equivalently.  For instance, there are library
routines that accept either and (sometimes after several levels of
subroutine) call read() or write() to perform the I/O.  What's the
best way to port such code?

My options seem to be (1) to duplicate the library routines, and have the
high level routines call the net- version of the library if appropriate,
(2) [almost equivalent] add flag parameters or global variables to
communicate whether a particular int refers to a VAXC fd or a TWG socket,
or (3) to decide in the low level routine what a particular int refers to.
What's my best bet?  

In particular, is there any reliable way to distinguish between a fd and a
socket?  I notice that VAXC, like most Unixes, returns small sequential
ints for fds; Wollongong appears to return user memory addresses, e.g.
280, 284, etc., so a gross check on value would appear to be possible.

By the way, I have the same questions as the above for Multinet.  UCX
presumably is not a problem in this regard.

-- 
JQ Johnson				Office: 250E Computing Center
Director of Network Services		Internet: jqj@ns.uoregon.edu
Computing Center, Univ. of Oregon	voice:	(503) 346-1746
Eugene, OR  97403-1212			fax: (503) 346-4397
Newsgroups: vmsnet.networks.tcp-ip.wintcp
Subject: Re: porting Unix code to Wollongong
From: fxmlk@acad3.alaska.edu (KIENENBERGER MIKE L)
Date: Thu, 17 Dec 1992 05:04:00 GMT
Organization: University of Alaska - Fairbanks
News-Software: VAX/VMS VNEWS 1.41.UAC

In article <16DEC199220230646@acad3.alaska.edu>,
I wrote...

Bunch of stuff saying how to simulate a select() in Wollongong.

when the original question never really asked about that :)

Err....

Well, it's useful information anyway :)

Sorta got hung up on my own problem.

Back to the original question.
I guess I'd just take the easy way out, and save a flag indicating
how to access the channel for each opened channel.  It keeps the overhead low
and simple.  Of course, if you come up with a nice general routine, I'll
be glad to incorporate it into any of my code :)

=============================================================================
-Mike Kienenberger                       FXMLK@ALASKA           (BITNet)
 Academic Computing                      FXMLK@acad3.alaska.edu (Internet)
 University of Alaska-Fairbanks
 "I'm a computer programmer....<link><link><kludge><kludge> say-no-more!"
From: chall@eco.twg.com (Charles Don Hall)
Subject: Re: Name service for printers using tcpsymb
Organization: The Wollongong Group (East Coast Operations)
Distribution: na
Date: Tue, 15 Dec 92 21:16:29 GMT

In <WINTCP-L%92120310300683@UBVM.CC.BUFFALO.EDU> TIM BIDDLE <7210BIDDLE@INDY.NAVY.MIL> writes:

>Does anyone know of a way to use name service with the tcpsymb print symbiont
>instead of hard coding the address for the printer into a logical?

>At present, we use the following:

>$ define/system 720b_address "129.1.3.128!513"
>[...]

>I would like to get away from the logical, and use the name server to resolve
>the address of the printer.  If you can't do it with this configuration, what
>configuration would work?

As TCPSYMB exists now, you have to use the logical name in the format
you've shown. 

It would be possible to rewrite TCPSYMB so that it didn't rely on
the logical name...presumably, it would get the IP address and port
number by doing "gethostbyname" and "getprotobyname" calls on the
queuename. I don't think this is a good idea, though, because the
information would get spread out too much. The IP address would be
stored on the nameserver host, and the port number would be stored
in the "PROTOCOLS" file on the local host, and the other TCPSYMB
configuration options would still be specified as logical names.
This is much less convenient than the current setup, which allows
all the relevant information to be stored in one section of the
system-wide startup procedure.

I'm not sure what your objection is to the current mechanism. If
it's simply that you'd rather use an ASCII hostname as opposed to a
numeric IP address, then we could keep the logical name, but allow
a wider choice of formats. For example,
    $ DEFINE/SYS 720B_ADDRESS "b720!513"
(Where b720 is known to the nameserver), or even:
    $ DEFINE/SYS 720B_ADDRESS "b720!rlogin"
(Since 513 is the port associated with the "rlogin" protocol)

TCPSYMB doesn't currently support these formats, but it would
be a fairly easy modification. Let me know if you're interested 
in pursuing this.

>Tim Biddle
>System Administrator
>Naval Air Warfare Center Aircraft Division, Indianapolis
>7210biddle@indy.navy.mil
-- 

===========================================================
Charles Don Hall, Licensed Philosopher  (chall@eco.twg.com)
===========================================================
Newsgroups: vmsnet.networks.tcp-ip.wintcp
From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: porting Unix code to Wollongong
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Thu, 17 Dec 92 16:00:19 GMT


In article <1gocceINN124@pith.uoregon.edu>, jqj@duff.uoregon.edu (JQ
Johnson) writes:
|>Path:
|
eco.twg.com!uunet!usc!rpi!usenet.coe.montana.edu!news.u.washington.edu!n
news.uoregon.edu!duff.uoregon.edu!jqj
|>From: jqj@duff.uoregon.edu (JQ Johnson)
|>Newsgroups: vmsnet.networks.tcp-ip.wintcp
|>Subject: porting Unix code to Wollongong
|>Date: 16 Dec 1992 22:59:26 GMT
|>Organization: University of Oregon Network Services
|>Lines: 31
|>Distribution: world
|>Message-ID: <1gocceINN124@pith.uoregon.edu>
|>NNTP-Posting-Host: duff.uoregon.edu
|>
|>I'm in the process of porting some moderately complex Unix networking
|>code to Wollongong, and would like to solicit some advice from the
|>community.  My problem is with netread(), netwrite(), and netclose().
|>
|>The code I'm working with makes the assumption that local fds
|>(generated
|>by VAXC open()) and remote sockets (generated by Wollongong socket())
|>can be treated equivalently.  For instance, there are library
|>routines that accept either and (sometimes after several levels of
|>subroutine) call read() or write() to perform the I/O.  What's the
|>best way to port such code?
|>
|>My options seem to be (1) to duplicate the library routines, and have
|>the
|>high level routines call the net- version of the library if
|>appropriate,
|>(2) [almost equivalent] add flag parameters or global variables to
|>communicate whether a particular int refers to a VAXC fd or a TWG
|>socket,
|>or (3) to decide in the low level routine what a particular int refers
|>to.
|>What's my best bet?  
|>
|>In particular, is there any reliable way to distinguish between a fd
|>and a
|>socket?  I notice that VAXC, like most Unixes, returns small
|>sequential
|>ints for fds; Wollongong appears to return user memory addresses,
|>e.g.
|>280, 284, etc., so a gross check on value would appear to be
|>possible.
|>
|>By the way, I have the same questions as the above for Multinet.  UCX
|>presumably is not a problem in this regard.
|>
|>-- 
|>JQ Johnson				Office: 250E Computing Center
|>Director of Network Services		Internet: jqj@ns.uoregon.edu
|>Computing Center, Univ. of Oregon	voice:	(503) 346-1746
|>Eugene, OR  97403-1212			fax: (503) 346-4397
|>
JQ,
	You might try one of two approaches.. the most clean approach is to
get our UCX emulation and just use the C RTL.. This is coming out with our
new release of PathWay for VMS... but given you don't want to wait for an
upgrade you might want to try doing a MSG_PEEK QIO (IO$_RECEIVE) on a potential
FD prior for every operation and if you receive the SS$_BADPARAM error.. assume that you 
have a FD and use the C RTL otherwise assume that you have a socket 
and follow those rules.. You will pay a performance penalty.. but it
should give you a fairly simple port. ie, write your own read(), write() and
close() functions which either call netread() or real read()..

-Larry.
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: CMUTEK is dead, long live CMU-OPENVMS-IP
From: Marc Shannon <synful@drycas.club.cc.cmu.edu>
Date: Sun, 13 Dec 1992 17:29 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
X-Vms-To: IN%"CMU-OpenVMS-IP@DRYCAS.CLUB.CC.CMU.EDU"

>Unless you have put on Copyrights more restrictive than the MIT X-Window
>style, any group that wanted to take the code and distribute a modified
>work could come up with any good name they chose.
>
>Has CMU intended to prevent that?

In fact, CMU would like to have the "CMU" part of the name removed on any
subsequent releases.  It was just my thought that renaming it to, say, DECUS
TCP/IP might cause confusion with users regarding compatability between the two
packages.

--Marc
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: <None>
From: Syon Bhattacharya <syon+@cmu.edu>
Date: Tue, 15 Dec 1992 17:10:30 -0500 (EST)
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Sun opening X-window display on VAX running DECWINDOWS
From: bgoldstein@omni:.dna_node.jplsp1.span (Bruce Goldstein, (818) 354-7366)
Date: Mon, 14 Dec 92 18:47:11 -0800
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
X-MX-Warning: Warning -- Invalid "From" header.
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

Recent message from Jim Garrigues, c/o Dave Zurliene asked about
opening Decwindow display on a VAX.  The display security has to be
set appropriately (the * * * will allow anyone to open a window).
Also, the VAX has to know about the transport.  In sys$startup
directory you will find the file DECW$PRIVATE_SERVER_SETUP.TEMPLATE
copy the TEMPLATE file to DECW$PRIVATE_SERVER_SETUP.COM.  Then,
within the .com file uncomment the line for decw_servers and add
cmu, i.e,
decw$server_transports == "DECNET,LOCAL,CMU"

This seems to work for a while.  When it fails something has gone wrong
with CMUTEK and it is necessary to restart CMUTEK.

P.S. You have to reboot the VAX after creating the above command procedure.
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Transmitting Data IO$_WriteVBlk questions
From: <scholten@woodstock.si.com>
Date: Tue, 15 Dec 1992 18:14:26 -0500 (EST)
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Content-Type: text
X-Mailer: ELM [version 2.4 PL13]
Content-Length: 331

>
> Yes indeed it Concatonates, and splits packets as needed.  The data
> needs to contain the information that is needed to keep the packets separate.
>
> You can prevent most of this by using the push option on SEND.
> 	John Clement
> 	Rice University
>
>
>

How is the push option enforced?  I'm using qiow() calls.

Dave

Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: poncelet@smr.slb.com (Paul Poncelet - SFM - (33)-1-4746-7117)
Subject: Pathworks TCP/IP on VAX with CMU/TEK
Reply-To: poncelet@smr.slb.com
Organization: SMR Montrouge, France.
Date: Fri, 18 Dec 92 11:47:06 GMT

We have the CMU/TEK TCP/IP package running on our VAX cluster. We are  running
Pathworks for VMS with DECnet, without problem. We wished to try out the TCP/IP
option of Pathworks and installed the files on the server without problem. 

The problem is that the NBNS TCP Netbios process crashes upon startup claiming
it can't find the hostname. DEC's answer is to use their UCX product as the
TCP/IP layer. Does anyone else have experience of getting Pathworks TCP/IP to
work with products other than UCX?


Thanks for any help you can provide


Paul Poncelet
Systems Manager
Sedco Forex Schlumberger
Montrouge
France

e-mail: poncelet@sfm.sinet.slb.com
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: New Name
From: <nord@chemvax.princeton.edu>
Date: Thu, 17 Dec 1992 13:29:10 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

For many years now I've found the CMUTEK package to be:

Cheap Multipurpose Unassuming     software
                   Unpretentious
                   Unequivocally [Good]
                   Untroublesome
                   Useful
                   .
                   .
                   .


    Dan
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: Calling a command procedure from a WKS logical ???
From: Mighty Firebreather <dragon@nscvax.princeton.edu>
Date: Thu, 17 Dec 1992 09:31:57 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: Chris@csvax1.ucc.ie
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

	Chris Higgins <chris@csvax1.ucc.ie> writes:
>
>I have an application that I want to hang as a server off a WKS port. My
>problem is that it uses CLD definitons to get it's defaults. When it is
>called by CMU it seems to be executed as a process without an attached CLI.
>This means that it can't find it's defaults, and terminates without doing
>anything.
>        Is there anyway I can have a CLI associated with the invocation of
>the application. Failing that can I call a command procedure and have it
>call my application....
>
>The application by the way is a Finger Server, so I need the response to be
>fast....
>

	The usual technique here is to run SYS$SYSTEM:LOGINOUT.EXE and
specify its input to be a command file that runs your application.
LOGINOUT.EXE maps DCL into P1 space for the created process.  This works
quite well for spawning a process from code that you write.  I've never
tried to do anything like this using CMU-etc and I can't say the technique
is applicable but it's worth trying.


*************************************************************************
*                                                                       *
*                        Here, there be dragons!                        *
*                      dragon@nscvax.princeton.edu                      *
*                                                                       *
*                                                Richard B. Gilbert     *
*************************************************************************
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Re: Transmitting Data IO$_WriteVBlk questions
From: "John Clement-Rice U. (713)527-8101x2037" <clement@physics.rice.edu>
Date: 16 Dec 92 00:28:00 CST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

When using qiow calls, you can find the macros in cmutek_src:[central]network.
This is "suggested" by setting P4 to 1, as you can see from the following
extract.  This may not be obeyed, but it will help.
! NET$SEND - Send data over the network



    NET$SEND(
	LC_ID,			! OBSOLETE, UNUSED Local Connection ID.
	BufAdrs,		! Data buffer address
	BufSize,		! Buffer Size in bytes.
	Tag,			! OBSOLETE, UNUSED request identifier tag.
	Urgent=0,		! NYI Urgent data boolean
	EOL=0,			! EOL (PUSH) boolean.
	Addr_Spec=0,		! IP adrss for UDP, ICMP, and IP (address)
	IOmode=Synch,		! Asynchronous or synchronous
	IOchan,			! I/O channel
	IO$SB,			! I/O Status blk (quadword)
	Ast$Adr=0,		! Adrs of AST service rtn.
	Ast$Prm=0,		! AST parameter.
	EF=0			! Event Flag #.
	) =

	CHKOBS(LC_ID,'LC_ID','NET$SEND')
	CHKOBS(TAG,'TAG','NET$SEND')

	$$QIO(IOMODE) (
	    CHAN	= IOchan,
	    IOSB	= IO$SB,
	    Func	= IP$Send,
	    ASTADR	= Ast$Adr,
	    ASTPRM	= Ast$Prm,
	    EFN		= EF,
	    P1		= BufAdrs,
	    P2		= BufSize,
	    P4		= EOL,
	    P5		= Urgent,
	    P6		= Addr_Spec
	    )
    %,
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: How about some help
From: "Tim McKee, 803-366-2620" <mckeetr@cvse.cortex.prospect.com>
Date: Thu, 17 Dec 1992 17:25:50 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

I have RTFM, but I can't find any specifics regarding
the DEV-SPECIFIC field in the DEVICE_INIT field of
INET$CONFIG for SLIP connections.

I am trying to make it work and getting nowhere...

Has anyone got any information on this?  I have tried
setting the field to 0.0.0.0 but the machines won't
talk.  (I have tried PC<->VAX and VAX<->VAX.)

Thanks


================================================================================
Timothy R. McKee                        |  Senior Consultant - VAX/VMS Internals
Cortex Corp. - SouthEast Field Office   |       mckeetr@cvse.cortex.prospect.com
Phone: (803) 366-2620                   |                    FAX: (803) 366-5417
================================================================================
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Transmitting Data IO$_WriteVBlk questions
From: <scholten@woodstock.si.com>
Date: Mon, 14 Dec 1992 18:05:28 -0500 (EST)
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu
Content-Type: text
X-Mailer: ELM [version 2.4 PL13]
Content-Length: 502

Can anyone tell me if the WriteVBlk drivers will concat packets that are
sent if they are too small.  I'm having this rather interesting problem.
When I call a QIOW to send out the data, it appears that the low level
routines are concatting three of these writes before sending out the data.

I know that it may split of the packets before sending them out. But will
it also concat before being sent out?  If this is true, it is not very
clear in the documentation.

Thanks for the help,
Dave Scholten
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: unsuscribe
From: "Jonathan E. Hardis" <hardis@garnet.nist.gov>
Date: Fri, 18 Dec 1992 17:23:20 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: hardis@garnet.nist.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

>> unsuscribe
>> will it work this time!!!

> 	I don't know how this list is managed, but some lists use a program
> to handle requests.

Alas, this list no longer uses MX
(Received: from DRYCAS.CLUB.CC.CMU.EDU by DRYCAS.CLUB.CC.CMU.EDU (PMDF #11060))
List management is done by hand.

The host even uses Multinet, not C**/T** TCP/IP.
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: Mailing address rewriting
From: <bmv@mapp.atc.sp.paramax.com>
Date: Wed, 16 Dec 92 16:55:09 CST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

I just got a copy of the message I wrote to CMU-OpenVMS-IP wherein my mail
address was rewritten to:
	 bmv@mapp.atc.SP.Paramax.COM (Barry M. Vornbrock)

In my experience
	 jersey!charon!bmv@orbit.orb.mn.org
works and the ...Paramax.COM does NOT work.

I am assuming that my address is being rewritten by one of the mailers between
me and thee.  All hints and/or suggestions for resolving this would be greatly
appreciated.

Until then, I shall really be...

Barry M. Vornbrock			jersey!charon!bmv@orbit.orb.mn.org
MAPPCOR
1111 Third Avenue South
MINNEAPOLIS MN 55410     (USnail-net)	(612)341-4604 (AT&T-Net)
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
From: vindvad@imf.unit.no (Hans Vindvad)
Subject: Problems: VMS v.4.5 and cmutex v 6.3
Organization: The Norwegian Institute of Technology, Trondheim, Norway.
Distribution: vmsnet
Date: 16 Dec 92 06:36:58

We are trying to install cmutex v 6.3 on a microvax running vms 4.5.
but cmnutex don't seem to get any contact.

internet.log contains a lot of messages of this type:
07:13:37.25 XE device 00000001 offline (xmit)

and show dev says that XQA0 is online.

Do anybody have any tips.

Please respond by email to:
vindvad@imf.unit.no
Newsgroups: vmsnet.networks.tcp-ip.cmu-tek
Subject: RE: From CMU-OpenVMS-IP === to ===> TIP.
From: "Henry W. Miller" <henrym@sacto.mp.usbr.gov>
Date: Fri, 18 Dec 1992 21:12:31 EST
Reply-To: CMU-OpenVMS-IP@drycas.club.cc.cmu.edu
Organization: The Internet
Return-Path: <@andrew.cmu.edu:CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu@mccall.com>
CC: henrym@sacto.mp.usbr.gov
Errors-To: CMU-OpenVMS-IP-Request@drycas.club.cc.cmu.edu

Karl,
	I can dig it.

-HWM
----------
Henry W. Miller  (Old network dude)
Assistant Systems and Network Manager
U.S. Bureau of Reclamation
Mid Pacific Region
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS - Same as commercial
Inet:	"henrym@sacto.mp.usbr.gov"

"I've fallen, and I can't get up!"