HDTenEightyP/NetNews huggingface dataset:
From: force.ssd.lmsc.lockheed.com!marshall (Bob Marshall)
Subject: Re: print que problems
Reply-To: marshall@force.ssd.lmsc.lockheed.com
Organization: LMSC, Sunnyvale, California
Date: Wed, 15 Apr 92 16:53:06 GMT

In article <1992Apr14.145127.450@news2.cis.umn.edu>, mark@cda.mrs.umn.edu (Mark Van Overbeke) writes:
>
>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.

Are you using device control libraries with these queues? That's the first
place I would look. Sounds like someone or something has been messing
with some of your device control modules. Also, check your forms definitions
to see if any of them have been modified to include a /SETUP switch that
you weren't aware of. Who knows, perhaps the Multinet upgrade mucked around,
but I'd sorta doubt it.
=============================================================================
Bob Marshall                     \\     
Lockheed Missiles & Space Co.     \\       "In my occupation
Sunnyvale, CA                      \\       There ain't no vacation
marshall@force.ssd.lmsc.lockheed.com\\      I'm a professional fool"
"I tell the truth 'cept when I lie"  \\
=============================================================================
Newsgroups: vmsnet.networks.tcp-ip.multinet
From: jwmanly@amherst.edu
Subject: Re:  Telnet question
Organization: Amherst College, Amherst, MA.
Date: Thu, 9 Apr 1992 23:21:32 GMT

"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.

- John W. Manly  <JWMANLY@AMHERST.EDU>    System Manager -- Amherst College

P.S.  And I DON'T want to hear about Ehud Gavrons hack to EXE$NAMPID to prevent
      duplicate process names systemwide.  If a user set his process name to,
      say, MULTINET_SERVER while I had the server down, bad things would happen
      when I tried to bring it back up.  (Unlikely, but possible.)
From: honce@rhine.stx.com (Jhon Honce)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: BEEP! Re: BEEP! Re: BEEP! Re: NFS between VMS systems question
Date: 16 Apr 92 00:23:23 GMT
Article-I.D.: TGV.2540174416APR92002323
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: Jhon Honce <honce@rhine.stx.com>


    This is an automatic reply.  Feel free to send additional mail, as only
    this one notice will be generated.

I'm at the IMS retreat for the week of 4/13/1992 to 4/17/1992.

/jwh
jhon honce -- honce@spso.gsfc.nasa.gov
           -- honce@rhine.stx.com

X-Gateway-Source-Info: INTERNET
Date: 08 APR 92 20:41:53 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From: "Ned Freed, Postmaster" <NED@HMCVAX.CLAREMONT.EDU>
X-New-From: WORK_FROM_LINE
Subject: Re: SLIP and Multinet
X-VMS-To: IN%"nathant@yang.earlham.edu"
X-VMS-Cc: IN%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

> One thing that is bothersome is that you can't change the IP addresses
> rebooting (unlike many SLIP packages on other systems).

This statement is incorrect. I configure SLIP interfaces in Multinet all
the time. I almost never set the IP address initially and I often change
the IP address later. I have never had a problem changing the address.

You do have to go through several iterations with MULTINET SET/INTERFACE to
do this. First you have to set the interface /DOWN. Then you change the address
or do whatever else you have to do. Then you set the interface /UP. Finally,
I'm not sure when you have to specify /SLIP_DEVICE, but there are times
when it has to be specified that are not obvious. I usually specify it in
every command just to be on the safe side.

One final trick that everyone should be aware of is to make the change you
want in MULTINET CONFIGURE, write the new configuration to disk, and then
DIFF the START_MULTINET.COM file to find out what changed. I do this all the
time; often as not you can make a change without rebooting. In particular,
this technique will tell you what MULTINET SET/INTERFACE command to use in
most cases. You just surround this command with SET/INTERFACE/DOWN and /UP
and you're set.

				Ned
From: ECF_STBO@JHUVMS.HCF.JHU.EDU (Engelboat Humperdinghy)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: ftp hack
Date: 7 Apr 92 22:24:41 GMT
Article-I.D.: TGV.2160285C07APR92222441
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: Engelboat Humperdinghy <ECF_STBO@JHUVMS.HCF.JHU.EDU>
X-VMS-To: IN%"info-multinet@tgv.com"

Tried to email direct but couldn't...

For what it's worth, CMU-tek can do it and I've done it many times (if I
understand what your trying). The most unfortunate thing about multinet is that
tops-20 stuff that keeps rearing its ugly head. Other than that it's very well
integrated into the vms environment (if that's the worst complaint, think of
how worse it could 
be)... 

-Tom O'Toole

X-Gateway-Source-Info: INTERNET
Date: 14 APR 92 19:37:21 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From:    busma @ TGV.COM (Jeffrey D. Busma)
X-New-From: busma@TGV.COM
Subject: RE: POP3, Eudora and replying to mail messages.
Organization: The INFO-MULTINET Community

From: Brian McKeever <MCKEEVER@VAX2.CSTP.UMKC.EDU>
> 
>Okay, I've got POP3 (Multinet 3.0G) and Eudora (1.2.2) working on my VAX
>(VMS V5.4-3) but we've got a small problem when we try to reply to messages
>sent without using PMDF (4.0).
>
>If I send mail to the individual using Eudora on their Mac with PMDF they
>get a REPLYable address.  If I send a message from one of our LAVC (VMSWS1)
>hosts just specifying the username (PLACE), the message gets to them with a
>from address of "VMSWS1::MCKEEVER", when they REPLY to it, I get a header
>back that looks like this:

When you read your VMS Mail from a POPx client, MultiNet will use the real SMTP
headers if the From: address is of the form IN%, SMTP%..etc.. If the message is 
from VMS MAIL, MN POPx server will create RFC822 From: address, in your example.

	if ( VMSWS1 == sys$node)
		from_address = MCKEEVER@TCPHOST.DOMAIN
	else
		from_address = "VMSWS1::MCKEEVER"@TCPHOST.DOMAIN

You should never see just "VMSWS1::MCKEEVER".

    From:   IN%"place@VAX2.CSTP.UMKC.EDU"
    To:     IN%"'VMSWS1::MCKEEVER'@VAX2.CSTP.UMKC.EDU"
                ^^^^^^^^^^^^^^^^^^

>The message does arrive, but it doesn't look to me like it is a valid
>RFC-822 address.  Any way to keep VMS Mail from sticking the bloody DECnet

Can you reply wih this address?

>nodename in the address?  Any way to avoid VMS Mail altogether by forcing
>every message, whether it is preceded by a IN% or not, to go through PMDF? 
>That's one of the reasons I don't use MM, mail just sent to a username
>never gets to MM.  Have I got something really screwed up?

If you're in a cluster you can set the low bit of the MAIL$SYSTEM_FLAGS logical 
name, I believe that will dump the NODE:: part of the From address line.

I suppose I can make this configurable from the POP side as well for to
strip the NODE:: from the VMS address.
 
  
						Jeff
Date: 11 APR 92 19:31:15 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From: Stephen Tihor <TIHOR@ACFcluster.NYU.EDU>
X-New-From: Stephen Tihor <TIHOR@ACFcluster.NYU.EDU>
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
X-VMS-To: IN%"KASHTAN@TGV.COM"
X-VMS-Cc: IN%"info-vax@sri.com",IN%"info-multinet@tgv.com",IN%"wintcp-l@ubvm"
Organization: The INFO-MULTINET Community

I am also mildly curious as to why TGv choose the reserved area rather than an
Application ACE for the SETUID/SETGID information.

X-Gateway-Source-Info: INTERNET
Date: 08 APR 92 20:41:59 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: RS/6000
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

Wow!  Guess there are more RS/6000s out there than I thought.  I got over
20 responses, and they still keep coming in.  Found out the info that I
needed.  Many thanks to all that replied!

Regards,
-----Stuart
From: schoenzeit@vixvax.mgi.com (Loren Schoenzeit)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: RSHELL LOGNAME: Undefined variable Error
Date: 13 Apr 92 15:57:40 GMT
Article-I.D.: vixvax.1992Apr13.105740.1760
Organization: Management Graphics, Inc.



	I've been trying to use RCP and RSHELL with an SGI 4D/25 with
	IRIX 3.3.1.  BELOW is the error -- any Ideas ??

	$ rshell /user=XXX/password=YYY  node remote_command
	LOGNAME: Undefined variable.

	$ rcp /user=XXX /pass=YYY login.com node::
	%RCP-F-ERROR, From Remote Host: "LOGNAME: Undefined variable."


						Thanks
						-Loren
--------------------------------------------------------------------------
						Loren Schoenzeit
Office:		612-851-6123			
Switch board:	612-854-1220			Management Graphics, Inc
FAX:		612-854-6913			1401 E 79th Street
Internet:	schoenzeit@mgi.com		Bloomington, MN 55425		
--------------------------------------------------------------------------
From: honce@rhine.stx.com (Jhon Honce)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: BEEP! Re: NFS between VMS systems question
Date: 16 Apr 92 00:23:17 GMT
Article-I.D.: TGV.2540174416APR92002317
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From: Jhon Honce <honce@rhine.stx.com>


    This is an automatic reply.  Feel free to send additional mail, as only
    this one notice will be generated.

I'm at the IMS retreat for the week of 4/13/1992 to 4/17/1992.

/jwh
jhon honce -- honce@spso.gsfc.nasa.gov
           -- honce@rhine.stx.com
From: adelman@TGV.COM (Kenneth Adelman)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
Date: 11 Apr 92 21:31:55 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

>> I am also mildly curious as to why TGV choose the reserved area rather than an
>> Application ACE for the SETUID/SETGID information.

    Actually, we don't store these bits in the reserved area of the file
header (defined in the ODS-2 specificiation, section 3.2.5), but rather
in the reserved-to-customer byte of the user-characteristics longword
(defined in the ODS-2 specification, section 3.5.2.14), FCH$L_FILECHAR.

    Application ACEs are definitely not the only nor the best way to store
such "extra" information with a file. Besides being relatively expensive
to read (compared to UCHAR) they aren't preserved by BACKUP/INTERCHANGE.

								Ken
From: smith@mcclb0.med.nyu.edu
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
Date: 11 Apr 92 22:24:42 GMT
Organization: NYU Medical Center, New York, NY 10016, USA

The metafile scheme is fine and clearly works well, but there is a MAJOR 
problem if the little files start chewing up space and headers.  I feel very 
strongly that if a package creates files (like .FDL... things) then it should 
also clean them out if they become orphaned.  We use PacerShare as an 
AppleShare file server on the VAX.  It uses these things too.  Recently we 
ran out of file headers on the disk.  After writing a DCL script to clean out 
the orphans we deleted about 5,500 orpahn files.  This is rediculous.

Please.  If you create files with your file NFS client s/w, please delete 
them again if they are nolonger needed.  The files should be usable from both 
the VAX and the UNIX sides and operations on either platform or another should 
leave the file system lean, mean and efficient.  No excuses.

+----------------------------------------------------------------------------+
|Ross Smith,  Research Computing Resource, Department of Cell Biology, NYU-MC|
|E-Mail:  SMITH@NYUMED.BITNET (BITNET),   SMITH@MCCLB0.MED.NYU.EDU (Internet)|
+----------------------------------------------------------------------------+
X-Gateway-Source-Info: INTERNET
Date: 15 APR 92 00:19:39 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
X-RFC822-From:    OGG@physics.carleton.ca (Michael Ogg, 613-788-2600 x4379)
From: OGG@physics.carleton.ca
Subject: POP3,Eudora and replying to mail messages.
X-Vmsmail-To: SMTP%"info-multinet@tgv.com"
Organization: The INFO-MULTINET Community

> The message does arrive, but it doesn't look to me like it is a valid
> RFC-822 address.  Any way to keep VMS Mail from sticking the bloody DECnet
> nodename in the address?  Any way to avoid VMS Mail altogether by forcing
> every message, whether it is preceded by a IN% or not, to go through PMDF? 
> That's one of the reasons I don't use MM, mail just sent to a username
> never gets to MM.  Have I got something really screwed up?

There is a little known undocumented feature of VMS mail: you can overide VMS
transport with
MAIL> set transport foo%  (undo with set notransport)

