HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Sun, 30 Aug 92 03:22:20 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: PMDF-MR, MIME, WPS-Plus format attachments
X-To:         bob@camb.com, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

The notion of doing an alternative conversion for WPS-Plus has been on
the to-do list for about a year now. There is nothing wrong with this
approach that I can see. Expect to see something implementing it in the
next release.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"WITTWER@tech.ascom.ch"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 26 Aug 92 11:14:43 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: vrfy and expn commands
X-To:         WITTWER@tech.ascom.ch, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

You'd better have you sendmail guru reread the relevant RFCs and
explain in some detail why the results you cite are incorrect. As far
as I know PMDF fully supports both VRFY and EXPN to the full extent
possible. sendmail offers nowhere near comparable support for these
commands.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Duke University Medical Center, Durham NC, USA
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@ymir"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 28 Aug 92 19:44:46 GMT
From:         "James Dryfoos - Postmaster" <DMPM@DUKEMC>
Subject:      More on (Any status returned by $ PMDF SEND command in 4.1?)
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>I would like to use PMDF SEND command under program control, but
>cannot find any sort of return status on failure (except for the text message).
>Is there anything like deliver_status and deliver$message in this facility?
>Even upon failure (such as bad address) $status is 1.
>This is a much needed feature.
>
>Thanks,
>
>Jim

I would like to change this a bit.  Some failures do result in an error in
$status.  However, my problem is:

%PMDF-E-ALLADDRBAD, All addresses specified are bad; message not sent
$ stat = $status        !Does $status return anything - no
$ sho sym stat
  STAT = "%X00000001"

-Jim
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Tue, 1 Sep 92 01:46:07 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Reprocessing channel
X-To:         D.Nash@utexas.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Tue, 1 Sep 92 07:48:42 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Mail-11 delivery and soft-vs-hard failures
X-To:         bob@camb.com, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

The code to determine whether or not a given error is temporary or
permanent is deeply buried in the internals of the VMS mail foreign
protocol interface. This code is not shipped with PMDF as a rule (it is
available under nondisclosure). The code is extremely complex since these
are not simple numbers -- they are strings and have to be parsed to obtain
their content.

This error in particular is also produced when a forwarding address is
broken on receiving system's side of things. This can in fact be a
consequence of the system not being fully initialized, so it does happen
at completely transient times. It is therefore inappropriate to reclassify
this particular error as permanent. Classification of errors is very tricky
because you have to know all the circumstances that can produce the error.
(My personal favorite is the "no such device" error, which you might think
would be permanent, but turns out to be what you get when some network
software is temporarily shut down!)

                                Ned
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:         Sat, 29 Aug 92 03:23:19 GMT
From:         "Donald L. Nash" <D.Nash@UTEXAS.EDU>
Subject:      Reprocessing channel
X-To:         info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

There are several references to the reprocessing channel in the PMDF V4.1
documentation (both on-line and printed), especially in the description of
the expandlimit channel keyword, but there is no documentation about the
reprocessing channel itself.  I'd like to use expandlimit and the
reprocessing channel, but I don't know what is necessary to set up the
channel.  Can anyone provide some enlightenment?

                                Thanks,

                                ++Don Nash

Internet: D.Nash@utexas.edu     The University of Texas System
BITNET:   DON@THENIC            Office of Telecommunication Services
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@INNOSOFT.COM"
X-VMS-Cc: 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>
Date:         Mon, 31 Aug 92 04:01:23 GMT
From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: RE: vrfy and expn commands
X-To:         NED@INNOSOFT.COM
X-cc:         IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

Ned,
  We are very much in agreement on all of this, although (perhaps as usual)
not for the same reasons.
  One possible suggestion for some future release...
  Given that RFC1123 provides for disabling these things for security
reasons, would it be sensible to have a per-list attribute that could be
set to, e.g., NOEXPN so that one could selectively protect lists?  Seems
more straightforward than hiding them behind aliases, and it seems to me
that a clear "no, you don't get any information" message would have
advantages in at least some situations.
  This would also presumably disable MAILSERV SEND/LIST if applied to
one of those lists.
   As I think about this, it may be that the right list analogy to
VRFY isn't EXPN but some new command that would take the list name and
a mailbox address and return, like VRFY, an indication as to whether or
not that address was on the designated list.  Slightly more invasive
than VRFY, but not nearly as much so as EXPN.  Maybe someone should find
an SMTP Extensions WG and propose it to them :-).
     --john
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", IN%"NED@INNOSOFT.COM"  "Ned Freed"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 31 Aug 92 16:04:03 GMT
From:         "Jeffrey J. Carpenter" <jjc+@PITT.EDU>
Subject:      RE: Holding Mail
X-To:         IPMDF@YMIR, Ned Freed <NED@INNOSOFT.COM>
Newsgroups: bit.listserv.pmdf-l

