Hi, Rod.

RS>FM> The output from PKTJOIN and MESSAGES.DAT seems to be OK,

RS>RS> Thats what it seemed when I had the problem too. But processing
RS>RS> the individual archive files of PKTs one at a time produced a
RS>RS> QWK with good NDXs anyway. I couldnt see any problem with the
RS>RS> MESSAGE.DAT and the output from PKTJOIN which produced the bad
RS>RS> QWK, but the QWK was bad anyway.

RS>FM> I don't think that excludes PKT2QWK.

RS>Who said anything about excludes ?  I was talking about likelys.

Sure. I think PKT2QWK is more likely.

RS>FM> As you say below, it may be the fine detail of the environment
RS>FM> PKT2QWK runs in.

RS>Yes, but you said you are sure its a bug in PKT2QWK. In fact its rather
RS>more likely its your BAT files or your machine config since no one else
RS>is currently seeing it and we have been running PKT2QWK for many months.

Sure, the environment (in some peculiar combination) causes the PKT2QWK
bug to be revealed, just as a peculiar combination in the environment
will cause the PKTJOIN bug to be revealed.

RS>Corse you can always split hairs and insist that if at any time PKT2QWK
RS>doesnt complain and produces a QWK which is no good without complaining,
RS>that has to be a PKT2QWK bug. Life is a tad more complex than that tho.

Yep, that's what I'd call a PKT2QWK bug (even if it's activated by crook
info produced by a bug in say, PKTJOIN).

RS>FM> it's just the indexes which are produced by PKT2QWK.

RS>RS> It was in my case too. The evidence was graphic, hit return on
RS>RS> an area, watch OLX go bang. Process the archive files of PKTs
RS>RS> each in their own run, no problem.

RS>FM> Yep, exactly same symptom (but I haven't tried your workaround).
RS>FM> To my mind, *my* workaround (not zipping the indexes into the QWK)
RS>FM> strongly suggests PKT2QWK as the culprit, 'cos MESSAGES is OK but
RS>FM> the indexes aren't.

RS>Yes, but it doesnt explain why processing the individual archive files of
RS>PKTs each in their own run does not. THATs the bit of evidence which made
RS>me think that PKTJOIN was the more likely culprit. Atleast in my case.

Sure, that's reasonable. But now that we've seen PKTJOIN (well, I have -
you may have seen it right from the start) I think it's more likely that
that's just changing whatever subtle detail that activates the bug.

RS>FM> I take it this is a separate PKTJOIN problem from the one which
RS>FM> was affecting me and for which I devised a workaround?

RS>RS> No idea. It may be or may not be, no way to know without determining
RS>RS> where the bug is in both cases and seeing if its the same problem.

RS>FM> Now that Paul has posted the source of PKTJOIN in PUBLIC_DOMAIN,
RS>FM> I find it hard to see that it could be causing this problem.

RS>Yes, but then the symptom that processing each archived file of PKTs
RS>in separate runs producing a good QWK is hard to explain with a PKT2QWK
RS>bug. Particularly when there was nothing special about the size of the
RS>combined PKT when multiple archived files of PKTs were processed in a
RS>single run. That file was in the mid range size wise, certainly not
RS>just the big ones. Big the sense of total size or number of PKT files
RS>processed either. There was nothing obvious about the dud runs at all,
RS>and as I say it almost never happened.

Sure. Could still be affecting the environment, doesn't have to be a
size thing.

RS>FM> It's still got the other bug, though.

RS>Yeah, I excluded that possibility, my created PKT isnt even in the
RS>same subdirectory as the ones being joined.

No, as I've now realised (and had pointed out) is the case in the
TinyPoint batch too.

RS>FM> Sure, but I think the problem is in PKT2QWK.

RS>RS> Without much evidence tho.

RS>FM> The indexes are fucked but MESSAGES are OK.

RS>That doesnt prove a damned thing about it being a bug in PKT2QWK.

RS>FM> The indexes are created by PKT2QWK.

RS>Using info which it gets elsewhere. So whatever affects that info
RS>it uses, can be the cause of the dud NDX too.

RS>FM> Therefore PKT2QWK is fucked

RS>Nope.

Oh, I see.

RS>FM> (either internally or because it's grabbing some stuff I've left
RS>FM> lying around). That's my evidence.

RS>Its useless.

RS>FM> Basically, we don't know.

RS>Precisely, which is what I said.

Which is what I said.

RS>FM> Now that I'm keeping the absolute raw files from Paul, it should only
RS>FM> take 1 more problem packet to find out.

RS>You poor fool. Now you are saving the evidence, it will never appear again.
RS>Dont you know nuffin after all this time ?

And of course, it hasn't. :-)

Regards, FIM.

 * * Expert - someone from out of town carrying a brief case.
@EOT:

---