zsummeruni Hamburg WebSphere MQ for z/os

Transcription

1 Copyright IBM Corporation All rights reserved. zsummeruni Hamburg WebSphere MQ for z/os Lab Version V2.1 Monday, 14 September, 2009 Table of Contents zsummeruni Hamburg... 1 WebSphere MQ for z/os...1 General Overview... 2 General Preparation... 4 General Instructions Queue Manager Initial Configuration Review the z/os Configuration for WebSphere MQ Creating Your Queue Manager s System Data Sets Defining Start-up Parameters and Starting the Queue Manager Basic Queue Administration Basic WMQ Administration using the ISPF Admin Panels Basic WMQ Administration Using the WMQ Explorer Tool Simulate application activity using a workstation GUI MQ tool Distributed Queueing Defining Channels to Connect Queue Managers Putting Messages to a Remote Queue Exercising on Some Special Distributed Queueing Conditions End of WMQ Lab Exercises /14/2009 Wildfire-WebSphere MQ Page 1 of 38

2 General Overview Within this series of labs, you will build a "Queue Manager" (Qmgr) on z/os based on WebSphere MQ Version 7, exercise on Queue Administration, define WMQ channels to connect your QMgr with that of a partner team and exchange messages with them using some simple sample applications. You will make use of both the ISPF based z/os specific administration user interface as well as the WMQ Explorer which is an Eclipse-based GUI for administering Queue Managers on any platform. The lab can be summarized in the following main tasks: 1. Setting up and configuring a Queue Manager on z/os 2. Basic queue administration, running local applications against different types of queues. 3. Distributed Queueing: connecting Queue Managers and exchanging messages between them What has been prepared on z/os The lab environment is made up of one LPAR named SYS9. WebSphere MQ for z/os Version 7 is installed WMQ target libraries are named MQM.V700.SCSQ* 16 Queue Managers are defined as subsystems to z/os with names - MQ13, MQ14, MQ15, MQ16 - MQ23, MQ24, MQ25, MQ26 - MQ33, MQ34, MQ35, MQ36 - MQ43, MQ44, MQ45, MQ46 Likewise, student TSO IDs have been created named - TEAM13...TEAM16, - TEAM23... TEAM26, - TEAM33... TEAM36, - TEAM43... TEAM46 For each student ID, there is a working library with JCL and default input named TEAM#$.WMQ.CNTL where #$ represents the two-digit team ID. SYS

3 What has been prepared on the Workstation On your workstation, Windows XP is running as a VMWare image with the following components installed that support these exercises: A 3270 emulator as part of IBM Personal Communications, which is used to run 3270 mainframe ( green screen ) sessions for TSO access. The WebSphere MQ Server V7 software to connect to a remote WMQ Queue Manage via the network. WebSphere MQ Explorer, the Eclipse-based WMQ Administration tool, with a rich set of useful functions. RFHUTIL, an auxiliary sample application suitable to read and write messages from/ to WMQ queues.

4

5 General Instructions How to Logon to TSO 1. Double-click the Personal Communications icon on your desktop. 2. In the input field at the bottom of the screen, which is marked by an arrow ===>, enter (without quotes): tso TEAM#$, where #$ is substituted by you team ID. - the screen shot below shows the correct entry for TEAM14 - the entry string (both tso and the ID) is *not* case-sensitive. ********************************************************** * Boeblingen TMCC * * z/os * * Enter an application name or a VTAM LOGON command. * * Example: TSO userid or LOGON APPLID(applid) * *********************************************************** TSO - TSO/E (TSOMn for LOGON with Model n=2,3,4,5) CICS - CICS TS 3.2 IMS - IMS V10 z/os SYS1 z/os Wildfire Workshop IPADDR: PORT : ===> tso TEAM14 3. Press the right Strg key to actuate your input. Note that all throughout the TSO session, the data entry key is *not* the normal (carriage-return) enter key, but the right Strg key! This takes you to the TSO Logon screen, which, at the left top, looks like this: (ensure that Procedure ===> WFWBI and Command ===> wbimq7)

6 4. Tab/put the cursor to the Password entry field and enter the password announced by the instructor(s) you won t see what you type, so be sure you type carefully and hit the Enter (Strg) key again. You will see something like this: ICH70001I TEAM14 LAST ACCESS AT 16:56:06 ON TUESDAY, JUNE 17, 2008 IKJ56455I TEAM14 LOGON IN PROGRESS AT 15:37:14 ON AUGUST 18, 2008 IKJ56951I NO BROADCAST MESSAGES WBIMQ7 INMR003I You have no messages or data sets to receive. *** 5. Hit the Enter/Strg key again, which will take you to the ISPF Primary Option Menu. Instructions for the various TSO-based lab activities will start from this point.

7 1 Queue Manager Initial Configuration What this exercise is about This exercise provides an opportunity to examine a WebSphere MQ environment which has just been installed from the tapes, including the z/os system settings provided by PARMLIB members. You have to create the objects that are to support your particular Queue Manager and, and specify some variable attributes of your Queue Manager, before you may start it for the first time. 1.1 Review the z/os Configuration for WebSphere MQ This is just a browsing exercise, with no new contributions from your part. You are offered an opportunity to retrace the methods and places where and how the z/os environment has been configured so to support the execution of our set of WebSphere MQ Queue Managers. Review the APF Authorization of WMQ System Load Libraries 6. From the ISPF Main Menu, enter 3.4 in the Option ==> input field to access the Data Set Utility. 7. In the Dsname level input field, enter SYS1.PARMLIB and hit Enter (right-hand Strg ). 8. From the list of data sets shown, select SYS1.PARMLIB by placing a b (for Browse) in front of its name, as shown below, and press Enter (r-strg) again. - The member list will open, in alphabetical order. 9. Go to member PROGMQ, either by scrolling (PF8) until this name appears or by typing L PROGMQ (without quotes/ not case-sensitive) in the command entry field, and then put an S (select) in front of the name and press Enter (r-strg) again. The contents of the member shows you - the WebSphere MQ libraries defined to the z/os Linklist, - and those defined as APF-authorized, which is required for those libs. 10. Press F3 to close the member currently displayed and to return to the member list.

