Subj : Error Code 64
To : Mark Lewis
From : Mike Luther
Date : Mon Aug 02 2004 10:52 pm
You are correct Mark!
ML> DOS-AUTOEXEC : MAILEXEC.BAT
ML> DOS-BACKGROUND_EXECUTION : ON
ML> DOS_BREAK : OFF
ML> DOS_DEVICE: : C:\OS2\MDOS\ANSI>SYS
ml> is that a mistype or ?? it should be ansi[dot]sys ;)
Should be a 'dot' there. Sorry.
In that I don't know what the error 64 means, what I was trying to do was to do
an end run around the DPMI, and extended plus expanded mem manager stuff,as
well as to cover the possible path statement not being in the environment.
That, plus lack of available file handles, and kept ones and so on, can creat a
lot of hard to find error causes in DOS-VDM's in OS/2.
Beyond those issues, I've long ago learned to expand the environment beyond
even 768 bytes as I posted. Who knows what that setup program is doing
relative to internal 'unseen' shell statements? (!). I sure don't, but I know
that from a compiler standpoint, I can sure create a shell-child game that the
user doesn't really know is being used. Thus if there isn't enough environment
space, or the path isn't really passed to whatever is made of this, all kinds
of wierd errors can happen.
There are some other very oblique errors in OS/2 and DOS-VDM's as to box
lockups and so on that I doubt very seriously are involved at this initial
stage of troubles. These have to do with MULTIPLE DOS-VDM's on an OS/2 box in
the Fix Pack 15 range and on into early Fix Pack 16 officially. Somehow, in
the upgrade work of the OS/2 game from Warp 4.5 into the 'unified' kernel of
what is now MCP1/2 and specifically Fix Pack 17, DOSCALL1.DLL turned up a
problem wherein the environment wasn't passed totally correctly between NESTED
use of batch files! If you look at this whole thing as it really is, when you
use a .BAT file in a DOS-VDM, even that first use of AUTOEXEC.BAT is, really, a
nested batch file! There were, at this time major issues in how the HPFS file
system and its write caching code were getting lost as to the operating path
between batch files and on collapse of one, such as AUTOEXEC.BAT and the one
you would be running.
It took a SUBSTANTIAL amount of work and hand plugging of all my many, many
batch and .CMD files that wrote a cross-section trace log for each step of
every .BAT and and .CMD file, on this multiple BBS/TCP-IP/TELNET server box
here. But I proved exactly how and at what time in relation to the cache
writing, and particularly, the refresh of the OS2.INI files, the information it
took to get IBM's kernel crew to get this whole mess fixed. The DOSCALL1 and
other code data to fix this wasn't found and completed until Fix Pack 16.
Plus a portion of the DHCP log-in code was creating multiple falsely held
open, same-name file handles, for each renewal of DHCP post boot-up. That
wasn't finally found and fixed by IBM until not many months ago even well
beyond the UN2206 and WR08706 level fixes! In other words, some of this which
can produce these strange errors in DOS-VDM's in OS/2 wasn't really cleaned up
until AFTER the MCP2 and even XCR0002 official releases were made.
This is one reason I keep trying to get people to officially update to the very
latest IBM fixes and so on. Even my Fix Pack 16 boxes didn't stabilize out
until after some of the post fixes were made! Plus .. Fix Pack 17 is another
major effort to equalize the operating code between the old Warp 4.52 and MCP
kernel and PMMERGE level stuff. It is really needed for those wanting
stability in DOS-VDM work. At least on heavy multiple DOS-VDM boxes with lots
of DOS still running, it seems to be here.
That said, another thing we learned was that it is really better still to do
the batch file game in a .CMD file, even though a lot of it may be actually
running DOS programs as components of the native OS/2 .CMD file!!
Once done, the entire system here which is still running FE 1.46 under DOS,and
IM and a FAMILY and thus OS/2 mixed operation for 1:117/100 and as well two
other OS/2 BBS units, POTS and TELNET for 1:117/3001, plus a full FTP server
and two RF packet gateway applications in DOS-VDM's .. FINALLY stabilized out.
It finally guit throwing everything from FE errors on to totally locked box
stuff. Actually, one of the TNC RF programs is a WIN 3.1 proggie that runs on
top of everything else! In fact, to keep FE even running, until all the IBM
stuff came clean, I had to deliberately turn off the HPFS Lazy Write cache game
to keep from box lockups every week or so.
Since I dunno what Error 64 really is .. all I was doing was trying my best to
be of service. Trying to pay back some of the really thoughtful and real debug
time that IBM spent with me officially on finding and fixing some of this stuff
on DOS-VDM's. I'm *VERY* happy with IBM and what they have been able to do for
little old me. I really respect them.
--> Sleep well; OS/2's still awake! ;)
Mike @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
