HDTenEightyP/NetNews huggingface dataset:
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: RCP timing - why so slow on VAX?
Date: 9 Apr 92 22:08:59 GMT
Article-I.D.: TGV.210000CF09APR92215019
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: adelman@TGV.COM
X-New-From: adelman@TGV.COM

>    We've been doing some basic timing of rcp file transfer between Sun Sparcs
> and VAXstations.  Copying a 32MB file from Sun to VAX takes about 6 minutes
> whereas copying the same file back to the Sun takes a bit less than 3 minutes.
> This is true whether the rcp originates on a VAX or a Sun. (RCPs of this file
> take about 1 minute going between two Suns.)	We've noticed that disk space is
> allocated ahead of the actual transfer, and that the transfer doesn't start
> until 1 or 2 minutes after the rcp command is given.

>    My question is why does it take so long to rcp a file to a VAX?  Is it
> entirely due to preallocation of disk space, or does rcp start up a separate
> process on the VAX even when invoked from that VAX?

    Are you sure you've got that right? I'd expect the SUN->VAX
direction to be faster; the VAX needs to read the file twice before transmitting
it (to get the length in bytes after conversion to the UNIX stream; due
to a braindead RCP protocol it needs to know this before it starts sending
data).

    If you're sure you've got that right, my guess would be that you
have a very fragmented disk and the allocation of space for the file
is taking 1-2 minutes.	This would be consistent with the transfer not
starting for that period of time. How long does it take COPY to copy
a file of that size?

						    Ken
X-Gateway-Source-Info: INTERNET
Date: 16 APR 92 04:24:54 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: C.Chaundy@its.unimelb.EDU.AU
From: C.Chaundy@its.unimelb.EDU.AU
Subject: Problem with NFS mapping escape character ($)
X-Envelope-to: info-multinet@tgv.com
X-VMS-To: IN%"info-multinet@tgv.com"
X-VMS-Cc: IN%"jonathan@ucsvc,pal@ariel"
Organization: The INFO-MULTINET Community

We have found a situation where the use of the NFS mapping escape character
($) causes considerable problems.  We have the VMS documentation CD-ROMs
mounted on our VAXcluster which we wish to NFS-serve to a range of clients,
including Ultrix systems that have Bookreader capability.  The problem is
that because $ is now a legal character in VMS file names, the file names
of various manuals appear on the Ultrix systems as 'blah.decwBOOK' rather
than 'blah.decw$book', and likewise for the 'blah.decwBOOKSHELF', the $
being interpreted as a change-case command.  The Bookreader therefore cannot
find the files referred to in the bookshelf files and the whole thing sort-of
falls down.

Any suggestions?

Chris Chaundy (Technical Manager, Networks)

Information Technology Services, Thomas Cherry Building,
The University of Melbourne, Parkville, Victoria 3052 Australia
Phone:    +61 3 344 7045                Fax:   +61 3 347 4803
Internet: C.Chaundy@its.unimelb.EDU.AU 	(X.121 505233430003)
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re:  RCP times between Suns and VAX/VMS.
Date: 10 Apr 92 01:10:30 GMT
Article-I.D.: TGV.202004E510APR92011030
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: adelman@TGV.COM

> I was just thinking, what about accepting VMS specific qualifiers on the
> "rcp" server like you accept for "rdump".  An /RMS_EXTEND=<blocks> would be
> nice.  That should speed things up.  The RMS defaults are almost always
> tiny.  Transferring a 32MByte file using most systems default values could
> require hundreds (maybe even thousands) of rms extend calls.	On my system
> with a default extent of 100 blocks - which I think is larger than most -
> that would be 640 extensions.  Talk about time consuming!  Yuck.

    ;-) One step ahead of you. RCP knows the file size when it
opens the file, and specifies the correct allocate in the SYS$CREATE
request.

							    Ken

Newsgroups: vmsnet.networks.tcp-ip.multinet
From: cws@ovro.ovro.caltech.edu (Cur Seeliger)
Subject: RCP timing - why so slow on VAX?
News-Software: VAX/VMS VNEWS 1.41    
Organization: California Institute of Technology
Distribution: na
Date: Wed, 8 Apr 1992 17:09:00 GMT

   Folks,

   We've been doing some basic timing of rcp file transfer between Sun Sparcs
