Re: ILE and Access Paths

JMBauman@xxxxxxxxxxxxxxxx wrote:
> 
> ... I am not sure what you mean when you say the
> "UEP Module".  Would it be possible for you to post some code demonstrating
> the use of a cleanup procedure.  Thanks again.
> 

"UEP" stands for "user entry procedure".  The UEP module is the one that
is specified in the ENTMOD parameter of the CRTPGM command; it contains
the procedure that is first called when you call a program.  When you
call an ILE program, the system calls a special procedure called the
"PEP" (Program Entry Procedure).  The PEP is a compiler-generated
procedure whose function is just to call the main procedure of the
module.

Here's a sketch of a module with a cleanup procedure.

 * Module HDLMYFILE
H nomain
Fmyfile   if      e           disk usropn
 /copy prototypes
D p             s         *   inz(*null)
P myproc        b             export
 /free
    if not %open(myfile);
      open myfile;
    endif;
    read myfile;
    if something ---
       eval p = %alloc(10);
    ---
 /end-free
P               e

P hdlMyfile_cleanup...
P               b               export
 /free
   // close files
   close *all;
   // free allocated storage
   if p <> *null;
     dealloc(n) p;
   endif;
 /end-free
P               e

Here's how the main procedure of the program's uep module would look,
along with the cleanup() procedure of the uep module.

 /free
     // enable cancel handler to ensure cleanup() is called
     // doing parameters by memory, maybe not exactly 3
     ceertx (%paddr(cleanup) : *omit : *omit);

     // do the function of the program
     --- whatever ---

     // cleanup 
     cleanup();
     *inlr = '1';
     return;
 /end-free

P cleanup       b
 /free
   // cleanup submodules
   hdlMyfile_cleanup();
   queries_cleanup();
   reports_cleanup();
   whatever ('CLEANUP')  // say you have a submodule with a main
procedure
                         // and 'CLEANUP' is the special parameter
indicating
                         // that it should just SETON LR and RETURN

   // cleanup this module's allocated storage if necessary
   // could also delete any temporary files or any other cleanup
necessary
   if somepointer <> *null;
     dealloc(n) somepointer;
   endif;
 /end-free
P               e

You might do similar processing for modules in service programs linked
to your program, but a service program module might be "serving" more
than just one program, so you might want a service program module to
stay 'active' for your whole job.

But as someone already said in this thread, you can get most of the
cleanup done just by reclaiming the activation group.