Consider the runtime is a single executable and that traditionally a COBOL program would do it's call sub-programs sequentially .. by using threads the COBOL program can call a sub-program and have that program run while the caller program is still running. The threading is done within the runtime, the runtime does not leverage any system routines (such as Hyper-V). The runtime does not monitor nor is it aware of what load your program or programs need, that is up to you to manage. With threads you can also use messages so you can make your sub-programs report what their status is (i.e.75% done).

Ok.

If the runtime does not create system-thread I assume that my applications does not take advantage of using multi-core CPU. And I cannot use any Windows thread-scheduling knowledge.

My actual problem is exactly related to the visualization of the percentage. The background worker thread consumes a lot of resources (CPU and I/O) and the graphical window remaining freezed (e.g. 10%) until the thread ends.

Could  the variables IO_SWITCH_PERIOD and DISPLAY_SWITCH_PERIOD be useful ?

For the single execution of the rutime, yes it does not take advantage of using multi-core CPU. However, when you have mutiple runtimes executing, the O/S may take advantage of using multi-core CPU.

It is possible that IO_SWITCH_PERIOD and DISPLAY_SWITCH_PERIOD may be useful, you'd have to experimant to see if they help you. If the load issue is based on calling a program that makes a report you might consider using AcuConnect Distributed processing (even though AcuConnect would be on the same server as the runtime) and C$ASYNCRUN - Call C$ASYNCRUN along with your remote applications to allow AcuConnect to run asynchronously... this would allow your report program to run effectively independent of the display program.

Hi shjerpe, i'm a Davide's colleague. Thank you for your replies, but what davide was trying to find out is why a cpu intensive thread frezees al others running threads. In particular we have a background worker thread that perform a huge amount of delete on three different files; when this thread starts (on pcs that are 2 or 3 years dated)  the GUI become totally unresponsive and by clicking on any button Windows says that the window is not responding. We already know that the background thread is still working but our costumer doesn't, so they directly kill the wrun32 process. Please don't answer to try out "mass update", "bulk addition" or so; we already tried and they just make the process even worse as they take such a CPU load on the server that even other terminals that try to connect have speed degradation.

We are just trying to figure out how the multithreading works on Acu runtime, and if it is a real multithread (like you can achieve using any other language like C , C#, Java, Python and so on) or it is a proprietary implementation that tries to emulate it.

Threading has been available in Acu for sometime, it is a proprietary implementation. However, the runtime is not a thread-safe executable and this is one of the reasons that Acu hasn't been able to leverage O/S that do provide multi-threading like Hyper-V. If you can de-couple the programs that perform a huge amount of delete on three different files ... perhaps you can run them using C$SYSTEM or C$RUN or use AcuConnect Distributed processing to run these file intensive programs while the GUI program continues to run as well.

Ok we understood. But the goal in using multithreading is to perform multiple procedures with the perception of doing them concurrently; does it exist a way in acucobol to have a threaded procedure that executes many i/o without freezing the main thread on dated PCs? C$SYSTEM or C$RUN is not a suitable option.

Add this to your background process.

   accept is-there-a-key-pressed from input status.

You won't actually do anything with the result from input status for your situation. The accept frominput status will return control to the windows os for a brief time.  Basically your program will be 'checking in' to say that it is still alive.

Here is our solution in context...

77  is-there-a-key-pressed      pic 9.

    88 there-is-a-key-pressed   value 1 when false 0.

--------------------

start x-file

      invalid set eof to true

not invalid set eof to false

end-start

perform until eof

  perform check-for-excape-key-press

  if i-want-to-quit

    set eof to true

  else

    read x-file

          ...

  end-if

end-perform.

------------------------    

check-for-escape-key-press.

   set i-want-to-quit to false

   PERFORM CHECK-FOR-KEY-PRESS.

   IF ESCAPE-FUNC

      SET ESCAPE-FUNC TO FALSE

      PERFORM DO-YOU-WANT-TO-QUIT

      IF YES-ENTERED

         set i-want-to-quit to true

      end-if

   end-if.

check-for-key-press.

   set there-is-a-key-pressed to false

   move spaces to key-being-pressed

   accept is-there-a-key-pressed from input status.

   if there-is-a-key-pressed

      accept key-being-pressed LINE 1 POS 1 OFF time 1 auto.

Threading certainly allows you to have multiple programs processing concurrently. Let's discuss your I/O .. where are the data files .. I'll take a guess that they are on a mapped drive (i.e. Z:) .. one of the underlying issues with using a mapped drive will be performance and potentially file corruption .. are your data files residing on a mapped drive? If so, have you tried using AcuServer? Many of our customers present a "progress bar" type of dialog when their application does something intensive. This would present a clue to the user to wait until the progress bar disappears and then their screen is ready for user input.

Data are on the same local drive of the wrun32 and we perform this process in thread just because we don't want our users to wait for procedure ending, otherwise we could have put this procedure in the main thread with a progress bar avoiding any kind of multithreading coplexity.

However the workaround suggested by DMiller seems to work, the procedure in thread is a bit slowed down but at least it doesn't freeze anymore.

Thank you for support.

I apologize for being late in responding.  Setting the Runtime configuration "FILE_IO_PEEKS_MESSAGES" to "ON" or "FILE_IO_PROCESSES_MESSAGES" to "ON" usually helps prevent locked up screens during heavy i-o.

"FILE_IO_PEEKS_MESSAGES" must be newer than my (printed) version 7 documentation.  Which version of the runtime is needed to begin using this configuration variable, i.e. when did it become available?  Also, can it be turned on and off with a "set environment" statement?  

Looks like 7.2.0 ... SUBJECT: Windows XP "Not Responding" ghost window during FILE I/O

Change Number:  ECN-3146

Status:         Complete

Type of Change: Correction

Priority:       Medium

Date:        2005-06-22

Product:     ACUCOBOL-GT

Module:      wrun32.dll

New Version: 7.2.0

Machines Affected: Windows

Known Versions Affected: All

DESCRIPTION of problem or enhancement:

If your application spends more than a few seconds outside of an ACCEPT

statement, Windows XP will replace your application window with a ghost

window appending "(Not Responding)" to the window's title. The user can move,

resize or close the ghost window but not do anything else until the

application goes into an ACCEPT statement. Closing the ghost window will

tell the application to exit or display a dialog box allowing the user to

end the process if the application does not exit on its own.

To prevent Windows XP from creating this ghost window during FILE I/O you can

set the runtime configuration variable FILE-IO-PROCESSES-MESSAGES to "1".

However, this can cause keystrokes to be lost or to be queued for the next

classical (non-graphical) ACCEPT statement instead of being sent to the next

active graphical control.

This ECN adds a configuration varible, FILE_IO-PEEKS-MESSAGES, that

when set to "1" (on, true, yes) tells the Windows runtime to automatically

call the Windows PeekMessage() API function in between file operations.

The runtime calls PeekMessage() with flags that tell it to simply check for

messages without removing them from the message queue. This is enough to let

Windows know that the application is still alive and still responding.

Thanks,  I'll revise our minimum requirements for windows and begin windows load testing with the 7.2 runtime.