and VAXstations.  Copying a 32MB file from Sun to VAX takes about 6 minutes
whereas copying the same file back to the Sun takes a bit less than 3 minutes.
This is true whether the rcp originates on a VAX or a Sun. (RCPs of this file
take about 1 minute going between two Suns.)  We've noticed that disk space is
allocated ahead of the actual transfer, and that the transfer doesn't start
until 1 or 2 minutes after the rcp command is given.

   My question is why does it take so long to rcp a file to a VAX?  Is it
entirely due to preallocation of disk space, or does rcp start up a separate
process on the VAX even when invoked from that VAX?

   Thanks in advance,
	Curt Seeliger
	cws@ovro.caltech.edu
From: MCKEEVER@VAX2.CSTP.UMKC.EDU (Brian McKeever)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re:  RCP times between Suns and VAX/VMS.
Date: 10 Apr 92 01:10:33 GMT
Article-I.D.: TGV.202004E510APR92011033
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: Brian McKeever <MCKEEVER@VAX2.CSTP.UMKC.EDU>
X-Envelope-to: Adelman@TGV.COM, info-multinet@tgv.com
X-VMS-To: IN%"Adelman@TGV.COM"
X-VMS-Cc: IN%"info-multinet@tgv.com"

>> I was just thinking, what about accepting VMS specific qualifiers on the
>> "rcp" server like you accept for "rdump".  An /RMS_EXTEND=<blocks> would be
>> nice.  [...]

>     ;-) One step ahead of you.................................

Only one step Ken?  Why so modest?  ;-)

>     .......................... RCP knows the file size when it
> opens the file, and specifies the correct allocate in the SYS$CREATE
> request.

Or that.  :-}

--Brian
X-Gateway-Source-Info: INTERNET
Date: 08 APR 92 02:30:52 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From: service@tgv.com
X-New-From: service@tgv.com
Subject: Re:  Remote printer configuration problem
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

>Problem:
>I want to print on a queue on a u*x box from my VMS system running multinet.
>But - it doesn't work
>This is what I have done:
>
>
>$ mult conf /print
>MultiNet Remote Printer Configuration Utility 3.0(12)
>[Reading in configuration from MULTINET:REMOTE-PRINTER-QUEUES.COM]
>PRINTER-CONFIG> add print_queue 
>[Adding new configuration entry for queue "PRINT_QUEUE"]
>Destination IP Address: 139.80.64.1
>Protocol Type: [LPD] 
>Remote Queue Name: [lp] lp4
>[PRINT_QUEUE => 139.80.64.1, lp4]
>PRINTER-CONFIG> write
>[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]REMOTE-PRINTER-QUEUES.COM.2]
>PRINTER-CONFIG> exit
>[Configuration not modified, so no update needed]
>$
>$ @multinet:remote-printer-queues
>$
>$ sho queue /full/all print_queue
>Printer queue PRINT_QUEUE, idle, on THORIN::NLP1:"139.80.64.1/lp4", 
>mounted form DEFAULT
>  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /OWNER=[SYSTEM] 
>  /PROCESSOR=MULTINET_LPD_SYMBIONT /PROTECTION=(S:E,O:D,G:R,W:W)
>$
>$ print /notify /queue=print_queue ux.prt
>Job UX (queue PRINT_QUEUE, entry 158) started on PRINT_QUEUE
>$
>Job UX (queue PRINT_QUEUE, entry 158) completed
>%SYSTEM-F-ABORT, abort
>
>Its VMS version 5.5 and the unix in question is Ultrix 4.2 -- though it doesn't
>seem to get as far as the unix box.
>
>Any help would be appreciated.

Some debugging techniques for problems of this sort:

o Do a REPLY /ENABLE=NETWORK /TEMP before issuing the print command.  MultiNet
  reports many of its errors via OPCOM NETWORK class messages.

o Do a MULTINET SHOW /QUEUE=PRINT_QUEUE to see if you can see the remote queue.