Excerpts from mail: 30-Aug-92 Re: Holding Mail Ned Freed@INNOSOFT.COM (410*)

> The usual way to do this is to associate the machine with a channel of
> its own and then set the notices intervals for the machine to either
> very large or very small values. This has the effect of either holding the
> mail or bouncing it more or less immediately.

> The PMDF_HOLD stuff may work and you are welcome to try it, but it is
> largely a holdover from times when we didn't have notices intervals.

>                               Ned


Can you specify a different interval on a channel by channel basis?  I
couldn't see how to do this in the manual.



        jeff
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Concordia University Information Systems, River Forest, Il.
X-PS-Qualifiers: /BOTTOM_MARGIN=12/FONT=COURIER/LEFT_MARGIN=9/SIZE=12
                 .0/TOP_MARGIN=36
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@innosoft.com"
X-VMS-Cc: HELMKE
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 3 Sep 92 19:12:06 GMT
From:         Rich <HELMKE@CRF.CUIS.EDU>
Subject:      Using PMDF to deliver printer files
Newsgroups: bit.listserv.pmdf-l

    We have a number of small satellite VAX/VMS systems all over the
    USA that we remotely support via dialup logins and PMDF e-mail.

    We are investigating the possibility of setting up a home grown
    implementation of something that acts like DQS, but uses PMDF
    (dialup PhoneNet) and DELIVER instead of a DECNet connection to
    transfer print files.  We are facing the fact that even a modest
    file (without any graphics--just line printer ASCII of 200-1000
    blocks) will take many minutes to transfer so we must consider a
    data compression utility as well.

    Has anyone "pushed the envelope" with PMDF and associated
    utilities to deliver files to remote printer queues?  Any
    suggestions for implementation (or pit falls)?

    Thanks for your help,
    Rich Helmke
    Associate Director
    Concordia University Information Systems
    708/209-3221
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:         Fri, 4 Sep 92 07:54:11 GMT
From:         Jeremy Begg <JEREMY@VSM.COM.AU>
Subject:      Erroneous output from CONFIGURE.COM
Newsgroups: bit.listserv.pmdf-l

I recently installed PMDF V4.1-2 and used the CONFIGURE.COM procedure to
generate the initial configuration.  I have found two problems with it so
far, which other people might like to know about.

1) The local host information didn't work.  Here's part of CMDF.CNF:

!
! Rewrite rules for the local host/VAXcluster
!
SERF                            $U@r.s.g.a
SERF.r.s.g.a                    $U@r.s.g.a
WKVA                            $U@r.s.g.a
WKVA.r.s.g.a                    $U@r.s.g.a
WKVB                            $U@r.s.g.a
WKVB.r.s.g.a                    $U@r.s.g.a
WKVC                            $U@r.s.g.a
WKVC.r.s.g.a                    $U@r.s.g.a
r.s.g.a                         $U@r.s.g.a

l nox_env_to defragment charset7 us-ascii charset8 iso-8859-1
r.s.g.a

The "r.s.g.a" rule was not generated by CONFIGURE.COM: when I tried to
send a message to myself on SERF (the node I had just installed PMDF on) it
resulted in an infinite bounced message loop, which didn't go away until I
added the "r.s.g.a" rewrite rule.


2) I  included a few DECnet-mail hosts:

!
! Rewrite rules for the D (MAIL-11) channel
!
paper                                   $U@paper
pencil                                  $U@pencil
ruler                                   $U@ruler

d 733 nox_env_to defragment linelength 255 charset7 us-ascii charset8 iso-8859-1
DECNET-MAIL
paper                                   paper
pencil                                  pencil
ruler                                   ruler

But when I tried to send a message to a user on PAPER, the message was
encoded using BASE64 and was not readable:

>From:   SNAGWY::IN%"SYSPRGG@r.s.g.a"  "Jeremy Begg"
>To:     IN%"sysprgg@paper"
>CC:
>Subj:   This time the test is to paper
>
>Return-path: <SYSPRGG@r.s.g.a>
>Received: from r.s.g.a by r.s.g.a (PMDF #2395 ) id
> <01GODRIN20PYAXB0VS@r.s.g.a>; Fri, 4 Sep 1992 09:38:15 +0930
>Date: 04 Sep 1992 09:38:15 +0930
>From: Jeremy Begg <SYSPRGG@r.s.g.a>
>Subject: This time the test is to paper
>To: sysprgg@paper
>Message-id: <01GODRIN2K0OAXB0VS@r.s.g.a>
>X-VMS-To: IN%"sysprgg@paper"
>MIME-version: 1.0
>Content-type: TEXT/PLAIN; CHARSET=US-ASCII
>Content-transfer-encoding: BASE64
>
>QW5vdGhlciB0ZXN0LCB3aXRob3V0IGEgZG9tYWluIG5hbWUuDQoNCg==

The original message was just a line of text.

The first problem I could fix myself, but I don't know what to do about the
second.

Thanks,

        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: Fox Chase Cancer Center
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, 4 Sep 92 02:49:28 GMT
Comments:     Warning -- original Sender: tag was NETNEWS@AMERICAN.EDU
From:         stodola@ORION.FCCC.EDU
Subject:      Strange forwarding problem.
Newsgroups: bit.listserv.pmdf-l

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.

--

stodola@fccc.edu -- Robert K. Stodola (occasionally) speaks for himself.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"SKIPPER%MEDCOLPA.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 29 Aug 92 05:30:11 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: PMDF 4.1 L Channel error message (bad prolog??)
X-To:         SKIPPER@MEDCOLPA, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

You seem to have all the information that's available -- the process
clearly was not able to log in due to an error in the system authorization
file. This may well have been a transient problem of some sort. You might
want to ANALYZE/RMS your authorization file to make sure the problem is
really transient in nature.

In any case, this was a problem with the login process and not with PMDF.
It could just as easily happened to any job (PMDF or otherwise).

                                Ned
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"
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>
Date:         Thu, 27 Aug 92 21:38:15 GMT
From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject:      4.1 configuration on upgrade
X-To:         info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l


Since I did an upgrade from 4.0 to 4.1, my PMDF.CNF file was essentially
preserved, and it looks like a number of interesting and/or important
4.1 options did not make it into it.

(1) General question:  What should I (and others in this situation) be
looking at wrt to adding to/changing the CNF file that isn't discussed
in the upgrade instructions in the installation guide (almost nothing
is) or in the "new features" list and that is not obvious from looking
at the new list of channel keywords.  I know this sounds like a "what
should I know that I don't" question, but it really isn't--it is closer
to "what of this sort was left out of the documentation and release
notes that would have been there if people had more time".

(2) Specific question: A new automatic config (looking another host on
which a new 4.1 installation was done) seems to generate  "defragment"
and "reprocess" channels and to use these as keywords. They are not in
table 3-10, the channel keyword list, nor are they in  the index.    I
can guess what these might be, but, for those of us upgrading older
configurations, pointers to specific documents or other suggestions
about how these are used, how they are supposed to be entered into the
PMDF.CNF file, etc., would be appreciated.

(3) Is it possible to run CONFIGURE.COM from a user process in what
might be thought of as a test environment, putting the output files into
a user directory?  This would be extremely useful for comparing the
incrementally-upgraded configuration files for a running system with
those that the 4.1 configuration generator would produce de novo.  If
not, can we get this as a request into some appropriate development
queue?

(4) I fear this has already been answered, but, if so, I've misplaced
the answer, for which I apologize.  The release notes indicate the
availability of a mechanism for restricting who can post to lists.  I
have a vague memory to a keyworded attribute list out at the end of
an alias as the syntax.  Could you folks review this feature or point to
some documentation I haven't been able to find?

  thanks,
  --john
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
Organization: SUNY at Buffalo, Systems group
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:         Sun, 23 Aug 92 10:30:33 GMT
Comments:     Warning -- original Sender: tag was NETNEWS@AMERICAN.EDU
From:         tkslen@UBVMS.CC.BUFFALO.EDU
Subject:      pmdf v4.1-1 and slow delivery
X-To:         ipmdf-newsgate@mccall.UUCP
Newsgroups: bit.listserv.pmdf-l


I just installed vms v5.5-1 and pmdf v4.1-1 on monday.  Ever since then it
seems
my queues build during the day (all of them from the local to the bitnet and
internet queues) then during the night they catch up.  I feel this is from the
low volume of new mail during the night.
Anyone have any idea's of what could be causing the performance problem.  The
cpu the queue is running on not 100% loaded.  The log files from the delivery's
show no errors, just successful delivery's.
When I installed pmdf all I did was run bitnet_domains.  Should I have run
something else?

Anyways, thanks in advance,
  Lenny
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@INNOSOFT.COM", in%"IPMDF@YMIR.CLAREMONT.EDU"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 31 Aug 92 19:12:22 GMT
From:         "Donald L. Nash" <D.Nash@UTEXAS.EDU>
Subject:      RE: Reprocessing channel
X-To:         NED@INNOSOFT.COM, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

>There's no explanation of the reprocessing channel largely because there's
>very little to explain.

Yes, but it is still rather hard to know this if it isn't written down
somewhere.  I think this is worth mentioning in the "Other Channels" chapter
of the manual, even if it is only one paragraph.

Anyway, thanks for the explanation.

                                ++Don
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Tue, 1 Sep 92 23:34:21 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: `Disconnected' remote PhoneNet dial-in processes
X-To:         bob@camb.com, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

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