|
Installation
Although my intent is not to document every component on every platform that can be used to build this sample, I will add some information pertaining to the components I used. From this information, you should be able to get an idea of what would be needed on other platforms. There is also a bit about the debugging I did (at the bottom). CICS for NT - I used CICS for NT as supplied with Transaction Server for NT V4 at PTF set 2. I followed the directions supplied with Jim MacNair's CA03 SupportPac to make programs VERIFYPW, NEWBRW, and NEWCALL available. The variation here is that CICS for NT does not support EXEC CICS VERIFY PASSWORD. To accomodate this, I modified the VERIFYPW program to provide a return code of zero, then do an EXEC CICS RETURN. The Java applet is hard coded to add the user supplied userid and password to the VERIFYPW program COMMAREA and to use a userid of FRED and a password of FRED on the ECI call to the VERIFYPW program. If my target CICS server platform was CICS for NT, I would have changed the Java program to use the supplied userid and password on the ECI call to my dummy VERIFYPW program. As long as the VERIFYPW program had the same security as the NEWCALL and NEWCBRW programs, an invalid user would fail the initial call and appropriate security messages could be produced. If the target environment supported EXEC CICS VERIFY PASSWORD, the userid and password used on the ECI call to verify the password could be any userid and password that is allowed to use the VERIFYPW program. CA03's VERIFYPW also returns that number of days until password expiration and other bits of information. I did not code the Java program to give this information back to the user. This would be something that you might want to add to a real application. Since I was going to use the CICS Client for NT, I also added a TCP/IP client listener to CICS for NT (I used the default port 1435). CICS Client for NT - I used the CICS Client for NT because I also ran the CICS Gateway for Java on the same machine. I installed V2.0.3 of the CICS Client for NT. I modified the cicscli.ini file in the client's bin directory to point to my CICS for NT region. I started a 'cicsterm' to verify that I had configured the CICS Client for NT properly. The client will automatically be started when you try to use its services. This means that after you start CICS for NT and the CICS Gateway for Java, the CICS Client for NT will automatically start when you make your first Java request through the CICS Gateway for Java. CICS Gateway for Java - I used V2 of the CICS Gateway for Java. The CICS Gateway for Java comes as a zip file. After the zip file is expanded, you will have a base directory of JGate. To start the CICS Gateway for Java you can execute the JGate.cmd command in the Gateway's \bin\nt directory. This is a command file that sets a CLASSPATH environment variable to run the CICS Gateway for Java and then starts the Gateway. This is usually all that is needed to have a running CICS Gateway for Java. The window that you started the CICS Gateway for Java from becomes its console. You can view this 'console' to see when your Applets connect and disconnect from the Gateway. I set up a shortcut to JGate.cmd on my desktop, so a couple mouse clicks starts my CICS Gateway for Java. JDK 1.1 - Although you can use any Java compiler that is Java 1.1 compliant, I used Sun's JDK (Java Development Kit). The JDK from Sun, is currently at level 1.1.5, and can be obtained from http://java.sun.com/products/jdk/1.1/index115.html (as of 5-21-98). This has a Install Shield type install. You will want to update your PATH and CLASSPATH environment variables. You can set the environment variables as system or user environment variables, or you can execute a setup batch file in the command prompt window where you are working. I used the following: @echo off The \jgate\classes directory contains my CICS Gateway for Java Classes. Executing the sample Java program - To run the my sample Java program, you will need to compile the program and use appletviewer to run the program. mkdir \temp cd \temp (unzip the files into this \temp directory using your favorite zip tool) (compile the Java program, note that the Java program name must match the applet class name inside the source file, so the name is case sensitive, see next line) javac IVPApplet.java (run the program in the applet viewer) appletviewer IVPApp.html The appletviewer is like a mini-browser that only runs Java programs, and only looks at 'applet' tags in HTML. The IVPApp.html file is an HTML file that contains an applet tag. The window that you used to start the appletviewer becomes your 'java console'. I left all my debugging messages in, so you should see lots of messages. If you see security messages, click on 'applet' on the menu bar of the appletviewer screen, then click on properties. Network access will have to be set to 'applet host' or 'unrestricted'. If all is working OK at this point, you should see lots of messages on your java console (the window you used to start the appletviewer), your CICS Gateway for Java console (the window you used to start the CICS Gateway for Java), and on the console.msg and/or CSMT.out of your CICS for NT. Note that if you use the JDK1.1.5 appletviewer, the appletviewer has a problem displaying the last line on the applet. If you resize the window, the message will display properly. Web Server/Browser - At this point you are ready to try to access the sample Java program from a web browser (must be a Java 1.1 compliant browser). Before we can attempt web browser access, you will have to set up a web server. In my case I used Microsoft's IIS (yes, I had everything running on the same machine). From our web browser, we would like to type in something like http:\\myserver\applets\IVPApp.html. This says to go to the web server called 'myserver', in its directory called 'applets', and retrieve a file called IVPApp.html. So, set up a virtual directory in IIS and point to the \temp directory that was set up in the step above. When the IVPApp.html file is retreived by the web browser, the web browser will find the applet tag. The applet tag looks like: <applet code=IVPApplet width=375 height=375> The applet tag says to retreive a file called IVPApplet.class and execute it under a Java Virtual Machine. The height and width indicate how much space on the browser window it should receive. The param tags indicate name/value pairs that should be passed to the executing Java program. The 2006 is the default port where we started the CICS gateway for Java. The gateway is the name or TCP/IP address of the machine containing the CICS Gateway for Java (which also must be the machine containing your web server and CICS client). The server is the name of the CICS region we are connecting to (as defined in the CICS Client cicscli.ini file). Note that these param tags are specific to the way I coded the sample Java program. So, the IVPApplet Java applet starts executing and refering to objects. When an object is referenced that is not contained in the virtual machine, the web browser requests the object's class from the web server. Common objects like buttons are contained in the virtual machine so the web browser does not have to request these from the web server. For some browser implementations, the browser will also search the CLASSPATH environment variable for requested objects (this can be confusing). For the IVPApplet sample program, your browser will request multiple files from the \temp directory (our virtual /applets directory) (the directory where we compiled our Java program). The last piece of the puzzle is the .class files from the CICS Gateway for Java that the virtual machine in your web browser needs to run the sample applet. This varies a lot from web server to web server, but for IIS, copy the IBM directory and all of its subdirectories from the \jgate\classes directory into your \temp directory where you pointed the virtual /applets direcory. Everything should work fine from your browser at this point, just like it did from the appletviewer. The Java programs that I have been writing so far have been fairly simple. I have been able to correct my errors by looking at message files and writing messages to the java console. The Java compiler does such close checking, the compiler has caught most of what would be logic errors in any other language. There are source code debuggers, but I haven't had a need to use one yet (again, my programs have been simple). In this environment I used:
Should you have problems with your Java programs you develope, you may also want to look into;
[Title Page] [Overview] [The Flow] [Top] [The Applet] [Summary] This page last modified: 06/15/98 |
©1998 IBM Corporation |