o Do a TCPDUMP from a third system (VAXes can't see their own traffic) and see
  what is actually happening between the two systems.  The command will be
  something like:

    MULTINET TCPDUMP /HEX HOST vax-host AND HOST ultrix-host AND PORT PRINTER

Some problems to look for:

o Does your local username match a username on the ULTRIX system?

o Have you verified that the printer name specified in MULTINET CONFIG /PRINT
  is indeed the correct printer name as specified in /etc/printcap?

Drop a note back if you still have any questions or problems.

Regards!
-----Stuart
X-Gateway-Source-Info: INTERNET
Date: 14 APR 92 19:37:25 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From:     adelman (Kenneth Adelman) @ TGV.COM
X-New-From: adelman@TGV.COM
Subject:  Re: Connections in a CLOSING state
Organization: The INFO-MULTINET Community

> After our system has been up for a while, I find MultiNet connections in
> a CLOSING state when doing a MULTINET SHOW.  These never seem to go away by
> themselves (until a reboot).	Is there a way to get rid of these
> connections?

> They are (almost?) always from PCs on our campus net that are running CUTCP
> telnet to connect to the VAX.  I suspect that the cause of the problem is
> that the PC exits from the network too quickly, before the VAX has finished
> sending everything to the PC that it wants to.  I say this because the
> entries in MULTINET SHOW that are in a CLOSING state also have non-zero
> values in the Snd-Q column.

> We have recently converted from Wollongong to MultiNet and had this problem
> show up there, too.  They were unable to provide a means to get rid of the
> hanging connections.

    CLOSING means that we've sent a FIN packet to the other side, it has
responded with a FIN, but it isn't acknowedging our FIN. We'll stay in this
state indefinitely retransmiting the FIN (and the data in the Send-Q)
waiting for an ACK or a RST.  I think you're right about the problem
with the PC; it stops running TCP/IP after sending its FIN and
receiving an ACK, and it isn't around to ACK our FIN.  These
connections should clear themselves the next time the PC runs TCP/IP.

    I wouldn't worry about them, they only consume 256 bytes of memory
and send a packet very occasionally.  If they bother you, I'd try a
PC product which doesn't exit before the other side has time to close down
the connection.

								Ken
From: mcmahon@TGV.COM
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Seeking...
Date: 15 Apr 92 20:21:59 GMT
Article-I.D.: TGV.254014A315APR92202159
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' McMahon)

I would like to talk to any customers who have the following configuration...

Using our NFS client software on 20+ VAXen (Multiple VAXclusters perhaps), and 
connecting to the same UNIX (SunOS perhaps) NFS Server.

The usual bribe of a TGV T-shirt applies to those who answer :-)

Cheers!
John

X-Gateway-Source-Info: INTERNET
Date: 15 APR 92 08:21:12 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: SLIP and Multinet
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

>I stand corrected on this fact.  I'd like to be corrected on other on: it
>seems that one is not able to change the speed of a  static SLIP line without
>rebooting.  I tried  MULTINET SET/INTERFACE sl0/DOWN command and then SET TERM
>but the terminal is still configured a network device.  I even tried bringing
>the slip device back up on another line, but the orginal one remained a network
>device and wouldn't let me change the speed....

Under MultiNet V3.0, do a:

	MULTINET SET /INTERFACE SL0 /DOWN /SLIP_DEVICE=TTxx:

Under V3.1, it'll be:

	MULTINET SET /INTERFACE SL0 /DOWN /VMS_DEVICE=TTxx:

You need the /SLIP_DEVICE and/or /VMS_DEVICE to turn it back to a terminal
device.

Regards,
-----Stuart

X-Gateway-Source-Info: INTERNET
From: P_TANNENBAUM@ACC.HAVERFORD.EDU (Balthazar Still)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Logs of Telnet and FTP?
Date: 7 Apr 92 18:14:20 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: Balthazar Still <P_TANNENBAUM@ACC.HAVERFORD.EDU>
X-Envelope-to: info-multinet@tgv.com
X-VMS-To: IN%"info-multinet@tgv.com"

Hello.  We are running a vanilla copy of MultitNet 3.0 rev H.  (It works
very well, thank you.)

Is there any log kept of outgoing Telnet and FTP sessions?  We were trying
to see if we could tell to which machine someone was Telnetting at a 
particular time.

If this is not set in the vanilla package, is there a way to turn it on?

Thanks for any help.

Peter Tannenbaum
System and Network Manager
Haverford College
p_tannenbaum@acc.haverford.edu
From: TIHOR@ACFcluster.NYU.EDU (Stephen Tihor)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
Date: 12 Apr 92 01:32:24 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: Stephen Tihor <TIHOR@ACFcluster.NYU.EDU>
X-VMS-To: IN%"smith@mcclb0.med.nyu.edu"
X-VMS-Cc: IN%"info-multinet@tgv.com"

Lets say that it would be a desirable feature in BOTH NFS client and server to
be able to automatically walk the file tree and clean up orphans when reqested
as part of the mount operation or when triggered by an external request such as
from NFSCONTROL.   The Pathworks (Mac) model of a mount point option for the 
degree of checking to be done is a nice idea.
X-Gateway-Source-Info: INTERNET
Date: 13 APR 92 17:34:24 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From: RBECK@VAX1.dseg.ti.com (I haven't lost my mind...It's backed up on tape somewhere!)
X-New-From: RBECK@VAX1.dseg.ti.com
Subject: RE:  TGV NFS Client vs TWG NFS Client
X-Vmsmail-To: SMTP%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

Gentlemen,
I have found the comparisons between the TWG and TGV implementations of NFS 
Clients to be rather informative.  We have been using the MultiNet NFS Client 
software for the last two years now and I have some comments from a 
CUSTOMER's perspective.

	1) In our environment, we WILL run out of file inodes before
	   we fill the disk.  We have an Epoch Infinite Storage Fileserver
	   mounted to our VAX system.  The main application that uses
	   this connection has already stored 111,484 files in one
	   directory.  Approximately 75% of these files are meta-files
	   that correspond to their respective data files.  I fully
	   expect to one day to have the "big headache" of restructuring
	   this partition.  However, we normally follow the 5-P rule:

		Proper Planning Prevents P--- Poor Performance!

	   We fully tested the NFS Client software prior to use in
	   a production environment and were aware of all aspects 
	   involved, including the initial filesystem sizes.  TGV 
	   was very cooperative with requests for evaluation
	   software and technical expertise during our evaluations.

	2) We have had a few occasions when we were required to restore
	   files from backups.  Although our operations staff is very
	   efficient, the meta-files were somehow neglected when the
	   data files were retrieved.  Copying and renaming existing
	   meta-files brought us back up and running in seconds rather
	   than the hours needed to perform another restore (8mm are
	   rather slow!).

	3) Even if the system ran like a dog and had problems every
	   other day, I wouldn't trade the service I've received from
	   the "TGV Crew".  I can't begin to tell you how secure it
	   makes me feel knowing that whenever I call I'm talking to
	   the engineers of the product, not some customer service 
	   person who's paging through the same manual I am.  On more
	   than one occasion they have been able to help me correct
	   a problem in a timely manner.  And believe me, when your
	   design engineers can't access their data, not only do 
	   they get rather testy but you're losing real dollars!

I guess what it really boils down to is, if the product resolves the 
requirements you have to your satisfaction then use it.  If it falls short, 
then find something else.  So far TGV and MultiNet have far exceeded the 
requirements we had for use of that product.

A satisfied user!

Ron Beck				rbeck@mcopn2.dseg.ti.com
Member, Group Technical Staff		If you don't know where you're going
Texas Instruments			How do you know when you're there?
McKinney, TX

X-Gateway-Source-Info: INTERNET
Date: 08 APR 92 20:42:38 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From: "L. Stuart Vance" <VANCE@TGV.COM>
X-New-From: WORK_FROM_LINE
Subject: Re:  Telnet question
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

>Is there a way for a common user like me to check and see where a specific
>process is telnet(ing) to?  

Do a MULTINET SHOW /CONNECTIONS=PROCESS (or MU SH/CONN=PR).  It'll correlate
local process names with local and remote IP addresses and port numbers.

Regards,
-----Stuart
From: georgetl@cnsvax.uwec.edu
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Telnet question
Date: 7 Apr 92 15:44:55 -0600
Organization: University of Wisconsin Eau Claire

Is there a way for a common user like me to check and see where a specific
process is telnet(ing) to?  
 
                                              Thanks
                                               Todd
From: oberman@ptavv.llnl.gov
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
Date: 9 Apr 92 21:03:07 GMT

In article <2280012A08APR92204201@TGV.COM>, D.Nash@utexas.edu (Donald L. Nash) writes:
> David,
> 
> I really think you went too easy on Reece.  You really shouldn't feel so 
> inhibited about reducing someone's arguments to shreds.
> 
> :-)

