System iNetwork

The Java programs that explain using data queues in Java in future entries will use the demonstration model. You can use the CL client to read input from the Java examples or put input into the demonstration server to be read by the Java examples.

The Java examples will be presented first as console applications which can be run on a PC or on the System i. They will go beyond the basic data queue operations described in the Java toolbox documentation.

If you are interested in the Java parts take the time to build the demonstration server and test client on your System i.

The IBM Redbook Who Knew You Could Do That with RPG IV? A Sorcerer’s Guide to System Access and More, section titled Data Queue APIs - Programming with Data Queue APIs (5.2.3) explains implementing a client / server model using data queues. When possible this material is referenced for the System i side of the Eclipse RCP client data queue examples.

The steps to create a demonstration model for the future Java work are:

1. Create the data queues
2. Build a demonstration model / server on the System i
3. Build a test client / view-controller on the System i

We will move through the System i side of this very quickly and at a high level. This is very simple and basic for the experienced readers of System i network and the topic is thoroughly covered in the IBM Redbook referenced.

Step 1.

This design uses two data queues. One data queue is for the Model (server) to receive data from the View-Controller (client), call it MDLI (MoDeL Input). The second data queue is for the Model to send data to the View-Controller, call it MDLO (MoDeL Output). Feel free to pick your own names. This short name leaves 6 characters to identify the specific model when implementing.

MDLI (Model in) is a FIFO data queue. The Model gets instructions from any View-Controller through this data queue. The data structure of MDLI is
- identifier of the View Controller (6 characters)
- instruction (16 characters)
- data which is defined in an external data structure

CRTDTAQ DTAQ(your_lib /MODLI) MAXLEN(64512) AUTORCL(*YES)
TEXT('Template input to Model of MVC')

MDLO (Model out) is a keyed data queue. The Model returns results to any View-Controller that sent the request, identified by the key, through this data queue.
- the key is 6 characters, the identifier of the View-Controller
- the data structure is
- instruction (16 characters), echo back the instruction the model is responding to
- data which is defined in an external data structure

CRTDTAQ DTAQ(your_lib/MODLO) MAXLEN(64512) SEQ(*KEYED)
KEYLEN(16) AUTORCL(*YES) TEXT('Template output to Model of MVC')

The source for step one:
MDLDMODQCL
The library to create the data queues, your_lib, is passed to this CL as a parameter.

Step 2

Create a test System i server / model which reads MDLI and writes MDLO. We are demonstrating how client applications interact with data queues. We don't need much from the Model but we need something to prove the clients works and debug them.

The test server / model needs to read the input data queue (MDLI) and write to the output queue (MDLO). At this point all we need is something the client can write to and get a response.

This server / model runs in batch in a simple tight loop
- read MDLI (QRCVDTAQ API)
- build a reply with the info read from MDLI
- write the input from MDLI and the response to an audit file
- write MDLO (QSNDDTAQ API)
- if the instruction in MDLI is '*ENDIT' set on LR otherwise repeat

The test model / server is similar to the test data queue server described in Data Queue APIs - Programming with Data Queue APIs (5.2.3) of Who Knew You Could Do That with RPG IV? A Sorcerer’s Guide to System Access and More .

The differences between the test program for this project and the server described in the Redbook are:
- the data queues use data structures that are defined externally where the IBM example defines the necessary fields as program variables.
- the model / server loops continuously until *ENDIT is received as an instruction where the IBM example executes one cycle
- an audit file records the model / server function for testing and debugging

The source for step two:
MDLIDS01 - model input data queue external data structure
MDLODS01 - model output data queue external data structure
MDLAFL01 - audit file to show what goes in and out of the demo server
MDLDMOSRRG - source for the demo server
MDLDMOSRCL - starts the demo server in batch, modify this to meet your needs

Hint: Change the parameter of the audit file of "Records to force a write" (FRCRATIO) to 1. This forces the demo server to write each cycle to disk as it happens. That way you can check on the server's operation which query or DSPPFM while it is running.

Step 3

Create a test client or view-controller on the System i. This is done to test the server or model. It also demonstrates that the server or model will serve clients other than a desktop Java application.

We need a simple client, one that takes input from the user, sends it to the model / server, and shows the user the results from the model. These simple tasks can be done with CL. The command prompter can accept the users input. SNDUSRMSG can display the output.

You can also display the audit file to see that the model is working.

The steps are

Define a CMD to accept the three fields in the MDLI data structure
VCID - view controller ID
INSTRCTN - instruction to the Model
MESSAGE - message to the Model

To make the command more useful I defined two logical variables. One to indicate if CL program should only read the output data queue (MDLO) and the other to indicate if the CL program should only write to the input data queue. With these additions the CL client can
- test the demo server by writing to its input and reading its output
- read the output of the server (for an input put by another client)
- write to the input of the server (for another client to read as server output)

Write a CL program to accept these as parameters. The key points are

- Concatenate the three fields into a single field to send to the demo server

- Use QSNDDTAQ API to send the single field to the MDLI data queue

- Use QRCVDTAQ API to received the results from the model, MDLO data queue. Only wait a reasonable amount of time.

- Use SNDUSRMSG to display the output of the model. If the length returned by QRCVDTAQ is zero then give the user an error message otherwise give the user the results from the model.

The source for step three:
MDLDMOVCCL
MDLDMOVC

The source in HTML has been linked to this entry. The source is also in the CVS provided by CVSDude. CVS is an open source change management system supported by Eclipse and WDSc. The CVS can also be accessed through the web.

The instructions for accessing CVSDude repository are in a link at the top right of the main page for this blog, beneith the blog mission link. I can be reached at b_blalock@comcast.net.