Re: Signal API's

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

I don't understand what this code is supposed to do.  Your comments say 
that alarm() puts the program into a "sleep mode" (which is not true), 
instead, it tells the OS to send an alarm signal in 10 seconds.

Your program then returns control to DB2.  Apparently, the alarm signal 
is being received by the IBM code inside DB2 (which makes perfect sense, 
since your program did a RETURN!) and that IBM code wasn't expecting to 
receive a signal.  So it proceeds to return an error of 'Interrupted 
function call' (which is the normal error message to be used when a 
routine in the OS is interrupted by a signal)

This all seems like correct behavior to me.

I'm not exactly sure what you're trying to do -- but if your goal is to 
have your program automatically run every 10 seconds, then I'd suggest 
keeping the program active rather than returning control to DB2.


On 5/11/2010 11:23 AM, Bill Greenfield wrote:
> I have done some more playing around with my perceived 'Signal' problem. I
> have posted portions of 'Stored Procedure' code below so that any glaring
> errors can be caught by the community.  Also, I am including portions of
> the joblog that I forced.   If you look at the subset of the joblog, you
> will see that a CPE3407 diagnostic message is been sent.  Note on the job
> log the that my code executed a 'Return' in some CL program at
> 11:41:06.xxxx.  Next you will see the CPE3407 diagnostic message being
> issued at 11:41:16 which happens to be the approximate number of seconds
> that the 'Alarm' was set to (10 seconds).   I do not know what all of this
> means but searching the internet for CPE3407 and QZBSCOMM does not provide
> my little brain much useful information.   What I read from this is that
> "You can't do that dude" (interruption a function call).
>
>
>
>
>
> JOBLOG snippet
> *NONE      Command                      05/11/10  11:41:06.236281  QCLRTNE
>       QSYS        0058     PRCMSG      CASPGM      0065
>                                       From user . . . . . . . . . :   BG
>
>                                       Message . . . . :          - RETURN
>    /* RETURN due to end of CL program
>                                         */
> CPE3407    Diagnostic              10   05/11/10  11:41:16.729363 QZBSCOMM
>      QSYS        *STMT    QZBSCOMM    QSYS        *STMT
>                                       From user . . . . . . . . . :   BG
>
>                                       From module . . . . . . . . :
> QZBSCOMM
>                                       From procedure  . . . . . . :
> SndErrnoMsg__FPc
>                                       Statement . . . . . . . . . :   13
>
>                                       To module . . . . . . . . . :
> QZBSCOMM
>                                       To procedure  . . . . . . . :
> SndErrnoMsg__FPc
>                                       Statement . . . . . . . . . :   13
>
>                                       Message . . . . :   Interrupted
> function call.
>
> CODE snippet
>      <code omitted>
>
> // Set the 'Alarm' to be xx minutes from now.
> // This procedure causes the program to go into a 'sleep' mode for the
> amount
> // of seconds identified in the the constant).  Once the 'sleep' time is
> over,
> // the 'Alarm' is signaled.  The Init_Signal procedure called in the
> *INZSR
> // routine sets up this process.  If this program is being constantly
>
> // called, then alarm procedure simply keeps hitting the 'snooze' button.
>
> // The procedure is only effective if no activity (the program is not
> being
> // called) occurs.  Should the 'Alarm' sound, then the special procedure
>
> // (identified in the Init_Signal procedure) will get control.
> Alarm(wncAlarm);               ->  in this test the wncAlarm is a named
> constant with a value of 10
>
> <code omitted>
>
> Return:
>
> <Various subroutines omited>
>
> <The following is the same as my original post.>
>
>
> *______________________________________________________________________________
>
>   * Procedure to Initialize/Enable Signals
>
> *______________________________________________________________________________
>
> P Init_Signals    B
>
> *_______________________________________________________________________________
>
> D Init_Signals    PI
> D 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 Receiving of an Alarm
> *______________________________________________________________________________
>
>   Got_Alarm       B
> *_______________________________________________________________________________
>
>   Got_Alarm       PI
>
> /Free
>
>   // If the application is unavailable and the activation group and
>   // resources have not already been reclaimed, reclaim them now.
> <Please note that values in these variables are not true thus>
>   If wdsWebAppEnv.aeunAvlF = 'Y' and         // Unavailable flag
> (y=unavailable)<  nothing actually executes>
>      wrkReclaimDone = 'N';                                   // Reclaimed
> not already done
>    Reclaim();
>   Endif;
>
> /End-free
>
>
> Bill Greenfield
> CAS Severn, Inc.
>
>
>
>
> > message: 4
> > date: Mon, 10 May 2010 17:00:05 -0500
> > from: Scott Klement<rpg400-l@xxxxxxxxxxxxxxxx>
> > subject: 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