What? Where? How? I saw Stuart's original challenge and Reece's follow-ups, but
I have not seen anything new from David or any of the TGV folk. Did I miss
something fun?

Actually, I could have shredded several of his arguments myself without knowing
too much about NFS innerds (sp?). I just don't want to miss out on anything
good.

Maybe some things are not making it through the USENET gateway.

R. Kevin Oberman			Lawrence Livermore National Laboratory
Internet: oberman1@llnl.gov		(510) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
X-Gateway-Source-Info: INTERNET
Date: 10 APR 92 07:16:10 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From:     adelman (Kenneth Adelman) @ TGV.COM
X-New-From: adelman@TGV.COM
Subject:  Re:  Telnet question
Organization: The INFO-MULTINET Community

> "L. Stuart Vance" <VANCE@TGV.COM> writes:
> >>Is there a way for a common user like me to check and see where a specific
> >>process is telnet(ing) to?
>>
>> Do a MULTINET SHOW/CONNECTIONS=PROCESS (or MU SH/CONN=PR).  It'll correlate
>> local process names with local and remote IP addresses and port numbers.

> However, I feel compelled to point out once again that this is nowhere near as
> useful as it could be.  If two of my users (in different groups, of course)
> have the same process name, there is no way to tell which of them is the one
> with the Internet connection.  If only, he said while casting an eye towards
> the folks at TGV, the MU SH/CONN=PR would include the PID, you could correlate
> real processes instead of just process names.

    The problem is one of synchronization -- the output of MULTINET
SHOW just isn't reliable enough to machine-parse and we wouldn't want
to encourage it.  Like "netstat" under UNIX, MULTINET SHOW reads the
kernel connection routing tables by going into kernel mode and
emulating a "/dev/kmem".  Like under UNIX, there is no synchronization
with this table, and if the connection table changes during the
display you'll get garbled output.  To get an accurate picture of the
connection table would require blocking a lot of network activity
during the table copy, and I think this solution would be worse than
the problem.

							Ken
From: mcmahon@TGV.COM
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: RE: Finger information...
Date: 14 Apr 92 22:11:32 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' McMahon)

>Where does the multinet command "finger" keep the information seen in the
>personal name field when you do a finger? Can I as a non-privileged user have
>access to that info?

It is stored in the System User Authorization File.

A user can grab the information by using the $GETUAI system service.  Privs are 
required to get someone elses information.

John McMahon
TGV Tech Support
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: print que problems
Date: 14 Apr 92 21:38:10 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: adelman@TGV.COM

>   Over the last couple of weeks, we have had some problems with print
> queues.  It all seemed to start when I upgraded from V2.2 of Multinet to
> V3.0-H and moved the queue file from one place to another.  I don't know
> if the upgrade of Multinet caused the problem, or if moving the queue
> file caused the problem, but it started after those two events.  Here is
> the problem:

> We have a number of distinct print queues pointing to the same device.
> This device just happens to be a B300(can you say dinosaur?).  We use
> this printer to print a number of different types of forms.  We also
> have one print queue for each type of form.  Some of the queues are
> supposed to be set up with the default action being nofeed when the job
> starts or is done.  All jobs submitted to those queues are submitted
> with /nofeed.  Up until the upgrade/move, this worked correctly and the
> printing started immediately when the printer was put online.  Now when
> we switch queues to print the special forms, we get a page eject before
> the printing starts.	On normal 11 inch paper, this is not a problem.
> On labels and 3x5 cards and such, this is a real mess since a page eject
> does not necessarily mean that the printer will line up at the top of
> one of the cards or labels.  I have tried retrieving the queue file
> previous to the date that I did the upgrade/move.  I still have the same
> problem with this queue file.  I also created a new queue file and got
> the same result.  I am starting to believe that it is not a problem with
> the queue file.  I am getting ready to look a replacing prtsmb and
> smbsrvshr with copies from before the upgrade/move and see if that fixes
> the problems.  Other than that, I am at a loss as to what to try next.
> Anyone out there got any ideas that might help?  Thanks.

    MultiNet V2.2 had a bug where the VMS symbiont would send a FF
at the end of a job and we didn't correctly pass it to the network. This
was fixed in V3.0 Rev E. I don't believe there is any way to suppress this,
but the behavior is the same as the VMS symbiont's behavior.

								Ken