Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 3 Tools : @MESSAGETRACE

@MESSAGETRACE
Stores table access message requests between the Execution Environment and the Data Object Broker collected when using trace facility. (TBL)
Prerequisites
@TRACEMESSAGES.TRACE must be set to Y prior to running applications for which trace information is required.
Table Definition
Parameters
This table has no parameters.

Fields
 
Integer identifier incremented by one for each message pair (outbound and reply). Can be reset only by clearing the table via a FORALL loop. Also used as high-order primary composite for table @MESSAGEDUMP.
The table name as specified in the outbound message. Not included in certain administrative or transaction messages, such as commits (CODE = 'R').
Contains up to 16 bytes of the value (if any) of the table's first parameter. Not present for certain supervisory messages, nor for messages that are generated internally. Normally can be depended on if the message is explicitly generated by a rule.
Indicates, when the entry is Y, that a unique selection based on a primary key is supplied. For example, 'GET TABLE WHERE KEY = VALUE … & … ( … |… )' and other queries of the same form represent unique primary selections. This indicates that a server does not have to sweep the table and is normally the preferred optimization. Although it reduces server work, it does not necessarily reduce message traffic.
GET table WHERE key operator somevalue
where operator is one of >, >=, <, <=.
The query can also be of a logically equivalent form. This is normally the second choice for server optimization, as it restricts the range of sweeps by enabling servers to use any index that supports ordering.
Y indicates that a message contains either unique secondary key values or secondary value ranges. They are provided to the server in a normalized form so that non-unique secondary indexes can take part in data access. Normally the third preferred optimization.
Y indicates that fields that are not indexed could possibly need to be examined by the server. This does not preclude the use of indexes. It can require that the server examine each row that is accessed via indexes before returning it.
Contains the internal lock code. For example, single a quotation mark (') represents table share; S, row share; and X, row exclusive. Blank does not necessarily indicate that no lock exists; a previous message could have taken an equivalent or larger lock.
This is the descriptive name of CODE (from the table @TFMIRS).
This is the outbound message length (the total length as provided to TIBCO Object Service Broker communication services).
This is the total length of reply message as returned by TIBCO Object Service Broker communication services.
Y indicates that an outbound message is directed to a different Data Object Broker than the local Data Object Broker's NODENAME.
This field contains the Data Object Broker NODENAME that the outbound message attempted to send to, for example, GET TABLE WHERE LOCATION = 'NODENAME'.
This field contains the request type of view table, if applicable, for example, G means GET, A means FORALL HEAD, B means FORALL TAIL. This could be different from CODE. For example, a non-optimizable query could generate a server sweep via CODE = 'N' (next rows).
This field contains the table name as specified by the calling rule, after any indirection has been performed.
This field contains the name of the rule that explicitly caused the message or on whose behalf the message is sent, or the most recently run rule (or possibly a program name). The purpose is to enable the correlation of messages to specific rules.
This is the hexadecimal transaction identifier as returned by the reply message. NOTE: It could be inapplicable if RETURNCODE is non-zero.
This field contains a number representing the executor's trigger level. It enables distinction of messages from trigger rules.
Usage Notes
Trace information is written to this file automatically when the value of @TRACEMESSAGES.TRACE is set to Y and the applications to be traced are run. Message tracing can be further refined by modifying other fields of the @TRACEMESSAGES table.
Since these trace results are in table format, they can be processed by rules. Apart from debugging uses, this table is intended for application profiling; no particular profile is assumed. Applications must define their own tables to hold whatever trace attributes are deemed important for later processing.
This table is subject to the same security clearance checking as all session tables, but the definition must not be changed without corresponding engine changes.
Constraints
Using @MESSAGETRACE to store message information necessarily causes extra data accesses (INSERTs to the @MESSAGETRACE table), and therefore, extra messages during message collection. To avoid this overhead, @TRACEMESSAGES.MESSAGELOG can be set to Y prior to running applications being traced.
Example
If you request a generalized trace using an appropriate rule, the contents of @MESSAGETRACE are similar to the following trace. Due to space limitations, not all fields are shown. The output contains timestamps, rule names, and other information.

 
BROWSING TABLE : @MESSAGETRACE
COMMAND ==>
SCROLL: P
ID CODE TABLENAME FIRSTPARM UNIQUE RANGE SECONDARY
_ ----------- - ---------------- ---------------- - - -
_ 1 R
_ 2 G @USERSOPTIONS Y
_ 3 G @USERSOPTIONS Y
_ 4 G @MONTH_CODES Y
_ 5 G @MONTHLIST Y
_ 6 G @WEEKDAYS Y
_ 7 G @MONTHLIST Y
_ 8 G @RULESLIBRARY COMMON Y
_ 9 G APPOINTMENTS AZDA0 Y
_ 10 G APPOINTMENTS AZDA0 Y
_ 11 G @MONTH_CODES Y
_ 12 G @LIBRARIES Y
_ 13 G @RULESLIBRARY TZHA0 Y
PFKEYS: 1=HELP 5=FIND NEXT 9=RECALL 18=EXCLUDE 13=PRINT 3=END 14=EXPAND

 

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved