× 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.



List,

 

I have a problem with a registered call-back procedure not being called when
a named activation group is ended.

 

 

OK, some background:

 

I have a program that runs in a named activation group. When this program is
called it registers a procedure as the call-back procedure using CEE4RAGE.

 

The prototype for the call is as per a recent thread by Scott Klement
(except I have Extproc defined, rather than naming the proc - does that make
a difference?):

 

D myProcName      PR                  Extproc('CEE4RAGE')  
D   procedure                     *   procptr const
D   feedback                    12A   options(*omit)

 

The call is via a callp, passing both parameters (we're not allowed to use
/free):

D                                 Callp
myProcName(%paddr(myCallBackProc):fc)

 

This registration seems to work fine. The feedback data-structure is
populated as follows:

 

D fc         DS
D  sev            5U 0 (value = 0)
D  msgno          5U 0 (value = 0)
D  flags          1    
D  facid          3    (value = 'CEE')
D  isi           10U 0 (value = 0)

 

The procedure interface for my call-back procedure is as follows:

 

D myCallBackProc  PI
D   Ag_Mark                     10U 0 options(*nopass)
D   Reason                      10U 0 options(*nopass)
D   Result                      10U 0 options(*nopass)
D   UserRC                      10U 0 options(*nopass)

 

I even passed the feedback condition token to the CEEDCOD API to decompose
it and it seemed to work fine there too.

 

Background: This program calls other programs (all in the same named
activation group) to extract stream files from zip files in the IFS. The
stream files are then opened and read. The data is extracted into temporary
database tables (all in QTEMP). The QTEMP tables are keyed so I can read the
extracted data, in key sequence, and process (copy data to live tables and
delete from QTEMP tables). All zip file extractions, CCSID conversions, and
stream file manipulations are performed using QSHELL.

 

This job runs all day. As there is a possibility that we are left with
orphaned data in the QTEMP tables (order without lines or carton without
details, etc.), the idea is to copy any data left in the QTEMP tables to log
files. This will allow us to investigate. This program also calls the
system() API, so I have specified QC2LE as the binding directory. The
program remains in the call stack throughout the lifetime of the job, it has
a single (MAIN) module and the call-back proc is in this module. (just for
completeness, this program is called from a CLLE that is run in the default
activation group). 

 

Now, rather than simply issue a set of CPYF commands at the foot of the
program, I decided to use an Activation Group Exit Procedure as this should
ensure I get the QTEMP data even if the job ends abnormally. 

 

Right, that's what I HAVE done. What I HAVEN'T done is actually caused my
call-back proc to get called.

 

I don't explicitly end the named activation group, I simply end the job
normally - this doesn't call the proc. If I end the job *IMMED - this
doesn't call the proc either.

 

My assumption is that the call-back proc would get called whatever the
reason for the activation group ending. Can anybody see what I'm doing
wrong? Does my call-back proc have to be in a service program? Does it have
to be in a module other than the main module? 

 

Your thoughts on this would be appreciated.

 

Larry       


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.