HDTenEightyP/NetNews huggingface dataset:
From: dave Mulvihill - Technical Support x-6993
Newsgroups: vmsnet.mail.pmdf
Subject: Using DELIVER
Date: 4 Sep 92 20:20:54 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 04 Sep 1992 16:20:54 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOFSSHKV8C96VMU9@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.bitnet"
X-Vms-Cc: DPMSYS
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT


I know this has been covered on this list before, but can
someone explain again why the VMS forwarding address cannot
be used as the determinant for the execution of DELIVER.

I recently encountered the following senario:

A user runs PMDF with integrated DELIVER on his home
machine (TECHNO).  On another machine (VAXA) which also runs
PMDF with DELIVER disabled he has his forwarding address set
to forward mail to his home machine.   His login directory on
VAXA is his home directory on TECHNO mounted on VAXA via
DEC's DFS.

This all worked fine until I enabled DELIVER on VAXA.  PMDF
ignored the forwarding to TECHNO and instead processed all
mail to his account on VAXA using his mail.delivery file
from TECHNO.

I realize there are workarounds such as defining different
mail.delivery file names for different nodes, but what are
the reasons for allowing the file to override a forwarding
address.  If there are no technical limitations to letting
the ~forwarding address be the deciding switch, can the switch
be defined in the PMDF option file.

Thanks,

