jkirman
asked on
Novell Netware 3.X in a HyperV session
Greetings,
I have a client that is using a legacy DOS application (yes, it's still out there) that was designed to run on Novell Netware 3.X. The program is written in the Clipper database language, and as an aside crashed and burned horribly in the old Windows NT environment. They've had Novell 3.2 running on an ancient Dell PE 2400 server for a decade plus, and I've finally convinced them it needs to be replaced. One of the options we're trying is testing Novell 3.X operating in a virtual server environment. The Novell 3.X server boots into DOS, in this case 6.22, and then runs the Novell server.exe to load the Novell OS. I've set up a HyperV virtual machince that boots off a DOS 6.22 virtual floppy drive, partitioned and formatted a drive C: on the virtual machine, and then copied in the Novell files to that C: drive. When I first run server.exe, it comes up OK at the file server console prompt, but my keyboard will not communicate with the Novell server.
My startup.ncf looks like this:
REM THE FOLLOWING LINES WERE ADDED BY THE 3.2 ENHANCEMENT PACK INSTALLATION
LOAD C:\SERVER.312\CPUCHECK
LOAD C:\SERVER.312\START\PM312
PMLOAD C:\SERVER.312\START
REM END MODIFICATIONS MADE BY THE 3.2 ENHANCEMENT PACK INSTALLATION
;******* PM312 is the NW v3.12 Patch Manager. ********
set auto register memory above 16 megabytes = off
set reserved buffers below 16 meg = 200
set enable disk read after write verify = off
set minimum packet receive buffers = 500
set cache buffer size = 8192
The autoexec.ncf is as follows:
file server name FS1
ipx internal net B5
register memory 1000000 6000000
set maximum alloc short term memory = 33554432
search add c:\server.312
load clib
load streams
load nwpaload
load ideata port=1F0 int=E
load pcntnw slot=301 frame=ethernet_802.3
bind ipx to pcntnw net=4444
mount sys
search add c:\server.312
set timezone EST5EDT
load nw4_idle
load remote test
load rspx
load monitor /p
Note that nw4_idle is required to keep the virtual Novell server from sending the host server's CPU utilization up to 90% or higher.
Any input on where I can tweak the keyboard access into the NW 3.X virtual server would be appreciated. I see no keyboard-related options in the Hyper-V console. If this doesn't work I'll be trying a vmware-based approach but would prefer to get this working in Hper-V if possible, as it is native to Windows 2008 server.
I left this at 500 points as this is an attempt to get ancient and current technologies working in unison.
Thanks in advance,
jkirman
I have a client that is using a legacy DOS application (yes, it's still out there) that was designed to run on Novell Netware 3.X. The program is written in the Clipper database language, and as an aside crashed and burned horribly in the old Windows NT environment. They've had Novell 3.2 running on an ancient Dell PE 2400 server for a decade plus, and I've finally convinced them it needs to be replaced. One of the options we're trying is testing Novell 3.X operating in a virtual server environment. The Novell 3.X server boots into DOS, in this case 6.22, and then runs the Novell server.exe to load the Novell OS. I've set up a HyperV virtual machince that boots off a DOS 6.22 virtual floppy drive, partitioned and formatted a drive C: on the virtual machine, and then copied in the Novell files to that C: drive. When I first run server.exe, it comes up OK at the file server console prompt, but my keyboard will not communicate with the Novell server.
My startup.ncf looks like this:
REM THE FOLLOWING LINES WERE ADDED BY THE 3.2 ENHANCEMENT PACK INSTALLATION
LOAD C:\SERVER.312\CPUCHECK
LOAD C:\SERVER.312\START\PM312
PMLOAD C:\SERVER.312\START
REM END MODIFICATIONS MADE BY THE 3.2 ENHANCEMENT PACK INSTALLATION
;******* PM312 is the NW v3.12 Patch Manager. ********
set auto register memory above 16 megabytes = off
set reserved buffers below 16 meg = 200
set enable disk read after write verify = off
set minimum packet receive buffers = 500
set cache buffer size = 8192
The autoexec.ncf is as follows:
file server name FS1
ipx internal net B5
register memory 1000000 6000000
set maximum alloc short term memory = 33554432
search add c:\server.312
load clib
load streams
load nwpaload
load ideata port=1F0 int=E
load pcntnw slot=301 frame=ethernet_802.3
bind ipx to pcntnw net=4444
mount sys
search add c:\server.312
set timezone EST5EDT
load nw4_idle
load remote test
load rspx
load monitor /p
Note that nw4_idle is required to keep the virtual Novell server from sending the host server's CPU utilization up to 90% or higher.
Any input on where I can tweak the keyboard access into the NW 3.X virtual server would be appreciated. I see no keyboard-related options in the Hyper-V console. If this doesn't work I'll be trying a vmware-based approach but would prefer to get this working in Hper-V if possible, as it is native to Windows 2008 server.
I left this at 500 points as this is an attempt to get ancient and current technologies working in unison.
Thanks in advance,
jkirman
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for your combined responses.
Mburdick, your recommendation to migrate off the current application is certainly among the best options we could choose. The client has spoke with their software vendor regarding upgrading the legacy DOS app to the current windows version, but unfortunately the cost is gargantuan. Most developers have a reasonable upgrade path for legacy users in this situation, however this vendor is basically punishing those who did not upgrade earlier - there's no other way I can put it. That said, one of the options still open is to go with another vendor, though if they can't convert the existing data then the alternative of retyping everything into the new system is not feasible. Also and FYI, the application itself is compiled Clipper, and runs as a single executable which manages the dbf, dbv and ntx files, so there is no need to tune the app or Clipper on the server. As long as the environment is hospitable, it runs without issue. Thanks again for your thoughts.
Deroode, thanks for the links provided - I've created a working Novell 3.2 environment under VMWare Server. I'm using the same startup.ncf and autoexec.ncf as I listed above. I used no special tweaks for the VM configuration, and can run the DOS application off of the VM very nicely. On my own system it seems stable in testing and performance, now we need to test this in parallel on the client system. I'm accepting your suggestion as the solution for the 500 points, since HyperV is a dead end, per what you wrote.
Regards and thanks again to all,
Jkirman
Mburdick, your recommendation to migrate off the current application is certainly among the best options we could choose. The client has spoke with their software vendor regarding upgrading the legacy DOS app to the current windows version, but unfortunately the cost is gargantuan. Most developers have a reasonable upgrade path for legacy users in this situation, however this vendor is basically punishing those who did not upgrade earlier - there's no other way I can put it. That said, one of the options still open is to go with another vendor, though if they can't convert the existing data then the alternative of retyping everything into the new system is not feasible. Also and FYI, the application itself is compiled Clipper, and runs as a single executable which manages the dbf, dbv and ntx files, so there is no need to tune the app or Clipper on the server. As long as the environment is hospitable, it runs without issue. Thanks again for your thoughts.
Deroode, thanks for the links provided - I've created a working Novell 3.2 environment under VMWare Server. I'm using the same startup.ncf and autoexec.ncf as I listed above. I used no special tweaks for the VM configuration, and can run the DOS application off of the VM very nicely. On my own system it seems stable in testing and performance, now we need to test this in parallel on the client system. I'm accepting your suggestion as the solution for the 500 points, since HyperV is a dead end, per what you wrote.
Regards and thanks again to all,
Jkirman
You *may* have better luck attempting to virtualize that machine into a Linux environment. Novell has documents and tools available to help you migrate a full Netware 6.5 server into the XEN environment on SLES... There *MAY* be enough there to allow you to do something similar with this box.
It's a long shot.
Instead of pushing the customer to replace the box, you need to have a heart-to-heart with them to replace the software. It's two decades old.