Day-29.

Introduction To RPGILE

 Overview:

This module enables the student to understand the concept of RPGILE.

Outline:

Topics covered,

a.     Introduction to RPGILE

b.     Concept of Procedure and Sub Procedure

Objective:

By the end of this module, the student should be able to:

a. Understanding Of Basic Concepts RPGILE

b. Understanding Procedure and Sub Procedure

What is ILE?

IBM introduced the Integrated Language Environment (ILE) in 1993. It is an architectural enhancement to the AS/400 system to increase the programmer’s productivity and improve application performance. ILE is a programming model that allows program modules to be first compiled and then bound together into executable programs. Modules can be written in different languages and then bound into a single program. IBM enhanced the existing RPG III language syntax. The new RPG language dialect is dubbed as RPG IV.

ILE RPG/400 is a compiler and RPG IV is language syntax.

RPG IV supports:

• The date, time and time-stamp data types
• Expanded field, table, array and file-name lengths
• Free-format expression in numerous calculation operations
• With V4R2, you can write indicator less programs.

 The RPG III supported only dynamic program calls (a called program is activated at runtime) to other programs. Dynamics calls area simple but not performance efficient. More time is required to execute the application as number of programs and calls to those programs increase.

With ILE, this major obstruction to modularization is eliminated through the support of bound calls (or static calls). Bound calls are much faster than dynamic calls because the call to the external module is resolved at compile time instead of at runtime (as with dynamic call). With bound calls, it is now possible to break down programs and applications into smaller components with acceptable performance levels. One of the most important benefits of ILE is reduction in the overhead associated with calling programs. Thus ILE supports and encourages modularization.

 ▪          ILE Benefits

• As the name implies, ILE provides an Integrated or Common interface to programming language. ILE Programs can call programs written in different language (like RPG, C and COBOL).

• An important benefit of new ILE program is capability to bind programs. To bind program means to compile programs separately as non-executable modules and combine them to form a single, executable program object. Binding modules is a static process that is normally part of compile process. Binding facilitates modularity and makes it possible to create reusable components without performance penalty of external program calls.

• In case of ILE RPG, programs are compiled separately as a non-executable object called as module (*MODULE) and then combined into an executable object (*PGM).

• ILE supports following features like:

o      Free-format expressions, especially for calculation operations.

o      The date, time and time-stamp data type

o      Various built-in functions, which improves the performance.

o      Expanded field lengths, opcodes.

o      Source-level debugger.

o      Procedure & Sub-procedures.

o      Use of External variable to share information between different programs.

Binding:

It helps reduce the overhead associated with calling programs. Binding the modules together speeds up the call, mechanism which is called dynamic or external call.

The binding capability makes it far more practical to develop applications in a highly modular fashion. An ILE compiler produces a module (*MODULE) object that can be combined (bound). With other modules to forma single runnable unit; that is, a program object (*PGM). It is possible to create a single runnable program that consists of modules written separately in RPG, COBOL, C or CL.

Modularity

Modular approach in application programming has following benefits:

o      Faster compile time: Smaller he piece of code we compile, the faster the compiler can process it. This helps in maintenance. Mostly only a ;line or two needs to be changed and we compile 2000 lines of code after the change. That is not an efficient use of resources. If we modularize the code and take advantage of the binding capabilities of ILE, we may need to recompile only 100 or 200 lines. Even with binding step included step included, this process is considerably faster.

o      Simplified Maintenance: In a large program, it is very difficult to understand exactly what is going on. Every programmer has different style of writing programs. A smaller piece of code generally has a single function and it is easy to understand. When you make changes, it is les likely that you will introduce unwanted code.

o      Simplified Testing: Smaller compilation units can be tested independently. This helps to insure that test is complete i.e. all logical inputs and process are tested.

o      Better use of programming resources: When it is a large program it is difficult to subdivide the work. But small modules can be assigned to different programmers.

o      Easier migrating of code from other platforms: Programs written on other platforms if modular, they can be migrated to the AS/400 system and incorporated into an ILE program.

·         Reusable Components

  ILE allows binding selected routines into your own programs. All ILE compiler users can use routines written in any ILE language. You have widest possible choice of routines as programmers can write in the language of their choice. One can use off-the-shelf routines in the application as well as develop routines in any ILE language.

• Common Run-Time Services

A selection of off-the-shelf components or routines (bindable APIs) is supplied as a part of ILE ready to be incorporated in any application. These APIs provide services such as :

o      Date and time manipulation

o      Message handling

                  o      Math routines

                  o      Greater control screen handling

                  o      Dynamic storage allocation

·         Co-existence with Existing Applications

ILE programs can co-exist with existing OPM programs. ILE programs can call OPM programs and other ILE programs. Similarly, OPM programs can call ILE programs and other OPM programs. This helps in gradual transition to ILE.

·         Source Debugger

The source debugger allows you to debug ILE programs and service programs.

• Better Control over Resources

Before the ILE, resources (e. g, open files) used by a program could be opened to or owned by only:

         -The program that allocated the program could be scoped to or

         -The job.

• Better Code Optimization

The ILE translator does many more types of optimization than the original program model (OPM) translator does most of the optimization, but the translator does most of the optimization of the AS/400.

An ILE enabled compiler does not directly produce a module. First it produces an intermediate code into instructions that can be run.

