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.<giggle>

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)