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)

.