Dave Mulvihill      (Postmaster)        Allin1: MULVIHILL DP
Systems Programmer                      Email:  dpmsys@ritvax.BITNET
Information Systems & Computing                 dpmsys@ritvax.isc.rit.edu
VAX/VMS, ULTRIX Technical Support
Rochester Institute of Technology, Rochester NY, 14623 (716) 475-6993
From: portia@innosoft.com (Portia Shao)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problems with multiple messages to the cc:Mail gateway.
Date: 31 Aug 92 20:39:45 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 31 Aug 1992 13:39:45 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: service@INNOSOFT.COM, ipmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO8EU0JUOY95OW41@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SMITH%NYUMED.BITNET@ymir.claremont.edu"
X-Vms-Cc: IN%"service@innosoft.com",IN%"ipmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>I have been having some problems with the cc:Mail channel that we are trying
>to get to work.  A series of messages sent to the ccmail channel should yield
>an output file with the messages being sent appended to oneanother.  What is
>happening is that the first file is created ('cc_output.dt' in this case)
>just fine (see first log). But the output file seems not to be being created
>by cc_master in the second case (see second log file: I put in the DIR to see
>whether there is a new file there: there isn't).  This has got to be a silly
>mistake somewhere.  I changed the names of the in and out files in the option
>file just to be sure I had not picked a silly name: same effect.
>
>This is V4.1-10, with the cc_master.exe re-linked.

cc_slave needs to be relinked also in V4.1-10.

Please check your master.com, you should have the following in the cc:Mail
section, there was a line which could be missing.

$   if f$search("pmdf_root:[queue.''channel_name']*.%%;") .nes. ""
$   then
$     if f$search(ccoutfile) .nes. "" then -
        rename/log 'ccoutfile' 'ccoutfile'-tmp-save
$     define/user option_file        pmdf_root:[table]'channel_name'_option.

Did you have the above line? it was missing in some earlier versions of
master.com (and it did not show up in your log file)

$     run pmdf_root:[exe]cc_master.exe

>
>--------------- Option file ------------------------------------------
>CC_OUTPUT_FILE_NAME=SYS$APPLE:[SMITH]CC_OUTPUT.dt
>CC_INPUT_FILE_NAME=SYS$APPLE:[SMITH]CC_INPUT.dt

I assume you also have the CC_GATEWAY_NAME line in your option file.


		/portia
		portia@innosoft.com	(714)624-7907
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Digested lists and the Notes channel
From: Ned Freed <ned@innosoft.com>
Date: 11 Sep 1992 12:54:40 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Sep 1992 12:54:40 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GONQGXAK3M984OSY@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"BOWMAN_BRETT_E@LILLY.COM"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

There currently isn't any way of undigestifying messages before passing
them to NOTES. I asked about this publicly when I originally developed
the channel and the general repsonse was that undigestifying was Wrong
and possibly even Evil. Since I'm not a VAX NOTES user I don't have any
real opinion myself, so I elected not to provide such an option (I do have
lots of other things to do...). I have since encountered (as expected)
people who think such a thing would be nice to do, but too late for
anything in V4.1. It is on the list for V4.2.

If you saw the code necessary to do a good job of this you'd understand
why it is far from trivial. We're talking roughly 2000 lines of code
here to handle all the cases (MIME digest format plus all the older
formats). Fortunately this code exists in PMDF for other reasons; it is
only necessary to fit a bunch of calls into the NOTES channel to make
use of it.

				Ned
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: `Disconnected' remote PhoneNet dial-in processes
Date: 1 Sep 92 18:47:18 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 01 Sep 1992 11:47:18 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO9PSVL3K295OZ1I@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 often have a half dozen disconnected processes (sometimes more) from
> the same remote site which dials into our node for PhoneNet msg transfer.
> Nothing really goes wrong, but these disconnected processes are eating
> some resources while they hang around waiting to time-out.

It sounds to me like your slave jobs are chattering on the terminal port as
they shut down. There should be no output at all between the time that the
PhoneNet end command arrives and the session logs out completely. It therefore
should not matter if the port gets disconnected or not since this will not
affect the proper termination of the job.

You might want to try to connect to one of these things and see what output
they produce. I can think of no simpler way to find out what's stuck in the
buffers.

> The scripts all end with `go' and `end' lines.  Examining, at the other
> end, the di_<channel>_master.trn files shows them sending the `end'.

This has nothing to do with the script -- there is no script on the slave end.
This is the PhoneNet "end" command you're seeing in the transcript. Once that
command is seen and ack'ed by the slave things start shutting down and should
not produce any additional output from the slave.

> I vaguely remember seeing something about this a long time ago.  A bug?
> A bug that was fixed in some release?

There was a bug that prevented scripts from taking control back after the
PhoneNet transfer is complete. This would only affect attempts to reset
terminal lines things on the master side, however. As far as I know there has
never been a bug that would cause this sort of behavior. I have seen cases
where this happens and it has always been traced back to a situation where
there was some spurious output from the job.

> The remote system is running 4.1-9 and this system is running 4.1-6.

This should be the same even if you were running PMDF V2.4.

					Ned
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:05:04 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Sep 1992 19:05:04 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOJWKFNVW296VVY1@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 has multiple entries for each node.  Could I have answered
> one ...

Those multiple entries are indeed correct.  If you look carefully, you will
see that the multiple entries are not duplicates and do quite different things
depending upon the source of the address ($E$F -- envelope, forward pointing
address; $S..$Q -- fail of host not from source route, fail if not sending
to specified channel; etc.).

Dan
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Help.  list.exe going crazy?
Date: 1 Sep 92 18:10:18 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 01 Sep 1992 11:10:18 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO9NVTZ6B695P0TF@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DMPM%DUKEMC.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Your problem is that your homebrew channel isn't working properly. It must
remove the entries for the messages it processes from the queue cache. When
you don't remove the entries LIST (and everything else in PMDF) has no
way of knowing that the entries are gone. As such you are left with the
list of all messages that have ever been processed on the channel, and the
list will continue to grow without limit over time.

You need to either rewrite your channel to use PMDF's QU routines (this is
the way to do it that we can possibly support) for dequeuing or you can
use the OS routine os_qu_delete_outbound to delete the entries as you
process them.

The reason why I say that the QU routines are the only reasonable way to
do this is that the queue format PMDF uses is subject to change without
notice. It changed fairly substantially in PMDF V4.1 (I bet you didn't
realize this) and is very likely to change even more in the future. Programs
written to the old format sort of work because the new format is only
used in some cases and is backwards compatible. But this may not be
true in the future.

The reason why you don't always see the huge list of messages is simply
the difference between immediate processing jobs and periodic jobs.
Immediate jobs only process the messages they were queued to deal with. Older
messages are invisible in this case, so you don't see all the phantoms. But
if a periodic job runs it sees all queued messages and that's when the
huge list appears.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problems with cc:Mail channel.
From: Ned Freed <ned@innosoft.com>
Date: 14 Sep 1992 01:13:48 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 01:13:48 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOR8UYPZKY984UOA@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"andrewr@itd.adelaide.edu.au"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

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

You might want to check the online documentation -- it may be more
complete even in the early release you have.

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

> 	Now, according to "help errors supersede", this message
> indicates a success state after redefining the logical name
> OPTION_FILE, and requires no user action.

Correct. This error is irrelevant.

> As such, the first thing of
> note is the Pascal error message.

Correct. This is a problem that was fixed in -10 or thereabouts.

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

It is.

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

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.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: default host name as foreign host
From: c.santana@cgnet.com
Date: 14 Sep 1992 23:19:38 -0600 (CST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 23:19:38 -0600 (CST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOSH2OEA369FMGF1@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I have been attempting to do the following:
	In VMSmail, addressing a message To: in%username
					     (no quotes or host/domain)

Instead of this being translated to:  username@localhost.localdomain,
I would like it to always translate to a particular foreign host.domain.

I have tried setting the official-host-name of my local channel to
the foreign host, and then adding the local host name as the
local-host-alias for EVERY channel in the channel/host table.
This did not work (the FROM address of a local message was always
assigned to the foreign host/domain) and also seems a bit unelegant,
if not downright dangerous.

Has anyone done this or have any ideas about how it could be done?

-Steve Ross, CGNET

NOTE:  REPLY-TO: sross@cgnet.com  (not where this msg came from)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Digested lists and the Notes channel
From: Mark_Strawcutter <mjstraw@grove.iup.edu>
Date: 11 Sep 1992 20:42 -0400 (EDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Sep 1992 20:42 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOO0JYPG5U984PYY@YMIR.CLAREMONT.EDU>
X-Organization: Indiana University of Pennsylvania
X-Vms-To: NetMail%"NED@INNOSOFT.COM"
X-Vms-Cc: IN%"info-pmdf@ymir.claremont.edu"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>There currently isn't any way of undigestifying messages before passing
>them to NOTES. I asked about this publicly when I originally developed
>the channel and the general repsonse was that undigestifying was Wrong
>and possibly even Evil.

Boy, I must have missed that discussion.  I couldn't disagree more.

>                        Since I'm not a VAX NOTES user I don't have any
>real opinion myself, so I elected not to provide such an option (I do have
>lots of other things to do...). I have since encountered (as expected)
>people who think such a thing would be nice to do, but too late for
>anything in V4.1. It is on the list for V4.2.

It really is a nice fit to VAXnotes.  The TOC at the beginning of the
digest becomes x.0 and each article is x.n.  If the whole digest was one
big note, if you wanted to look at article 15 you'd have to scroll down
thru all the preceeding text.  With it undigested you can "next reply"
thru quickly or count the TOC lines and go right to it.

----------
Mark J Strawcutter                           BitNet:    MJSTRAW@IUP
Director, Systems and Communications         DNS (mx):  mjstraw@grove.iup.edu
Indiana University of Pennsylvania           Voice:     (412) 357-4000
Indiana, PA   15705                          "you can't nail jello to a tree"
From: klensin@infoods.mit.edu (John C Klensin)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Handling of aliases via Option Name_table_name
Date: 3 Sep 92 15:33:43 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 03 Sep 1992 19:33:43 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: KLENSIN@INFOODS.MIT.EDU, IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOCSRHLY8Q95P7IG@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-Vms-Cc: IN%"KLENSIN@INFOODS.MIT.EDU", IN%"IPMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>

Ned,
  Thanks very much for the quick response.

  My last question wasn't clear....
> (2) Is there any reasonable way to test whether such a search resulted
> in a "hit?".  It appears that one might be able to do this with a
>   $[image,...]
> rule that searched the logical name table itself, but is there an
>
>The PMDF TEST/REWRITE utility lists the expansion of any address you give it at
>the very end of its output. This takes all alias expansion into account. In
>general aliases don't expand into headers, so they don't show up in the earlier
>output of PMDF TEST/REWRITE that pertains to what headers would look like.

Sorry... The requirement is a production one, not a "test" one.  In
essence, I'm trying to construct a rule that sends things out one
channel if they map onto aliases specified by a particular logical name
table, and out another channel if they aren't found there.  I'm actively
trying to translate the requirement into some more reasonable form, but
have not yet been successful in doing so.

   john
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Limiting access to outgoing mail.
From: Ned Freed <ned@innosoft.com>
Date: 14 Sep 1992 11:45:12 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 11:45:12 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GORUWMYCQA984WO4@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"TERRY@spcvxa.spc.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Yes, putting notices 1 on the d_noexquota channel should have the desired
effect of returning messages after one day. The effect will not carry
over to any other channels.

I have completed the changes necessary to get noexquota to work right. We
are running it on a couple of systems for testing. If all goes well the
changes will go into the -13 revision level for PMDF V4.1.

				Ned
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: `Disconnected' remote PhoneNet dial-in processes
Date: 2 Sep 92 15:35:45 GMT
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 02 Sep 1992 11:35:45 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@INNOSOFT.COM
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOAWT3EF1E9FM9Y1@INNOSOFT.COM>
X-Vms-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-Vms-Cc: IN%INFO-PMDF,TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> It is stuff coming out of the slave process. The way this works in PMDF is
> that SLAVE exits and then SLAVE.COM stops the process. If, for instance, you
> have SET VERIFY enabled, there will be noise from the command file that will
> go out on the line.

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

> 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?  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.
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Limiting access to outgoing mail.
From: Ned Freed <ned@innosoft.com>
Date: 14 Sep 1992 12:12:07 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Sep 1992 12:12:07 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GORVUN8ZN6984V1V@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"TERRY@spcvxa.spc.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

One additional point -- when I was testing the new quota code I happened
to try delivering mail across a DFS disk connection. The quota check
failed because the proxy account on the remote node has EXQUOTA (it has to
have it) and DFS didn't know that I had EXQUOTA privilege temporarily
disabled on the client side. So you can add proper handling of both
holdexquota and noexquota to the list of things DFS breaks when you
try to deliver mail across it.

This is all to one side of Terry's original questions (and answers) but
since DFS was discussed on info-pmdf recently I thought I would mention
this.

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

> > It sounds to me like your slave jobs are chattering on the terminal port as
> > they shut down. There should be no output at all between the time that the
> > PhoneNet end command arrives and the session logs out completely. It therefore
> > should not matter if the port gets disconnected or not since this will not
> > affect the proper termination of the job.

> I'm confused.  It's at the slave end that I'm seeing the disconnected
> processes.

Sure. The master job is a batch job. It cannot disconnect.

> You're saying that once the slave job receives the `end'
> it should always ``log off'', independent of what happens to the line.

Correct.

> What does that have to do with ``chattering on the terminal port''?  Is
> this chattering something you picture coming from the slave computer or
> going to the slave computer?

It is stuff coming out of the slave process. The way this works in PMDF is that
SLAVE exits and then SLAVE.COM stops the process. If, for instance, you have
SET VERIFY enabled, there will be noise from the command file that will go out
on the line.

> > You might want to try to connect to one of these things and see what output
> > they produce. I can think of no simpler way to find out what's stuck in the
> > buffers.

> By that do you mean I should dial into the slave computer, log into the
> PhoneNet account, and pretend to be the master end of the connection?
> If so, I guess I can figure out how to do that, after making sure that
> there is nothing queued at the master end for transmission.

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.

				Ned