Warning: Declaration of TCB_Menu_Walker::walk($elements, $max_depth) should be compatible with Walker::walk($elements, $max_depth, ...$args) in /home/nicklit/www/www/wp-content/plugins/thrive-visual-editor/inc/classes/class-tcb-menu-walker.php on line 620

Warning: session_start(): Cannot start session when headers already sent in /home/nicklit/www/www/wp-content/plugins/userpro/includes/class-userpro.php on line 222
RPG ON-EXIT is housekeeping for sub-procedures - Nick Litten is IBM-i, AS400 iSeries RPG Programmer and Nerd

RPG ON-EXIT is housekeeping for sub-procedures

Programming

May 15

IBM is adding all kinds of new tweaks to RPG with each new release of IBM i. RPG ON-EXIT is a great example of a neat tweak to the RPG programming language.

Last year, IBM quietly introduced a rather neat new function called “ON-EXIT” to our sub procedures in RPG.

RPG ON-EXIT is a nice structured way of storing procedure house keeping and/or error catching.

ON-EXIT is available if you are running IBM i V7.2 or higher:

The ILE RPG compiler is enhanced with a new ON-EXIT opcode which begins the “ON-EXIT” section containing code to be run whenever a procedure ends, either normally or abnormally.

So, if you have code that you always want to run at the end of a procedure you can just put that in the ON-EXIT section.

So how does ON-EXIT work?

The ON-EXIT operation code begins the ON-EXIT section. The ON-EXIT section contains code that runs every time that the procedure ends, whether it ends normally or abnormally. The ON-EXIT section runs under the following conditions:

  • The procedure reaches the end of the main part of the procedure.
  • The procedure reaches a RETURN operation.
  • The procedure ends with an unhandled exception.
  • The procedure is canceled, due to the end of the job or subsystem, or due to an exception message being sent to a procedure higher in the call stack.

By placing your clean-up code, such as deleting temporary files and deallocating heap storage, in the ON-EXIT section, you ensure that it is always run, even if your procedure ends with an unhandled exception, or if it is canceled.

Extended Factor 2 contains an optional indicator variable that indicates whether the procedure ended normally or abnormally. If the procedure returned normally, the indicator is set to *OFF. If the procedure ended with an unhandled exception or if the procedure was canceled for any other reason, the indicator is set to *ON.

The ON-EXIT section is coded at the end of the subprocedure, following any subroutines.

All variables and files defined in the procedure are available in the ON-EXIT section.

I can already think about using ON-EXIT something like this:

RPG ON-EXITdcl-proc myproc;
 dcl-s OhBuggerIcrashed ind inz(*off);
 dcl-s myprocFinished ind inz(*off);
 Open fileName;
 doStuff = things * widgets / shoeshize;
 filename = crtTempFile();
 ... // do lots of subprocedure logic stuff
 myprocFinished = *on;

 return; 
on-exit OhBuggerIcrashed;

 // "OhBuggerIcrashed" is set *ON if the on-exit is invoked abnormally
 // (so it acts sort of like a *PSSR capture)
 if OhBuggerIcrashed;
   reportProblem ();
 endif;

 // then we could have some logic added around the "myProcFinished" indicator
 if myprocFinished;
   dltTempFile (filename);
 endif;

 // any housekeeping that we want to do if we finished cleanly or not
 Close fileName; 

end-proc;

This is discussed in more detail over at the IBM Developerworks.

Follow

About the Author

IBM i Software Developer, Digital Dad, AS400 Anarchist, RPG Modernizer, Alpha Nerd and Passionate Eater of Cheese and Biscuits. Nick Litten Dot Com is a mixture of blog posts that can be sometimes serious, frequently playful and probably down-right pointless all in the space of a day. Enjoy your stay, feel free to comment and in the words of the most interesting man in the world: Stay thirsty my friend.