You can create message parameter blocks (MPBs) instead of storing messages in your application code. MPBs contain a message identifier, and, if needed, a format number, line number, and any substitution data. The actual message text resides only in the message skeletons in the run-time message file. Using MPBs provides the convenience of having to modify only the install message file if any of your message text requires a change. It also allows you to have a single repository for message text.
If you use message text blocks (MTBs) or self-defined text as input to the TRANMSG macro, and your message text requires a change, you will have to change it in both the message skeleton and the MTB or self-defined text. Modifying just the existing run-time message files to adapt changed message text can result in unpredictable errors when using the TRANSMSG service.
To build a message parameter block (MPB), allocate storage for the MPB, and issue BLDMPB and UPDTMPB. BLDMPB initializes the MPB and adds the fixed message data (called the message header), and UPDTMPB adds one substitution token to the MPB for each invocation.
Issue BLDMPB once for each MPB you will build and before you issue UPDTMPB. Issue UPDTMPB once for each substitution token in the message. You can also use UPDTMPB to replace or change the value of a particular substitution token in an existing MPB. However, you must ensure that the new value is not longer than the original value to maintain the integrity of the MPB. You might use UPDTMPB if you want to invoke TRANMSG several times with one MPB. For example, if you have an MPB associated with a message that you will translate in several languages, you can change only the language code in the MIO, and issue TRANMSG.
Once you have built an MPB for a message, you can issue TRANMSG to return the text of the message in a message text block (MTB). If the requested language is not available, TRANMSG returns the message number and its substitution data as a text string in the output area.