Partial Message IDs and Performance

You cannot specify a partial message ID, such as XXX**YY, only XXX would be acceptable. The first three bytes of the message ID are the minimum required to specify a message to trap in the exit. You can specify a partial message ID within this limitation.

It is recommended that you do not use the TOKEN keyword with partial message IDs for messages. This causes a performance degradation because the token data must be matched for the partial message and then again for any specific message.

You can specify MSGDISP policy information on actions for all specific message IDs that match the partial message ID. You do not have to specify more specific message IDs. Instead a partial message ID and a matching set of TOKEN keywords can be used to specify the actions for a message. Be aware that token scanning is much less efficient than message ID scanning.

You can use the partial message IDs to improve exit performance. An extreme example might be if you are trapping messages ABC000-ABC100. You might choose to create partial message IDs for ABC00-ABC10. The partial message IDs would specify MSGDISP=(NONE) to prevent them supplying default actions. This would cause the exit to first scan the set of partial message IDs ABC00-ABC10 or 11 checks. Then, assuming it found a match on ABC10, it would scan the specific messages ABC110-ABC119 for a total of 21 checks as opposed to 101 for the original set. This would require 112 MESSAGES/USER DATA policy definitions. 101 for messages ABC000-ABC100 and 11 for messages ABC00-ABC10. In normal circumstances you can ignore the usage of partial message IDs for performance reasons and use them for functional reasons.