Re: Can the destination volume be obtained from the BRM1553 message

On 13-Jun-2014 17:10 -0500, Steinmetz, Paul wrote:

On 13-Jun-2014 16:59 -0500, CRPence wrote:

On 13-Jun-2014 15:16 -0500, Steinmetz, Paul wrote:

Can the destination volume be obtained from the BRM1553 message?
In the example below, 001012.

Message ID . . : BRM1553 Severity . . . : 10
Job: BRMS User: PAULS Number: 921257
Date sent . . . . . : 6/12/14 Time sent . . . : 10:26:32
Program . . . . . . : q1aDuplica Area . . . . . . : *MED
Message: Data has been moved from the source to destination
media.
Cause: Data has been moved from media 001041 to media 001012.

The /message data/ layout is defined by the Format (FMT)
specification on the Add Message Description (ADDMSGD).
The Display Message Description (DSPMSGD) will reveal each
/replacement variable/ to map the storage to match that defined
MsgDta layout; see "2=Display Field Data if using displayed
output" for the definition of the FMT() information. If the DSPMSGD
BRM1553 MSGF(_theBRMSmsgf_) shows that the "Cause" text is "...
from media&3 to media&2." [see "1=Display Message Text" if using
displayed output], that would signify that the replacement data
'001012' [shown in the quoted replied-to message] came from the
_second_ FMT() element [that appeared as "&2" in the Field Data].

Accessing that data depends on where the message is. The message
needs to be /received/ or accessed by whatever other means. Whence the
message information was obtained was not clarified; e.g. the data could
be in a program message queue, in an external message queue [ a *MSGQ
object], or in a log [file] such as QHST. Arguably, whatever interface
gave that expanded message text [with variable data replacement
complete], the data is available in that form, but locating that data
requires either assuming a fixed-format or parsing the string; neither
of those are /good/ ideas.

Message is in dsplogbrm

<http://www.redbooks.ibm.com/redbooks/pdfs/sg247031.pdf>
"...
The BRMS log is a combination of the history log and job log. It only contains messages that deal with BRMS. To access the BRMS log, you enter the Display Log BRMS (DSPLOGBRM) command. Then you see a display similar to the Display BRM Log Information example in Figure 11-5. Each day is separate. If you want to see a specific date, change the date in the upper right corner. You can also see additional information about the messages by placing your cursor on the message and pressing F1.
..."

If the above doc link information is to be believed, the details for the msg BRM1553 are obtained by the Display Log For BRM (DSPLOGBRM) command processing obtains the message and details from either the History Log or the Job Log. Thus instead of issuing the DSPLOGBRM to obtain only the limited output available from that command, the message could be /received/ or /listed/ from the joblog, or /listed/ from the QHST History Log; or if the origin of the message with in the history log is indirectly via the *SYSOPR, then the message could be /received/ from the QSYSOPR message queue. Thus instead of invoking the DSPLOGBRM, a program that mimics that feature could be coded and called instead; that program would be coded to use the respective API(s) to access the BRM1553 message from whatever is the location whence the DSPLOGBRM would receive\list the message.

Of course the spooled output from the DSPLOGBRM request could be /scraped/ for that information [possibly only when specifying DETAIL(*FULL), if even the "Cause" details appear. Such usage is at risk of having to deal with changes to the message and the formatting of the data in the spool file data for the printer file QP1ALG; that may include requirements to deal with changes in the [installed] language being utilized, beyond changes that might be limited only to changes from release [or maintenance] upgrades to the BRMS feature.