Subj : re: "stuck" open files To : Marc Lewis From : Mike Luther Date : Tue Aug 16 2005 09:57 pm Sure thing Marcus! ML> Can you give some example of your logging routines? Here is a direct clip from my BINK.CMD file that runs the POTS phone instance of BINK here in OS/2 on one logging unit. What we are looking at here is a DOS-VDM call for a specific DOS program that is still here even under the OS/2 operation which captures every single message that this node processes into an AskSam fully relational database. Yes every message for gawsh close to two decades here in a fully relation database? Yep, you betcha. That is one reason that I am reading the IC echo via TelNet on Sursum Corda rather than doing it all here. By sorta agreement with the 'local authorities' two decades ago, it was the only way to prove what Net 117 wasn't doing that it was claimed that it was and I could prove it. Period. Anyway, here is the snip from that section of the BINK control file for the POTS game: if not exist c:\opus\msg2ask.ctl goto tapestart rem " Now change to OPUS drive and directory" c: cd c:\opus rem " call the DOS program MSG2ASK to suck them up" Echo Kilroy9 Echo Kilroy9 > D:\BT\abend3.flg echo msg2ask1T echo msg2ask1T > c:\autoexe1 msg2ask new echo msg2ask2T echo msg2ask2T > c:\autoexe1 Echo Kilroy10 Echo Kilroy10 > D:\BT\abend3.flg rem " Now change to routine MAX drive and directory" d: cd d:\max rem " Make the new message caps for messages" mrp all -pd:\max\max.prm Echo Kilroy11 Echo Kilroy11 > D:\BT\abend3.flg Notice that dual reference to Kilroy11 in those last two cited lines and in other places above? That is so when the box freezes, you can look in the session window and see where a VISUAL prompt hit, but perhaps the log file snippet DID NOT get recorded to the disk. That is proof positive that in the batch file it was executing at that point on the screen, but FAILED to write the needed log snippet update into that particular needed file. It tells you that the file system or the box failed at the instant of that action, as far as this application is concerned. Now, here is a snip of the Intermail OS/2 .CMD file that actually runs in a DOS-VDM operation on this same box, from the FTP section. It is important, we've found, if you are going to mix and match all this stuff that you run it from OS/2 .CMD files, even though the items are at times DOS-VDM stuff, so that the Environment is synchronized better: :FTP_AUTO cd \FNOS echo kilroy15 echo kilroy15 > e:\im\abend1 echo ^ echo *** ATTENTION! * Running UP-DOWN batch! *** echo ^ echo -------- echo Wait until ccom shuts down echo -------- :: wait +00:00:05 wait2 5 Wait2 5 is my personal compilation of the old DOS WAIT program for use in native OS/2, thus it is better to call it as in the .CMD file, even though the Intermail program is still a DOS program running from that same batch file as DOS under the OS/2 .CMD file. Notice that the file for that task's logging is a different file in a different directory, but the technique of screen print followed by the common name concept, adjusted for that task is similar? That's so you can collage each task's log unit from the totally locked box, as it stood at the last instant just before the lockup took place. You take the file time stamp for each of these specific named log files. Each write to the file will have the exact instant in time it was written to the disk, and .. it will be in sequence as to how the HPFS file system actually wrote it. And .. failed! You position the tasks on the screen so you can see what each task was doing visually at that last moment before the Rapture, if you will! Grin! To that, you also must realize that every time you call a DOS-VDM you are asking for the file AUTOEXEC.BAT to get executed, or whatever the 'standard' such file is called. You maintain a log run in this same fashion for each child process spawned that time-line stamps this too. This is how you can PROVE what child was the bad child in the sequence, and exactly what sequence was being done, between the whole collage of totally 'independantly thinking' batch children, with totally 'free', in some cases, time schedule run requirements; yet is expected to handle common message file, directory files,and most important in DOS-VDM operations, that cross-generation nasty called AUTOEXEC.BAT which is mandatory for every one of these COMMUNICATIONS PORT I/O applications all running at once. You'll discover there are real issues which can show up for what happens with TCP/IP, at the same instant in real-time that DOS-VDM operations are doing real-time data I/O on the comm ports on a box. I've even had to do IPTRACE stuff and hand sync the logs to that to 'prove' .. AHA! Sure .. There are other ways to 'synchronize' this. And sure, you can try this game in Theseus 4. And sure you can run this in a debug kernel and all this. But the people on the other end of this have *NO* way to duplicate, at least at my financial level of cooperation, exactly what I have which has been proven this way to blow the Hades out of this or that HPFS change, KERNEL change, PMMERGE.DLL change, DHCP change and so on. And on ... This is exactly how the issue where the DHCP operation, which had a bug in it that left an open file handle for AUTOEXEC.BAT of all things, for EVERY time a DHCP request was made for re-registry was happening! Yes, it could be seen in Theseus 4. But proving that amidst the real-time game of hundreds of instances of calls for DOS-VDM's and children environments seemed to be best found in a low-level pest like my stuff so that real capable people could find the real failure points. The initial pointers came from this stuff. Anyway. You asked and here's what I've done for years now to figure out exactly what the box was doing when it locked, the clock is stopped up there on the WPS, and the only way to go foward isn't even a three finger salute but Big Red Switch time. Yes, you can intance a dump remotely from a TelNet connection .. but .. Oh well, you get the idea. --> Sleep well; OS/2's still awake! ;) Mike @ 1:117/3001 --- Maximus/2 3.01 * Origin: Ziplog Public Port (1:117/3001) .