|
|
|
The Java Applet
The four main areas to consider when writing a Java applet are:
To get the sample Java program (IVPApplet.java), click here. To get a sample html file (IVPApp.html) to execute the Java program click here. A third of the code in the IVPApplet.java file constructs the various panels used for the IVPApplet. I did not place a lot of effort into designing a fancy GUI since GUI panel building is not the emphasis of this SupportPac. The application backend was already in place (from CA03), so I built the GUI to be quite similar to the supplied IVP. I used a border panel (one of the panel types in Java), where "North" is a the applet heading, "South" is a informational message, and "Center" is a card panel (one of the panel types in Java). There is a 'card' for the signon panel, the inquiry panel, the add panel, the update panel, and the browse panel. The program logic switches the 'card' that is displayed. Each 'card' usually consists of a border layout with a heading area in the "North", a message area in the "South", and a grid layout (one of the layouts in Java) in the "Center". I specifically did not use VisualAge for Java, J++, or some other Java panel builder as I wanted a simple sample that any one could build, and that would not require any additional products. [top] When an Java applet is run under a virtual machine (VM), the init() method is invoked when the program is first loaded, the start() method is invoked when the applet goes 'on page', the stop() method is invoked when the program goes 'off page', and the destroy() method is invoked when the Java program is terminated. Other methods in the program are invoked when events happen (like a button being pressed), or are invoked from other methods. In the init() method, I get parameter values and build the panels. In the start() method, I try to instanciate a JavaGateway object that causes a connection to the CICS Gateway for Java. If this fails (causes an exception), I display a pop-up panel indicating there was an error communicating with the CICS Gateway for Java. When a JavaGateway object is instantiated, all the servers are listed and a status check is performed. The results of the status check are listed on the Java console. Any time a request is going to be sent to the CICS Gateway for Java, the code checks if the JavaGateway object is null. If it is null, the code tries to instanciate a JavaGateway object. This means that if the CICS Gateway for Java was down when the user loaded the applet, the user does not have to reload the applet when the CICS Gateway for Java become available. The user only has to click the appropriate button to try to use the CICS Gateway for Java. In the stop() method, I close() the JavaGateway object. In appletviewer, instantiating and closing the JavaGateway object causes a connect and disconnect to/from the CICS Gateway for Java when you maximize or minimize. This program uses the Java 1.1 event model. [top] A COMMAREA is a communications area that is used to pass data between the Java GUI front-end, and the backend CICS program. The COMMAREA sometimes presents a challenge; going from the object oriented world of Java to the record oriented COMMAREA approach of a CICS COBOL program. The backend programs that are called by this sample (from the CA03 SupportPac) although being simple programs, still have many COMMAREA fields. Because of the many fields, I created a generic COMMAREA object. It was faster for me to code the generic COMMAREA object than to code a 'getter' and 'setter' method for each field (a method to get each field's data, and a method to set each fields data). The generic COMMAREA object is composed of a class called Commarea which also uses another class called CommareaElement. The Commarea constructor uses a String array that identifies the name of the COMMAREA field, its size, its initial value, and its data type. Currently supported data types are character, display numeric, and 'MFL' which stands for Map Field Length (2-byte binary) (CA03 takes the original map from the IVP programs and moves that map definition to a COMMAREA). The MFL supports a max value of 127. Information about each COMMAREA field is stored in a CommareaElement. When requested, the Commarea object can return a byte array which can be used as a COMMAREA for the ECI call. Information about the CommareaElements is kept in a vector and a hash table in the Commarea object. The value of a field can be set or accessed with the following commands:
The CommareaElement object also has methods to access the data length, the data type, its displacement into the COMMAREA, the field value as a byte array, etc. OK, so why did I spend a bit more time to build my own Commarea object and not use something like the VisualAge for Java COMMAREA JavaBean generator? As stated in another section, I wanted a sample that was as simple as possible, and didn't require the purchase or use of additional products (also, there was this one Tuesday morning about 1:00 am, where I just had nothing to do). [top] The CICS Gateway for Java extends the API available in the CICS Clients to your Java program. In this Java program, I used synchronous ECI calls. This involves instantiating a JavaGateway object to start communications between your Java program and the CICS Gateway for Java (in a try/catch structure because it can throw exceptions). Composing an ECIRequest object that includes the name of the CICS program to be called, the CICS userid and password you wish to use, a COMMAREA (byte array) and its length. Invoking the flow() method of the JavaGateway object to make the ECI request. Below is a sample ECI call: try { // Stuff for successfull ECI call goes here
// Stuff for bad ECI call goes here
Note that the CICS Gateway for Java capabilities are well documented
in the HTML pages that are supplied with the CICS Gateway for Java. [top] [Title Page] [Overview] [The Flow] [Installation] [Top] [Summary] This page last modified: 06/15/98 |
©1998 IBM Corporation |
