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 {at} 1:117/3001

--- Maximus/2 3.01