HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"MATS@rigel.efd.lth.se"
X-VMS-Cc: IPMDF
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 22 Jul 92 01:10:00 GMT
From:         "Daniel C. Newman" <DAN@HMCVAX.CLAREMONT.EDU>
Subject:      RE: PMDF-FAX!
X-To:         MATS@rigel.efd.lth.se, INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> 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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: Washington University in Saint Louis, MO USA
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf-newsgate@mccall.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 29 Jul 92 17:31:03 -0500
From:         "Charles M. Fineberg" <fineberg@WUPOST.WUSTL.EDU>
Subject:      RE: Mail lists and large queues
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l

  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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"JEREMY@vsm.com.au"
X-VMS-Cc: IPMDF
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 26 Jul 92 17:24:09 GMT
From:         "Daniel C. Newman" <DAN@HMCVAX.CLAREMONT.EDU>
Subject:      RE: Request for minor changes to installation procedure
X-To:         JEREMY@vsm.com.au, INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> I do not gree with this.  Plenty of DEC products support a SYSTARTUP.COM as pa
   rt
> of the regular startup procedure.  Sure, it can't cater for all sites, but I'l
   l
> bet that if you say "PMDF_SYSTARTUP.COM is run at such-and-such a point in the

> startup process" people will set up their systems appropriately.

And when should we invoke a site-supplied system startup?  Before PMDF_STARTUP
runs or after (but before the networks begin running), or before
PMDF_SUBMIT_JOBS runs (and after the networks are started) or after
PMDF_SUBMIT_JOBS runs.  I know of legitimate examples, in use at sites today
for all four cases.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: root@se
Errors-to: epmdf@YMIR.BITNET
Organization: Alcatel Bell, Antwerpen, Belgium
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"alcbel-list-pmdf@alcbel.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Followup-To: alcbel.list.pmdf
Newsgroups: bit.listserv.pmdf-l
Date:         Wed, 29 Jul 92 14:49:29 GMT
Reply-To:     gdha@se.alcbel.be
Comments:     Warning -- original Sender: tag was root@SE.ALCBEL.BE
From:         Gratien D'haese <gdha@SE.ALCBEL.BE>
Subject:      Remote DECnet nodes using PMDF
X-To:         alcbel-list-pmdf@alcbel.UUCP



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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: The McCall Pattern Co., Manhattan, KS, USA
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf-newsgate@mccall.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 23 Jul 92 22:10:03 GMT
From:         Terry Poot <tp@MCCALL.COM>
Subject:      RE: SVR4 TLI TCP/UDP address binding
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l


Sorry about that. That was a usenet news article posted to a bogus newsgroup
("world"), and it slipped through the gateway. The problem should be fixed now.
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
(Gateway operator)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: in%"info-pmdf@ymir.claremont.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 26 Jul 92 09:48:36 GMT
From:         Jeremy Begg <JEREMY@VSM.COM.AU>
Subject:      RE: Request for minor changes to installation procedure
X-To:         info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>Again, this assumes knowledge of local environments that we simply do
>not have. How do we know that such a local procedure should always be
>run? How do we know that it should be run at a particular point?
> ...
>In other words, your proposal is considerably less flexible than providing
>no hook at all. Why should we provide a mechanism with narrow flexibility
>when no mechanism at all is considerably better?

I do not gree with this.  Plenty of DEC products support a SYSTARTUP.COM as part

of the regular startup procedure.  Sure, it can't cater for all sites, but I'll
bet that if you say "PMDF_SYSTARTUP.COM is run at such-and-such a point in the
startup process" people will set up their systems appropriately.

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

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: Corning Incorporated
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf-newsgate@mccall.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 21 Jul 92 13:50:05 -0500
From:         "Richard P. Copeland" <copeland_rp@CORNING.COM>
Subject:      RE: VMS MAIL_SERVER and undeleted temp files
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l

In article <01GMLRT10XTY9FM73V@YMIR.CLAREMONT.EDU>,
 mitchell%uthscsa.bitnet@ymir.claremont.edu (Scott J. Mitchell) writes:
> We recently discovered a large number (10,000s) of uncataloged MAIL.TXT
> files on the system disk of one of our Vaxes.  DEC acknowledges that
> MAIL_SERVER.EXE is creating these temp files and failing to delete them
> properly, but at the same time they're pointing an ambiguous finger at
> "non-DEC protocols," suggesting that the problem is more likely to occur
> when the delivering system is something other than VMSmail.  A timestamp
> comparison suggests that the problem is indeed associated with deliveries
> relayed by our primary mail host using PMDF.
>
> I'm absolutely not suggesting that PMDF has any relationship to this problem,
> particularly in a causal sense.  Just wondering if anyone can shed additional
> light on the subject.  We were caught asleep at the switch and had some
> difficulty recovering the disk because of a hosed INDEXF.SYS.
>
> Scott Mitchell
> University of Texas Health Science Center at San Antonio
> mitchell@uthscsa.edu
> mitchell@uthscsa.bitnet
>

We saw the same behavior on one of our systems ... we got about 6,600 MAIL.TXT
files before rectifying the problem.  We used ANAL/DISK/REPAIR to place them
all in [SYSLOST], and I took a look at several of them.  Occasionally, some
mail messages sent via PMDF will generate hundreds of duplicate partial copies
as uncatalogued MAIL.TXT files.  The other weird thing is that the files were
on DIA0 (the system disk), while the recipient was on DIA2.  Another weird
thing is that other systems exhibit no problems whatsoever.

DEC indicates that this is a VMS bug that will be fixed in VMS V5.5-2.  Until
then, we're just going to ANAL/DISK/REPAIR on that system more frequently.

