The business environment influencing your iSeries appli-cation development and deployment continues to increase in complexity. Business events such as mergers and acquisitions often yield difficult system integration tasks. The Internet, along with the associated e-business opportunities to more closely link with your customers, suppliers, and other stakeholders for increased organizational effectiveness, has also exposed the difficulty and costliness of linking disparate applications and data. Add in the 24/7/365 uptime and availability requirements and the shortage of skilled IT professionals, and the challenges never end.

A sound solution architecture must get the job done today and be cost-effective; it must also be flexible enough to adapt to changing business and technology developments. Message-oriented middleware (MOM) based on data queue infrastructure is a popular choice, as it supports a variety of application integration needs and is typically easier to implement than direct communications APIs such as Sockets, or remote program call techniques.

The IBM MQSeries product family is a leader in MOM and provides a solid foundation for application integration needs. MQSeries is available on 35-plus operating system platforms and provides application integration middleware across different network and communications environments, and different programming languages. MQSeries provides assured, one-time delivery for synchronous and asynchronous messaging applications, as well as the core messaging services for a number of additional products such as MQSeries Integrator and MQSeries Workflow. MQSeries also provides messaging services for the recently released Connect for iSeries product for linking your AS/400 and iSeries applications with electronic exchanges such as the Ariba Network. In this article, I will provide you with some guidelines to help you get MQSeries operational on your iSeries server quickly.

Why You Need Synchronous and Asynchronous Messaging

A typical business application has real-time, transactional requirements. However, as the number of functions and procedures that make up a transaction increase (especially in the B2B model), so does the response time and the possibility of a failure somewhere in the process chain. This brings up the concepts of synchronous and asynchronous messaging.

With synchronous—or transactional—messaging, the application issues a service request and waits for a successful completion or an error notification. An example of synchronous messaging would be a bank funds transfer. With asynchronous messaging, the application issues a service request and then continues doing other processing. An

asynchronous messaging example would be scanning the barcode of an item at a point-of- sale terminal, then having the application retrieve the item’s price while you scan another item.

Figure 1 illustrates the benefits of synchronous and asynchronous messaging. This example uses the Connect for iSeries product (iSeries Connect), which also installs a version of MQSeries on your iSeries or AS/400 machine when iSeries Connect is installed. However, the MQSeries version that is supplied with iSeries Connect is intended to be used only with the iSeries Connect product. If you intend to use MQSeries outside of the iSeries Connect environment, you must purchase a license for the product. [Editor’s Note: for more information on Connect for iSeries, see “Getting Started with iSeries Connect,” Midrange Network Expert, March/April 2001.] The buyer issues a purchase order request through the electronic exchange. The server receives the request and routes it to the iSeries Connect application. The iSeries Connect application validates the authenticity and accuracy of the request, and then uses MQSeries internally to forward the message for subsequent processing. The iSeries Connect product can then invoke the appropriate application interface (e.g., Java program call, OS/400 program call, or a queue message) with the correctly formatted request data. After the application response is received, another message is generated and MQSeries delivers it to the appropriate iSeries Connect task for replying back to the requester.

The iSeries Connect product uses the asynchronous capabilities of MQSeries to send messages for invoking server-processing tasks. The synchronous, transaction- oriented capabilities ensure that a positive or negative response is generated back to the originator within a prudent amount of time. You can also use MQSeries asynchronous messaging to your advantage when integrating your back-office applications with iSeries Connect. This is a good strategy, as even a seemingly simple order request can involve multiple applications across multiple servers.

MQSeries Installation and Basic Configuration

MQSeries version 5.2 for AS/400 and iSeries 400 is available as licensed program 5733- A38 for OS/400 releases V4R4 and later. There is an older version—licensed program 5769-MQ2—that has been available since OS/400 V4R2 that is also currently supported. Refer to the IBM Web site, www.iseries.ibm.com/ developer/ebiz/mqseries/article.html, for an overview of the different release capabilities. You install MQSeries via the standard OS/400 Restore Licensed Program (RSTLICPGM) command. The product includes a wealth of sample applications, which you can add by selecting option 1 during product installation. Naturally, you will want to ensure that your AS/400 or iSeries machine is at the latest cumulative PTF level.

