Among all of the articles we have written, none have elicited as much response as those pondering the future of RPG. Interestingly, outside the AS/400 world nobody even cares. The rest of the world views RPG as an anachronism of programming. Looking to the future, we see an inevitable amalgamation of these two universesRPG and ROW (Rest of World). Will it be a union or a collision? What should you be doing today to prepare? Is it even a programming certainty?
RPG is not simply a programming language. It is a programming system. It includes a unified data dictionary, editing tools, screen design tools, simple transaction tools, reporting tools and debugging. RPG also has a highly integrated system for programming, which removes the complexities of transaction programming, interactive dialogs, communication sessions and reporting.
This programming system is tied inexorably with IBM’s OS/400 operating system itself. Furthermore, it is directly integrated to database management, system security, systems management, recovery and more. Going one step further, legacy AS/400 systems once consisted of hardware expressly architected to host the OS/400 operating system, and by inheritance, RPG.
As one programming system component becomes intertwined and integrated with the next, we see why AS/400 programmers have always held the notion of being “native” in high esteem. Native means to use the AS/400 programming system in the way it was intended, and thus leverage the entire AS/400 computer system. However, native is also a politically correct way of saying proprietary. Not only is the AS/400 programming system proprietary, we joke that it is fair to consider it “the mother of all proprietary systems.”
Nonetheless, it is so good and integrated that it beats the productivity, maintainability and performance of a commercial application built piece-meal on any other platform.So strong is the AS/400/RPG development foundation, that during the 1970s and 1980s no other hardware providers could match it. I have found through my experience with other platforms, (HP-MPE, DEC VAX among others), that the only way for other system users to come close to the productivity levels associated with AS/400 is to use 4GL tools from third-party vendors.Procedural programming gave way to component-based development
Openness Undoes the RPG Paradigm
The push toward open systems is a direct response to the fact that many commercial IT customers felt trapped. They were tied to specific vendor and hardware platforms whether they wanted them or not. Worse yet, software vendors who wrote applications became committed to specific hardware platforms, whether their customer wanted them or not. This has resulted in lost sales and opportunities because customers wanted to choose hardware platforms based on their own strategies, and partners wanted to offer their application software on the platform of choice for customers.
The norm in the early 1980s, within commercial computing, was to use a proprietary system of some sort: Wang, Data General-AOS, HP-MPE, DEC-VAX, S/36 or AS/400. Portability, interoperability and openness were foreign concepts. They were “trapped” on the platform, and faced big problems when dealing with expansions, mergers, acquisitions and enterprise application integration. Business was pushing toward openness.
Initially, many customers and partners alike felt that the solution to openness would be portability. Portability seemed to mean the C programming language coupled with the Unix operating system. Portability would simply mean that if a customer desired a solution on a different platform, they could pick up the source code and recompile it somewhere else. Sounds nice, but in truth, it never really worked that way for any applications written in the 80s. Why?
Let me assert several principles, call them Mark’s Application Development Rules.
Rule #1. Software works best on its mother platform.
If you follow this principle, it means that code originally written for an AS/400 will not work as well on some other platform. Similarly, a direct port of say, DOS code to Windows 2000 will be trouble. This nasty effect is broken only once the application is written to a platform-neutral “mother architecture.” This is the clue to why openness is not just simply a matter of porting.
Openness is a matter of breaking up the application into a minimum of three distinct components where access and usage of the components is permitted through open software interfacesso called “open standards.” The components must be available or portable across platforms. The acceptance of these open standard interfaces allows for the interchange of their hardware engines and software vendor specifics.
Even RPG has evolved to support open systems. Client/server forms of RPG such as VisualAge RPG, allow clients to communicate with the AS/400, RPG and database servers. Future versions of RPG will include the ability to generate byte stream from the same syntax, enabling RPG to be used to program Web applications. But none of these technological tricks eliminate the need for the restructuring/rearchitecting of existing applications. This means that RPG can participate in an open world, but not without cost.
|The three minimum components are:|
|Data||ODBC, OLE-DB, SQL-CLI|
|Process Logic||EJB, MQI, Stored Procedures|
|User Interface||HTML, XML, ICA, 5250|
Today, the user wants the flexibility to place their data on any hardware platform within their IT organization. This data should be accessible from any approved application, user and location, with appropriate reliability, security and integrity. Furthermore, there is a general corporate goal to obtain a “single version of the truth”eliminating data redundancies, synchronization problems, integrity issues and multiple definitions.
The standard for databases today is a relational, SQL-compliant model. The optimization of this database comes from appropriate database design and utilization of important functions such as referential integrity, triggers, stored procedures, two-phased commits etc. Full usage of RDBMS saves enormous programming and maintenance efforts and increases the integrity and reliability of associated applications.
Access to the database comes from open standards, which are independent of hardware or software vendor. This data access middleware, which makes a database open, includes SQL CLI (Call Level Interface), ODBC (Microsoft’s Open Database Connectivity), JDBC (Java Database Connectivity), and OLEDB (Microsoft’s Object Linking and Embedding Database).
An AS/400 customer will soon realize that all they need from a data perspective is right under their noses. It is DB2 UDB for the AS/400. It provides the customer every aspect of data management needed. Unix or Windows NT customers have to select and procure such an offering separately (DB2, Oracle, SQL Server, etc.). The only thing you need to do is educate yourself, and put in place the appropriate plans to use and exploit what you already have.
The full use of the DB2 UDB for the AS/400 is independent of the programming languages chosen. So, RPG applications today and in the future can easily access such well-defined data. But to re-engineer an RPG existing application to fully exploit DB2 UDB, even if it will continue to be RPG, will mean significant “untangling” of data and process.
Rule #2: Your database is your key strategic IT asset. Design it well, exploit its features and carefully engineer access to it.
Process logic defines what happens in case of a user event or data condition. Simply speaking, this is programming to define a logical unit of work. Today, we try to separate this code from the data, user interface, infrastructure and underlying communications. It now defines a singular business process. This can relate directly back to an object-based business model (such as an entity relationship diagram). Because the process logic is independent of data, the logic becomes highly reusable in other and similar situations. In object-oriented terms, this is called “polymorphism.” In actual fact, it ends the old-fashioned practice of copying source code (resulting in inflated lines-of-code counts) and starts the process of reuse of software business components.
Where does the process logic execute, on the client or on the server? That is up to the application designer. This is a fairly serious architectural decision as it heavily impacts performance, usability, security and data integrity. What programming language is used to define the transaction is open for debate, and we’ll address this later on.
Older generation 3GL languages such as RPG have morphed themselves into being capable of delivering open/standalone, reusable business logic that is independent of the user interface and database server. This is a complement of ILE, the Integrated Language Environment of the AS/400.
What has become more interesting is the design, use, and reuse of transaction/process logic that is portable across business application and business boundaries. These should be developed to be platform neutral (the big thrust behind Enterprise JavaBeans), and designed so that future applications need to use only code and may be built up from software components that come from a variety of sources.
Rule #3. Some day you will be assembling applications from components.
This is simple. Nobody procedurally programs a commercial GUI any more, whether client/server, Web, Microsoft or Network Station. A user interface is designed and the code to reflect this user interface is either generated by a tool or interpreted by a run-time environment.
In fact, the user interfaces themselves are considered to be “forms,” and directly reflect a type of common business object everyone understands. No one uses programming languages to create these: People use “visual” tools to define such forms. Often, especially in the Web environment, programmers are more accurately graphic designers. Programming skills are not required for user interfaces anymore.
When there is no programming logic associated with the interface, the future tells us that almost any tools will do, for example, Flash, MS Word, Lotus Notes or Excel.
When programming logic (process) is involved, you go to another type of tool that incorporates a scripting language that defines the actions to be taken for particular events. Because an event is something like a mouse click, we often refer to this type of environment as “Event Driven Programming.” The relationship between visual tools and development language is often self-evident:
Rule #4. The user interface is very important, but which tool you choose to build it is not.
|Inprise Delphi||Object Pascal|
Why Does this Undo RPG?
The trend toward decomposition of applications into three layers, coupled with open middleware does not blend well with the monolithic model of RPG. For RPG, all components of the application are intertwined in the program itself. There is no separation, no middleware and especially no way to move the entire system to any other platform with the same effects. There is no polymorphism, inheritance and other characteristics of object-oriented programming. The best we can do is to have “structured” programs.
Thus, any true effort to modernize an existing RPG application will eventually involve a lengthy, tedious job of untangling data, logic and user interface, even if you use RPG in a client/server or Web format for the new and modernized version.
E-Business, Collaboration, and Business Intelligence: RPG No-Can-Do
The new types of applications in vogue today carry new technological baggage. E-business applications do not work well unless they propagate the advanced graphics of Flash, the platform independence of Java, the Web standards of HTML and the advanced data/graphics interaction of XML. Nor do they perform well if e-business transactions lose their integrity because of network problems. They can’t possibly fulfill their promise if authentication, secure sockets or encryption are not included in their development. The programming to provide proper, secure bank transactions over the Internet is nightmarish. Why bother if you have Net.Commerce, Net.Data and WebSphere?
Programming collaborative applicationsones that use loosely associated data, messaging primitives, involving workflow and data synchronizationis incredibly difficult. Why bother with RPG if you have Domino?
Business Intelligence calls for altogether new computing models using Online Analytical Processing (OLAP) and not OLTP. This calls for nifty things such as data extraction, data transformation, data propagation, data cleaning, metadata, star schemas and data refining. Have you tried this with RPG lately?
The point here is that RPG performed well to help deliver commercial OLTP and batch solutions. Today’s new applications, however, are different in nature, and require a new set of tools.
Rule # 5. You don’t have to rewrite perfectly good RPG applications using the latest tool: You’re supposed to evaluate new application requirements against the tools best suited for them.
Chances are, Domino would make a lousy order entry replacement for your 5250 systems used by the order clerks today. What about the help desk, the sales tracking system, or the e-commerce system?
AS/400 Hardware Trends: the Nasty Reality of Interactive Feature Cards
We note that in the olden days, the entire AS/400 computer system, from the hardware up, was designed to run RPG. Now, you actually get punished for doing so. Today, the hardware inside an AS/400 has much more in common with other IBM systems—some sources say up to 85 percent commonality. This includes processors, system enclosure, power supply, fans and internal disks.At some point in the near future, the entire system may be shared across IBM servers (RS/AS). It would be stretching the truth very thin to claim the AS/400 hardware today is geared to RPG applications. Similarly, all that is new with the operating system (OS/400) is geared to e-business and standards. Look at V4R4 enhancements for TCP/IP, HTTP, Client Access, Integrated Netfinity Servers, Domino, VPN, etc. How much proportionally is being spent on 5250 interfaces and RPG?
IBM seems more interested in investing to punish AS/400 users for using RPG and 5250 interactive applications. Yes, the Interactive Feature Cards (as they are known on the AS/400) are a chargeable necessity if you want to use your AS/400 for anything more than the minimum number of interactive CPW cycles (CPW, or Commercial Processing Workload is a sort of horsepower measurement of the AS/400 relative performance capability). Using a single such CPW for a 5250 (Native/Interactive) function will cost more than four times as much as using it for open systems functions.
Rule # 6. You don’t get rewarded for going “native.”
Procedural Programming Gives Way
Application development using components is evolving in much the same manner as procedural code evolved, albeit at a more accelerated pace. Where procedural code, linear code written line by line, took 40 years to evolve, the component-based industry is relatively newcertainly less than five years old.What do we mean by procedural code, and what do we mean by component-based development?
Procedural Development: the Old Way…
Procedural code evolved from basic machine languages to second-generation language (2GLs) such as Basic Assembler Language (BAL), to third-generation languages (3GLs) such as Common Business Oriented Language (COBOL), to 4GLs such as Progress and many other variations of advanced development tools. Many of these advanced development tools used what were called components, but these components were essentially pieces of procedural or linear code held in procedural libraries.
Model-based application development tools ask you to model your data and business processes using their own or, in some cases, a third party’s modeling tool and they would generate the application for you.
These advanced tools were, and will remain, very powerful application development environments that will continue to save time and money in development. Unfortunately, they tend to be proprietary. You have to wait for them to evolve before you can take advantage of new technology introductions such as graphical user interfaces and Internet enablement, just to mention a couple of the more obvious and painful ones. In fact, it is still relatively common to hear stories of IT environments that have yet to move in these directions because they are being held up (some would say held hostage) by tool vendors.
Components can be defined in many ways and can even be used to describe common procedural subroutines or copied code. But for the purposes of this discussion, we are going to define components as those that subscribe to object-oriented technology. These components may be pure object technology, or in fact, procedural code “wrapped” to appear as object-oriented.
How do you tell the difference? Just ask yourself: Can the object be modified using traditional object-oriented techniques (true OO), or do you use the object as is (a sure sign of wrapped procedural code)?
Another aspect we must consider is just what a component is—more specifically we now want to focus on business components.
What is a business component? These are elements business people recognize as being important to their business. It can be a basic object such as “person” that can be further subdivided into “customer” or “supplier” or “employee.” It can be a more sophisticated object such as the common business object “address.” What’s sophisticated about address? Consider: Is it a mailing address or physical location? Is it a single location or does the business have many locations? Where does the postal code fit? This depends on where you are in the world; it may be at the end, the beginning or the middle of an address.
Doing business over the Internet on a worldwide basis makes all of this painfully important and highlights the limitations of our current application portfolio. A business component may be very large, typically called a business process component such as “invoice” or “payment” or “back order.” These very large components are made up of basic objects, common business objects and even other business components. Another characteristic of business components is that they must work together and interoperate with infrastructure components.
Why Object Oriented Now?
Object Oriented Programming was developed back in the mid-1970s. You may ask: If it’s so great, why doesn't everyone use it today? What if everyone used it today? How would the world be different? Object technology is highly flexible, adaptable and easier to maintain. It’s also difficult to get it right the first time and was initially very expensive to redesign and rework existing applications. Not to mention the enormous compute power (by 1970 standards) that it took to run object-oriented applications.
Timing is everything. Like many technologies, the compute power, technical infrastructure (operating systems and middleware) and basic agreements among interested parties (standards, both agreed to and defacto) were not there yet. They are today.
With Y2K still fresh in our memories, “So what?” would have meant literally billions of dollars that businesses might have saved or redirected to more profitable pursuits. Using object technology, we could have modified the single date object in our application system and it would have essentially been recognized by all the applications using it.
A Case for Openness on the Server Side
Standards are important, both official and defacto. Standards foster interoperability. Look how Microsoft has provided on the client a set of easy-to-use components that have given programmers an ease-of-use we only dreamed of 25 years ago. Client-side developers around the world almost universally accept Microsoft components.
Unfortunately, the server side of the equation is not so well ordered. There is such a mix of environments that even if you were fortunate enough to have a single IT vendor, chances are they would have a mix of incompatible hardware, operating systems and middleware.
Java, introduced about five years ago, has enjoyed dramatic acceptance by developers and product vendors. Why? It is both a language and an environment that delivers on the promise of running application across a variety of platforms. While we did have middleware, remember: True portability is only attainable once the application is written to a “mother architecture” that is platform neutral.This is Java!
Java gives a sense of openness that has become a rallying point for many application developers. Java is an excellent object-oriented programming language. It has the best features of Smalltalk and C++, but minimizes the problems of those languages. In rapid succession came JavaBeans and Enterprise JavaBeans.
JavaBeans provide a standard way of describing objects that, in turn, allowed tool vendorsprimarily advanced procedural tool vendorswith a way to use these objects and deliver more interoperability. A JavaBean component industry was born that brought about easier development and modification.
The Enterprise JavaBean initiative is no less important because it provides a common interface to object services—the middleware needed to access any platform-independent business processes. Application developers and tool vendors not only can mix and match JavaBean components from various vendors, they are now able to mix and match the middleware services that best suit their needs, without sacrificing the portability that Java delivered.
Who are the component developers and tool vendor?
The good news is that they are for the most part the same people who brought you the predecessors, the middleware, and the advanced application development tools. If you made a commitment to advanced development tools, then ask your vendor about object technology and Java. Some already have products in the market, others are in development, and still others are developing plans to migrate to this technology whose time has come. If you are considering moving to an advanced technology tool, a word of caution: Make sure you choose a vendor committed to openness. You don't want to be trapped with a commitment to a single tool vendor for all your application development support.
One of the leading vendors in building common business object and business process components is IBM. IBM has a deep understanding of object technology and has been introducing it into its operating systems and middleware for many years, and OS/400 may be the best example of this. It has also been a leader in the development of business object and business process components. The San Francisco project is probably the best example of this commitment, with over five years of development experience invested.
Ultimately it is you, and you alone, that must make the choice to embrace the future. If you do move forward, we offer you these tips to prepare yourself for the future of application development.
1.Understand the importance of separating database elements from the existing application. Build an enterprisewide data model that exploits the full features of your SQL compliant RDBMS. Provide access to this data via commercially accepted data access middleware.
2.Use GUI standards for new applications. Pick the tools that suit you best (as long as they are open) and use them.
3.Build a strategy to use Object Oriented application development along with open system standards. Users of IBM systems must actively consider Java, and products such as WebSphere.
4.Prepare for the eventuality that you will be able to build applications from components and piece parts.
No one can argue against the effectiveness that RPG has brought to the traditional world of AS/400 applications development. But, survival in the post-RPG world requires an understanding of object-oriented technology and the revelation that Java might just be in your future.