TLOG Validation - TLOGic Help

Overview

TLOGic's TLOG Validation tool checks individual transaction records against a set of configurable rules. It is designed to catch data quality issues like missing fields, empty values, and invalid data that can cause downstream processing errors such as NullPointerExceptions (NPEs) and incorrect POSLOG output.

The default rules were generated from the ACE Albertsons transaction mapping configuration, covering 30+ string types and 150+ field checks. This provides comprehensive out-of-the-box validation for most IBM TLOG implementations.

In addition to rule-based validation, TLOGic also includes a Scan Structure action for file-wide structural review. Use it when you want to inspect transaction boundaries, malformed data windows, duplicate transactions, or incorrect NumStrings values across the entire loaded file.

License Availability

TLOG Validation is available to Trial (full access during 14-day trial) and Professional license holders. It is not available with the Standard license.

How to Use

Validating a Single Transaction

Select a transaction in the transaction list
Click the Validate button in the transaction detail header (next to the Offset/Size/Terminal badges)
An offcanvas panel opens showing validation results immediately
Errors (red) indicate fields that WILL cause processing failures if missing
Warnings (yellow) indicate fields where missing data may indicate data quality issues but the processing pipeline has filters to handle them
Click any violation row to highlight the corresponding string and field in the string pane

Validate All Transactions

Batch Validation

At the bottom of the validation offcanvas, click Validate All Transactions to scan every transaction in the file.

A progress bar shows scan progress as each transaction is checked
Results open in a modal dialog grouped by transaction, with an accordion for each affected transaction
Click any row to navigate directly to that transaction and highlight the relevant string and field

Scan Structure

Structural File Scan

Click Scan Structure in the Transaction List header to scan the entire loaded TLOG for structural anomalies. This is different from the normal Validate button: the validation workflow checks string and field rules, while Scan Structure focuses on whether the file layout itself looks correct.

The button sits on the same line as the Transactions count in the left-hand transaction list pane
A busy cursor is displayed while the scan is running
Results open in a floating panel so you can keep browsing the file while reviewing findings
The summary pills at the top of the panel jump directly to each findings section
The summary now includes a dedicated Minus Sign Fields section for suspicious trailing minus values found in ASCII or BCD fields
Click any finding to navigate to the offending transaction in both the list and the detail pane

What It Detects

Unknown data / malformed transaction windows — data that does not begin or end where a transaction should, or data that appears between transactions in an unexpected format
NumStrings mismatches — header string 00 says a transaction should contain more or fewer strings than were actually parsed
Minus sign fields — flags ASCII and BCD field values that contain minus signs so you can quickly review negative-value encoding or formatting anomalies
Duplicate 00 transactions — exact raw duplicates of normal transactions; 0x20 family duplicates are intentionally not flagged

Note: valid transaction header keys are 00, 20*, and 21. Any other top-level transaction key is shown as Unknown in the scan results and transaction list.

Working With Results

Use the pin control to auto-minimize the results panel after you click into a finding
When minimized, the panel docks out of the way so you can inspect the selected transaction behind it
Use the Key filter in the Minus Sign Fields section to narrow findings to one string key at a time
Restore the panel at any time to move to the next anomaly without rerunning the scan
If no anomalies are found, TLOGic displays a clean result message instead of the findings list

Rule Language

Validation rules use a simple domain-specific language (DSL). Each rule is a single line with the following syntax:

[SEVERITY] STRING_KEY:FIELD_INDEX CONDITION [ARGS...]

Component	Description
SEVERITY	`error` or `warn`. Defaults to `error` if omitted.
STRING_KEY	The TLOG string key (e.g., `00`, `11:BD`, `99:10:F5`)
FIELD_INDEX	1-based field number (matching IBM documentation)
CONDITION	The validation condition to apply (see Available Conditions below)
ARGS	Optional arguments required by some conditions

Lines starting with # are comments and are ignored during validation.

Available Conditions

Condition	Args	Description
`not_empty`	—	Field must exist and have non-empty data
`not_null`	—	Field index must exist in the string
`numeric`	—	Field display value must be a valid number
`min_length`	N	Field hex must be at least N hex characters
`valid_date`	FORMAT	Field must match date format (e.g., `YYMMDDhhmm`)
`matches`	REGEX	Field display must match the regex pattern
`in`	V1,V2,...	Field display must be one of the listed values
`range`	MIN MAX	Numeric value must be within [MIN, MAX]
`min_fields`	N	String must have at least N fields
`equals`	VALUE	Field display must exactly equal VALUE

Rule Examples

# Transaction header: Terminal must exist
error  00:1   not_empty            # Terminal

# Item: ExtendedPrice must be numeric
warn   01:2   numeric              # ExtendedPrice

# Coupon association: ItemCodeForCoupon must not be empty
error  11:BD:6  not_empty          # CouponCode

# Comment out rules with #
#warn  00:10  not_empty            # RingTime (disabled)

Customizing Rules

Rule Editor

Click Edit Validation Rules at the bottom of the offcanvas to expand the rule editor. From here you can modify the ruleset to match your specific TLOG format and processing pipeline.

Rules are saved automatically to browser localStorage
Reset Defaults restores the built-in ACE Albertsons ruleset
Export downloads rules as a text file for sharing
Import loads a rules file from disk
Rules persist across sessions — your customizations are remembered

Understanding Severity Levels

error Error Severity

The downstream processing pipeline accesses this field WITHOUT null/empty checks. If the field is missing, it WILL cause an NPE or processing failure. These rules were derived from fields in the mapping XML that have no <filter> protection.

warn Warning Severity

The pipeline has filters to handle empty/null values for this field, but missing data may still indicate a data quality issue worth investigating.

License Requirements

License	TLOG Validation Access
Trial	Full access during 14-day trial period
Professional	Full access
Standard	Not available

Tip: Export your custom rules file and share it with your team so everyone validates against the same criteria. Import the shared file on any workstation to stay in sync.