I have a application that's been running for 10 years, summer 87, using blinker. The program works great accross VPN, on 2000 machines, on xp machine being used as a server, with a total of 6 machines. Two of the XP pro machines will load the program, load the menues, but when it gets to a data entry screen with a database attached it just stop, the cursor sits on the bottom of the screen and waits. The funny thing is that it work on this machine before, I can't figure out what has changed, as it's in my clients office. The problem occurs no matter where the program is running from, c: , flash drive, vpn. There must be a variable setting, I've changed the config.nt to files=250 but no luck, I could sure use some help on this one.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Program works on one Xp pro machine locks on different XP machine
- Thread starter emucode
- Start date
Hi,
This is a clipper hogging all the resources problem. When it's on a data entry screen - in a @ SAY GET - it essentially does a lowish level InKey() and waits for the user to press a key. On a server this will take nigh on 100% of a processors attention.
Most servers have more than one processor, or a dual or quad core processor (which works in much the same way). So for a dual core, the first iteration of your program will take 100% of one processor - 50% of your servers capacity, the second copy of the program will then absorb the other 50%, making your server virtually useless.
There is a fix for summer 87 though!
Download the idle.zip from here
Good luck
Regards
Griff
Keep [Smile]ing
This is a clipper hogging all the resources problem. When it's on a data entry screen - in a @ SAY GET - it essentially does a lowish level InKey() and waits for the user to press a key. On a server this will take nigh on 100% of a processors attention.
Most servers have more than one processor, or a dual or quad core processor (which works in much the same way). So for a dual core, the first iteration of your program will take 100% of one processor - 50% of your servers capacity, the second copy of the program will then absorb the other 50%, making your server virtually useless.
There is a fix for summer 87 though!
Download the idle.zip from here
Good luck
Regards
Griff
Keep [Smile]ing
JockMullin
MIS
Hi, emucode
I agree with Grif's suggestion about the wait states insertion to keep the s'87 prog from hogging the cpu, but it should still run OK locally unless there is something else on the machine also cpu-intensive. You can check that easily with task manager - is the program still flogging the CPU when it hangs? Are there other processes also using a lot of cpu cycles?
Possibly something has changed in the configuration of the machine which has altered DOS memory availability. Look at the output from doing mem /d in a cmd window and compare it to a machine on which the program works.
Use of expanded memory manager under XP can be a problem; have you set clipper environment variable with the e0 option to disable it?
Finally, I would really recommend you look into porting the app to xharbour. I have had good results in configuring the xHarbour compiler to compile (well-written) S'87 programs with very few code changes, and the result is much quicker and better-behaved under current versions of windows while retaining the look and feel and being interoperable with S'87 exe's. However this may be difficult if you are using 3rd party clipper libraries, not all of which have equivalents.
Jock
I agree with Grif's suggestion about the wait states insertion to keep the s'87 prog from hogging the cpu, but it should still run OK locally unless there is something else on the machine also cpu-intensive. You can check that easily with task manager - is the program still flogging the CPU when it hangs? Are there other processes also using a lot of cpu cycles?
Possibly something has changed in the configuration of the machine which has altered DOS memory availability. Look at the output from doing mem /d in a cmd window and compare it to a machine on which the program works.
Use of expanded memory manager under XP can be a problem; have you set clipper environment variable with the e0 option to disable it?
Finally, I would really recommend you look into porting the app to xharbour. I have had good results in configuring the xHarbour compiler to compile (well-written) S'87 programs with very few code changes, and the result is much quicker and better-behaved under current versions of windows while retaining the look and feel and being interoperable with S'87 exe's. However this may be difficult if you are using 3rd party clipper libraries, not all of which have equivalents.
Jock
I too have a similar problem and discovered that it was a virtual memory problem. Apparently my program was making calculations that seemed to get page files. And somehow I discovered that it was zero divide that seemed to eat up the number of page files. I added a code that basically said if we're dividing by zero don't divide and my use of virtual memory significantly decreased. I also recommend that you make certain the VM on the machine is being set as needed as opposed to a fixed amount. I don't know if this is going to help your problem but it's something that you may want to consider.
harvey
harvey
emucode,
On the machine that is locking up do Ctl-Alt-Del and click the Task Manager button. Processor usage is at the bottom. If processor usage is at 100% it will take quite a while for the Task Manager to show up. Can you start another program or is the XP computer totally locked up?
Also, if a machine that locks up works if it is started first the resource problem will probably be at the server.
When your worstation locks up, do the other two continue to work normally?
The proper way to allow more files in Clipper is with the FILES command in the config ie. CLIPPER=/F50, without this the defalut is 15. In XP this is more properly set by right Clicking My Computer -> Properties -> Advanced tab, there click the Environment Variables button and Then the Add button. In the pop-up use CLIPPER as the variable and /F50 as the value. Note the isn't an equal sign. You can add this for just the current user or globally.
Good Luck,
Mike
On the machine that is locking up do Ctl-Alt-Del and click the Task Manager button. Processor usage is at the bottom. If processor usage is at 100% it will take quite a while for the Task Manager to show up. Can you start another program or is the XP computer totally locked up?
Also, if a machine that locks up works if it is started first the resource problem will probably be at the server.
When your worstation locks up, do the other two continue to work normally?
The proper way to allow more files in Clipper is with the FILES command in the config ie. CLIPPER=/F50, without this the defalut is 15. In XP this is more properly set by right Clicking My Computer -> Properties -> Advanced tab, there click the Environment Variables button and Then the Add button. In the pop-up use CLIPPER as the variable and /F50 as the value. Note the isn't an equal sign. You can add this for just the current user or globally.
Good Luck,
Mike
- Status
Similar threads
- Locked
- Question
- Locked
- Helpful tip
- Locked
- Question