Once the product is installed, you can configure one or more queue managers (assuming you are using 5733-A38; 5769-MQ2 supports only one queue manager instance). A queue manager is an autonomous entity that provides the server infrastructure you need for sending and receiving application messages, such as the application data queues, communications services, security, and other system management functions. A typical environment consists of one queue manager, defined as the default manager, that is used for application integration tasks, plus one or more other queue managers used for testing and development purposes.

I’ll go through an example using the MQSeries for AS/400 V5.x product (5733- A38) for configuring a queue manager and verifying that it is operational (e.g., that it can receive and send messages). This example is only valid for the 5733-A38 product, as the interfaces have changed from the older 5769-MQ2 product and the MQ2 product only supports one queue manager instance. For information on configuring the older 5769-MQ2 product, please see the MQSeries for AS/400 V4R2.1 Admin-istration Guide (GC33-1956) available at the IBM MQSeries Family:Books Web site at www-
3.ibm.com/software/ts/mqseries/ library/manualsa/index.htm.

MQSeries for OS/400 provides a number of helpful CL commands for administering the setup, plus the familiar menu structure from a standard 5250 session. MQSeries tasks, by default, run in their own subsystem, QMQM, which is defined in the library QMQM. The first task is to start this subsystem via the Start Subsystem (STRSBS) command as follows:

STRSBS SBSD(QMQM/QMQM)

You will find that MQSeries provides numerous options for most commands and tasks; however, the default options are typically more than adequate in most situations.

The second step is to create a test queue manager, which, we have decided for testing purposes, will not be the default. You can enter the CRTMQM command directly or select the Create Message Queue Manager option off of the MQSeries Commands menu (Figure 2 shows the MQSeries Commands menu, which also contains many other options for configuring your MQSeries setup). Figure 3 shows the screen where you specify a name for your queue manager in the Message Queue Manager Name (MQMNAME) parameter and set up the other parameters. For this example, I used the name MYQMGR as my test queue manager instance. I also specified that undelivered messages should go into a separate queue called the SYSTEM.DEAD.LETTER. QUEUE, which is one of the queues that is created on your system when OS/400 creates a new queue manager. I recommend that you get into the habit of specifying SYSTEM.DEAD.LETTER. QUEUE for your undelivered messages queue. However, for this simple starter example, you could also change the undelivered message queue parameter to *NONE, which is the default.

When you create a queue manager, numerous objects get created on an iSeries machine. Library QMxxxxxxxx (with xxxxxxxx being the first eight characters of the queue manager name) is created, which contains journal definitions, a message queue, job descriptions, and a number of other objects. There is also a directory structure put in place on the AS/400 Integrated File System (AS/400 IFS) in /QIBM/UserData/mqm/qmgrs/ xxxxxxx, where the application queue data actually resides, along with logging files and other objects.

After creating the test queue manager instance MYQMGR, I will work with it as a development environment. To start the instance, I enter the Start Message Queue Manager (STRMQM) command in the following way:

STRMQM MYQMGR

The MQSeries CL commands require that you specify a queue manager, because multiple queue managers may be installed on the machine.

After the command completes, look at the jobs in the QMQM subsystem. Refer to MQSeries for AS/400 V5.1 System Admin-istration (SC34-5558-00) at the IBM MQSeries Family:Books Web site at www-3.ibm.com/software/ts/mqseries/ library/maualsa/ index/htm for details on each of these tasks for the 5769-A38 product. By and large, the Start Message Queue Manager (STRMQM) command starts all necessary MQSeries tasks, and the End Message Queue Manager (ENDMQM) command stops them.

Compile and Run Sample Programs to Verify the Queue Manager Is Operational

