Re: Signal API's

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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