HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"coleve@cc.uvcc.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 21 Aug 92 00:05:52 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: Problem with printer channel?
X-To:         coleve@cc.uvcc.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> Hmmmm. Good point.
>      How about:
>      HARDCOPY.UVCC.EDU        /AT=$U@PRINTER.UVCC.EDU
>      PRINTER.UVCC.EDU             $U@PRINTER.UVCC.EDU
>
> That way you can do it both ways, correct?

No, instead you now have double the trouble.  This whole discussion centered
around people using incorrect printer channel addresses. Regardless of what you
do, people will occassionally enter an incorrect address.  Now you've merely
introduced a new variable they can get wrong -- two different printer channel
"domain" names each with a different addressing format.

Dan
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: info-pmdf
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 21 Aug 92 06:35:14 GMT
From:         "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
Subject:      RE: TCP/IP Services for VMS V2.0 and PMDF
X-To:         fineberg@wupost.wustl.edu, info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>  Just a quickie:
>       Has anyone used pmdf 4.x and UCX 2.0?
> We just got the new UCX in here at our campus ESL and I want to know
> if it is safe to use it...

It should work fine, you just have to disable the SMTP server that comes with
UCX.  I don't recall the details (we don't have it yet) but you need to remove
the UCX SMTP server from INETD.  Don't put the PMDF server in there, we haven't
modified it to work under INETD yet, just use START_UCX_SMTPD.COM as you did
with previous versions of UCX.

        /Kevin Carosso
         Innosoft
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: Beckman Instruments
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:         Fri, 21 Aug 92 04:46:13 GMT
From:         dsroberts@BECKMAN.COM
Subject:      RE: Deliver and MM-32
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l

In article <714322258.880000.PAVER@Maximillion.mcc.com>,
 paver@maximillion.mcc.com (Bob Paver) writes:
> Does DELIVER work with MM-32 under PMDF 4.1? I read the manual, but
> it only talks about using Deliver with VMS mail.
>
> Thanks,
>
> Bob
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> Bob Paver  ---->  paver@mcc.com  OR  cs.utexas.edu!milano!paver
>
> Microelectronics and Computer Technology Corp (MCC)
> 3500 West Balcones Center Drive
> Austin, Texas 78759-6509             (512) 338-3316

We just noticed a problem with this today.  DELIVER seems to have stopped
working with MultiNet MM as of PMDF 4.1.  Perhaps a logical needs to be set or
something?
--
   Don Roberts                   Internet:  don@beckman.com
   Beckman Instruments, Inc.     Phone:     714/961-3029
   2500 Harbor Bl. Mailstop X-12 FAX:       714/961-3351
   Fullerton, CA  92634          Disclaimer:  Blame me, not Beckman.
   People are as happy as they decide to be - A. Lincoln
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"8004SLB@VMS.CSD.MU.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 18 Aug 92 07:24:45 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: Problems with QM RETURN command
X-To:         8004SLB@VMS.CSD.MU.EDU, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> I'm having problems getting the QM RETURN command to work.  It keeps telling m
   e
> that the files I see in the various channel queues via the DIR command do not
> exist.  I changed the line in QM.COM that is 2 lines after the CMD_RETURN labe
   l
> from
>
>       $ fext = heldext
> to
>       $ fext = outext
>
> and this seems to fix the problem.  Is this a correct fix or am I missing
> something here?  I'm running PMDF V4.1-6.

This is the correct fix (posted to info-pmdf back in June or thereabouts).

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KNAPKE%BUTLERU.bitnet@UICVM.UIC.EDU"
X-VMS-Cc: info-pmdf
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 13 Aug 92 17:37:51 GMT
From:         "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
Subject:      RE: Mail User agents
X-To:         KNAPKE%BUTLERU.bitnet@UICVM.UIC.EDU, info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

> You certainly cannot connect 350-400 mac's to a file server.  The cost
> of installing 3 (100 Mac users per server) additional Novell file servers
> would be slightly prohibitive.

This is the major reason in my mind why the PC mail solutions are all inadequate
   .
They all try to base the mail transport on file services, which simply cannot
scale adequately.  With mail services you need connectivity to millions of
hosts, not dozens.  SMTP based on a host to host wire protocol easily handles
a million hosts today (Internet).  Try doing that if SMTP were replaced with
something like BSMTP on NFS.  And even if you did it, who'd manage the
100,000 post offices? In a worldwide network it could never work.  A large
multi-national corporation isn't much different.

Most of the PC mail packages can interconnect post offices with a wire protocol,
but the narrow-minded designers chose proprietary protocols -- mainly designed
to run over dial-up lines.  Just try getting information on anything at that
level (the level at which we would prefer to speak to the things).

        /Kevin Carosso
         Innosoft
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"WEAVER@sheridanc.on.ca"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 21 Aug 92 22:38:13 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: pmdf-mr
X-To:         WEAVER@sheridanc.on.ca, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> One of the questions asked during the configuration of pmdf-mr
> is:  Convert WPS-PLUS to ASCII ?  I chose NO because I had already
> answered yes to a similar question from the installation of V3.0 of
> ALLIN1.  The question was "do you want outgoing WPS-PLUS docs converted
> to ASCII?

> I assumed that it is the same function, but if so why does PMDF offer
> it if ALLIN1 already does it.

The problem is that ALL-IN-1 does not always do it and cannot always do it.
Consider the following scenario -- you have a dozen systems running ALL-IN-1
connected by Message Router. These systems happily exchange messages in
WPS-Plus format. If they had chosen to convert all messages to ASCII before
sending them the general utility of the setup would be very severely
compromised.

Now you add PMDF-MR to this scheme. The ALL-IN-1 systems have no way of knowing
if they are sending to another ALL-IN-1, PMDF-MR, or (worst case) both at once.
You are now asking them to severely mangle their existing document exchange
capabilities for the sake of one added gateway.

> Is this one of those cases where it isn't getting done quite right
> and I should be letting PMDF do the converts?  :-)

See the documentation -- the converter we use is cobbled together out of the
libraries that ship with MRGATE. These libraries offer exactly the same
(very limited) functionality you get with ALL-IN-1. This is unfortunate
since I'd prefer to convert to/from richtext. The WPS-Plus format is totally
undocumented, however, so there's no way to do this.

In any case, the only reason why you might not want to have PMDF do  this
conversion is when the remote sites you're contacting via PMDF also have
PMDF-MR and ALL-IN-1. In other words, you want to exchange WPS-PLus across the
Internet. This is a rather nasty concept but it is one people use and we do
support it.

                                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:         Mon, 17 Aug 92 18:01:55 GMT
From:         "J.Lance Wilkinson, 814-865-1818" <JLW@PSULIAS>
Subject:      Channel Keyword "logging" and BITNET_DOMAINS.COM
X-To:         IPMDF@PSULIAS
Newsgroups: bit.listserv.pmdf-l