MQSeries for iSeries and AS/400 V5.x includes sample programs written in C, COBOL, and RPG for the ILE and OPM environments. Install these by selecting option 1 during the RSTLICPGM task. The samples are in the library QMQMSAMP, and the ILE service programs are in library QMQM. Therefore, you need to add them to your library list via the Add Library List Entry (ADDLIBLE) command. I’ll build two applications: one to place

some messages on a queue, and the other to read the messages placed on the queue. I can do this quite easily by entering these CL commands to create the bound RPG programs:

CRTRPGMOD MODULE(QMQMSAMP/AMQ3PUT4) SRCFILE(QMQMSAMP/QRPGLESRC)
CRTPGM PGM(QMQMSAMP/AMQ3PUT4) MODULE(QMQMSAMP/AMQ3PUT4) BNDSRVPGM(QMQM/LIBMQM)
CRTRPGMOD MODULE(QMQMSAMP/AMQ3GET4) SRCFILE(QMQMSAMP/QRPGLESRC)
CRTPGM PGM(QMQMSAMP/AMQ3GET4) MODULE(QMQMSAMP/AMQ3GET4) BNDSRVPGM(QMQM/LIBMQM)

I can post test messages to the queue by entering the following text at the command

line:

CALL PGM(QMQMSAMP/AMQ3PUT4)
PARM(‘ SYSTEM.DEFAULT.LOCAL.QUEUE ‘ ‘MYQMGR ‘)

Next, I’ll make sure the messages arrived. At the command line, enter the following code to view the message data:

WRKMQMMSG QNAME(SYSTEM.DEFAULT.LOCAL.QUEUE) MQMNAME(MYQMGR)

There should be three messages on the queue. The sample programs expect you to pass parameters as 48-character strings, so you will find it easiest to enter the command and use the prompt (F4) key to place single-quote (‘) characters at the beginning and end of the fields.

MQSeries messages are comprised of two parts: a message header (which contains descriptors such as data type, date and time stamp, and message identifiers) and the actual data payload. You can view both parameters from a 5250 session. Figure 4 displays how I selected option 8 (Display Data) and looked at the actual message content for message 1.

Note that the data is in text format, capable of being used by OS/400 applications. MQSeries runs on many platforms, so you may be curious about data encoding if you plan on exchanging messages with an ASCII-based platform such as AIX, or another EBCDIC- based AS/400. Each MQSeries queue manager can receive messages from any supported platform and translate them to the native format (e.g., EBCDIC for OS/400 machines, ASCII for RS/6000 machines or PCs).

Next, I’ll try reading messages from the queue. At the command line, I enter the following command:

CALL PGM(QMQMSAMP/AMQ3GET4) PARM(‘SYSTEM.DEFAULT.LOCAL.QUEUE ‘ ‘MYQMGR ‘)

I now refresh the view of messages in the SYSTEM. DEFAULT. LOCAL.QUEUE queue by using the WRKMQMMSG command, and I see that there are no messages. The get program has evidently read the messages successfully, but how can I be sure? The AMQ3GET4 application writes the messages to a spool file, and I can use the Work with Spooled File (WRKSPLF) command to verify this. In this example, the getting application has permanently removed the message. What do you do if you want the application to read the message, but not remove it? This is possible, as MQSeries also supports a browse option with the getting application.

For transactional applications, MQSeries has its own version of commitment control. An application can send and receive messages under an option called syncpoint control. Upon successful completion, the gets and puts are committed. This means that sent messages are permanently removed from queues and received messages can be retrieved by other applications. In case of error or failure, the queue manager does not commit the get and put transactions. For more complicated transactions, such as database updates, MQSeries jobs also work within the auspices of OS/400 commitment control. This feature enables what is known as a two-phase commit transaction.

Host-to-Host Communications

The queue manager is able to send and receive messages with itself, but how do you get it to communicate with applications on other systems? MQSeries uses channels to communicate. For OS/400, you can define channels via communications based on TCP/IP or Advanced Program-to-Program Communications (APPC).

Before discussing channels in any detail, it is important to define the types of hosts running MQSeries applications. The iSeries runs as a queue manager, or server. MQSeries also has clients, which typically run on PCs or workstations. The MQSeries Java client can run in most Java environments, including OS/400.

Queue managers communicate via server channels. These are unidirectional, so you must define a sender and receiver channel on each machine. Bidirectional sends and receives between two queue managers require four channel definitions: a sender and receiver on one machine, and a matching sender and receiver on the other machine. MQSeries client channels are bidirectional and communicate with queue managers having an appropriately defined server connection channel. You can dynamically define MQSeries channels or manually create them. In my example, I will configure the queue manager to accept transactions from MQSeries clients, such as a Java servlet running on WebSphere Application Server. You can easily define this channel and assign privileges by entering this command:

CRTMQMCHL CHLNAME(SERVERCONNECTION) CHLTYPE(*SVRCN) MQMNAME(MYQMGR) TRPTYPE(*TCP)
MCAUSRID(RMTUSERID)

This does two things: It provides a TCP/IP-based communications path between the MQSeries client application and queue manager, and it grants application privileges to the client at the level of OS/400 user profile RMTUSERID, or any other user profile you specify on this command (the default is *NONE which uses the client application’s user ID and typically is not appropriate for security purposes). In order for the iSeries queue manager to communicate over this TCP/IP channel, you have to enter the Start MQM Listener (STRMQMLSR) command with the following parameters:

STRMQMLSR PORT(1492) MQMNAME(MYQMGR)

Then, if you run the Work with TCP/IP Network Status (NETSTAT) command to view the connection status list, as follows:

NETSTAT *CNN

you should now see that port 1492 (the default is 1414) is active for cross-system MQM communication.

Additional Services and Components

MQSeries provides numerous additional features and capabilities for building secure, reliable applications—too many to list here. One powerful function is triggering. You can set queues to initiate calling an OS/400 application based on arrival parameters such as the first message or every message.

MQSeries uses OS/400 journaling extensively for providing assured, once-and- only-once message delivery. MQSeries for iSeries also has excellent Java support for building standalone applications or e-business applications running as servlets or Bean components. There are a number of complementary products for iSeries that can greatly aid your application development efforts, such as the MQAdapter Offering and the MQSeries Application Messaging Interface. Some are purchased items, but you can download many of them free of charge from the MQSeries home page on the Internet.

References and Related Materials

“Getting Started with iSeries Connect,” Rick Golla, Midrange Network Expert, March/April 2001

MQSeries Family Web site: www.software.ibm.com/mqseries

MQSeries for AS/400 V4R2.1 Administration Guide (GC33-1956), IBM MQSeries Family: Books Web site: www-3.ibm.com/software/ts/qseries/library/manualsa/ index/htm

MQSeries for AS/400 V5.1 System Administration (SC34-5558-00), IBM MQSeries Family: Books Web site: www-3.ibm.com/ software/ts/mqseries/library/manuals

MQSeries for AS/400 Web site: www.ibm.com/software/ts/ mqseries/platforms/os400

MQSeries for iSeries Web site (PartnerWorld, iSeries): www.iseries.ibm.com/developer/ebiz/mqseries

Connect for iSeries Framework

Java Pgm MQ Series

Pgm Call

ACD

Figure 1: MQSeries can be used for invoking server processing tasks or for ensuring that a timely response is returned to the originator.

Trading Partner Network

MQ Series

Delivery
Gateway

Flow Manager

Intra-enterprise Network

PFM

MQ Series

Connectors

Figure 2: The green-screen MQSeries command menu contains a number of options for configuring your MQSeries.

Figure 3: Use the CRTMQM to configure your test queue manager instance.

Figure 4: Be sure to take advantage of the sample programs to ensure that you are posting and reading data from your queues.

Also Read

What Does Domino 10 Really Mean?

The Domino 9.0.2 Waiting Game

Technology Focus: Employee Aids for Internal Communications