8 11. Split your screen by placing the cursor somewhere in the first line, and then press the F2 key. a second screen with the ISPF Primary Menu will show up. 12. From here, chose option s to invoke SDSF- the system display and search facility, which is the also the place where z/os commands can be entered. 13. In the SDSF Primary Option Menu screen, enter log (without quotes) in the COMMAND INPUT field to browse the system log. 14. Enter, in the COMMAND INPUT field of the subsequent screen the following z/os command to browse the list of APF-authorized libraries (the leading slash ( / ) indicated that your following entry is a z/os command): /D PROG,APF 15. Can you identify the WMQ libs from the (probably quite long) list of APF-authorized libraries? Note that you can scroll forward (F8) and backword (F7) the system log, and also issue searches from the command line by entering something like this: f MQM.V700 The option prev (previous) maybe added to search backwards. Review the z/os subsystem entries for the Queue Managers defined 16. Press F9 (switch) to return to your first screen. We recommend to keep the second screen active- a multiple screen configuration with at least one screen for browse/edit and another one for SDSF proves to be very useful in many practical situations when using TSO. 17. In the SYS1.PARMLIB member list, locate the member with names starting with IEFSSNM. You will find members named IEFSSNM1, -2, -3, -4,...; these are the members that define the WMQ subsystems to the appropriate z/os system. 18. Browse the member with the suffix of -9 - Can you determine an entry for the queue manager with your team number? - What is your queue manager s command prefix string? 19. Switch (F9) to the SDSF screen and enter a display command for your queue manager, entering the following string in the SDSF command line (note the starting slash) /< cpf> DISPLAY QMGR where <cpf> has to be replaced by the command prefix string determined before - Is there a reasonable response to this command? Note: we expect to see something like this, as a response: RESPONSE=SYS1 CSQ3106E +MQ14 CSQ3EC0X - QUEUE MANAGER STOPPED. RESPONSE=COMMAND NOT PROCESSED - +MQ14 DISPLAY QMGR 20. Try the same command with an arbitrary, not defined, command prefix, such as +ABCD, so enter /+ABCD DISPLAY QMGR from the SDSF command input line. -Note: we expect to see something like this, as a response to the command input from above: RESPONSE=SYS1 IEE305I +ABCD COMMAND INVALID - Can you explain why this command input produced a completely different response?

9 1.2 Creating Your Queue Manager s System Data Sets Before you can start a z/os Queue Manager for the first time, some data sets have to be created for exclusive use by this particular queue manager: - the page data sets, where the message data is stored - the log data sets, where message data is logged for recovery - bootstrap data set(s), which holds recovery related control information We also cover in this part of the exercise the set of initialization input data sets, by which various system resources (mainly queues) are defined to the queue manager. Creating your Queue Manager s Page Data Sets 21. Assumed that you still have your two-screen configuration active, press F3 in the first one until you are on the Data Set List Utility start level (alternatively, enter =3.4 in the command line) and enter TEAM#$.MQM in the Dsname level entry field, where #$ is substituted by your two-digit team ID. Just one entry will be displayed- the one representing your WMQ working library, named TEAM#$.MQM.CNTL. 22. Put an e (lower or uppercase) into the command column to the left of the library name, to open the member list for editing selected members. 23. Edit (select with s and press Enter/Strg) member MQXYPAGE and using the change... all command from the TSO command line, change all occurrences of the string #$ to your team ID. Note that this change will always be required throughout these exercises, whenever you access a new JCL template member which you are going to submit. - How many page sets will be defined for your queue manager? - You may write down here the data set names of them: - What about their sizes? 24. Submit the job, typing to the command line sub (without quotes), and then press Enter/Strg. You will see this message (shown for team #14) IKJ56250I JOB TM14PAG(JOB03584) SUBMITTED... and if you press Enter/Strg again, within a short time a message like this will show up: JOB03584 $HASP165 TM14PAG ENDED AT BOEBPCM1 MAXCC=0 CN(INTERNAL) *** 25. Switch to the SDSF screen (F9) and enter ST (status/ without quotes) in the command line to get a list of jobs that are of interest to you. In case you see (maybe a lot) of other prosecces, enter the following SDSF commands, one at a time- where #$ has to be replaced by your team-id again: - pre *#$* - e.g. pre *13* for team13, pre *44* for team 44 - owner * This will limit the list of processes displayed in your session to you own jobs and, later on, to your system address spaces.

10 26. Put an s (select) in front of the TM#$PAGE job name- which is the job you just and account for its output. We expect that all three steps complete with RC=00. ran Go to the end of the listing (max/f8) and account for the number of pages formatted per page set. Creating your Queue Manager s Log and Bootstrap Data Sets 27. In your browse/edit screen, edit member MQXYBSDS and apply the same global change as before to replace the #$ string by your team ID. Have a look at the contents of the JCL: - How many logs and how many bootstrap data sets will be prepared for your queue manager? - What do you conclude from the number of data sets created and their namings as to dual logging and dual bootstrapping? 28. Submit the job, typing to the command line sub (without quotes), and then press Enter/Strg. The same kind of intermediate pop-up messages will occur as before indicating the start and completion of your job. 29. Switch to the SDSF screen (F9) and re-enter the ST (status) command line to jump to or refresh the status display. 30. Select the TM#$BSDS job, and account for its output. We expect that all six steps complete with RC=00. Call out for help if this is not true for your job. Reviewing the Initialization Input Data Sets 31. In your browse/edit screen, copy the started task procedure JCL by which your queue manager is started, to your working library, TEAM#$.MQM.CNTL. You may do it this way: - starting from the member list of your working library, opened in EDIT mode, type S MQ#$MSTR (without quotes, with the #$ placeholder substituted, as shown below for team 14): This opens a new (empty) member with the specified name.

11 32. Copy the equally named member from the library, where the active started task procedures are placed, which is USER.PROCLIB : - the fastest way to perform this is, to type the copy command into the command line, as shown below for team14, then press Enter (Strg). - This input is not case-sensitive, but the single quotes shown are required. You now can explore the startup JCL of your queue manager (we don t want you to edit the member in its original place, as any faulty changes could make its start-up impossible). 33. Scroll forward (F8) to the SYSTEM INITIALIZATION INPUT FILES section, with DD names CSQINP1 and CSQINP Have a look, ie. browse, as described below, at least the member referenced by the CSQINP1 DD statement, and one or two of the members referenced by CSQINP2, and discuss with your team partner what you come to see. To browse a named member from within the EDIT mode, take the following steps: - copy the full library(member) name to be looked at to your clipboard (edit/copy); - type bro or browse into the command input line, hit Enter (strg); - paste the library(member) name copied before to the Data Set Name input field in the middle of the screen, but ADD a single quote in front of the name (an ending quote is not required), as shown here for team 14: The member specified will open in Browse mode. When you finished exploring a member, go back by pressing F3 (end/return) twice. 1.3 Defining Start-up Parameters and Starting the Queue Manager

12 The last activity required before the queue manager can be started for the first time, is to provide a module with start-up options, which are WMQ system attributes and settings that are variable. In z/os, these options are provided by means of a load module which is created from three WMQ assembler macros. The name of the load module has to be specified with the START QMGR command. Tailoring and assembling the Queue Manager start-up parameter module 35. Edit member MQXYZPRM in your working library, TEAM#$.MQM.CNTL and first, perform the mandatory global change to replace the #$ by your team ID. 36. Search for the string CSQ6LOGP, the name of the first macro which is used to define the logging options. The template specifies dual logging, and you have to change this to single logging: - change the TWOACTV=YES setting to TWOACTV=NO; - Be sure to put the comma immediately after the NO and keep the X in column 72. Note that this is a critical change. Your queue manager will not start if this is done wrong! 37. Search for the string CSQ6SYSP, the name of the third macro that is used to specify system attributes from different areas. - change the TRACSTR value from YES to NO; this prevents the internal trace to start automatically and saves resources. 38. Scroll (F8) to the bottom of the member and notice the name of the resulting load module. - You may write it down here- wherever it fits. - The module is link-edited into the (commonly used) library specified by the SYSLMOD DD statement of the last step. 39. Submit the job, typing to the command line sub (without quotes), and then press Enter/Strg. 40. Switch to the SDSF screen (F9) and re-enter the ST (status) command line to jump to or refresh the status display. 41. Select the TM#$ZPRM job, and account for its output. We expect that all four steps complete with RC=00. Call out for help if this is not true! Starting your Queue Manager for the first time 42. In your SDSF screen, enter the following command in the command input line (remember that the command input has to start with a slash ( / )) /<cpf>start QMGR PARM=<parm-module-name> where: - <cpf> is the command prefix string associated with your Queue Manager, as determined within step 18 of this exercise. - <parm-module-name> is the name of the parameter module assembled just before (you should have noted that name above). 43. Enter log in the SDSF command line to switch to the syslog display, if you are not already in this mode.

13 44. Browse the messages that are issued by your queue manager during start-up. - You may shift to the right using F11 to see the message texts. - Note that other teams may start their systems at quite the same time, and so the syslog messages maybe mixed from various sources. - All messages are marked by the queue managers cpf string, so MQ14 messages appear like this: CSQY000I +MQ14 IBM WebSphere MQ for z/os V CSQY001I +MQ14 QUEUE MANAGER STARTING, USING PARAMETER M Search for the following message that indicates that your queue manager has started successfully (shown for team 14): CSQY022I +MQ14 QUEUE MANAGER INITIALIZATION COMPLETE CSQ9022I +MQ14 CSQYASCP 'START QMGR' NORMAL COMPLETION 46. Note that a second address space (started task) named MQ#$CHIN is started automaticallly, right after the messages shown above have been issued. This is the Channel Initiator address space that hosts WMQ s network interface functions. We will refer to this in the next lab exercise. ************** END OF THE Queue Manager Initial Configuration LAB **************

14 2 Basic Queue Administration What this exercise is about Within this exercise, you learn to administer a running WebSphere MQ Queue Manager on z/os both by use of the ISPF Administration panels that come with the product, and the Eclipse-based WMQ Explorer that runs on the workstation. You will define some queues of different types and use both z/os batch jobs and simple workstation tools to access these queues- write messages to them, browse and remove them from there etc. Furthermore, you familiarize with the command function of the WMQ for z/os batch utility CSQUTIL. 2.1 Basic WMQ Administration using the ISPF Admin Panels The exercise starts from the ISPF primary menu, as before. It is advisable to work with a split-screen configuration again, with a fix use of the single screens: 1) to access members through the Data Set List Utility (ISPF option =3.4) 2) SDSF, to browse job output or the system log (ISPF option =s) and maybe a 3 rd one) to access the WMQ Operations and Control panels (ISPF =m) However you accomplish it, the lab instructions presume and encourage such a configuration, and will refer to the DSList screen, the SDSF screen and the WMQ screen to denote where an activity takes place. Configure the WMQ ISPF panels and check some basic functions 1. Open a new (third?) screen by typing split new into the command line at any of the existing screens Display Filter View Print Options Help SDSF OPERLOG DATE 08/19/ WTORS COMMAND INPUT ===> split new Page Buffer Total Unused Pe A new screen with the ISPF Primary Option Menu will show up; - you probably have to put the cursor to the bottom line of the visible screen and hit the F2 key to display the newly created screen. 2. From the ISPF Main Menu, enter m in the Option ==> input field to access the Data Set Utility. The IBM WebSphere MQ for z/os - Main Menu will show up. 3. You have to configure the basic settings within this screen to access your queue manager. If not already there,

15 4. enter Q (without quotes) as the Disposition 5. put the name of your queue manager to the three fields as shown below for MQ14. a. Change/set the Response Wait Time to a value in the range of 10 (seconds)- we hope that our system performance is good enough to get along with this... Disposition Q Q=Qmgr, C=Copy, P=Private, G=Group, S=Shared, A=All Connect name MQ14 - local queue manager or group Target queue manager... MQ14 - connected or remote queue manager for command input Action queue manager... MQ14 - command scope in group Response wait time seconds These settings will remain in place for all ISPF based exercises; the other input fields will vary, dependent on what you are going to do. 6. To display the queue manager attributes, enter (everything without quotes): - 1 as the Action id; qmgr as the Object type (not case-sensitive); * as the Name as shown below, then press Enter/Strg. Complete fields. Then press Enter. IBM WebSphere MQ for z/os - Main Menu Action List with filter 4. Manage 1. List or Display 5. Perform 2. Define like 6. Start 3. Alter 7. Stop 8. Command Object type qmgr + Name * Disposition Q Q=Qmgr, C=Copy, P=Private, G=Group, S=Shared, A=All This inquiry is equivalent to the DISPLAY QMGR MQSC command. The result is displayed by mutliple panels, within which you can scroll forward and backward (F8/F7). 7. Return to the WMQ Main Menu (F3) and select Action 3 (Alter) instead of 1 (Display), then press Enter/Strg again. 8. You may now change (alter) some attributes- but you should do so very carefully and be sure you know what you are doing. An uncritical setting is the Description that appears in the first result screen- you may add additional text in the second line, such as Tom's and Tina's zqmgr. Hit Enter/Strg to make your changes effective Choose action 1 (Display) again, place the cursor in the object type field (which need not be cleared), and press F4 (Prompt) to get a list of valid Object Types. - There are three lists, between that you may scroll (F8/F7). 11. From the first list, select 1 (Queue) and press Enter/Strg. - be sure the Name field is still set to * - press Enter/Strg again to run the inquiry to display all queues. - how many queues are there (see the hint in the upper right corner: Row 1 of?? )

