System iNetwork

Consider this a review of data queue related classes and examples provided by IBM. That documentation is found in the iSeries Information Center, under Programming > Java > Toolbox section. You can compare the Java code to the data queue examples which IBM provides.

In the last blog entry the CL view-controller gave you a means to exercise the demonstration model which was running in batch with a couple of options (write to the model but don't read and read from the model but don't write). This blog entry provides the same basic tool in Java. You can run this on the System i (in QSH) or on your desktop.

The code for this is in the CVSDude repository, in the project "info.billblalock.mvcintro.java_apps". The programs are
- dataqueue.DtaQExample1.java and
- dataqueue.DtaQExample2.java.
The programs are similar with one significant difference I will get to later.

The logic of these programs is like the CL view-controller in that they write an entry to the demonstration model's input data queue and wait to read an entry from the demonstration model's output data queue. This pattern is similar to EXFMT of a 5250 display, write the display file and wait for a read.

The console prompts the user for the instruction to send to the model. If the instruction is *STOPNOW the program terminates. If not the program prompts the user for the data to send with the instruction. The instruction and data is written to the model input data queue. The program waits to read the model output data queue.

The class common.Me.java defines constants and getters for your AS400, data queue names, etc. That is the only thing you should need to change to get these programs to run on your system.

These two Java client programs will run either on the System i as Java programs or on your desktop. There is no GUI involved, all the IO is through stdin and stdout.

The only difference between Example1 and Example2 is that Example1 dynamically builds the Record object and Example2 uses a static pre-compiled Record object.

Example1 doesn't know anything about the data structures for the input and output data queues that are expressed as System i files (external data structures). It dynamically retrieves the files from the System i and learns the structure of the data from the files. Each time the program is run the data structures are resolved.

Example2 uses precompiled classes to represent the data structures. It doesn't have to retrieve this information from the System i.

Example1 shows the time it takes to retrieve the information during the startup of the program. Example2 shows that virtually no time (0 milliseconds) is required to use the precompiled information.

I did this comparison because while the Java toolbox documentation mentions the two methods it doesn't give you a good feel for the real difference.

Example1, the dynamic example, limits the impact of changes in data structures. Dynamic resolution means your program won't care if new fields are added to the data structures, if lengths of fields are changed or if the order of field names is changed. But you pay for this flexibility each time the Java program dynamically fetches the information. Of course the program is still going to tank if the names of the fields or their data types are changed.

Example 2 is fast. If the external files on the System i which represent the external data structures are changed then the pre-compiled classes will have to be re-generated.

That is pretty much gives you all you need to know to decide between the two methods for your given circumstances.

The class common.CreateModelRecordFormats.java is the code to generate the static, or pre-comiled classes to represent the data structures based on System i files. See the toolbox documentation for details.

I am writing less blog and putting the time into the code. If I missed something or there are questions leave a comment.

Enjoy!