A run-id token is useful when trying to match a message from a particular run. It is important to remember that a run-id used for pattern matching is the run-id generated by the system and not the original run-id that was specified in the @RUN statement. Masking is allowed (and useful) in run-id tokens.

You may not see the generated run-id when your console message is displayed, but it is still available for pattern matching.

For example, assume a pattern exists for a message and CP-AMS is to perform the associated actions only when the run "XYZ" issues the message. You could specify the following run-id token:

TOKEN RUNID "XYZ"

The pattern would not match the message if the Exec renamed the run "XYZA" because of an existing run or queued print files named "XYZ". To eliminate this problem you could specify the following more general run-id token:

TOKEN RUNID "XYZ\*1\"

This causes CP-AMS to perform the specified action when the message is sent by any run with a 3- or 4-character run-id beginning with "XYZ".

Matching All Messages from a Run

You can use a standard pattern without keywords and a TYPE of VARIABLE-LENGTH to match all messages from a particular run. You can match the pattern to a message with any number of tokens when you specify VARIABLE-LENGTH.The only token required for pattern matching is a run-id token.You can use this method to match all messages that have text.You cannot match blank messages.

DEFINE "run"
MESSAGE "Message text"
TYPE OTHER ANY-SENDER VARIABLE-LENGTH
TOKEN RUNID "run-id"
 .
 .
 .

In an autoaction database containing this pattern, a nonstandard pattern can never match a message from the run specified in this pattern because all of the messages from the run would match this standard pattern first.

Using a TOKEN Command with Logging Run-Ids

The Exec permits console messages from privileged runs to specify a logging run-id that is different from the run-id used by the Exec. The run-id that is specified in console messages allows a service run to display console messages and make system log entries on behalf of another run. If the privileged run specifies a different run-id when sending a message to the system console, the run-id specified in the console message is the run-id that must match the run-id pattern token. However, if the specified run-id contains characters not permitted by ADBM or BADB, they can be matched only by using masked characters, for example, \*1\ or \?1\. The specified run-id is displayed on the console, but it is not part of the MESSAGE text.

Run-Id Token in Non-Exec Messages

CP-AMS does not consider the run-id of a non-Exec message to be part of the message text. The first token in a non-Exec message is the first word of the message text that follows the run-id, as show in the following example:

8VAVRA*THIS IS A NON-PRIVILEGED MESSAGE.
       ----
       token
     position 1

AMS compares a run-id pattern token to the run-id of the sender of the console message. You can specify a run-id token as a fixed string of characters or as a masked string. You can only have one run-id token per pattern. Run-ids do not have a token position.

Run-Id Token in Exec Messages

Do not use run-id tokens when trying to match an Exec message using CP-AMS. Because the generated run-id of Exec messages is always blank, a run-id pattern token would always prevent the pattern from matching an Exec message.

Common examples of messages sent by the Exec are run-id START, run-id FIN, and messages produced by the @MSG and @MSG,W commands.

For Exec messages, the entire visible string constitutes the message text. The following message resulted from user VAVRA's @MSG command.

VAVRA*MSG: THIS IS A MESSAGE
-----------
  token
position 1

Even if the run-id has fewer than six characters, there are no spaces between the run-id and *MSG.