16 Note: This is the set of queues that have been created as system objects by the commands contained in the system initialization input members. Define Queues using the WMQ ISPF panels First, you are going to change some attributes of SYSTEM.DEFAULT.LOCAL.QUEUE in order to avoid that queues which are defined like this, do not stress the queue manager and the system environment too much. 12. Start with DISPLAYing all the queues whose names start with the characters SYSTEM.DEFAULT 13. Using the Alter option in the WMQ ISPF panels, change the following characteristics of the queue named SYSTEM.DEFAULT.LOCAL.QUEUE- use F8/F7 to scroll through the panels and press Enter (Strg) only when you completed all of the changes: a. Provide a description, such as Team#$ local queue default settings c. Set the maximum number of messages to be hosted by that queue to e. Reading messages from this queue is to occur in the sequence the messages arrived on the queue. f. Messages written to this queue shall not be larger than 9,999 bytes. 16. Start with displaying all existing Alias Queues (it won t be thus many..), and refer to the SYSTEM.DEFAULT* object to create your first alias queue, named LAB2.ALIASP, that allows for PUT requests, but disallows GETs. 17. Define a second alias queue, named LAB2.ALIASG, that may be used for GETs but not for PUTs. 18. What about its maximum message length and its current depth? At last, b. Change the Storage Class to be used to WILDFIRE d. Permit shared read (GET) access and specify shared access as the default for input 14. Now DEFINE a local queue LIKE the modified template from before (SYSTEM.DEFAULT.LOCAL.QUEUE). Name the new queue LAB2.Q Display the attributes of queue LAB2.Q1 and answer the following questions a. Which Storage Group will host this queue? b. What is the Maximum queue depth? You have already learned about alias queues. You will now create two ALIAS queue definitions that refer to LAB2.Q1 as their target queue, one that allows for GET requests and disallows PUTs:

17 19. DEFINE a local queue LIKE SYSTEM.DEFAULT.LOCAL.QUEUE. Name the new queue LAB2.Q1. Put and get messages to and from queues using simple batch programs This part of the exercise can be completed best with a 3-screen-configuration, as described by the introductory notes for this section, on page 14. We assume that the sample program function and the way it is invoked through variable parameters has been explained before- feel free to ask the instructor(s) if you don t know. 20. Switch to the DSList screen and locate member JCLPUT in your working library, TEAM#$.MQM.CNTL. 21. You have to run two (2) global change commands to make the JCL executable.: 22. change the #$ string to your team ID 23. change the (remaining) occurences of the single # character to the system number you are working with (SYS9) 24. When you performed these changes, the PARM string will reflect the correct settings to write ( MQPUT): (3 paramet er) persistent (6 th parameter) messages, 26. each made up of 1,024 (5 th parameter) X characters (4 th parameter), 27. to the queue named LAB2.Q1 (2 nd parameter) through your queue manager MQ#$ (1 parameter) 28. Submit the job and swap to the SDSF screen (maybe you have to use the split new function first to create it) in order to check its output. 29. Don t be worried, if an error is indicated- this is a designed one! - Refer to the Appendix A. API completion and reason codes section of the WebSphere MQ for z/os Messages and Codes manual provided as a PDF file on your desktop to look u p the error code shown. - Can you determine, from the output listing and the reason code shown, the error cause? - Discuss with your team partner before you continue; the solution is provided below. 30. To make the program work, i.e. to make your LAB2.Q1 queue usable, you have to define the Storage Class referenced by the queue definition. Remember, step b adviced you to change the storage class name of the default local queue definition, and your self-defined queues adopted this setting. - Switch (swap) to the WMQ panels screen, and DEFINE a new storage class object named WILDFIRE, and associate it with page set number 2. - Note that you always start with a Display operation, then select one of the existing objects as a template to create a new one of the same type. st 31. Swap back to the screen with the JCLPUT member and submit the job again.

18 32. Check for the job output in SDSF: - we expect that the job now runs with Return Code (RC)=00 - the application program protocol at the bottom of the listing indicates what WMQ activities have been performed. 33. Optional step at this point: - Are you able to determine from the WMQ panels that the LAB2.Q1 queue now has 100 messages placed on it? 34. Submit the JCLPUT job another three times, once for each of the other queues created before, as shown by the table below, after appropriately varying the PARM string, to write: - 33 persistent messages, - each with 512 bytes in length, - continue to use the X as the padding character. Try to discuss and predict what will happen at each of the attempts, and write down your prediction, together with the real results that you determine from SDSF after the job executions. - Use the WebSphere MQ for z/os Messages and Codes manual to determine the meaning of any non-zero return codes that may appear. - Can you explain why one of the 3 attempts to write messages fails? Queue Name Prediction Result LAB2.ALIASP LAB2.ALIASG LAB2.Q2 35. Find the most suitable way to determine the current depth (number of messages) for each of your LAB2.* queues and note the results in the table below. - You may again dare to make a prediction, if you like. - Anything surprising? Kommentar: OK- messages written Kommentar: MQOPEN fails with RC=2053 (Put inhibited). No messages can be written. Kommentar: OK- messages written Queue Name Prediction Result LAB2.Q1 LAB2.ALIASP LAB2.ALIASG LAB2.Q Basic WMQ Administration Using the WMQ Explorer Tool Since Version 6 of WebSphere MQ, the Eclipse-based WMQ Explorer Tool that runs on Windows and Linux, can also beused to fully administrate z/os Queue Managers. Of course, a network connection must be active between the workstation that hosts the Tool and the z/os Queue Manager(s) to perform the remote management. So the first step of this part will be, to provide the prerequisites for this network connection to work, then you have to introduce the z/os Queue Manager to the E xplorer Tool by its name and connection specifications, and if you perform these steps correctly, you will be able to manage and control your mainframe Queue Manager from the powerful Explorer GUI.