Richard Copeland
Corning Incorporated, Corning NY
copeland_rp@corning.com
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"fineberg@wupost.wustl.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 30 Jul 92 22:45:02 GMT
Comments:     Warning -- original Sender: tag was NED@SIGURD.INNOSOFT.COM
From:         Ned Freed <ned@INNOSOFT.COM>
Subject:      RE: Mail lists and large queues
X-To:         fineberg@wupost.wustl.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

There's all sorts of support in PMDF for handling large lists efficiently.
You can control how many processing jobs get created, whether list expansion
is done immediately or delayed, and lots of other stuff.

PMDF fully supports having multiple recipients in a single copy of a message.
The issue isn't whether or not this works, the issue is instead whether or
not a given channel can handle multiple recipients, or multiple recipients
on different remote hosts. In particular, the SMTP channel's processing is
enormously simplified by virtue of the fact that each message copy contains
addresses associated with only a single target machine.

Modifying the SMTP channel to support fully general messages with any mix
of recipients gains some efficiency in terms of eliminating extra copies of
messages but loses efficiency big-time when it comes to actual channel
processing. I've done some testing of this and use of this sort of thing
actually slows delivery of an expanded list in PMDF by a very considerable
amount. This more than offsets the cost of the multiple message copies in
most cases.

I eventually plan to generalize the support in SMTP to allow for this, if for
no other reason than to allow for the special case of lists that only
process really enormous messages and where the destination hosts are almost
always available. But don't expect this support to improve the efficiency
of mailing list handling. It has basically no effect on getting jobs to
process the messages in a timely fashion and has a significant negative
effect on getting the jobs to process messages efficiently when any sort
of temporary failure conditions exist (and they often do...).

In summary, this is something I have studied and tested very extensively, and
I have found that lessons learned from sendmail don't necessary apply to
VMS. In most cases, in fact, they lead to very wrong conclusions in most
cases.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"JSTAFFORD@VAX2.Winona.MSUS.EDU"
X-VMS-Cc: IPMDF
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 22 Jul 92 19:48:22 GMT
From:         "Daniel C. Newman" <DAN@HMCVAX.CLAREMONT.EDU>
Subject:      RE: FAQ?
X-To:         JSTAFFORD@VAX2.Winona.MSUS.EDU, INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> 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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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)
Date:         Wed, 29 Jul 92 20:33:22 GMT
From:         "Daniel C. Newman" <DAN@HMCVAX.CLAREMONT.EDU>
Subject:      RE: What to do about .HELD messages
X-To:         JLW@PSULIAS, INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> 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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"jal@strobe.ATC.Olivetti.Com"
X-VMS-Cc: IPMDF
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 23 Jul 92 20:32:31 GMT
From:         "Daniel C. Newman" <DAN@HMCVAX.CLAREMONT.EDU>
Subject:      RE: SVR4 TLI TCP/UDP address binding
X-To:         jal@strobe.ATC.Olivetti.Com, INFO-PMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> 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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Organization: Duke University Medical Center, Durham NC, USA
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@ymir"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 30 Jul 92 05:02:52 GMT
From:         "James Dryfoos- PostMaster" <DMPM@DUKEMC>
Subject:      Return address on envelope?
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

Can someone help?  Why does the envelope from address here not
have a domain when the rest of the header does?  Mail was sent
from a NEXT box.  Am trying help someone set it up, but do not
have a clue to unix mail config files.

Thanks, JIm

m;schwa002@bullnext
DRYFO001@DUKEMC.DEMPO

Received: from bullnext.mc.duke.edu by mc.duke.edu (PMDF #12191) id
 <01GMY2AZ08E8004J9E@mc.duke.edu>; Wed, 29 Jul 1992 09:25 EDT
Received: by bullnext.mc.duke.edu (NX5.67a/NX3.0M) id AA01084; Wed,
 29 Jul 92 09:18:32 -0400
Received: by NeXT Mailer (1.82)
Date: Wed, 29 Jul 92 09:18:32 -0400
From: Babs Schwartz <schwa002@bullnext.mc.duke.edu>
Subject: More mail from Bullnext
To: dryfoos@romeo.cs.duke.edu, dryfo001@mc.duke.edu, dmpm@mc.duke.edu
Message-id: <9207291318.AA01084@bullnext.mc.duke.edu>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KANAITIS@SINGER.ASRI.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 31 Jul 92 02:27:00 GMT
Comments:     Warning -- original Sender: tag was NED@SIGURD.INNOSOFT.COM
From:         Ned Freed <ned@INNOSOFT.COM>
Subject:      RE: VAX Notes channel
X-To:         KANAITIS@SINGER.ASRI.EDU, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

You can use the channel-specific header stripping features of PMDF to
do this. Check out section 3.7 in the System Manager's Guide (page 3-79 or
thereabouts) for the details.

This is one of the few places where such functionality is actually a good
idea!

The ability to map NOTES back into MAIL is not presently supported. We do have
the hooks in place to do this, however, and I plan to provide a NOTES_SLAVE
program for this purpose in the future. No promises on when, but it definitely
a planned enhancement for this channel. Note that it isn't going to be the
fastest thing in the world, but it will work...

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Organization: Penn State University / University Libraries
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IPMDF
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 29 Jul 92 20:00:26 GMT
From:         "J.Lance Wilkinson, (814) 865-1818" <JLW@PSULIAS>
Subject:      What to do about .HELD messages
X-To:         IPMDF@PSULIAS
Newsgroups: bit.listserv.pmdf-l

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."-------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: Utah Valley Community College
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf-newsgate@mccall.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 30 Jul 92 13:09:54 GMT
Comments:     Warning -- original Sender: tag was news@PARK.UVCC.EDU
From:         coleve@CC.UVCC.EDU
Subject:      O= option inneffective in PRINTER_OPTION.
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l

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 --
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU