[archive] Identify how many sessions of AcuCobol Runtimes are running

[Migrated content. Thread originally posted on 15 May 2003]

I need to restrict users invoking more than one session of the runtime on Windows 98, XP and 2000 terminals. Is there any way to identify a session already in progress so that the 2nd session can be terminated?

You may use the Windows API to enumerate the active windows upon startup of a new instance. You may then examine the window related class, if this is of ACUCOBOL-GT you'd count it in and then decide further action on the counted number. This kind of programming does however require som insight in the Windows API.
Here are some clues:

Use the GetWindow function to enumerate.
Use the GetClassName and see if it is returning a string that matches "AcucobolWClass", if so, count it in.

[Migrated content. Thread originally posted on 15 May 2003]

I need to restrict users invoking more than one session of the runtime on Windows 98, XP and 2000 terminals. Is there any way to identify a session already in progress so that the 2nd session can be terminated?

Thank you Guy, I am not well versed in Windows API but I am willing to learn. I shall try it first. I may come back!:)

[Migrated content. Thread originally posted on 15 May 2003]

I need to restrict users invoking more than one session of the runtime on Windows 98, XP and 2000 terminals. Is there any way to identify a session already in progress so that the 2nd session can be terminated?

I think CreateMutex() is a better and easier approach to solving that problem from API point of view.

Mutex stands for MUTual EXclusion object and is normally used to enforce threads in multi thread apps. Separate runtimes (instances of the wrun32 app) run in separate processes but they can share mutex via the name. There is a trick to determine if you are the orginal creator of the mutex. Check the windows API documentation for CreateMutex() and OpenMutex() you can call these functions directly from a cobol program be loading up the windows API dll.

logic:
1. app starts
2. calls openmutex: fails, continue on succeeds, user message and exit
3. call createmutex: blocks other apps from running
4. app closes, frees the mutex.

This is better than checking to see if windows of a certain class exist because AcuCorp may change the name of the class, for example. It is also simpler (2 API calls total).

regards,
Merlin