Ensign
Ensign
1914 views

NETX 5.1 and Hyperthreading

Jump to solution

We have a COBOL application compiled with NetX 5.1 and have issues running it on a Windows 7 machine with hyperthreading enabled. The application is NOT multithreaded but works fine on XP machines that are hyperthreaded. The application reads data from an Oracle or Sybase DB, processes it and then writes to the same DB. Connectivity is via native ODBC.

The user is able to kick off multiple instances of a script (muti-process - not multi-threaded) that calls the same application (exe). Each application will read separate sets of account data, process and write the results. So essentially multiple instances of the application are executing in separate Command Window Shells - separate processes. This scenario works well on XP - hyperthreaded or not - but not on Win 7. In fact we see this issue on Win 7, even if a SINGLE application/process/instance is kicked off. The moment we turn off Hyperthreading, the application runs fine - single or multiple-process simultaneously.

We need to find a solution for our clients. At this time, the workaround is to disable hyperthreading but this is not always an acceptable solution to our clients.

To the question: Is hyperthreading supported my the Microfocus Compiler on the Windows 7 OS? Has this issue been reported before and do you have any suggestions on how we can debug and/or find the solution.

Tags (2)
0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

I am not sure that there is any such thing as a hyper-threaded aware application as this is something that is handled between the operating system and the CPU and it should really be transparent to the applications that are running.

You might try turning on the SQL(THREAD=ISOLATE) directive although this is really meant for actual multi-threaded applications and you state that yours is single-threaded.

When the 114 error occurs does it create an mfdebug.log file in the applications folder?

Can you please show me what is in that file?

If you have a reproducable test case then I would suggest that you open up a support incident with Customer Care and we can look into this further by getting our SQL Development team involved.

Thanks.

View solution in original post

0 Likes
3 Replies
Micro Focus Expert
Micro Focus Expert

Can you please be more specific as to what the actual problem is that you are experiencing when running the application with hyperthreading turned on?

Thanks.

0 Likes
Ensign
Ensign

The application fails - meaning it appears to be NOT able to retrieve data from the DB. The ODBC trace LOG shows this - jtxenp01.exe is our application. The application itself :

IAG [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed (0)

jtxenp01        142c-19a4 EXIT  SQLConnectW  with return code 1 (SQL_SUCCESS_WITH_INFO)

We also provided to Sybase some of their tracing and they see that the application fails on the SQL:

SELECT target_system, extract_data FROM sim_input

WHERE extract_id = @dr_ta0 AND sys_id = @dr_ta1    

ORDER BY seq_id"

This is what they have to say:

The connection just looks like it is killed or ends.

This makes me think its breaking in the application before even sending anything to the server.

All the customer traces end in the exact same place.

I do not have access to the actual Microfocus error at this moment - will get to it from our Support person - but essentially it was a 114 error and was not much help. It appears to break in the COBOL program that access/reads the data before processing the data.

0 Likes
Micro Focus Expert
Micro Focus Expert

I am not sure that there is any such thing as a hyper-threaded aware application as this is something that is handled between the operating system and the CPU and it should really be transparent to the applications that are running.

You might try turning on the SQL(THREAD=ISOLATE) directive although this is really meant for actual multi-threaded applications and you state that yours is single-threaded.

When the 114 error occurs does it create an mfdebug.log file in the applications folder?

Can you please show me what is in that file?

If you have a reproducable test case then I would suggest that you open up a support incident with Customer Care and we can look into this further by getting our SQL Development team involved.

Thanks.

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.