OS/2 DOS-VDM LAN error help?

[Mike Luther]

I just hit a problem I've never seen before. I've got an OS/2 PEER LAN box set
up as a server. I have another one set up as a work station. The work station
is MCP2 latest XRC05 level code with all the MPTN and PEER fixes and so on.

The PEER LAN 'server' box is, as best I can tell, set up for sharing drives C:,
D: and E: here and for fixed addressing on LAN0 with local host on 127.0.0.1 as
well. The work station box is set up, at least in this case, supposedly for
fixed addressing, properly defined as to host name in config.sys and the TCP/IP
setup. I've chosen to define the connected resource on the work station for
the 'server' drive C: as drive V:, the connected resource on the work station
for the 'server' drive D: as drive W: and the connected resource on the work
station for the 'server' drive E: as drive X:

In this case the 'server' drive C:, D: and E: are actually partitions of just
under 2048K or 2GB so that there will be no issues about the use of any of them
for DOS-VDM applications.

OK .. I can log in to the work station. I can see, access and use the 'server'
drives on the work station under OS/2 sessions just fine.

But the instant I try to open any DOS-VDM session, somehow an 'error' happens
which totally faults out the PEER LAN connection for all of the PEER LAN
drives! Even under OS/2 after I once touch any DOS-VDM application, I cannot
access or do anything with any of these connections until I reboot the work
station and start again! I've never seen this before.

I've checked the DOS session settings. Yes .. last drive is "Z" as usual. As
far as I can see nothing I am doing is any different on a bunch of other box
collections that work just fine this way.

Any thoughts on how I can trace this error and what to look for? Thanks!

[Bob Plyler]

Post by Mike Luther
I just hit a problem I've never seen before. I've got an OS/2 PEER LAN
box set up as a server. I have another one set up as a work station.
The work station is MCP2 latest XRC05 level code with all the MPTN and
PEER fixes and so on.
The PEER LAN 'server' box is, as best I can tell, set up for sharing
drives C:, D: and E: here and for fixed addressing on LAN0 with local
host on 127.0.0.1 as well. The work station box is set up, at least in
this case, supposedly for fixed addressing, properly defined as to host
name in config.sys and the TCP/IP setup. I've chosen to define the
connected resource on the work station for the 'server' drive C: as
drive V:, the connected resource on the work station for the 'server'
drive D: as drive W: and the connected resource on the work station for
In this case the 'server' drive C:, D: and E: are actually partitions of
just under 2048K or 2GB so that there will be no issues about the use of
any of them for DOS-VDM applications.
OK .. I can log in to the work station. I can see, access and use the
'server' drives on the work station under OS/2 sessions just fine.
But the instant I try to open any DOS-VDM session, somehow an 'error'
happens which totally faults out the PEER LAN connection for all of the
PEER LAN drives! Even under OS/2 after I once touch any DOS-VDM
application, I cannot access or do anything with any of these
connections until I reboot the work station and start again! I've
never seen this before.
I've checked the DOS session settings. Yes .. last drive is "Z" as
usual. As far as I can see nothing I am doing is any different on a
bunch of other box collections that work just fine this way.
Any thoughts on how I can trace this error and what to look for? Thanks!

I would check the DOS VDM tcp/ip settings. Also, you might
try doing the following:

"iptrace" in an OS/2 window.
Then do the DOS VDM that causes the problem.
go to the iptrace window, then hit enter to stop the trace
"ipformat -x" in the window you did IPTRACE in.
Look at the resulting file "IPTRACE.ENC" with ethereal/wireshark

from http://www.wireshark.org

Bob Plyler



Then look

[Mike Luther]

Thank you Bob!

Post by Bob Plyler
I would check the DOS VDM tcp/ip settings. Also, you might

Where are the DOS VDM settings? I'm familiar with the DOS Session settings.
Also with the TCP/IP setup operations as well as the MPTS setup operations.
But as I understand this, there is nothing in these options which is specific
to DOS VDM tcp/ip settings. Is this something which I need to do by hand
editing the OS/2 LAN .INI files somehow? And if so, can you steer me to the
right place and needs for that?

Post by Bob Plyler
"iptrace" in an OS/2 window.

Let's save this for after the above. Haven't done this is a while but do have
a basic understanding of what you suggested.

