DOS app $ Pentium IV

Point value changed by question poster.

Point value changed by question poster.

My initial response would be: if the application worked efficiently on the old server, put it back (i.e. the old maxim - if it isn't broke, don't fix it.) Of course without knowing the reasons you moved the app to a new server, this may not be a valid response.

The application vendor may not have given the whole story (i.e. it has problems with the P4 architecture in certain hardware configurations or hardware/software combinations).

Is there different software that runs on the clientworkstations vs. the server?

If the software is the same, and you have successfully run it on a P4 with WinXP, the logical next step (if you have the latitiude to do so) would be to install XP on the server to see if the problem is related to that specific hardware combination or the combination of that hardware and WinNT. I.E. so far we have the app working correctly on a PII with WinNT, so the logical conclusion would be that the problem is PROBABLY not related directly to NT (at least notby itself). We also have the app working on a P4 with WinXP, so the logical conclusion is that the problem is PROBABLY not related directly to the P4 (at least not by itself). You only know it doesn't work on the P4 (in your specific server configuration) with WinNT.

If the software isn't the same (i.e. there is a server app and a separate client app), it may be the server app that has the problem with the P4.

The bottom line here is that if the vendor continues to take the same line (purchase an upgrade and renew your service contract), it is up you to either accept this solution or experiment to prove the vendor wrong. Either way, you will end up spending money (either for the service contract or for your time and effort to prove the vendor doesn't know what they are talking about).

Here is what you can try :

1) See what type of resources that this application use. Does it uses the SCSI or sound or other specified network protocols.

2) Check and see if the config.sys or autoexec.bat settings is interfering. Like for eg, is the environment buffer is full or the files=xx buffer is not big enough.

3) See if there are any TSR running in the background. Remove those unneeded ones.

I am thinking most probably it's the number (2) that's causing the problem. Try putting the same config.sys/autoexec.bat or config.nt/autoexec.nt as in your previous machine.

Since you say have problem running the machine locally. Try booting up the system with bootdisk. Say, win98. Then run the application once you have access to the server. Oh, if it is NTFS, try getting some third party software that can read NTFS. If it runs fine, then it's NOT pentiumIV architecture problem.

Make sure you make a backup copy of this program in case something happens.

This idea has several problems, but it could be worth a shot:

Get a copy of Symantec Ghost and Ghost your old server. Then put the image on your new server. Yes, there would be all kinds of problems with hardware drivers (and the processor drivers especially), but NT "might" be able to load up. At that time, you could fix all the driver issues.
Then see if the application works. This would tell you that it had something to do with the way NT4 was installed on the new server (putting a Ghost image on the new server would over-write the NT install on the new server).
Again, there are problems with this idea, and NT might not even boot correctly on the new server, but it is just an idea.

BTW, the old and new servers both have the same service pack level???

As you have deduced, it's a Turbo/Borland Pascal 16-bit DOS program and it's hitting a division by zero (aka. RTE 200) error from the CRT timing routine.

You could try looking for a program call "moslo" to try to slow the server's CPU down, but your options quite limited (especially since you don't have the source). Technically, you don't need an upgrade, you sort of need to downgrade the server's CPU.

Are these the Pascal patches you tried?

http://www.brain.uni-freiburg.de/~klaus/pascal/runerr200/

Is the particular problem only when running an AMD processor?

This problem is solved by the patch amdk6upd.exe that can be downloaded fromMicrosoft (go to their homepage, click on search and enter the filename) or try
http://www.microsoft.com/Windows95/downloads/contents/WURecommended/S_WUServicePacks/AMDPatch/Default.asp

---

Here's a patch that may work for DOS applications:http://www.arcscience.com/downloads/DanceInstructions.doc

---

do a search for "dos Run time error 200" in order to get more hits.

Tim,
Your "initial response" WAS MY INTENTION. But because in the last 4 years, we had 3 problems with the old server, a double memory error, which can't be corrected by the ECC memories and two HDD failure, the general manager and accounting manager decided to move the application on the new server...!?!?
Other reason was that we made an upgrade to gigabit network in server's area and the new server has a gigabit NIC integrated and more resources.
About WinXP on the new server: we have more than 40 clients for this application, workstation OS can't give access to all and now is a production machine (unfortunately my attention was focused to the clients and later I saw that it doesn't works local).
Also I don't make any changes in software. Only a new hardware and a new backup software ? Backup Exec 9.0.

Abubin,
1. The network configuration is same.
2. Checked
3. Only defaults of the OS, RAID and Backup software.
4. Boot diskette ? this is not a solution.

Joseph,
The easy way is to reinstall from scratch. I think that a ghost image don't help me so much and don't works because the hardware differences (hard disks controllers). Both servers have the same OS version and SP or patches.

