Skip to main content

C$sleep in a Thread

  • August 31, 2016
  • 6 replies
  • 0 views
A
  • Anonymous

We are having a problem that I would like to hear if one of you have a solution for .

We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

(we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    6 replies

    D

    We are having a problem that I would like to hear if one of you have a solution for .

    We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

    When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

    (we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    I haven't tried this, but it's possible that if EVERY ACTIVE ACCEPT statement is "ACCEPT BEFORE TIME", then the thread will not switch. And therefore the window will not switch.

    I realize this may cause a bit of work for you, but it's all I can think of.

    D

    We are having a problem that I would like to hear if one of you have a solution for .

    We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

    When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

    (we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    Have you tried simply calling the Windows Sleep function? Note its argument is in milliseconds.

    D

    We are having a problem that I would like to hear if one of you have a solution for .

    We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

    When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

    (we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    What you are seeing is expected behavior when calling C$SLEEP in a THREAD.

    You should probably use "ACCEPT OMITTED BEFORE TIME {VALUE}" instead of the call to C$SLEEP.

    Here's an explaination from our development team:

    "Because of the way timers work, the runtime only ever sets one timer in the system.

    When the foreground thread calls C$SLEEP, the thread manager notices the other thread wants to do an ACCEPT. Since sleeping when trying to do an ACCEPT is bad (the ACCEPT never gets anything), the thread manager converts that ACCEPT to an ACCEPT BEFORE TIME specifying the sleep amount, and then lets the ACCEPT thread run (it will straighten everything out when the ACCEPT expires).

    The ACCEPT wakes up and notices that its window is not active, but that no other threads are controlling the screen. So it activates its window in accordance with the normal rules for ACCEPT handling.

    The problem with having multiple threads is that whenever the runtime encounters a COBOL verb that requires user interaction it will treat that as an opportunity to check whether the other threads should do some processing."

    A
    • Anonymous
    • September 14, 2016

    We are having a problem that I would like to hear if one of you have a solution for .

    We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

    When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

    (we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    Thank you for your answeer. It sounds reasonable, but my problem is, I use the same sleep command whether I am in a window with focus or not. If I use your suggestion I think the program which is not in focus, jumps into focus because of the accept.

    Do you know if there is away to ask if a specific window is in Focus or not ?

    If that was possible I could choose the right sllep command for each process

    A
    • Anonymous
    • September 14, 2016

    We are having a problem that I would like to hear if one of you have a solution for .

    We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

    When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

    (we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    How is the Windows sleep command called ?

    D

    We are having a problem that I would like to hear if one of you have a solution for .

    We are running thin client, 9.2.1 and we have a Menu system which starts threads of subprograms.

    When these subprograms reads a record which is locked we normally call C$sleep and read again after a few ticks. But unfortunately this behavior makes the focus of the window change to another subprogram. These is of course done because windows concludes that the subprogram with the sleep does not need ressources right now, and it would be a good idea  to bring anoher program in focus. We have stopped using the c$sleep and calls a while loop, and it is functioning very well, but unfortunately this behavior uses a lot of CPU etc. Do you see any other possibilities ?

    (we have also tried accept upon time, but this brings the program in focus, also if the user has switched the program in background)

    It's the Windows Sleep function, not command. It's a Windows API. Also note the capital "S".

    It would be called the same way any Windows API is called in ACUCOBOL. I haven't used ACU (keep meaning to install it and play around to get some familiarity, but haven't had a chance), so I don't know exactly what's involved. In MF COBOL you'd just use  CALL statement with a literal program-name of "Sleep" and the appropriate calling-convention. The time (in milliseconds) would be passed BY VALUE.

    Documentation for calling Windows API functions from ACU can be found here:

    http://documentation.microfocus.com/help/topic/com.microfocus.eclipse.infocenter.extendACUSuite/BKITITWINDS020.html

    The Sleep function is in Kernel32.dll.

    There is a Windows command which sleeps for a given period of time - the timeout.exe program, which is in %WINDIR%\\System32. But that's not what you want.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement