Parallel Tools Consortium

Message Queue Manager Adopter's Guide

Version 1.0

Information for software developers wishing to implement proprietary versions of MQM


On-line flyer describing project from viewpoint of parallel application developers
Information on downloading current version
General Web pages on the MQM project

Purpose and Organization of Document

This document describes those aspects of MQM design likely to be of interest to commercial software developers who wish to adopt the graphical tool and/or the standard-format queries that obtain message operation status from the run-time system. Emphasis is on the features that were designed in response to specific user requests or feedback during the user-centered design process.


Name and Ownership Issues

According to the objectives of the Parallel Tools Consortium (Ptools), the design of MQM and its reference implementation are available for royalty-free adoption and use by any public or private organization. Copyright is retained by the Parallel Tools Consortium and Oregon State University. (Queries concerning its use should be directed to the address at the end of this document.)

The name "Message Queue Manager" and its abbreviation "MQM" are used as a convenience. Proprietary implementations are not required to use those names, but aliases should be provided to associate the name mqm with the proprietary tools, for the benefit of users familiar with the generic Ptools names.

Adopters are asked to attribute the origin of the design in their support documentation, referring to their work as derivative work based on "the Parallel Tool Consortium's Message Queue Manager Interface" or "the Parallel Tool Consortium's Message Queue Manager Standard Query Adopters are also requested to inform Ptools of their plans to adopt the design, by sending email to the address at the end of this document. (This will add them to the distribution list for any updates.)

The intent of Ptools projects is that their proprietary implementations by other parties conform to certain consistencies in operation and look-and-feel, so that users familiar with the tool on one vendor platform will be able immediately to recognize and use it on a different platform. Therefore, the Ptools Steering Committee recommends that alterations be confined to "cosmetic" features that might help the tool to fit into a platform-specific programming environment, but do not substantially affect its use.


Design Objectives

The original need for the MQM project was identified at a series of user group meetings and workshops. The same forums established what should be the primary design considerations:
  1. The user must be able to determine the current status of message-passing operations on demand, without modifying the program. That is, it must not be necessary to instrument the program in order to acquire status information.

  2. The user should be able to control the type and amount of information displayed. It should be possible to reduce the amount of data using dynamic filters.

  3. The presentation must be scalable. Specifically, it should handle data from programs involving hundreds or thousands of processes within a reasonable screen space.

  4. The interface must be extremely simple. In particular, the tool should be quick to invoke.

  5. The interface must be intuitive. That is, no user manual should be necessary, even for first-time users.

  6. The tool should be adaptible to any message-passing system. Message operations should be described in generic terms to avoid dependencies on any particular message-passing library API.

These priorities constrained the tool's design in several ways, as outlined below.

The remainder of this document describes the particular features that were identified as critical by users involved in the design process. Adopters should recall that the entire point of Ptools projects is to reflect user needs and preferences. Wherever possible (within the constraints of the execution environment), a proprietary version of MQM should maintain all features that evolved in response to user input.

It is anticipated that some adoptions will uncover additional uses for the MQM project components (query format, graphical tool) that were not foreseen and may require substantial modifications to the original design (see "Extensions to the MQM Model"). The MQM working group invites direct interaction with adopters so that such changes can be made in a consistent way and propagated through future adoptions.


Requirements

The Message Queue Manager includes the following elements:

Additional information will be found in the sections below.


Graphical Interface

The fundamental design constraint is that MQM must present message data within a reasonable amount of screen space, but without sacrificing details. Since the number of messages can grow explosively in applications running on large numbers of processes, it is obvious that data must be presented selectively.

In discussions with users, it was determined that very coarse information - such as knowing which processes were blocked waiting for an operation to complete, or which processes had a large number of messages pending - would often be sufficient to allow the user to identify a point of error. Information about queue contents, on the other hand, would not likely be examined for more than a few processes. MQM's displays were therefore designed at two primary levels of granularity (overview and process-level).

The requirement for selective data presentation also led to discussions of how users would want to control display filtering interactively. Three orthogonal methods were discussed, to restrict the values displayed according to: (a) which types of operations are reported; (b) which operations within a type (e.g., by source of message) are reported; or (c) which processes are reported. Since scenarios were posed showing that all the controls could be useful, the final design allows all three. We also had users rate the three according to how frequently they would use each. Since by-operation-type appeared to be most frequent, this is the mechanism supported directly on the main display. The other two mechanisms are controlled by popup dialogs.

Virtually every aspect of the graphical interface was modified in response to user preferences obtained through direct user testing. The features that ended up being of particular importance to the users are described below. Adopters are cautioned not to undermine the effectiveness of the representation by making arbitrary changes to these features.

However, we did not exhaustively test every aspect. In particular, the reference implementation intentionally sidesteps color and font issues (under the assumption that proprietary implementations are most likely to want these to conform to product-line appearance standards). What you see are the default colors and fonts of the Tk widgets. With one exception (see "color buckets" bullet), users expressed no particular preferences for color.

Clarifications and Updates

After initial publication of the standard, several related issues were raised and resolved. They are formatted as question-and-answer below: In addition, user review prompted the following suggestions for improvements:


Last updated September 20, 1996.

Comments and queries to Cherri M. Pancake, pancake@cs.orst.edu