HDTenEightyP/NetNews huggingface dataset:
From: jjc+@pitt.edu (Jeffrey J. Carpenter)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: BN_MASTER and SEND/FILE
Date: 8 Sep 92 16:42:15 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Sep 1992 12:42:15 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOJCYRVER696VTE2@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"IPMDF@YMIR.CLAREMONT.EDU", IN%"NED@INNOSOFT.COM"  "Ned Freed",
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Thanks for all your help.

The JNET Manual for version 3.4 has the following paragraph (on page 6-11):

    SEND/FILE adds "W=destuser" to any options supplied with the
    /OPTIONS="text" qualifier.  It doesn't add "W=destuser" if "W=" or
    "EXTWTR=" is manually specified in /OPTIONS, nor does it add
    "W=destuser" if there's no destination user (sending to @NODE).
    This default for external writer is useful for sites that send files
    to MVS systems running JES2 and TSO.  It eliminates the need to
    specify the "destination user" twice in a SEND/FILE command, as in
    the following:

        $ SEND/FILE/OPTIONS="W=CHRIS" filename.dat CHRIS@MVSNODE

    /OPTIONS="" is the default.


The problem is that it ONLY adds the external writer by default as the
destination user if you also specify another option, such as
"/OPTIONS=FORM=blah".   There doesn't seem to be a way to have it ONLY
add the external writer by default.

What I ended up doing was creating a separate channel for our MVS
machine and creating an option file that had:

    OPTIONS=FORMS=STANDARD

The "FORMS" option seemed to be the safest one to specify.

In my previous message, I mentioned using "OPTIONS=W=".  Reading the
blurb above would lead you to believe that this would not include the
external writer field.  Joiner (I can't remember their new name) Tech
support told me that it would include it by default with "/OPTIONS=W=",
but it ends up that the manual is correct, and it did not.

Everything seems to be working ok now.

Thanks again.



	jeff
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: `Disconnected' remote PhoneNet dial-in processes
Date: 2 Sep 92 18:36:30 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 02 Sep 1992 11:36:30 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOB33G1TK295P36N@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

> OK.  I understand that now.  We explictly do a SET NOVERIFY in our SYLOGIN.COM,
> just before we quit if the user is a PMDF PhoneNet channel.  So I don't think
> that's the problem (unless it broke, of course :-).

The only thing that stands between the slave process and logging out is
terminal I/O; disconnecting should have no effect if no output is done. The
slave program definitely should not produce any I/O. This leaves the command
file trapping and related environment.

> No, I mean connect to one of those disconnected processes by logging in to the
> PMDF account and then explicitly reconnecting to one of those disconnected
> processes out there. I expect that some output should pop out and the job will
> then log out. The output that appears is what's important.

> I'll try that the next time I see them.  However, I'll have to reset the
> account from it's current setting of DisReconnect.  That couldn't be the
> problem, could it?

Just disable disreconnet prior to doing your reconnect. I don't see how this
could be the problem. You could also simply set the terminal /NODISCONNECT
and let VMS blow the process away instead of leaving it out there.

> I set that at one point because the scripts I'm using
> at the MASTER end couldn't deal with the unexpected prompt when there were
> disconnected processes.

Correct. But the information that pops out when you reconnect to one of
these processes is critical to determining where the problem is.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: BN_MASTER and SEND/FILE
From: "Stephen L. Arnold" <arnold@arnold.com>
Date: 11 Sep 1992 12:50:08 -0500 (CDT)
Organization: Arnold Consulting
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Sep 1992 12:50:08 -0500 (CDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOO36MJVEQ984Q2W@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir"
X-Vms-Cc: ARNOLD
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Craig Watkins said:
> |> 2. Joiner Tech Support tells me it is safe to include "/OPTIONS="W=" to
> |> have the external writer field filled in on each SEND.  Is that true?
> |> Are there any NJE mail software packages that would not like this?
> | ...
> This is about as safe as you can get.  Jnet does it by default on
> outgoing mail.  Do it.

To add a bit more to this:

I see you are running Jnet V3.4.  I'd strongly suggest upgrading to the
current release.

There is no danger of setting The external writer on every BITNET mail
file.  It is required by many MVS systems, and it makes no difference to
other systems.

PMDF should do this by default, too.  Can we get this enhancement in the
next release?

Steve
Newsgroups: vmsnet.mail.pmdf
Subject: Question about TEST/REWRITE
From: khatri@pcmail.inre.asu.edu
Date: 11 Sep 1992 18:27:00 -0700 (MST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Sep 1992 18:27:00 -0700 (MST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOO24FF2CY984Q54@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-Type: MULTIPART/MIXED; BOUNDARY="Boundary (ID jcdAH1bRLKYl/zeAvGNKUA)"
X-Mailer: Network Courier V2.1b


--Boundary (ID jcdAH1bRLKYl/zeAvGNKUA)--
From: crw@icf.hrb.com (Craig R. Watkins)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: BN_MASTER and SEND/FILE
Date: 6 Sep 92 20:12:02 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 06 Sep 1992 15:12:02 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: jjc+@pitt.edu, IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOGPIPV92Q96VOMY@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@INNOSOFT.com"
X-Vms-Cc: IN%"jjc+@pitt.edu", IN%"IPMDF@YMIR.CLAREMONT.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

|> 2. Joiner Tech Support tells me it is safe to include "/OPTIONS="W=" to
|> have the external writer field filled in on each SEND.  Is that true?
|> Are there any NJE mail software packages that would not like this?
|
|There is no way to ever be sure of this. BITNET simply doesn't have any rules
|about this sort of thing. As a result you may find all sorts of bizarre usage
|out there. All I can say for sure is that I have never seen a mailer that's
|sensitive in this way. However, my experience also tells me that when it comes
|to BITNET there is almost certainly such a system out there.

This is about as safe as you can get.  Jnet does it by default on outgoing
mail.  Do it.
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Defragment channel
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 15 Sep 1992 15:53:46 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Sep 1992 15:53:46 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOTHW7JY2A985350@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

I certainly didn't mean to imply the documentation that shipped on this
stuff with the release of V4.1 was adequate. It was not. But the problem was
fixed about a month back by adding a little section to the miscellaneous
channel chapter of the manual. This will appear in the documentation for
the next release of PMDF. Both the defragment and reprocess channels are
covered now.

Many of the internal details about the linkage between these channels and
PMDF's enqueuing facilities are not currently documented. This is intentional;
I'm pretty sure these linkage will change in the future and therefore relying
on their internal nature is a bad idea.

				Ned
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Strange forwarding problem.
Date: 3 Sep 92 03:42:15 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 03 Sep 1992 10:42:15 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOCFJTRPCI95OZNB@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"stodola@orion.fccc.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> We have a situation where a network alias (J_Blow@fccc.edu) points to Joe's
> VMS account (Blow@rm.fccc.edu).  Joe wishes to forward his VMS mail to his Unix
> account (J_Blow@xyz.fccc.edu).  Unfortunately, xyz recognizes J_Blow as an
> alias which then loops.  We had hoped to fudge the problem by putting a
> backslash in the forwarding address on the VAX side.  Unfortunately, putting
> in one backslash (set forward "in%""\j_blow@xyz.fccc.edu""") appears to
> swallow the backslash, while putting two backslashes causes PMDF to complain
> about a bad address (\J_Blow...).
>
> Flames aside (and I recognize that many are deserved in this situation!), if
> someone could explain how one might do this in PMDF, I'd be most grateful.
> We have some workarounds which may be better anyway, but I'd like to understand
> the options.

Backslash is, in RFC822 parlance, a "special" and must be quoted when it
appears in a mailbox name.  So, the legal RFC822 address for what you're
trying to do is "\j_blow"@xyz.fccc.edu.  To specify such an address in
VMS MAIL, you must use IN%"'\j_blow'@xyz.fccc.edu".  To set a VMS MAIL
forwarding address of this form, use the command

    MAIL> SET FORWARD "IN%""'\j_blow'@xyz.fcc.edu"""

Dan
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: NOTES channel for PMDF 4.0
Date: 1 Sep 92 15:10:10 GMT
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 01 Sep 1992 11:10:10 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO9HLWLETU9FM99A@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf"
X-Vms-Cc: TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Back in June I'd posted the following to the vmsnet.mail.pmdf newsgroup.
I never saw it arrive via the mailing list so I'm reposting it directly.

Date: 04 Jun 1992 09:44:48 -0400 (EDT)
From: bob@camb.com (Bob Tinkelman)
Subject: RE: NOTES channel for PMDF 4.0
Message-id: <1992Jun4.094448.39950@camb.com>
Newsgroups: vmsnet.mail.pmdf

In article <01GKQPB2ZOHYAYJZ9L@HMCVAX.CLAREMONT.EDU>, dan@hmcvax.claremont.edu
(Daniel C. Newman) writes:

> PMDF V4.1, due out any day now, has a PMDF -> VAX NOTES channel.

Any thoughts on the other direction: VAX NOTES -> PMDF ???
--
Bob Tinkelman, Cambridge Computer Associates, Inc., 718-464-9392, bob@camb.com
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: GATES.RULES file does not look right.
Date: 9 Sep 92 02:08:18 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Sep 1992 19:08:18 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOJWP7IXB696VVYB@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> As you can see it is trying to use the local channel to send to this node.

No, the PMDF TEST output clearly shows that it will send the message out
your bit_mailer channel:

> Submitted address list:
>   bit_mailer

>     k@alaska.BITNET (alaska.BITNET)

The instance of the local (l) channel which you saw mention of was the channel
which PMDF MMTEST was acting _as_ when rewriting the address.  Take a glance
at the PMDF TEST/REWRITE (a.k.a., PMDF MMTEST) documentation in the PMDF
System Manager's Guide.  In the example it describes some of the output of
PMDF TEST/REWRITE.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problems with cc:Mail channel.
From: andrewr@itd.adelaide.edu.au
Date: 14 Sep 1992 15:48:15 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 15:48:15 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOR4UI9AGI984TVF@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@INNOSOFT.COM"  "Ned Freed"
X-Vms-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mts: smtp

In message <01GOP8H9AB1A9FM7LA@INNOSOFT.COM> Ned writes:

+ I gather from this that you're entering cc:Mail addresses as
+
+     "user AT postoffice"@ccmail.whatever
+
+ on the Internet/PMDF side of things. This is incorrect and unsupported. The
+ proper form to use is
+
+     user%postoffice@ccmail.whatever
+
+ where any spaces in the user part are replace with underscores and any
+ commas are replaced with plus signs. This is the supported format; it is
+ also the format that will be produced by the slave channel program.

	OK, Thanks. The problem is that the documentation I have
(PMDF-REF-4.1) has minimal information on this.

+ What are you doing to force processing of the input file? Processing
+ is not automatic -- it cannot be since PMDF has no way of sensing the
+ creation of the input file. You have to arrange to do a
+
+     $ @PMDF_ROOT:[EXE]MASTER CC_LOCAL POLL

	When I try this, I get the following error message:

$ @PMDF_ROOT:[EXE]MASTER CC_LOCAL POLL
%DCL-I-SUPERSEDE, previous value of OPTION_FILE has been superseded
%PAS-F-ARRINDVAL, array index value is out of range
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           000AEE5C  000AEE5C
CC_SLAVE        DOSUBMIT                         4944      000004F8  00002D30
CC_SLAVE        CC_SLAVE                         5027      00000017  0000347B

	Now, according to "help errors supersede", this message
indicates a success state after redefining the logical name
OPTION_FILE, and requires no user action. As such, the first thing of
note is the Pascal error message.

+ at the proper time. The periodic job can be told to do this when it runs if you
+ mark the channel with the master channel keyword.

	I'm hesitant to do this until the above problem is resolved,
which it probably is in the current release.

+ What version of PMDF are you running. There have been a number of changes
+ and enhancements since the initial release. Please contact service@innosoft.com
+ and request the most recent version if you're not running at least V4.1-10.

	ident="V4.1-A"

	Not sure what the latest release from our supplier is, will
contact service as requested if they don't dave -10 or greater.

Thanks,
	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 !
 */
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problems with cc:Mail channel.
From: andrewr@itd.adelaide.edu.au
Date: 15 Sep 1992 13:10:36 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Sep 1992 13:10:36 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOSDLBNH76984YZW@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mts: smtp

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

+ >> 	ident="V4.1-A"
+ > Interesting -- I don't know of an instance where we used a letter as a
+ > dash number. Be that as it may, this is definitely a very early version
+ > and you need a more recent one.

+ V4.1-A is the ident applied to PMDFDISP.EXE after the mandatory security patch
+ has been applied.  All other images (and PMDF_ROOT:[EXE]IDENT.OPT) should
+ still contain the original ident after the patch has been applied.

$ TYPE PMDF_ROOT:[EXE]IDENT.OPT
ident="V4.1-3"

	I'll let you know how it goes when I get hold of V4.1-10 or greater.

Cya,
	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 !
 */
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Erroneous output from CONFIGURE.COM
Date: 3 Sep 92 14:37:48 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 03 Sep 1992 21:37:48 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOD2ETB4EQ95NKT2@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"JEREMY@vsm.com.au"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> That makes sense, I told it the official local host name was r.s.g.a, not
> SERF.r.s.g.a which was the default response.  Although this does mean I
> have mis-understodd how the rewrite rules and the channel blocks interact.

I have changed CONFIGURE.COM so that in the future it will insure that the
official local host name gets its own rewrite rules.

> Actually, no.  I just did this:
> $ MAIL
> MAIL> send
> To:   in%"sysprgg@paper"
> Subj: Test mail to paper
> Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
> This is a short test message to paper.
> ^Z
> MAIL>

> Didn't work.  I removed the "charset7 us-ascii" without success, and then
> also the "charset8 iso-8859-1" and that didn't help either.

Did you remove them from both the D AND the L channels? You have to get rid of
it in both places. charset8 has nothing to do with it unless you use 8-bit
characters. You can also solve the problem by getting rid of the linelength
limits. The proper solution, of course, is to get a newer version of PMDF that
handles this interaction correctly. Please contact your distributor if you want
a updated version; all distributors have had updated versions in hand for quite
a while.

Dan was incorrect on one point -- the problem has nothing to do with actually
having long lines. The problem is rather due to the fact that a line length
limit was given AND a character set was given WITHOUT providing an incentive
for an actual detailed length check of the message. The result is that the
general MIME converter in PMDF doesn't know the lengths but knows there's a
limit; it then assumes the worst and encodes "just to be on the safe side".
This is also the reason base64 is used -- there is no frequency information
available to indicate that quoted-printable would be a better choice.

This problem was corrected by making a bunch of different and interrelated
changes. In some cases more analysis is now done and in others the converter is
no longer quite so strict.

All this is an unfortunate consequence of the interaction of linelengths and
character sets. I have described the problem and the ways to solve it in
previous info-pmdf postings. I am fairly sure this is the problem you're
seeing; the symptoms are absolutely identical to previous problem reports.

If you cannot get things to work even after you have removed all linelength and
charset7 specifications and recompiled and reinstalled (if you use a compiled
configuration) please send me your configuration and I'll look into it further.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: Problems with cc:Mail channel.
From: andrewr@itd.adelaide.edu.au
Date: 12 Sep 1992 17:20:01 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Sep 1992 17:20:01 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOOFFFFOBM984QR1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mts: smtp

	I'm having two problems with the cc:Mail channel under PMDF.
The first, of irritance value only, is that it manipulates spaces
inside quotes in names to underscores in it's output file namem,
including those around the "AT" which signifies the post office to go
to, so it's treated as one user. We've got around this with a small
program on the DOS side to change it back, and using cc:Mail's
directory propogation so we don't have to specify the post office.
	The second problem is that it only works one way. It creates
the output file just fine, in the correct format, but it doesn't seem
to look at the input file specified. EG:

$ type pmdf_root:[table]cc_local_option.
CC_GATEWAY_NAME=AARNet
CC_OUTPUT_FILE_NAME=DKA400:[POST_OFFICE]CCMAIL.IMP
CC_INPUT_FILE_NAME=DKA400:[POST_OFFICE]CCMAIL.EXP

$ dir /date=all DKA400:[POST_OFFICE]

Directory DKA400:[POST_OFFICE]

CCMAIL.EXP;1         11-SEP-1992 12:16:38.60  11-SEP-1992 12:16:39.07   <None specified>   <No backup recorded>
CCMAIL.IMP;1         11-SEP-1992 13:37:49.78  11-SEP-1992 13:35:34.00   <None specified>   <No backup recorded>
TEST.IMP;1           11-SEP-1992 13:37:01.18  11-SEP-1992 13:35:34.00   <None specified>   <No backup recorded>

$ show time
  12-SEP-1992 17:16:29

ie, the file's been sitting there for over 24 hours.

	Obviously I'm doing something wrong as others have got this to
work - can anyone offer any suggestions? The PC accesses the
filesystem via PC-NFS through Multinet NFS on the VAX side.

Thanks,
	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 !
 */
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Reprocessing channel
Date: 31 Aug 92 22:35:44 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 31 Aug 1992 15:35:44 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO8IVZYWB695OX76@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"D.Nash@utexas.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I already added the explanation to the "Other channels" chapter in response
to your first note.

The usual way sites get these channels is when they run CONFIGURE. It
generates them automatically. However, this does leave sites upgrading an
existing configuration in a spot, so the explanation is indeed useful to
have.

				Ned