Post by Bob Plyler
Bob Plyler

Thanks for trying to help me.

[Bob Plyler]

Post by Mike Luther
Where are the DOS VDM settings? I'm familiar with the DOS Session
settings. Also with the TCP/IP setup operations as well as the MPTS
setup operations. But as I understand this, there is nothing in these
options which is specific to DOS VDM tcp/ip settings. Is this something
which I need to do by hand editing the OS/2 LAN .INI files somehow? And
if so, can you steer me to the right place and needs for that?

I thought there were. But I don't see any settings in VDM.

You might try disabling TCPIP in VDM sessions by remming out

DEVICE=x:\MPTN\BIN\VDOSTCP.VDD
RUN=x:\MPTN\BIN\VDOSCTL.EXE
and
DEVICE=x:\TCPIP\BIN\VDOSTCP.SYS
from config.sys

Bob Plyler

[Paul Ratcliffe]

Post by Bob Plyler

Post by Mike Luther
Where are the DOS VDM settings? I'm familiar with the DOS Session
settings. Also with the TCP/IP setup operations as well as the MPTS
setup operations. But as I understand this, there is nothing in these
options which is specific to DOS VDM tcp/ip settings. Is this something
which I need to do by hand editing the OS/2 LAN .INI files somehow? And
if so, can you steer me to the right place and needs for that?

I thought there were. But I don't see any settings in VDM.
You might try disabling TCPIP in VDM sessions by remming out
DEVICE=x:\MPTN\BIN\VDOSTCP.VDD
RUN=x:\MPTN\BIN\VDOSCTL.EXE
and
DEVICE=x:\TCPIP\BIN\VDOSTCP.SYS
from config.sys

What's any of this got to do with Peer? And even if it had (which it doesn't)
how do you know what Protocol he's using?

[Mike Luther]

Thanks again Bob

Post by Bob Plyler
I thought there were. But I don't see any settings in VDM.
You might try disabling TCPIP in VDM sessions by remming out
DEVICE=x:\MPTN\BIN\VDOSTCP.VDD
RUN=x:\MPTN\BIN\VDOSCTL.EXE
and
DEVICE=x:\TCPIP\BIN\VDOSTCP.SYS
from config.sys

Yes, there are the precise entries in the OS/2 CONFIG.SYS which, per IBM
documentation *ARE* required for LAN support in DOS-VDM sessions. Further,
there is a specific warning that they actually must be in a certain order in
the CONFIG.SYS file for this to work and that if they are out of order it will
create problems.

Per the IBM documentation, if any of the above three items are not used, there
will be DOS troubles with TCP operations.

OK, for research, I happen to have a fully functional PEER LAN OS/2 collection
of boxes of which this one I am posting from is, in theory, exactly the same
setup for the work station as compared to the one which fails. I just compared
the CONFIG.SYS files for both boxes. They are EXACTLY the same as to the
precise placement in the grouping for the files above on both boxes.

As well, I am using exactly the same PROTOCOL settings in the MPTN operation;
only OS/2 NETBIOS and OS/2 TCP/IP. Plus the exact same motherboard is in use,
and the exact same Intel NIC chip, with the exact same MAC driver setup and the
exact same IRQ and log data from PCISNIFF as well for both boxes. Further, the
files VDOSTCP.VDD, VDOSCTL.EXE and VDOSTCP.SYS are the same date and size in
both boxes and in the same directories as needed.

No, at this point I've not run the OS/2 version trace utility to check what it
things about things, but the TCP/IP fixpack is the same on both boxes, so my
records show for work done on them.

I pulled the fault prone box off the LAN against the server where it fails,
temporarily put it on the LAN against the server where the failure doesn't
show. I rest the CONNECTIONS to test this on that LAN. Same exact failure
there. No residual damage that I can tell on the LAN and the PEER server
supporting it.

And this workstation I'm typing this on works fine in DOS-VDM operations
against a PEER LAN OS/2 server for it, but the one I am troubleshooting does
not. And no .. I don't dare yank it from service to test it on the other LAN
for security reasons.

Thoughts, other than IPTRACE and report here?

[Bob Plyler]

Post by Mike Luther
Thoughts, other than IPTRACE and report here?

You may want to manually verify the entries in the *.INI files in the IBMLAN
directory.


Bob Plyler

[Mike Luther]

Thanks Bob ..

Post by Bob Plyler
You may want to manually verify the entries in the *.INI files in the
IBMLAN directory.

I've done that on two boxes that fail this way, compared to what I can read in
a text editor for text type .INI files on a box that works this way on my
normal development system here. They are exactly the same.

In line with Will Harzell's thoughts and my reply to him I now know more about
this. The two boxes were DFSEE 'cloned' out of an upgrade of an IDE
workstation for this other network into SATA drives, but from the same
motherboard and hardware mix. I've now discovered that if I test a completely
same hardware box with a totally different SATA drive workstation from the
original site ..

It works on this switch, and the PEER LAN server unit is working fine.

Which was also produced as a cloned drive with DFSEE by the way, as was the now
seen working drive unit.

Thus with the very complex total professional template involved in my work,
what I'll do next is to more or less clone the working drive into one of the
two units for research next with Jan's DFSEE. If that results in a working
unit, I'll do all the ID requirement changes for the MPTN, TCPIP and LAN
changes one at a time on it, checking the results. That working, the only not
latest change in Fix Pack levels on this working unit is that PEER 8605 is on
it as contrasted to PEER 8608 I'm already using on all my normal work.

I'm almost sure as well that even the later released TestCase DHCP fixes for
the DOS-VDM autoexec.bat file closure failure post XRC05 and the updated
Kernel's match on all the stuff so far.

But I'll test for these as well in the research. I'd really like to know what
went wrong in all this, but keeping a failing drive for back tracing, and a
fully working drive from which to step forward is a far better way not to waste
your or anyone else's time here as far as I know things.

Thank you VERY much for the help. I'm learning more and deeply appreciate the
chance for that in life.

[Mike Luther]

Question Bob..

Post by Bob Plyler
I would check the DOS VDM tcp/ip settings. Also, you might
"iptrace" in an OS/2 window.
Then do the DOS VDM that causes the problem.
go to the iptrace window, then hit enter to stop the trace
"ipformat -x" in the window you did IPTRACE in.
Look at the resulting file "IPTRACE.ENC" with ethereal/wireshark
from http://www.wireshark.org

It's been a long time since I used iptrace. I tried the above for the
shortest possible successful log on in OS/2, a new OS/2 window session with a
log to a server drive and a one file DIR listing. I followed that with a
simple DOS-VDM window session opening to a command prompt, which trips the error.

I then stopped the iptrace run as in the above. But there is no dump file
length at all for the iptrace.dmp expected! Curious, I restarted iptrace and
then opened up Seamonkey. It showed all 127.0.0.1 activity on the Privoxy
enabled proxy server operation I have here. But no other activity except for
that!

Assuming that this means something is working, why doesn't the iptrace above
get any data for the LAN network log on, simple DIR read, then the DOS-VDM
operation which crashes the PEER operation?

Thanks!

[Paul Ratcliffe]

Post by Mike Luther
Assuming that this means something is working, why doesn't the iptrace above
get any data for the LAN network log on, simple DIR read, then the DOS-VDM
operation which crashes the PEER operation?

Because Peer is using Netbios I would guess. Seeing as you never post any
definitively useful information it's very difficult to tell.
I said this (to Bob) in a roundabout sort of way a couple of days ago, but was
conveniently ignored.
You are on a wild goose chase by pissing about with IP at a low level like
this, even if Peer was using it, which it appears not to be.

[Mike Luther]

Yes Paul ..

Post by Paul Ratcliffe

Post by Mike Luther
Assuming that this means something is working, why doesn't the iptrace above
get any data for the LAN network log on, simple DIR read, then the DOS-VDM
operation which crashes the PEER operation?

Because Peer is using Netbios I would guess. Seeing as you never post any
definitively useful information it's very difficult to tell.
I said this (to Bob) in a roundabout sort of way a couple of days ago, but was
conveniently ignored.
You are on a wild goose chase by pissing about with IP at a low level like
this, even if Peer was using it, which it appears not to be.

