Subj : Grunged message cap pointer help? To : Paul Quinn From : Mike Luther Date : Wed Nov 21 2001 11:13 am Suprised at this Long Delayed Echo Paul? PQ> Yes, and from what you have written to Mark Lewis... I would tend to PQ> agree. You have a (perhaps?) unique combination of PQ> system, & application software, there, producing a PQ> quite curious side-effect. I think I know more about this curious side-effect! Lookie here at what seems to have, maybe, 'solved' it! The commented out line at the top below from my batch file which calls the utility MOVEMAIL has a -t command line parameter in it. In theory, that is a valid and goodie! But on *VERY* close inspection I discovered that an error flag comment was popping at this call line! It said "Illegal parameter -t", but apparently was moving this stuff somewhere.. In theory,this was only, in the call below, stuff in outbound destined for the HUB,Steve Loupe in Houston at 1:106/1, but .. And there is another one of these for one other instance of MOVEMAIL elsewhere! :: loadhigh movemail -se:\outbound -de:\fnos\ftpout -fdcf36924 -e -t loadhigh movemail -se:\outbound -de:\fnos\ftpout -fdcf36924 -e As well you may be curious about the LOADHIGH DOS command! Well, in OS/2 DOS-VDM sessions, I found out that MOVEMAIL pops a SYS3175 error all the time if I don't try to use that! Now I *THINK* I might be able to bust that error on MOVEMAIL by careful manipulation of a DOS-VDM session setting parameter list for the OS/2 DOS-VDM, but that isn't possible when you are running these things out of a batch file, unless you use ORUN or DHANG to force the thread. So the simplest fix for it was just to load it high and forget about the bug! I was trying to isolate a curious hard lock hang with the AIC154X.ADD OS/2 Adaptec SCSI disk driver and 1542C cards. It suddenly popped up when we moved from the Kernel that was distributed with Fixpack 15 to the IBM official later one in W40508.ZIP in May this year! It got better in the one that was just released as W41026.ZIP in October. But in tracing this pest which only is popped by DOS-VDM sessions, and is so nasty it locks the whole box hard lock red light on, and only power down to break it, I tried something. I coded every single one of the .BAT and .CMD file for the three BBS systems which run on this box. Using a completely separate flag file and screen pop display file for each step, I was FINALLY able to trace exactly what step all three systems were at when the lock fired. In doing that, this curious little error message above flipped by. So .. I commented out the -t, just to see what would happen. The error we discussed seems to have vanished! At least what was left of it after I discovered that I could leave a single message in my NetMail area all the time and that broke most of it! Wierd! For anyone reading along on the curious DOS lock deal for Adaptec 1542C cards and Warp 4.5 with FP-15, I have another suggestion! There are SOME dos utilities out there which can use DMPI memory which are *NOT* Windows code! For example, PKZIP and PKUNZIP .. and .. also .. There are SOME BBS programs which seem to be DMPI aware, even if they do not, perhaps USE this memory. I think they may be looking at somehow sniffing if they are maybe running under a WIN 3.x system! At any rate, I have discovered that if this *IS* a problem, you can seemingly break or near fix it! You must *NOT* use the DOS-VDM session setting command in OS/2 to let a program have Interrupts before the disk action is finished. As well, you need to also set the DOS-VDM session parameter for DMPI enablement to ALWAYS on, even if you technically use no DMPI memory applications and this curious lockup is astraddle your pony! As well, a prime DOS-VDM batch file using the old AIC154X.ADD and an old 1542C card can also, it seems, be induced into stability by adding the option to the DOS-VDM session settings to let the session have direct access to the HARDWARE for the box. This also includes things that have FASTECHO in them, so all this should be on topic here! Happy turkey day! --- Maximus/2 3.01 * Origin: Ziplog Public Port (1:117/3001) .