19 Start the Queue Manager s TCP/IP listener to enable inbound communication The Channel Initiator address space, which is the communications component of WMQ for z/os has been automatically started with your Queue Manager. The listener that enables inbound communications has to be started separately, and this didn t happen yet. 36. D isplay the status of your Queue Manager s communication component, which is done through the DISPLAY CHINIT MQSC command. St art with the Display option (1.), with the Object Type set to SYSTEM, and select 1. Distributed Queueing in the subsequent panel. Amongst others, the command response will show these two lines that indicate that no listener process is running (shown for MQ14): CSQX848I +MQ14 CSQXRDQM TCP/IP listener INDISP=QMGR not started CSQX849I +MQ14 CSQXRDQM LU 6.2 listener INDISP=QMGR not started 37. The MQSC command to start the TCP/IP listener is (with all default settings in effect): START LISTENER PORT(<port-number<) Equivalent to the DISPLAY CHINIT command before, there are multiple ways to issue the command (the 3 rd one is, from the SDSF command line, as z/os command). The port number to use is 140#$, where #$ is to be replaced by your team ID, so for MQ13, for MQ14, for MQ23 and so on. To issue the command via the WMQ ISPF panels, - start with Option 6.Start, while the Object Type is set to SYSTEM; - in the following panel enter 2. as the Function type for Channel listener, which activates just the bottom section of the screen; - enter a T into the Transport Type field and the 140#$ port number into the Port Number (TCP/IP) field, - then press Enter (Strg). The CSQ9022I +MQ14 CSQXCRPS ' START LISTENER' NORMAL COMPLETION message should appear. 38. Repeat step 36 to display the CHINIT status. One line within the response should be changed now, looking like this: CSQX846I +MQ14 CSQXRDQM TCP/IP listener INDISP=QMGR started, for port address * CSQX849I +MQ14 CSQXRDQM LU 6.2 listener INDISP=QMGR not started 39. Display the SRVCONN channel types defined to your Queue Manager (although this hasn t been covered yet by the lectures), using the Display function with the Object Type set to SVRCONN and the Name set to *. You will see three (3) entries, the first of which wil be used to support the connection of the WMQ Explorer Tool: SYSTEM.ADMIN.SVRCONN SVRCONN QMGR MQ14 INACTIVE SYSTEM.DEF.SVRCONN SVRCONN QMGR MQ14 INACTIVE WAS.JMS.SVRCONN SVRCONN QMGR MQ14 INACTIVE

20 40. To automate the start-up of the TCP/IP listener with reference to the correct port number, return to your TSO session and edit member CSQINPX of your working library, TEAM#$.MQM.CNTL, - locate the line that contains the START LISTENER command; - remove the asterix ( outcomment ) in column 1, thus activating this command line; - replace the ++port-number++ string with the real port number (140#$) ; - save the member (F3). Note that this member is referenced by the CSQINPX DD name of the MQ#$CHIN started task procedure, so its contents take effect whenever the Channel Initiator address space is (re-)started.

21 Start the WebSphere MQ Explorer and configure your z/os Queue Manager 41. On your workstation desktop, start the WebSphere MQ Explorer, either from the workstation s Start Menu or from the appropriate desktop icon and accept the default Workspace location offered. If the Welcome view shows up, close it. 42. In the navigator panel on the left-hand side, select right click on Queue Managers Show/Hide Queue Managers, then hit the Add-Button in the upper half of the screen to include a new queue manager. 43. During the subsequent Add Queue Manager dialog steps, enter the specifications that identify your Queue Manager on z/os: a. 1 st panel: the Queue Manager name: MQ#$, and keep the connect directly option checked, then click Next b. 2 nd panel: keep the Specify the connection details option checked, and enter - host name or IP address: port number: 140#$ (where #$ is your team ID) - Server-connection channel: SYSTEM.ADMIN.SVRCONN (set by default) - let the auto-refresh settings default to the values offered. Press Finish and complete the configuration and connect to the Queue Manager. 44. When an entry for your z/os Queue Manager appears in the Shown Queue Managers table with the symbol of active system, your connection has been established. Klick Close to return to the Explorer base perspective. The newly defined Queue Manager shows up in the navigator list and you can expand the section to access the various types of resources. Perform some queue administration functions using the WMQ Explorer 45. Click on the Queues folder in the navigator view. The content view to the right of the Explorer screen will fill with the list of existing queues. - If the list includes the SYSTEM.* queues, click the Show System Objects icon (see the cursor position in the following screenshot) to exclude them. Afterwards, the list only contains the LAB2.* queues you defined yourself before and a queue named WAS.BROKER.*** which is a system queue to support the broker.

22 46. Shift right within the Queues display result to see the column with the current number of messages per queue. - Do the numbers displayed match with the ones determined at step 35- they really should! 47. To define another local queue named LAB2.Q3, - right-click on the Queues folder in the navigator pane, then select New Local Queue; - enter the name of the new queue, LAB2.Q3, and as we accept the SYSTEM. DEFAULT.LOCAL.QUEUE as the template, you could just hit Finish here; but you may also click Next, and browse the various sections of queue attributes that may be tailored. 48. The WMQ Explorer offers an option to browse messages on a queue, which cannot be performed by the ISPF panels. - Right-click the LAB2.Q1 queue entry in the list of queues and select (click) the Browse Messages option. - A panel opens that shows you the formatted MQ message descriptor (MQMD) and the frist?? bytes of the message data. - What is the put application name shown? - What is the message type of the messages? - Why does the message data field show XXXXXXXXXXXXXX...? - Double-clicking a single line opens a new pane with the full details of the particular message, including the full message data area. - Click Close to return to the normal Explorer view. 49. You can also clear messages from a queue, but only all at a time. The same function is also available with the ISPF panels, as it is an implementation of the CLEAR QLOCAL MQSC command. - Right-click the LAB2.Q2 queue entry and select the Clear Messages option. - Can you guess the difference between the two clearing methods offered? - At this point, either method may be checked when you hit the Clear button. Optional section: Define a filter and a new scheme to easily identify queues with messages Kommentar: TM#$PUT, which is the job name of the JCLPUT jobs Kommentar: DATAGRAMthat s the type the JCLPUT sample program uses Kommentar: well, that s the message contents, denoted as padding character by the JCLPUT sample program Kommentar: it s stated quite clearly; one uses a command, the other uses the MQGET interface to remove messages. The command option can only be used if the queue is not opened by another process.

23 This section does not produce any new WMQ objects or messages- so it is declared optional. But it will simplify the further activities by configuring the WMQ Explorer so you can easily display only queues that contain messages, and immediately see the columns with the number of messages. This is peformed by managing filters and schemes. 50. Inside the queue display contents screen from the previous exercise, click the down arrow at the right of the scheme name field, at the right-hand bottom of the MQ Explorer window, and select the Manage Schemes function. 51. Inside the Manage Schemes dialog, select Add and specify as a new Scheme name My QLOCAL. 52. On the left-hand selection, switch from the Distributed to the z/os selection; and apply the following changes to the right-hand table: a. remove the QSG disposition attribute (something with shared queues); b. move up the current queue depth attribute to the 3rd (third) position; c. move down the Definition type attribute to behind the Open output count field d. move up the Page Set ID field (which is at position 61 by default) to position 6 (hint: there is an easier way than hitting move up 55 times...) So far, the result should look like this: 53. You may perform some more re-arrangements if you like. 54. Finish selecting OK twice. Your newly defined scheme will immediately be applied to the current display of queues. Doesn t it look already much better? We re going to apply another improvement! 55. Open the Manage Filters dialog by clicking the down-arrow on the right-hand side of current filter name field, as shown here:

