Hi, Paul.

PE> PE> FM>> This time, I hope I've captured all the input so I
can recreate
PE>and
PE> PE> FM>> possibly track down these problems. I notice
you've sent me a new
PE> PE> FM>> PQWK222.ZIP. What does it fix?

PE> PE>> PQWK222 fixes the problem with people leaving
"To:" out of their
PE> PE>> netmail, so please switch to it.  And if you can reproduce the

PE> FM> OK, then it's relatively minor and I can do that at my convenience.

PE>NO IT IS NOT MINOR AND I WOULD APPRECIATE IT IF YOU UPGRADED TO IT
PE>*STRAIGHT AWAY* NOT AT YOUR CONVENIENCE SEEING AS IT IS A DROP IN
PE>REPLACEMENT,

However, I take the same view of upgrades as it seems Rod does; I want
to make sure there are no problems, and that they work the same as
before (apart from whatever has been fixed or enhanced). As a one-time
professional programmer and maintenance team manager, I know all about
"minor" upgrades. The loss of Westpac's Handybank network over Easter a
few years ago was following a minor software upgrade.

AND YESTERDAY YOU SENT A MESSAGE TO BOB LAWRENCE
PE>WITHOUT PUTTING THE To: IN THERE AND IT WENT TO ZONE 5966.

Sorry, I'll send it again.

PE> FM> AAMOI, if I send netmail to Areafix (as I did today), I don't put a
PE>To:
PE> FM> in the first line. What will 222 do then?

PE>AND TODAY YOU SENT A MESSAGE TO AREAFIX, AND IT WENT TO ZONE
PE>5966 ALSO.  222 WOULD HAVE SENT IT BACK TO YOU, INSTEAD OF
PE>LETTING IT GO TO CYBERSPACE (I DON'T KNOW WHERE THESE
PE>MESSAGES GO).

But I don't want it to come back to me! Do I have to put a To:
3:711/934.0 in there? SDUSRMAN.DOC doesn't say anything about that.

PE> PE>> problem with PQWK222, especially the problem with CONTROL.DAT

PE> FM> Why do you say that? Have you made other changes to PQWK222 apart from
PE> FM> what you said above?

PE>No, but I don't want to debug old code, I only want to debug
PE>the latest version.

That's fair enough.

PE> PE>> being zero-length, I'll take a look at it.  Please include an

PE> FM> I have already reproduced *that* problem with my existing PKT2QWK; if
PE> FM> you insist I'll verify it on 222 as well before sending you enough
PE>stuff
PE> FM> to reproduce it yourself. However, I want to try and track down the
PE> FM> other bit, too - PKT2QWK generating fucked indexes. As I said, I think
PE> FM> I've captured enough to be able to reproduce that problem too,
PE>although
PE> FM> my one attempt to date, while it did create the problem, also
PE>exhibited
PE> FM> another weird effect - the QWK was only ~1/4 the size it should have
PE> FM> been! I think we've got more than one bug here.

PE>Yeah, a separate archive for each problem thanks.

OK, the zero length seems easy to reproduce, I'll send that first.

PE> PE>> archive containing the PKT files, and a batch file that calls
PE> PE>> PKT2QWK with whatever parameters you normally use.  BFN.  Paul.

PE> FM> Yeah, it'll be the minimal amount I can put together which shows the
PE> FM> bug, but be prepared to wait an hour while it runs - more if you're
PE>not
PE> FM> running a DX50 :-)

PE>I will print out the message number each time and went it gets
PE>excessive I'll put a whole lot of printf's until I find out
PE>where the problem is.  BFN.  Paul.

OK, might be 2 problems, though, and just coincidence that the excessive
time happened in the same packet as the zero length.

Regards, FIM.

 * * Upgrade (vt): Remove old bugs ... add new ones! *
@EOT:

---