AS/400 optimization

The AS/400 Toolbox for Java licensed program is "Pure Java" so it runs on any platform that has a release 1.1.2 or later Java Virtual Machine. "Pure Java" also means the AS/400 Toolbox for Java classes function in the same way no matter where they run.

Additional classes come with OS/400 that alter the behavior of the AS/400 Toolbox for Java when it is running on the AS/400 Java Virtual Machine (JVM). Sign-on behavior and performance are improved when running on the AS/400 JVM and connecting to the same AS/400. The additional classes are part of OS/400 starting at Version 4 Release 3.

The classes that modify the behavior of the AS/400 Toolbox for Java are in directory /QIBM/ProdData/Java400/com/ibm/as400/access on the AS/400. If you want the Pure Java behavior of the AS/400 Toolbox for Java, delete the classes in this directory.

Sign-on considerations

With the additional classes provided by OS/400, Java programs have additional options for providing system name, user ID and password information to the AS/400 Toolbox for Java.

When accessing an AS/400 resource, the AS/400 Toolbox for Java classes must have a system name, user ID and password.

When running on a client, the system name, user ID and password are provided by the Java program, or the AS/400 Toolbox for Java retrieves these values from the user through a sign-on dialog.

The Java program cannot set the password to "*current" if you are using record-level access. When you use record-level access, "localhost" is valid for system name and "*current" is valid for user ID; however, the Java program must supply the password.

When running on the AS/400 JVM, the AS/400 Toolbox for Java has one more option. It can send requests to the current (local) AS/400 using the user ID and password of the job that started the Java program.

With the additional classes, the user ID and password of the current job also can be used when a Java program that is running on one AS/400 accesses the resources on another AS/400. In this case, the Java program sets the system name, then uses the special value "*current" for the user ID and password.

A Java program sets system name, user ID, and password values in the AS400 object.

To use the job's user ID and password, the Java program can use "*current" as user ID and password, or it can use the constructor that does not have user ID and password parameters.

To use the current AS/400, the Java program can use "localhost" as the system name or use the default constructor. That is,

     AS400 system = new AS400();
is the same as
     AS400 system = new AS400("localhost", "*current", "*current");

Two AS400 objects are created in the following example. The two objects have the same behavior: they both run a command to the current AS/400 using the job's user ID and password. One object uses the special value for the user ID and password, while the other uses the default constructor and does not set user ID or password.

                       // Create an AS400 object. Since the default
                       // constructor is used and system, user ID and
                       // password are never set, the AS400 object sends
                       // requests to the local AS/400 using the job's
                       // user ID and password. If this program were run
                       // on a client, the user would be prompted for
                       // system, user ID and password.
     AS400 sys1 = new AS400();

                       // Create an AS400 object. This object sends
                       // requests to the local AS/400 using the job's
                       // user ID and password. This object will not work
                       // on a client.
     AS400 sys2 = new AS400("localhost", "*current", "*current");

                       // Create two command call objects that use the
                       // AS400 objects.
     CommandCall cmd1 = new CommandCall(sys1,"myCommand1");
     CommandCall cmd2 = new CommandCall(sys2,"myCommand2");

                       // Run the commands.
     cmd1.run();
     cmd2.run();

In the following example an AS400 object is created that represents a second AS/400 system. Since *current is used, the job's user ID and password from the AS/400 running the Java program are used on the second (target) AS/400.

                       // Create an AS400 object. This object sends
                       // requests to a second AS/400 using the user ID
                       // and password from the job on the current AS/400.
     AS400 sys = new AS400("mySystem.myCompany.com", "*current", "*current");


                       // Create a command call object to run a command
                       // on the target AS/400.
     CommandCall cmd = new CommandCall(sys,"myCommand1");


                       // Run the command.
     cmd.run();

Performance improvements

With the additional classes provided by OS/400, Java programs running on the AS/400 JVM will increase (or improve) their performance. Performance is improved in some cases because less communication function is used, and in other cases, an AS/400 API is used instead of calling the server program.

Faster communication

For all AS/400 Toolbox for Java functions except JDBC and integrated file system access, Java programs running on the AS/400 JVM will run faster. The programs run faster because less communication code is used when communicating between the Java program and the server program on the AS/400 that does the request.

JDBC and integrated file system access were not optimized because facilities already exist that make these functions run faster. When running on the AS/400, you can use the AS/400's JDBC driver instead of the JDBC driver that comes with the AS/400 Toolbox for Java. To access files on the AS/400, you can use Java.io instead of the integrated file system access classes that come with the AS/400 Toolbox for Java.

Directly calling AS/400 APIs

Performance of the record-level database access, data queue, user space, and digital certificate classes of the AS/400 Toolbox for Java is improved because these classes directly call AS/400 APIs instead of calling a server program to carry out the request. APIs are directly called only if the user ID and password are the user ID and password of the job running the Java program. To get the performance improvement, the user ID and password must match the user ID and password of the job that starts the Java program. For best results, use "localhost" for system name, "*current" for user ID, and "*current" for password.

Start changePort mapping changes

The port mapping system has been changed, which makes accessing a port faster. Now you tell the AS/400 which port to use. Before, the request for a port would be sent to the port mapper. From there, the AS/400 would determine which port was available and return that port to the user to be accepted. Port mapping is still available, but is no longer necessary. For the port mapping improvement, a few methods have been added to AS/400 access class:

MRI changes

MRI files are now shipped within the AS/400 Toolbox for Java program as class files instead of property files. The AS/400 finds messages in class files faster than in property files. getString now runs faster because the MRI files are stored in the first place that the computer searches. Another advantage of changing to class files is that the AS/400 can find the translated version of a string faster

Converters

Two classes have been added that allow faster, more efficient conversion between Java and the AS/400:


[ Legal | AS/400 Glossary ]