Getting a grip on ILE binding requires you to properly manage the exports and signatures of service programs. Implementing export and signature controls though binder language makes applications flexible, modular, dependable, easier to enhance and modify, and less prone to costly production errors.

A service program is a collection of ILE procedures that can be statically called from ILE programs or other service programs. Service programs are bound to their callers by reference during the ILE program creation process.

Binder language is a special language that allows the programmer to control how service programs bind to their callers. Binder language gives a programmer a way to list a service program’s exports, the procedures and data to which calling procedures have direct access. Listing exports through binder language means that calling programs can continue to use a service program, even after that service program has been modified.

The Importance of Signatures

When a service program is compiled, OS/400 generates a special 16-byte signature from the exportable procedures and data items of the service program. This is similar in concept to the level identifiers that OS/400 generates for record formats when files are created. OS/400 uses signatures to ensure that the programs that call the service program use a compatible program-calling interface. If the program-calling interface is not compatible, a program signature violation error will occur. You can use binder language to avoid such conflicts.

When you compile an ILE service program, you have two ways to specify exports. If you specify EXPORT(*ALL) in the Create Service Program (CRTSRVPGM) command, the system generates a signature from all the exported variables and subprocedures. If programs or other service programs are already using the service program, and the list of exports has changed since those callers were compiled, you’ll have to recompile all the callers in order to avoid signature violations (level checks). Recompiling programs is not productive; binder language lets you eliminate the need to do so.

Binder language gives you a way to list the procedures and data items you want to export. You can also specify what service program signature you wish to have when you create the service program.

To avoid the need to recompile callers when a service program’s list of exports changes, specify EXPORT(*SRCMBR) on the CRTSRVPGM command. This means that you have entered binder language statements into a source member. CRTSRVPGM will use this source member when creating the ILE service program.

You can specify more than one list of exports in a binder language source member. Each list will generate a different signature.

You can use the Display Service Program (DSPSRVPGM) command to view the exports and signatures of a service program. This signature will be displayed in hexadecimal format.

Example ILE Payroll Application

To illustrate how to take charge of binding, consider an RPG IV service program designed for a payroll application. Initially, it calculates federal taxes and net pay for one employee. Later, I will add procedures to compute the state and social security taxes. The purpose of this approach is to show how to avoid program interface errors when adding new exported procedures to an existing service program.

The service program I’ll use is named CalcTaxes (see Figure 1). It copies one source member that contains procedure prototypes (Figure 2), and then it exports two items—subprocedures CalcFedTax and CalcNetPay.

Binder language is stored in member CALCTAXBL, shown in Figure 3. Notice that the syntax is similar to CL. Each line begins with a command and is followed by parameters in keyword format. The Start Program Export (STRPGMEXP) and End Program Export (ENDPGMEXP) binder statements start and end the export declarations. The PGMLVL(*CURRENT) parameter of the STRPGMEXP statement stipulates that this export list generates the current service program signature. The LVLCHK(*YES) parameter specifies that the signature should be verified at runtime, when the service program is called. The EXPORT statements indicate what procedures are to be exported.

First, create a module from the CALCTAXES member. Then create the service program using the binder language source. The commands needed to complete these steps are shown in Figure 4. Notice the SRCMBR parameter on the CRTSRVPGM command. It tells the compiler where to find the binder language source code.

When the service program is created, it can be bound by reference to a calling program. Binding by reference, as opposed to by copy, saves disk space. Also, more than one calling program can use this service program [see “Get a Grip on ILE Binding, Part 1,” MC, October 1998].

In order to demonstrate how to use the CalcTaxes service program, I wrote a calling program named CalcTaxesPrn. Because of space limitations, we cannot publish the entire code in this article. However, all of the code for this article, including CalcTaxesPrn, is available free from the Midrange Computing Web site at http://www.midrangecomputing.com/mc/98/11.

The code snippet used by CalcTaxesPrn is displayed in Figure 5. Notice the use of the EVAL and CALLP commands. These are the commands that access the procedures in the CalcTaxes service program [see “RPG IV Subprocedures,” MC, August 1996].

Enhancing the Service Program Assume the CalcTax service program has been in production for a while and is being called by various programs. Now you’re told to add some procedures that will calculate state and social security taxes to the CalcTaxes service program. To do so, you must modify three source code members:

• CalcTaxes (the service program)
• CalcTaxesPr (subprocedure prototypes)
• CalcTaxesBL (binder language)

You can see the revised service program and prototype source in Figures 6 and 7, respectively. The revised binder language, shown in Figure 8, updates the service program export list to include the new procedures. The previous version of the export list is supported by the PGMLVL(*PRV) keyword in the second STRPGMEXP statement. This ensures backward compatibility with the previous versions of the service program. That is, callers who expect to find the old version of the CalcTaxes service program will be able to use the CalcFedTax and CalcNetPay subprocedures in the new version of the service program.

Design Your Own Signature

If you wish, you can specify a service program signature of your choosing by using the SIGNATURE keyword of the STRPGMEXP statement, as in Figure 9. You might want to do this to further control which programs can access your service programs.

Speaking in Binder Language Will Make Your Applications Better

Learning to use binder language is not difficult; it doesn’t take much time or effort, and the application results are definitely worth it. Service programs are important in ILE application development. The better your service programs are implemented, the stronger your applications will be.

References

AS/400 ILE Concepts V4R2 (SC41-4606, CD-ROM QB3AQ701) ILE Application Development Example V4R2 (SC41-5602, CD-ROM QB3AQ400) ILE RPG for AS/400 Programmer’s Guide V4R2 (SC09-2507, CD-ROM QB3AGY00)

Moving to ILE RPG V4R2 (GG24-4358)

Figure 1: CalcTaxes service program, version 1

* Source member - CalcTaxes
H NOMAIN

/copy qrpglesrc,calcpr

P CalcFedTax B EXPORT
D PI 6 2
D WageAmt 4s 0 VALUE
D FedPercent 2s 2 VALUE
C return WageAmt * FedPercent
P CalcFedTax E

P CalcNetPay B EXPORT
D PI
D NetPay 6 2
D WageAmt 4s 0
D FedTax 6 2
D StTax 6 2
D FICATax 6 2
C eval NetPay = WageAmtC FedTaxC StTaxC FICATax
P CalcNetPay E

* Source member - clacpr
D CalcFedTax PR 6 2
D 4s 0 VALUE
D 2s 2 VALUE
D CalcNetPay PR
D 6 2
D 4s 0
D 6 2
D 6 2
D 6 2 STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
EXPORT SYMBOL(CalcFedTax)
EXPORT SYMBOL(CalcNetPay)

ENDPGMEXP CRTRPGMOD MODULE(XXX/CALCTAXES)
CRTSRVPGM SRVPGM(XXX/CALCTAXES) +

MODULE(XXX/CALCTAXES) SRCMBR(CALCTAXBL) *----------------Declare standalone variablesD EmployeeName S 20a

D WageAmt S 4s 0

D FedPercent S 2s 2

D StPercent S 2s 2

D FICAPercent S 2s 2

D TotPayAmt S 6 2

D StTaxAmt S 6 2

D FedTaxAmt S 6 2

D FICATaxAmt S 6 2

D NetPayAmt S 6 2

* Issue static procedure calls with the eval command

*

C eval FedTaxAmt = CalcFedTax(WageAmt:

C FedPercent)

*

* Issue static procedure calls with the callp command

C callp CalcNetPay(NetPayAmt:

C WageAmt:

C FedTaxAmt:

C FICATaxAMT:

C STTaxAmt)

Figure 2: Subprocedure prototypes, version 1 Figure 3: Binder language, version 1 Figure 4: Compiling a service program with binder language Figure 5: Code snippets for CalcTaxesPrn driver module

* Source member CalcTaxes Version 2
H NOMAIN

/copy qrpglesrc,calcpr
/copy qrpglesrc,calcpr2

P CalcFedTax B EXPORT
D PI 6 2
D WageAmt 4s 0 VALUE
D FedPercent 2s 2 VALUE
C return WageAmt * FedPercent
P CalcFedTax E

P CalcNetPay B EXPORT
D PI
D NetPay 6 2
D WageAmt 4s 0
D FedTax 6 2
D StTax 6 2
D FICATax 6 2
C eval NetPay = WageAmtC FedTaxC StTaxC FICATax
P CalcNetPay E

P CalcStTax B EXPORT
D PI 6 2
D WageAmt 4s 0 VALUE
D STPercent 2s 2 VALUE
C return WageAmt * STPercent
P CalcStTax E

P CalcFICATax B EXPORT
D PI 6 2
D WageAmt 4s 0 VALUE
D FICAPercent 2s 2 VALUE
C return WageAmt * FICAPercent
P CalcFICATax E * Source member calcpr2
D CalcStTax PR 6 2
D 4s 0 VALUE
D 2s 2 VALUE
D CalcFICATax PR 6 2
D 4s 0 VALUE
D 2s 2 VALUE STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES)
EXPORT SYMBOL(CalcFedTax)
EXPORT SYMBOL(CalcNetPay)
EXPORT SYMBOL(CalcStTax)
EXPORT SYMBOL(CalcFICATax)
ENDPGMEXP
STRPGMEXP PGMLVL(*PRV)
EXPORT SYMBOL(CalcFedTax)
EXPORT SYMBOL(CalcNetPay)

ENDPGMEXP

Figure 6: CalcTaxes service program, version 2 Figure 7: Subprocedure prototypes, version 2

Figure 8: Binder language, version 2 Figure 9: Specifying a signature of choice

STRPGMEXP PGMLVL(*CURRENT) SIGNATURE('CALCTAXPR2')