HDTenEightyP/NetNews huggingface dataset:
From: dmpm%dukemc.bitnet@ymir.claremont.edu (James Dryfoos- Postmaster)
Newsgroups: vmsnet.mail.pmdf
Subject: Moving mail from one channel to another.
Date: 17 Dec 92 17:27:40 GMT
Organization: Duke University Medical Center, Durham NC, USA
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 12:27:40 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSF1JA15LU90MXBC@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

We recently switched from using Wollongong's tcp/ip to UCX.
All is working, but I notice some old mail n the WTCP_LOCAL
channel.  Is there a way to move the to the CTPC channel so it
will get processed?

-Jim

  ==========================================================================
     James D. Dryfoos                   |  E-Mail:
     Medical Center Information Systems |    dryfo001@mc.duke.edu
     Duke University Medical Center     |    dryfo001@dukemc.bitnet
     Box 3900 DUMC                      |  (919) 286-6391 - Office
     Durham, NC 27710 USA, Earth        |  (919) 286-6369 - Fax
  ==========================================================================
From: flep@net.ccd.bnl.gov (Frank Lepera 516-282-4183)
Newsgroups: vmsnet.mail.pmdf
Subject: Queued mail messages.
Date: 14 Dec 92 12:59:05 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 08:59:05 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSANBV34DE8ZKDVI@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"Info-PMDF@Ymir.Claremont.Edu"
X-Vms-Cc: FLEP
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Folks...

How can I find out WHY a mail message is being queued??

Frank Lepera
Brookhaven National Lab.
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Second l channel?
From: "Joel D. Kraft" <kraftjoel@bvc.edu>
Date: 14 Dec 1992 23:29:55 -0600 (CST)
Organization: Buena Vista College
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 23:29:55 -0600 (CST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSBJVWQQEQ8ZLJ7A@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KVC@SUMMER.INNOSOFT.COM"
X-Vms-Cc: IN%"info-pmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>Don't use a dn_ channel, that will not run the correct channel program.  You
>need to use a "d" or "d_" channel for this.  A "d" channel is normally used to
>support DECnet MAIL-11 for remote DECnet nodes that do not have PMDF.  It turns
>out that PMDF supports remote DECnet MAIL-11 nodes simply by handing the
>message
>to VMS MAIL, which makes the network connection and does the transfer.  If
>the address has no remote node then this devolves to being the same as a local
>VMS MAIL delivery -- hence the use of a "d" channel for alternate local
>delivery.

>If you are already using a "d" channel and you don't want its configuration to
>change for this purpose, go ahead and create a "d_headers" or something channel
>(everything after the "d_" can be whatever you like).

Okay, this is close, but when trying this I see that the "d" channels parse
the user@host format in its entirety interpreting the host as a decnet node
name, while the "l" channel will strip off the "@host" portion.  What is
the best way to set up the rewrite rules in our homogeneous cluster (which
shares the PMDF configuration) to get the decnet hostname to work properly.
I'd prefer not to write a rule for each node to get it to work out
properly.

May I also suggest adding support for multiple "l" channels...

Thanks,
Joel D. Kraft
System Manager
Buena Vista College
Newsgroups: vmsnet.mail.pmdf
Subject: RE: REPLY-TO: handling on PMDF-MR gateway
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 18 Dec 1992 18:28:27 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Dec 1992 18:28:27 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSGYO5WVFM90N6LE@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DPMSYS%RITVAX.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Does the PMDF-MR channel handle processing of the REPLY-TO:
> headers so that replying in Allin1 will send to the REPLY-TO:
> address?

Reply-To: headers are mapped into the inReplyTo Message Router and/or X.400
field. This is in accordance with RFC1327. The information is therefore
present; I don't know whether ALL-IN-1 IOS can get at it or not. MailWorks
definitely can; use REPLY/LIST in the character cell client. It currently isn't
possible to specify that /LIST is the default in MailWorks; I hope this is
added to a future release.

> I've set up a list in my aliases file with the reply-addr
> specified as the list address.  For VMSMAIL recipients PMDF
> rewrites the from address,  other recipients receive the
> mail from the sender, but their mailer processes the REPLY-TO
> headers and sends replys to the list.

Proper processing of Reply-To: is an essential element of proper UA behavior
behavior. If ALL-IN-1 IOS doesn't do this by default it should be possible to
customize it do to it.

> Recipients who receive mail from this list via the PMDF-MR
> channel recieve it from the sender and no processing of the
> REPLY-TO address seems to occur.

> Can I configure this somewhere?

I hope you can configure this in ALL-IN-1 IOS. We do not plan to add an option
to map Reply-To: into MR FROM information; this would be a flagrant violation
of RFC1327.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: PMDF Installs in a Heterogeneous VAX Cluster
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 15 Dec 1992 10:20:20 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Dec 1992 10:20:20 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSCARB4FF68ZLTHQ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"GREENBJB%SNYONEVA.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Section 1.3.2 of the PMDF manual explains how to install PMDF on two nodes in
> a heterogeneous cluster.  I think I understand it but want to make sure.

> I currently have PMDF running on one node no problems.  I now want to install
> it on the other, each having their own QUEUE, LOG, TABLE, etc. directories.
> In fact, they will be on different disks. I realize I could share the EXE
> directory but don't know how if PMDF_ROOT has to point to a different place
> on each node. So lets say I will have two of those also.

> I now have the PMDF startup files in my SYS$COMMON:[000000.SYS$STARTUP] dir
> from the first install.  This points the PMDF_ROOT to the correct place for
> the current install.  When I install the second node, won't it will overwrite
> (create a new version) of this file since the nodes share a common startup
> disk.  Don't I have to break up the startup so the two startups are in
> specific not common areas?

After doing one install, simply move the PMDF_STARTUP.COM and
PMDF_SUBMIT_JOBS.COM files to system specific directory of the SYS$STARTUP:
directory tree.

> The manual says the startup files will be installed in the specific areas but
> that is not what appears to have happened with my first install.  Did I miss
> something?

I am not aware of the manual ever claiming that the startup files will be
installed in specific areas.  It merely states that they will be stored in the
SYS$STARTUP directory which out being any more specific.  For 90% of PMDF
installs, storing the files in the common SYS$STARTUP is the correct action.
For non-homogeneous clusters, we leave it to the installer to move these
startup files.  This is mentioned in paragraph 3 of the VAXcluster installation
section.

> Does it sound like I know what I'm doing? Anything else to worry about?

Yes, you sound like you're aware of all of the issues and doing the right
thing.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Second l channel?
From: "Kevin V. Carosso" <kvc@summer.innosoft.com>
Date: 14 Dec 1992 21:21:22 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 21:21:22 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSBJJ42VOY8ZL36L@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"kraftjoel@bvc.edu"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>>on messages.  I have tried to make a new channel using the MAIL_ prefix name on
>>the channel, but any delivery on that channel crashes with this error:
>
> Use a d or dn_ channel for a second local channel.

Don't use a dn_ channel, that will not run the correct channel program.  You
need to use a "d" or "d_" channel for this.  A "d" channel is normally used to
support DECnet MAIL-11 for remote DECnet nodes that do not have PMDF.  It turns
out that PMDF supports remote DECnet MAIL-11 nodes simply by handing the message
to VMS MAIL, which makes the network connection and does the transfer.  If
the address has no remote node then this devolves to being the same as a local
VMS MAIL delivery -- hence the use of a "d" channel for alternate local
delivery.

If you are already using a "d" channel and you don't want its configuration to
change for this purpose, go ahead and create a "d_headers" or something channel
(everything after the "d_" can be whatever you like).

The "mail_" channel didn't work because these channels are used to support other
foreign mail transports through VMS MAIL.  PMDF unconditionally takes whatever
follows the "_" in "mail_xxxx" and puts it in front of the address with a
percent sign, leading to "xxxx%address".  In your case the foreign transport
prefix didn't match an existing foreign transport, therefore the error.

	/Kevin Carosso
	 Innosoft
Newsgroups: vmsnet.mail.pmdf
Subject: default routing in Jnet V3.6
From: dan@toe.towson.edu
Date: 11 Dec 1992 12:47:19 -0500 (EST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 11 Dec 1992 12:47:19 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GS6S761TIA8ZL0RV@YMIR.CLAREMONT.EDU>
X-Vms-To: ipmdf
X-Vms-Cc: joe,sam
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I just upgraded to Jnet V3.6.  However, before I institute the new default
routing can anyone tell me what its effects on BN_MASTER are?  If I tell TOWSON2
that the default Jnet router is TOWSON1 and then bring up Jnet on TOWSON2
without a JANROUTES.JCP file, what happens when PMDF tries to process a message
destined for BN_MASTER on TOWSON2?

I am assuming, since I haven't seen any warnings on this list about this being a
problem, this should be OK.  I'd like to see it in writing, though, before I go
and install it.

Many thanks.

Dan

P.S. - Effective 12/16, I am leaving Towson State University for a new position
at University of MD Baltimore County.  Though they currently use PMDF on their
administrative but not their academic system - where I am going - I'm afraid I
will be leaving the list (at least until I can convince them they can't live
without PMDF :-).  My account at TSU will still exist for a while so if you wish
to send me email after 12/16, you can still send it here.

   Daniel A. Dinkin
   Network Services Manager                   BITNET: dan@towsonvx.bitnet
   IR Academic Computing                    Internet: dan@toe.towson.edu
   Towson State University                            dan@midget.towson.edu
   Towson, Maryland 21204                UMSA DECnet: toe::e7opdan
   (410)830-3320

     Any thoughts in this message are purely random and my employer had
           nothing to do with them... especially if I was right.
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Moving mail from one channel to another.
Date: 17 Dec 92 16:53:53 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 09:53:53 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSF2G2XH6Q90MXJ2@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

> We recently switched from using Wollongong's tcp/ip to UCX.
> All is working, but I notice some old mail n the WTCP_LOCAL
> channel.  Is there a way to move the to the CTPC channel so it
> will get processed?

Copy the files from the [queue.wtcp_local] directory to [queue.utcp_local]
directory.  In the process, introduce some sort of name change to the files;
e.g.,

   $ copy [queue.wtcp_local]*.%% [queue.utcp_local]*.02

and then run PMDF_ROOT:[EXE]SYNCH_CACHE.

In general you cannot always move files from one queue directory to another
but in this case you should be okay.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE: MCI mail PDMF interface?
From: "Kevin V. Carosso" <kvc@summer.innosoft.com>
Date: 14 Dec 1992 21:37:06 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Dec 1992 21:37:06 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSBK4STOPE8ZLJ0Q@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"rbp@netcom.com"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> does PMDF have a way to talk directly to mcimail?

What does MCI Mail speak?  We may well have some protocol in common with
whatever their service has.

	/Kevin Carosso
	 Innosoft
Newsgroups: vmsnet.mail.pmdf
Subject: RE: default routing in Jnet V3.6
From: "Kevin V. Carosso" <kvc@summer.innosoft.com>
Date: 12 Dec 1992 20:57:48 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Dec 1992 20:57:48 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSBGJ369LU8ZL6Z8@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"Dan@TOE.TOWSON.EDU"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I just upgraded to Jnet V3.6.  However, before I institute the new default
> routing can anyone tell me what its effects on BN_MASTER are?  If I tell
TOWSON2
> that the default Jnet router is TOWSON1 and then bring up Jnet on TOWSON2
> without a JANROUTES.JCP file, what happens when PMDF tries to process a
message
> destined for BN_MASTER on TOWSON2?

Depends a bit on what Jnet default routes mean.  If it is purely a Jnet issue
and has nothing to do with mail, then PMDF won't know or care anything about
Jnet default routes.  I suspect this is the case.

	/Kevin Carosso
	 Innosoft
From: smith%nyumed.bitnet@ymir.claremont.edu
Newsgroups: vmsnet.mail.pmdf
Subject: Encrypted mail
Date: 17 Dec 92 12:19:18 GMT
Organization: NYU Medical Center, 550 First Ave., New York, 10016
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 08:19:18 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSESV4PDLE90MVTG@YMIR.CLAREMONT.EDU>
X-Vms-To: in%"ipmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

A couple of years ago I got a program called ENCRYPT from Wesleyan and have
had it here for a while.  It hasn't been used much until now, but we recently
had a user who wnated to mail encrypted text and asked if this could be built
in directly into mail.  ENCRYPT generates mail-like headers, which potentially
allows decryption on the fly, and might lend itself to incorporation into a
mail package.

Any thoughts on whether this might be something you would consider for the
PMDF user agent, or whether other mailers might support encryption (or
security-enhanced mail, as ENCRYPT calls it).
Newsgroups: vmsnet.tpu
Subject: RE: KEYWORDS: DECFORMS, WYSIWYG, VIDEO EFFECTS, LINE-DRAWING
From: franco@uduniv.cineca.it
Date: Mon, 14 DEC 92 17:51 N
Reply-To: FRANCO@UDUNIV.CINECA.IT
Organization: The Internet
Return-Path: <TPU-Mgr@SHSU.edu>
Errors-To: TPU-Mgr@SHSU.edu
X-Listname: Text Processing Utility (TPU) Language Discussion List
Comments: GMAIL V1.3, DECnet, 21 Mar 1989
X-Original-To: info-tpu@shsu.bitnet, FRANCO

>Original_From: W_COSTA@UNHH.UNH.EDU (Bill Costa - University of NH
>      [+1-603-862-3056])
>Subject: Keywords: DECforms, WYSIWYG, video effects, line-drawing
>
>[...]
>       Using a TPU window, has anyone created a procedure that allows the
>       escape sequences, embedded in a text file, to be sent directly to
>       the display instead of being interpreted? I know this can be very
>       dangerous.  But the reason I would like to do this is to use EVE in
>       READONLY mode on a file that contains flat text with the occasional
>       ANSI video special effect.  An example of such a file would be
>       `terminal' output from VAX Document.  This style of output uses ANSI
>       escape codes to accomplish things like underlining.
>[...]
>
>                         Bill Costa
>

Bill, standard TPU will do it!    8-)

Following TPU command:

SET(TEXT,Current_Window,NO_TRANSLATE)

should do what you want.

Bye
                                                Franco

*****************************************************************************
*  Franco Brunetta, VAX/VMS System Manager, University of Udine, Italy
*  Phone  nr. 39 432 556705  DECnet:   UDUNIV::FRANCO  (37963::FRANCO)
***************************  Bitnet:   FRANCO@UDUNIV.CINECA.IT
** The Lone Manager ! *****  Internet: FRANCO%UDUNIV.CINECA.IT@CUNYVM.CUNY.EDU
*****************************************************************************
Newsgroups: vmsnet.tpu
Subject: Re: Keywords: DECforms, WYSIWYG, video effects, line-drawing
From: "Comet" <comet@us.oracle.com>
Date: Mon, 14 Dec 92 11:42:13 PST
Reply-To: "Comet" <COMET@us.oracle.com>
Organization: The Internet
Return-Path: <TPU-Mgr@SHSU.edu>
Errors-To: TPU-Mgr@SHSU.edu
X-Listname: Text Processing Utility (TPU) Language Discussion List
Original-To: HQPYR1:INFO-TPU@SHSU.edu



I used EDIT/FMS, which may be a precursor of DECforms.  Anyway, the screen
editor there would allow you to edit (...dramatic pause...) ONE SCREEN,
including special graphic renditions and character sets.  There was an option
to do just what you want, namely, to produce an output file which could be used
in a $ TYPE command to display the results directly to the terminal without
requiring any special interpretation outside that performed by the terminal
ROMs.  Perhaps DECforms also has the option to produce such an output file.

The TPU command SET(TEXT,window,NO_TRANSLATE) will allow the specified window
to display control sequences directly to the screen.  Below, I have excerpted
some of the relevent sections from the VAX Text Processing Utility Manual:

    Digital recommends that you use this mode for sending directives to the
    terminal but not for editing. VAXTPU does not manage margins or window
    shifts while NO_TRANSLATE mode is enabled.  Furthermore, VAXTPU does
    not necessarily update lines of text in the order in which they appear
    when NO_TRANSLATE mode is enabled.

    To send escape sequences from within a VAXTPU procedure, you can use
    SET (TEXT) with the NO_TRANSLATE keyword followed by statements using
    the MESSAGE and UPDATE built-ins.  See the example in this built-in
    description for more information on this technique.


--------
Comet <comet@us.oracle.com>             Oracle Corporation
Technical Analyst                       500 Oracle Parkway
VMS Product Line                        Box 659312
Worldwide Technical Support             Redwood Shores, CA  94065-5041

Newsgroups: vmsnet.tpu
From: rryan@panix.com (Rob Ryan)
Subject: Re: forward/backwards clock proposal
Date: Wed, 16 Dec 1992 02:13:53 GMT
Organization: Panix, NYC

I agree: It makes sense to have the taking back of moves to take the time
off the clock too.  Especially if it's affecting the time that the computer
allocates for calculating future moves.  (The computer's searching should
never be compromised because the user decided to take back a move.)  And it
would seem that consistency dictate that you also detract the time from
the users clock, too.

Keeping the time per move in the movelist seems like the most sensible
solution, but clearly the actual implementation is completely up to you.
Incidentally, storing the time in the movelist also opens the potential of
optionally displaying the time consumed on the printed record of the game as
well.

BTW, an excellent program.  Keep up the good work, everybody.

-- 
 Rob Ryan
    rryan@panix.com
Newsgroups: gnu.chess
From: cracraft@ai.mit.edu (Stuart Cracraft)
Subject: Merry Christmas
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 20 Dec 1992 14:31:10 GMT

'
Hi,

This small note is just to wish you and your family a Merry
Christmas and Happy New Year. In these greedy times, it is all
too easy to forget the free things we get in life. Value for
one's money is hard enough to find. But GNU is a very unusual
animal. 

Let's all wish the GNU project the happiest and productive new
year!

	Stuart

Newsgroups: gnu.chess
From: mann@src.dec.com (Tim Mann)
Subject: Re: forward/backwards clock proposal
Organization: DEC Systems Research Center
Date: Sun, 13 Dec 92 00:27:36 GMT

I've thought about this problem, but it wasn't clear to me what to do.
It seems to me that if you are allowing yourself to take back moves,
the clocks don't really mean anything anyway, so you might as well set
gnuchess to take a fixed time per move.

However, since the feature of letting you take back moves is there and
people are going to use it, I suppose it does make the most sense to
give gnuchess back the time it used thinking about replies to the
moves you took back.  It would not be hard to do that in xboard.  I'll
put it on my list of things to do for a future version.  (If you want
this to work when you're using gnuchess without xboard, that's another
story, and it's not my decision whether to implement it.)  Should I
give the human player back his time too?

	--Tim
Newsgroups: gnu.chess
From: mann@src.dec.com (Tim Mann)
Subject: Re: forward/backwards clock proposal
Organization: DEC Systems Research Center
Date: Sun, 13 Dec 92 00:07:41 GMT

I've thought about this problem, but it wasn't clear to me what to do.
It seems to me that if you are allowing yourself to take back moves,
the clocks don't really mean anything anyway, so you might as well set
gnuchess to take a fixed time per move.

However, since the feature of letting you take back moves is there and
people are going to use it, I suppose it does make the most sense to
give gnuchess back the time it used thinking about replies to the
moves you took back.  It would not be hard to do that in xboard.  I'll
put it on my list of things to do for a future version.  (If you want
this to work when you're using gnuchess without xboard, that's another
story, and it's not my decision whether to implement it.)  Should I
give the human player back his time too?

	--Tim
Newsgroups: gnu.chess
From: QUG102@waccvm.corp.mot.COM (Lars Moeller)
Subject: Re: forward/backwards clock proposal
Organization: Motorola
Distribution: gnu
Date: Tue, 15 Dec 1992 17:29:28 GMT

------------------------- Original Article -------------------------
Newsgroups: gnu.chess