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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

16-bit Unix Application

Status
Not open for further replies.

BWK

IS-IT--Management
Jul 6, 2000
13
US
My company uses a 16-bit application to access programs run on a Unix server.  The application is published on a Metaframe 1.8 server farm with Windows NT 4.0 TSE and service pack 6.  There is a latency in the screen update on workstations where a user can enter an entire screen of updates before the cursor moves on the terminal session.  When the screen does refresh all changes can be seen.  This is a problem as real-time response is required for some transactions.  I have checked the network connection and reponse time on most of the workstations and the 16-bit application is the only one with latency.  When running a full desktop with Run in separate memory space checked the latency disappears.  I have not found a way to force published applications to use a separate memory space.  Has anyone experienced this with published 16-bit applications or found a method to force use of separate memory space?
 
Just some information to think about.&nbsp;&nbsp;16 bit applications tend to hold CPU utilization.&nbsp;&nbsp;I had seen in the past that 16 bit applications don't use the additional processors of a machine.&nbsp;&nbsp;Thus making every connection to the 16 bit application run off of a single processor.&nbsp;&nbsp;One of the best tests is to launch Task Manager on the server and launch the application several times and notice what happens.&nbsp;&nbsp;Also to really show the CPU utilization of a 16 bit app try this little test.&nbsp;&nbsp;Lauch Task Manager, open a command window, type edit and press enter.&nbsp;&nbsp;Once edit launches, hit the ALT button to make the menu active.&nbsp;&nbsp;Notice your CPU.&nbsp;&nbsp;It waits for the next command.&nbsp;&nbsp;CPU should start to spike.<br><br>I have run in to this in the past and never really found a fix primarily because it is application based not Citrix based.&nbsp;&nbsp;Hope this sheds some light.<br><br>Joe <p> <br><a href=mailto:eek:neworld@goes.com>oneworld@goes.com</a><br><a href= >
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top