Yes, Paul, I'll gladly admit I'm not informed enough to post the most useful
information that would quickly let a person post the needed data to help me.
So said, I have gotten a LOT more up the technical ladder by participating here
in the OS/2 forums, and, in this case, I'm now learning a lot more about what
you point out. OS/2 is kind of like learning to really fly an airplane in
heavy weather instrument conditions. You can read the books all you want, even
go to class and get your ticket. But even with radar aboard the plane and all
that, I guarantee you that punching holes in squall lines and heavy
thunderstorms and all that based on the ticket you hold and what's on the radar
in front of you in the cockpit alone can sure teach you a lot more.

I thank you for the comment and the sincere efforts of all to help me keep
going up the OS/2 ladder here.

[Paul Ratcliffe]

Post by Mike Luther
Yes, Paul, I'll gladly admit I'm not informed enough to post the most useful
information that would quickly let a person post the needed data to help me.
So said, I have gotten a LOT more up the technical ladder by participating here
in the OS/2 forums, and, in this case, I'm now learning a lot more about what
you point out. OS/2 is kind of like learning to really fly an airplane in
heavy weather instrument conditions. You can read the books all you want, even
go to class and get your ticket. But even with radar aboard the plane and all
that, I guarantee you that punching holes in squall lines and heavy
thunderstorms and all that based on the ticket you hold and what's on the radar
in front of you in the cockpit alone can sure teach you a lot more.

Clouding the issue in all this sort of verbiage doesn't help either.
Sometimes you write 100 or more lines and say virtualy nothing. It is very
difficult to read. Verbal diarrhoea they call it.

[Trevor Hemsley]

On Thu, 6 Mar 2008 05:06:06 UTC in comp.os.os2.networking.misc, Mike Luther

Post by Mike Luther
But the instant I try to open any DOS-VDM session, somehow an 'error' happens
which totally faults out the PEER LAN connection for all of the PEER LAN
drives!

I had a similar problem a few years ago. The cause was that I had run one of
those config.sys sorting utilities that puts everything in order. The wrong
order it turns out. Reverting to a pre-sorted config solved the problem so I
have no idea which lines it was that caused it.

[Mike Luther]

Thanks Trevor for your time ..

Post by Trevor Hemsley
On Thu, 6 Mar 2008 05:06:06 UTC in comp.os.os2.networking.misc, Mike Luther

Post by Mike Luther
But the instant I try to open any DOS-VDM session, somehow an 'error' happens
which totally faults out the PEER LAN connection for all of the PEER LAN
drives!

I had a similar problem a few years ago. The cause was that I had run one of
those config.sys sorting utilities that puts everything in order. The wrong
order it turns out. Reverting to a pre-sorted config solved the problem so I
have no idea which lines it was that caused it.

In addition to all the other research work I've posted in the other vectors on
this, the latest try is here. I took a completely working similar MCP2 latest
everything box that does work with DOS-VDM's on PEER LAN. I hand worked the
CONFIG.SYS from that box to the CONFIG.SYS on the box that doesn't work, taking
care to hand synchronize the exact order and actions between the two boxes.
There were a number of priority changes in the line positions in the bad box
CONFIG.SYS, but no actual differences in the critical items between the two
boxes.

Modified bad box boots just fine. Unimaint and all says it is all perfect.
And *NO* the DOS-VDM open of any kind trashes the LAN operations with an 0059
error still! Logging off, then stopping PEER on the bad box then re-starting
PEER and trying another new LOGON will *NOT* fix this! In fact, the instant
you do that the duplicate user alert flashes when you try to LOGON. The only
way to recover this is to do a complete reboot. At which we are right back to
a fully functional PEER LAN operation so long as only OS/2 is involved.

This is getting interesting..

[William L. Hartzell]

Post by Mike Luther
Thanks Trevor for your time ..

Post by Trevor Hemsley
On Thu, 6 Mar 2008 05:06:06 UTC in comp.os.os2.networking.misc, Mike

Post by Mike Luther
But the instant I try to open any DOS-VDM session, somehow an 'error'
happens which totally faults out the PEER LAN connection for all of
the PEER LAN drives!

I had a similar problem a few years ago. The cause was that I had run
one of those config.sys sorting utilities that puts everything in
order. The wrong order it turns out. Reverting to a pre-sorted config
solved the problem so I have no idea which lines it was that caused it.

In addition to all the other research work I've posted in the other
vectors on this, the latest try is here. I took a completely working
similar MCP2 latest everything box that does work with DOS-VDM's on PEER
LAN. I hand worked the CONFIG.SYS from that box to the CONFIG.SYS on
the box that doesn't work, taking care to hand synchronize the exact
order and actions between the two boxes. There were a number of priority
changes in the line positions in the bad box CONFIG.SYS, but no actual
differences in the critical items between the two boxes.
Modified bad box boots just fine. Unimaint and all says it is all
perfect. And *NO* the DOS-VDM open of any kind trashes the LAN
operations with an 0059 error still! Logging off, then stopping PEER on
the bad box then re-starting PEER and trying another new LOGON will
*NOT* fix this! In fact, the instant you do that the duplicate user
alert flashes when you try to LOGON. The only way to recover this is to
do a complete reboot. At which we are right back to a fully functional
PEER LAN operation so long as only OS/2 is involved.
This is getting interesting..

It is as Paul says, which variety of SMB are you using? I assume that
it is the Netbios over TCPIP type? You are saying that everything is ok
with Peer until you open a single DOS window. Then you lose Peer.

Compare your Autoexec.bat files between the working OS/2 box and the one
with this problem. They should be the same. Now open a text file on
the broken machine from the share that's on the serving Peer using the
system editor, and minimize. This is to make sure that the OS/2
requester is in use. Open a DOS window to \TCPIP\DOS\BIN and try Ping
the address of the server box (q to quit). Then ping the server box by
name. Next type in NET VIEW. Unless you have DOS requester installed,
it should fail. Close the DOS window. If ping by address works and by
name works, then the TCPIP stack for DOS is working. Does these actions
cause OS/2 requester to exit with the above error?

Next open an OS/2 window and type in NET VIEW. If requester has failed,
this request should start the requester. Does it? IF Logon fails, try
Logoff, then Logon. Logon & Logoff requires requester to be working.
In fact you have requester running if you get to the logon prompt (or
get the duplicate user logon error). Try a different user at the logon
prompt (may mean you'll need to define another user). Does the other
user work? The duplicate user logon to the remote machine error can be
expected if there was a crash in local Peer. That is why I suggest Logoff.

Still got the same problem? Restore the system from your backup. Life
is too short to go farther with this. You've got something that has
corrupted one file that is the cause of this. It is not a configuration
error.

[Mike Luther]

Thanks for your time too Will

Post by William L. Hartzell
It is as Paul says, which variety of SMB are you using? I assume that
it is the Netbios over TCPIP type? You are saying that everything is ok
with Peer until you open a single DOS window. Then you lose Peer.

SMB? I'm using OS/2 NETBIOS and OS/2 TCPIP, if that is what you are asking. I
am NOT using Netbios over TCPIP as a formal selection in any of my networking
boxes which are only used with OS/2 operations.

Post by William L. Hartzell
Compare your Autoexec.bat files between the working OS/2 box and the one
with this problem. They should be the same.

They are. Further I have tested reducing the 'standard' AUTOEXEC.BAT to the
minimum as installed by OS/2 version. Without delete file slushing and so on.
In this case the error still exists.

Post by William L. Hartzell
Now open a text file on the broken machine from the share that's on the
serving Peer using the system editor, and minimize. This is to make sure
that the OS/2 requester is in use.

Done.

Post by William L. Hartzell
Open a DOS window to \TCPIP\DOS\BIN and try Ping
the address of the server box (q to quit).

Done. It works fine that way.

Post by William L. Hartzell
Then ping the server box by name.

Doesn't work with DOS PING.EXE. Nor does it work as a 'by name' operation on
any PEER LAN operation I have here, even on the whole ROSE KVM rack normal
operation I have. The by name operation sends to an apparently 'found' name
that is a HOSTNAME which corresponds to all the other 'name' data fields for
that in all the .INI files. But there is never an answer from that target!

Post by William L. Hartzell
Next type in NET VIEW. Unless you have DOS requester installed,
it should fail.

Done. That shows the identity of the server and comment name. Which is
correct as verified by the setup information objects in the server as well.

Post by William L. Hartzell
Close the DOS window. If ping by address works and by
name works, then the TCPIP stack for DOS is working. Does these actions
cause OS/2 requester to exit with the above error?

The instant you touch any kind of a DOS-VDM application or command prompt, it
trashes the PEER operation for that work station.

Post by William L. Hartzell
Next open an OS/2 window and type in NET VIEW. If requester has failed,
this request should start the requester. Does it? IF Logon fails, try
Logoff, then Logon. Logon & Logoff requires requester to be working.
In fact you have requester running if you get to the logon prompt (or
get the duplicate user logon error). Try a different user at the logon
prompt (may mean you'll need to define another user). Does the other
user work?

From the error point on, you can try any of a number of users I have

Post by William L. Hartzell
The duplicate user logon to the remote machine error can be
expected if there was a crash in local Peer. That is why I suggest Logoff.

But Logoff doesn't make a bit of difference at that point! The only way you
can recover the PEER connectivity is to reboot the whole system and start over.

BTW if you do a NET ERROR operation, you get the log line like:

REQUESTER 3190 03-07-08 5:28pm
NET 3190 A Netwksta internal error has occured:
NCB Done: NCB not recognized?

Post by William L. Hartzell
Still got the same problem? Restore the system from your backup. Life
is too short to go farther with this. You've got something that has
corrupted one file that is the cause of this. It is not a configuration
error.

At the moment, that is the worst of all possible fixes here. I have two
completely set up complicated boxes that are totally ready to go and I then as
the last resort, checked DOS-VDM operations which are absolutely needed. BLAM
I hit this one!

I have two vectors to go here in trying to get enough information for help.
Sometime later tonight or tomorrow I'll try to IPTRACE the scenario as simply
as possible. I ought to be able to see a 'correct' log on via the OS/2 native
trace work. Then, I ought to be able to bash it with simply opening up a trial
DOS command prompt window session. That might give someone here enough more
information to help.

Secondly, I have another complete IBM 915GAVL box with a totally identical
hardware interface and about four SATA drive trays with different system
complete operation backups in each. I'm going to see if I have one which works
on my 'working' network. Then I'm going to try to switch it to this one and
see if one of these totally other system image trays doesn't do this. However,
at this point, other than host names and so on, as far as I know, all of them
are the same level of the tools and techniques.

Sigh ..

[Mike Luther]

Absolutely correct as to the problem, but not how it happened here!

Post by Trevor Hemsley
On Thu, 6 Mar 2008 05:06:06 UTC in comp.os.os2.networking.misc, Mike Luther

Post by Mike Luther
But the instant I try to open any DOS-VDM session, somehow an 'error' happens
which totally faults out the PEER LAN connection for all of the PEER LAN
drives!

I had a similar problem a few years ago. The cause was that I had run one of
those config.sys sorting utilities that puts everything in order. The wrong
order it turns out. Reverting to a pre-sorted config solved the problem so I
have no idea which lines it was that caused it.

I deeply appreciate that Eric Paxton sent me a private Email message which

Post by Trevor Hemsley
Mike, That triggered an old memory. I had a similar problem after sorting
the config file. The problem turned out to be the sequence of entires in
the file.
I'm in Blows at the moment so can't check but I *think* there is a file
entry for "Netwksta.???" Compare the place of that call between the two
boxes,

Dead on correct suggestion, but not for that reason!

I used GFC.EXE for OS/2 to carefully analyze a working CONFIG.SYS for
these MCP2 machines with a bad CONFIG.SYS. Here is what causes this
error here.

I keep DETAILED records on the work here. Worse than my wordy exchanges
some don't appreciate. From my records and the date of corruption revealed
from the CONFIG.00# files, I am SURE the error happened August 3, 2005
during
an update for IBM's Java 1.3.1 on these boxes.

The order of the files NETBIOS.OS2 and the IFS loader for NETWKSTA.200 was
reversed as follows in the CONFIG.SYS files for all boxes serviced with
this download of the Java 1.3.1 fix:

Post Java 1.3.1 fix:

DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2
IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN /N
DEVICE=C:\IBMCOM\MACS\E100B.OS2

The only way this will work properly is:

DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200
IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN /N
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2
DEVICE=C:\IBMCOM\MACS\E100B.OS2

I can absolutely guarantee that no CONFIG.SYS sorting utility was ever
involved with this error. I've never used one.

Eric suggested I post this in this fashion to the group. He does not want
to post here for the spam and trash that is attracted to the Email address
and otherwise for discussions here.

I hope this can help someone else. I thank all those who posted information
on what might help find this.