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

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

FM> I don't think that excludes PKT2QWK.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RS> Without much evidence tho.

FM> The indexes are fucked but MESSAGES are OK.

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

FM> The indexes are created by PKT2QWK.

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

FM> Therefore PKT2QWK is fucked

Nope.

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

Its useless.

FM> Basically, we don't know.

Precisely, which is what I said.

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

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

--- PQWK202