I have just done the bare minimum for this release. If users find it useful then I would imagine greater flexibility will be added in the future. Figure Print Dialog Selecting the Print This dialog displays the general parameters which will be used for printing.
Printer Details Displays information about the selected printer and paper size To change the printer and the general values chosen you can select the 'Printer Setup Printer Setup Pressing this button will bring up the system printer dialog.
The exact format of this dialog is system dependent. However, it should allow the user to select the printer, the paper size, the paper orientation, pages to print and probably a whole host of printer specific options. On some systems the button to apply the changes in the printer dialog is Print. No printing will actually take place when this button is pressed. Print Preview Pressing this button will display a simple window showing what the print output would look like with the current settings.
This allows the user to modify various values like margins, font size,. As values are changed in the main print dialog the preview will change immediately showing the effect of the value5. The print preview menu allows the user to select how many pages to display and what the size of each page is relative to the size of the window.
Print Button Only when this button is pressed will any data be sent to the printer. The button will change to a cancel print button which allows the user to cancel the print operation if necessary. Margins This Tab will show graphically the printable area of the page. There are two types of setting:. Margins These fields allow the user to set the vertical and horizontal margins on the paper. Values are in millimetres.
Overlap When printing large dialogs it could be that to print all the information the output will need to be spread across multiple pages. In this case the program prints each page as though it were part of one large logical piece of paper. After printing the pieces can then be placed side by side to see the whole output. If multiple page output is required the Overlap values tell the program how much of an overlap is required between each page.
An overlap ensures that a relatively seamless join can be made between the multiple sheets. Overlap values are specified in millimetres. Choose Font This button will display a dialog allowing the user to select the required font for printing. This font is not related in any way to the fonts selected for dialog screen display. The currently selected font is displayed in the box to the left of the Choose Font button.
Line Spacing This field allows the user to change the spacing between successive lines in the print output. The value is expressed as a percentage of the currently selected font height. Title, Header, Footer These Tabs allow a user specified string to be printed along with the printed text. The title is printed once, across all the top most pages.
Headers and Footers are printer at the top and bottom of each page respectively. It is useful to be able to put values rather than just a known string at the top and bottom of the page. For example, you may wish to print out the date and time as a footer. To allow this, inserts may be specified in the text. These are as follows On Windows 95,98,Me the preview window is a monochrome bit map so the print colour will not be reflected in the displayed output.
This is due to a bit map size limitation on these platforms. Sun, Mon, Tue Day e. Sunday, Monday, Tuesday Day of the month e. Jan, Feb, Mar Month e.
Not all of these values are available all the time. For example the Queue Manager may be meaningless for some printouts. We need a way of switching off text if a variable is not present. The answer is to enclose the text in brackets. Printing Lists When printing lists the application will print titles for the fields at the top of the upper pages. The titles shown will honour the List Titles choice made in the list dialog window. However, there can be a slight difference with the Auto setting.
The Auto list title setting tells the dialog to use short or full titles depending on whether there is room on the dialog. In printing there isnt quite the same concept of room on the dialog. For printing therefore Auto means. Exporting Definitions I was asked for an option to write the displayed dialog information to a file. There are essentially two reasons why this may be useful. You want to embed the information into some other document In this case the information needs to be exported in human readable text form.
You want to capture the information so the object can be defined on another Queue Manager In this case you really want the data exported in MQSC define format. On most of the dialog displays an export option is available in the pop-up menu. The dialog displayed allows the user to select the type of export, a file name to export to if required and control what type of data should be exported.
All Objects When using export from a list the default operation will export only those objects selected in the list. However, by checking the All Objects box all entries in the list will be exported. Export to File or Export to Clipboard A choice is presented as to whether the data should be exported to the file name given below or directly to a clipboard for pasting into another application.
Overwrite When checked the program will overwrite any previous version of the file. Without this option checked the program will prompt the user for an overwrite decision if the file already exists. Append By default the program will overwrite any existing file.
However, with the append box checked the data is written to end of any existing information in the file. Export MQSC format When data is exported only the data currently contained in the dialog is exported. This can be really useful when exporting text and only certain fields of an object should be exported. However, care should be used when exporting lists in MQSC format. Because only the data in the dialog is exported it is quite possible to export an invalid MQSC definition.
To ensure a complete definition is exported select Alter List in the list window first. Ensure that all fields are in the left hand window i. Select OK. This will retrieve all information about all objects. You can now export the objects from the list knowing that all data for all fields is available. Normal monitoring A program on the receiving Queue Manager should send the monitor messages back to the monitor program.
In addition, it must change the first character of the message from 'm' to 'r'. Loop back In loop back monitoring the monitor queue at the remote location must 'point' back to the Reply Queue defined in the local Queue Managers location settings.
Using this method it is not necessary to have any code other than the base WebSphere MQ product on the target system which allows very simple monitoring of any WebSphere MQ platform. Since you must define a remote queue at the remote location pointing back to the Reply Queue you can not use loop back monitoring if your reply queue is a model queue. Using both methods a WebSphere MQ message will make a complete round trip between the monitoring program and the target Queue Manager.
The application keeps track of when it needs to send a message and whether a reply is outstanding. If a message is not received within a reasonable time then the application will give a visible, and if required, an audible alert that a Queue Manager is not responding. In this way it is simple for an operator to check whether all of the Queue Managers and the Channels between them are functioning correctly.
The command is always submitted as a background process. The actual format of the command and what capabilities you have depend on the OS. The two places where you can specify a command string are :. In the location dialog Here you are given the opportunity to give two commands. The idea is that, during monitoring of a remote location, monitoring will either succeed or fail.
As it makes the transition from one to the other the appropriate command will be issued. This allows the user to have a downstream application which is driven from MQMONNTP which takes some action when it is told that, for instance, monitoring to a remote location is now failing. In the filter string using the system function call The system function, in the filter, takes two parameters, an expression and a command string. If the expression is evaluated to TRUE the command will be issued.
This allows the user to check for virtually any combination of object attributes and if they match a certain criteria then a command will be issued.
Note that the system function is executed for each item in the list returned. So, for example, if a filter of system 1,"myprog. You should use the expression to make sure that the program is only started as many times as necessary. Format The format of the command string is whatever the underlying OS supports. Essentially it should be a program name followed by zero or more parameters which are governed by the program.
The Administrator will treat everything up to the first space as the program name and pass everything else as parameters. I have had varying degrees of success starting REXX and batch files.
Sometimes it is necessary to start the command interpreter CMD. EXE on NT and pass the command you want executed as the parameter to it e. Remember that if you need embedded double quotes in a string you can precede it by a backslash. Substitution Characters A substitution character is a way of simply modifying the parameters passed depending on the object generating the command.
Substitution will occur anywhere in the command string. If the command being issued is not related to a list then it will be ignored and removed from the command string. Examples "myprog. The previous chapter dealt with monitoring Queue Managers as a whole and detecting whether they were reachable. However, even though the Queue Manager is available and working it does not necessarily imply that all is well within it.
What we need is some way to monitor the individual objects of the Queue manager, most notably Channels and Queues. Event messages are specially formatted messages which are written to 'known' queues when particular key events occur within the Queue Manager.
For example, an event message can be generated when the depth of a queue reaches a certain predetermined level. Why, I hear you ask, rather than MQ just raising a message doesn't the Queue Manager just fix the problem? The point here is that different installations may want to perform different actions for the same event; the same event for different objects may well be handled differently; and for a number of these situations it is not at all clear what 'the right' thing to do is.
For example, in the case earlier where a queue has reached a certain depth, is the right thing to do just increase the maximum depth of the queue; should one inhibit the queue for puts to prevent any further messages from being put to it; or should one start another instance of the application which is supposed to be servicing this queue.
The answer may well depend on what the queue is and what the installation policy is. So it is an advantage that MQ does not enforce a certain policy for these situations and instead generates an event message which provides the most flexible method of informing an application that something has happened. The downside, of course, is that something has to be written to process these event messages and do something with them. For some time now I have been having more and more requests for this type of functionality to be put into MO The problem is that I too am faced with the problem that what each person wants to do may well be different.
This is a big area and there are many companies who have developed entire products whose sole purpose is to monitor and act upon these events. Sadly I have neither the resource nor knowledge to generate a product which integrates with other monitoring tools. What I have attempted to do is come up with a fairly simple but flexible way of monitoring for these event messages and acting upon them.
Perhaps the best way of describing monitoring is to do an example. Event Example Let's take the case above of a queue reaching a predefined limit. First we determine what the MQ event message is that will be generated and which queue it will be written to. To do this we look at the 'Event Monitoring' book and find the chapter on queue depth events. EVENT queue. Note that we need to switch on performance events for the Queue Manager and the High Depth Event for this queue.
So, now we should have the Queue Manager generating this message, all we have to do is configure MO71 to look for it. From the main menu select Action-Event this will bring up a dialog with quite a number of fields which we'll ignore for now. For the moment just concentrate on the fields we must fill in.
Type We now need to tell MO71 what event we're looking for. Press 'F4' to drop down the list. Select 'Queue High'. The rest of the fields are mainly concerned with what we want to happen when we see one of these messages. Let's keep things simple and just write a message to the console. Tab down to the 'Console Priority' field and change 'None' to, say, 'Medium'. Now press the create button and check the application says an event has been created.
The message may well say it has created 2 events. We'll see the reason for this soon. Now go back to the main window but this time select 'Action-Event List'. This will show a familiar looking list window, pressing refresh will show the event we've just defined. Notice though that it only shows the Queue Name and not the actual event type. By changing the 'Display Type' to 'Detail' and pressing refresh we see the event type we created. We also see another event, called 'Default'.
This explains why the message said 2 events created but what is it for? The default event is there because the Queue High Event we're looking for isn't the only message which may be put to this event Queue.
If MO71 reads a message off the queue and it is not a Queue High Event what should it do with the message? This default event allows you to specify that behaviour. But for now, in time honoured tradition, let's ignore it. The other thing we notice on our event list display is that the status is stopped. What does this mean? Well it means that MO71 is not at this moment reading this queue.
Any messages put to the event queue will not be noticed. So, we need to start the event, select either of the events for this queue, right-click and press start. You should see the status change from Stopped to Running. If you don't there should be a 'status reason' field stating why it didn't work. Now the exciting bit, we get to see whether it actually works.
We need to cause a Queue High Event. Using something like my SupportPac MA01 which allows you to specify the number of messages to put can help here but you can use MO71 itself by selecting 'Action-Put Message'.
Put a bunch of messages to the queue and keep watching the event list display. You should see the count of events processed change to 1 as MO71 receives and processes the message. Now, if you remember this far back, when we defined the event we changed the console priority to 'Medium'. What this said was that when one of these messages was received MO71 should write a message to the console.
So let's go see From the main menu select 'View-View Console'. You will probably see an info message telling you the time MO71 started and now we also see a 'Queue High' message stating that whatever queue name you chose has reached its Queue High limit.
Now let's see what happens when the queue depth becomes low again. Use MO71 to browse the queue. Select 'Message Selection-Apply to all messages'. The 'Delete' button now changes to 'Delete All'. Press the 'Delete All' button. Now it we take a look at the console you see we still have a record there saying Queue High even though we know it's empty. There are two things we forgot to do; firstly. Secondly, in our event list we need to add an entry to look for Queue Low.
So, go and do that now. Right, hopefully now you have a event list which shows three entries, Queue High, Queue Low and Default. Let's try the same exercise. Use the 'Action-Put Message' to put a bunch of messages to the queue. You should see the event list for Queue High now read 2. Let's take a quick look at the console. That's strange; we only see one record for Queue High. Why is this? The reason is the 'Console Type' we specified when we defined the event.
We set 'cumulative'. What this says is that the console should only display the latest entry if there are two events of the same type, for the same object from the same Queue Manager. If you like you can change this to 'History' which will write a new entry to the console every time it happens. Anyway, now we want to go and delete the messages on the queue. So do the same trick of 'DeleteAll' from the browse window.
The first thing to notice is that in the event list we now correctly have a count of one next to Queue Low event. The second thing to notice in the console window rather than getting a console entry saying 'Queue Low' event instead the 'Queue High' event has gone. Well for pretty much the same reason we didn't get two Queue High events. Since we've asked for a cumulative console we're asking for it to display the sum of the events that have occurred.
Since a Queue Low cancels a Queue High event it seems logical not to display anything. By now you should understand the basic principals of event monitoring so let's go through all the fields you can specify on an event object.
Queue Manager Name In it's simplest form this is just the Queue Manager name for which this event applies to but it can take wildcards. Location This field is largely for convenience but it can useful in some circumstances where you have more than one location defined for the same Queue Manager. Type This is the event type the event is monitoring for.
You cannot define a 'default' event nor can you delete the default event unless it is the only event for a particular event queue. Filter There may be occasions when you may want different actions depending on the actual contents of the event message.
The most likely of these would be the object name that generated the event. For example, suppose you wanted to only write console messages for channels starting with the string.
Filter Priority This field can be used to force the correct ordering of events. Suppose you have two events defined for catching the Queue High event. You may have a filter on one of them for just queues called 'ABC'. The second event may have no filter as a catchall mechanism.
For this to work you need to ensure that the filtered event is processed first. To achieve this define the filtered event with a filter priority which is lower than the general event i. To enable you to make easy additions later it may be a good idea to define your filters with priority such as ,, and so on so that you can insert another filter between them if required.
Discard This value essentially switches off the event definition. If Discard is set to 'yes' the event is essentially disabled. Any other events which match the event, including the default filter, will still be processed. Command Here you can type the name of a command to be issued if this event is driven. For example, it might run a script which calls the operators pager.
Queue Full. Log File If required a hard copy record of the events which have been caught can be written to file. This can be useful as an audit trail or perhaps to post process and see how often certain events are being generated.
Enter the full path of the file name to write to. Log Line The format of each line in the log file. Requeue One of the problems with processing event messages is that there may be occasions where you want more than one program to monitor events. The simplest way of achieving this is to daisy chain the monitors.
Have one monitor processing the 'real' event queue and when it's finished it then puts the message to another queue for another program to then process. This field allows you to specify where MO71 should put the message once it has finished processing it. If no destination is specified the message will be discarded.
Auto Start As its name suggests it allows for the event monitor to reading the queue as soon as MO71 is started. If set to 'No' the event must be started manually. Note that starting any event for the same queue will start all of the events defined for that queue. It is not possible to only start one. Console Priority This field tells MO71 whether the event should be logged to the console. A value of 'None' implies that no console entry will be made. Console Type Some events have an equivalent but opposite event.
For these events it can make sense to allow them to cancel one another out so that only the negative situation is ever presented on the console. The value for this is 'cumulative'.
If however you want every instance of this event to be logged to the console you can specify 'History' so that a history of all of these events is maintained in the console.
Operational Considerations In order to monitor event messages MO71 must have a connection to the Queue Manager and open the event queue. Consequently the more event queues which need to be monitored the more connections are required to the Queue Manager. Different queues can be useful if you have one type of monitoring application monitoring one set of events and another monitoring a different set.
However, if you have a program, such as MO71, which can deal with different events from different queues it is far more efficient to merge the event queues. The simplest way of doing this is to redefine the event queues as alias queues pointing to a central event queue.
EVENT replace. This mechanism could even be extended to collect events from remote queue managers to a single, central event queue, by defining the event queues as remote queues. Menu options Many of the menu options act on the selected Queue Manager in the main window.
The menu options available are therefore dependent on which Queue Manager is selected. Make sure that the correct Queue Manager is selected before issuing the command. The menu options available are Refresh Information Causes the application to refresh its cached information about the selected Queue Manager. This should be used to update the information shown in the tree view of the main window. This project is actively being developed.
All features are created for the daily task of any MQ Admin team, any suggestions for general programming discussion,feedback, new feature request are welcomed. Please provide the ad click URL, if possible:. Oh no! Some styles failed to load. Help Create Join Login. Application Development. IT Management. Project Management. For more information about the program and its features why not read the datasheet , or download the user guide.
The first version of program was written in and over many successive releases it has been enhanced to incorporate a wealth of features. You can watch videos which introduce some aspects of MO71 here.
Tagged: Message Queue. You can follow any responses to this entry through the RSS 2. You can leave a response , or trackback from your own site. You are commenting using your WordPress. You are commenting using your Google account.
You are commenting using your Twitter account. You are commenting using your Facebook account. Notify me of new comments via email. Notify me of new posts via email. Home About. Top Clicks towardssoa. Allows you to index the messages and export them to a file.
0コメント