e.g. for foo=smtp, mail sent to a local address will have a reply address of
SMTP%"fred", rather than foobar::fred.  However, to send to a remote node, you
still have to use the full syntax, cos (I think) the parser barfs when it sees
something like foo@bar.domain.  I don't run PMDF, so I don't know whether this
will solve your problem.  (Actually, credit where it's due: I learnt about this
"feature" from the MX doc.  Apparently, it's not a recommended practice.)

Mike

  +-------------------------------------------------------------------+
  |  Michael Ogg           |  Internet:  ogg@physics.carleton.ca      |
  |  Dept. of Physics      |  HEPnet:    hepcu::ogg    (19233::ogg)   |
  |  Carleton University   |                                          |
  |  Ottawa, K1S 5B6       |  voice:     (613) 788-2600 ext.4379      |
  |  Canada                |  fax:       (613) 788-4061               |
  +-------------------------------------------------------------------+


Newsgroups: vmsnet.networks.tcp-ip.multinet
From: pyron@skndiv.dseg.ti.com (Dillon Pyron)
Subject: Bit vs Buffered Reapter 
Reply-To: pyron@skndiv.dseg.ti.com
Organization: TI/DSEG VAX Support
Date: Tue, 14 Apr 1992 18:49:32 GMT


Does anyone have experience with bit and or buffered repeaters in largish
networks?  We are experiencing problems with our network and bit repeaters that
go away when we switch to buffered repeaters.  Configuration:

10-15 VAXen (stations to 4000-200)
10 SPARCs
10 DECservers (200s, 300s)
5-6 NCD X-terminals

The VAXen and SPARCs talk to each either via MultiNet and mount each other's
disks.  The VAXen are also in an LaVC.  What we see is network hangs and one or
more VAXen crashing, apparently due to timeouts and data corruption.

Thanks for any leads or info.
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
(214)462-3556 (when I'm here)     |
(214)492-4656 (when I'm home)     | I'd exercise my 2nd Ammendment to protect
pyron@skndiv.dseg.ti.com          | your First.  Would you do the same for me?
From: WHITFILL@meediv.lanl.gov (Jim Whitfill, Los Alamos)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: RE: MM from session mgr window
Date: 10 Apr 92 19:23:24 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: "Jim Whitfill, Los Alamos" <WHITFILL@meediv.lanl.gov>

> Date:    Fri, 10 Apr 92 09:58:08 PDT
> From:     mahan@TGV.COM (Patrick L. Mahan)
> Message-Id: <920410095808.20e00162@TGV.COM>
> Subject: RE: MM from session mgr window
> To:       info-multinet@TGV.COM, whitfill@meediv.lanl.gov
> X-ST-Vmsmail-To: ST%"info-multinet"
> 
> #
> #Has anyone developed a procedure for bringing up MM from a session mgr window
> #like VMSmail is on DECWindows/Motif?
> #
> #I'm talking about something like the MAIL application that comes up from
> #vue$library:vue$mail.com.......
> #
> 
> Jim,
> 
> Here is a very simple one that I just whipped up ;-)
> 
> $!
> $!	Start up MM in a DECterm window
> $!
> $ Create/Term=DECterm/Window=(Title="MM Mail",Icon="MM") MM
> $!
> $ exit
> 
> Patrick L. Mahan
> 
> --- TGV Window Washer ------------------------------- Mahan@TGV.COM ---------
> 
> Waking a person unnecessarily should not be considered  - Lazarus Long
> a capital crime.  For a first offense, that is            From the Notebooks of
> 							  Lazarus Long
> 

I've done that. I'm talking about something a little fancier, not using a
DECterm window. Something with more of the feel of the Mail app that comes
with DECwindows.............
---------------------------------------------------------------------------
Jim A. Whitfill    Mechanical & Electronic Eng. Division     (505) 667-9282
whitfill@meediv.lanl.gov       		     Los Alamos National Laboratory
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Remote printer configuration problem
From: brendan@otago.ac.nz (Brendan Murray, OUCSC)
Date: 8 Apr 92 10:17:56 +1300
Organization: University of Otago, Dunedin, New Zealand

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.

-- 
 Brendan Murray, Systems Manager
 Computing Services Center	        Email:  brendan@otago.ac.nz
 University Of Otago     		Phone:  +64 3 479-8597          
 PO Box 56                      	  FAX:  +64 3 479-8577          
 Dunedin, New Zealand		          PSI:	PSI%0530124000016::brendan  
X-Gateway-Source-Info: INTERNET
Date: 11 APR 92 19:31:13 GMT
Newsgroups: vmsnet.networks.tcp-ip.multinet
X-Return-path: <info-multinet-relay@TGV.COM>
From: Stephen Tihor <TIHOR@ACFcluster.NYU.EDU>
X-New-From: Stephen Tihor <TIHOR@ACFcluster.NYU.EDU>
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
X-VMS-To: IN%"KASHTAN@TGV.COM"
X-VMS-Cc: IN%"info-vax@sri.com",IN%"info-multinet@tgv.com",IN%"wintcp-l@ubvm"
Organization: The INFO-MULTINET Community

Let me just mention one other approach.  Pathworks for VMS (mac) uses  meta
files but stores roughly one per directory with the shared information (and a
separate subdirectory with other resource data in it.)   Nontheless if  the
problem is using up FILE HEADERS then the best fix would bea  meta data file
with all the file information in it for whatever granularity  you want. Of
course that makes the "moving the file and losing the attributes" problem WORSE
but if thats the key issue then do it.



X-Gateway-Source-Info: INTERNET
Date: 09 APR 92 06:32:28 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: Looking for...
Organization: TGV, Incorporated
X-Phone: 408/427-4366 (work); 408/427-4365 (fax)
X-Address: 603 Mission Street; Santa Cruz, CA  95060 (work)

..people using MultiNet with an Auspex or Epoch file server.  We've got a
prospective customer who has a couple of questions for someone running in such
an environment.

Thanks!
-----Stuart
From: nathant@yang.earlham.edu
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: Re: SLIP and Multinet
Date: 13 Apr 92 23:22:17 EST
Organization: Earlham College, Richmond, Indiana

In article <2280012A08APR92204153@TGV.COM>, NED@HMCVAX.CLAREMONT.EDU
(Ned Freed, Postmaster) writes:
>> One thing that is bothersome is that you can't change the IP addresses
>> rebooting (unlike many SLIP packages on other systems).
>
> This statement is incorrect. I configure SLIP interfaces in Multinet all
> the time. I almost never set the IP address initially and I often change
> the IP address later. I have never had a problem changing the address.

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....

I'm running VMS 5.4-2 and Multinet 3.0.
-------------------------------------------------------------------------------
Nathan Treadway    | VAX programmer, Postmaster, | NATHANT@EARLHAM.bitnet
Earlham College    | Apple Student Rep, Comp.    | nathant@yang.earlham.edu
Richmond, IN 47374 | Sci. Tutor, and so on....   | "C^u vi parolas Esperanton?"
From: GREENWOODDE@FEDC06.FED.ORNL.GOV (Dave Greenwood)
Newsgroups: vmsnet.networks.tcp-ip.multinet
Subject: "bad program # 200006" messages
Date: 7 Apr 92 18:14:16 GMT
Organization: The INFO-MULTINET Community
X-Gateway-Source-Info: INTERNET
X-Return-path: <info-multinet-relay@TGV.COM>
X-New-From: GREENWOODDE@FEDC06.FED.ORNL.GOV
X-Vmsmail-To: SMTP%"info-multinet@tgv.com"

We just received a patch for the IBM RS/6000 workstations which reduces - but
not eliminates - the number of "bad program # 200006" error messages generated
when the IBM nfs mounts our VMS disks.  We now get just one error message per
disk, rather than bunches of errors per disk (I guess that's progress ;-).  The
patch is "nfsextfix" and presumably is available from wherever you normally get
your RS/6000 patches.

Dave
--------------
Dave Greenwood                   Internet: Greenwoodde@ORNL.GOV
Oak Ridge National Lab           Bitnet:   Greenwoodde%ORNL.GOV@LBL.BITNET
PO Box 2009, MS 8073             Voicenet: (615) 574-0711
Oak Ridge TN 37831-8073          %STD-W-DISCLAIMER, I don't speak for nobody