Midware Ltd.

Sign-up for e-mail notifications

Take our weekly poll

Now that you have a good understanding of the language differences between RPG III and RPG IV, as well as the conceptual differences between OPM and ILE, it's time to cover the specifics of ILE.

The effort and complexity converting from OPM to ILE can vary widely depending on how extensively you want to exploit ILE's features.  Some of the benefits are as simple as converting a program to ILE.  However to take full advantage of ILE requires a great deal of planning during the design phase of an application.  There are many issues and strategies that must be fully explored before a system can be fully take advantage of the advanced features of ILE.  We'll try to at least touch on most of these issues, but the subject is just too vast, and specific to your company's environment to cover fully.

Before we look forward to where language development in general is going, it may be helpful to look back at the evolution of programming philosophies.

In the 50's & 60's computer programming was in it's infancy.  There was little regard given to style or maintainability.  And in honesty, the primitive nature of computers at the time didn't offer many amenities to make a programmers life easier.

In the 70's, as new programmers entered the field and had to maintain the existing code, a new programming style emerged know as structured programming.  Structured programming involved organizing programs in a top-down structure with common code executed more than once isolated in a subroutine.

Structured programming did in fact improve the readability and maintainability of programs.  The usage of subroutines insured that common code would only reside once in a program.  If this code needed changed, it would only be need to be changed once  --  per program,

There was still the problem of common code existing (although once per program) in many programs.  Possible hundreds.  This was (and still is) a problem from two points of view.  First, it reduces programmer efficiency, and second, it complicates program maintenance.

Two solution were offered to improve this situation: (1) Common code could be moved to external programs and called when needed, or (2) Common code was isolated to copybooks and included automatically at compile time when needed.

Externalizing common code to separate programs and calling them when needed seemed like the answer.  However, it was soon discovered that this was very expensive from a CPU usage standpoint.  At this point in computer history, many batch processes were already running many hours overnight, or even days for some month-end jobs.  Externalizing common code could easily increase run times exponentially.

There are also additional inconveniences with using called programs - primarily the inability to share elements between the calling and called programs unless they are passed as parameters.

Copybooks partially solved these problems, but they themselves have two major drawbacks.  First, they do little to improve maintainability.  True, if the code needs to be changed, it only needs to be changed once, but all programs using the copybook need to be recompiled.  There is also the possibility that the changes could adversely affect something in the base program.

Copybooks also require a great deal of compliance from the programs that will be using them.  Files needed must be previously defined correctly, working variables must either be previously defined or reserved for use by the copybook.  Parameters aren't passed either.  Rather specific field names name be assigned with the correct data.

The following table summarizes the benefits and drawbacks of each of the three methods we've talked about so far.  We'll see this table in later sections as we compare some of the ILE techniques with these.  Each category is given a rating of 0 to 3 checks (the more, the better) based on the ease of using and maintaining code with common functionality.

By structured programming, we mean that the code is replicated as a subroutine in each of the programs that needs it.  Called programs means the code is isolated to a separate program and called when needed.  Copybooks are included at compile time when they are needed.

The four categories are:

1. Maintainability:  How easy is it to make changes to the common code.
2. Performance:  How long does it take (from a CPU standpoint) to execute the common code.
3. Data sharing:  How easy is data shared between the common code and the base (calling) code.
4. Ease of use:  How easy is it to use the common code as a utility.  How much preparation must be done?

	Maintainability	Performance	Data sharing	Ease of use
Structured Programming
Called programs
Copybooks

We can see that called programs would be a good solution if calling them were more efficient on the CPU.  Data sharing is also difficult - all shared data must be passed as parameters.  Numeric fields must be the same type (packed vs. zoned) and length.

Copybooks eliminate the performance concerns, and because ultimately they just get compiled as subroutines in the same program, the data sharing is much easier also (although you need to be careful with field names).  However, they are still difficult to maintain if changes need to be made.  There are also often many requirements placed on your program before you can use them.

This is where ILE comes in.  The integrated language environment provides features which - depending how you use them - fix some or all of the above concerns.

 

Back to Built-In-Functions

Next to ILE Procedures

 

Send mail to midware@midwareservices.com with questions or comments about this web site.
Copyright © 2000 Midware, Ltd.

Last Modified:  August 21, 2000