HDTenEightyP/NetNews huggingface dataset:
From: larry@flash.eco.twg.com (Lawrence B. Henry III)
Subject: Re: DEC TCP/IP Services for VMS V2.0
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Fri, 21 Aug 92 22:04:11 GMT


In article <1992Aug20.211321.13218@wl.com>, duffiem@wl.com (Mark
Duffield) writes:
|>Newsgroups: vmsnet.networks.tcp-ip.ucx
|>Path: eco.twg.com!uunet!caen!vela!pd-dom!duffiem
|>From: duffiem@wl.com (Mark Duffield)
|>Subject: Re: DEC TCP/IP Services for VMS V2.0
|>Message-ID: <1992Aug20.211321.13218@wl.com>
|>Organization: Warner Lambert / Parke-Davis
|>References: <1992Aug10.180351.27239@raven.alaska.edu>
|><1992Aug11.082627.827@galaxy.gov.bc.ca>
|><1992Aug17.111422.13270@rz.uni-karlsruhe.de>
|>Date: Thu, 20 Aug 1992 21:13:21 GMT
|>Lines: 32
|>
|>In article <1992Aug17.111422.13270@rz.uni-karlsruhe.de>
|>ONASCH@IRAV17.ira.uka.de (Bernd Onasch) writes:
|>>[...]
|>># It *should* be.  I just heard yesterday that the product has
|>finally been
|>>[...]
|>>
|>>It is now released. (I have one here)
|>>
|>
|>I have mine too.  Still no NFS Client services though.
|>
|>>Nice features, that DEC told all the FT time to be not in the pack:
|>>
|>>* LPD/LPRM/LPQ are really in the pack...
|>>* TRACEROUTE (SYSPRV or OPER required)
|>>* SNMP (now working :-)
|>>
|>>After looking through the docs, there seem to be many small
|>differences
|>>between the FT and the final distribution. I don't know yet, how it
|>>affects non-DEC programs but i'll have to test...
|>>
|>>Greetings, Bernd Onasch
|>>
|>
|>Anyone installed this puppy yet?  I haven't had time.  This has its
|>advantages.
|>Now someone else can run into the brick walls for me.  Any
|>comments/observations
|>would be appreciated (by me and the net).
|>
|>-- 
|>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|>~~~~~
|> Mark J. Duffield          |   "Being proactive must mean that you
|>have 
|> Parke Davis Biotechnology |    nothing better to do with your time."
|> (duffiem@wl.com)          |                     -- Mark Duffield
|>

If you need NFS Client for UCX you should contact us (Wollongong).. 
We announced that our ClientNFS product supports the UCX transport sometime 
in June. For more information on this you can send e-mail to SALES@TWG.COM.

-Larry.
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: JONESD@kcgl1.eng.ohio-state.edu (David Jones)
Subject: Re: DEC TCP/IP Services for VMS V2.0
Organization: The Ohio State University
Date: Fri, 21 Aug 1992 14:07:10 GMT

I just installed 2.0.  I haven't played with many of the new features
yet.  Some observations:

  - The telnet client seems to be improved.  Telnet connections to the
    our Cray now work.

  - If during the installation you tell it you don't want to configure
    SMTP (we use PMDF), startup generates some complaint about SMTP.
    I haven't tracked that down yet.

  - UCX$CONFIG makes you re-enter the name servers used by the BIND resolver,
    have your list ready.

  - The FTP utility still goes out of its way to screw up the file ownership
    of created files.  The file creations explicitly set ownership to the
    user's UIC instead of the ODS2 default, so files copied to resource
    identifier owned directories don't get owned by the identifier.  I was
    able to patch the FTP client to work right, but I'm still working on the
    server side (UCX$FTPC).



David L. Jones               |      Phone:    (614) 292-6929
Ohio State Unviversity       |      Internet:
1971 Neil Ave. Rm. 406       |               jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210           |               jones-d@eng.ohio-state.edu

Disclaimer: A repudiation of a claim.
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Announcing ruptime/rwho/rwhod for VMS with UCX TCP/IP
Date: 22 Aug 92 03:54:21 GMT
Organization: St. Peter's College, US

In article <1992Aug21.133201.14921@rz.uni-karlsruhe.de>, ONASCH@IRAV17.ira.uka.de (Bernd Onasch) writes:
> Second - bug fix :-)
> 
> In ruptime.c and in rwho.c are checks for file existencies that seem to
> be handled different by some VMS versions.

  How very odd - that code was from part of VMS C-Kermit work, and nobody
has complained about it. I'll implement your change to both the rwho and
C-Kermit distributions tomorrow.

  Can you tell me what version of VMS you saw this behavior with?

	Terry
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Will V2.0 support slip?
Date: 19 Aug 92 17:31:45 GMT
Organization: Mitech Corporation, Concord MA

Does anybody know if VERSION 2.0 is going to support SLIP?

Newsgroups: vmsnet.networks.tcp-ip.ucx
From: duffiem@wl.com (Mark Duffield)
Subject: Re: DEC TCP/IP Services for VMS V2.0
Organization: Warner Lambert / Parke-Davis
Date: Thu, 20 Aug 1992 21:13:21 GMT

In article <1992Aug17.111422.13270@rz.uni-karlsruhe.de> ONASCH@IRAV17.ira.uka.de (Bernd Onasch) writes:
>[...]
># It *should* be.  I just heard yesterday that the product has finally been
>[...]
>
>It is now released. (I have one here)
>

I have mine too.  Still no NFS Client services though.

>Nice features, that DEC told all the FT time to be not in the pack:
>
>* LPD/LPRM/LPQ are really in the pack...
>* TRACEROUTE (SYSPRV or OPER required)
>* SNMP (now working :-)
>
>After looking through the docs, there seem to be many small differences
>between the FT and the final distribution. I don't know yet, how it
>affects non-DEC programs but i'll have to test...
>
>Greetings, Bernd Onasch
>

Anyone installed this puppy yet?  I haven't had time.  This has its advantages.
Now someone else can run into the brick walls for me.  Any comments/observations
would be appreciated (by me and the net).

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Mark J. Duffield          |   "Being proactive must mean that you have 
 Parke Davis Biotechnology |    nothing better to do with your time."
 (duffiem@wl.com)          |                     -- Mark Duffield
Newsgroups: vmsnet.networks.tcp-ip.ucx
From: mchenry@BAEPV2.NCSU.EDU (MCHENRY@BAE.NCSU.EDU)
Subject: Telnet Trouble
Reply-To: mchenry@BAEPV2.NCSU.EDU (MCHENRY@BAE.NCSU.EDU)
Organization: North Carolina State University
Date: Thu, 20 Aug 1992 14:59:27 GMT


20-AUG-1992 10:51:05.87
 
Hello:

We are running UCX 1.3a on VMS 5.4-3 and are having intermittent
Telnet problems. 

The problem is that users who open telnet sessions to VMS from
ULTRIX suddenly lose all of their telnet connections with a
"Remote host closed connection". The wierd part is that the
VMS sessions remain active even after connection is lost. This
appears to happen when the user opens multiple telnet sessions.

Does anyone recognise this problem? It does not appear to me related
the maximum telnet sessions parameter. Also, is there a way to more
descriptive telnet errors? 

                                          Thanks in Advance
    
                                          Kevin R. McHenry
                                          Computer Systems Administrator
                                          N. C. State University
From: MyTH@ssg.ltn.dec.com (M. T. Hollinger)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Will V2.0 support slip?
Date: 20 Aug 92 21:35:27 GMT
Organization: Digital Equipment Corporation, Littleton, MA

Sorry; I know of no supported or documented way to integrate your own
transports or drivers into UCX V2.0.  Naturally, a UCX system will
happily communicate across a SLIP line if you use something else (such
as a dedicated router or a UNIX system doing routing) at each end of the
line to provide the connectivity.  In that case, you'd hook the UCX
system to the "something else" via Ethernet, and the something would
look just like any other IP router.

         - MyTH
From: ONASCH@IRAV17.ira.uka.de (Bernd Onasch)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: How to obtain data from an existing UCX device
Date: 19 Aug 92 20:04:19 GMT
Organization: University of Karlsruhe (FRG)
X-News-Reader: VMS NEWS 1.24

Hello,

I want to get the connection data from existing connections.
(device, local port, remote port)

As documented I have just to do the following:
* sys$assign on the device _BGxxx:
* sys$qio (...,io$_sensemode,...)
* sys$dassgn

But I do not want that the deassign removes the connection - as it does
here... Please just tell me where i'm wrong or send me a sample program
that does the job.

I have here: UCX 2.0, VMS 5.5-1

Thanks and greetings, Bernd Onasch
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.networks.tcp-ip.ucx
Subject: Re: Will V2.0 support slip?
Date: 20 Aug 92 10:57:11 GMT
Organization: Mitech Corporation, Concord MA

In article <1992Aug20.043832.28622@nntpd.lkg.dec.com>, MyTH@ssg.ltn.dec.com (M. T. Hollinger) writes:
> No, SLIP support was not added for V2.0.
> 
>          - MyTH

