Re: Signal API's

Hi Bill,

I haven't run into the problem you describe, and I'm not certain if it is or isn't related to signals?

I do write code that's used as external stored procedures and/or UDFs quite regularly, and I have a lot of screwy problems when code doesn't behave.

For example, I try to use a debugger to step through the code, and it ends up locking up the job and the job becomes "un-endable". Meaning ENDJOB doesn't succeed in ending it after it locks up. (Though, sometimes if you wait long enough it'll eventually end.)

Or if the program gets stuck in a loop due to a programming error, I can neither debug it nor end the job.

I haven't specifically had a problem with signals -- but there might be one related to that as well. So if you end up finding out anything about this, please share. I'd love to find out why these jobs are so difficult to work with.

On 5/10/2010 3:02 PM, Bill Greenfield wrote:

Does anyone know if the signal API's behave differently in a pre-start job
versus an interactive job? I ask because of the problem that I am having
using the API. I adapted (stole) some code from Scott Klement's article
'Handling Errors in TCP/IP Programming' created 10/23/05. When I
created a program to test this technique, all seemed to work as I
expected. When I run the program in debug mode, I had a break point on
the For loop. When I would sit on the break of the debug for an
appropriate amount of time, the 'got_alarm' routine would execute. I would
respond to the Dsply op-code and the program would return to the for
loop and execute. If I let the loop complete and execute the return all is
good. While getting ready to call the program again, if I wait to long,
the got_alarm would execute as I expect. I actually had to kill my session
to stop the got_alarm procedure from executing. Now, when I place similar
logic in a program that is running in a pre-start job (it is actually an
SQL stored procedure call that waits on xml input and then does a bunch of
stuff and the returns), the prestart job ends once the got_alarm procedure
is executed. So are there any sort of 'signals' being thrown by pre-start
jobs. If I call the pre-start job over and over again (via Iseries
Navigator and the 'Run Sql Scripts' option) quickly, the program executes
without the alarm being processed. Once I wait over 10 seconds (my test
value) and the got_alarm executes, the pre-start job ends.

/Free
alarm(wrkwaitsec); // wrkwaitsec is a variable passed into the
program
For x = 1 to 10;
Endfor;

Return;


//______________________________________________________________________________

Begsr *Inzsr;

//______________________________________________________________________________

Init_Signals();

Endsr;

/End-free

*____________________________________________________________________
* Procedure to Initialize/Enable Signals
*____________________________________________________________________
Init_Signals B
*____________________________________________________________________
Init_Signals PI
Act Ds LikeDS(SigAction_T)
/Free

Qp0SEnableSignals();
SigEmptySet(Act.Sa_Mask);
SigAddSet(Act.Sa_Mask: SIGALRM);
Act.Sa_Handler = %Paddr(Got_Alarm);
Act.Sa_Flags = 0;
Act.Sa_SigAction = *Null;
SigAction(SIGALRM :Act :*Omit);

/End-free

P E

*______________________________________________________________________
* Procedure to Handle the Receiveing of an Alarm
*______________________________________________________________________
P Got_Alarm B
*______________________________________________________________________
D Got_Alarm PI

D wrkDspRsp S 1
/Free

Dsply ('They are here.....') ' ' wrkDspRsp;

Alarm(wrkwaitsec);

/End-free

P E