Using VDos with DOS DataBase Program and Named Pipes

[Anonymous]

I am looking for a solution that allows use to use our multi-user DOS based DataEase running against a SQL7 server in Windows 10. For the past four years we have been running it in Windows 7 64 bit using a virtualized Windows XP session. The multiuser aspects are handled by the SQL Server, but we do run up to four instances of DataEase in the virtualized XP session per station.

The backend server that houses the SQL7 database is named PENN2003SERVER. We achieve the starting of the program through the following batch file on C Drive of the Virtualized XP machine after mapping M to the directory that contains the database on the server:

SET DENAME=%COMPUTERNAME%
SET DEPATH=M:\DATAEASE
C:
CD \ c:\DATAEASE\tame\tame /I
CD \ CD DATAEASE
DBNMPIPE
DE16M =65000 -M -W M:\DATAEASE\CMANAGER

I have managed to get the script to run and attempted to login to the database only to get an SQL error 10004 Severity Level: 9 Unable to connect: SQL Server is unavailable or does not exist. I cannot seem to get past this error and am wondering if this is a protocol issue and how to get passed that.

In our present arrangement, we can run the program executable both off the mapped drive and the local drive referring to the mapped drive for only data. Running it on the local drive reduces network traffic.

The program uses extended memory.

We use the named pipes protocol for communication with the SQL Server.

Please advise of the solution if any to get past this point.

Robert

[Jos Schaars]

It has been a very long time ago I encountered DOS DataEase, I even didn’t know it could connect to a SQL server. So I can only make some comments to your batch file.

SET DENAME=%COMPUTERNAME%
That doesn’t work and should be: SET DENAME=%%COMPUTERNAME%%

SET DEPATH=M;\DATAEASE
M: is properly setup in vDos (USE M: M:\ or USE M: \PENN2003SERVER...)?

c:\DATAEASE\tame\tame /I
Tame doesn’t do anything to/for vDos.

I also don’t know if DataEase uses extended memory or XMS.

Jos

[Anonymous]

Jos,

Ok, will change the first item.

I did create that path manually before I started the batch file so I had that covered.

I had anticipated on taking Tame out.

It can use either Extended or XMS. The DE16M executable is for the extended memory.

So any ideas on how to get this to work?

[Jos Schaars]

XMS is protocol to handle/manage extended memory. Basically a 16-bit DOS program that utilizes XMS, requests extended memory from the XMS manager and swaps conventional and extended memory by XMS calls, so a real mode 16-bit DOS program has a kind of very fast method to swap memory w/o using a disk file. DOS programs, switching to 32-bit mode, can address beyond the 16-bit 1MB barrier, but still use XMS calls to inquire how much extended memory is available and how much to set aside for them.

I have no idea what DBNMPIPE exactly does. It intercepts DOS create/open calls and translates them, if needed, to Windows CreateFile() calls and forwards DOS reads and writes to Windows API calls?
Is DBNMPIPE a DOS (TSR) program (that needs NTVDM to run?), or a Windows 32-bit program? At the vDos command line, issue MEM and then DBNMPIPE, and check if it is loaded in DOS by a second MEM.
If it is a DOS program, start vDos.exe with the /log option. This will create a vDos.log file, perhaps it reveals something (unsupported calls, invalid paths).
You can also use Process Monitor (https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx) to see what’s going wrong.

Jos