IBM i > DEVELOPER > GENERAL

The Seven Deadly Sins of ILE


Over the last few years, weve taught and consulted with many shops on topics relating to the Integrated Language Environment (ILE). During this time, weve seen many practices that work well, some that dont work so well, and a few that are outright lethal. Weve concluded that seven ILE practices are either best avoided or should be severely restricted. These "seven deadly sins" are the subject of this article. Well touch on each of them here, although many require a full article in their own right to do them justice. If reader interest warrants, well detail specific "sins" in future issues of iSeries EXTRA.

 

First deadly sin: Allowing "real" ILE programs to run in the default activation group.
What do we mean by "real" ILE programs? These are programs that are created either via the CRTxxxMOD and CRTPGM commands or by specifying DFTACTGRP(*NO) to one of the CRTBNDxxx commands (where xxx is RPG or CL). Note that for the purposes of this discussion, programs created with the CRTBNDxxx default of DFTACTGRP(*YES) arent considered to be ILE programs; theyre instead original program model (OPM)-compatible programs, and therefore arent bound by any of our ILE rules.

The default activation group (sometimes called DAG) is designed specifically for OPM programs and is the only activation group where these programs can run. You cannot directly request that your ILE programs run in the DAG, but if you specify *CALLER for the activation group parameter and subsequently call the program from an OPM program, your ILE program will run in the DAG. This is contrary to ILEs design (IBMs original intent was that ILE programs not be permitted to run in the DAG at all) and will eventually cause problems of some sort.

Second deadly sin: Using service programs in the DAG.
Many shops commit the first deadly sin and run their ILE programs in the DAG. If you happen to work in one of these shops, you can avoid some of the most serious problems by running your service programs in their own named activation group(s). Service programs are more prone to problems when running in the DAG, particularly if the Reclaim Resource (RCLRSC) command is run while the service program is active with files open. While RCLRSC is often used specifically to close open files, the command doesnt notify the service program logic that the files are closed. This leaves the application in a Catch 22 situation: The files are closed, but the procedures in the service program believe theyre still open.

Third deadly sin: Using *NEW by default rather than by design.
The *NEW option creates a brand new activation group every time the program is called. If specified for a large number of programs, this option can dramatically slow your application. So why would anyone ever use such a value as standard? Its pretty simple: Prior to V5R3, *NEW was the IBM default on the CRTPGM command. Because of this, many developers use it by accident. While *NEW might be an appropriate choice in some cases, they are few and far between. For this reason, a good approach might be to change the default value for activation group on CRTPGM.

In V5R3, the shipped default value for the Activation Group parameter on the CRTPGM command changed from *NEW to *ENTMOD (Entry Module). This means that the system looks at the language of the module used as the program entry procedure to determine the appropriate activation group value. If the entry module language is RPG, COBOL or CL, then the name "QILE" is used for the activation group. If the entry module is C, then the previous default value of *NEW is used. This is a great improvement and will hopefully reduce the number of accidental uses of the *NEW value. Its also more consistent because the default value on the CRTBNDRPG, CRTBNDCBL and CRTBNDCL commands has always been QILE. (Note: If you create a program that uses the teraspace storage model-which would be rare for RPG or COBOL programs-the default activation group name would be QILETS instead of QILE.)

 

Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.


comments powered by Disqus

Advertisement

Advertisement

2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Are You Multilingual?

Rational enables development in multiplatform environments

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters