Wanted: Native RPG and COBOL Support for Browsers
March 23, 2005 Brian Kelly
Back in the 1990s, when client/server was the big thing, the AS/400 was missing from the party. IBM Rochester’s position was that customers could get that type of system from the company’s PC line of business. At about the same time, when the Internet was the next big thing, IBM Rochester’s position was that Internet facility was already provided in the server line by the RS/6000 Unix box. Again, the AS/400 was conspicuously absent from the party. And that party is still going on!
Louis Gerstner, IBM’s former chairman and CEO, coined the term “server-centric” before he coined the term “e-business”. When Lou looked at his inventory of server products, as a former CEO of a cookie company, he knew that IBM servers should be able to function as the server part of client/server. After all, that was what server-centric meant. He also correctly assessed that without Internet capabilities, two of IBM’s server lines would be irrelevant in just a few short years. Before his first year was finished, to leverage IBM’s server business, he directed that all server divisions be able to support both client/server and the Internet, and he said further that IBM’s customers ought not have to pay extra for that support. Lou Gerstner is a smart man.
Just two server divisions were affected by this decision. From 1994 on, there was a scramble by the S/390 Division and the AS/400 Division to add client/server and the Internet to their respective platforms. To get the job done, IBM picked the lab in Endicott, New York, to write the TCP/IP software for both systems. Armando Fratezi, an IBM folk hero when Internet products were finally released, at the time carried the title Internet Architect. His mission was to make it happen.
In early 1994, I was employed at Marywood University in Scranton, Pennsylvania, and we were evaluating Windows and Unix options for the Internet. Armando drove from Endicott to a meeting at the university. At the meeting, he previewed the coming Internet facilities and shared with us that the free Endicott-developed TCP/IP stack was running eight times better than the $20,000+ AS/400 product that it was replacing. He also noted–but swore us to secrecy–that TCP/IP was running better in the mainframe project than IBM’s proprietary SNA data communications protocol. He winked and said that the mainframe people do not want to hear that.
After a few years, just about all the well-known TCP/IP applications were running on the AS/400. IBM had done a great job catching up, but there was still one thing missing. There was no natural way for a typical AS/400 program to talk to a Web browser. IBM had built CGI capabilities into the TCP/IP product, but that was a long way from the ease of development to which AS/400 shops had become accustomed. Yes, it worked with RPG, but the non-conventional code to support the browser took about ten times more lines of code than the standard RPG in the same program. So, Web programs were about 11 times as large and were about twenty times more difficult to write than standard fare AS/400 programs.
AS/400 shops responded to the perceived difficulty of Web application development by letting the Windows and Unix guys in their shops run the Web.
In the late 1990s, as IBM was again tuning into the fact that the company made four different servers, Sun Microsystems was making hay with a new programming environment called Java. So, rather than exclude the AS/400 from the Java mix, IBM included the AS/400 in the mix, bigtime. Arguably, today’s eServer i5 (the fourth generation System/38 or the third generation AS/400, depending on how you want to look at it) is IBM’s finest Java platform. With such a fine implementation, IBM decided that Java would be the tool to get AS/400 development shops to the Internet. Who could ask for more?
Well, we could.
Just like all servers are not equal, all programming languages are not equal. The best analogy for this is the spoken language. All spoken languages are not equal. And learning a new language has lots to do with the language you currently speak. For example, it is more likely that somebody conversant with a Romance language, such as Italian, would be able to pick up another Romance language, such as Spanish, far more easily than somebody who speaks a West Germanic language such as German. Moreover, it is more likely that somebody conversant with a West Germanic language, such as Flemish or Dutch, would be able to pick up German far more easily than somebody who speaks Italian. It just makes sense.
There are similarities in comparing programming languages with spoken languages. Just as there are major linguistic and syntactic differences between the Romance Languages and the Germanic Languages, there are major differences between the block structured computer science programming languages and the English-like business programming languages, also known as the report writing languages. Java, Pascal, C, and C++ can all be classified as block structured languages, whereas COBOL and RPG would fall under the business report writing languages classification. (The C++ crowd refers to these languages as “card wallopers,” referring to their heritage in punch card machines–as if there was something wrong with this. As if you could look down on ancient Greek or Latin.)
Java, a block structured programming language with an extra wrinkle of difficulty, namely an object orientation, was chosen as the language to lead the OS/400 community to browser Nirvana. The only problem was that most of the OS/400 community could not speak in a block structured tongue, and very few, if any, knew anything about object orientation. Instead, most members of this community spoke and reasoned in a business report writing language known as RPG. Those of this ilk who did not speak RPG spoke COBOL.
But, IBM had done such a wonderful job of bringing Java to the AS/400 that the company stood firm in its declaration that Java was the way to the Web for OS/400 shops. OS/400 shops stood just as firm in their refusal to accept Java as the way to the Web. For most, the transition to a new type of language was seen as too high of a price for participation in Web development.
Many smaller AS/400 shops had come from a System/36 heritage and these shops in particular were not easily led to new technology, particularly if they believed that what they already had was superior. When IBM announced the AS/400 in 1988 as the replacement system for the System/36, for example, a large number of these shops stubbornly clung to their old System/36s and refused to move to the new AS/400. It was not until IBM added a System/36 emulation environment and made changes to OS/400 in the 1990s that made it more like their System/36s that this group began again to embrace new technology. IBM ameliorated holdouts further by announcing the AS/400 Advanced/36, which was the first 64-bit, RISC server IBM shipped; it allowed System/36 programs to run untouched on the new hardware.
In the mid-1990s, as IBM noticed that not many AS/400 shops had taken the call to the Web, the company decided that it needed to make it easier. IBM announced the AS/400e servers in 1997 (the “e” was short for e-business, and then renamed the line to the iSeries in 2000. As these changes were taking place, IBM worked on refining a PC-based Intelligent Development Environment (IDE) using open source technologies known as Eclipse. At the same time, the company was wrestling with the right way to bring out a Java servlet server to host the applications that were expected to be brought forth from the new iSeries Eclipse developers. After a few false starts, IBM settled on a subset of its WebSphere product called WebSphere Express to serve as the engine to get all this new Java code and WebFaced applications onto the iSeries platform. Again, though the same tools as other platforms were made available for the iSeries, and the tools were improved with an affinity for the iSeries, just a small handful of AS/400 developers took the bait.
I have written nine books about various WebSphere topics since 2001. There are a few others out there who have also written books about WebSphere. To put it bluntly, none of us are making close to a living on our books. WebSphere and Java, and even the Eclipse IDE, as good as they may be in other server shops, are viewed as foreign in most iSeries shops.
iSeries shops code in business languages, not computer science languages. The baby boomers who run the iSeries shops today chose the iSeries way of life to be free of the complexities of computer science nuances in operating systems and programming. They chose to concentrate on solving business problems. Since 1969, with the introduction of the System/3, these shops have been writing programs in RPG and COBOL and they see no reason to abandon their ways today just because IBM has a great Java environment and a great WebSphere servlet server to host those Java servlets.
To understand the motivation that iSeries shops have to keep things iSeries-like, you need look no further than the programming languages they use and those that they are being encouraged to use. It is far beyond the scope of this article to do a full comparison of the block structured languages C, C++, and Java against the business languages, COBOL, and RPG. However, it is easy to differentiate the two based on the intended use factor.
C, C++, and Java were written by computer scientists for computer scientists. For many systems, C, for example is the language in which the operating system is built. (It is, in fact, the third try at a compiler created by AT&T ‘s Bell Labs to in turn create an operating system that we now know as Unix; the A and B compilers were not so great.) A programming language that can be used for building an operating system is, by definition, low-level and not friendly to business programmers. Java is similar in form, but it does not have certain attributes that enable it to talk directly to hardware as C does. However, its look and feel for a programmer used to block structure languages is very similar. The fact is, none of these languages have any appeal for a True Blue iSeries programmer.
RPG and COBOL have real names that explain their underpinnings. For example, RPG stands for Report Program Generator, a clear indication that the language was originally built to provide report writing capability for businesses. COBOL stands for Common Business Oriented Language and it has been used successfully for over forty years to provide businesses with an English-like methodology for creating business applications.
RPG and COBOL were built by computer scientists for business use, not for their own use. Nobody would ever think about using RPG or COBOL to write an operating system. Nor, would anybody use RPG or COBOL to create a computer animation such as a spinning globe in a browser panel. However, hundreds of thousands of businesses use and will continue to use RPG and COBOL to run their business. There are even rumors that Microsoft is still using some RPG programs in its own distribution business; they used to be in-house, but the word is that Microsoft outsourced the applications. There’s no shame in using RPG.
All businesses need a good business programming language to run their business. For a business programmer, for a business application, and for a business, the choice of programming language rightfully should be a business language, not a computer science language. I am hoping that IBM will eventually tune into this. The iSeries is not like IBM’s other servers. Period. It is a business server or as IBM once called it, an Application System. A business server should be programmed in a language that makes reading and writing data from and to databases, reading and writing data from and to interactive displays, and reading and writing data from and to browsers easy by design.
The last item there is the problem.
To make this happen, artifacts must be built within programming languages to make data access and interaction a no-sweat proposition. For all but the Web, IBM has achieved this with RPG and COBOL using the OS/400 platform. Now, it is time for the Web to go native.
The iSeries is the only machine in existence that has a natural compiler interface to both databases and terminals. It’s been that way for almost thirty years and though it may be old hat for iSeries aficionados, it would be revolutionary if such capabilities appeared in any other platform. From Day One, the System/38’s RPG and COBOL compilers were able to perform natural operations to databases that still require expensive and difficult-to-use products such as IBM’s IMS DB and MVS DB2, Oracle’s eponymous database, Microsoft’s SQL Server, and others. IBM built facility into the operating system and artifacts into the RPG and COBOL compilers to support database files as naturally as flat files for other platforms.
Instead of special devices, RPG and COBOL programs from the System/38 on through the eServer i5 can use Read operations and Write Operations provided by the compiler. On every other system, you first need a database administrator to install the software, and then you must use special, unnatural operands within your code to access the data. After thirty years, it still has not changed. That’s why iSeries shops don’t want to use languages that make their job more difficult.
Now, the same goes for interactive terminals or PCs pretending to be terminals to the iSeries server. On other platforms–Unix, Windows, or mainframe–you must first buy another product called a transaction processor (Tuxedo or CICS) in order to use terminals for business transactions. Of course, you also need a certified engineer or a systems programmer to join the capability to your operating system. When you are all done installing the software, you then have to make it all work. Developing software in this environment has many challenges. Writing programs for non-integrated transaction processing monitors such as BEA Systems‘ Tuxedo or IBM’s CICS is no piece of cake. It is an arduous task and the developers who work in this environment get paid handsomely for the knowledge and abilities they bring to the table. It takes much longer to write code using these add-on transaction monitors and consequently it costs lots more.
With the System/34 in 1977, IBM changed this paradigm for its midrange computers and it then employed a method similar but better than that developed for System/34 when the company introduced the System/38, the great grandfather of the new eServer i5. Rather than force users in IT shops to build terminal capability into the operating system by buying an add-on program, such as Tuxedo, IBM built it into the system itself. You get native transaction processing with every iSeries server. It’s there with no big deal and no installation work. Moreover, because the system comes with innate terminal capability, just like with native database capability, the compilers have natural artifacts and operations to use terminals as natural devices to the system.
Rather than having to embed the code for BEA’s Tuxedo or IBM’s CICS application programming interfaces (APIs) just to read or write data from or to a terminal, RPG and COBOL developers merely use Read and Write operations to send and receive panels of data to and from interactive workstations. It actually is a snap. That’s why programs are so easy to write. That’s why programmers can finish assignments five to ten times faster using an i5 than any other platform. That’s why business benefits are accrued sooner and cost less in i5 shops than any other shop in which programs are developed.
To show you what a simple RPG interactive program looks like, I have included code that I call “Advanced Hello World.” In Figure 1 below, the program is done in RPG. In Figure 2, the same program logic is done in COBOL. One of my students at the university is working this semester to write this simple application in C, C++, and Java. I don’t have it to show yet. Don’t hold your breath expecting to see it any time soon. However, I have provided a simple Java snippet in Figure 3 so that you can contrast it with the readability of RPG and COBOL. As an aside, the RPG program shown in Figure 1 took me about fifteen minutes to write after I had defined the database file and the workstation file.
1 FPANEL CF E WORKSTN
2 FLANGUAGE IF E K DISK
3 D ERRMSG C CONST('HELLO WORLD TRANSLAT-
4 D ION NOT FOUND, TRY A-
5 D GAIN')
6 C *IN99 DOWEQ *OFF
7 C EXFMT SCREEN1
8 C LANGUA IFEQ 'END'
9 C LEAVE
10 C ENDIF
11 C LANGUA CHAIN LANGUAGE 90
12 C *IN90 IFEQ *ON
13 C MOVEL ERRMSG MESSAG
14 C ITER
15 C ENDIF
16 C ENDDO
Figure 1: RPGIV Version of Advanced Hello World Program
*************** Beginning of data ********************************
.......-A+++B+++++++++++++++++++++++++++++++++++++++++++++++++++++
PROCESS
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLOAC001.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT DB-LANGUAGE
ASSIGN TO DATABASE-LANGUAGE
ORGANIZATION IS INDEXED
ACCESS MODE IS RANDOM
RECORD KEY EXTERNALLY-DESCRIBED-KEY
FILE STATUS IS MF-STATUS.
SELECT DISPLAYPANEL
ASSIGN TO WORKSTATION-PANEL
ORGANIZATION IS TRANSACTION
ACCESS MODE IS SEQUENTIAL
FILE STATUS IS WS-STATUS.
DATA DIVISION.
FILE SECTION.
FD DB-LANGUAGE
LABEL RECORDS ARE STANDARD.
01 LANGUA-RECORD.
COPY DDS-REFFMT OF LANGUAGE.
FD DISPLAYPANEL
LABEL RECORDS ARE STANDARD.
01 PANEL-RECORD PIC X(150).
WORKING-STORAGE SECTION.
01 PNL-INPUT.
COPY DDS-SCREEN1-I OF PANEL.
01 PNL-OUTPUT.
COPY DDS-SCREEN1-O OF PANEL.
01 WS-STATUS PIC XX.
01 MF-STATUS PIC XX.
01 INDON PIC 1 VALUE B'1'.
01 INDOFF PIC 1 VALUE B'0'.
PROCEDURE DIVISION.
BEGIN.
OPEN I-O DISPLAYPANEL.
OPEN INPUT DB-LANGUAGE.
PERFORM SCREEN-IO THRU EXIT-SCREEN-IO
UNTIL IN99 OF PNL-INPUT = B'1'.
CLOSE-ALL.
CLOSE DB-LANGUAGE DISPLAYPANEL.
STOP RUN.
SCREEN-IO.
WRITE PANEL-RECORD FROM PNL-OUTPUT
FORMAT IS 'SCREEN1'.
READ DISPLAYPANEL INTO PNL-INPUT
FORMAT IS 'SCREEN1'.
IF IN99 OF PNL-INPUT IS EQUAL TO B'1'
GO TO EXIT-SCREEN-IO.
MOVE LANGUA OF PNL-INPUT TO
LANGUA OF LANGUA-RECORD
READ DB-LANGUAGE
INVALID KEY PERFORM LANGUA-NOT-FOUND
NOT INVALID KEY PERFORM LANGUA-FOUND.
EXIT-SCREEN-IO.
EXIT.
LANGUA-FOUND.
MOVE CORRESPONDING REFFMT TO SCREEN1-O OF
PNL-OUTPUT.
LANGUA-NOT-FOUND.
MOVE 'HELLO WORLD TRANSLATION NOT FOUND, TRY AGAIN'
TO MESSAG OF PNL-OUTPUT.
****************** End of data **********************************
Figure 2: COBOL Version of Advanced Hello World Program
class SimpleProgram7 {
String classScopeStringVariable;
SimpleProgram7() {
System.out.println("This is the constructor for SimpleProgram7");
classScopeStringVariable = "X52.9238";
}
void tellMeYourName() {
System.out.println("This is for class "+classScopeStringVariable);
System.out.println("The name of this program is SimpleProgram7");
}
String returnYourName() {
System.out.println("This is for class "+classScopeStringVariable);
etc, etc, etc. . . .
Figure 3: Java Snippet
In both the RPG and COBOL programs, a database file named LANGUAGE is accessed to look up the translation for Hello World in German, French, and Spanish. A terminal file (WORKSTN device) named PANEL is used to write the initial panel to the terminal and to read it back. For simplicity, both the RPG and COBOL programs use the same device file (contains the panel) and the same database. The RPG program is 16 statements and the COBOL program is 65 statements. My student anticipates that the program to perform this in Java will be several hundred lines of code. Since lines of code cost money to build, it is easy to see why OS/400 programmers are more productive in batch and interactive work than developers on other systems.
The Missing Piece
So, what about RPG and COBOL and the Web? As we have discussed in this article so far, in 1978 IBM used real innovation to create a solution that was out of the box. Nobody at the time thought that anything other than card devices, tape devices, or disk devices could be brought in naturally as compiler-aware devices. These were all a programmer could hope to read or write from. With the System/38, IBM added database devices and workstation devices making programming even that much easier for the tasks of the day. With CICS and CCP as the only IBM predecessor transaction processing monitors for terminals in 1978, nobody at the time thought making a terminal a real device was even possible. So, when the System/34 and the System/38 achieved this capability with no apparent fanfare, a paradigm had been broken.
This was an unbelievable accomplishment at the time. Few in IBM at the time who had worked on the transaction monitors for terminals believed that IBM could make a system that would have a terminal as a natural device. I know that I was amazed, as were my peers in IBM. It was a wow! Could anything so significant to programmer productivity ever happen again? Can IBM do the same thing for the browser? The answer to this question, ladies and gentlemen–and particularly in 2005–is absolutely: “Yes.” However, it is clearly up to IBM.
Just today, I read that IBM upped its commitment to desktop Linux, pledging $100 million over the next three years to boost Workplace support for Linux. With so many pieces already in place to make the browser a natural operating system device and with the compiler artifacts for database and interactive processing available for use as a guide, a few million dollars here or there may be all IBM needs to pull this off. In return, IBM would gain unqualified loyalty from the masses of iSeries users who have been asking for a natural way to the Web.
If IBM were trying to move the next generation of computers (the i5) to the Web in the same fashion as the company moved the System/38 to the terminal in 1978, the accomplishment, again, would be phenomenal and it would probably remain unequaled for years to come.
Thinking well within the box, we who work with AS/400, iSeries, and i5 know that to bring this marvelous machine to the Web without moving from IBM, we must indulge in the IBM WebSphere phenomenon. Additionally, we must engage in WebSphere almost to the same level that the mainframe, Unix, and PC server shops must engage.
|
The raw facts indicate that if we, the iSeries faithful, wanted to do this as a group, we would have done it by now. We have yet to make our move and it looks like we will not be making a move any time soon. The reason is that iSeries shops feel left behind with the Java and WebSphere path that IBM has outlined for them to follow. (This is one of the reasons why IBM has recently opened up the iSeries Developer’s Roadmap to include other tools than WebSphere and RPG in addition to Java.) Consequently, many iSeries IT shops hire or permit Windows or Unix people to run the Web at their companies, since they know there is no natural way for them to engage with the tools that IBM has given them.
Will RPG and COBOL developers continue to be separated from the Web?
That is the question of the day. George Farr, from the IBM Lab in Toronto, is one of IBM’s major development managers for RPG. Farr has cautioned those looking for solutions for simple Web access from business programming languages. For example, at a recent COMMON conference, I heard him say: “There will be no enhancements to RPG/400. Get used to it.” I was taken back at such a bold statement. I thought Farr was on our side. All IBM enhancements recently have been to RPGIV, and they have made the language more like a block structured language and many of us are not pleased with these moves.
Farr’s preoccupation has been to use IBM’s precious development dollars to make RPG resemble Java rather than to add real function to the language and the operating system. Most OS/400 customers have rejected the Java notion and the WebSphere notion and they properly wonder why IBM people such as Farr are not trying to please them. Though Farr is sharp, he is not an OS/400 guy at heart. You guessed it. He is a computer scientist, and computer scientists don’t think like us. So, if IBM wanted a real project that would pay real dividends for iSeries shops, he would advocate a new browser device file for RPG and COBOL and keep the Java artifacts from the RPG language.
Using the same model as the model that proved that CICS and Tuxedo were not needed, if I were IBM , I would be working to add a BROWSER device to the RPG and COBOL language. If IBM thought out of the box in this instance, to please IBM’s real constituency instead of the Java crowd, it would assure that each display file that linked to an RPG or COBOL program would be immediately usable by the programmer merely changing the program device name to BROWSER. IBM could probably make it even easier.
Additionally, there are a few external constructs that are readily available to the Web developer world, such as Java Server Pages, and Java Server Faces, and even HTML and XML files. For the AS/400 crowd, these can be akin to the display files that link RPG and COBOL programs to terminals. So, if IBM chose to build the operating system interfaces for Web designs into the natural development process for i5 programmers, the impact on Web programmer productivity could be boosted from non-existent to five to ten times better than all other platforms. By using the same methodology as that which made CICS unneeded in OS/400 shops, IBM could build browser support into the operating system and the compilers. Programmers could then use natural Read and Write operations to send out and receive external Web constructs to and from browsers without any unnatural program code. And it wouldn’t cost IBM $100 million to build it.
If you are not an iSeries programmer capable of linking a display file to a program in an hour or less of coding and compiling, you may wonder why this is such a big deal. It is such a big deal because it can increase your productivity five to ten times over traditional tools. If you are an OS/400 programmer who uses display files to write programs that interact with users via terminals, there is no real reason why the same code that interacts with green screen terminals cannot interact with browsers. That would make working with browsers from within RPG and COBOL a veritable piece of cake.
And, oh what a happy, productive day that would be in iSeriesland!
Brian Kelly retired as a 30-year IBM Midrange SE in 1999, having cut his eye teeth in 1969 on the System/3 and later with CCP. While with IBM, he was also a Certified Instructor and a Mid-Atlantic Area Designated Specialist. Kelly takes pride in having announced the AS/400 at Marywood University in June, 1988. When IBM began to move its sales and support to Business Partners, he formed Kelly Consulting in 1992 as an IT education and consulting firm. Kelly developed numerous AS/400 professional courses over the years that range from soup to nuts. He has written dozens of books and numerous magazine articles and about current IT topics; he has also developed and taught a number of college courses and is currently an adjunct member of the graduate faculty at Marywood University in Scranton, Pennsylvania, where he also serves as iSeries technical advisor to the IT faculty.
