Hello Keith,

Quick question are you also running Acuconnect TC V8.n.n  on the same Server that you are trying Acuconnect TC V 10.3.1 on?

If so please try running  your Programs through Acuthin V10.3.1    after you stopped the Acuconnect TC V8.n.n  on that machine.

I ask this because I had a customer who also had a slow performance  when testing the newer Acuconnect TC   but the performance was good once he temporarily stopped the old Acuconnect TC Version.

It's no guarantee but if you have both Acuconnect TC Versions installed and running on the machine it should be an easy and fast test to do.

Take care, Piet

Hello Piet,

Thank you for responding to my issue.

I have installed ACUTHIN v10.3.1 on a brand new server running 2016.  The old ACUTHIN 8.1.1 was installed on Windows 2003.  SUpport indicated that my issue was related to 32/64 bit.  I was running the 64 bit service, but running the 32 bit executable on the client PC.  However, I have since deleted the 64 bit service running on port 5632 and started the 32 bit service on the same port.  

CLIENT PC call for ACUTHIN

"C:\\Program Files (x86)\\Micro Focus\\extend 10.3.1\\AcuGT\\bin\\acuthin.exe" nd0acuwtv01:5632 utilmenu

I have no issues with I/O or Screen displays - those statements execute immediately, but as soon as I "CALL" another COBOL program, the delay kicks in.  I actually see a bit of a lag when the first program is started as well.

CLIENT PC call for ACUSERVE

"C:\\Program Files\\Micro Focus\\extend 10.3.1\\AcuGT\\bin\\wrun32.exe" -c \\\\nd0acuwtv01\\CobolCfg$\\cblconfi.srv \\\\nd0acuwtv01\\object$\\utilmenu.acu

First couple of lines from cblconfi.srv

ACUSERVER-PORT 6523
CODE_PREFIX \\\\nd0acuwtv01\\Object$

Are we dealing with some network latency on how each of the products work?

Thanks,

Keith

There should be any discernable difference when using 32 bit or 64 bit runtimes on the server. The client (acuthin) is 32 bit, it can access either 32 bit or 64 bit server runtimes. A 64 bit runtime is not going to be much faster than 32 bit unless you are actually doing 64 bit processing or accessing a 64 bit .Net assembly.

What we have seen is that Microsoft has become more restrictive for using a network share like \\\\nd0acuwtv01  .. CODE_PREFIX \\\\nd0acuwtv01\\Object$   network share permissions seem to change with more current Microsoft servers

From the config - the  COBOL application file are on nd0acuwtv01 .. do the data files also reside on nd0acuwtv01

If both resources exists on the server running AcuServer, consider changing the config entries so that the COBBOL application files and data files use AcuServer:

FILE_PREFIX @server-name:path-name
CODE_PREFIX @server-name:path-name

You are correct - its all about the network share on the config file.  I brought the config file over directly from our production environment.  As soon as I changed it to match the FILE-PREFIX method, my performance is exactly the same as ACUSERVER.

#CODE_PREFIX \\\\nd0acuwtv01\\Object$
CODE_PREFIX @ND0acuwtv01:D:\\CobolWorkspace\\Object

Such an easy fix!  

Thanks for the support!