HDTenEightyP/NetNews huggingface dataset:
From: gdha@se.alcbel.be (Gratien D'haese)
Newsgroups: alcbel.list.pmdf,vmsnet.mail.pmdf,mail.info-pmdf
Subject: Remote DECnet nodes using PMDF
Date: 29 Jul 92 12:15:42 GMT
Reply-To: gdha@se.alcbel.be
Followup-To: alcbel.list.pmdf
Organization: Alcatel Bell, Antwerpen, Belgium
Originator: root@ge-dab.GE.COM
Content-Transfer-Encoding: 7BIT
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
X-Vms-To: IN%"alcbel-list-pmdf@alcbel.UUCP"
Resent-Message-Id: <01GMXVI481YA9GVYTZ@YMIR.CLAREMONT.EDU>
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-To: <infopmdf@ge-dab.ge.com>
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Resent-Date: Wed, 29 Jul 1992 08:15:42 -0400


 
 
On the VMS system BTGV78  PMDF is running, and a remote VMS system, e.g. BTGV48
is using PMDF remotely (via the logical IN -> BTGV78::IN%).
Now the problem is that I want BTGV48 be renamed to "ee2", so that all mails
which are send from these VMS systems are treated as they were send from
the local system (ee2), in this case BTGV78.
Now the destiny user sees as sender something like "user@BTGV48.alcbel.be".
The ".alcbel.be" is appended by our SUN backbone. What I want to see is
simply "user@ee2.alcbel.be". This will NOT cause any problem for a reply,
because on system "ee2" (=BTGV78) all users are know through aliases.
I included the configuration file, althought, I skipped some rewrite rules of
local machines.
--------------------------------------------------------------------
! PMDF.CNF - PMDF configuration file for ee2.
! Written by SYSTEM, 13-APR-1992 18:06
! This file was created by the PMDF configuration generator.
!
! Rewrite rules for the local host/cluster
!
! Mailserver is BTGV78 (VAX/VMS)
BTGV78                                  $U@ee2
BTGV78.ee2                              $U@ee2
BTGV48					$U@ee2
BTGV48.ee2				$U@ee2
!....skipped over a lot
btkp42					$U@btkp12
btkp42.ee2				$U@btkp12
ee2                                     $U@ee2
alcbel					$U%$H@UTCP-DAEMON
!
! Rewrite rules for the D (MAIL-11) channel
!
btgv48                                  $U@btgv48
btmvg9                                  $U@btmvg9
!
! Rewrite rules for TCP/IP domain literals
!
[138.203.224.52]                        $U@ee2
[]                                      $U%[$L]@UTCP-DAEMON
!
! Match all rule (send unknown addresses to the backbone "alcbel")
! All internet addresses will go to the backbone.
!
					$U%$H@alcbel
 
l nox_env_to
ee2
 
d 733 nox_env_to
DECNET-MAIL
btgv48                                  btgv48
btmvg9                                  btmvg9
 
utcp_local single_sys smtp nox_env_to nomx logging
UTCP-DAEMON
btkp12					BTKP12
 
utcp_gateway smtp daemon router
alcbel
 
 
Many regards, Gratien
--
  _______ 		Gratien D'haese    Switching Systems Division  se121
  \     /Alcatel			  F. Wellesplein 1, B-2018 Antwerpen
   \   /  Bell		e-mail: gdha@se.alcbel.be    Phone: (32) 3 240 94 51
    \/ Telephone		gdha@alcbel.be 	     Fax:   (32) 3 240 99 50
From: ned@sigurd.innosoft.com (Ned Freed (Postmaster))
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Repeating messages on info-pmdf list
Date: 22 Jul 92 16:25:50 GMT
Organization: The Internet
Resent-Date: 22 Jul 1992 08:25:50 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMO88A9TIA9GV8NB@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"C.Chaundy@its.unimelb.EDU.AU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

The problem was caused by disk errors on ymir.claremont.edu. It should
be fixed now.

				Ned
From: jeremy@vsm.com.au (Jeremy Begg)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Request for minor changes to installation procedure
Date: 25 Jul 92 21:15:14 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 25 Jul 1992 15:15:14 -0600 (CST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMRUSL8AOY9GVM1O@YMIR.CLAREMONT.EDU>
X-Vms-To: in%"info-pmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

From Ned:
>The proper approach is to put these things collectively into a site-specific
>startup file. This file should then be run immediately after PMDF_STARTUP is
>run. This eliminates the possibility that these settings will be lost after an
>upgrade. It also eliminates the possibility that we'll lose your changes, and
>it eliminates the need to scan the old startup looking for changes.

So how about built-in support for something like SYS$STARTUP:PMDF_SYSTARTUP.COM?

Regards,

        Jeremy Begg

  +----------------------------------------------------------+
  | VSM Software Services,  |  E-Mail:  jeremy@vsm.com.au    |
  | P.O.Box 801, Unley,     |   Phone:  +61 8 4145074 (pager)|
  | South Australia 5061    |     FAX:  +61 8 3734911        |
  +----------------------------------------------------------+
From: ned@sigurd.innosoft.com (Ned Freed (Postmaster))
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Postmaster notification for held msgs
Date: 28 Jul 92 22:01:18 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Jul 1992 15:01:18 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMWZR46PNM9GVWP1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

When PMDF puts messages on hold because of detected loops no messages are
sent to notify anyone about it. In addition, the message return job does not
"see" these messages and does not act on them in any way.

I think the reasons for not generating mail when mail loops have been detected
are pretty obvious. If you want to do this yourself it is trivial to write
a DCL procedure that runs once a day and does it. I would never recommend
using such a scheme, however -- my experience has been that mail loops on
postmaster addresses are far more common than on any other sort of address.

The preferred approach is to write something that checks for held messages
and notifies the appropriate people using something other than mail. This is
axiomatically outside of the realm of PMDF to implement, so we don't
provide any mechanism for doing it. Given the fact that a single line of
DCL suffices to check to see if any messages are on hold, there doesn't seem
to be much infrastructure outside of the notification process to provide in
any case.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Repeating messages on info-pmdf list
From: c.chaundy@its.unimelb.edu.au
Date: 22 Jul 1992 17:24:48 +1000
Organization: The Internet
Resent-Date: 22 Jul 1992 17:24:48 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMNRFSHJDU9GV97R@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Is everyone suffering repeated messages on the info-pmdf list (about
four fairly recent ones) or is this a local Australian distribution
problem?

Regards, Chris Chaundy
From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: What to do about .HELD messages
Date: 29 Jul 92 18:52:50 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 29 Jul 1992 11:52:50 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMY7K505TE9GVWPS@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"JLW@PSULIAS.BITNET"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Moon-Phase: 0% (0% = New; 100% = Full)
Age-Of-Moon: 29 days, 12 hours, 9 minutes
Moon'S-Distance: 363893 kilometers, 57.1 Earth radii
Moon-Subtends: 0.5473 degrees (32'50.3")
Sun'S-Distance: 151871123 kilometers, 1.015 astronomical units
Sun-Subtends: 0.5252 degrees (31'30.5")
Last-New-Moon: 29 Jul 1992 19:36:05 +0000 (UT) (Lunation 861)
First-Quarter: 5 Aug 1992 10:59:31 +0000 (UT)
Full-Moon: 13 Aug 1992 10:28:56 +0000 (UT)
Last-Quarter: 21 Aug 1992 10:03:24 +0000 (UT)
Next-New-Moon: 28 Aug 1992 02:42:43 +0000 (UT) (Lunation 862)

> I won't be installing v4.1 for a while yet; is this kind of procedural
> information in the system manager's guide for v4.1, or do I have to keep
> this mailgram around (which I'm going to do, anyway, in case the answer is
> no)?  This is a fine example of a clear, concise *how to get out of this mess*
> procedure which as a system manager for PMDF I really need to have, and if it
> isn't in the system manager's guide, it really ought to be....Thanks, Dan.

The new Maintenance and Troubleshooting chapter (Chapter 15) of the PMDF V4.1
System Manager's Guide includes a section (Section 15.3.9) dealing with
*.HELD messages.  The information I supplied complements that presented in
15.3.9.  I plan to merge the two in the 4.2 manual.

This new chapter, written by Kevin, is something we should have done years
ago (but aren't Fruit-of-the-day: headers more important? ;-).  Any suggestions
for additional sections in it are welcome (as are suggestion of any sort).

Dan
From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: FAQ?
Date: 22 Jul 92 18:25:00 GMT
Organization: The Internet
Resent-Date: 22 Jul 1992 10:25 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMOCEM30VM9GVAZE@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"JSTAFFORD@VAX2.Winona.MSUS.EDU"
X-Vms-Cc: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Pardon if this is a FAQ, but is there an archive of this list?

Anonymous FTP to ymir.claremont.edu ([.mailserv.files]) or send mail to
MAILSERV@ymir.claremont.edu with the single line 

    INDEX

to get an index.

The archives are not up-to-date at present.

Dan
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail lists and large queues
Date: 27 Jul 92 20:42:15 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Jul 1992 12:42:15 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMVGMTLWDU9GVSDA@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"TIHOR@ACFcluster.NYU.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

There is no way to separate mailing list traffic from regular message
traffic and probably never will be. What there will be is a way to
prioritize list trafffic so it runs at a lower priority than regular mail.
Unfortunately we simply ran out of time and while all the hooks for this
were added to PMDF V4.1 the actual support at the mailing list level did not
make it in. It will be in the next release of PMDF. Note that this mechanism
can also be used to force the priority of the list upwards -- this is useful
for bug reporting lists and similar things.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem with timezone names
From: rollo.ross@levels.unisa.edu.au
Date: 27 Jul 1992 08:45:28 +0930
Organization: University of South Australia
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Jul 1992 08:45:28 +0930
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMU9SU0B6Q9GVPKW@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.claremont.edu"
X-Vms-Cc: CCAJR
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Ned says:
> The logic for getting values from MULTINET_TIMEZONE should, in practice,
> never be used. This is because PMDF should always be started prior to
> starting Multinet. See the documentation on startup ordering in the
> PMDF installation guide for details.
	Our SYSTARTUP_V5.COM does this. It turns out that the examples of bad
"Date:" headers that I saw were an artifact of the PMDF 4.1 installation. The
execution of PMDF_STARTUP.COM done as part of the installation used the
MULTINET_TIMEZONE logical that had been defined by Multinet when the system
was first booted.

                                    Rollo Ross, Network Manager (CLW campuses)

Computer Centre,  University of South Australia, The Levels, SA 5095, Australia
Ph +61 8 302 3158 Fax 302 3385 DTE 505282622004  Rollo.Ross@Levels.UniSA.Edu.Au
Newsgroups: vmsnet.mail.pmdf
From: coleve@cc.uvcc.edu
Subject: O= option inneffective in PRINTER_OPTION.
Organization: Utah Valley Community College
Date: Thu, 30 Jul 1992 01:47:59 GMT

My shiney new PMDF 4.1-7 seems to be ignoring the O= option in
the PRINTER_OPTION file.

Also the documentation did not make it clear how to delimit the
strings in that file.  It took me a few tries to come up with:
ou=   Department:                <cr>

The printer channel itself works GREAT -- made me look like a hero to the
boss, and the 4.1 upgrade was a snap.  Thanks!

-- 
-- Vern Cole -- Systems Manager -- Utah Valley Community College --
From: ned@sigurd.innosoft.com (Ned Freed (Postmaster))
Newsgroups: vmsnet.mail.pmdf
Subject: RE: WP Office to Internet via X400/PMDF
Date: 29 Jul 92 07:15:10 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 29 Jul 1992 00:15:10 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMYGXICF0Y9GVH42@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"gcprtck@state.systems.sa.gov.au"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

You have not provided enough information about your setup for me to comment
on it. Specifically, you say that you have a mechanism in place that lets
ALL-IN-1 users send and receive Internet mail. What mechanism is this?

You also say that you plan to get an X.400 gateway running on a PC. This
then will connect your WPO community to ALL-IN-1 somehow. How is this
supposed to work? MRX? Rest assured that ALL-IN-1 has no X.400 capabilities
of its own!

I know of only one way to connect ALL-IN-1 to PMDF that's reasonable, and
that's PMDF-MR. I know of only one way to connect an X.400 system to
ALL-IN-1, and that's MRX. If this is in fact what you're planning, it is
possible to gateway from X.400 to MRX to PMDF-MR to PMDF. The big loser
in this picture is MRX, whose registration requirements make this strategy
very unattractive.

I could say a lot more about all this, but I'm unwilling to proceed without
some additional information about what you're trying to do and what products
you are using.

				Ned
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: What msgs are covered by PostHeadOnly?
Date: 27 Jul 92 20:37:41 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Jul 1992 12:37:41 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMVGHQVHGY9GVSCT@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

There are dozens of different bounce messages generated by PMDF in dozens
of different places. There is no simple way to categorize them all. Our
goal is to have them all covered by postheadonly and be in MIME format --
eventually. This work was about about three quarters done for the
PMDF V4.1 release.

The message you got here was one that bounced during address conversion on
the mr_local channel. In PMDF V4.1 this generates a non-MIME message that
does not obey postheadonly. This has already been fixed for the next
release of PMDF.

				Ned
From: fineberg@wupost.wustl.edu (Charles M. Fineberg)
Newsgroups: vmsnet.mail.pmdf
Subject: Re: Mail lists and large queues
Date: 29 Jul 1992 17:31:03 -0500
Organization: Washington University in Saint Louis, MO USA
NNTP-Posting-Host: wuarchive.wustl.edu

  Pursuant to the discussion about clogged queues from busy mailing lists:
Is there any way that the mailing lists could take advantage of setting
multiple envelope RCPT TO: lines for groups of 50 or so users when using
smtp as the transport mechanism?  That way you wouldn't have to have so
many entries on the smtp queue.  It seemed to make a difference when I 
manually rigged such a system with sendmail once.  Is it possible?  Would
the benefits be as great with PMDF as with sendmail?  Does PMDF ever send
to multiple recipients?  (I thought I remembered reading something in
the docs which said yes on channels that support it, but I can't imagine
how to take advantage of it.)
	Charlie
From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: SVR4 TLI TCP/UDP address binding
Date: 23 Jul 92 19:50:00 GMT
Organization: The Internet
Resent-Date: 23 Jul 1992 11:50 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMPTN6ZDIA9GVG4G@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"jal@strobe.ATC.Olivetti.Com"
X-Vms-Cc: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I'm currently doing some reading up on Transport Interface Programming in
> the USL manual "UNIX SYSTEM V RELEASE 4 Programmer's Guide: Networking
> Interfaces"
>  
> My problem is that I can't work out how to bind a TCP/UDP-type address
> (32-bit host address + port number) to a transport endpoint.
> 
> This is easy enough when using sockets; you simply set up the sockaddr_in
> structure with the appropriate values.  However all the TLI examples in
> the manual neatly side-step the issue by binding local (integer) addresses.
> (e.g. the example starting on page 2-20).
>  
> It is obviously just a case of setting up the (struct netbuf)t_bind.addr
> structure correctly, but I can't for the life of me figure out how!

No one at Innosoft knows enough about TLI to give you any good advice.
Hopefully, some other readers of this list may be able to help out.  You might
also try sending e-mail to info-multinet@tgv.com.  Even if you don't run
MultiNet, you can post there and you may get some useful feedback from the
MultiNet community or the TGV folks.

Dan
From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: PMDF-FAX!
Date: 21 Jul 92 00:29:00 GMT
Organization: The Internet
Resent-Date: 20 Jul 1992 16:29 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-Id: <01GMLWIIWMAA985CIW@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MATS@rigel.efd.lth.se"
X-Vms-Cc: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Anyhow In the Manual for PMDF-FAX you talk about
> two faxmodem (DCE FaxBox/30 and Fujitsu dexNET 200).
>  
> I happen to have a faxmodem called ZyXEL U-1496 and it claim
> that it support CCITT V.17 and Class II FAX Commands.
> In the manual they talk about CCITT T.30 fax protocol.
> 
> Can I use this with PMDF-FAX for incoming and sending FAX?????

We do not support Class II FAX modems at present.  However, we expect too
in the very near future.  Watch this list for an announcement of such support
(and I'll send you a direct message).

Dan
From: j.lance Wilkinson, (814) 865-1818
Newsgroups: vmsnet.mail.pmdf
Subject: What to do about .HELD messages
Date: 29 Jul 92 19:06:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 29 Jul 1992 14:06 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMY5WBBI6Q9GVTDF@YMIR.CLAREMONT.EDU>
X-Organization: Penn State University / University Libraries
X-Vms-To: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

On 28-JUL-1992 19:20, "Daniel C. Newman <DAN@HMCVAX.CLAREMONT.EDU>"  said,
RE: Postmaster notification for held msgs
------------------------------------------------------------------------------
>Now, after things are straightened out, rename the *.HELD file to *.00, [run
>pmdf_root:[exe]synch_cache.exe if you're using PMDF V4.1,] and then release the
>PMDF Delivery job in the MAIL$BATCH queue.  There's a good chance that the
>message will pass on to another PMDF channel queue directory (e.g., the local
>channel directory) and again be marked *.HELD.  This is normal; it happens
>because PMDF again sees the local host name appearing 10+ times in the received
>line.  Merely rename the file to *.00, [rerun synch_cache,] and then release
>the PMDF Delivery job yet again.
>

I won't be installing v4.1 for a while yet; is this kind of procedural
information in the system manager's guide for v4.1, or do I have to keep
this mailgram around (which I'm going to do, anyway, in case the answer is
no)?  This is a fine example of a clear, concise *how to get out of this mess*
procedure which as a system manager for PMDF I really need to have, and if it
isn't in the system manager's guide, it really ought to be....Thanks, Dan.

+-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
| J.Lance Wilkinson ("Lance")            BitNet:    JLW@PSULIAS.BITNET      |
| Systems Design Specialist - Lead       InterNet:  JLW@PSULIAS.PSU.EDU     |
| Library Computing Services             AT&T:      (814) 865-1818          |
| E8 Pattee Library                      "I'd rather be dancing..."         |
| Penn State University         A host is a host from coast to coast,       |
| University Park, PA 16802     And no one will talk to a host that's close |
| <POSTMAST@PSULIAS.BITNET>     Unless the host that isn't close            |
| <POSTMAST@PSUCES.BITNET>      Is busy, hung or dead.                      |
+------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+