Way back before the dawn of time (well, 1984, actually) when I first got involved in programming on the IBM midrange platform, RPG was where it was all at. In fact, the RPG geeks of the time insisted that the only way to programme was with the processing cycle, and everything else was just poor coding.

Since then, we’ve had code generators, 4GLs, C++, Delphi – but most of the core systems are still in RPG. So what’s wrong with that? Well, from where I sit, RPG is still relevant – but it’s not ideal for programming for browser integration, or multi-tiered applications – or to make use of emerging standards like XML, and extensible HTML (XHTML).

The development environment now finally seems to be shifting away from RPG and towards Java. In this article, I will briefly look at Java, and how it works by investigating some of the differences between RPG and Java, as well as the similarities. With RPG III, life was simple. A well-written source member consisted of a number of sub-routines and a main procedure compiled into a programme (*PGM), and a job consisted of a CL *PGM that typically called one or more RPG III *PGMs.

The move to RPG IV bought us into the world of ILE, where source members compile into modules (*MODULE), multiple *MODULES are bound into *PGMs, and then linked to service programmes (*SVRPGM) which allow for re-use of binary objects without recompiling. Using RPG IV, a job consists of an activation group, in which a CL *PGM can call a main RPG *PGM, which in turn will utilise helper *SRVPGMs. These are called using calling procedures, which allow local variables, return values, the passing of parameters, recursion and so on - so the *SVRPGMs can be thought of as grown-up subroutines. So RPG IV and ILE come close to the model that Java uses, with re-use of code and modularisation of processing into discrete chunks.

In Java, being fully object-oriented, we start with a class, which is a template that describes the object, the object’s visible and hidden portions, defines the variables and defines the methods for that class. As an RPG programmer, I don’t understand a word of that last sentence, so let’s use a table to translate to RPG IV:

With this, we can now start to see the similarities between RPG IV and Java. In RPG IV the main *PGM will call a *MODULE which will set up variables, and then execute a number of procedures which will in turn set up variables and then execute RPG C (calc) specs to perform a function. In Java, the same thing happens – the main .CLASS will call a secondary .CLASS which will set up variables, and then execute a number of methods which will in turn set up variables and then execute Java code to perform a function. Once the .CLASSes are created, they can be included in a package, which will contain a number of .CLASSes, including both home-grown ones and standard functions. ‘package’ must be the first statement in the definition, and acts like a complier directive.

So Java and RPG IV have some similarities in the way they compile and run. However, as languages they are quite different. I don’t intend to cover all the differences in this article, but just to look at some of the main points, to give a flavour of the language in RPG terms.

Unlike RPG, Java is completely free form. All white space is ignored – which can make for some clarity of coding, but means that some standards need to be imposed. The language syntax is very ‘C’ like – semi-colons end each statement, braces (‘{‘ and ‘}’) are used to delimit scope blocks, at the beginning and end of methods, and at the beginning and end of classes – so the braces are nested – and names are extremely case-sensitive.

Data types

Data types are different, too. In RPG, they can be broadly split into two types, numeric and non-numeric. Numeric types are binary, integer, float, packed, unsigned and zoned, whilst non-numeric types cover things like character, date, graphic, indicator, time and so on. In Java, there are a number of Primitive Types of data. These can be split into Boolean and Numeric – and Numeric can be further subdivided into Integer and Float. Integer types are byte, short, int, long and (because it is a Unicode type) char. Float types are float (32bit) and float double (64 bit). So there is much more flexibility in the Java primitive types, particularly when you take into account the ability to do things like assigning a value to a Boolean – for example:

To set a Boolean - boolean myInd = true

However, consider – Boolean myInd = (count > 10)

then, if (count > 10)… OR if (myInd)… will both be the same.

Mainly as a result of the problems of precision with ‘fixed decimal’ numbers there is no packed decimal data type in Java, however a class, BigDecimal, exists to cope with large numbers – it is a software simulation of fixed decimal numbers and can cope with very large numbers and the full complement of mathematical operators. Unsurprisingly there is also a class BigInteger. Incidentally, having said that there were differences in data-types between RPG IV and Java, it is worth noting that since V4R4 RPG IV has supported all the Java Primitive Types.

When it comes to operators, Java has a corresponding set to match RPG on a one-for-one basis. To access database files from Java, remember that a file will be a public class – the simplest way to access the data is via SQL to return a CSV file. There are also some predefined classes for stream I/O, for example System.

RPG is not a true Object Oriented language – it does not fully support Encapsulation, Inheritance or Polymorphism. What do these terms mean? Well, encapsulation is the ability to put fields, variables and code together into a ‘black box’ that can be re-used – in Java terms, a Package, and in RPG a service programme. Inheritance is where a child class extends the parent class, inheriting all the methods and variables of the parent while adding its own – and possibly over-riding some. RPG does not have any real elements of inheritance. Polymorphism is a term that defines the situation where calling the same method against two different objects will have different results depending on the class of the object – in RPG, the WRITE opcode is a good example, as it does different things dependent on the file type.

So, that was a quick overview of the language – for more information, do some searching on the Web – there are a number of basic on-line Java primers and courses to get you started (try http://www.hitmill.com/programming/java/primers.html for starters).

Direction finder

Where is Java used today on the iSeries 400? To begin with, Java was used to produce GUI interfaces to replace green-screens and applets that downloaded via the browser to the client machine, but as the Java environment has matured, server Java strategies have moved to the fore. These can be in the form of tools and toolsets such as JavaBeans or Java Server Pages (JSP), coding and communication techniques such as servlets and Remote Method Invocation (RMI) (which allows multi-tiered applications to run across a variety of platforms and servers) or complete development environments such as VisualAge for Java, which can utilise Enterprise Java Beans and in-house Java classes to produce a complete application. However, most of these need to run in a Web application server environment, such as WebSphere. For a full discussion of Server Java Directions, see Sharon Hoffman’s article in the April 2001 edition for News/400, page 25. (also available on-line, article 9616).

Where would you use Java in your installation? Well, I don’t recommend rushing out and re-writing your ERP system in Java tomorrow, and if you want to add a simple Web front end to your existing business logic, Net.Data is a quicker and simpler route than Java. However, if you need good performance and complex integration in your Web-facing applications, or are developing a proper e-commerce environment, Java is the way to go. And as we have seen, it is part of an evolutionary process for RPG developers, and is a development environment that will continue to grow, and to attract developers. I don’t think even the most die-hard RPG proponent can claim that RPG is attracting development effort and innovation… although it’s not dead yet, as we have seen in V5.

Until now, the main use for Java on the iSeries has been to build Web-enabled applications, but as functionality in these applications increases it is becoming harder to identify which part of the app is the Web-facing part and which part is application main-line code. As this happens, Java developers are being forced to address the mainstream issues of security, performance, data integrity and application design. As these issues are solved, Java will become the main development environment on the iSeries, so now is the time to get on board.

Stephen Way is midrange controller of the IBM CUA and a senior IT manager with a major British multi-national manufacturer, responsible for iSeries and AS/400 systems on three continents.

steve@way.org.uk