TAMz for RACF parsing of SMF LOGSTR records
search cancel

TAMz for RACF parsing of SMF LOGSTR records

book

Article ID: 374465

calendar_today

Updated On:

Products

Trusted Access Manager for Mainframe

Issue/Introduction

Currently (as of summer 2024) in TAMz v1.1, the key(value) pairs are in fixed positions in the SMF LOGSTR field record. However, that may not be the case in the future. Because of this, Broadcom cannot provide a mapping of the formats, but a general outline is provided below. If you are attempting to parse these values, please keep the following aspects and example in mind.   

Environment

Product: Trusted Access Manager for Mainframe 
Version: 1.1

Resolution

 Considerations for key(value) pair parsing:

  1. TamZ v1.1 will continue to use the key(value) method for COMMAND keywords.
  2. Today, the keywords are in fixed positions and values have fixed lengths and some keywords contain output with no values.  However, in the future, keywords and their values will not be in fixed positions and data values will be variable length.  
  3. Values for command keywords will always be wrapped in matching parenthesis.
  4. Values will not always have trailing blanks.
  5. Values with included blanks do not normally occur today, so values should be treated as being wrapped in parenthesis.  If Broadcom finds in the future that this technique is insufficient (for example if a parenthesis could be part of the value text) then the value could eventually be delimited by double quotes.    

The LOGSTR values for COMMANDs are in the following order:

  1. They start with "TAMZ FOR RACF"
  2. Followed by the type of event, such as "COMMAND:" or "AUDIT EVENT". 
  3. Then, there is TAMID= with a 16-character numeric identifier.  
  4. Following these fields are the key(value) pairs for COMMAND records.
  5. At the end of TAMz ELEVATE and DEELEVATE commands, there are the "RC:nn RSN:nn" return code and reason code values.  The "nn" value is a 2-character decimal value.  Parse on the trailing blank of each value to allow for a 3-digit value in the future.

Note: When parsing, do not parse in any assumed sequence of key(value) pairs - they must be parsed as they arrive as it is impossible to predict any anticipated sequence or order.