• Foundation for the Future

Future ILE compilers will offer significant enhancements. ILE environment is a step closer to OOP languages and visual programming tools. Increasingly, programming methods rely on a highly modularized approach. Applications are built by combining thousands of small reusable components to form the completed application.

Ø  Program Models

ILE is a stage in the evolution of OS/400 program models. Each stage evolved to meet the changing needs of application programmers.

The programming environment provided when the AS/400 system was first introduced is called the Original Program Model (OPM). In OS/400 Version 1 release 2, the Extended Program Model (EPM) was introduced.

• Original Program Model Description

Application developers on the AS/400 system enter the source code into source file and compile that source. If compilation is a success, a program object is created. The set of functions, processes and rules provided by the OS/400 to create and run a program is known as the Original Program Model (OPM).

As an OPM compiler generates the program object, it generates additional code. This code initializes program variables and does special processing such as processing of any additional compiler generated code becomes the starting point (entry point) for the program.

A program is typically activated when the OS/400 encounters a call request. At run time, the call to another program is a dynamic program call. The resources needed for this are significant. An application is often designed to consist of a few large programs to minimize the number of dynamic program calls.

The following figure illustrates the relationship between OPM and the operating system RPG, COBOL, CL, BASIC and PL/1 all operates in this model. The broken line forming the OPM boundary indicates that OPM is an integral part of OS/400. It means that many functions normally provided by the compiler writer are built into the operating system.

The resulting standardization of calling conventions allows programs written in one language to freely call those written in other languages.

Principal Characteristics of OPM

o      Good for traditional RPG and COBOL programs: OPM is ideal for supporting traditional RPG and COBOL programs, i.e. relatively large, multifunction programs.

o      Dynamic Binding: When program A wants to call program B, it just does so. This dynamic program call is a simple and powerful capability. At run time, the operating system locates program B and ensures that user has the authority to use it. It also checks to see of program is activated. If it is, that activation is used when the program is given control so that the static storage variables retain their previous values. But sometimes you may want a new copy of program’s static variables that are reset to their initial states.

o      Limited data sharing: OPM provides limited support for data sharing. Typically, to share data between programs in an application, you pass the data as parameters on a CALL statement. This is an effective method except in those cases where the data is not processed by the next program in sequence. Under OPM, system support for other types of data sharing was limited. So the RPG and COBOL compiler writers decided not to include such support. As a result, OPM programmers have to use alternative techniques such as storing data in a local data area (LDA), in a database or in a user space.

• Extended Program Model Description

OPM does not provide direct support for procedures as defined in languages like C,A procedure is a set of self-contained high-level language (HLL) statements that performs a particular task and then returns to the caller. OPM was enhanced to allow languages that define procedure calls between compilation units or that define procedures with local variables to run on the AS/400.

These enhancements are called the Extented Program Model (EPM). As shown in following figure EPM was created to support languages like Pascal. Along with base OPM support, EPM provides the ability to call procedures located in other programs. Conceptually, the entry point of the called EPM program provides the following functions: Initialize the program variables and Call the identified procedure. The system support to help resolve the procedure calls to the appropriate programs is provided by the Set Program Information (SETPGMINF) command.

EPM is closely tied to OPM. EPM is built as an additional layer above the AS/400 high-level machine interface. Unlike OPM, EPM is not incorporated into OS/400. Rather, it is a layer on top of the operating system. It provides the additional support required for procedure-based languages.

• Principal Characteristics of Procedure – Based Languages

        Procedure- based languages have characteristics:

o      Locally Scoped Variables: Locally scoped variables are known only within the procedure that defines them. The equivalent of locally scoped variables is the ability to define two variables with the same name that refer to two separate pieces of data. E.g. the variable COUNT might have a length of 4 digits in subroutine CALCYR and a length of 6 digits in subroutine CALCDAY. Locally scoped variables provide considerable benefit when you write subroutines, which are copied into several different programs.

o      Automatic Variables: Automatic variables are created whenever a procedure is entered. Automatic variables are destroyed when procedure is exited.

o      External Variables: External data is one way of sharing data between programs. If program A declare a data item as external, program is said to export that data item to other programs that want to share the data .Program D can then import the data item without programs Band C being involved at all.

o      Multiple Entry Points: COBOL and RPG programs have only a single entry point. In a COBOL program it is the start of the PROCEDURE DIVISION. In an RPG program, it is the first–page (IP) output. This is the model that OPM supports. Procedure-based languages, on the other hand may have multiple entry points. E.g. a C program may consist entirely of subroutines to be used by other programs. These procedures can be exported, along with relevant data if required, for other programs to import. In ILE, programs of this type are known as service programs. They can include modules from any ILE languages. Service programs are similar in concept to dynamic link libraries (DLLs) in Windows operating system.

o      Frequent Calls: Procedure-based languages are by nature very call sensitive and procedure calls between separately compiled units still have a relatively high overhead. ILE improves this type of call significantly

• Integrated Language Environment Description:

As shown in the following figure, ILE is tightly into OS/400, just as OPM is. It provides the same type of support for procedure-based languages that EPM does, but it does so far thoroughly and consistently. Its design provides for the more traditional languages, such as RPG and COBOL, future language development.

Following table compares the OPM and Integrated Language environment (ILE).

OPM	ILE
Program	Program Service Program
Compilation results in runnable program	Compilation results in a non-runnable module object
Compile and run	Compile, bind and run
Run in default activation group	Can run in specific activation group
Dynamic program call	Dynamic program call Static program call
Single-language focus	Mixed-language focus
Language-specific error handling	Language-specific error handling Common error handling
OPM debuggers	OPM debuggers Source-level debuggers

• Structure of an ILE Program

An ILE program contains one or more modules. A module, in turn, contains one or more procedures.

• Summary

o      Original Program Model (OPM)

▪          Programmers enter source code into a source file and compile that source. If the compilation is successful, a program object is created. The set of functions provided by OS/400 to create and run a program is known as OPM.

▪          A program is typically activated when the OS/400 encounters a call request. At run time., the call to another program is a dynamic program call.

o      Extended Program Model (EPM)

▪          OPM does not provide direct support for procedures as defined in languages like C. A procedure is a set of self-contained HLL statements that perform a particular task and then returns to the caller.

▪          The enhancements on OPM to allow languages that define calls between compilation units or that define procedures with local variables to run are called EPM.

o      Integrated Language Environment (ILE)

§  ILE provides better support for procedure-based languages than EPM does.

§  Its design provides for future language developments.

  

Ø  Module object

A module object is a non-runnable object that is created when an ILE program is compiled. The type of the object is *MODULE. It is a basic building block for creating runnable ILE objects.

A module object can consist of one or more procedures and data item specifications. It is possible to directly access the procedures or data items in one module from another ILE object.

ILE RPG/400, ILE COBOL/400 and ILE C/400 all have the following common concepts:

o    Exports: An export is the name of a procedure or a data item, coded in a module object, which is available for use by other ILE objects. The export is identified by its name and its associated type, either procedure or data. An export can also be called a definition.

o    Imports: An import is the use of or reference to the name of a procedure or data item not defined in the current module object. The import is identified by its name and its associated type, either procedure or data. An import can also be called a reference.

A module object is basic building block of an ILE runnable object. So when a module object is created, the following may also be generated:

o      Debug Data: Debug data is the data necessary for debugging a running ILE object. This data is optional.

o      Program Entry Procedure (PEP): A program entry procedure is the compiler-generated code that is the entry point for an ILE program on a dynamic program call. It is similar to the code provided for the entry point in an OPM program.

o      User Entry Procedure (UEP): A user entry procedures, written by a programmer, is the target of the dynamic program call. It is the procedure that gets control from the PEP.

The main () function of a C program becomes the UEP of that program in ILE.

Following figure shows conceptual view of a module object. In this example, module object M1 exports two procedures (Draw_Line and Draw_Arc) and a data item (rtn_code). Module object M1 imports a procedure called Draw_Plot. This module object has a PEP, a corresponding UEP (the procedure Draw_Arc) and debug data.

• Conceptual view of a Module

Note that PEP may be defined. An UEP is defined when PEP is defined.

Characteristics of a *Module object:

o      A *MODULE object is the output from an ILE compiler.

o      It is the basic building block for ILE runnable object.

o      It is not a runnable object.

o      It may have a Program Entry Procedure (PEP) defined. A PEP is the compiler-generated code that is the entry point for an ILE program on a dynamic program call.

o      If PEP is defined, a User Entry Point (UEP) is also defined to indicate the procedure that is also called a reference and is identified by its name and its associated type, either procedure or data.

o      It can optionally have debug data is defined, which is necessary for debugging a running ILE object.

·         CL Commands used with Modules

Commands	Description
CHGMCD	Change Module Changes the attributes of a module object without requiring the module to be recompiled
CRTCLMOD	Create CL Module Creates a control language (CL) module from the specified CL source member.
CRTRPGMOD	Create RPG Module Compiles the RPG source code to create a module object (*MODULE).
DLTMOD	Delete Module Deletes a compiled module or group of modules.
DSPMOD	Display Module Displays information about a module.
WRKMOD	Work with Module Allows you to display and work with a list of modules from one or more libraries

·         Characteristics of an ILE *PGM object:

o      One or more modules, from any ILE language are copied to make the *PGM object.

o      When the CRTPGM command is specified, the ENTMOD parameter allows the programmer to select which module’s PEP is the entry point for the program.

o      On a dynamic program call, the module’s PEP that was selected as the PEP for the program gets control to run.

o      The UEP associated with the selected PEP is the entry point for the program.

o      Procedures and data item names cannot be exported from the program.

o      Procedures or data item names can be imported from modules and service program but not from program objects.

o      Module can have debug data.

o      A program is a run able object.

·         Command to Create an ILE Program shown in the following figure:

CRTPGM PGM(PGMEXAMP) MODULE (M1 M2 M3 M4) ENTMOD(M3)

BNDSRVPGM (PLIB/PRINTS MATHLIB/MATHFUNC)

Ø  Service Program

A service program is a collection of runnable procedures and available data items easily and directly accessible by other ILE programs or service programs. In many respects, a service program is similar to a subroutine library. Service programs are so called because they provide common services that other ILE objects may need.

The public interface of a service program consists of the names of the exported procedures and data items accessible by other ILE objects. Only those items that are exported from the module objects making up a service program are eligible to be exported from a service program.

The programmer can specify which procedures or data items can be known to other ILE objects. So, a service program can have hidden or private procedures and data that are not available to any other ILE object.

It is possible to update a service program without having to re-create the other. ILE programs or service programs that use the updated service program. The developer making the changes to the service program controls whether the change is compatible with the existing support.

ILE provides this support through binder languages. It allows the developer to define the list of procedure names and data item names that can be exported. A signature is generated from the names of procedures and data items and from the order in which they are specified in binder language. In order to make compatible changes to a server program, new procedure or data item names should be added to the end of the export list.

Although the modules is a service program may have PEPs, these PEPs are ignored. The service program itself does not have PEP. Therefore, a service program cannot be called dynamically.

o      One or more modules can be copied to make he *SRVPGM object.

o      It is similar to a subroutine library or procedure library.

o      No PEP is associated with the service program. Therefore, a dynamic call to a service program is not possible. A module’s PEP is ignored.

o      Other ILE programs or service programs can use the exports of this service programs identified by the public interface.

o      Other ILE programs or service programs can use the exports of this service programs identified by the public interface.

o      Signatures are generated from the procedure and data item names that are exported from the service programs.

o      Service programs can be replaced without affecting the ILE programs or service programs that use them as long as previous signatures are still supported.

o      Modules can have debug data

o      A service program is a collection of runnable procedures and data items.

·         CL Commands used with Service Programs

Command	Description
CHGSRVPGM	Change Service Program Changes the attributes of a program without requiring that it be recompiled.
CRTSRVPGM	Create Service Program Creates a bound service program or group of service programs from a set of modules and binding directories.
DLTSRVPGM	Delete Service Program Deletes a bound service program or group of service programs from a set of modules and binding directories.
DSPSRVPGM	Display Service Program Displays information about a service program
UPDSRVPGM	Update service program Replaces modules of an Integrated Language Environment (ILE) bound service program with other modules on the system, without requiring you to change or recompile the bound service program.
WRKSRVPGM	Work with Service Program Allows you to display and work with a list of service programs from one or more libraries.

·         Command to Create ILE Service Program

       CRTSRVPGM SRVPGM (SPGMEXAMP)

MODULE(M1 M2 M3 M4)

BNDSRVPGM (PLIB/PRINTS MATHLIB/MATHFUNC)

EXPORT(*SRCFILE)

SRCFILE(SRVLIB/QSR VSRC)

SRVLIB/QSRVSRC SPGMEXAMP-

STRPGMEXP PGML VL (*CURRENT)

LVLCHK(*YES) SIGNATURE(SIGxx)

EXPORT SYMBOL (P1)

EXPORT SYMBOL (P4)

EXPORT SYMBOL (D)

ENDPGMEXP

STRPGMEXP PGML VL (*PRV)

SIGNATURE (SIGyy)

EXPORT SYMBOL (P3)

ENDPGMEXP

Ø  Binding

Binding helps in reducing the overhead associated with calling programs. Binding the modules together speeds up the call, which is referred to as static or bound call. This is a faster alternative to previous call mechanism, which is called dynamic or external call.

The binding capability makes it far more practical to develop application in a highly modular fashion. An ILE compiler produces a module (*MODULE) object that can be combined (bound) with other modules to form a single runnable unit; that is, a program object (*PGM). It is possible to create a single runnable program that consists of modules written separately in RPG. COBOL, C or CL.

·         Bind by Copy

The modules specified on the MODULE parameter area always bound by copy. Modules named in a binding directory specified by the BNDDIR parameter are bound by copy if:

o      The module provides an export for an unresolved import

o      The module provides an export named in the current export block of the binder language source file being used to create a service program.

If an export found in the binder language comes from a module object, that module is always bound by copy.

E.g.

Module M1: imports P2

Module M2: exports P2

Module M3: exports P3

Binder language S1:

STRPGMEXP PGML VL (*CURRENT)

EXPORT P3

ENDPGMEXP

Binding directory BNDDIR1:

M2

M3

CRTSRVPGM SRVPGM(MYLIB/SRV1) MODULE(MYLIB/M1)

SRCFILE(MYLIB/S1)

SRCMBR(S1)BNDDIR(MYLIB/BNDDIR)

Service program SRVI will have three modules: M1, M2,and M3. M3 will be copied because P3 is in the current export block.

·         Bind by Reference

Service programs specified on the BNDSRVPGM parameter are bound by reference. If a service program named in a binding directory provides an export for an unresolved import, that service program is bound by reference. A service program bound in the way does not add new imports.

·         Dynamic Binding

When program A wants to call program B, it just does so. This dynamic program call is a simple and powerful capability. At run time, the operating system locates program B and ensures that user has the authority to use it. It also checks to see if program is activated. If it is, that activation is used when the program is given control. Calling external programs is called dynamic binding.

 ·         Static Binding

Here the source program is compatible to create modules. The modules are bound together to create program object. Calling a procedure in another ILE program or ILE service program is called static call.

·         Binding Directory

Binding directory contains the names of modules and service programs that may be needed when creating an ILE program or service program.

Modules and/or service programs listed in the binding directory are used only when they provide an export that can satisfy any currently unresolved import request. It is a system object of the type *BNDDIR. Binding directories are optional. The binding directories are used for convenience and program size.

The binding directories offer a convenient method of packing the modules or service programs that may be needed when creating an ILE program or a service program. E.g. one binding directory may contain all the modules and service programs that provide math functions. If anybody wants to use some of those functions, he has to specify only one binding directory and not each module or service program used.

Binding directories can reduce program size because those modules and/or service programs are not specified that do not get used.

The name of a module or service program can be added to a binding directory even if its objects does not exist yet.

·         Following figure shows a conceptual view of a binding directory:

Binding Directory (BID)

Object Name                 Object Type                   Object Library

QALLOC                       *SRVPGM                      *LIBL

QMATH                        *SRVPGM                      QSYS

QFREE                          *MODULE                      *LIBL

-                                               -                                   -

-                                               -                                   -

-                                               -                                   -

·         Characteristics of a *BNDDIR object:

o      Convenient method of grouping the names of service programs and/or modules that may be needed to create an ILE program or service program.

o      Binding directory entries are just names. So the objects listed do not have to exist yet on the sytem.

o      Valid library names are*LIBL and specific library only.

o      The objects in the list are optional.

o      The named objects are used only if any unresolved imports exist and if the named object provides an expert to satisfy the unresolved import request.

·         CL Commands used with Binding Directories

Command	Description
CRTBNDDIR	Create Binding Directory Creates a binding directory object in the specified library.
DSPBNDIR	Display Binding Directory Displays the contents of a binding directory.
DLTBNDDIR	Delete a Binding Directory Deletes a binding directory
WRKBNDDIR	Work with Binding Directory Allows you to display and work with a list of binding directories.
ADDBNDDIRE	Add Binding Directory Entry Adds an entry to the binding directory.
RMVBNDDIRE	Remove Binding Directory Entry. Removes an entry from the binding directory
WRKBNDDDIRE	Work with Binding Directory Entry. Allows you to work with the entries in a binding directory.

·         Binder

 The binder processes import requests for procedure names and data item names from specified modules. The binder then tries to find matching exports in the specified modules, service programs and binding directories.

While creating an ILE program or a service program, the binder performs following types of binding:

o      Bind by copy: To create the programs following are copied:

§  The modules specified on the module parameter

§  Any modules selected from the binding directory that provide an export for an unresolved object.

Physical addresses of the needed procedures and data items used within the copied modules area established when the ILE program or service program is created.

o    Bind by reference: Symbolic links to the service programs that provide exports for unresolved import requests are saved in the created program or service program. The symbolic links refer to the service programs providing the exports. The links are converted to physical addresses when the program object to which the service program is bound is activated.

  

·         Binder Language

The binder language is a small set of non-runnable commands that defines the exports for a service program. Binder language enables SEU syntax checker to prompt and validate the input when a BND source type is specified.

The binder language consists of a list of the following commands:

o      Start Program Export (STRPGMEX) command, which identifies the beginning of a list of exports from a service program.

o      Export Symbol (EXPORT) commands, each of which identifies a symbol name available to be exported from a service program.

o      End Program Export (ENDPGMEXP) command, which identifies the end of a list exports from a service program.

  Example of the binder language in source file:

         STRPGMEXP PGMLVL (*CURRENT)LVLCHK (*YES)

               EXPORT SYMBOL(P1)

               EXPORT SYMBOL(P2)

  

               ENDPGMEXP

        STRPGEXP PGML VL(*PRV)

        EXPORT SYMBOL(P3)

        ENDPGMEXP

 ·         Signature

The symbols identified between a STRPGMEXP and ENDPGEXP pair define the public interface to a service program, which is identified by a signature. A signature is a value that identifies the interface supported by a service program.

If specific signature is not specified then the binder generates the signature from the list of procedure and data item names to be exported.

 STRPGMEXP Command Signature Option

Following screen appears when user presses enter on STRPGMEXP command

   Start Program Export List (STRPGMEXP)

       Type choices, press Enter.

      

       Additional Parameters

       Program level………>*CURRENT  *CURRENT. *PRV

       Signature level check….>*YES      *YES, *NO

       Signature………………>*GEN

       Comment

SIGNATURE identifies the interface that the service program will provide. The default value for the signature parameter, *GEN will cause the binder to generate a signature from exported symbols.

Using the Display Service Program (DSPSRVGM) command and specifying DETAIL (SIGNATURE) can determine signature value for a service program.

·         Binding Static vs. Dynamic

o      Static binding scores on storage and performance

o      In dynamic binding and Service programs, modules are frequently used by various       

     applications but storage is a concern.

                  o      In static binding purpose of the module is unique and it is used by few application programs.

       ·         CL Commands Used to Edit the Binder Language Source File

STRPDM	Start Program Development Manager
STRSEU	Start Source Entry Utility

The following non-runnable commands can be entered into the binder language source file:

Command	Description
STRPGMEXP	Start Program Export List Starts a list of exports in a service program export block.
EXPORT	Export a Program Symbol Defines an export in a service program export block
ENDPGMEXP	End Program Export List Ends a list of exports in a service program export block.

• Binder Language Example

The binder language for the Rate, Amount, Payment and term procedures is as follows:

FILE: MY LIB/SQR VSRC             MEMBER:ACCOUNTS

STRPGMEXP PGMLVL (*CURRRENT)

       EXPORT SYMBOL (‘Term’)

       EXPORT SYMBOL (‘Rate’)

       EXPORT SYMBOL (‘Amount’)

       EXPORT SYMBOL (‘Payment’)

ENDPGMEXP

Three modules viz. MONEY,RATES and CALCS do the necessary processing.

 To create the service program as shown on the next page, the binder language is specified on the following CRTSRVPGM command:

CRTSRVPGM SRVPGM (MYLIB/ACCOUNTS)

MODULE (MYLIB/MONEY MYLIB/RATES MYLIB/CALCS

EXPORT (*SRCFILE)

SRCFILE(MYLIB/QSRVSRC)

SRCMBR(*SRVPGM)

Ø  Calls to Programs and Procedures

In ILE one can call either a program or procedures. ILE requires that the caller identity whether the target of the call statement is a program or a procedure. ILE languages communicate this requirement by having separate call statements for programs and for procedures. Each ILE language has unique syntax to distinguish between a dynamic program call and a static procedure call. Its standard call statement default call and for C it is static procedure call.

Two types of calls can be made during ILE run time: dynamic program calls and static procedure calls. When an ILE program is activated all of its procedures except its PEP become available for static procedure calls. Program activation occurs when the program is called by a dynamic program call and the activation does not exist already. When a program is activated, all the service programs that are bound to this program are also activated. The procedure in an ILE service program can be accessed only by static procedure calls (and never dynamic by program calls)

·             Dynamic Program Calls

A dynamic program call is a call made to a program object. E.g. when you use the CL command CALL, you are making a dynamic program call.

 OPM programs are called by using dynamic program calls. OPM programs are limited to making  only dynamic program calls.

 EPM programs can make program and procedure calls. OPM programs are limited to making only dynamic program calls.

 EPM programs can make program and procedure calls. EPM programs can also be called by other  programs and procedures.

 ILE programs are also called by dynamic program calls. The procedures within an activated ILE program can be accessed by using static procedure calls. ILE programs that have not been activated yet must be called by dynamic program call.

 Unlike static procedure calls, which are bound at compile time, symbol for dynamic procedure calls resolved to addresses when the call is performed. As a result, dynamic program call uses more system resources than a static procedure call. Examples of dynamic program call include:

       o    A call to an ILE program, an EPM program or an OPM program

 o    A call to non-bindable API

A dynamic program call to an ILE program passes control to the PEP of the identified program, which then passes control to the UEP of the program. After the called program is done processing control is passed back to the instruction following the call program instruction.

·         Passing Arguments on a Dynamic Program Call

Calls to ILE or OPM programs (unlike calls to ILE procedures) usually pass arguments by reference, meaning that the called program receives the address of the arguments.

 When using a dynamic program call, you need to know the method of arguments passing, that is expected by the called program. A maximum of 255 arguments are allowed on a dynamic program call.

 A dynamic program call transfers control to either an ILE program object or an OPM program object. Dynamic program calls include the following:

o      An OPM program can call another OPM program (*PGM) or an ILE program (*PGM), but it cannot call a service program (*SRVPGM).

o      An ILE program can call an OPM program or another ILE program, but it cannot call a service program.

o      A service program can call an OPM program, or an ILE program, but it cannot call another service program

·         Call Stack

The call stack is a last-in-first out (LIFO) list of call stack entries, one entry for each called procedure or program. Each call stack entry has info about the auto variables for the procedure or program. There is one call stack per job. A call adds a new entry on the call stack for the called procedure or program and passes control to the called object. A return removes the stack entry and passes control back to the calling procedure or program in the previous stack entry.

Ø  ILE Source Debugger

ILE provides a debugger that allows source level debugging. You must create debug data when you compile a module to allow it to be debugged. The debugger can work with a listing file and allow you to set breakpoints, display variables and step into or over an instruction. One can do all these without entering any command from command line. A command line is also available while working with the debugger.

The source-level debugger uses system-provided APIs to allow you to debug an ILE program or a service program

 The debugger for OPM programs continues to exist on AS/400 system but can be used to debug only OPM programs.

·         Debug Mode

   To use the source debugger, your session must be in debug mode. Debug mode is a special environment in   which program debug functions can be used in addition to normal system functions. Your session is put into   debug mode when you run the Start Debug (STRDBG) command.

·         Debug Environment

           A program an be debugged in either of the two environments:

o      The OPM debug environment. All ILE programs are debugged in this environment unless the OPM programs are explicitly added to the ILE debug environment.

o      The ILE debug environment. All ILE programs are debugged in this environment. In addition, an OPM program is debugged in this environment if all the following criteria is met:

§  It is a CL, COBOL or RPG program.

§  It is compiled with OPM source debug data

§  The program name is specified on the Start Debug (STRDBG) command and OPMSRC parameter of this command is set to *YES.

The ILE debug environment provides source level debug support. The debug capability comes directly from statement, source or list views of the code.

·         Addition of Programs to Debug Mode

A program must be added to debug mode before it can be debugged. OPM programs, ILE programs and ILE service programs can be in the debug mode at the same time. As many as 20 OPM programs can be in debug mode at one time in the OPM debug environment. But the number of OPM, ILE and service programs that can be in debug mode in ILE debug environment is not limited. However, the maximum amount of debug data that is supported at one time is 16 MB per module.

You must have *CHANGE authority to a program to add it to debug mode. A program can be added to debug mode when it is stopped on the call stack.

·         Module Views

The levels of debug data available may vary for each module in an ILE program or service program. The modules are compiled separately and could be produced with different compilers and options. These debug data levels determine which views are produced by the compiler and which views are displayed by the source debugger.

Possible values of the debug view (DBGVIEW) parameter on commands CRTxxxMOD and CRTBNDxxx are as follows:

*NONE  No debug views area produced. No debug data.

*STMT  No source is displayed by the debugger but breakpoints can be added using procedure names and statement numbers. Minimum amount of debug data.

*SOURCE    The source debugger displays source if the source files used to compile the module are still present on the system.

*LIST    The list view is produced and stored with the module. This allows the source debugger to display source even if the source file is not present on the system.

*ALL     All debug views are produced. Amount of debug data can be very large.

ILE RPG/400 also has a debug option *COPY that produces both a source view and a copy view. The copy view is a debug view that has all the /COPY source members included.

·         How Observability and Optimization Affect Debugging

Whether a module is observable and whether it is fully optimized affect the ability to debug it.

Module Observability refers to data that can be stored with module that allows it to be changed without being compiled again.

Optimization is a process where the system looks for processing shortcuts that reduce the amount of system resources necessary to produce the same output.

Observability

                  Module Observability consists of two types of data:

§  Debug Data: Represented by the *DBGDTA value. This data is necessary to allow a module to be debugged.

§  Creation date: Represented by the *CRTDATA value. This data is necessary to translate the code to machine instructions. The module must have this data for changing the module optimization level.

Once a module is compiled, you can only remove this data using Change Module (CHGMOD) command. You can remove either type of data from the module. Removing all observability reduces the module to its minimum size.

o      Optimization Levels

If a module has creation data, you can change the level at which the source code is optimized to run on the system. The higher the optimization level, the more efficiently the procedures in the module run. However, with more optimization you cannot change variables and may not be able to view the actual data of a variable during debugging. While debugging set the optimization level to 10 (NONE). This provides lowest level of performance for the procedures in the module but allows you to correctly display and change variables. After you have module but allows you to correctly display and change variables. After you have completed your debugging, set the optimization level to 30 (*FULL) or 40. This provides the highest level of performance for the procedures in the module.

Debug Data Creation and Removal

Debug data is stored with each module and is generated when a module is created. To debug a procedure in a module that has been created without debug data, you must recreate the module with debug data and then rebind the module to the ILE program or service program. You do not have to recompile all the other modules in the ILE program or service program that already have debug data. To remove the debug data from the module, re-create the module without debug data or use the Change Module(CHGMOD) command.

·         CL Commands Used with Source Debugger

Command	Description
STRDBG	Start Debug Puts a job into debug mode and, optionally, adds as many as 20 programs to debug mode.
ENDDBG	End Debug Ends debug mode for a job, removes all breakpoints and traces, clears any trace data, and removes all programs from debug mode.
DSPMODSRC	Display Module Source Allows the user to show the source debug display for debugging bound programs.

·         Summary

o      ILE provides a debugger that allows source-level debugging. You must create debug data when you compile a module to allow it to be debugged.

o      The OPM debugger is all still supported but can only be used to debug OPM programs.

Ø  ILE ACTIVATION GROUP

·         Activation

The process of getting a program or service program ready to run is called activation. A command need not be issued to activate a program. Activation is done by the system when a program is called. As the service program are not called, they are activated during the call to a program that requires their services.

Activation performs the following functions:

o      Uniquely allocates the static data needed by the program or service program.

o      Changes the symbolic links to service programs providing the exports into links to physical addresses.

No matter how many jobs are running a program or service program, only one copy of that object’s instructions resides in the storage. However every program’s activation has its own static storage. So even if one program object is used concurrently by many jobs, the static variables are separate for each activation. A program can be activated in more than one activation group, even within the same job, but activation is local to a particular activation group.

·         Program Activation

Activation is the process used to prepare a program to run. Both ILE programs and ILE service programs must be activated by the system before they an be run.

Program activation includes two major steps:

o      Allocate and initialize static storage for the program.

o      Complete the binding of programs to service programs.

·         Program Activation Creation

         ILE manages the process of program activation by keeping the track of program activations within an            activation group. An activation group has only one activation for particular program object.

When a dynamic program statement is used in a HLL program, ILE uses the activation group that was specified by using the activation group (ACTGRP) parameter on either Create program (CRTPGM) command or the Create Service Program (CRTSRVPGM) command. If program activation already exists within the activation group indicated with this parameter, it is used. If the program has never been activated within this activation group, it is activated first and then run.

Once a program is activated. it remains activated until the activation group is deleted. As a result. it is possible to have active programs but that are not on the call stack within the activation group.

Following figure shows an example of three active programs within an activation group, but only two of the three programs have procedures on the call stack. Here program A calls program B, causing program B to be activated. Program B then returns to program A. Program A then calls program C, the resulting call stack contains procedure for programs A and C but not for program B.

·         Activation Group

      All ILE program and service programs are activated within a substructure of a job called Activation       

      Group. This substructure contains the resources necessary to run the program, which are as follows:

o      Static and automatic program variables

o      Temporary data management resources

o      Certain types of exception handlers and ending procedures.

       The static and automatic program variables and dynamic storage are assigned separate address spaces           for each activation group. This provides some degree of program isolation and protection from       

        accidental access.

      The temporary data management resources include following:

o      Open files (Open Data Path or ODP)

o      Commitment definitions

o      SQL cursors

o      Hierarchical File System (HFS)

o      User interface manager

o      Query management instances

o      Open communication links

o      Common Programming Interface (CPI) communications

    The separation of these resources among activation groups supports a fundamental concept. That is, the         concept that all programs within one activation group developed as one co-operative application.

Software vendors may select different activation groups to isolate their programs from other vendor applications running in the same job. This vendor isolation is shown in the following figure. In this figure, integrating software packages from four different vendors provides a complete customer solution. Activation groups increase the case of integration by isolating the resources associated with each vendor package.

·         Activation Group Creation

One can control the run-time creation of ILE activation group by specifying an activation group attribute when one creates the ILE program or service program. Using the ACTGRP parameter on the CRTPGM or CRTSRVPGM command specifies this attribute. There is NO Create Activation Group (CRTACTGRP) command.

All ILE programs have one of the following activation group attributes:

o      A user-named activation group specified with the ACTGRP (name) parameter. This attribute allows you to manage a collection of ILE programs and ILE service programs as one application. The activation group is created when it is first needed. It is then used by all programs and service programs, which specify the same activation group name.

o      A system-named activation specified with the ACTGRP (*NEW) parameter on the CRTPGM command. This attribute allows creating a new activation group whenever the program is called. ILE selects a name for this activation group, which is unique within the job. ILE service programs do not support this attribute.

o      An attribute to use the activation group of the calling program specified with the ACTGRP(*CALLER) parameter. This attribute allows you to create an ILE program or ILE service program that will be activated within the activation group of the calling program that will be activated within the activation group of the calling program. With this attribute, a new activation group is never created when a program or service program is activated.

All activation groups within a job have a name. Once an activation group exists within a job. It is used by ILE to activate programs and service programs that specify the name. Because of this duplicate activation group names cannot exist within one job.

·         Default Activation Groups

When an OS/400 job is started, the system creates two activation groups to be used by OPM programs. One is reserved for OS/400 system code. The other activation group is used for all other OPM programs. The OPM activation groups are deleted by the system when a job ends. User cannot delete the OPM default activation groups.

      ILE program and ILE service program can be activated in the OPM default activation groups if                    following conditions are satisfied:

o      The ILE programs or ILE service programs were created with the activation group *CALLER option.

o      The call to the ILE programs or ILE service programs originates in the OPM default activation groups.

As the default activation groups cannot be deleted, ILE HLL end verbs cannot provide complete end processing. Open files cannot be closed by the system until the job ends. Also static and heap storages used by ILE programs cannot be returned to the system until the job ends.

Following figure shows a typical OS/400 job when an ILE activation group and an OPM default activation groups. The two OPM default activation groups are combined because the special value *DFTACTGRP is used to represent both groups. The boxes within each activation group represent program activations.

Service Program Activation

The system uses steps to activate service programs. The common steps used for programs are described in the topic Program Activation. The following activities area unique for the activation of service programs:

o      Service program activation starts directly as part of a dynamic program call to an ILE program.

o      Service program activation includes completion of inter program binding linkages by mapping the symbolic links into physical links.

o      Service program activation includes signature check processing.

An ILE program activated for the first time within an activation group is checked for binding to any ILE service programs. If service programs have been bound to the program being activated, they are also activated as part of the same dynamic call processing. This process is repeated until all the necessary service programs are activated. 

·         ILE Activation Group Deletion

Activation groups require resources to be created within a job. Processing time may be saved if an activation group can be reused by an application. ILE provides several options to return from the activation group without ending or deleting the activation group. Whether the activation group is deleted depends on the type of activation group and the method in which the application ended.

An application may leave an activation group and return to call stack entry, that is running in another activation group in the following ways:

o      HLL end verbs. E.g. STOP RUN in COBOL or exit () in C.

o      Un-handled exceptions can be moved by the system to a call stack entry in another activation group.

o      Skip operations. E.g. sending an exception message or branching to a call stack entry that is not in the current activation group.

You can delete an activation group from the application by using HLL end verbs. An un-handled Exception can also cause the activation group to be deleted.

System named activation groups is always deleted by a normal return because they cannot be reused using the system-generated name.

A user-named activation group may be left I the job for later use. For this type of activation group, any normal return or skip operation does not delete the activation group. The same operations used within a system named activation group delete the activation group. System named activation groups are always deleted because they cannot be reused using the system generated name.

A user named activation group is left in the job, it can be deleted by using the Reclaim Activation Group (RCLACTGRP) command. This command allows one to delete named activation groups after the application has returned. Only activation groups that are not in use can be deleted with this command.

When an activation group is deleted by ILE, certain end-operation processing occurs. This processing includes calling user-registered exit procedures, data management cleanup, and language cleanup (such as closing files).

Following figure shows examples of how to leave an activation group. In the figure, procedure P1 is the oldest call stack entry. For the system-named activation group (created with ACTGRP (*NEW) option), a normal return from P1 deletes the activation group. For the user-named activation group (created with the ACTGRP (name) option), a normal return from P1 does not delete the activation group.