Brief: On February 16, IBM announced that V2R3 of OS/400 will include major changes to the underlying language support. The Integrated Language Environment (ILE) which is at the root of these changes will become increasingly important to you. In this article, a key member of IBM's languages planning team explains the concepts and functions of ILE.The new Integrated Language Environment (ILE) announced in February is a paradigm, or model, for programming languages on the AS/400. It provides an essential building block for all AS/400 languages at the operating system level. By establishing a common interface for programming languages, ILE supplies the functions you'll need to do your job easily and efficiently in the years to come.
In order to understand ILE, a short history lesson is useful. There are currently two distinct language models on the AS/400. The Original Program Model (OPM) is used for the traditional business programming languages like RPG and COBOL. The Extended Programming Model (EPM) supports languages such as C and Pascal. As 1 illustrates, EPM is implemented above the machine interface, causing a performance penalty for EPM languages. ILE (sometimes referred to as New Program Model or NPM) brings the best of the two existing models together into one evolutionary model at a lower level of the operating system. This marriage of strengths allows C to perform well and, at the same time, enables the traditional languages to meet changing business application needs. The benefits of ILE may not be immediately apparent but they include: the tools IBM needs to develop truly modern languages for the AS/400, including object-oriented languages; better interaction between programs written in different languages; better program-to-program call performance; and a fertile environment for third-party development products.
In order to understand ILE, a short history lesson is useful. There are currently two distinct language models on the AS/400. The Original Program Model (OPM) is used for the traditional business programming languages like RPG and COBOL. The Extended Programming Model (EPM) supports languages such as C and Pascal. As Figure 1 illustrates, EPM is implemented above the machine interface, causing a performance penalty for EPM languages. ILE (sometimes referred to as New Program Model or NPM) brings the best of the two existing models together into one evolutionary model at a lower level of the operating system. This marriage of strengths allows C to perform well and, at the same time, enables the traditional languages to meet changing business application needs. The benefits of ILE may not be immediately apparent but they include: the tools IBM needs to develop truly modern languages for the AS/400, including object-oriented languages; better interaction between programs written in different languages; better program-to-program call performance; and a fertile environment for third-party development products.
Specifically, the February 16 announcement includes a new product-ILE C/400- and two statements of direction: one for ILE RPG and one for ILE COBOL. ILE languages give the programmer access to the underlying ILE functions in the operating system. At the same time, as part of IBM's commitment to ILE, many new language-specific features will be introduced as the ILE languages are released. To date, the languages team has invested more than two years of intense development effort in ILE and the related languages.
What's In It For Me?
You might think that ILE is only relevant to system designers and C programmers, but it has specific benefits for every AS/400 shop now and in the future:
o Performance enhancements for program-to-program calls. These enhancements will make it feasible to develop very small, reusable code modules. Although from a design perspective this approach has always been preferred, until now the performance impact on the AS/400 has been substantial. As a result, performance-conscious programmers have limited the number of calls within any program, reducing the overall modularity of the code.
o Performance enhancements for C applications. Even if you never intend to write a C program, this enhancement matters, right now! For both IBM and third-party tool vendors, C is the development language of choice. Improving its performance opens the door for faster compilers, better application development tools and the migration of many products from other platforms. Expect a proliferation of new development software over the next few years.
o Enhanced functions for all languages. Each new ILE language incorporates a wish list of new features specifically designed to meet the needs of AS/400 application developers.
How Does It Work?
Most of the performance benefits associated with ILE are attained through something called static binding. Under OPM, a call between programs is considered to be dynamic. This dynamic binding means that the operating system does some processing at execution time to determine the location of the called program and whether it is okay to call it. This processing must occur every time the program is run and has a relatively large impact on run-time performance.
On the other hand, static binding shifts some of the overhead of the program- to-program call to the compilation, or program creation, step. Therefore, the overhead occurs once when the program is created, rather than every time the application is run. This permits the programmer to structure his application in a very modular format without having to pay a penalty in performance. This is particularly important for C programs which are typically much more call- intensive than traditional business applications.
Under ILE, the programmer can choose whether to use static binding, dynamic binding or a combination of the two. As a result, you, rather than the software constraints, control which calls require high performance and where the overhead occurs.
A new step has been added in the creation of programs to provide the facilities for static binding. Before a program object (*PGM) can be created, the individual ILE programs must be compiled with a Create xxx Module (CRTxxxMOD) command (e.g., CRT-RPGMOD for RPG). The CRTxxxMOD commands produce a system object (new with V2R3) called a module (*MODULE). This module is not an executable object; an additional step is required to create the program object.
For ILE programs that utilize static binding, the Create Program (CRTPGM) command binds together two or more modules to create an executable program object (*PGM). 2 (page 56) illustrates the process for two RPG modules. The final *PGM object can be built up from many modules, all written in the same language or each one written in a different ILE language.
For ILE programs that utilize static binding, the Create Program (CRTPGM) command binds together two or more modules to create an executable program object (*PGM). Figure 2 (page 56) illustrates the process for two RPG modules. The final *PGM object can be built up from many modules, all written in the same language or each one written in a different ILE language.
Less is More
Unlike the current AS/400 language environments, ILE does not penalize application performance when you build well-structured, easy-to-maintain applications. Building smaller programs reduces the compile time and makes it easier for several different programmers to work on a project simultaneously. ILE also greatly enhances your ability to reuse code in multiple applications.
Wouldn't it be nice if you could build an application using parts that have already been thoroughly tested? You know what these parts do and you know they are reliable because they have been used for years. Although this "perfect" programming environment is still in the future, ILE brings it much closer to reality.
This capability hinges on some changes that are part of ILE-for example, greater consistency among languages. Today, it's difficult to build a reusable part because each language has its own rules, forcing the programmer to be aware of the languages that make up the application. You cannot just plug in a module from a different language without understanding the language that was used. ILE languages reduce this barrier significantly since they share a common interface and thus interact well together.
Everyone always advocates using the right tool for the job; but under current language models, this admirable concept is not always easy to implement. For example, an RPG application may need to process the bits and bytes of a stream of data. A C routine that is called from the RPG application could easily accomplish this; but, without ILE, it is not as easy as it should be to mix languages within an application. Differences in data type support and error handling are examples of problems that occur when you combine languages within an application. The rules defined for ILE will ease these problems significantly, making multilanguage applications practical.
Static binding also facilitates the process of building reusable modules. Program-to-program call overhead presents one of the obstacles to building a module that can be plugged into any application. If the module you build has to be called dynamically every time it is used, you end up paying a penalty in performance or building a larger, less generic module. With the ability to statically bind these modules to the main program, the dynamic call overhead disappears.
The Sum of the Parts
The combination of consistent rules and flexibility in the bind step enables you build an application from different languages. 3 (page 56) shows an ILE program, PGMA, made up of three modules. Two of the modules are coded in C and one of the modules is coded in RPG. The calls between the modules are static or bound calls; but a call from one of the modules in PGMA to the OPM program, PGMB, is still considered a dynamic call. The call syntax in the language would identify the call as being a bound call. For example, ILE RPG syntax will include two separate operation codes, CALL and CALLB, to identify the type of call. CALL is the usual dynamic call, while CALLB is for statically-bound programs.
The combination of consistent rules and flexibility in the bind step enables you build an application from different languages. Figure 3 (page 56) shows an ILE program, PGMA, made up of three modules. Two of the modules are coded in C and one of the modules is coded in RPG. The calls between the modules are static or bound calls; but a call from one of the modules in PGMA to the OPM program, PGMB, is still considered a dynamic call. The call syntax in the language would identify the call as being a bound call. For example, ILE RPG syntax will include two separate operation codes, CALL and CALLB, to identify the type of call. CALL is the usual dynamic call, while CALLB is for statically-bound programs.
As the diagram shows, you can combine existing OPM or EPM programs and new ILE programs in the same application. This means you can migrate programs to ILE as it makes sense for your business to do so.
ILE lets you build up libraries of reusable parts whether they are written in- house or provided by a vendor (including, but not limited to, IBM). The days when you had to change multiple programs when the tax laws changed are gone forever. Instead, you can replace just the modules that perform those tax calculations. This opens up exciting new opportunities for AS/400 software providers and provides increased productivity for all programmers.
Immediate Gratification
Our language development team took advantage of the fact that all ILE languages share a common interface to provide you with some new programming tools that are available for any ILE language.
o The new source-level debugger makes it much easier for you to debug programs because you can view the program source directly. For example, you can watch the logic flow of the program as you step through the program code.
o ILE supplies common code for many generic programming tasks such as date/time functions, arithmetic routines and message handling.
o A set of routines is provided which you can use to control the screen dynamically rather than defining DDS. For example, a field or a window can easily be placed anywhere on the panel at execution time.
At the same time, the common interface gives the language developers the ability to use common routines for compiler development. For more information on the compiler modules, see the sidebar, "On Underlying Structure."
In addition to the changes that are generic to any language that supports ILE, each of the ILE languages is an evolutionary step above the languages used today.
o The ILE RPG language, which some people refer to as RPG IV, is the logical extension of the current RPG/400. Some of the new features we plan to include in ILE RPG are: 10-character names, larger field sizes, mixed-case source, logical and arithmetic expressions, date, time and timestamp fields and operations and a new definition specification. For more information, see the "RPG Futures" sidebar in "Software Announcements: Client/Server Strategies," MC, March 1993.
o The ILE C language includes a CHECKOUT compiler option that performs additional checks for common programmer errors. Many errors which pass the compiler tests and are currently found during testing can be caught by the CHECKOUT option. This helps the programmer detect errors earlier in the development cycle. Support for a packed-decimal data type allows C programs to easily manipulate packed-decimal data. This data is commonly found in AS/400 database files or passed from an RPG or COBOL program.
o The ILE COBOL language will include additional ANSI 85 high-level functions such as nested programs and alternate record keys.
A Bridge to the Future
One of the most important reasons for developing ILE is to give the AS/400 the opportunity to grow with the changing needs of the computer industry. It is the foundation for future programming language enhancements such as object- oriented programming (OOP).
I believe ILE will enable the user programming community to develop more and better applications for the AS/400, contributing both to your success and to ours at IBM. I hope I have given you some insight as to why you should invest the time to learn about ILE and what it can do for you. I'll join you here again with more details as the release dates for ILE and the ILE languages approach.
Mark Stankevicius is IBM's manager of AS/400 Programming Languages Planning and Strategy. He has been working at the Toronto Laboratory for the past 10 years in the area of compiler development and is actively involved in the planning of future enhancements to the AS/400 languages. He is a regular speaker at COMMON on the topics of RPG/400, C/400 and AS/400 languages in general.
On Underlying Structure
One of the hidden parts of the new ILE compilers that are being introduced is the underlying structure that allows the Toronto Laboratory to reuse common code to build multiple compilers. If you were to look at the pieces that make up the compiler, you would see a structure that resembles the right-hand diagram in A1.
One of the hidden parts of the new ILE compilers that are being introduced is the underlying structure that allows the Toronto Laboratory to reuse common code to build multiple compilers. If you were to look at the pieces that make up the compiler, you would see a structure that resembles the right-hand diagram in Figure A1.
At the top of the diagram, you will notice three different language compilers. We refer to these compilers as the compiler front ends. The front end is the part of the compiler that makes sure you have a syntactically correct program. It is not platform-specific. We can actually use the same front end for the AS/400 as well as for the RS/6000. The front end generates an intermediate code called W-code, which is also not platform-specific. The back end of the compiler takes this W-code (regardless of the high-level language) as input and generates the new machine interface (MI) for the AS/400. This back-end part of the compiler is built for a specific platform, such as the AS/400, and generates code that will work on that specific architecture.
This approach allows us to react more quickly to customer requirements for language enhancements and new languages. We are able to port the front end to other platforms to provide the language rather than write the whole compiler for every platform. At the same time the common AS/400 back end helps shield the compilers from some operating system changes. We can make the changes once in the back end, rather than several times for every front end. The savings we get can be translated into additional enhancements or new languages.
Finally, as the diagram shows, the new MI is used as input to the ILE translator and generates an AS/400 *MODULE object. The ILE translator is an optimizing translator which tunes code for peak performance on the AS/400 architecture. These modules can then be bound by the module binder to create the executable program object.
Contrast this structure with the current AS/400 compiler design shown on the left. Each compiler has far more language and machine-specific code greatly increasing our maintenance burden.
The Integrated Language Environment (ILE)
Figure 1 AS/400 Language Support
Existing Existing New Languages Languages Languages PRG/400 C/400 ILE C/400 COBOL/400 PASCAL ILE RPG/400(SOD*) PL/I ILE COBOL/400(SOD*) CL EXTENDED PROGRAM BASIC MODEL (EPM) ---ORIGINAL MI-----------------------NEW MI------ || ||ORIGINAL PROGRAM INTEGRATED LANGUAGE || MODEL (OPM) ENVIRONMENT (ILE) ||[ORIGINAL TRANSLATOR] [ILE TRANSLATOR] -------------------------------------------------- -------------------IMPI------------------ || HARDWARE ----------------------------------------- *Statement of Direction
The Integrated Language Environment (ILE)
Figure 2 Combining Modules With Static Binding
Source File A *MODULE RPG RPG *PGM source---------CRTPRGMOD-----module------ | | Source File B *MODULE ||--CRTPGM-- IL || PROGRA RPG RPG | source---------CRTPRGMOD-----module------
The Integrated Language Environment (ILE)
Figure 3 Mixing Static and Dynamic Binding
PGMA PGMB ILE RPG PROGRAM module----------------> OPM MOD1 RPG/400 / program C C module module MOD3 MOD2
The Integrated Language Environment (ILE)
Figure A1 AS/400 Compiler Structure
EXISTING MODEL: C RPG COBOL compiler compiler compiler || || || || || || || || || || OLD MI (machine interface) | | OPM <---------- Translator ---- | | *PGM ILE MODEL C RPG COBOL compiler compiler compiler || || --------------------------------> W-code | | Common AS/400 <------------------ compiler back end ----------------> | | NEW MI (machine interface) | | ILE Optimizing <----------------- Translator ----------------> | | *MODULE | | Other modules | || || Module <---------------------- Binding ---------------------> | | *PGM
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online