Highlighted
Absent Member.
Absent Member.
2726 views

[archive] Using parallel threads to process transactions at the same time!

[Migrated content. Thread originally posted on 23 July 2009]

Current Implementation: Server socket (created using C$Socket library) listens continuously. Client connects to the server socket, sends 1 claim, the claim is processed, and response is sent back to the client. So, only one client connects at 1 time and only 1 claim is processed per connection.

Proposed Implementation: To allow multiple clients to connect using 1 server socket and process multiple claims at the same time. Each client connection will send only one claim so that TCP/IP session management is used.

Challenge: At this point in time, we are able to read multiple client claims/transactions using 1 server socket (C$Socket). We have created multiple threads to process the read claim data at the same time. Based on the code developed so far, the first claim is send to the first thread but the second claim although successfully read from the socket and available is not send to the second available thread until the first thread has complete its processing. As a result we are unable to achieve parallel claim processing. Please see that we are using arrays to read claims and pass them to available threads. These arrays are shared between the threads and the main process.


QUESTIONS:
1. How to use multiple threads to process parallel claims/transactions? Is this possible in ACUCOBOL-GT? Please provide sample code that performs such an operation.

More information:
UNIX server runs HPUX B.11.23 U ia64. operating system
ACUCOBOL-GT Runtime Version: 7.0.1 and patch set 820
AcuConnect - Thin Client Version: 7.0.1
Communication protocol used - TCP/IP
0 Likes
13 Replies
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

C$SOCKET is, as many of the library functions a direct call to OS API functions, the wrapping mechanism is not a part of the portable multithread support in ACUCOBOL-GT. Thus there is no way to have multiple C$SOCKET calls running in parallell in a single runtime.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

Yes - the old chestnut with threads - I mentioned this in another post recently on progress bars. It really is a nusisance that these type of calls (including c$system) will not run in concurrent threads, a mechanism that would be very useful. If the whole run unit is put into a wait state it nullifies the perceived advantage of using threads for concurrent processing.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

Thanks for the replies.

Just for more clarification, if client data is read/available and there are multiple threads running the same code(claims processing code) then each thread will wait for the previous thread to finish before accepting client data for processing. Is this correct?

In conclusion, parallel transaction processing cannot be done using ACUCOBOL-GT threads and C$Socket cannot read multiple claims/transactions at the same time. Please confirm.

Is there another product from Micro Focus that allows multiple clients to connect to a server socket and send claims/transactions for parallel processing?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

Parallel transaction processing can be done using ACUCOBOL-GT threads within cobol programming, but the problem seems to be that when a thread calls any OS function it effectively suspends processing of all threads within the ACUCOBOL runtime unit until it completes the function call. Gisle says this is true of the C$SOCKET routine - I know it is true of the C$SYSTEM routine.

I do agree with your inferred criticism of the situation with threads we wish to use in the manner you suggest - which is very limiting. Perhaps they might change this behaviour in a future release?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

As stated by you that "Parallel transaction processing can be done using ACUCOBOL-GT threads within cobol programming". We run multiple copies of the same thread in a program and store the different thread handles into a handle array. Can this multiple copies of the thread be considerd as multiple threads and can be run in parallel? The code for thread does not have C$Socket function in it but the main program that send data to the threads has C$Socket function in it.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

yes. For instance a menu program can call a selected program in a new thread and then the menu program will continue to allow another program to be started in another new thread -all these threads running simultaneously with the main menu program still being active.

We for instance start a program in another thread to bring up a window showing a transaction reference number when any of our transaction processes complete.

You do need to be careful using threads and making sure they are controlled and terminated correctly. Using the debugger to try to sort out issues with threads is a real ball breaker. Also remember to bind to thread as you will want to have the runtime system deal with swapping from one thread's screen to another.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

Thanks for the input.

In your example it seems that different threads have different code. In our case, there are five threads running the same code and access some common global variables. The main program sends data to the empty threads using the thread handles. Our problem is that after the first claim is send to the first thread, the SEND data to second thread statement in the main program does not get executed until the first thread has completed its processing. Is this because the threads are running the same code and share same global variables? Any suggestions on why this might be happening?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

We do not use SEND DATA, so perhaps this may be the culprit to your problem.

You could try letting the main program create the thread and write the data you want to send to the thread to a file named say as the 'thread_id.dta'. The thread thus created would wait until it could open the file, process the data, delete the file and stop the thread. While this thread is processing you should be able to start a new thread for the next data set (claim?).

I can see no reason why your main program is waiting for the first thread to finish before allowing you to continue.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

In our application we use threads.
For example, the menu program calls programs in threads and allows messages to be sent (from our security routines - license expired etc etc)

Can you create a small reproducible example of your problem?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

Thanks for the reply.

I will use our test results to demonstrate what we started with, what is achieved and what still needs to be done.The goal is to find out if ACUBOBOL-GT allows multiple clients to conenct to the same socket (Clients will send 1 claim per connection) and then process these claims in multiple threads at the same time. We understand that C$Socket does not read multiple claims at the same time, so a max delay of 1-2 seconds between reads is acceptable. THE KEY IS TOTAL CLAIM PROCESSING TIME.

TEST#1 - The original code.(See attachment for test results)
Test conclusion: Although the client claim is read by C$socket while the previous claim is being processed by a thread, the new claim is not send to the next available thread until the currently running thread completes its processing. As a result, parallel processing cannot be achieved. Total processing time for last 8 claims (excluding first record) is 25.32 sec

TEST#2 - Changed the original code to lock the send data to thread code within the code to find next empty thread. Test conclusion: In this case moment the client data is read by the C$Socket, it is sent to the next empty thread and does not wait for the currently running thread to finish. The time to read client claims has reduced as compared to test#1. However for each client connection, the processing of claim previously read from the same connection, delays reading the next claim form that particular connection. It seems as if all code is running in sequence and not in parallel.Total processing time for 8 claims is 20.32 sec.

TEST#3 - In the above 2 tests the threads are responsible for sedning data back to the client using C$Socket and not the main process that initailly read them. The test 3 involves removing any OS Functions from thread code and moving them to main process. This will ensure that the main process is not suspended by any thread and continues to execute while other threads are processing. We are in the process of executing this thread and will post the results shortly.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: [archive] Using parallel threads to process transactions at the same time!

Some code would be essential I think - very cut down but with the main logic of the main program and the called (in thread) program you are calling. Are you limiting your application to five threads? I am not sure I understand what an 'available' thread is in your test results.
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.