Building Java Applications for the iSeries Server with VisualAge for Java 3.5

344 Building Java Applications for the iSeries Server with VisualAge for Java 3.5

One important fact should be noted here. If the program on the iSeries server issues a

message that waits for a response (an inquiry message), then

control is never returned. The

submitOrder() method hangs on the ordEntrPgm.run() method. If this occurs, you must

check the server job that is handling the request on the host iSeries server. This job has a

name of QZRCSRVS, and its job log should be viewed. If the program runs successfully, the

submitOrder() method updates the status text field accordingly.

This concludes the application flow from the Java client perspective. Now, we examine the

code changes made in the RPG code to accommodate the Java client.

8.5 Changes to the host Order Entry application

This section contains details about the transition of the RPG code on the host. The changes

are made, so the application can run in one of two modes:

򐂰 As a native application with a 5250 screen interaction

򐂰 In conjunction with the newly created Java client

For the most part, the changes are examined in the same sequence as the client application

flow.

8.5.1 Providing a customer list

We saw earlier that one of the first things the client does after connecting is to request a

customer list. This was done by executing an SQL stored procedure using JDBC. The stored

procedure is actually an RPG program called SLTCUSTR. To accommodate the Java client,

two subroutines are added to the program and the logic flow is changed when a second

parameter is detected. In the original version of SLTCUSTR, the logic flow can be

summarized as:

򐂰 Run the OpenCust subroutine (declares and opens the cursor for CSTMR file).

򐂰 Run the BldSfl subroutine (populates and displays the subfile).

򐂰 Run the Process subroutine (detects the chosen customer and displays).

The new logic flow can be summarized as:

򐂰 Run the CloseCust subroutine (resets the cursor for multiple client requests).

򐂰 Run the OpenCust subroutine (same behavior as the original version).

򐂰 If more than one parm, run the ResultSet subroutine (makes result set available to the

caller of the stored procedure).

򐂰 If only one parm, continue as the original version did. Run the BldSfl subroutine, and then

run Process.

The added subroutines are minimal code changes. Here is the CloseCust subroutine:

CSR CloseCust BEGSR

* ----------

C/Exec Sql Close CUSTOMER

C/End-Exec

*

CSR ENDSR

As previously mentioned, this ensures that the cursor is at the beginning of the file when

multiple requests are received from the client. Now, we examine the ResultSet subroutine: