Java programming is fun. It is as easy as Visual Basic and fully object-oriented without being as complex as C++. However, programming more than two or three Java classes a day can cause irritability when you return to legacy application programming. I developed more than the recommended limit myself while designing the sample GUI application in this article, and, I have to say, I had quite a bit of fun doing it. Read on to see how easy it is to write a Java client/server application for the AS/400.

The sample application presented here is actually something you might find very useful. It displays the percentage of an AS/400's CPU utilization. The application prompts you for an AS/400 system domain name or IP address you would like to check the CPU utilization against. The prompt allows you to add domain names or IP addresses to a list (see Figure 1). From that list, you select an AS/400 to attach to; the application then displays a bar chart of CPU usage (see Figure 2). The bar chart dynamically updates itself with a new CPU usage percentage every 10 seconds. You can simultaneously open up a bar chart window for multiple AS/400s. The list of system identifiers in the CPU usage application window is saved and restored on successive invocations, so the user does not have to remember to rekey the system addresses.

One of the major enhancements to Java 1.1 was its new event handling model. The Java 1.1 event handling mechanism revolves around three objects: a source, an event, and a listener (for more information on the Java event handling model, see "Java GUI Programming" in Technology Spotlight elsewhere in this issue). To begin development of the CPU usage application, I created the table in Figure 3. The table organizes the Java Abstract Windowing Toolkit (AWT) component sources, the events fired by the source, and the listening classes, along with the associated functions defined to handle those events.

The driver class for the Java CPU usage utility is As400CpuUseApp (as shown in Figure 4). To say that it is the main program is incorrect. Java is completely object-oriented; there is no such thing as a program-only objects. Any class that has a public static void main() function defined may be directly invoked. You can think of the main() function as bootstrapping the application.

The public access specifier of main() is what allows the function to be callable by a user of the class. The Java keyword static means the function can be invoked even if an object of this class type has not yet been instantiated. That is typically what a main() function does-instantiate an object of its type.

As400CpuUseApp's main() function (see Label A in Figure 4) bootstraps the application by invoking Java's new operator on the As400CpuUseApp() constructor function. The constructor is passed the title to be displayed in the main window frame. As400CpuUseApp (see Label B in Figure 4) extends an AWT window Frame class, so it is itself a frame. The first thing the As400CpuUseApp constructor function does is ask his daddy to create the window frame. The As400CpuUseApp class's dad is the AWT Frame class. As400CpuUseApp extends AWT's Frame class and is thus said to inherit from the Frame class. By calling Java's super() function, the constructor of the immediate class's parent is invoked. AWT's Frame class's constructor then creates the window frame using the string passed to the super() function in its title.

The constructor function then sets the initial size of the application frame and sets the Layout Manager to BorderLayout. BorderLayout is a window component placement strategy in which up to five containers can be placed at north, east, west, south, or center relative to the window. Text labels are then created and added to the northern and southern borders of the application frame. Notice, however, that the Label object is not assigned to a variable. It is instantiated and sent on the fly to the frame's add function. There is no reason for a variable. It is not used by any other function. You will see frequent use of this technique in Java classes. It simplifies code and can even make objects execute faster.

At Label C in Figure 4, you can see the try block (the Java-reserved word try and its curly braced section of code, which I will cover later in the section titled CpuWindowListener). Just trust me that the first time this section of code is executed, the line within the catch block will be executed. It is there that a ListSystems class object is instantiated and assigned to the class field systems. Then, to handle the close window event for this application's frame, a CpuWindowListener is dynamically created and registered as a listener with a call to the addWindowListener() function.

The ListSystems class (see Label D in Figure 4) presents the prompt panel shown in Figure 1. It contains a TextField for the entry of an AS/400's domain name or IP address; a List box to hold those system identifiers; and an add button for the user to say when the text field is to be copied to the list box. The List-Systems() constructor function, called from the As400CpuUseApp class, simply creates these three AWT components and then registers action listeners to handle the two events. The AddSystemListener class is created with a call to its constructor, passing a reference to the List box and TextField class variables.

On a click of ListSystems' add button, the text field value is inserted into the list box with the actionPerformed() function of the Add-SystemsListener class. The actionPerformed() function is automatically called by Java 1.1's event handling mechanism, because the AddSystemsListener object was registered to be notified in the occurrence of an action event-a mouse click. Similarly, the ListSystems-Listener class object is instantiated and then added as a listener to the list box. ListSystemsListener's actionPerformed() function will then be called whenever a user double- clicks on an entry in the list box.

When the event notification occurs, ListSystems-Listener's actionPerformed() function receives an ActionEvent object as a parameter. That parameter is an AWT ActionEvent object that encapsulates information about the event, including a reference to the object that was the source of the event. The actionPerformed() function uses getSource() to retrieve a local reference to that source object. ListSystemsListener's actionPerformed() function then casts that object reference to a list (casting is a feature of Java and C++ that lets you explicitly declare an ambiguous object's type). From that list, we can get the system identifier from the list element selected by the user and place it into the local string variable: VsystemIDV. I'll leave it to you to add the ability for the ListSystems class to remove an element from the list.

The user selects a system identifier that is used to connect to an AS/400 for which we will present a bar chart of CPU usage. It is in the actionPerformed() function of the ListSystemsListener class (see Label E in Figure 4) that a CpuBarChart class is instantiated with a call to its constructor taking the system identifier string.

At that point, we use a relatively sophisticated Java feature. We create a Java thread (a spawned process), and, using the thread's start() function, the CpuBarChart class will execute as if it were a completely new application. The CPU usage application that spawned the CpuBarChart process is completely unhampered by this new thread. As400CpuUseApp can continue to respond to user input and potentially create more CpuBarChart threads to other AS/400s until the client machine runs out of resources.

Threads are a sophisticated feature of Java, but the complexity is embedded inside the language. Using threads is easy. The CpuBarChart class extends the AWT Frame class so that it can present a bar chart, but the class also implements the Java Runnable interface. I will show you how simple it is to implement that Runnable interface in a minute, but first let's go over the construction of the CpuBarChart class object. The CpuBarChart() constructor (see Label F in Figure 4), after asking its parent to create the Frame with a call to super(), adds a window listener to handle the window close event. I'm throwing you a curve here, because I used an event handling shortcut. Instead of designing an explicit class to handle CpuBarChart's window close event, I dynamically defined and created a WindowAdapter class (try that, C++ programmers). That dynamic class is an example of another Java 1.1 enhancement known as inner classes. Inner classes are handy when the implementation of the listener class is trivial. This seems like a fancy technique, but it is easily copied for use with the window close event.

After the CpuBarChart constructor adds a window listener, it creates a qwcrssts class. The qwcrssts class was named for the AS/400 system API that retrieves CPU usage. This qwcrssts class has some moderately complex code, but who cares? It was already implemented for us by Richard Shaler, the editor of this magazine, in "AS/400 Program Calls from Java via the AS/400 Toolbox for Java," Internet Expert, Oct/Nov 1997. This is the nature of object-oriented programming. As a programmer, you are also a user of classes designed by other object-oriented programmers. To use qwcrssts, we need only call its constructor passing the system identifier string and then iteratively call qwcrssts's public getCpuUsage() function to retrieve the CPU usage percentage. I didn't include the source code for the qwcrssts class, but you can download it from the Internet Expert section at http://www.midrangecomputing. com/code. You will also have to download and install IBM's AS/400 Java ToolBox to your PC and install the AS/400 JDK port (Java Development Kit) to the AS/400 that you want to connect to. These downloads are available at the IBM Centre for Java Technology Development home page at

http://ncc.hursley.ibm.com/ javainfo/hurindex.html. (Note that when the qwcrssts class is being constructed, it will prompt you for your AS/400 user profile and password before attaching.)

After creating the qwcrssts class, the CpuBarChart class constructor then instantiates and adds a BarChart object to its panel and calls the show() function to force the BarChart to display. Earlier, I said that the getCpuUsage() function of qwcrssts class was to be called iteratively. It is with the implementation of CpuBarChart's Runnable interface that we do this. To implement the Runnable interface, we only have to define a run() function (see Label G in Figure 4). We do not explicitly call that run() function; it is called automatically by the spawned thread process when the thread's start() function is called.

CpuBarChart's run() function first does a little work to set initial bar labels and CPU values. It then updates the BarChart object by calling BarChart's setLabels() and setValues() functions. The run() function uses the Java Thread.sleep() function to yield to other applications for a specified number of milliseconds-in our case, 5,000, or five seconds. The while(true) block tirelessly calls qwcrssts's getCpuUsage(), updates the bar chart, and sleeps for 10 seconds until the user closes the CpuBarChart panel (and the inner WindowAdapter class shuts down the frame).

To graphically display the CPU percentages, I scanned the Internet looking for a suitable bar chart. I ended up finding one in my own backyard-the Java Development Kit (JDK) from SunSoft comes with an example bar chart applet. I already had that class on my machine. I did, however, have to tweak SunSoft's BarChart class.

SunSoft's class was designed for use as an applet, which I felt was inappropriate for three reasons. One, Java applications are easier to test than applets, which must be executed from within an HTML file in a Web browser. Two, most browsers do not yet support Java 1.1, and I have implemented this application with the event handling model of Java 1.1. Three, the SunSoft's bar chart applet gets the values from HTML parameter tags, which would have required continually updating the HTML source with the new CPU percentage.

If you look at the partial listing of my BarChart class in Figure 5, you can see the pertinent private fields and the public set functions, which allow users to safely set those class data members. CpuBarChart's run() function at one time or another calls each of these functions to set various bar chart attributes such as its title and the color selection for the bars. Knowledge of the implementation for these BarChart functions is not necessary for you to use the class-that's object-oriented programming. To use a class, you only need to know how to use its public functions. You can download my version of SunSoft's bar chart at http://www.midrangecomputing.com.

One handy feature of As400CpuUseApp is its ability to save the AS/400 system identifiers in the ListSystems list box. If you close the As400CpuUseApp window and later reexecute the application, the system identifiers will still be in the list. By the way, you can execute this application by calling the java.exe program and passing the As400CpuUseApp class name as parameter one:

java As400CpuUseApp

To enable this automatic save and restore feature, I used Java's object serialization mechanism. Like threads, serialization sounds complicated, but look at the implementation for

CpuWindowListener's class constructor (see Label H in Figure 4) and look again at the try block in As400CpuUseApp's constructor (I told you I'd cover that try block), and I will explain how easy serialization can be.

CpuWindowListener was designed to react to the window close event of the CPU usage application window. When the window is closed by the user, the windowClosing() function of the CpuWindowListener class makes the systems list box persistent by creating a local file and then writes the systems list to that file as a data stream with Java's writeObject() function. This process is wrapped within what is known as a try block, which is similar to a Monitor Message (MONMSG) statement in a CL program. The catch block is like the DO portion of that MONMSG statement. If something goes awry within the try block's code, the catch block's code will execute.

Looking at the try block within the constructor for As400CpuUseApp, you can see that, if the local file AS.400 is not found, the catch block will be invoked to create a new, and hence empty, list. This is what happens the first time As400CpuUseApp is executed. On subsequent executions, the try does not fail, and the readObject() function constructs the ListSystems object from the persistent data stream. All the user-entered system identifiers are still there.

Note that Java forces you to use try blocks when you use a class that throws exceptions (generates explicitly documented errors). The stream functions used to make the list object persistent were designed to throw exceptions when file errors occur, such as "file not found."

Albert Einstein pointed out that an example isn't another way to teach-it's the only way to teach. The CPU usage application was designed to be an example. It is simplistic in that it uses only a few AWT components. But within the meager 150 lines or so of code (if you don't count the qwcrssts class and my version of SunSoft's BarChart), As400CpuUseApp accomplishes a lot. It adds event listeners, it uses Java serialization, it creates threads, it connects to AS/400s, and it dynamically displays a bar chart.

Take the time to download the classes off Midrange Computing's Web site. If you don't have the ability to connect to an AS/400 that has the AS/400 JDK port installed, simply comment out the two lines that reference the machine object variable. Add some features of your own to the As400CpuUseApp. And after working on two or three Java classes, you too will be kept up at night thinking about the possibilities of Java programming.

Don Denoncourt was a veteran of AS/400 legacy applications programming before he jumped over to systems programming. Since that time, Don has developed several successful AS/400 client/server products in object-oriented C++. Today, Don feels that Java is the object-oriented language of choice for AS/400 client/server programming. He can be reached by email at This email address is being protected from spambots. You need JavaScript enabled to view it..

Englander, Robert. Developing Java Beans. Sebastopol, Cal.: O'Reilly & Associates, Inc., 1997.

Flanagan, David. Java Examples in a Nutshell. Sebastopol, Cal.: O'Reilly & Associates, Inc.,
1997.

Geary, David M. Graphic Java 1.1: Mastering the AWT, second edition. Mountain View, Cal: The Sunsoft Press Java Series, Sun Microsystems Press, 1997.

Gosling, James, Bill Joy, Guy Steele. The Java Language Specification. Mountain View, Cal: The Sunsoft Press Java Series, Sun Microsystems Press,1996

To compile, first be sure to set your class path environment variable to point to wherever you placed IBM's AS/400 Java Toolbox zip file so the Java JDK compiler can access it:

SET CLASSPATH=C:jdkAS400libjt400.zip;

Then, from a DOS window, invoke the Java Development Kit's compiler over each of the three filestocreateexecutableJavabytecodeclassfiles:

o JAVAC qwcrssts.java

o JAVAC BarChart.java

o JAVAC As400CpuUseApp.java

To execute, use the following:

JAVA As400CpuUseApp

When the AS/400 Connection prompt pops up, add the IP address or domain name for the AS/400 to which you want to connect. Once the Add System button adds the address to the list box, double-click on the AS/400 list element to which you want to connect. IBM's AS/400 Java Toolbox will then prompt you for a valid User Profile Name and Password. The BarChart frame will then begin filling the 10 bars in 10-second intervals. Note that interval 1 displays the most recent CPU percentage. You can add as many AS/400 IP addresses or domains as you wish to the AS/400 Connection prompt. You can also simultaneously connect to multiple AS/400s. If you do not have an AS/400 to connect to, try setting initial CPU values in the BarChart class and comment out any references to the variable machine.

Figure 1: The AS/400 selection panel allows you to choose the AS/400 you want to know the CPU usage

Figure 2: The AS/400 CPU-usage bar chart

Figure 3: Source, event, listener, and action table

Figure 4: As400CpuUseApp and other associated classes

import java.awt.*;
import java.awt.event.*;
import java.io.*;
import java.awt.Color;
import java.util.Date;

// As400CpuUseApp class

public class As400CpuUseApp extends Frame {

ListSystems systems = null;

public As400CpuUseApp (String title) {
super(title);
setSize(300,300);
setLayout( new BorderLayout(10,10));
this.add("North", new Label("AS/400 Connection"));
this.add("South", new Label("Double click on system identifier in list to attach"));
try {

FileInputStreamf=newFileInputStream("AS.400");
ObjectInputStreams=newObjectInputStream(f);
systems = (ListSystems)s.readObject();
systems.systems.addActionListener(new ListSystemsListener());
systems.add.addActionListener(new AddSystemListener(systems.systems, systems.systemID));
} catch (Exception e) {
systems = new ListSystems();

}

this.add("Center", systems);
this.show();
addWindowListener(new CpuWindowListener());
}

public static void main(String args[]) {

As400CpuUseApp cpuApp = new As400CpuUseApp("AS/400 Cpu Usage");
}

}

// ListSystems Class

class ListSystems extends Panel {

Button add = null;
TextField systemID = null;
List systems = null;

public ListSystems() {
super();

add = new Button("Add System");
systemID = new TextField(25);
systems = new List();

systems.addActionListener(new ListSystemsListener());
add.addActionListener(new AddSystemListener(systems, systemID));

add(systemID);
add(add);
add(systems);
}

}

// AddSystemListener class

class AddSystemListener implements ActionListener {

List systems;
TextField systemID;
public AddSystemListener(List systems, TextField systemID) {
this.systems = systems;
this.systemID = systemID;

}

public void actionPerformed(ActionEvent e) {
systems.addItem(systemID.getText());

}

}

// ListSystemsListener class

public class ListSystemsListener implements ActionListener {

// on double-click connect to selected AS/400
public void actionPerformed(ActionEvent e) {

List list = (List)e.getSource();
String systemID = list.getItem(list.getSelectedIndex());
CpuBarChart cpu = new CpuBarChart(systemID);
new Thread(cpu).start();

}

}

// CpuBarChart class

public class CpuBarChart extends Frame implements Runnable {
private BarChart barChart = null;
private qwcrssts machine = null;

public CpuBarChart(String systemID) {
super(systemID);
setSize(300,400);
addWindowListener(new WindowAdapter () {
public void windowClosing(WindowEvent e) {

((Window)e.getSource()).dispose();
}

});

machine = new qwcrssts(systemID);
barChart = new BarChart();
add(barChart);
show();

}

public void run() {

String labels[] = {"1","2","3","4","5",

"6","7","8","9","10"};

int cpuUses[] = {0,0,0,0,0,0,0,0,0,0};
Color colors[] = {Color.red, Color.green,

Color.blue,Color.pink,
Color.orange,Color.magenta,
Color.cyan,Color.darkGray,
Color.yellow,Color.gray};
barChart.setColumnCount(10);
barChart.setValues(cpuUses);
barChart.setColors(colors);
barChart.setLabels(labels);

while(true) {

// promote index values
for(intx=9;x 0;x--){
cpuUses[x] = cpuUses[x-1];
}

cpuUses[0] = machine.getCpuUsage();
Date now = new Date();
barChart.setTitle("AS/400 CPU Usage at " +
now.getHours() + ":" +
now.getMinutes() + ":" +
now.getSeconds());
barChart.setValues(cpuUses);
try {

Thread.sleep(5000);
} catch(InterruptedException ie) {

System.out.println("wait failed");
}

}

}

}

// CpuWindowListener class

class CpuWindowListener implements WindowListener {
public void windowActivated(WindowEvent e) {}
public void windowClosed(WindowEvent e) {}
public void windowClosing(WindowEvent e) {
try {

FileOutputStream f = new FileOutputStream("AS.400");
ObjectOutputStream s = new ObjectOutputStream(f);
ListSystems systems = ((As400CpuUseApp)e.getSource()).systems;
s.writeObject(systems);
s.flush();
} catch (Exception xcpt) {

System.out.println(xcpt);
}

Window window = (Window)e.getSource();
window.dispose();

System.exit(0);
}

public void windowDeactivated(WindowEvent e) {}
public void windowDeiconified(WindowEvent e) {}
public void windowIconified(WindowEvent e) {}
public void windowOpened(WindowEvent e) {}

}

// partial list of SunSoft's BarChart

public class BarChart extends Panel {
static final int HORIZONTAL = 1;
static final int VERTICAL = 2;

private String title = "Bar Chart";
private int columns;
private int values[];
private Object colors[];
private Object labels[];

public BarChart() {super(); ...}

Figure 5: The BarChart Class API

public synchronized void paint(Graphics g) {...}
public void setValues(int values[]) {...}
public void setLabels(String labels[]) {...}
public void setColors(Color colors[]) {...}
public void setOrientation(int orientation) {...}
public void setTitle (String title) {...}
public void setColumnCount(int count) {...}

}

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

		Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale

Also Read

Practical Java: Start Your Java Engine!

Practical Java: Making Java Work for You

Book Review: Java for RPG Programmers