Date: Thu,  6 Nov 97 04:06:12 EST
From: Snuffles@kew.com
Subject: UUPC-Info-Request Digest 1997 #17
To: uupc-info-digest@kew.com
Message-ID: <XtnTf7sV2.20D@kew.com>
Reply-To: UUPC-Info-Request@kew.com


UUPC-Info-Request Digest    Thu,  6 Nov 97       Volume 1997: Issue  17   

Today's Topics:
                                1.12s?
                          Alternate SIG file
                   connect in UUPC/extended logfile
                   expire stopped working (2 msgs)
                      Hostpath, SMTP, revisited
         How configure UUPC/Extended for two receiving modems
                    No junk group in UUPC/extended
                        RAS with uupc/extended
                       Supposed bug in uuxqt.c
           Trouble with UUPC/extended EXPIRE 1.12s (3 msgs)
                     UUPC - NASI/INT14 Compliant?
                              UUPC v1.12

To subscribe to UUPC-Info-Digest, send the command in the body of a
message to listserv@kew.com:

        subscribe uupc-info-Digest

To signoff from UUPC-Info-Digest, use "signoff" instead of "subscribe".

You can also send an "index" to the listserv to get an index of back
issues and other files available for retrieval.

Note:  Questions on UUPC/extended itself which are not of general
interest should be sent to help@kew.com, not to the mailing list.
Nor questions should be posted on Usenet, we don't read it.  (Much.)
----------------------------------------------------------------------

Date: Sun, 02 Nov 1997 21:27:57 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: 1.12s?
To: Peter Gahbler <uupcl@pgeck.kiel.org>

Peter Gahbler wrote:
> There was no date in the index file but
> according to the index the actual version is 1.12p, 1.12r is
> located in a directory named test and there is no sign of 1.12s!?
> Could it be the index is completely outdated? Has 1.12s been deleted?

1.12s was on the ftp site (ftp.kew.com) but not on the listserv file
system.  This has been corrected, and UUPC/extended 1.12s can now be
retrieved via the listserv.

-ahd-

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"CP SHUTDOWN" is "Miller Time" spelled sideways.

------------------------------

Date: Sun, 02 Nov 1997 22:18:42 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: Alternate SIG file
To: Walter Medak <ghoti@lao-tse.lcrnet.org>, uupc-info@kew.com

Walter Medak wrote:
> 
> On Wed, 06 Aug 1997 23:00:52 -0500, "Drew Derbyshire - UUPC/Extended Support" <Software@kew.com> wrote:
> 
> > > I'm just wondering where I would put the command to insert an
> > > alternate SIG file when sending email? The docs for 1.12b mention ~A,
> > > while the userid.RC that came with 1.12p mentions ~S to do the alt sig
> > > thing. Which is the proper command?
> >
> > Either.  From the configuration table in configur.c:
> >
> >    {"altsignature", &E_altsignature, B_MUA,     B_TOKEN },
> >    {"signature",    &E_signature,    B_NEWS|B_MUA, B_TOKEN },
> >
> > ~s reads signature, and ~a reads the alternative.
> 
> Okay, but where do I put the command? I've tried the command line and
> all that did was generate email to either ~s or ~a at my domain.

At the prompt:

	Abort, Continue, Edit, List, or Send?

Select Continue enter line input mode, and then enter the ~ command.  


-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"CP SHUTDOWN" is "Miller Time" spelled sideways.

------------------------------

Date: Tue, 4 Nov 1997 13:47:14 -0500 (EST)
From: Drew Derbyshire <ahd@kew.com>
Subject: connect in UUPC/extended logfile
To: ahd@kew.com, jos@snake.xs4all.nl

> From jos@snake.xs4all.nl  Tue Nov  4 13:37:58 1997
> <November 03, 1997> you wrote to Jos Huijnen:
>
>  DD> If you only want to check once in a while, you can use the -t option
>  DD> to trace the entire connection into the linedata.log file.
>
> Thanks. I'll try that one..
>
> Allthough it would be nice to get the connect rate in uucico.log in stead of
> the terminal speed. Sometimes I get CPS's normal for a 14k4 connect. Now I
> can't see if the connect speed is "normal" (except when I always use the -t
> option). Perhaps the CPS is "normal" and the connect speed is really 14k4. A
> defective modem in the modem-bank could cause such a problem.

But is it's more important to the UUCICO program itself to know
what speed it is talking to the modem, for those cases when it must
match speeds (options=autobaud).  Trying to support both this
carrier speed message and autobaud would confuse many users, even
those interested in only one of the two functions.

(Plus, I'm too far behind on everything else related to UUPC/extended.
Just ask Snuffles.)

-ahd-

--
Drew Derbyshire                 Internet:       ahd@kew.com
Kendra Electronic Wonderworks   Telephone:      781-279-9812

 Somebody *please* write an install program for UUPC/extended.

------------------------------

Date: Tue, 04 Nov 1997 18:57:37 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: expire stopped working
To: Sysop <MarchHare@momeraths.org>,

Sysop wrote:
> Yes, I've had the same problem with 1.12s.  It only happened
> occasionally with 1.12r.  I have, after three weeks or so, tracked down
> the problem.  It became obvious after I started writing NoCEM for UUPC
> that it was happening more and more.  The problem is that there are
> missing articles that expire expects to find, according to the history
> file.  

But, but, but ...

I just checked.  The return code of to REMOVE call is not checked, this
should not cause a problem for expire.  Got any other ideas?

> When the article's expiration date comes, expire attempts to
> remove the file, which is not there (see purge_article() for details).
> Obviously, this is a big problem with NoCEM, as that is what it does
> (deletes spammed articles), so I had no choice but to track this down.
> 
> Your options:
> 
> 1.  Run genhist.  That seems to fix it up about 50% of the time.  I
> don't know for sure why it doesn't fix it 100%.
> 
> 2.  Run expire with a short expiry date on each group one at a time.  It
> won't likely fix the problem, but at least you won't run out of disk
> space waiting for it to get over it.
> 
> 3.  Wait.  Sooner or later, you will have all the needed entries to
> satisfy expire.  Of course, you could run out of disk space first, which
> has happened to me about every two days until I was able to patch the
> problem.
> 
> 4.  I will be putting out a patched expire, with all of the diffs, as
> soon as I am satisfied that DBZ is finalized (got a little side-tracked
> with expire).  I will put an announcement in uupc-hackers when it is
> uploaded, which should be soon.  [As a side note, NoCEM should be about
> two weeks or less behind it, knock on wood.]
> 
> Of course, you could delete the entire news directory and start over, if
> things are really out of hand :)

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"An important, but often overlooked, feature of running a computer
system
 is maintaining its security from outside intrusion, internal sabotage,
 and just plain user stupidity."
                          -- Unix System Administration, Fiedler and
Hunter

------------------------------

Date: Wed, 05 Nov 1997 18:47:19 -0500
From: MarchHare@momeraths.org (Sysop)
Subject: expire stopped working
To: uupc-info@kew.com

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 04 Nov 1997 18:57:37 -0500, Drew Derbyshire <ahd@kew.com> wrote:
>Sysop wrote:
>> Yes, I've had the same problem with 1.12s.  It only happened
>> occasionally with 1.12r.  I have, after three weeks or so, tracked down
>> the problem.  It became obvious after I started writing NoCEM for UUPC
>> that it was happening more and more.  The problem is that there are
>> missing articles that expire expects to find, according to the history
>> file.  
>
>But, but, but ...
>
>I just checked.  The return code of to REMOVE call is not checked, this
>should not cause a problem for expire.  Got any other ideas?

Actually, the problem is not checking the return code of REMOVE(). 
Instead, it is calling REMOVE() on a non-existent file.  Normally, the 
file would be present, so the problem won't show for a while.  However, 
let something get munged, such as CHKDSK not liking the way the article 
files are allocated so much it moves/deletes them, and the problem rears
its ugly head.  So, if you stat() the file, it will return 0 if it can 
fill the struct.  Then, it is safe to call REMOVE().  If stat() returns 
- -1, then it could not get the struct info, so the assumption I made was 
that the file is not there.  Therefore, if stat() does not return 0, 
then the only action is to remove the entry from the history file.

Obviously, this is not the only way to tackle this, but it seemed more 
elegant than doing an open/close on the file (which does not guarantee 
it is not hidden, for example).

The really strange part of it is, I was not able to find any code in 
REMOVE() that should have resulted in any system violations, although I 
admit I haven't played much with DosForceDelete().

Hope that's clearer now,
John
- -- 
//------------------------------------------------------------------------
// momerath@apk.net                    sevot yhtils eht dna ,gillirb sawT`
// MarchHare@momeraths.org                 ebaw eht ni elbmig dna eryg diD
//                                           ,sevogorob eht erew ysmim llA
//                                            .ebargtuo shtar emom eht dnA
//                     In case of stupidity, break glass.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850

iQCVAwUBNGEJ4bMHJ4yl8MPNAQHuvgP/aWBTtByoFFHWC7B6vBEKoX3cAJ8/cEYu
iWC9pSJl4hwp6W5F91JewfdNi1UCovh+dFTK8D2RCi4QQ1sqD5Oz8EGAPaDeEYxo
SSQAcDBkKRqQLK0JsPtT7l1XiQY7sqhHzJ1cRYd+GnhnQgfKcp0anKsd1JcOkvcB
UsF96ONowNs=
=xJue
-----END PGP SIGNATURE-----

------------------------------

Date: Mon, 03 Nov 1997 20:07:13 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: Hostpath, SMTP, revisited
To: Sysop <MarchHare@momeraths.org>

Sysop wrote:

As aside, I prefer I get mail from people with first and last names. 
Well, creatures, since I rather like when Snuffles P, Bear sends me
mail.

> OK, after banging my head against the desk enough times, maybe I have
> this right this time.  I've never understood some of the comments about
> calling an external program or passing the mail messages directly to a
> SMTP server until now, I think.  So, this is how I understand it:
> 
> A sysadmin at node N puts the entry into his HOSTPATH file:
>    N | localproc.exe
> 
> The ISP for node N sits and waits for node N to call.
> 
> Node N calls up ISP to receive news/mail (it has been a very light day).
> 
> UUCICO accepts incoming messages.  After disconnect, UUXQT is run.
> 
> mail msg -> UUXQT -> localproc.exe

Nope.

mail.msg --> UUXQT --> RMAIL --> localproc.exe 

> 
> Now, localproc.exe handles the message, say to import to a POP3 server.
> 
> OK, user dials up, pops their mail, reads it and then replies.
> 
> mail reply -> POP3 -> outgoing spool
> 
> Now, a timed program picks up the replies in the spool.

This is a POP3 spool?

> spooled msg -> localproc.exe -> RMAIL -> UUCP spool
> 
> Right?  Since the outgoing message is NOT intended for the local domain,
> it still gets passed to RMAIL and goes into the outgoing spool, yes?
> And, if there are two recipients, one local and one remote, then the
> local recipient would receive it as
> 
> spooled msg -> localproc.exe -> RMAIL -> localproc.exe -> POP3

No, you want to have two programs UUCP2SMTP and SMTP2UUCP, else your
program needs routing smarts.  BAD idea, because it duplicates function.

> I guess I'm just slow sometimes.  However, the above also illustrates
> that the local recipient would most likely receive it three times in
> this example.  Once because the POP3 server would most certainly deliver
> it, once because localproc.exe would probably respool it again before
> passing it to RMAIL and the third time because RMAIL would pass it back
> to it again.


Then the POP3 server has to be smart enough not to queue the local copy
for the POP3 user to either RMAIL or itself.  Keep in mind RMAIL will be
driven by the command line arguments normally -- users can appear in the
header that don't appear on command line (or the reverse).

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

 An elephant is a mouse with Windows NT for an operating system.

------------------------------

Date: Sun, 02 Nov 1997 19:52:00 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: How configure UUPC/Extended for two receiving modems
To: "Dmitry E. Taran" <DMITRY@usbank.kiev.ua>, uupc-info@kew.com

You don't say what the system is.  In any case, on all multi-tasking
systems, you can use the -m parameter to the second UUCICO to listen on
whatever port is defined by the second modem file.

Dmitry E. Taran wrote:
> 
> Dear Drew Derbyshire,
> 
> How I can connect two modems on one UUPC/Extended host?
> 
> For example:
> user calls on the modem1 and begins to transmit
> data, but line breaks.
> User recall on modem2 and continues transfer.
> ---
> Sincerely yours                 Dmitry E Taran
>                                 dmitry@usbank.kiev.ua
> 
> --
> Drew Derbyshire         UUPC/extended e-mail:  software@kew.com
>                                    Telephone:  617-279-9812
> 
>  Steele's Plagiarism of Somebody's Philosophy:  Everybody should believe
>  in something -- I believe I'll have another drink.

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"He sure looks like plant food to me!"          - "Little Shop of
Horrors"

------------------------------

Date: Sun, 02 Nov 1997 21:24:28 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: No junk group in UUPC/extended
To: Peter Gahbler <uupcl@pgeck.kiel.org>, uupc-info@kew.com

There was a problem everything being flagged as having processed by one
group in 1.12r, I think, and fixed in 1.12s. (Which of course, isn't out
yet.)

Peter Gahbler wrote:
> 
> 'Drew Derbyshire - UUPC/Extended Support' schrieb:
> >
> > On Tue, 29 Jul 97 8:22:36 +0200, "Peter Gahbler" <uupcl@pgeck.kiel.org> wrote:
> > > I must have changed something but I don't know what. For some
> > > time I haven't looked at junk. But now I would like to control
> > > which news are junked so I can adjust my active file and/or tell
> > > my feed which newsgroups to omit. Junk is in my active file. The
> > > directory exists. Nevertheless nothing shows up in junk although
> > > I have log entries about undeliverable articles (but 0 junked
> > > articles). Where should I look for the problem?
> >
> > 'junk', not 'Junk', perhaps?
> 
> In fact it is 'junk' although it shouldn't matter. I have tried
> it the other way to no avail.
> 
> > Which version?  There were bugs around ~ 1.12p/1.12r in this regard.
> 
> It is 1.12r now. I used 1.12p former and it worked. Something
> must have changed but I can't find the reason...
> 
> Bye
>     Peter
> 
> --
> Drew Derbyshire         UUPC/extended e-mail:  software@kew.com
>                                    Telephone:  617-279-9812
> 
>  Steele's Plagiarism of Somebody's Philosophy:  Everybody should believe
>  in something -- I believe I'll have another drink.

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"CP SHUTDOWN" is "Miller Time" spelled sideways.

------------------------------

Date: Sun, 02 Nov 1997 20:01:42 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: RAS with uupc/extended
To: Martin Smits <msmits@mindless.com>

Martin Smits wrote:
> Drew Derbyshire - UUPC/Extended Support wrote:
> > On Sat, 2 Aug 1997 12:01:49 MYT+8, "Yvonne Russell"
> > <yvonne@egroup.po.my> wrote:
> > > On NT is it possible to have RAS running with uupc/extended on the
> > > same serial port? I can only get uupc to dial if the RAS is shut
> > down
> > > otherwise it monopolises the port.
> >
> > Not until I get the TAPI version integrated.  Anyone know if it works
> > then?
> 
>   With TAPI this should work. I currently have RAS and a FAX program
> running together (both using TAPI) and they don't bite each other.
> My UUPC connection however goes over the TCP/IP RAS connection, which
> again autodials.

I think the user in question wanted the direct serial outdial of RAS. 
Any takers on that?

--
Internet:       ahd@kew.com             Voice:          781-279-9812

"He sure looks like plant food to me!"          - "Little Shop of
Horrors"

------------------------------

Date: Sun, 02 Nov 1997 21:22:40 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: Supposed bug in uuxqt.c
To: master@master.iaas.msu.su, uupc-info@kew.com

Yup, it's a bug.  I'll sort it out.


Michail Vidiassov wrote:
> 
> Hi, bugs-hunters!
>  If I issue at a remotenode (with commands=all set for)
>   uux mynode!ver ">" remotenode!ver.out
>  the task fails with complains about wrong arguments of uucp.
>  The reason seems to be the following:
>  The the marked line of uuxqt.c looks strange:
> > /*--------------------------------------------------------------------*/
> > /*    d o _ c o p y                                                   */
> > /*                                                                    */
> > /*    Send a file to remote node via uucp                             */
> > /*--------------------------------------------------------------------*/
> >
> > static void     do_copy(const char *localfile,
> >                        const char *rmtsystem,
> >                        const char *remotefile,
> >                        const char *requestor,
> >                        const KWBoolean success )
> > {
> >       if (rmtsystem == NULL)
> >       {
> >           copyLocal(localfile, remotefile);
> >       }
> >       else {
> >
> >           char commandOptions[FILENAME_MAX * 2];
> >           int status;
> >
> >           sprintf( commandOptions,
> >                    "-C %s -a%s %s %s!%s",
> LOOK HERE->                  ^^ -a is not among valid uucp
>                                  parameters
> 
> >                    (char *) (success ? "-n" : ""),
> >                    requestor,
> >                    localfile,
> >                    rmtsystem,
> >                    remotefile );
> >
> >
> > /*--------------------------------------------------------------------*/
> > /*       We don't have a good response to UUCP failing, so we         */
> > /*       pretty much ignore it if it fails                            */
> > /*--------------------------------------------------------------------*/
> >
> >           status = execute( "UUCP",
> >                             commandOptions,
> >                             NULL,
> >                             NULL,
> >                             KWTrue,
> >                             KWFalse );
> 
> Sincerely, Michail Vidiassov
> 
> --
> Katherine Derbyshire
> 
> Kendra Electronic Wonderworks                   support@kew.com
> PO Box 80144                                    phone: 617 279 9812
> Stoneham, MA 02180                              http://www.kew.com
> 
> Have you registered your copy of UUPC/extended? (Don't forget!)
>  Potsdam, New York is too cold a place to wake up alone.
> --
> Drew Derbyshire         UUPC/extended e-mail:  software@kew.com
>                                    Telephone:  617-279-9812
> 
>  Steele's Plagiarism of Somebody's Philosophy:  Everybody should believe
>  in something -- I believe I'll have another drink.

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"CP SHUTDOWN" is "Miller Time" spelled sideways.

------------------------------

Date: Mon, 03 Nov 1997 18:15:11 -0500
From: MarchHare@momeraths.org (Sysop)
Subject: Trouble with UUPC/extended EXPIRE 1.12s
To: uupc-info@kew.com

-----BEGIN PGP SIGNED MESSAGE-----

On Sun, 02 Nov 1997 19:02:03 -0500, Drew Derbyshire <ahd@kew.com> wrote:
>Numerous problems still exist with expire.  I need to stablize the
>source for the SMTP code and then revisit news.  Clearly, given my
>disappearance for six months (I switched day time employers), I don't
>know the schedule.
>
>William Joye wrote:
>> 
>> In 32 bits mode :
>> 
>> I have tested the new UUPC 1.12s on my windows 95 pc (with UUPC installed
>> on a Netware file server 3.14). I have regenerated a history file by
>> GENHIST command and after I have launched a EXPIRE command. Here is my
>> command : EXPIRE -e7 alt.security.pgp. This caused a Windows GPF. Is it a
>> bug or a mistake ?

In the meantime, there are two ways you can attack this problem:

1.  Rename your history.pag and history.dir files to something else, 
then rerun GENHIST.  If it works, then you can remove the backups.  If 
not, maybe there is something else going on.

2.  If you have a compiler and some time, you can make changes to 
HISTORY.C.  What you need to do is find a workaround for determining 
whether or not the file exists before it attempts to remove it.  This 
will probably vary from compiler to compiler, but what I did was:
   a.  After the #include "uupcmoah.h" line, I inserted:

       #include <sys/stat.h>
       #ifndef min
       #define min(x,y) (((x) < (y)) ? (x) : (y))


   b.  Did a search for the purge_article function.

   c.  After the line containing long article, remaining;:

       struct stat statBuf;
       int rc;

   d.  Searched for ImportNewsGroup(filename, group, article);, then 
changed the line that reads REMOVE(filename); to:

           rc = stat(filename, &statBuf);
       #ifdef DEBUG
           printmsg(10, "stat(%s, statBuf) returns %lu", filename, rc);
           fflush(stderr);
       #endif
           /* One way to check if the file already exists */
           if(rc == 0)
           {
       #ifdef DEBUG
               printmsg(10, "attempting to remove file %s", filename);
       #endif
               REMOVE(filename);
       #ifdef DEBUG
               printmsg(10, "back from removing file");
       #endif
           }
       #ifdef DEBUG
           else
           {
               printmsg(10, "not attempting to remove file %s", 
filename);
           }
       #endif

Now, for the disclaimers:

1.  The above code is not sanctioned by Drew and company.
2.  There will probably have to be several other changes in several 
other files, unless you are running the same compiler that KEW is using.
3.  There are complete diffs for emx on OS/2 in UUDBZ003.ZIP on Hobbes, 
in addition to the UUDBZ program (public domain, no warranty implied), 
but the essentials are above.
4.  If you have questions about either the code above or UUDBZ, then you
may either email me directly or ask it on UUPC-HACKERS mailing list
(which has been pretty dead lately).  Please don't use this particular 
list (I'm not even sure that I'm not stepping over the line as it is, 
and if so, then I apologize).
5.  This is only intended to fix one problem which causes EXPIRE to 
crash.  There may be others, but I have only encountered this particular
one AFAIK.  I only noticed it because I've been working on porting NoCEM
on spool to OS/2, and I started getting _lots_ of crashes very early on,
since the purpose of NoCEM on spool is to delete articles.  It took me 
about two weeks to find it, because I use emx or Watcom, and not C-Set, 
and there had to be some changes before I could even compile it.
6.  Six?  There is no six.

Regards,
John
- -- 
//------------------------------------------------------------------------
// momerath@apk.net                    sevot yhtils eht dna ,gillirb sawT`
// MarchHare@momeraths.org                 ebaw eht ni elbmig dna eryg diD
//                                           ,sevogorob eht erew ysmim llA
//                                            .ebargtuo shtar emom eht dnA
//                     In case of stupidity, break glass.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850

iQCVAwUBNF5jF7MHJ4yl8MPNAQFKeAP/QjqDk5KvkRv5wOzZ0Q/uIDOgUhdf5ojs
m/wbekG3dqKIhjVHjqsIelRXG9XSe9sthPJkIC9Pqdulo103qJ2jwGH8tw4d8+Fb
snfSdaoXj68siGcZu8zft5d44z3wySmRiOp99rb0VgzelCyjxy76EiE709Wga2VC
0ciBemEvwlQ=
=wbq9
-----END PGP SIGNATURE-----

------------------------------

Date: Tue, 04 Nov 1997 20:46:34 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: Trouble with UUPC/extended EXPIRE 1.12s
To: Sysop <MarchHare@momeraths.org>

Snuffles is loaded up with Chocolate in each paw, and we've got more
downstairs (the bears really like Halloween), but our combined talents
CANNOT figure out why this does anything.  The classic cause for expire
blowing chow is buffer runs in the history file processing (usually, too
many news groups), are you sure this is not just masking one of those? 
REMOVE() doesn't do much, you could just replace it with the regular C
RTL call.

I'm open to suggestions here.

Sysop wrote:
>
> In the meantime, there are two ways you can attack this problem:
> 
> 1.  Rename your history.pag and history.dir files to something else,
> then rerun GENHIST.  If it works, then you can remove the backups.  If
> not, maybe there is something else going on.
> 
> 2.  If you have a compiler and some time, you can make changes to
> HISTORY.C.  What you need to do is find a workaround for determining
> whether or not the file exists before it attempts to remove it.  This
> will probably vary from compiler to compiler, but what I did was:
>    a.  After the #include "uupcmoah.h" line, I inserted:
> 
>        #include <sys/stat.h>
>        #ifndef min
>        #define min(x,y) (((x) < (y)) ? (x) : (y))
> 
>    b.  Did a search for the purge_article function.
> 
>    c.  After the line containing long article, remaining;:
> 
>        struct stat statBuf;
>        int rc;
> 
>    d.  Searched for ImportNewsGroup(filename, group, article);, then
> changed the line that reads REMOVE(filename); to:
> 
>            rc = stat(filename, &statBuf);
>        #ifdef DEBUG
>            printmsg(10, "stat(%s, statBuf) returns %lu", filename, rc);
>            fflush(stderr);
>        #endif
>            /* One way to check if the file already exists */
>            if(rc == 0)
>            {
>        #ifdef DEBUG
>                printmsg(10, "attempting to remove file %s", filename);
>        #endif
>                REMOVE(filename);
>        #ifdef DEBUG
>                printmsg(10, "back from removing file");
>        #endif
>            }
>        #ifdef DEBUG
>            else
>            {
>                printmsg(10, "not attempting to remove file %s",
> filename);
>            }
>        #endif
> 
> Now, for the disclaimers:
> 
> 1.  The above code is not sanctioned by Drew and company.
> 2.  There will probably have to be several other changes in several
> other files, unless you are running the same compiler that KEW is using.
> 3.  There are complete diffs for emx on OS/2 in UUDBZ003.ZIP on Hobbes,
> in addition to the UUDBZ program (public domain, no warranty implied),
> but the essentials are above.
> 4.  If you have questions about either the code above or UUDBZ, then you
> may either email me directly or ask it on UUPC-HACKERS mailing list
> (which has been pretty dead lately).  Please don't use this particular
> list (I'm not even sure that I'm not stepping over the line as it is,
> and if so, then I apologize).
> 5.  This is only intended to fix one problem which causes EXPIRE to
> crash.  There may be others, but I have only encountered this particular
> one AFAIK.  I only noticed it because I've been working on porting NoCEM
> on spool to OS/2, and I started getting _lots_ of crashes very early on,
> since the purpose of NoCEM on spool is to delete articles.  It took me
> about two weeks to find it, because I use emx or Watcom, and not C-Set,
> and there had to be some changes before I could even compile it.
> 6.  Six?  There is no six.
> 
> Regards,
> John
> - --
> //------------------------------------------------------------------------
> // momerath@apk.net                    sevot yhtils eht dna ,gillirb sawT`
> // MarchHare@momeraths.org                 ebaw eht ni elbmig dna eryg diD
> //                                           ,sevogorob eht erew ysmim llA
> //                                            .ebargtuo shtar emom eht dnA
> //                     In case of stupidity, break glass.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3a
> Charset: cp850
> 
> iQCVAwUBNF5jF7MHJ4yl8MPNAQFKeAP/QjqDk5KvkRv5wOzZ0Q/uIDOgUhdf5ojs
> m/wbekG3dqKIhjVHjqsIelRXG9XSe9sthPJkIC9Pqdulo103qJ2jwGH8tw4d8+Fb
> snfSdaoXj68siGcZu8zft5d44z3wySmRiOp99rb0VgzelCyjxy76EiE709Wga2VC
> 0ciBemEvwlQ=
> =wbq9
> -----END PGP SIGNATURE-----

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"An important, but often overlooked, feature of running a computer
system
 is maintaining its security from outside intrusion, internal sabotage,
 and just plain user stupidity."
                          -- Unix System Administration, Fiedler and
Hunter

------------------------------

Date: Wed, 05 Nov 1997 19:21:07 -0500
From: MarchHare@momeraths.org (Sysop)
Subject: Trouble with UUPC/extended EXPIRE 1.12s
To: uupc-info@kew.com

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 04 Nov 1997 20:46:34 -0500, Drew Derbyshire <ahd@kew.com> wrote:
>Snuffles is loaded up with Chocolate in each paw, and we've got more
>downstairs (the bears really like Halloween), but our combined talents
>CANNOT figure out why this does anything.

I explain that in my previous message.  However, ...

  The classic cause for expire
>blowing chow is buffer runs in the history file processing (usually, too
>many news groups),

Sounds similar to an RMAIL problem that I gave up on (large files 
causing it to crash and no error message).  How many is too many 
newsgroups, btw?  I've always wondered that.  I've got 291 at last 
count.

> are you sure this is not just masking one of those? 

No, but that would most certainly mean that REMOVE() is getting fed a 
bogus path/filename, then.  However, I don't think it is masking 
anything like that.  I added some "now removing..." and "back from 
removing..." types of messages, and the only thing I noticed was that I 
would check some of those articles, and they did not exist.  So, coding 
in a check for the files existence kept it from crashing.  However, I 
did not notice anything odd about the filenames, and I _believe_ I 
checked the history file backup as well.  Guess I should've kept notes, 
but this was a lot of weekend hacking and three colds ago.

>REMOVE() doesn't do much, you could just replace it with the regular C
>RTL call.

One would think.  As I said in the previous message, there really isn't 
any reason, IMO, that REMOVE() should cause this error to begin with. 
Note that my main concern at that moment was keeping it from crashing, 
because if you don't take care of the problem, articles _never_ get 
expired, and your problems suddenly get much, much worse (really fast, I
might add).

John
- -- 
//------------------------------------------------------------------------
// momerath@apk.net                    sevot yhtils eht dna ,gillirb sawT`
// MarchHare@momeraths.org                 ebaw eht ni elbmig dna eryg diD
//                                           ,sevogorob eht erew ysmim llA
//                                            .ebargtuo shtar emom eht dnA
//                     In case of stupidity, break glass.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850

iQCVAwUBNGEQhrMHJ4yl8MPNAQHPAAP/aQ2pgZAV4IbaOkiXDJnx3KAkmYW21NnZ
0ta2Xjjjlv6SFBKyogQZ04CssJGCLj5WUaa1bstdUDntjiGaSXYUmaPlvljQ25G4
9h2YDtRAtXR96mZu5iFaTjjY621iCTFSTV3SET4ee+oBK0PHEOGBvwQ5FCw7ZIJx
PAWkaB3HKBM=
=VmzY
-----END PGP SIGNATURE-----

------------------------------

Date: Sun, 02 Nov 1997 21:58:29 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: UUPC - NASI/INT14 Compliant?
To: Cesar.R.Garcia@MARSHMC.COM

>      Is UUPC (ver 1.11) NASI or INT14 compliant?  

No.  FOSSIL support existed but it was spotty.

>	If not, do any of the newer versions support it?

Yes. 1.12p and above all support INT14.

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"CP SHUTDOWN" is "Miller Time" spelled sideways.

------------------------------

Date: Sun, 02 Nov 1997 19:54:16 -0500
From: Drew Derbyshire <ahd@kew.com>
Subject: UUPC v1.12
To: Focus Optiplus <merlin@consva.com.cu>, uupc-info@kew.com

Focus Optiplus wrote:
> 
> Hello !!
> 
> There is a way to setup UUCP v 1.12 in order to confirm delivery
> (like UNIX) ???
> 
> Best Regards.

Not in the current version.  I may add it someday, but it's not
desirable in most cases because of the extra traffic it generates, and
people forget to turn it off when sending to mailing lists and the
like.  Because this latter issue, our mailing list exploder actually
refuses all mail to the lists which request a receipt.

-- 
Internet:       ahd@kew.com             Voice:          781-279-9812

"He sure looks like plant food to me!"          - "Little Shop of
Horrors"

------------------------------

End of UUPC-Info-Request Digest
******************************