Does UCX have a dynamic-loading TRANSPORT layer/driver, so that a SLIP
driver can be added by the user?


X-Gateway-Source-Info: INTERNET
Date: 18 AUG 92 20:09:40 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "W. Todd Wipke" <wipke@SECS.UCSC.EDU>
From: "W. Todd Wipke" <wipke@SECS.UCSC.EDU>
Subject: routing NNTP traffic                                            
Organization: The INFO-MULTINET Community

BULLETIN provides a news reader that will work if you have one node that
knows tcpip and a vax cluster, using decnet to get to the node that has
the access to the news server.  MX can do the same thing for mail, incoming
and outgoing.
Todd Wipke
UCSC Chemistry
From: RABINOWITZ@bear.com (Ari Rabinowitz)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: SMTP from other cluster members
Date: 13 Aug 92 15:37:19 GMT
Organization: Bear Stearns & Co.
X-News-Reader: VMS NEWS 1.20

In <2380E13312AUG92233452@TGV.COM> adelman@TGV.COM writes:

> > We have only one node here that runs Multinet.  Recently, this node
> > : MAIL> mail
> > : To:     vax01::smtp%"user@unix.machine"

>     This is the only option.  The mail flag indicates whether or not
> your cluster is homogenous; i.e., whether or not the nodes need to go
> over DECnet to reach each other.  If you aren't running MultiNet on all
> of the nodes, then your cluster isn't homogenous. There is no way to
> tell VMSmail that your cluster is "somewhat homogenous".

I beg to differ, Ken, but there is a way to do it.  If you specify the
to address as __vax01::smtp%"user@unix.machine" (note the TWO
underscores), it will force the mail to be sent to vax01, even in an
otherwise homogenous cluster.  We have used this in our cluster, where
we only have JNet and the Profs% transport on one machine in our
cluster.

It isn't elegant, but it is simple and it works.

Ari


Ari Rabinowitz                  rabinowitz@bear.com for VMS and personal mail
WorkStation Administrator	ari@bear.com for sun/HP Un*x mail
Bear Stearns
X-Gateway-Source-Info: INTERNET
Date: 21 AUG 92 03:23:30 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "L. Stuart Vance" <VANCE@TGV.COM>
From: "L. Stuart Vance" <VANCE@TGV.COM>
Subject: Re:  Multinet NFS Client to a DEC StorageServer-100
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

>Does anyone have any experience,  either good or bad,  with using a Multinet
>NFS client to a DEC StorageServer-100??  If so,  I'd appreciate hearing about
>it.  I'd also appreciate hearing either good or bad things about the
>StorageServer or alternatives as well.

DEC did have a copy of the NFS Client and did some testing against the
StorageServer several months before the product shipped.  They indicated
that it worked just fine!  We have a number of customers using Epoch file
servers as well.

Regards,
-----Stuart
From: adelman@TGV.COM
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: vaxcluster sharing of Multinet configurations
Date: 19 Aug 92 18:17:20 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM

> What is the recommended procedure if one wants to make a vaxcluster
> have identical MU configs for NFS on all nodes (for example by pointing
> to the same definition file for nfs-group and uid,gid etc)?

    The NFS.CONFIGURATION file is by default in the VAXcluster common
directory. If you want different configurations, but the file in
the specific directory.

								Ken
From: ewilts@galaxy.gov.bc.ca (Ed Wilts)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: What does an account need for the NFS Server to work?
Date: 14 Aug 92 07:25:59 -0700
Reply-To: EWILTS@GALAXY.GOV.BC.CA
Organization: BC Systems Corporation

In article <2380F6CA14AUG92054312@TGV.COM>, adelman@TGV.COM writes:
>> I am attempting to set up the NFS server on our Vax to allow access
>> from a group of suns.  The sun users do not now have accounts on our
>> vaxes, and we don't want them to have accounts.  We do, however, have to
>> create accounts so that the NFS server can map their UID/GID's to a
>> valid UIC on our Vax.  We are doing this by creating dummy accounts on
>> the Vax, and I want to know what these dummy accounts need in order to
>> allow the NFS server to work.
> 
>     Yes, it will. Even easier is that you can set it /FLAGS=DISUSER.
> The only fields the NFS Server looks at are username, UIC, and
> default privs.

I consider this a bug Ken.  An account that is flagged as DISUSER should be
unusable.

-- 

