Re: Signal API's

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