A user queried what had happened recently on a MAILSERV list posting that
didn't get delivered everywhere there were subscribers.  In an effort to figure
out what had happened, I started looking at MAIL.LOG (bad idea; the file hadn't
been cycled since March...;-() and then looked at my PMDF.CNF to find out that
there wasn't any "logging" keyword on my MAILSERV channel.  Then I noticed the
file PMDF_ROOT:[TABLE]GATES.CHANS didn't have "logging" on its entries, either.

The question is would "logging" on the channels built by BITNET_DOMAINS.COM in
the GATES.CHANS file be of any benefit?  If so, could BITNET_DOMAINS.COM be
updated to incorporate them (obviously, this needs to be an optional action,
by default not done to support the thousands of users who don't use it now)?

Currently using VMS v5.5, Multinet v3.0 rev H, PMDF v4.0-25 (although v4.1
finally arrived last week...;-)

+-"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
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 22 Aug 92 02:08:21 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: deliver and 'vacation' processing
X-To:         KLENSIN@INFOODS.MIT.EDU, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

The single best way to filter out list addresses from vacation processing
is to use subaddressing on the address you use to subscribe to the list.


For example, when I subscribed to the ietf mailing list, I told them to
put me down under the address ned+list-ietf@innosoft.com. This gets back to
me just fine, and I can use DELIVER to filter things based on the envelope
To: address, which is ALWAYS this address for mail coming from this
particular list.

I use a different subaddress for each list. Not only does this give me
a guaranteed way to do vacation processing right, it also gives me a way
to file messages from lists to selected folders automatically. I do this
sometimes for lists I'm not actively involved with.

All this requires some foresight since you have to use a subaddress at
the time you subscribe (or ask that your subscription be changed to a
subaddress later). But it is the only way I know of that works correctly;
in general the behavior of list exploders is just too unpredictable to make
any other scheme practical.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KNAPKE%BUTLERU.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 13 Aug 92 09:56:43 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Mail User agents
X-To:         KNAPKE@BUTLERU, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> cc:Mail looked pretty good as well, but we are not sure how we are going to
> serve it to close to 400 Macs.  On the DOS side, its easy, we have Novell
> servers.  There has been discussion of the cc:Mail channel in PMDF and how
> to push mail back and forth, that sounds good but a little ruff as far as
> the particulars of pushing the files back and forth.  Ned mentions MIME
> translation into cc:Mail, but said there were problems with multi-part mail
> (if I recall correclty).  That confuses me since cc:Mail had the ability to
> have multiple enclosures, or am I missing something??

It is really not that hard to arrange for the necessary file transfers.
We use PathWorks internally for this and it is seamless and clean. Any
other file server facility should work.

The only problems with multi-part mail are caused by the severe limitations
cc:Mail imposes. Text messages must consist of very short lines and cannot be
very long in cc:Mail. Everything else has to be a file attachment. The PMDF
gateway to cc:Mail takes all of this into account, and the results are the best
they can be, but I still don't like the limitations.

cc:Mail also doesn't support type information for attachments. This is a severe
limitation; you lose a lot of valuable information here.

There are essentially no problems with gatewaying cc:Mail and its attachments
into MIME. MIME is more than versatile enough to handle everything cc:Mail
can produce.

Please note that MHS has restrictions too -- in some ways it is more restricted
and in other ways it is less -- so there really is no perfect solution to these
problems.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Original_To:  BITNET%"ipmdf@ymir"
Date:         Wed, 12 Aug 92 18:03:55 GMT
From:         "Scott J. Mitchell" <MITCHELL@UTHSCSA>
Subject:      RE: two minor points
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>>  Is this information "boundary..." important to the person, who really only
>>  needs to know that he spelled the nodename wrong?
>>  Can we suppress it?

> This information is boundary information separating different pieces of the
> message.  The message, if you examine the headers, is a multipart message
> which had two pieces: bad address list and returned content of the original
> message.  You cannot remove this information.  When we finish up our user
> agent, users using it will not see these boundary markers and whatnot (althoug
h
> they will still be there).

I hate to sound retrograde, but there are probably some sites that would
prefer non-multipart notices.  Many people here won't have MIME-speaking
UAs in the near future.  Novice users looking at these things sometimes
despair before noticing that they contain readable information!

Scott Mitchell
University of Texas Health Science Center
mitchell@uthscsa.edu
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:         Wed, 19 Aug 92 05:29:14 GMT
From:         Bruce Tanner <TANNER@CERRITOS.EDU>
Subject:      RE: V4.1-10 mailserv questions
X-To:         info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>> * Where do I define the COMMAND_LIMIT, MAXBLOCKS and MAXLINES options?
>
> You put them all in a per-channel option file. The usual format PMDF uses
> is used here.

You can use a per-channel option file if you add the line
$ define/user option_file pmdf_root:[table]'channel_name'_option.
just before the "run pmdf_root:[exe]mailserv.exe" in MASTER.COM.

I'm too ashamed to tell you how long it took me to figure that one out.

-Bruce
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:         Thu, 20 Aug 92 14:55:34 -0500
From:         "Charles M. Fineberg" <fineberg@WUPOST.WUSTL.EDU>
Subject:      TCP/IP Services for VMS V2.0 and PMDF
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l

  Just a quickie:
        Has anyone used pmdf 4.x and UCX 2.0?
We just got the new UCX in here at our campus ESL and I want to know
if it is safe to use 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%"KVC@SUMMER.INNOSOFT.COM"  "Kevin V. Carosso"
X-VMS-Cc: IN%"info-pmdf@INNOSOFT.COM"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Mts: smtp
Date:         Fri, 14 Aug 92 08:29:26 +1000
From:         andrewr@ITD.ADELAIDE.EDU.AU
Subject:      RE: Mail User agents
X-To:         "Kevin V. Carosso" <KVC@SUMMER.INNOSOFT.COM>
X-cc:         info-pmdf@INNOSOFT.COM
Newsgroups: bit.listserv.pmdf-l
              <01GNIZNYGI108WZVZS@SUMMER.INNOSOFT.COM>

In message <01GNIZNYGI108WZVZS@SUMMER.INNOSOFT.COM> Kevin writes:

+ This is the major reason in my mind why the PC mail solutions are all inadequa
   te.
+ They all try to base the mail transport on file services, which simply cannot
+ scale adequately.  With mail services you need connectivity to millions of
+ hosts, not dozens.  SMTP based on a host to host wire protocol easily handles
+ a million hosts today (Internet).  Try doing that if SMTP were replaced with
+ something like BSMTP on NFS.  And even if you did it, who'd manage the
+ 100,000 post offices? In a worldwide network it could never work.  A large
+ multi-national corporation isn't much different.

        The real problem is that you can usually rely on VMS or Unix
machines to be up 24 hours a day to receive mail, and you can connect
to them from anywhere, whereas PC's and Mac's are usually only on
during office hours, and you can't connect to them from elsewhere to
check your mail. Thus the SMTP direct to your desk concept won't work,
as the basic assumptions about machine avalibility aren't held.
        So the concept employed is that there is one central place
that stays up all day, and you can access from all over the place. The
problem now is that PC and Mac users expect a GUI as opposed to the
CUI's we all use for VMS/Unix based mail. So the software companies
are forced to have some wonderful interface that'll knock your socks
off, and is necesarily different from the type that gets shunted over
SMTP.
        In summary, I agree that the current state of affairs is
woeful, but given the time, locality, and user expectation
constraints, I don't think it's going to get a lot better in the near
future. And you're never going to get micro software houses to
standardise on one mail format, unless it is almost forced on them
from the outside.
        I'm sure I can here a flamethrower warming up...

        Andrew.

/*
 * Andrew Rutherford                 andrewr@itd.adelaide.edu.au
 * +61 8 228 5669            Real Programmers always confuse Christmas and
 * Room 1060, Adelaide Uni      Halloween because OCT 31 == DEC 25 !
 */
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"robin_goldstone@macgate.csuchico.edu"
X-VMS-Cc: IN%"ipmdf@YMIR.BITNET"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 21 Aug 92 03:58:36 GMT
From:         "David J. Knapke 317/283-9420" <KNAPKE@BUTLERU>
Subject:      RE: deliver and 'vacation' processing
X-To:         robin_goldstone@macgate.csuchico.edu
X-cc:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

I don't have an answer for your problem, but a plea for what you are
trying to do.  PLEASE filter out lists for this reply!!!  It is really
a pain to get mail bounced back to a list that says John Doe will be
out until....  People on the list really don't care.



David J. Knapke                       Knapke@ButlerU.BITNET
Computer Center                          Assistant Director
Butler University                     Information Resources
Indianapolis, IN  46208                      (317) 283-9420
USA                                     Fax: (317) 283-9740
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: NYU Medical Center, 550 First Ave., New York, 10016
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"Ned Freed <NED@INNOSOFT.COM>",in%"ipmdf@ymir.bitnet"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 17 Aug 92 10:20:08 GMT
From:         SMITH@NYUMED
Subject:      RE: Error in queueing bounced message.
X-To:         Ned Freed <NED@INNOSOFT.COM>, ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l


Thanks for the analysis.  Yes, indeed 'nyu-medical.nyu.edu' is illegal (but
probably shouldn't be, but that is another matter).  My problem was that the
MR_LOCAL channel was not delivering what appeared to be a reasonable address.
I will be upgrading to V4.1-10 tomorrw, so with luck this will not recur.

Thanks again.
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:         Mon, 17 Aug 92 10:01:15 GMT
From:         "James Dryfoos - Postmaster" <DMPM@DUKEMC>
Subject:      More on no tape label problem.
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

By the way, I was sent a 9-track tape if that helps.
Here is some more I tried:

$ mou/ov=id mua0:
%MOUNT-F-NOTLABELMT, tape is not labeled

$ mou/nolab mua0:
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED,  mounted on _MIVAX$MUA0:

$ copy mua0:[000000]*.* */log
%COPY-E-READERR, error reading _MIVAX$MUA0:[].;
-RMS-F-RER, file read error
-SYSTEM-F-PARITY, parity error
%COPY-W-NOTCMPLT, _MIVAX$MUA0:[].; not completely copied
%COPY-F-OPENOUT, error opening DUA3:[SAVESETS].;1 as output
-RMS-F-SYN, file specification syntax error

$ dir mua0:[000000]
%DIRECT-E-OPENIN, error opening MUA0:[000000]*.*;* as input
-SYSTEM-F-NOTFILEDEV, device is not file structured


And I was excited to instal the new version sunday :-(

-Jim
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"PAVER@Maximillion.mcc.com"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 20 Aug 92 21:33:49 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Deliver and MM-32
X-To:         PAVER@Maximillion.mcc.com, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

If you're talking about MM-32 as shipped by TGV as part of Multinet the
answer is yes; integrated DELIVER fully supports it. Integrated DELIVER
detects whether you're using VMS MAIL or Multinet MM and modifies the
actions it performs accordingly.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU