Re: CEE4RAGE - call-back procedure not being called

[Mel Rothman <mel@xxxxxxxxxxxxxx>]

Larry,

I noticed that Scott's example clearly states that the call back procedure must 
be exported so that CEE4RAGE can call it.

Try adding the export keyword to the myCallBackProc subprocedure.

Mel Rothman
Mel Rothman, Inc.

larry_ducie@xxxxxxxxxxx wrote:
> 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