Re: CPC1224 SIGALRM

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

This sounds like a bug in the socket code.

I'm guessing here, of course, but often times folks will use an alarm 
signal (SIGALRM) as a means of timing-out communications.  So the C code 
might do something like:

1) Set alarm for 60 seconds.
2) Receive data from network.
3) If signal occurred before receiving was complete, it timed out.
4) If receive worked in less than 60 seconds, clear the alarm.

If there was a bug in the program that it did not clear the alarm (step 
4) then the signal could very well occur after the C program has ended 
and returned control back to the CL, causing the issue you're seeing.

The correct fix, here, is to change the C program to make sure the C 
program clears the alarm.



On 9/11/2014 1:45 PM, Rich Loeber wrote:
>     I have a CLLE program that calls a C program which does some socket level
>     communications and then, when completed, returns to the CLLE program.  The
>     CLLE then goes into a variable period of waiting for an external event
>     before calling the C program again.
>
>     The C program was recently changed and while testing the new version, it
>     works fine but 2 minutes after returning control to the CLLE program
>     (while it is legitimately waiting for the next event to happen), the whole
>     mess comes to a grinding halt with a CPC1224 message issued.  The detail
>     on the message reads: "A SIGALRM signal was received for the job.  The
>     action for the signal was to terminate the job.".
>
>     Is there some way to trap this in the CLLE and take some evasive action
>     rather than just terminating the whole mess?
>
>     Rich Loeber - @richloeber
>     Kisco Information Systems
>     [1]http://www.kisco.com
>
>     --------------------------------------------------------------------------
>
> References
>
>     Visible links
>     1. http://www.kisco.com/