Ed Wilts, BC Systems Corp., 4000 Seymour Place, Victoria, B.C., Canada, V8X 4S8
EWilts@Galaxy.Gov.BC.CA   |   Ed.Wilts@BCSystems.Gov.BC.CA   |   (604) 389-3430
X-Gateway-Source-Info: INTERNET
Date: 18 AUG 92 20:09:44 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "W. Todd Wipke" <wipke@SECS.UCSC.EDU>
From: "W. Todd Wipke" <wipke@SECS.UCSC.EDU>
Subject: NFS VMS client as file server?                                  
Organization: The INFO-MULTINET Community

We have a group of Ultrix workstations and another vaxclustered group of
vms workstations.  I am wondering if it is possible for one node in the
vaxcluster to nfsmount a filestructure that sits on Ultrix machine and then
because that vaxcluster node is a disk server, serve the file structure to
the rest of the vaxcluster (local area) without running NFS clients on every
other node in the vaxcluster.
    
We are hoping to have one set of source code for our development projects
that is available to both vms and ultrix via NFS.  What are the gottcha's?
Anyone doing this?  

We are using Vaxset software engineering tools in development on the vax and
hope that the Decset tools will let us do the same thing on Ultrix.  It is
probably too much to hope for that both could use the same code libraries.

Any voices of experience welcome.

Todd Wipke
Molecular Engineering Laboratory
Chemistry
UCSC
wipke@secs.ucsc.edu
From: adelman@TGV.COM
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: vaxcluster sharing of Multinet configurations
Date: 19 Aug 92 22:19:11 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM

> >> What is the recommended procedure if one wants to make a vaxcluster
> >> have identical MU configs for NFS on all nodes (for example by pointing
> >> to the same definition file for nfs-group and uid,gid etc)?
> >
>>    The NFS.CONFIGURATION file is by default in the VAXcluster common
> >directory. If you want different configurations, but the file in
> >the specific directory.
> >
>>								 Ken
> Understand, but I have four separate bootnodes, i.e., four different
> sys$common:[multinet] areas in one homogeneous cluster.  Other key files
> like sysuaf, queus, proxies, etc reside on a cluster common quorum disk.
> Is there a logical that I could direct to such a disk, or simply append
> that disk to the multinet_root definition and move the nfs.configuration
> file to the common disk.  that way, if I want node specific I can put it
> in the specific area, if boot specific in the sys$common area, if cluster
> wide put it in the cluster$common area.  For fault tolerant computing one
> will have more than one boot node and come across this problem.

    I can't think of any problems if you changed the logical names
in this fashion, other than that you'd need to manually maintain the
START_MULTINET.COM file and the MultiNet installation and CONFIGURE.COM
tools wouldn't understand the directory structure. Once installed and
running I know of no reasons it wouldn't work; let me know if it does.

							Ken
X-Gateway-Source-Info: INTERNET
Date: 18 AUG 92 18:08:37 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    busma @ TGV.COM (Jeffrey D. Busma)
From: busma@TGV.COM
Subject: RE: Maximum mail messages under POP3
Organization: The INFO-MULTINET Community

 
>We are using the POP3 protocol from a Mac and can't seem to read more than 50
>messages at a time from the VAX.  Is there a parameter I can set somewhere to
>increase the number of messages the POP3 server will deliver?  As I understand
>it, it is a problem on the VAX end, not the MAC (for a change).

 
	What version of MultiNet are you running?

	There was a problem fixed in 3.0 Rev H for accounts that had a lot of mail or low
	PGFILQUOTA. Anyways, we do suggest upgrading to 3.1.

								Jeff
	ps. If by chance you are running 3.1 , please open a support call by sending mail 
	to SERVICE@TGV.COM, please include a copy of the POP3_SERVER.LOG file in the users 
	default directory.
	
X-Gateway-Source-Info: INTERNET
Date: 13 AUG 92 23:41:31 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    PACK@UARS.ACD.UCAR.EDU (Daniel Packman (303) 497-1427)
From: PACK@UARS.ACD.UCAR.EDU
Subject: ucx bind to nfs: devices
X-Vmsmail-To: SMTP%"info-multinet@TGV.COM"
Organization: The INFO-MULTINET Community


Has anyone tried to do a ucx bind to nfs devices?
I have tried to do a ucx bind to such a device which seems to
succeed (no error messages) but within posix I cd to this
directory and find apparently no files.

Under VMS5.5-1 and multinet 3.0H I do

$ ucx bind nfs7: "/v"
$ucx sho bind
 
Logical filesystem                      Pathname
ACDURS$DKA400:                          /cdrom
_ACDURS$DKA300:[POSIX$CONT]             /cont
ACDURS$DKA100:                          /dka100
ACDURS$DKA200:                          /dka200
_NFS7:                                  /v
ACDURS$DKA300:                          /vms 

$ posix
psx> mount
_ACDURS$DKA300:[POSIX$CONT] on /cont 
ACDURS$DKA300: on /vms 
ACDURS$DKA100: on /dka100 
ACDURS$DKA400: on /cdrom 
ACDURS$DKA200: on /dka200 
_NFS7: on /v 
psx> cd /v
psx> ls
psx>
From: mcmahon@TGV.COM
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: ftp'ing tgv.com
Date: 14 Aug 92 09:50:28 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    mcmahon @ TGV.COM (John 'Fast-Eddie/FuzzFace' McMahon)

Reply-To: mcmahon@tgv.com


In article <2380F6CA14AUG92054315@TGV.COM> you write:
=
=I am new to Multinet, so forgive if this is a FAQ.

We don't have an FAQ list, although we will probably need one one of
these days.  I'd volunteer, but I'm having trouble putting together
the last FAQ I volunteered to write :-)

=I see what appears
=to be updates for v3.0*, is 3.1b avialiable?  I have 3.1a...I like to
=stay current.

MultiNet patch kits are stored on TGV.COM, with the following filename
format:

	ECO-<start><finish><version number>.A

So ECO-AB031.A is the V3.1 upgrade from Rev A to Rev B.  It's in the
directory right now.  The V3.0 stuff is in the [.MULTINET-V30] sub-
directory.

All of our public domain stuff was moved recently to PUBLIC.TGV.COM.

=I also see what appear to be DEC patches at TGV.COM, are those things
=to be concerned about??

They are (mostly) Ethernet driver patch kits.  The problems they fix
aren't subtle.  Typically if you call in for support and need the
patch kit quick (and you don't have DSNLINK) we recommend pulling
them from there.

--
John 'Fast-Eddie' McMahon    ()
TGV, Incorporated            () "Any networking problem can be solved by
603 Mission Street           ()  the application of 33 miles of Unshielded 
Santa Cruz, California 95060 ()  Twisted Pair (UTP)"   
408-427-4366 or 800-TGV-3440 ()                      [InterOp Spring 1992]
E-Mail: MCMAHON@TGV.COM      ()
X-Gateway-Source-Info: INTERNET
Date: 18 AUG 92 16:08:08 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: "Joe Dillon, IU - PU at Fort Wayne, DP Dept."
From: "Joe Dillon, IU - PU at Fort Wayne, DP Dept."
Subject: FROM: headers inaccurate
Organization: The INFO-MULTINET Community

I need help in solving a mailing problem.  We have an IBM bringing in BITnet.
Our VAXCluster accepts IBM's BITnet with Jnet.  The VAXCluster also runs
Multinet.  We have Novell networks running CC:Mail.  CC:Mail's product, 
SMTPLINK, is running on a Sun to link VMSMail and CC:Mail.  (I liken this to 
a triangle with one side open - Novell to IBM) MX has been installed recently 
to smoothly link forwarded accounts.  At that time Multinet's SMTP server was
disabled.

The problem:  FROM: headers are being stripped on forwarded accounts only if
the account names involved in the forwarding are the same.  (i.e. VAX account,
Dillon, is set to forward to CC:Mail account, Dillon.  Someone, lets say Bush,
sends mail to VAX account Dillon, CC:Mail account Dillon sees it as coming 
from VAX-Dillon, not Bush)
What works is VAX-dummy set to forward to CC:Mail-Dillon, Bush sends same 
message in the same way.  CC:Mail-Dillon sees it as from Bush and sees 
VAX-Dillon was involved too.

Any clues?  What's wrong with this setup?  Who's stripping and why?
================================================================================
/    Joseph H. Dillon
/    Computing and Data Processing Services
/    Indiana-Purdue University
/    Fort Wayne, Indiana 46805-1499
/    Dillon@Cvax.IPFW.Indiana.Edu
================================================================================
X-Gateway-Source-Info: INTERNET
Date: 18 AUG 92 22:11:11 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:     adelman (Kenneth Adelman) @ TGV.COM
From: adelman@TGV.COM
Subject:  Re: Multinet 3.1 Finger                                             
Organization: The INFO-MULTINET Community

> The new finger program gives every process in the vaxcluster instead
> of the main logins, and it doesn't give idle time etc.  its cute, but
> the first time I fingered the vax cluster from a unix node, the delay was
> so great I thought the network was down.  Since SHOW USERS/FULL gives the
> same information for vms, there isn't much need for this expanded feature
> IMHO.  If we want the old finger display can we use the 3.0 image with
> version 3.1 of Multinet? or is there a logical that changes FINGER behavior?

$ finger/nocluster

						    Ken

X-Gateway-Source-Info: INTERNET