
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.
Accepted Solutions

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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.