24 56. Within the next screen, select the all local queues default filter as a template and click the Copy As... button below. 57. Specify as your new filter name: Qs With Messages, first hit OK, then hit the Edit button to tailor the newly created copy -now the Edit Filter input shows up. 58. Here, keep the first two selections as to the Queue name and the Queue type but add a third one by checking the box before the second AND as shown below and specify a clause to display only queues with a current queue depth greater than zero. 59. Moreover, associate this filter with your My QLOCAL scheme just created- this is offered via another check box at the bottom of the active pane. 60. Click the OK button twice- and the empty queues will disappear from the Explorer contents view. Note that you may return to the previous display at any time by just selecting the Standard for Queues filter again. 2.3 Simulate application activity using a workstation GUI MQ tool Within this section, you make use of a workstation tool named RFHUTIL that offers a graphical user interface to handle WMQ messages. Unlike the primitive JCLPUT batch program, it offers control of all MQI options when writing and reading messages, and you can edit the message text as you like. Anyway, we will continue to use some TSO based utilities to access queues and messages. Setting up the RFHUTIL workstation utility Some background information regarding RFHUTIL: RFHUTIL is offered for free as a so-called SupportPac to assist development and test activities in the WMQ and WebSphere Message Broker area. Messages may be are stored as files, which are then read by the application and written to a WebSphere MQ queue, or vice versa. The program is GUI based. Command line performance measurement utilities are also provided within this support pack. You can download this SupportPac for free from

25 8&lang=en. For using this GUI, it is necessary to have WebSphere MQ Server or WebSphere MQ Client installed on your workstation, where you want to use it. On your workstation WebSphere MQ Client is already installed. MQ Client provides an interface for all MQ applications on the application machine (client machine) to establish a MQI Channel connection to the Host (WebSphere MQ Queue Manager/Queues) 61. To configure RFHUTIL to access your z/os Queue Manager, open the c:\student\tools\rfhutil\startup_rfhutil.bat file for editing with right-click edit ; - replace the # and $ placeholders according to the IP address and listener port used by your z/os Queue Manager, as shown above for team 14, then save the file. Note that we are using rfhutilc, which uses the WebSphere MQ Client environment to connect to the queue manager. 62. Start RFHUTIL by clicking the icon on your desktop for the file just edited and wait until the RFHUTIL GUI shows up (this may take a few moments, as it s Java...) 63. You see the GUI: Writing/browsing/reading messages with RFHUTIL The next step is to write a message on an existing local Queue to verify that RFHUTIL is correctly connected to your Queue Manager. You can check, if the message was put on the queue with WebSphere MQ Explorer.

26 64. Create a Text (*.txt) file on your desktop (you may name it message1.txt ) with some text that to write as a message to one of your previously defined queues. 65. Enter any text to the file, e.g. what is shown below, then save it and close the text editor. 66. In the RFHUTIL GUI, 67. activate the (one) existing entry from the Queue Manager Name selection bar, you have to which shows the connection controls for your z/os Queue Manager specified as MQSERVER environment variable by your *.bat file; 68. open/select the file using the Open File -Button; a. enter the Queue LAB2.Q2, which you defined previously - finally, hit the Write Q button (once or twice or...), which will launch the MQ activity. Successful (or failed) execution is reported within the large frame on the left bottom of the GUI panel. side

27 69. Switch to the WMQ Explorer to verify that the message arrived on named queue. 70. If you performed the steps on filters and schemes, you can keep (and just refresh) your last view with the scheme and filter you created. Else choose the all local queues filter and have the system queues excluded. - does LAB2.Q2 show a message count of 1 or more? 71. Start browsing the first (or only) message on the LAB2.Q2 queue using the menu option Browse messages when selecting the queue. You can see The data/time when the message was put on the queue Who put the message on the queue The message data (the text you entered in the text file) Feel free to examine all fields, displayed by the Message browser. 72. You can also use RFHUTIL to check if messages have arrived on your queue and to perform other kinds of application accesses to your queues. Particularly, you may (destructively) read selected messages, thus removing them from the queue, which cannot be done from the WMQ Explorer. Check some RFHUTIL functions, as described here: The number of messages on the queue is indicated within the Queue depth frame. Clicking the Display Q button shows you some selected MQMD fields of the message on the queue as a list. Click Close to return. The best way to look at (browse) the messages on the queue, is to click the Start Browse button on the Main pane: The contents (data) of the first message is shown in the Data pane.

28 The Data panel offers a BrowseNext button by which you can step through the messages. You have to click End Browse button to finish browsing. Two questions to discuss with your partner: a. With >1 messages on the queue, which one will be removed when you just use the Read Q option of the Main panel? b. Can you guess a way to read/remove a particular message, leaving the others on the queue? Can you make it? Kommentar: while browsing, switch to the MQMD pane and use the Copy Msg to Correl Id function offered. End Browse and (in the Main pane) check the get by Correl Id option, then Read Q that should do it!

29 3 Distributed Queueing What this exercise is about Within this exercise, you connect your z/o S Queue Manager with that of another team, allowing the systems to communicate to each other. You will work with Remote Queues and experience some special conditions that may occur with distr ibuted queueing. 3.1 Defining Channels to Connect Queue Managers You may perform this part of the exercise either by use of the WMQ ISPF panels, or on the WMQ Explorer, or use a combination of both. Appropriately, the instructions will tell you what to do, but no longer how you have to do it (with some exceptions where the authors think that you need some help). The idea of this exercise is that Queue Managers are interconnected as pairs, following the rule that each of the odd-numbered teams connects to the system with the next higher number, so: - MQ13 connects to MQ14, - MQ15 connects to MQ16, and so on. According to this rule, write down for your partner system: Remote Queue Manager name: (MQ#$) Remote IP address and port: ( (140#$)) Define a sender channel 1. Within the Explorer navigator, channel definitions are contained in the Advanced folder. 2. Define a new sender channel, based on the default object, with the following characterictics mandatory to specify:

30 Choose <your QM name>.to.<partner QM name> as the name of the channel. If team13 connects with team13, team13 s sender channel is named MQ13.TO.MQ14, and team14 s sender channels is named MQ14.TO.MQ13. the transmission protocol is TCP/IP; you have to specify the IP address of your partner system, with the port number used put in brackets as the Connection name; point to you a queue with the name of the remote Queue Manager you connect to as the transmission queue- you will create this queue in a minute; provide a description, if you like. Define a transmission queue 3. Define a new local queue with the following special attributes: use the name of the remote Queue Manager you like to connect to as the queue name; be sure you specify its use as a transmission queue appropriately; refer to the REMOTE storage class; allow for a maximum message length of 100,000 bytes; as a sender channel is going to be triggered from this queue, triggering has to be activated and some particular triggering options have to be specified: - trigger type = first - initiation queue = SYSTEM.CHANNEL.INITQ this is an existing system queue - trigger data = the name of the sender channel just defined; you may provide a description. Hint: If you are using the WMQ Explorer, you might have to switch the filter to have the new queue displayed withinb the contents pane. Kommentar: USAGE(XMITQ) Define a receiver channel 4. Define a new receiver channel, based on the default object. The only thing you have to care for is, to be sure that you use the correct name- the one your partner team used for their sender. Check the newly defined channel s operability 73. Make sure your partner team has also progressed so far (else, you may either just wait or advice them in some way- if they like...); then use the PING CHANNEL function aginst your newly defined sender channel to check the connectivity. You may perform this both from the Explorer and the ISPF panels. in the WMQ Explorer, start with right-clicking the sender channel, then click the Ping option. The pop-up panel will tell you about the success or failure of the operation

31 in ISPF, start with a display of your channels; - use action code 5=Manage to invoke the Manage Menu for your sender channel; - use function code 2=Ping to invoke the ping operation. A message will inform about the success or failure of the operation. 74. Check the system log for traces of the ping operation performed. In TSO, switch to the syslog option of SDSF (=s;log - maybe you still have an SDSF screen active), and search for a sequence of three messages like this: +CSQX500I +MQ14 CSQXPING Channel MQ14.TO.MQ13 started +CSQX500I +MQ13 CSQXRESP Channel MQ14.TO.MQ13 started +CSQX501I +MQ13 CSQXRESP Channel MQ14.TO.MQ13 is no longer active These three messages (with the appropriate channel name) indicate what the PING really is: a start-up of the channel followed by an immediate, but regular stop. 3.2 Putting Messages to a Remote Queue 75. Define a remote queue named TEAM??.Q1 that points to your partner team s LAB2.Q1 local queue. Again, you may use the WMQ Explorer or ISPF to do this. 76. Within the lab_files folder on your Desktop, create a text message file as in the previous exercise (or re-use that one) and edit an appropriate text such as Team 13 attempt to put a message on a local queue owned by team Start RFHUTIL, read the file contents and put the message on the remote queuemaybe two or three times- be sure RFHUTIL indicates that the message(s) has/have been sent successfully. Notes: - It s still your queue manager that you access with the RFHUTIL program- another one will not work! - you have to direct RFHUTIL to the remote queue name you just defined! - The write (MQPUT) has been successful if RFHUTIL indicates message sent. Check if the messages have been transmitted to the partner system

32 78. Switch to the display of the channels, and check the status of your sender channel (you may have to refresh the display). - is the channel now running (it should be)? If the channel is not running, - check the Triggering properties of your transmission queue (step 3.) - call out for help if you don t come along by yourselves! Check the status of your running channel, which is worth to be done both with the WMQ Explorer and with the WMQ ISPF panels: In the WMQ Explorer, right-click the channel name, then select Status / Channel Status - the information of interest is the counter in the Messages column: - we expect that the number shown here is the number of messages you issued via RFHUTIL. With MWQ ISPF, start again with Display Channels, then hit F11 for Status the status list of the currently active channels is displayed, and here as well, the Messages field shows the number of messages that successfully went over the channel since it was last started. Note that this is all you can confirm locally, ie. within your Queue Manager. You cannot determine what happened on the partner side, unless you directly access the appropriate Queue Manager -or, in the case of our exercise, ask your partner team :-) 81. Check the receiver channel s status appropriately. As long as it isn t running and it doesn t inidcate that messages have been transmitted, there s no use to look for the message on a local queue. 82. If one or more messages have come in via your receiver channel, check your queue LAB2.Q1 as to the number of messages contained and browse at least one of them with RFHUTIL.

33 3.3 Exercising on Some Special Distributed Queueing Conditions Please note: Within this third part of the Distributed Queueing Lab, you may split roles between you and your partner team in the way that one acts as the sender, the other one as the receiver of messages. Therefore, activities are marked appropriately. But you may as well continue to cover both parts- just be aware of what you are doing and agree with your partner team! Next, we like to put a message on a remote queue without a remote queue definition in place. This is supported by the MQI, and so it is by RFHUTIL. You may continue to refer to the message contents you used before, or create a different one and load it via the RFHUTIL Open File function. 83. Sender side activity Specify LAB2.Q2 as the destination Queue Name and refer to your partner team s queue manager in the RFHUTIL Remote Queue Manager Name field, but be sure to keep the name of your queue manager as the one to connect to. 84. Activity by Sender, Receiver accounts for results Again, launch the message (Write Q) two or three times. - Does RFHUTIL indicate that the messages have been sent? - Check as before if the messages really have passed your sender channel. - Ask your partner team to confirm that the messages have arrived on their LAB2.Q2 queue. 85. Activity by Sender, Receiver accounts for results What do you think happens when you specify a wrong queue name? Let s try! Change LAB2.Q2 to LAB2.QX or whatever (non-existent) queue name you like; keep your partner QM name as the Remote Queue Manager Name, and hit the Write Q button twice. - What does RFHUTIL say? - What does the channel status say? - Where are the messages? (a very difficult question at this time- just continue even if you can t find an answer!) 86. Activity by Sender, Receiver accounts for results Within RFHUTIL, select the MQMD section and, near the right bottom of the pane, check the Persistent Msg Yes option to mark the messages written as persistent. Kommentar: message sent - no error indication! Kommentar: still running, all messages are sent Kommentar: they have been discarded- as they were nonpersistent

34 Return to the Main section, and hit the Write Q button another two times to send two more messages. - Is there any difference in behavior compared to the step before? 87. Sender side activity If the status of your sender shows Retrying now, then go to TSO/SDSF;log and watch there for messages related to your sender channel. This is what we expect to find: +CSQX500I +MQ14 CSQXRCTL C hannel MQ14.TO.MQ13 started +CSQX500I +MQ13 CSQXRESP Channel MQ14.TO.MQ13 started +CSQX565E +MQ13 CSQXRESP No dead-letter queue for MQ13, channel MQ1 4.TO.MQ13 +CSQX527E +MQ14 CSQXRCTL Unable to send message for channel MQ14.TO.MQ13 +CSQX036E +MQ13 CSQXRESP Unable to open LAB2.QXYZ, MQCC=2 MQRC=2085 +CSQX599E +MQ13 CSQXRESP C hannel MQ14.TO.MQ13 ended abnormally +CSQX506E +MQ14 CSQXRCTL Message receipt confirmation not received for channel MQ14.TO.MQ13 +CSQX599E +MQ14 CSQXRCTL Channel MQ14.TO.MQ13 ended abnormally At this place, some explanations may be required: - on the originator/sender side, everything was fine, as there was/is a transmission queue with the name of the destination queue manager via which the messages could be sent; - on the receiving side, the destination queue proved to be not existent (RC=2085); - normal behaviour in this case is to put the message(s) to the dead-letter queue, but there is non defined; - so the receipt of the message is denied- and the channel closes; - the sending side retrys to start the channel, according to the retry options specified with the channel definition. - The corrective action is, to define and activate a dead-letter queue for the (destination) queue manager. - A ready-to-use dead letter queue definition including its activation for Queue Managers on z/os is provided by the installation, within member CSQ4INYG of the SCSQPROC library that can be activated by a pre-configured batch job. 88. Receiver side activity- but all teams should perform the tasks 88 through 93. In TSO, open or switch to a DSList (editing) session, edit your working library T EAM#$.MQM.CNTL, and start editing a new member named CSQ4INYG by typing S(elect) CSQ4INYG (without quotes) in the Command line, as shown below.

35 89. T hen type the copy command shown below in the command line and hit Enter (Strg). File Edit Edit_Settings Menu Utilities Compiler ssssssssssssssssssssssssssssssssssssssssssssssssssssss EDIT TEAM14.MQM.CNTL(CSQ4INYG) Command ===> copy 'MQM.V700.SCSQPROC(CSQ4INYG)' ****** ***************************** Top of Data ***** 90. Apply the following changes to the contents copied: change all occurrences of ++qmgr+ + to the name of your Queue Manager (note where and how the QM name is used. locate the line with the ALTER QMGR command, and uncomment (remove the * characters from column 1) from the following lines until the one with the AUTHOREV( DISABLED ) entry. You may specify a different description with the DESCR attribute, maybe something like: DESCR( ' MQ14, V7 QMgr on z/os owned by Paul and Mary' ) Advice: Do not use quotes and apostrophes within the description string. Save and Exit with F3 91. Edit (select) the UTILCMD member of your TEAM#$.MQM.CNTL library, which invokes a utitlity program that issues commands to a running Queue Manager, and apply the following changes to the JCL contained therein: Apply the mandatory global change of and the # character(s). the #$ In the CSQUCMD DD statement, change the member referenced as the command input to the one edited before, CSQ4INYG. 92. Submit the job and switch (swap) to an SDSF;st screen to look at its output. The job output summary at the bottom of the listing must look like this: ***************************************************************** * End of CSQ4INYG ***************************************************************** CSQU057I 4 commands read CSQU058I 4 commands issued and responses received, 0 failed CSQU143I 1 COMMAND statements attempted CSQU144I 1 COMMAND statements executed successfully CSQU148I CSQUTIL Utility completed, return code=0 ******************************** BOTTOM OF DATA ***************** Note that the job will run with RC=00 even is some of the commands have failed, so this summary is important to check. 93. Switch (swap) to the WMQ screen and account for your Queue Manager s attributes (Action= 1 (List/Display), Object Type= QMGR).

36 - we expect that the newly created attributes are visible on the first response panel, like this: Display a Queue Manager - 1 Press F8 to see further fields, or Enter to refresh details. Queue manager name.... : MQ14 M Description : MQ14, V7 QMgr on z/os owned by P aul and Mary Default transmission queue : MQ14.DEFXMIT.QUEUE Dead-letter queue..... : MQ14.DEAD.QUEUE Trigger interval..... : millisecon - Can you also verify that the two queues specified herein do exist? If you act as a sender of messages, 94. Sender side activity - Make sure your partner team has completed tasks # 88 through Check the Overall channel status of your sender channel using the WMQ Explorer. If it s running, continue with the next task. If it s still in the Retry state, try to start it by hand (right-click / Start) - It should enter the running state now! Receiver side activity Check where the messages (which were destined for a non-existing queue) have gone. - We expect them to go to the newly defined dead-letter queue (MQ#$.DEAD.QUEUE) that now should also be visible on your Qs With Messages filter view, if you created that before. Receiver side activity- optional The dead-letter queue can be accessed as any other queue- it will be specially protected in a production system however. Use the RFHUTIL Display Q function to access the messages on the DLQ (MQ#$.DEAD.QUEUE) and Start Browse. Check the Data section message your partner team wrote. of RFHUTIL for the Switch to the DLQ Tab of RFHUTIL and be sure the Include DLQ header option is checked: - here you see the Reason (2085= unknown (=invalid) object (queue) name) why the message was placed on the DLQ and the name of the destination queue that was specified by the originator. Using RFHUTIL s Move Q function (Main tab), you may move the messages from the DLQ to one of your self-defined local queues. When doing so in real life, you would make sure to have the Remove the DLQ Header option checked.

37 97. Sender side activity (but may be performed by both teams at the same time) One last send message test: From the RFHUTIL Main section, - open a message text file of your choice, - and use LAB2.Q2 as the Queue Name; - and a phantasy name, such as Mr.Bean as the Remote Queue Manager name. - Be sure you always have your QM specified as the QMgr name to connect to (1 st field) -W hat do you think will happen when you try to write the message(s)? 98. Initiate the MQPUT by hitting the Write Q say, three times. - surprised on what you see? - Where have the messages gone? - Hi nt: Use the Explorer to display the (non-system) queues that contain messages. There is (at least) one that contains exactly the number of messages you just produced. Kommentar: Default Transmission queue 99. Clean up your queues Find a way to clear all messages from your non-system queues. Thus, we have a clean environment when we start the next part of the exercise. 4 Fehler! Verweisquelle konnte nicht gefunden werden distributed Queueing31 4 Kommentar: (nearly) no more non-persistent data pages are being used Kommentar: we expect a RC=2192 PSID full condition after about 250 messages have been written