Items related to ILE by Example
Synopsis
This new book takes a fresh approach to Integrated Language Environment (ILE). Learn the fundamentals of the AS/400 s ILE by following working examples that illustrate the ins and outs of this powerful programming model. NEWS/400 Technical Editor Mike Cravitz demystifies such ILE concepts as service programs, subprocedures, activation groups, and more. CD included.
"synopsis" may belong to another edition of this title.
About the Author
Mike Cravitz is a NEWS/400 technical editor with more than 30 years of application development experience. A consultant, instructor, and highly regarded author on ILE, RPG, Cobol, and SQL topics, Mike was formerly a systems engineer with IBM marketing in support of the IBM midrange. He received a B.A. in mathematics from California State University at Northridge and an M.A. in mathematics from California State University at Los Angeles. Mike is also co-author (with Paul Conte) of the textbook SQL/400 Developer s Guide (29th Street Press, 2000).
From the Inside Flap
Here is everything you need to know to get a grip on the AS/400’s Integrated Language Environment (ILE). Learn by following working examples that illustrate the ins and outs of this powerful programming model. Major topics include:
ILE program structure, which is quite different from the OPM program structure
Bind by copy, and when this mechanism can be useful in your system design
ILE RPG subprocedures
Service programs and service program signatures
Activation groups
ILE exception handling
How to write your own ILE condition handler
How to use ILE cancel handlers to avoid problems when your programs are canceled
ILE by Example presents more than mere theory. It includes plenty of working examples to illustrate the fundamental aspects of ILE. The CD that accompanies this book contains all but the most trivial of the sample programs. Each source on the CD has explicit instructions regarding its use and any other sources that must be used in conjunction with it.
Excerpt. © Reprinted by permission. All rights reserved.
Chapter 1 ILE Program Structure
One of the keys to the AS/400 s survival has been the remarkable evolution of its program models -- the set of interfaces and underlying processes that the machine interface (MI) and OS/400 provide to create and call programs and procedures. ILE is the latest program model to provide increased sophistication and flexibility to AS/400 programmers.
OPM, EPM, and ILE
When IBM introduced the AS/400 in 1988, it shipped the system with the Original Program Model (OPM), in which programs are always invoked dynamically. That is, when an OPM program invokes (usually via a Call statement) another program, the invoked program is located and loaded into memory at run time. Each program is a separate, independent object.
To facilitate the use of block-structured programming languages such as C and Pascal, IBM unofficially introduced the Extended Program Model (EPM) on the S/38 and made it official on the AS/400 with OS/400 V1R2. Several characteristics distinguish block-structured languages from traditional AS/400 languages such as RPG and Cobol, including:
the ability to define multiple blocks of code (sometimes referred to as functions or procedures) within a single source member with local variables (i.e., variables available only within the block) and the ability to receive parameters; the ability to have local variables as well as variables that are available throughout a program or even across programs (i.e., flexible data scoping); multiple entry points within a single source member.
IBM wanted to find a way to let traditional AS/400 languages such as RPG and Cobol also reap some of these benefits. But because IBM designed EPM as an extension to OPM, the EPM environment couldn t accomplish this task efficiently. So IBM developed an entirely separate model called the Integrated Language Environment (ILE) and introduced it in V3R1. Because ILE encompasses the functionality of EPM (and more) in a more efficient way, EPM is no longer considered a useful model for the AS/400.
Programs, Modules, and Procedures
One of the first things to learn about ILE is the composition of its program objects. Unlike the familiar OPM environment, in which a program is pretty much a single unit, ILE program objects are composed of modules written in any combination of participating languages -- ILE RPG, ILE Cobol, ILE C, and ILE CL.
Figure 1.1 shows the relative complexity of an ILE program.
As you see, an ILE program consists of one or more modules; these modules, in turn, consist of procedures. The first module in an ILE program always consists of at least two procedures. One of them -- the Program Entry Procedure (PEP) -- is generated by the system and is always the first procedure to receive control in an ILE program. The first user-written procedure to receive control is called the User Entry Procedure (UEP). We ll see how the PEP and the UEP work in a moment.
Before V3R2 and V3R6, ILE RPG modules could contain only one user-written procedure. Now, however, we can create both a main procedure and subprocedures in an ILE RPG module.
To make these concepts a little more concrete, consider Figure 1.2.
The figure shows two ILE RPG source members: Mod1 and Mod2. (Think of a module as an object that corresponds to a single compilable source member.) Mod1 calls the main procedure of module Mod2 using RPG s CallB (Call Bound) opcode. To create a program from these two members, you must compile both source members into *Module objects using the CrtRpgMod (Create RPG Module) command. (CrtRpgMod is implemented as option 15 in Programming Development Manager, or PDM.) Then, you create an executable program using the CrtPgm (Create Program) command, specifying Module(Mod1 Mod2).
Note that the ILE RPG compiler (invoked via the CrtRpgMod command) doesn t produce a program object, as OPM compilers do. Instead, the ILE RPG compiler, as well as all other ILE compilers, produces modules -- AS/400 objects of type *Module. A module is not executable. To create an executable object, you must combine one or more modules into an object of type *Pgm using the CrtPgm command.
The CrtPgm command lets you specify the modules that make up an ILE program. One of CrtPgm s keywords, EntMod (Program Entry Procedure module), indicates which module is the first module to receive control when the program is invoked. By default, whichever module you specify first in the Module parameter is the entry point module. In Figure 1.2, Mod1 is the entry point module.
By the way, if your program contains only a single user-written module, you can use the CrtBndRpg (Create Bound RPG Program) command (option 14 in PDM) to perform module creation (CrtRpgMod) and program creation (CrtPgm) in a single step. The CrtBndRpg command automatically deletes the *Module object because in a single-module program, the module object isn t needed. These single-module programs are often referred to as standalone programs.
Upon execution of an ILE program, the first procedure to receive control is the PEP, as Figure 1.1 shows. The PEP doesn t correspond to any programming that the application programmer has coded; it s simply a system-generated procedure that receives control first. The PEP passes control to the UEP. In Figure 1.2, the UEP is the main procedure of Mod1. The main procedure is the initial part of an RPG module that we, the application developers, have written. Mod1 issues a CallB to Mod2. When you issue a CallB, control is transferred to the called procedure.
"About this title" may belong to another edition of this title.
Search results for ILE by Example
Stock Image
ILE by Example
Seller: ThriftBooks-Atlanta, AUSTELL, GA, U.S.A.
Seller rating 5 out of 5 stars
Paperback. Condition: Good. No Jacket. Pages can have notes/highlighting. Spine may show signs of wear. ~ ThriftBooks: Read More, Spend Less. Seller Inventory # G1583040323I3N00