Information for software developers wishing to implement proprietary versions of MQM
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.
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.
In addition, the working group strongly recommends the following features:
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.
Comments and queries to Cherri M. Pancake,
pancake@cs.orst.edu
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:
These priorities constrained the tool's design in several ways, as
outlined below.
Requirements
The Message Queue Manager includes the following elements:
Additional information will be found in the sections below.
It is anticipated that proprietary versions will vary the color scheme and
some aspects of appearance (e.g., node shape), but the
representations must resemble the reference version sufficiently
so that users have no trouble adapting from one version to
another.
mqm_main.
mqm_main is set to 1.)
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.
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:
Vendors are free to add Help buttons or menus,
according to their in-house policies.
Vendors are free to alter the window framework (in particular, the
menubar area) to conform to their in-house style.
No. Users were clear that a single scrollbar is sufficient, and
preferred because it creates less clutter. They also wanted to
remind vendors that the mechanisms and representations themselves
(i.e., as opposed to colors, shape of button, etc.) really need to
remain consistent across platforms.
Since MQM begins by querying for a list of process IDs, presumably the
list returned by the debugger would just show the tasks to which it was
attached. Only the subset would be known to MQM, using the current
structure. Yhis would not be reported in any way to the user.
The format of the ID is a string, specifically to accommodate variation
(some vendors might include process and thread, others process group
and process ID; some might call them "tasks"). It is expected that the
vendors might need to modify the message-area string and the popup
windows accordingly.
Yes. Users felt strongly that the mode should be controlled via
two items in the Options menu. The following terms were their
preference: Update automatically and
Update on-demand.
No. Although this was listed as an important enhancement, it was
never part of the specification. That means that implementors are
free to handle it if and how they choose.
Last updated September 20, 1996.