Subj : "stuck" open files
To   : Marc Lewis
From : Mike Luther
Date : Sun Aug 14 2005 12:52 pm

Marcus ..

This is part of the reason I took so much trouble to write a complete logging 
file for every step of the way in all the operations files for the batch files 
for Bink, Max and whatever.  In my humble opinion what you are seeing is 
exactly what I used to see with two diferent Bink/MAX/Squish applications 
running plus a DOS-VDM Intermail application, plus FTPSERV plus contol programs 
for my ham radio TNC controllers and my own telephone logging program all 
running on a 133Mhz CPU OS/2 FP17 program with SIO at the same time handling 
TelNet.  It's still running all that today very stable,  

But.  It couldn't be broken of things like what you complain of until  major 
things were done.  First, a whole lot of confict issues with DOSCALL1.DLL wound 
up being fixed officially by IBM over all this as part of the march to FP16 and 
the more or less concurrent MCPwhatever fixpack of about that time.  And the 
way that finally got fixed and 'proved' so it could be addressed, was for me to 
write a complete disk logging file for every single task in every running batch 
file that put a common log event line on the actual disk for every single step 
of the way.  I eventually proved that certain programs absolutely couldn't 
remain stable over days if they hit the same I/O operation for the kernel and 
for the HPFS file system at the same time.  While most of the time they DID 
work!  

My 'customer workaround' for that during the actual kernel trace work, was to 
disable HPFS write caching.  That's where the issue seems to focus out in my 
humble opinion.  However that was never officially confirmed by IBM in the 
mission.  After FP16 in FP17, I was able to re-enable HPFS write cache.  I've 
not seen it again.  However my control logging program is still working to this 
day.  It is not an add-to-line logger.  It simply tells us what exact line in 
what exact of all the many comman line operations, was the last step just 
BEFORE the lockup, three finger salute, whatever.  That information and the 
precise instant in time also logged compared to the failure precise time log 
elsewhere, was what it took to fix this for us all. 

It took me almost a YEAR of this work to document it all out.  I still have 
about half a dozen different DOSCALL1.DLL's that were in test here over the 
thing.

If you are not running at least FP17 for Warp 4 or XRC_04 or 5 for MCP, plus 
haven't installed the special HPFS file system fix which was put up on the 
Public Testcase to fix certain high activity level HPFS file system lockup 
failuer issues, my bet suggestion to you is try to shut off the HPFS write 
cache actions.  It can't hurt you, I think.  It might tell you something 
valuable as to why going forward with IBM as to all of this is so needed even 
for what we do in just the BBS work here! 

Just a thought. 

Mike @ a TDY site on an old Picollo transportable 40 pound case with FP17, a 
timy 7 inch super VGA Panasonic tube monitor and four serial ports all running 
simultaneous on comm test operation!

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)

.