Ana777,
Both servers have Intel processors.
I will try your links.

Other idea?

Jeng,
I'm not a programmer. You can tell me, if this is the situation, which is the best way: downgrade de server's CPU or move back the application to the old server? Which one of these solutions offers more stability and performance?

Whoever sold the product might not have given the proper specifications, and something might have slipped by them that is causing you the problem

Is the software that runs on the client workstations the EXACT same as the one on the server?

If the software is the same, and you have had good results with running it in windows XP with a Pentium 4, then you might want to try installing windows XP on your server too, and if that doesn't work then you might just want to re-install XP on your other systems, and just install it on your server.

If the software is different, and you have two apps, one for the server, and a different one for the client, then the server app might be having problems with the P4, and the problem might lie solely there, and nothing to do with client apps.

There are several solutions which you can take, one would be that you can talk to the vendor about getting any possible updates and patches, or you can try and use a different processor .

I hope that this helps!

This might seem like a silly suggestion, but have you tried running this app in 'full screen' mode?

The bug is in the initialization for the delay procedure that is part of the initialization of the Crt unit. The delay initialization is called in every program that uses the Crt unit, not just on those that use the delay procedure. The Crt unit is included in most programs that are written in Borland Pascal.
The delay initialization counts how often a tiny do-nothing loop must be called in order to delay by 55 milliseconds (time measured by reading the Bios Time Counter at memory address 40:6C that ticks 18.2 times a second, i.e. each 55 milliseconds).

This number is then divided by 55 to get the number of calls for one millisecond. The result is written to a word (16 bit) variable. The overflow of this variable triggers the run time error (the meaning of Runtime Error 200 is division by zero, but it is caused by an overflow in this case).

By the way , what sort of does program are you using , try to find out and we might be able to help you .

Jason,
The software is only on the server. The clients don?t have installed any software related to this application. They have only a mapped drive and a shortcut to launch the application.

Dpetrak,
Checked.

Walter,
Yes I know. I read about that. Solutions?

First, are you running the latest NT4 Service Pack? There have been a bunch of problem in the ntvdm.exe module that have been fixed in SP4,5 and 6a.

Now to the good stuff:

HyperThreading (HT) or really fast processors (2Ghz+ up) can present aproblem with dos apps (actually, the ntvdm.exe process that these apps run in).

Before you do the stuff regarding disabling HT, you might want to request the following ntvdm.exe hotfix from MS, it resolved my problem without having to disable HT. You might want to disable HT anyway since NT doesn't really get any improved performance because of it. The MS article:
http://support.microsoft.com/?kbid=320694
title: 16-Bit Programs May Not Update the Screen on Processors Faster Than 2.0 GHz

Some of these new P4 chips (mostly in server boxes 2.2Ghz + higher) have this new feature called hyper-threading. Basically it presents the OS with 2 logical processors per each physical processor. Read more about it here: http://www.intel.com/technology/hyperthread/

HT (hyperthreading) isn't officially supported on NT4 or Win2K (although it works somewhat with Win2K). If you are sure that the new server only contains 1 physical processor, then check the performance tab in task manager. If the CPU usage graph is split in two, then you have HT turned on in the bios. Try turning it off in the bios. Afterward you should only see 1 processor in the CPU graph. You might need to either reinstall NT or change the hal/kernel so thatit matches your 1 processor system (remember that with HT on, NT saw 2 processors during setup).

Good luck, I suffered, but hopefully this will solve your problem.

Hi Bonham,
Your story is very interesting. I follow your links, but unfortunately it is not my situation. I use the last SP6a. The problem still exists.

I'm suprised no one mentioned this, so I guess I'll have to. I have a very old DOS app that my company uses. It won't run from the server console either, but I don't care. Standard MS guidelines say, "Don't run apps on the server". The reason, as you point out, is that they can lock up the server, or cause memory leaks, or any number of other problems that mean the server has to be rebooted, thus interupting the users. If you need to run a complex task, get a fast PC and run them on that. That was what my vendor recommended, and it seems to work.
Hope that helps.

***************************************

Thank you to all IT specialists who tried to help me.
The solution in fact was very simple but take me some time to find it.
Jeng tell me about a program call "moslo". I send an email to this company to ask about an evaluation program. Dr. David from this company asks me if I customized the properties for the EXE file in Misc. tab \Idle sensitivity. Tried that before but no luck.

I look again over the options available in the shortcut's properties and I found something what I don't used until now.

In Program\WindowsNT you can see "Custom MS-DOS initialization files" window. Here exist a checkbox
"Compatible timer hardware emulation" which doesn't was enabled by default. I enable this option and finally the problem was fixed without any additional patches or something else.

This option means: "Enables MS-DOS based applications to reduce the rate at which the computer's timer sends timing signals."

****************************************

This question was closed by the author