Re: Signal API's

Well, I will try to explain the method to my madness. As indicated
earlier, the program in question is being used as a stored procedure. This
RPG is the initial program for (the lack of a better description) a web
service. I have users going through a web site to do many things such as
update membership data, created/adjust orders, retrieve data from the
Iseries to update a subset of tables on the web site. Lot's of different
'requests'. Again, all of these 'requests' come through this same RPG
program. I believe the web site (I was not responsible for the
implementation) is using an ODBC connection to call a stored procedure. I
can see this a the good ole' QZASOINIT job. This stored procedure has
four parms. The first being a 'Request' (type input) , second a 'Return'
code(type output), third a 32k XML string (type input) and the fourth
being another 32k XML return string (type output). My program takes this
'request' parm and via a table lookup decides what program to call. This
derived program is called and it of course calls many other programs.
Then, eventually, the called program builds a return xml and we return
back up through the program stack a returns the two output parms with a
status and some xml. During the course of these calls, many files are
opened and remain open as none of the programs seton LR. Many of the
called programs run in the *Caller activation group, and a named
activation group. Some are even OPM programs (don't yell at me, it is old
code that works). My reason for using the signal API's is to cause the
closing of the open files when necessary. You see, many of the files are
opened for update. These opened files cross many different applications
such as inventory, order entry etc. There comes a time (Monthend is the
usual offender) where we need to issue a backup of the data libraries. It
would be ideal to have exclusive access to these files for the savlib.
Currently I actually use a save while active to get around the lock issue
on these files. For this 'Web' application I have a data area which
contains among others contains a field that indicates if the web
application is 'unavailable'. This is a simple y/n flag. Prior to doing
a backup, the user updates this field with a 'Y' to indicate that access
is not allowed (actually they set a estimate of when it will be backup).
When the application is 'unavailable', the stored procedure RPG checks
this data area and will inform the web site that the application is not
available and indicates when it will be backup. If a user attempts to
access the 'web' application when this flag is 'Y', the RPG (stored proc)
will issue a reclaim activation group command against the named activation
group and a RCLRSC for those programs/files that are not in a named group
or are OPM programs. This accomplishes what I need just fine. However,
if the web users do not make a request for a long time, then the stored
procedure (by the way it always returns) simply sits idle in the
QAZDOSINIT job. I wanted to use the signal api's to just sort of fire
after approximately every 10 or 20 minutes to interrupt this 'idle'
program to examine the 'unavailable' flag. If it finds it to unavailable,
I wanted to issue the reclaims but keep the program active. By the way,
in the stored procedure RPG, one of the first things I do is to issue the
Alarm() procedure (to reset it is how I think of it, my 'Snooze' concept).


Sorry for the looooooong response. I hope you did not have a sudden urge
to reach for a cup of coffee for a wake-me-up. I am not sure if my intent
is clear here Scott. But thanks for spending the time to review my issue.



----------------------------------------------------
Bill Greenfield
CAS Severn, Inc.

message: 1
date: Tue, 11 May 2010 11:42:22 -0500
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: Signal API's

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.