.ALW<\/code> scripts, CoSort users can analyze job performance and resource-control settings, while FieldShield and other SortCL users can audit sensitive-data handling, user activity, failures, and policy changes. Wrangler can also export filtered log data for reporting, analytics, graphing, or use in external log-analysis and SIEM platforms.<\/p>\nAbstract:<\/strong> This article provides practical examples of querying IRI audit logs with the Audit Log Wrangler (ALW) utility to extract actionable information. Sample ALW scripts show how IRI CoSort<\/a> users can wrangle log data to analyze job performance under different resource-control settings. Other examples show how IRI FieldShield<\/a> users can audit the treatment of sensitive data for compliance verification and incident tracing. The article also explains how an AI assistant can help build Wrangler scripts for your own queries.<\/p>\nAbout Audit Log Wrangler<\/strong><\/h2>\nThe <\/span>Audit Log Wrangler <\/strong>utility introduced within the <\/span>CoSort v11<\/a> Ops Governance System (OGS<\/a><\/strong>)<\/strong> extracts information from JSON logs produced by SortCL<\/a>-compatible executions.\u00a0<\/span><\/p>\nSortCL scripts drive structured data integration, transformation, migration, cleansing, masking, and reporting jobs for users of:<\/p>\n
\n- IRI CoSort<\/li>\n
- IRI FieldShield<\/li>\n
- IRI RowGen<\/li>\n
- IRI NextForm<\/li>\n
- IRI Voracity<\/li>\n<\/ul>\n
Designed for governors, auditors, and analysts, the command-line Wrangler utility parses and filters logs, generates reports, and exports delimited subsets of log data. One JSON audit log file is produced for each SortCL execution. <\/span>1<\/sup><\/a><\/span>\u00a0 <\/span><\/i>By extracting meaningful information from many detailed JSON audit logs, Wrangler helps organizations conduct security and compliance reviews and analyze job performance without requiring an external analytics platform. <\/span>2<\/sup><\/a><\/span><\/span><\/i><\/p>\n![\"Audit](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/IRI-Audit-Log-Wrangler-workflow-1.png\")
<\/p>\n
This article demonstrates some of the insights you can generate from the Audit logs using the tool\u2019s SQL- and jQuery-compatible query syntax inside Audit Log Wrangler (.ALW) job scripts. It also explains how you can leverage the wrangler\u2019s JPath syntax support in AI assistants such as ChatGPT to create new log queries.<\/span><\/p>\nWrangler\u2019s Modes of Operation<\/strong><\/h2>\nAudit Log Wrangler offers two primary modes of operation:<\/p>\n
\n- Interactive mode<\/li>\n
- Batch or script mode<\/li>\n<\/ol>\n
Interactive Mode<\/h3>\n
Interactive mode provides a user-friendly command-line interface that guides users through:<\/p>\n
\n- Selecting audit logs<\/li>\n
- Defining query criteria using SQL- and JPath-compatible syntax<\/li>\n
- Displaying results in real time<\/li>\n
- Saving query specifications in an Audit Log Wrangler (
.ALW<\/code>) script<\/li>\n<\/ul>\nThe saved script can then be used for ad hoc or batch command-line execution.<\/p>\n
![\"IRI](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/Audit-log-wrangler-display-1-1024x427.png\")
<\/p>\n
The interactive mode is ideal for exploratory analysis, debugging specific log entries, or quickly checking job performance statistics without needing to construct a formal script from scratch.<\/span><\/p>\nBatch or Script Mode<\/h3>\n
Batch mode supports command-line execution of existing ALW job scripts. Saving queries as .ALW<\/code> files makes it possible to repeat auditing tasks and integrate log analysis into enterprise compliance-reporting workflows.<\/p>\nSaved scripts can be run from the interactive mode or directly from the command line, for example:
\n$wrangler ssnaudit3.alw<\/span><\/p>\n![\"Batch](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/ALW-Script-Execution-Workflow-1024x494.png\")
<\/p>\n
The following ALW batch script examples were generated in the Wrangler interactive mode, manually, or by an AI assistant to demonstrate real-world performance and security audits.<\/span><\/p>\nSpeed and Performance Analysis with Audit Log Wrangler<\/h2>\n
The performance examples below show how information captured in SortCL audit logs can be wrangled to compare memory settings, thread counts, block sizes, throughput, system load, and concurrent workloads.<\/p>\n
Speed Example #1: Improving Memory Allocation<\/h3>\n
Optimizing memory use where possible can improve system-wide performance when concurrent jobs are running. Incorrect settings can cause thrashing. This query helps identify an efficient cosortrc<\/code> memory value to use when large jobs run.<\/p>\nPolicy_Location : [C:\\IRI\\cosort110\\etc\\Policy]\r\nLog_Location : [C:\\IRI\\cosort110\\logs]\r\n\r\nRange :\r\n[Audit-2026-05-20T09-50-48-002884-CUMULUS-sortcl.json,\r\nAudit-2026-05-20T16-28-01-018576-CUMULUS-sortcl.json]\r\n\r\nSeparator : \"\\t\"\r\nOut : [File,\"C:\\IRI\\cosort110\\MemoryUsageReport.out\"]\r\n\r\nHeader : \"JobName StartTime RAMrequested RecordsPerSecond MemoryUsed\"\r\n\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.execution.startTime]\r\nSelect : [$.statistics.resourceControlSettings.memoryMax]\r\nSelect : [$.statistics.performance.recsPerSecond]\r\nSelect : [$.statistics.performance.bufferMemoryUsed]\r\n\r\nWhere : [$[?(@.statistics.jobResults.recordsProcessed > 50000000)]]<\/pre>\nThe resulting report includes:<\/p>\n
\nJobName StartTime RAMrequested RecordsPerSecond MemoryUsed\r\n[\"CreditCard.scl\"] 2026-05-20T09:50:48 2970615808 1131913.063001 251658240\r\n[\"RAME_2000000.scl\"] 2026-05-20T09:52:12 3592421376 25948.006708 3592421376\r\n[\"CreditCard.scl\"] 2026-05-20T14:41:14 3084910592 364162.294909 41943040\r\n[\"CreditCard.scl\"] 2026-05-20T15:00:33 3276800000 1011127.474121 209715200\r\n[\"RAME_2000000.scl\"] 2026-05-20T15:02:05 3383754752 26105.924737 3383754750\r\n[\"CreditCard.scl\"] 2026-05-20T15:49:47 3308257280 975985.317549 167772160\r\n[\"RAME_2000000.scl\"] 2026-05-20T15:51:21 3020947456 25754.54004 3020947456\r\n[\"CreditCard.scl\"] 2026-05-20T16:00:37 3167748096 733094.278843 125829120\r\n[\"RAME_2000000.scl\"] 2026-05-20T16:02:33 3183476736 25833.214393 3183476736\r\n[\"CreditCard.scl\"] 2026-05-20T16:09:25 3382706176 431494.535735 83886080\r\n[\"RAME_2000000.scl\"] 2026-05-20T16:12:23 2915041280 25568.512393 2915041280\r\n[\"CreditCard.scl\"] 2026-05-20T16:19:16 2999975936 361469.066081 41943040\r\n[\"RAME_2000000.scl\"] 2026-05-20T16:22:44 3040870400 25860.772138 3040870400\r\n<\/pre>\n<\/div>\nThe query found the two largest jobs for analysis. Their different start times reveal differences in system conditions when they ran. In these results, the highest records-per-second value for the CreditCard.scl<\/code> job occurred when less memory was used.<\/p>\nSpeed Example #2: Correlating Performance with Thread Count<\/h3>\n
Running the same representative job with different thread_max<\/code> settings in the cosortrc<\/code> file helps determine which setting performs best on a particular machine. The results can also help determine how many threads to license for CoSort on a given multi-core node.<\/p>\nHeader : \"specFile systemLoadPercentage threadMax elapsedSeconds\"\r\nSeparator : \"\\t\"\r\nOut : [File,\"longtimes.txt\"]\r\n\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.statistics.performance.systemLoadPercentage]\r\nSelect : [$.statistics.resourceControlSettings.threadMax]\r\nSelect : [$.statistics.performance.elapsedSeconds]\r\n\r\nWhere : [$.execution.specFiles[?(@.name == 'sort5_4198.scl')]]<\/pre>\nThe displayed longtimes.txt<\/code> output was formatted with additional tabs for readability:<\/p>\nspecFile systemLoadPercentage threadMax elapsedSeconds\r\n[\"sort5_4198m.scl\"] 9 1 62.12\r\n[\"sort5_4198m.scl\"] 25 6 28.812\r\n[\"sort5_4198m.scl\"] 24 5 29.419\r\n[\"sort5_4198m.scl\"] 24 4 31.499\r\n[\"sort5_4198m.scl\"] 22 3 31.235\r\n[\"sort5_4198m.scl\"] 14 2 43.108\r\n[\"sort5_4198m.scl\"] 9 1 62.316<\/pre>\nThe wrangled results above reveal that sort5_4198m.scl<\/code> achieved its fastest elapsed time of 28.812 seconds with 6 threads, despite the higher system load of 25%, and that performance scaled linearly as the thread count increased.<\/p>\nSpeed Example #3: Finding an Optimal Block Size<\/h3>\n
This query helps identify an efficient I\/O setting in the resource-control file for a given job. Identifying I\/O bottlenecks can save substantial processing time when jobs read or write thousands of gigabytes each day.<\/p>\n
Out : [File,\"C:\\IRI\\cosort110\\BlockSizeAnalysis.out\"]\r\nHeading : [AUTO]\r\n\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.execution.startTime]\r\nSelect : [$.statistics.resourceControlSettings.autoTune]\r\nSelect : [$.statistics.performance.recsPerSecond]\r\nSelect : [$.statistics.resourceControlSettings.blockSize]\r\n\r\nWhere : [$.execution.specFiles[?(@.name == 'CreditCard.scl')]]<\/pre>\nExample results:<\/p>\n
startTime autoTune recsPerSecond blockSize\r\n2026-07-31T11:43:24 Off 629591.080797 139264\r\n2026-07-31T11:44:26 Off 663350.248756 220000\r\n2026-07-31T11:45:01 Off 662910.507126 440000\r\n2026-07-31T12:11:31 On 669942.273336 614400\r\n2026-07-31T12:23:24 Off 685010.046809 1320000\r\n2026-07-31T12:29:45 Off 694846.902142 1640000\r\n2026-07-31T12:34:14 Minimize 668822.093412 139264<\/pre>\nThe report also includes the cosortrc<\/code> value for AutoTune<\/strong>, which configures memory and block size dynamically at runtime.<\/p>\nAccording to the source article:<\/p>\n
\nOn<\/code> is usually best for jobs running alone.<\/li>\nMinimize<\/code> is intended for multiple jobs.<\/li>\nOff<\/code> indicates that memory and block-size values were explicitly specified in the cosortrc<\/code> file.<\/li>\n<\/ul>\nIn this test, the highest measured throughput for CreditCard.scl<\/code> was associated with a block size of 1.64 MB<\/strong>.<\/p>\nFor broader tuning across multiple jobs, the Where<\/code> filter can be removed and job name added to the output:<\/p>\nHeader : \"JobName StartTime ElapsedTime RecordsPerSecond BlockSize\"\r\n\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.execution.startTime]\r\nSelect : [$.statistics.performance.elapsedTime]\r\nSelect : [$.statistics.performance.recsPerSecond]\r\nSelect : [$.statistics.resourceControlSettings.blockSize]\r\nSelect : [$.statistics.performance.systemLoadPercentage]<\/pre>\nSpeed Example #4: Identifying the Least Efficient Jobs<\/h3>\n
The records-per-second value recorded with each SortCL execution can be used to isolate performance bottlenecks. This example identifies jobs that meet a specified low-throughput threshold. Administrators can then examine the resource settings used by those jobs and determine what else may have been running on the system at the same time.<\/p>\n
Heading : [AUTO]\r\nSeparator : \"\\t\"\r\nOut : [File,\"slowThroughPut1.txt\"]\r\n\r\nSelect : [$.statistics.performance.recsPerSecond]\r\nWhere : [$[?(@.statistics.performance.recsPerSecond <= 30000)]]\r\nSelect : [$.execution.commandLine]\r\nSelect : [$.statistics.jobResults.recordsProcessed]\r\nSelect : [$.statistics.performance.systemLoadPercentage]\r\nSelect : [$.statistics.resourceControlSettings.threadMax]<\/pre>\nExample output:<\/p>\n
recsPerSecond jobName recordsProcessed systemLoadPercentage threadMax\r\n1612.903226 [\"sort5_4198m.scl\"] 100 14 4\r\n16949.152542 [\"sort5_4198m.scl\"] 1000 12 4\r\n25759.156302 [\"Replacer200.scl\"] 12000006 11 4<\/pre>\nAnother approach is to isolate jobs exceeding an elapsed-time threshold:<\/p>\n
Select : [$.execution.commandLine]\r\nSelect : [$.statistics.performance.elapsedSeconds]\r\nWhere : [$[?(@.statistics.performance.elapsedSeconds >=100)]]<\/pre>\nSpeed Example #5: Detecting Job Slowdowns from Concurrent Workloads<\/h3>\n
This query can help identify system bottlenecks caused by other jobs starting while a SortCL job is already running. If these overlaps are not addressed, they can result in unnecessary slowdowns. The system load percentage recorded in the log can indicate that another job began during the SortCL execution, while the start time lets you compare other job or system logs to determine what was running concurrently.<\/p>\n
Header : \"ScriptName StartTime RecordsPerSecond SystemLoadPercentage\"\r\n\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.execution.startTime]\r\nSelect : [$.statistics.performance.recsPerSecond]\r\nSelect : [$.statistics.systemInfo.systemLoadPercentage]<\/pre>\nThe example results compare two jobs running separately on one day and concurrently the next:<\/p>\n
ScriptName StartTime RecordsPerSecond SystemLoadPercentage\r\n[\"CUSTOMERS_14F.SCL\"] 2026-07-29 14:14:47 606857.793062 18\r\n[\"ENCRYPT_SSN.scl\"] 2026-07-29 16:15:00 153830.769231 10\r\n[\"CUSTOMERS_14F.SCL\"] 2026-07-30 14:15:28 583998.73467 21\r\n[\"ENCRYPT_SSN.scl\"] 2026-07-30 14:15:31 143389.101338 27<\/pre>\nThis query can also help a system administrator quickly identify patterns such as:<\/span><\/p>\n\n- Same job + lower
RecordsPerSecond<\/code> + higher SystemLoadPercentage<\/code><\/strong> \u2192 likely contention from another workload.<\/li>\n- Same job + consistently low throughput regardless of load<\/strong> \u2192 likely SortCL tuning issue.<\/li>\n
- High system load only during certain time windows<\/strong> \u2192 possible scheduled-application interference or overlapping batch activity.<\/li>\n<\/ul>\n
The log element $.statistics.jobResults.processID<\/code> may also be useful when correlating a SortCL execution with operating-system-level monitoring tools.<\/p>\n![\"\"](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/image3-1024x560.png\")
<\/p>\n
Security and Compliance Audit Examples<\/h2>\n
Audit Log Wrangler can also extract information useful for security review, compliance verification, incident tracing, access analysis, and OGS policy monitoring.<\/p>\n
Security Example #1: Tracing Jobs by User and Time<\/h3>\n
This example helps determine who accessed particular data at a particular time, supporting investigation against company role-based access control (RBAC) and zero-trust\/non-repudiation policies.<\/b><\/p>\n
![\"Workflow](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/tracing-jobs-1024x375.png\")
<\/p>\n
# Author: sidewind\r\n# Written: [2026-07-07T13-32-42]\r\n\r\nPolicy_Location : [C:\\IRI\\cosort110\\etc\\Policy]\r\nLog_Location : [C:\\IRI\\cosort110\\logs]\r\n\r\nRange :\r\n[Audit-2026-05-13T16-41-07-018360-CUMULUS-sortcl.json,\r\nAudit-2026-05-13T17-02-58-018364-CUMULUS-sortcl.json]\r\n\r\nHeading : [AUTO]\r\nSeparator : \"\\t\"\r\nOut : [File,\"nametest.txt\"]\r\n\r\nSelect : [$.execution.username]\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.execution.startTime]\r\nSelect : [logFileName]<\/pre>\nWhen the script runs in Wrangler interactive mode or from the command line, results can appear on screen or be written to a delimited file such as:<\/p>\n
username name startTime LogFileName\r\nsusan [\"sort5_4198m.scl\"] 2026-05-13T16:41:07 Audit-2026-05-13T16-41-07-018360-CUMULUS-sortcl.json\r\nsusan [\"sort5_4198m.scl\"] 2026-05-13T16:44:57 Audit-2026-05-13T16-44-40-018360-CUMULUS-sortcl.json\r\ndavid [\"repli_2000000.scl\"] 2026-05-13T16:57:56 Audit-2026-05-13T16-57-56-018441-CUMULUS-sortcl.json\r\njorge [\"aggregate2.scl\"] 2026-05-13T17:02:58 Audit-2026-05-13T17-02-58-018593-CUMULUS-sortcl.json\r\n<\/span><\/pre>\nWith Heading : [AUTO]<\/code>, the displayed header contains only the final log-schema element. A custom header can be specified instead, as shown in later examples.<\/p>\nSecurity Example #2: Finding Jobs That Access PII<\/h2>\n
This query helps manage data-breach and compliance risk by identifying jobs and data sources in which a specified sensitive field was processed.<\/p>\n
The example searches specifically for the PolicyHolder_SSN<\/code> field:<\/p>\nSeparator : \"\\t\"\r\nOut : [File,\"c:\\IRI\\cosort110\\logs\\Job11.out\"]\r\n\r\nHeader : \"JobName SourceName(s) FieldName\"\r\n\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.statistics.dataSources[*].name]\r\nSelect : [$.statistics.dataSources[*].fieldInfo[?(@.name == 'PolicyHolder_SSN')].name]\r\n\r\nWhere : [$.statistics.dataSources[*].fieldInfo[?(@.name == 'PolicyHolder_SSN')]]<\/pre>\nExample output:<\/p>\n
JobName SourceName(s) FieldName\r\n[\"sort5_4198m.scl\"] [\"BIG2\",\"BIG3\",\"BIG4\"] [\"PolicyHolder_SSN\"]\r\n[\"sort5_4198m.scl\"] [\"BIG2\",\"BIG3\",\"BIG4\"] [\"PolicyHolder_SSN\"]\r\n[\"sort6_4198m.scl\"] [\"BIG2\",\"BIG3\",\"BIG4\"] [\"PolicyHolder_SSN\"]\r\n[\"sort6_4198m.scl\"] [\"BIG2\",\"BIG3\",\"BIG4\"] [\"PolicyHolder_SSN\"]<\/pre>\nIn this case, PolicyHolder_SSN<\/code> was processed in two SortCL jobs, each of which ran twice.<\/p>\nThe article intentionally abbreviates the top portions of this and subsequent Wrangler scripts for space and shows only the relevant Select<\/code> and Where<\/code> queries needed to produce the results.<\/p>\nSecurity Example #3: Detecting Permission Violations and Failed Jobs<\/h2>\n
This ALW script identifies SortCL jobs that failed for any reason, including attempts to execute on an unlicensed hostname or failures caused by user access restrictions defined in the Policy File.<\/p>\n
Separator : \"\\t\"\r\nOut : [File,\"C:\\IRI\\cosort110\\BlockedJobs.out\"]\r\n\r\nHeader : \"StartTime User JobName ReturnCode ErrorMessage\"\r\n\r\nSelect : [$.execution.startTime]\r\nSelect : [$.execution.username]\r\nSelect : [$.execution.specFiles[*].name]\r\nSelect : [$.statistics.jobResults.returnCode]\r\nSelect : [$.statistics.jobResults.errorMessage]\r\n\r\nWhere : [$[?(@.statistics.jobResults.successfulCompletion == false)]]<\/pre>\nThe result in the BlockedJobs.out<\/code> file can contain entries such as:<\/p>\nStartTime User JobName ReturnCode ErrorMessage\r\n2026-05-10T10:14:37 joker [\"Group1000.scl\"] 46 license violation: incorrect node or invalid key\r\n2026-05-12T14:32:18 polly [\"ClaimMasking.scl\"] 210 Permission Denied\r\n2026-05-20T11:47:05 ethan [\"CustExtract.scl\"] 46 license violation: incorrect node or invalid key\r\n2026-05-20T13:08:54 susan [\"PolicyReport.scl\"] 210 Permission denied\r\n2026-05-20T15:26:41 joker [\"Group1000.scl\"] 46 license violation: incorrect node or invalid key<\/pre>\nFor error 46<\/strong>, the source article specifies examining the hostname in the log and sending IRI the contents of RegForm.txt<\/code> and the machine’s cosort.lic<\/code> file to determine the mismatch.<\/p>\nFor error 210 Permission Denied<\/strong>, the governor should examine the user and job name (.scl<\/code> script) against the active Policy File. The PFM utility can show that user’s permissions for the job script’s elements, or forms.<\/p>\nSecurity Example #4: Spotting Policy File Changes<\/h2>\n
This report supports change tracking and non-repudiation by monitoring modifications to the IRI Operational Governance System (OGS) Policy File<\/strong><\/a>.<\/p>\nSeparator : \"\\t\"\r\nOut : [File,\"c:\\iri\\cosort110\\polmod.out\"]\r\n\r\nSelect : [$.execution.username]\r\nSelect : [$.execution.startTime]\r\nSelect : [$.execution.commandLine]\r\nSelect : [$.execution.policy.whenModified]<\/pre>\nSelected polmod.out<\/code> results:<\/p>\n...\r\nsusan 2026-05-20T16:22:29 sortcl \/spec=example37.scl 2026-02-23T19:19:35\r\nsusan 2026-05-21T16:22:29 sortcl \/spec=Group1000.scl 2026-02-23T19:19:35\r\nsusan 2026-05-21T16:22:29 sortcl \/spec=example21.scl 2026-02-23T19:19:35\r\n...\r\nsusan 2026-05-26T12:44:44 sortcl \/spec=R_NAME_2000000.scl 2026-02-25T11:04:15\r\nsusan 2026-05-26T13:27:54 sortcl \/spec=SORT_NAME_2000000.scl 2026-02-25T11:04:15\r\nsusan 2026-05-26T13:22:03 sortcl \/spec=SORT_NAME_10000.scl 2026-02-25T11:04:15\r\nsusan 2026-05-26T14:27:38 sortcl \/spec=SORT_NAME_20.scl 2026-02-25T11:04:15<\/pre>\nWhen the report identifies a Policy File change, security officers can investigate PFM utility archives or Policy File change logs to determine exactly what policy changed, when the change occurred, and which OGS administrator, or governor<\/strong>, made it.<\/p>\n![\"Workflow](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/Tracking-Policy-File-Changes-1024x375.png\")
<\/p>\n
Using AI to Generate ALW Scripts<\/span><\/h2>\nBecause IRI OGS logs are stored in JSON and Wrangler parses them with JPath syntax, AI assistants such as ChatGPT, Claude, Copilot, and Gemini can help generate new queries. Users can describe the desired query in natural language and provide the AI assistant with enough information about the audit-log structure and Wrangler syntax to construct a corresponding .ALW<\/code> script.<\/p>\nYou will need to provide the AI engine with the log structure and specific requirements to build the script. A full sample log file, together with a representative ALW script from this article or the Wrangler section of the OGS manual that includes a SELECT<\/code> and WHERE<\/code> clause, should provide sufficient context.<\/p>\nWorkflow for Getting AI Help with an ALW Script<\/h3>\n\n- Gather Context: <\/strong>Collect a sample JSON audit log file or the relevant audit-log schema from the OGS manual, so the AI assistant can understand the data format.<\/li>\n
- Formulate the Request: <\/strong>Write a clear, descriptive prompt defining the goal of the audit.<\/li>\n
- Specify the Required Format: <\/strong>Tell the AI assistant to return the script using the specific
SELECT<\/code> and WHERE<\/code> syntax required by Wrangler.<\/li>\n<\/ol>\nExample AI Prompt Template<\/h3>\n
You can adapt the following template to the query you need:<\/p>\n
“I need to generate an IRI OGS Audit Log Wrangler (.alw) script. Here is a sample script: [Paste one here] and sample IRI OGS audit log from a SortCL job:\u00a0 [Upload or paste a sample log file or its schema here].<\/span><\/i><\/p>\nPlease create an .alw script that performs the following action: [Describe your goal, e.g., ‘Find all jobs where the user is ‘susan’ and the job result was unsuccessful’].<\/span><\/i><\/p>\nUse the following Wrangler syntax guidelines:<\/span><\/i><\/p>\n–\u00a0 Use ‘SELECT : [JPath]’ for fields.
\n<\/span><\/i>–\u00a0 Use ‘WHERE : [JPath condition]’ for filtering.
\n<\/span><\/i>–\u00a0 Include standard headers like Policy_Location and Log_Location as placeholders.
\n<\/span><\/i>–\u00a0 Include today\u2019s date in the comments and use a default or custom header as shown.
\n<\/span><\/i>–\u00a0 Specify a logical name for the tab-separated [or other-separated] output file”<\/span><\/i><\/p>\nKey Elements to Include in Your Scripts<\/b><\/h3>\n
When reviewing an ALW script generated by an AI assistant, verify that it contains the components used in successful .ALW<\/code> files:<\/p>\n\n- Script header information:<\/strong> Policy File path and filename, log-folder location, log-date range, output filename for the extract, and delimiter character or separator.<\/li>\n
- Output header format:<\/strong>
Heading : [AUTO]<\/code> uses the final element in the JSON key name unless a custom header is provided in quotes.<\/li>\n- Query logic:<\/strong>
SELECT<\/code> statements identify fields to display, while a WHERE<\/code> clause filters for a condition using JPath syntax.<\/li>\n- Comments:<\/strong> Lines beginning with
#<\/code> can document the script’s purpose, author, and date.<\/li>\n<\/ul>\nBy providing the schema and a clearly defined query goal, you can map your requirements to Wrangler’s JPath query capabilities and produce a fit-for-purpose .ALW<\/code> job script.<\/span><\/p>\nFAQ<\/h2>\n![\"\"](\"https:\/\/www.iri.com\/blog\/wp-content\/uploads\/2026\/09\/faq-1024x673.png\")
<\/h3>\nWhat does IRI Audit Log Wrangler do?<\/h3>\n
Audit Log Wrangler extracts information from the JSON audit logs generated by SortCL-compatible executions. It can parse, filter, report on, and export selected log information for performance analysis, security review, compliance auditing, and related operational analysis.<\/p>\n
What is the difference between interactive and batch mode?<\/h3>\n
Interactive mode guides the user through selecting logs, defining query criteria, viewing results, and saving an ALW script. Batch mode executes previously saved .ALW<\/code> scripts from the command line and is suitable for repeatable audit and reporting workflows.<\/p>\nCan Audit Log Wrangler help identify jobs that process PII?<\/h3>\n
Yes. The article demonstrates an ALW script that searches audit-log metadata for a specified sensitive field\u2014in the example, PolicyHolder_SSN<\/code>\u2014and reports the SortCL job and source names associated with that field.<\/p>\nCan Audit Log Wrangler help diagnose performance problems?<\/h3>\n
Yes. The examples in this article use logged information such as memory allocation, thread count, records per second, block size, elapsed time, and system load to compare job executions and investigate performance differences.<\/p>\n
Can AI assistants generate Audit Log Wrangler scripts?<\/h3>\n
The article describes using AI assistants to help generate .ALW<\/code> scripts when they are given the audit-log schema or a representative log, an example Wrangler script, the desired query, and instructions for using Wrangler’s JPath SELECT<\/code> and WHERE<\/code> syntax.<\/p>\nSummary<\/b><\/h2>\n
Audit Log Wrangler is a companion to the OGS audit-logging framework that converts raw JSON job logs into requested information for compliance, data security, performance tuning, and operational oversight<\/strong>.<\/p>\nWrangler uses targeted filtering, secure sharing, and structured reporting to help organizations make full use of the rich metadata in OGS without being overwhelmed by its volume or complexity. Wrangler’s JPath query support also makes it possible to provide an AI assistant with a representative audit log or schema, a sample .ALW<\/code> script, and a description of the desired query so that the assistant can help construct another ALW script.<\/span><\/p>\nTogether with the Policy File, PFM utility, and script signature system, Wrangler forms part of the operational governance environment for SortCL-driven jobs in IRI CoSort, FieldShield, NextForm, RowGen, and Voracity production environments.<\/p>\n
For questions or assistance using IRI Audit Log Wrangler, contact support@iri.com<\/span><\/a>.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"Quick Overview IRI Audit Log Wrangler (ALW), introduced with the CoSort v11 Ops Governance System (OGS), extracts actionable information from the JSON audit logs generated by SortCL-compatible executions. Using SQL- and JSONPath-compatible query syntax in .ALW scripts, CoSort users can analyze job performance and resource-control settings, while FieldShield and other SortCL users can audit sensitive-data<\/p>\n