× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.