Hi Paul



 >>> moved here from TML's LOCSYSOP in the faint hope of

     attracting hints.. 



On (06 May 94) Paul Markham wrote to Roy McNeill...



 PM>> Sounds like you're reinventing my original program. I was reading it

 PM>> twice as well, but it really thrashed the disk.



 RM> Get a bigger cache... On the 2nd pass, did you have all the input

 RM> files open at once? I had real fun with this,



 PM> I've got a 2MB cache with lazy write turned on. I don't know why it

 PM> was thrashing the disk so badly. From memory, all the packets were

 PM> open for the duration of the program, which caused it's own problems

 PM> with numbers of file handles.



For testing, I'm using around 24 packets totalling 350k odd. Almost

all of it fits in the cache (2M, delayed write), disk activity is

minor. It isn't quick, though, overall speeds of 7 to 11 msgs per

second are typical on this 486. Not a real priority, though.



The real reason I asked was to see if you had fun with file

handles. I ran into the 20 limit real fast. Found a solution called

relocate() that uses dos interrupt 0x67 in the Snippets file,

though, but it took some work to get it running:



a) The fix provides heaps more handles, but only of the int handle

variety. The FILE *fp file pointer system gets no assistance.

Therefore, all the nice fopen() type functions are out. FILE is

limited by the constant MAX_HANDLES, which is 20 under BC3 and 16-

bit BC4, or 40 with BC4 in flat 32 bit mode. What is it in the OS/2

compiler?



b) So I had to use open(), close(), read(), write(). Ok? Nope. Open

and close worked ok, read and write failed when the number of open

files hit the same limit (17 plus stdin/out/err). Turns out that

_read() and _write() are needed - I found this out by sheer trial

and error.



c) Got the thing reading the 24 source packets, writing to the

destination packet, and closing them all. Good. Then it wouldn't

open the log file, which still used fopen() functions. Had to

convert that over to open() and _write() too - there may be some

interaction here. There are now no fopen()s left in the program.

When BC4 compiles it, I get warnings that "_read() and _write() are

obsolete".... Damned cheek. I've been insulted by a bloody

compiler .





The program now runs, but... It crashes in spectacular fashion when

the pc is running Qemm (no multitasker, just Dos5 and Qemm). Runs

fine under Himem.sys . This is a real pain, because I need Qemm to

run Dv properly, and Dv is the target environment for this program.

As well as that, TD386v3 is the best debugger I have for this work,

because of its partial resistance to being crashed by the program

it is debugging. TD386 won't run under Qemm. I'm stuck with TDv3,

and the TDv4 that comes with BC4, which seems nearly identical to

TDv3. It certainly crashes just as easliy.



The program seems to go bananas during function returns. At one

stage, I could get it to crash when main() returned, by feeding it

incorrect parameters so it would terminate without doing any packet

sorting. That particular crash went away all by itself, though.

More work. Sigh.



And I think I will include date/time sorting after all. The current

setup seems to throw the msgs in reverse order more often than

not...



Cheers



--- PPoint 1.80