FM> OLX is spitting the dummy on every conference in this packet
FM> except the inbox. Splat right back to Windows.

FM> I tried reconstructing it by Qwk2Pkt then Pkt2Qwk - same thing.

FM> Any idea what's happening, and any idea how I can get today's
FM> messages back?

RS> Thats the PKTJOIN problem, in some cases it will produce a fucked
RS> QWK which OLX behaves like that with.

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

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

I was planning to automate the analysis of the output of PKTJOIN
particularly but obviously since there was only a subset of the total
messages in the good runs, it wasnt that easy and I never got around
to a proper analysis.

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

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

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?

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

RS> The crude workaround is to not process all the PKTs that you did to
RS> produce that QWK, say if there are two, make a separate QWK with each
RS> one. Those are the archive files you get in a mail run from Paul which
RS> have separate PKT files inside. On the very few occasions I have needed
RS> to do it, total of about 5 days, a single archive file from Paul at a
RS> time is enough.

FM> [later]

FM> I deleted all the indexes from the original packet because I knew
FM> SLMR recreated them if they were missing. Seems that OLX does, too,
FM> and that that was the problem - the indexes were fucked. They're
FM> created by PKT2QWK, aren't they? Then this program has a bug also.

RS> Yeah, its definitely the NDX files. Havent bothered to look too
RS> closely at whats wrong with them, never got around to it once it
RS> was very rare.

FM> There seems to be 2 problems, inclusion of index entries for areas
FM> which don't exist in MESSAGES.DAT

I dont know that I would have seen that. At the time I was having the
problem I would usually get messages in each area in each mail run.

FM> and incorrect pointers for those entries which do exist.

And I certainly never saw that, hit return on any area except the IN and
OUT boxes and OLX would fall over completely, total crash back to DOS.

FM> The first could be due to Paul's suggestion of the problem, me fucking
FM> up and leaving NDXs around (although I'm damned if I can see it),

I find that a bit hard to believe coz its relatively easy to check.

FM> the second seems to indicate some other problem in PKT2QWK.

Well, you may have a completely different problem to what I had, but
as everyone has been saying to you, if it really is a bug in PKT2QWK,
how come no one else is seeing that ?

In the case of the fine detail of the processing of the archived PKTs,
its easier to see that individual styles of getting mail from Pauls
system can result in different detail on various systems. Particularly
if the indexes which are fucked only make OLX crash and the others dont
care about whatever is wrong with them.

RS> The other possibility is to not use PKTJOIN at all, use daves message
RS> sorter for the same functionality.

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

Without much evidence tho.

--- PQWK202