Ironstream Configuration and Users Guide v2.1 PDF

Ironstream™
Configuration and User’s Guide
Version 2.1 - PTF SDF2179

Ironstream™ Configuration and User’s Guide
Document Number: SI-5704-03
© 2014, 2019 Syncsort Incorporated. All rights reserved.
Syncsort is the global leader in Big Iron to Big Data software. We organize data everywhere, to keep the
world working - the same data that powers machine learning, AI and predictive analytics. We use our
decades of experience so that more than 7,000 customers, including 84 of the Fortune 100, can quickly
extract value from their critical data anytime, anywhere. Our products provide a simple way to optimize,
assure, integrate, and advance data, helping to solve for the present and prepare for the future. Learn
more at syncsort.com.
Version 2.1 - PTF SDF2179

Last Update: March 14, 2019
Contents
List of Figures .............................................................................................................xiii
List of Panels ............................................................................................................... xv
List of Tables .............................................................................................................. xvii
SECTION I, About Ironstream

Chapter 1: Introduction ........................................................................................... 1-1
What’s in this Guide......................................................................................... 1-2
Audience ........................................................................................................... 1-4
Related Resources ............................................................................................ 1-4
Syncsort Knowledge Base ............................................................................ 1-4
Additional Documentation........................................................................... 1-5
Conventions...................................................................................................... 1-5
Chapter 2: Understanding Ironstream ................................................................. 2-1

What Is Ironstream? ........................................................................................ 2-1
What Data Does Ironstream Collect from z/OS? ......................................... 2-1
What Happens to z/OS Data in a Destination? ........................................... 2-2
What Happens If Ironstream Is Unable to Deliver Data to a
Destination? ................................................................................................. 2-2
Fast and Efficient Performance ................................................................... 2-2
Ironstream Components................................................................................... 2-2
Ironstream Forwarders................................................................................ 2-2
Data Collection Extension (DCE) ................................................................ 2-3
The Ironstream Desktop (IDT) .................................................................... 2-3
Network Monitoring Components Alerts..................................................... 2-3
Supported Data Sources ................................................................................... 2-5
Ironstream Design Roadmap ........................................................................... 2-7
Which destination is your data being forwarded data to? ........................... 2-7
What type of z/OS environment? ................................................................. 2-7
What type of security? ................................................................................. 2-7
What data types are going to be forwarded? ............................................... 2-7
Does your environment require minimal data loss? .................................... 2-8
Should I manually configure Ironstream or use the Configurator Tool?..... 2-8
Ironstream Starter Edition .............................................................................. 2-8
Integration with Splunk Premium Applications.............................................. 2-9
Ironstream Configuration and User’s Guide i

SECTION II, Configuring Ironstream Target Destinations
Chapter 3: Setting Up Splunk for Ironstream ..................................................... 3-1
Overview of Setting Up Splunk........................................................................ 3-1
Setting Up a Non-SSL Port .............................................................................. 3-2
Setting Up an SSL Port.................................................................................... 3-2
Splunk Platform........................................................................................... 3-2
Mainframe Platform .................................................................................... 3-2
Setting Up a Splunk Index............................................................................... 3-3
Next Steps ........................................................................................................ 3-3
Chapter 4: Setting Up Elastic for Ironstream ..................................................... 4-1

Overview of Elastic Support in Ironstream ..................................................... 4-1
Elastic Limitations with Ironstream ........................................................... 4-1
Forwarding Data to Logstash........................................................................... 4-2
Sending Data to Logstash............................................................................ 4-2
Logstash Configuration ............................................................................... 4-2
Receiving Ironstream Data in Elasticsearch.................................................... 4-4
Displaying Ironstream Data in Kibana............................................................ 4-4
Field Mappings and Elastic Defaults ............................................................... 4-4
Next Steps ........................................................................................................ 4-4
Chapter 5: Setting Up Kafka for Ironstream ....................................................... 5-1

Overview of Apache Kafka Support in Ironstream .......................................... 5-2
How Does Kafka Work with Ironstream? .................................................... 5-2
Kafka Requirements and Limitations with Ironstream .............................. 5-2
Instructions for Downloading and Configuring Kafka on Ironstream ........ 5-2
Downloading and Installing Kafka to z/OS OMVS Systems............................ 5-3
Converting Binary Kafka Files from ASCII to EBCDIC (Optional) ............ 5-3
Applying the Kafka Function to Ironstream .................................................... 5-4
Providing APF Authorization for Ironstream Programs.................................. 5-5
Authorizing the Ironstream Kafka Modules................................................ 5-5
Authorizing the Java Libraries.................................................................... 5-5
Configuring Ironstream to Use the Kafka Producer ........................................ 5-6
Setting the Ironstream DESTINATION...................................................... 5-6
Example Ironstream JCL for Sending Data to Kafka Brokers ................... 5-7
Configuring Ironstream to Use Other Kafka Producer Configurations ...... 5-7
Confirming Kafka Activity Status in Ironstream ............................................ 5-8
Messages Issued by Kafka ............................................................................... 5-9
Next Steps ...................................................................................................... 5-10
ii Ironstream Configuration and User’s Guide

SECTION III, Configuring and Running Ironstream
Chapter 6: Configuring Ironstream Components .............................................. 6-1
Overview........................................................................................................... 6-2
Manually Configuring Data Sources vs. Using the Configurator Utility .... 6-2
Installation Verification Process (IVP) ........................................................ 6-2
Manually Configuring Ironstream ................................................................... 6-4
Set Up Your Configuration File ................................................................... 6-4
Set Up the Ironstream Tasks....................................................................... 6-5
Configure Selected Data Sources................................................................. 6-5
Next Steps.................................................................................................... 6-6
About the Ironstream Configurator Utility...................................................... 6-7
DCE, IDT, and XCF Configuration Considerations..................................... 6-8
Running the Ironstream Configurator Utility ............................................... 6-11
Launch the Ironstream Configurator ........................................................ 6-11
Select the Ironstream Components to Configure....................................... 6-12
Specify the Ironstream Forwarder Parameters......................................... 6-14
Specify the DCE Parameters ..................................................................... 6-15
Specify the Ironstream Desktop (IDT) Parameters ................................... 6-17
Specify the Log4j Parameters .................................................................... 6-19
Configure the Network Monitoring Components ...................................... 6-20
Create the NMC Run-time Objects............................................................ 6-23
Post Configurator: Additional Actions ........................................................... 6-23
Chapter 7: Manually Setting Ironstream Parameters ...................................... 7-1

Overview of the Configuration File .................................................................. 7-2
Static versus Dynamic Modification of an Ironstream Configuration......... 7-2
General Syntax Rules....................................................................................... 7-3
Keywords ..................................................................................................... 7-3
Comments and Columns .............................................................................. 7-3
Parameter List Delimiters and Continuation Methods............................... 7-3
Section Identifiers and Parameters ............................................................. 7-4
Configuration Records Echoed to SYSPRINT ............................................. 7-5
Syntax Note about the Ironstream Starter Edition..................................... 7-5
Configuration Parameters................................................................................ 7-6
KEYS Section............................................................................................... 7-6
SYMBOLS Section ....................................................................................... 7-6
SYSTEM Section.......................................................................................... 7-7
DESTINATION Section ............................................................................. 7-11
SOURCE Section ....................................................................................... 7-16
Typical Ironstream Parameters ..................................................................... 7-27
Configuration File Examples ......................................................................... 7-29
Forwarding SMF Data (Single Indexer) .................................................... 7-29
Forwarding Syslog Data using SSL (Two Indexers) .................................. 7-30
Forwarding Log4j Data (Single Indexer) ................................................... 7-30
Ironstream Configuration and User’s Guide iii

Offline Ingestion of SMF Data (Single Indexer) ........................................ 7-31
Offline Ingestion of Log4j Data (Single Indexer) ....................................... 7-31
Offline Ingestion of Log4j Data from a z/OS Data Set............................... 7-32
Offline Ingestion of Log4j Data using PATTERN...................................... 7-32
Forwarding Syslog Data using SSL and Translate Table ......................... 7-33
Using KEEP ALIVE at the SYSTEM and PORT Level............................. 7-34
Chapter 8: Controlling Ironstream Components ............................................... 8-1

Controlling Ironstream Forwarders ................................................................. 8-1
Starting Ironstream Forwarders ................................................................. 8-1
Starting an Ironstream API Forwarder....................................................... 8-2
Stopping Ironstream Forwarders ................................................................ 8-2
Checking Ironstream Forwarder Status...................................................... 8-2
Controlling the Ironstream Desktop (IDT) ...................................................... 8-3
Starting the IDT .......................................................................................... 8-3
Stopping the IDT ......................................................................................... 8-3
Deploying Multiple IDT Instances............................................................... 8-4
Controlling the Data Collection Extension (DCE) ........................................... 8-4
Starting DCE ............................................................................................... 8-4
Stopping DCE .............................................................................................. 8-6
Controlling the Network Monitoring Components (NMC)............................... 8-7
EE Monitor .................................................................................................. 8-7
FTP Control ................................................................................................. 8-7
IP Monitor.................................................................................................... 8-7
OSA Monitor ................................................................................................ 8-7
UNIX Server ................................................................................................ 8-7
Chapter 9: Dynamically Modifying a Running Ironstream Configuration ... 9-1

Overview........................................................................................................... 9-1
Dynamic Reconfiguration Limitations ............................................................. 9-2
How Ironstream Performs a Dynamic Change in the Current Configuration. 9-2
Dynamic Reconfiguration Commands.............................................................. 9-3
Dynamic Reconfiguration Procedure................................................................ 9-3
Messages Issued by Dynamic Reconfiguration ................................................ 9-4
Chapter 10: Configuring Data Loss Prevention ................................................ 10-1

Overview......................................................................................................... 10-1
Ironstream System Requirements for Using DLP ......................................... 10-2
Configuring Ironstream DLP Parameters ..................................................... 10-3
Configuring Splunk Parameters .................................................................... 10-4
Best Practices When Using DLP .................................................................... 10-4
Configuring SMF Record Collection When Using DLP ............................. 10-4
Messages Issued by DLP ................................................................................ 10-5
iv Ironstream Configuration and User’s Guide

SECTION IV, Setting Up Ironstream Data Sources
Chapter 11: Syslog Message Filtering ................................................................ 11-1
Overview of Filter Modules ............................................................................ 11-1
Syslog Message Filtering................................................................................ 11-2
Chapter 12: SMF Record Filtering ....................................................................... 12-1

Overview of SMF Record Filtering................................................................. 12-2
Using the Ironstream Configuration File to Create SMF Filter
Configurations ........................................................................................... 12-2
Using IDT to Create SMF Filter Configurations....................................... 12-2
Using the READ Command ....................................................................... 12-2
Gathering SMF Data...................................................................................... 12-3
Supported SMF Record Types ........................................................................ 12-4
Manually Defining SMF Filtering Configurations......................................... 12-7
Limiting SMF Record Selection with WHERE Search Conditions ................ 12-7
Overview of WHERE Statements .............................................................. 12-7
Understanding the WHERE Syntax.......................................................... 12-8
WHERE Search Conditions ....................................................................... 12-9
Validating Command Syntax with a PARM Option ................................ 12-12
Using the SMF Filter Configuration Builder in IDT ................................... 12-13
Required JCL to Run the SMF Filter Configuration Builder.................. 12-13
SMP/E Updates to the SMF Dictionary................................................... 12-14
Using the SMF Filter Configuration Panels............................................ 12-15
Using the READ Command to Share SMF Filter Configurations ............... 12-22
Implementing a Custom CICS Monitor Dictionary in Ironstream .............. 12-23
The Need for CICS Monitor Dictionary Processing ................................. 12-23
Process Flowchart: Steps to Implement .................................................. 12-23
Using the CICS DFHMNDUP Utility to Create SMF 110 Dictionary
Records..................................................................................................... 12-25
Using the SSDFGDIC Utility to Process CICS Monitor Records ............ 12-25
Using The SSDFGDIC SYSIN Commands .............................................. 12-30
General Comments on the Control Statement Format for SSDFGDIC .. 12-31
System Messages for a Custom CICS Monitoring Dictionary ................. 12-31
Sample SMF Filter Configurations .............................................................. 12-31
Sample Filtering for All Fields in SMF Records...................................... 12-31
Sample Filtering for Specific Fields in SMF Records .............................. 12-31
Sample Filtering for All SMF Records Using Control Statements.......... 12-32
Chapter 13: SYSOUT Forwarding ......................................................................... 13-1

Using the SYSOUT Forwarding Function ..................................................... 13-1
Configuring Ironstream for SYSOUT Forwarding .................................... 13-2
The Selection and Forwarding Process...................................................... 13-2
Format of Forwarded Spool Data .............................................................. 13-2
Ironstream Configuration and User’s Guide v

Controlling the Job and Output Scan Wait Time ...................................... 13-3
Advanced Spool Data Forwarder Options ................................................. 13-3
Fields Forwarded from SYSOUT to Ironstream Destinations .................. 13-4
SYSOUT Selection and Filtering ................................................................... 13-4
Overview .................................................................................................... 13-4
Job and Data Set Selection ........................................................................ 13-4
Filtering Criteria ....................................................................................... 13-5
Job and Data Set Class Exclusion ............................................................. 13-5
Selection and Filter Keywords and Rules.................................................. 13-6
Using the Advanced PRINT Data Block Parameters................................... 13-13
Using Advanced Options to Process Log4j Data...................................... 13-14
SYSOUT Forwarding Parameter Examples and Sample Output................ 13-15
SYSOUT Forwarding Examples .............................................................. 13-15
SYSOUT Data Forwarding Examples ..................................................... 13-17
Chapter 14: Alerts and SyslogD Forwarding ..................................................... 14-1

Overview of Network Management Components........................................... 14-2
Configuring ZEN for Ironstream.................................................................... 14-2
ZEN Component Alert Generation................................................................. 14-3
The OSA MONITOR (ZOM) ........................................................................... 14-3
The LINUX MONITOR (ZLM) ....................................................................... 14-7
FTP CONTROL (ZFC).................................................................................... 14-8
The EE MONITOR (ZEM)............................................................................ 14-10
The IP MONITOR (ZIM) .............................................................................. 14-13
Routing SyslogD Messages to Ironstream.................................................... 14-19
Overview .................................................................................................. 14-19
Configuring ZEN to Route SyslogD Messages to Ironstream.................. 14-20
More Information about Alerts and SyslogD Forwarding............................ 14-20
Chapter 15: DB2 Data Forwarding ...................................................................... 15-1

Overview of DB2 Tables ................................................................................. 15-1
Configuration for DB2 Table Data ................................................................. 15-1
DB2 Definitions ......................................................................................... 15-1
Sample SSDFTRIG .................................................................................... 15-2
Sample SSDFPROC ................................................................................... 15-2
Ironstream DB2 Data Definitions ............................................................. 15-2
Enabling Data Loss Prevention in Splunk for DB2 Forwarding ................... 15-3
Configuration File Example for DB2 Data with DLP................................ 15-3
Command to Run Ironstream for DB2 Data with DLP ............................. 15-3
vi Ironstream Configuration and User’s Guide

Chapter 16: Sequential File Forwarding ............................................................ 16-1
Capturing Sequential Data ............................................................................ 16-1
Sequential File Forwarding Example ............................................................ 16-2
Batching FILELOAD Data............................................................................. 16-3
FILELOAD Batching Control Statements................................................. 16-3
BATCH_COUNTER Usage Notes ............................................................. 16-3
BATCH_RECORDS Usage Notes .............................................................. 16-4
FILELOAD Batching Example .................................................................. 16-4
Chapter 17: System State Forwarding ................................................................ 17-1

Overview......................................................................................................... 17-1
Configuring Ironstream for System State Forwarding .................................. 17-2
System-level Data Fields Forwarded to Destinations.................................... 17-2
Chapter 18: Configuring and Using the Ironstream API ................................ 18-1
Overview of the Ironstream API .................................................................... 18-2
Single-send versus Multi-send API ........................................................... 18-2
System Requirements ................................................................................ 18-2
Defining the IRONSTREAM_API Data Type ................................................ 18-3
Data Type Parameters............................................................................... 18-3
CLASS, TYPE, and SUBTYPE Parameters .............................................. 18-3
Ironstream API Configuration Example.................................................... 18-4
Using the Single-send API ............................................................................. 18-5
Single-send API Parameters...................................................................... 18-6
RACF Authorization for the Single-send API............................................ 18-7
Using the Single-send SSDFAPI Routine.................................................. 18-7
Performance and Maintenance Considerations....................................... 18-10
Linking SSDFAPI Into a Load Module.................................................... 18-10
Starting a Single-end API Instance ......................................................... 18-10
Using the Single-send API in CICS ......................................................... 18-11
Using the Multi-send API ............................................................................ 18-12
Multi-send API Request Types ................................................................ 18-12
Multi-send API Parameters..................................................................... 18-13
RACF Authorization for the Multi-send API ........................................... 18-14
Using the Multi-send SSDFPAPI Routine............................................... 18-15
Performance and Maintenance Considerations....................................... 18-16
Linking SSDFPAPI Into a Load Module ................................................. 18-17
Starting a Multi-send API Instance ........................................................ 18-17
Troubleshooting the Ironstream API ........................................................... 18-17
Return Codes and Reason Codes Generated by the Ironstream API ...... 18-18
Handling Data Store Full Conditions ...................................................... 18-20
Ironstream API Coding Examples ............................................................... 18-21
Single-Send API Examples ...................................................................... 18-21
Multi-send API Coding Examples ........................................................... 18-36
Ironstream Configuration and User’s Guide vii

Chapter 19: Setting Up Log4j ............................................................................... 19-1
Overview of Log4j ........................................................................................... 19-1
Defining the Log4j Parameters ...................................................................... 19-2
Sample Log4j Configurations ......................................................................... 19-2
SDFAppender Sample in log4j.xml............................................................ 19-2
SDFAppender Sample in log4j.properties ................................................. 19-3
SDF2Appender Samples for Log4j 2.x ....................................................... 19-3
How to use PATTERN in the Log4j Reader Facility ...................................... 19-4
Chapter 20: IMS Log Record Forwarding ........................................................... 20-1

Overview of IMS Log Record Forwarding ...................................................... 20-2
Excluded Functionality.............................................................................. 20-2
Synchronous versus Asynchronous IMS Log Record Capture................... 20-2
Synchronous IMS Log Gathering ................................................................... 20-3
Activating the log write Exit...................................................................... 20-3
Forwarder Task JCL.................................................................................. 20-4
Asynchronous IMS Log Gathering ................................................................. 20-4
IMS Log Record Extraction Process ............................................................... 20-5
Using the Category Keyword ..................................................................... 20-6
IMS Log Record Processing ............................................................................ 20-7
IMS Log Record Field Descriptions................................................................ 20-8
Log Records 01 – (Input Message) and 03 (Output Message).................... 20-9
Log Record 06 – IMS Stop/Start ............................................................. 20-22
Log record 07 – Application End ............................................................ 20-23
Log record 08 – Application Start .......................................................... 20-27
Log Record 0A – CPIC Application Start/End ........................................ 20-29
Log Record 31 – Message GU Call .......................................................... 20-31
Log Record 32 – Message Rejected ......................................................... 20-33
Log Record 33 – Message Freed .............................................................. 20-34
Log Record 34 - Message Cancelled ........................................................ 20-35
Log Record 35 – Message Enqueued ...................................................... 20-36
Log Record 38 – Message Re-queued after an Abend ............................. 20-39
Log Record 45 – System Statistics........................................................... 20-41
Log Record 56 – Unit-of-Recovery............................................................ 20-62
Log Record F9 – User Record................................................................... 20-72
Log Record FA – User Record .................................................................. 20-75
Messages Issued by IMS Log Records .......................................................... 20-85
viii Ironstream Configuration and User’s Guide

SECTION V, Setting Up the Data Collection Extension Data Types
Chapter 21: Configuring the DCE Parameters .................................................. 21-1
Overview of DCE ............................................................................................ 21-1
DCE Configuration Files ................................................................................ 21-2
Global Parameters ..................................................................................... 21-3
Ironstream Cluster Parameters................................................................. 21-3
Include Parameter Group .......................................................................... 21-4
Syntax for DCE Configuration Parameters ................................................... 21-5
Ironstream Forwarder Configuration Files.................................................... 21-5
Chapter 22: Setting Up USS File Collection ....................................................... 22-1

Overview of USS File Collection .................................................................... 22-1
Adjust File Monitoring and Offloading...................................................... 22-1
Scan for Duplicate Files............................................................................. 22-2
Tail Volatile Files....................................................................................... 22-2
Dynamic Administration of USS Processing Using IDT ........................... 22-2
Flexible Start Types................................................................................... 22-2
USS File Offload Operational Diagram ..................................................... 22-3
Summary of DCE’s USS Offload Functions ................................................... 22-4
Configuring DCE for USS File Offload .......................................................... 22-4
Overview .................................................................................................... 22-4
USS Defaults Parameters.......................................................................... 22-5
USS Filter Parameters .............................................................................. 22-8
Notes on USS File Filtering....................................................................... 22-9
USS Directory Parameters ...................................................................... 22-10
Duplicate USS File Detection....................................................................... 22-12
Overview .................................................................................................. 22-12
How Duplicate USS File Detection Works .............................................. 22-12
Modifying the Duplicate File Detection Behavior ................................... 22-12
USS File Tailing Process .............................................................................. 22-13
How It Works ........................................................................................... 22-13
Tailing Volatile Files ............................................................................... 22-13
Dynamically Modifying USS Processing ...................................................... 22-14
Overview .................................................................................................. 22-14
Accessing the Ironstream Desktop USS panels....................................... 22-14
Displaying the USS Files Status Panel ................................................... 22-14
Dynamically Modifying USS Settings ..................................................... 22-15
Chapter 23: Setting Up the RMF Data Forwarder ........................................... 23-1

Overview of the RMF Data Forwarder........................................................... 23-1
Configuring the RMF Data Forwarder .......................................................... 23-2
Configuring DCE RMF Parameters ............................................................... 23-2
Define RMFSettings .................................................................................. 23-3
Ironstream Configuration and User’s Guide ix

Setting the ScanFrequency........................................................................ 23-4
Defining Security Settings ............................................................................. 23-5
Changing the RMF User ID or Password .................................................. 23-6
Setting the RMF Filters in IDT...................................................................... 23-6
About the RMF Filters Panel..................................................................... 23-6
Sample Scenario for Setting RMF Filters .................................................... 23-10
Step 1: Open the RMF Filters Panel........................................................ 23-10
Step 2: Activate Filtering for Volumes .................................................... 23-11
Step 3: Specify the Metrics Collected for Selected Volumes .................... 23-12
Step 4: Specify the Metrics Collected per LPAR...................................... 23-14
SECTION VI, Integration with Splunk Premium Applications

Chapter 24: Splunk Enterprise Security and Ironstream ............................... 24-1
About Splunk Enterprise Security and Ironstream ....................................... 24-1
Ironstream Enterprise Security Technology Add-on (TA) ......................... 24-1
Intrusion Detection ........................................................................................ 24-2
Splunk ES Visibility .................................................................................. 24-3
TSO Log-on Activity ....................................................................................... 24-3
TSO Account Activity ..................................................................................... 24-3
FTP Sessions .................................................................................................. 24-4
FTP Change Analysis ..................................................................................... 24-5
IP Traffic Analysis.......................................................................................... 24-5
Network Management/User-Defined Notification ......................................... 24-6
SECTION VI, Troubleshooting Ironstream

Chapter 25: Ironstream Commands ................................................................... 25-1
Overview......................................................................................................... 25-1
Management Commands................................................................................ 25-2
STOP.......................................................................................................... 25-2
MODIFY Commands ...................................................................................... 25-2
BLOCKPRINT ........................................................................................... 25-2
DEBUG ...................................................................................................... 25-2
DUMP ........................................................................................................ 25-2
LIST ........................................................................................................... 25-3
RECONFIGURE ........................................................................................ 25-4
RECORDPRINT ........................................................................................ 25-4
x Ironstream Configuration and User’s Guide

RESTART .................................................................................................. 25-4
STATUS ..................................................................................................... 25-4
SMF Real-time INMEM Commands .............................................................. 25-5
Chapter 26: Operational Considerations ........................................................... 26-1

Message Flood Automation and Syslog Message Collection .......................... 26-1
Network Contention ....................................................................................... 26-1
Data Store Filling or Full Condition .............................................................. 26-2
Recommended Data Store Configuration Guidelines ................................ 26-2
Chapter 27: Ironstream Messages ...................................................................... 27-1

Overview of Ironstream Messages ................................................................. 27-1
Ironstream Messages ..................................................................................... 27-2
Data Collection Extension Messages ........................................................... 27-76
Chapter 28: Diagnostics and Contacting Syncsort Product Support ........... 28-1
Before Calling Syncsort Product Support ...................................................... 28-1
Searching the Syncsort Knowledge Base................................................... 28-1
Contacting Syncsort Product Support............................................................ 28-2
North America ........................................................................................... 28-2
Europe, Middle East, and Africa ............................................................... 28-2
Other Regions ............................................................................................ 28-2
SECTION VII, Ironstream Audit Reporting

Chapter 29: Using the Ironstream Data Usage Reporter ............................... 29-1
Overview......................................................................................................... 29-1
Configuring the Report Parameters ............................................................... 29-2
Basic JCL to Produce a Printed Report ..................................................... 29-2
SYSIN Parameters..................................................................................... 29-3
SELECT Parameters ................................................................................. 29-4
REPORT Parameters................................................................................. 29-4
Using the Report TRACE Facility.................................................................. 29-5
CSV File Report Format................................................................................. 29-5
Overriding the Default SMF Record Number ................................................ 29-6
Ironstream Configuration File................................................................... 29-6
Copying and Renaming the Default SMF Modules ................................... 29-6
System Messages for the Data Usage Reporter ............................................. 29-7
Ironstream Configuration and User’s Guide xi

SECTION VIII, Appendices
Appendix A: Forwarded Data Formats ............................................................... A-1
Syslog Format.................................................................................................. A-2
FILELOAD Format ......................................................................................... A-3
SYSOUT Format ............................................................................................. A-3
Log4j Format ................................................................................................... A-4
Alert Format.................................................................................................... A-4
SyslogD Format............................................................................................... A-5
Appendix B: The SSDFCPR Utility ......................................................................... B-1

Overview of SSDFCPR .................................................................................... B-1
Executing SSDFCPR ....................................................................................... B-1
Index ............................................................................................................................. i
xii Ironstream Configuration and User’s Guide

List of Figures
Example Kafka Statistics Output in STDOUT ........................................................................... 5-8
Sample Ironstream Configuration File for syslog .................................................................... 6-4
Sample Started Task JCL ......................................................................................................... 6-5
DCE Component Architecture ................................................................................................. 6-8
Ironstream Configuration for the USS Data Type ................................................................... 6-9
Ironstream Configuration for the RMF Data Type .................................................................. 6-9
DCE Configuration for USS .................................................................................................... 6-10
Sample Started Task JCL .......................................................................................................6-15
Summary of all DESTINATION Parameters ..........................................................................7-11
Typical Parameters for a TCP Non-SSL Member ...................................................................7-27
Typical Parameters for a TCP SSL Member ...........................................................................7-28
Example STATUS Output ......................................................................................................... 8-2
Required Ordering of Parameters when Using DLP ..............................................................10-3
Sample IDT JCL for SMF Filter Configuration Panels ...........................................................12-13
Process Flow to Implement a Custom CICS Monitor Dictionary .........................................12-24
Control Statement for SSDFAPI ..........................................................................................18-10
Control Statement for SSDFPAPI ........................................................................................18-17
Sample DCE Configuration for USS .......................................................................................21-2
Sample DCE Configuration for RMF III ..................................................................................21-2
Sample USS Data Type Configuration File ............................................................................21-5
Sample RMF Data Type Configuration File ...........................................................................21-6
Ironstream USS File Offload Operational Diagram ...............................................................22-3
Available USS Directory Parameters ...................................................................................22-10
Examples of Typical USS Directory Group Parameters .......................................................22-11
Example of USS Directory Name Using a Long Path ...........................................................22-11
Example of USS Directory Name Using Special Characters ................................................22-12
Sample Configuration for RMF Data Type ............................................................................23-2
Example LIST-MODULES Output ...........................................................................................25-3
Example STATUS Output .......................................................................................................25-5
Sample Usage Summary Report ...........................................................................................29-2
Sample Daily Usage Report ..................................................................................................29-3
Sample Data Usage Report in CSV Format ...........................................................................29-5
Sample Data Usage Report in a Spreadsheet ......................................................................29-6
Ironstream Configuration and User’s Guide xiii

xiv Ironstream Configuration and User’s Guide
List of Panels
Initial Configuration ..............................................................................................................6-11
Ironstream Component Selection ........................................................................................6-12
List NMC Configuration Members ........................................................................................6-13
Ironstream Forwarder Tasks .................................................................................................6-14
DCE Configuration ................................................................................................................6-15
IDT Configuration ..................................................................................................................6-17
Setting Authority Level within IDT ........................................................................................6-18
Log4j Forwarder Parameters ................................................................................................6-19
EE Monitor Configuration ..................................................................................................... 6-20
FTP Control Configuration .................................................................................................... 6-21
IP Monitor Configuration ......................................................................................................6-21
OSA Monitor Configuration ..................................................................................................6-22
UNIX Server Configuration .................................................................................................... 6-22
Ironstream Desktop Login Panel ............................................................................................. 8-3
SMF Filter Configuration - DEFAULT only ...........................................................................12-15
Configuration BOBDYLAN - Collapsed Record Types ..........................................................12-18
Configuration BOBDYLAN - Expanded Record Types ..........................................................12-20
Viewing SMF 110 Subtypes 1 and 2 ....................................................................................12-20
Viewing Configuration BOBDYLAN .....................................................................................12-21
Synchronous IMS Log Capture ..............................................................................................20-2
Asynchronous IMS Log Capture ............................................................................................20-3
Ironstream Desktop Menu Bar ...........................................................................................22-14
Accessing the USS File Status ..............................................................................................22-14
USS File Status ....................................................................................................................22-15
USS Defaults .......................................................................................................................22-16
USS Directories ...................................................................................................................22-16
Directory Scan Attributes ...................................................................................................22-17
USS Filters ...........................................................................................................................22-18
RMF Filters Panel ..................................................................................................................23-7
RMF Filters - No Metrics Selected ......................................................................................23-10
RMF Elements for VOL ........................................................................................................23-11
RMF Filters Panel - With 3 Volumes Selected .....................................................................23-11
RMF Filters Panel - With 3 Volumes Selected .....................................................................23-12
RMF Metrics for Volume Panel - With 3 Volumes Selected ...............................................23-12
RMF Metrics for Volume Panel - With 25 Metrics Selected ...............................................23-13
RMF Metrics for Volume Panel - With 75 Metrics Selected ...............................................23-14
Selected RMF Metrics Panel ...............................................................................................23-15
RMF Attributes for ENCLAVE ..............................................................................................23-15
Ironstream Configuration and User’s Guide xv

xvi Ironstream Configuration and User’s Guide
List of Tables
Sections and Chapters in this Guide ....................................................................................... 1-2
Text Conventions.................................................................................................................... 1-5
Network Monitoring Components ......................................................................................... 2-4
Ironstream Mainframe Data Sources ..................................................................................... 2-5
Ironstream Data Sources ........................................................................................................ 6-5
Generated NMC Member Names for Manual Tailoring ....................................................... 6-23
EBCDIC to ASCII Translate Modules...................................................................................... 7-17
Unconverted EDBCDIC Hex Values ....................................................................................... 7-18
SOURCE Data Types .............................................................................................................. 7-19
DCE Start Types ...................................................................................................................... 8-5
Syslog Record Types for Filtering.......................................................................................... 11-2
Supported SMF Records ....................................................................................................... 12-4
WHERE Statement Parameters ............................................................................................ 12-8
SMF Filter Configuration Panel Controls ............................................................................ 12-15
Configuration CONFNAME Panel Controls ......................................................................... 12-19
SELECT_JOB_IF_ Keywords .................................................................................................. 13-6
SELECT_DATA_SET_IN_JOB_WITH Keywords....................................................................... 13-7
FILTER_JOB_ON Keywords ................................................................................................... 13-8
JES2 PHASE Keyword Values............................................................................................... 13-10
JES3 PHASE Keyword Values............................................................................................... 13-11
MIB Performance Threshold Alerts ...................................................................................... 14-4
MIB Status Change Alerts ..................................................................................................... 14-4
OSA MONITOR-Generated Alerts ......................................................................................... 14-5
MIB Overall Counter Increase Alerts .................................................................................... 14-5
FTP Control Alerts................................................................................................................. 14-8
EE MONITOR Alerts ............................................................................................................ 14-10
IP MONITOR Alerts ............................................................................................................. 14-13
FILELOAD Batching Example 1 .............................................................................................. 16-4
FILELOAD Batching Example 2 .............................................................................................. 16-5
System State Data Fields ...................................................................................................... 17-2
Required SSDFAPI Parameters for the Single-send API ........................................................ 18-6
Ironstream API Environment ................................................................................................ 18-8
Ironstream API Input Registration........................................................................................ 18-8
Ironstream API Output Registration..................................................................................... 18-8
Ironstream API Parameter List ............................................................................................. 18-9
Required SSDFPAPI Parameters for the Multi-send API ..................................................... 18-13
INIT Request Parameter List ............................................................................................... 18-15
SEND Request Parameter List............................................................................................. 18-16
TERM Request Parameter List ............................................................................................ 18-16
RMF Filters Panel Controls................................................................................................... 23-8
Ironstream Messages ........................................................................................................... 27-2
Data Collection Extension Messages .................................................................................. 27-76
Ironstream Configuration and User’s Guide xvii

xviii Ironstream Configuration and User’s Guide
SECTION I About Ironstream
This section provides introductory and overview information about Ironstream and
how it works.
• “Introduction”
• “Understanding Ironstream”
Chapter 1 Introduction
The Ironstream Configuration and User’s Guide provides instructions for configuring and
running Ironstream® instances. It also describes how to configure the supported data source
parameters to optimize data collection and forwarding efficiency for your environment.
Topics:
• “What’s in this Guide” on page 1-2
• “Audience” on page 1-4
• “Related Resources” on page 1-4
• “Conventions” on page 1-5
Ironstream Configuration and User’s Guide 1–1

Introduction
What’s in this Guide

The Ironstream Configuration and User’s Guide is divided into categorical sections that
contain related chapters.
Table 1-1: Sections and Chapters in this Guide
Title Description
SECTION I: About Ironstream
• Introduction This chapter
• “Understanding Ironstream” Provides a detailed overview of Ironstream and its
components.
SECTION II: Configuring Ironstream Target Destinations
• “Setting Up Splunk for Describes how to set up Splunk indexes and TCP
Ironstream” ports for forwarding data to Splunk.
• “Setting Up Elastic for Describes how to set up Elastic products to ingest
Ironstream” data forwarded by Ironstream.
• “Setting Up Kafka for Describes how to set up Ironstream’s internal Kafka
Ironstream” producer to publish z/OS data to Kafka brokers.
SECTION III: Configuring and Running Ironstream
• “Configuring Ironstream Describes how to configure the Ironstream forwarder
Components” components for newly-installed Ironstream instances
using the Ironstream Configurator.
• “Manually Setting Ironstream Explains how to configure the Ironstream
Parameters” configuration file parameters to define data sources
and destinations. It also includes descriptions of
typical Ironstream parameters and example
configuration files.
• “Controlling Ironstream Instructions for starting and stopping the Ironstream
Components” forwarders and the their components.
• “Configuring Data Loss Describes how to configure Ironstream to minimize
Prevention” loss of forwarded Splunk data due to extended
network or Splunk server outages.
SECTION IV: Setting Up Ironstream Data Sources
• “Syslog Message Filtering” Describes how to configure syslog message filtering.
• “SMF Record Filtering” Describes how to configure field-level filtering for
SMF record types, either by manually creating control
records in the Ironstream configuration file or using
the GUI-based “SMF Filter Configuration Builder” in
the Ironstream Desktop.
1–2 Ironstream Configuration and User’s Guide

Introduction
Title Description
• “SYSOUT Forwarding” describes how to configure the SYSOUT data
forwarder to select and forward data sets.
• “Alerts and SyslogD Describes the optional Network Monitoring
Forwarding” components that enable alert monitoring and SyslogD
forwarding.
• “DB2 Data Forwarding” Describes how to configure DB2 table data for
forwarding.
• “Sequential File Forwarding” Describes how to capture data written and stored in
sequential datasets.
• “System State Forwarding” Describes how to capture z/OS LPAR system
performance metrics for forwarding.
• “Configuring and Using the Describes how to configure the Ironstream API to
Ironstream API” capture application information for analysis and
visualization.
• “Setting Up Log4j” Describes how to configure log4j configuration files to
collect log4j records.
• “IMS Log Record Forwarding” Describes how to configure Ironstream to gather IMS
log records.
SECTION V: Setting Up Data Collection Extension Data Types
• “Configuring the DCE Describes how to configure the Data Collection
Parameters” Extension (DCE), an Ironstream component that
provides extensions for collection of data from a
variety of data types.
• “Setting Up USS File Describes how to configure DCE to offload Unix
Collection” System Services (USS) to Ironstream.
• “Setting Up the RMF Data Describes how to configure the RMF Data Forwarder
Forwarder” to collect Resource Measurement Facility III (RMF
III) system performance and utilization data.
SECTION VI: Troubleshooting Ironstream
“Ironstream Commands” Describes how to use Ironstream system commands.
“Operational Considerations” Describes some operational considerations when
using Ironstream, such as message flood automation,
network contention, and data store conditions.
“Ironstream Messages” Contains the system messages generated by core
Ironstream and DCE.

Introduction
Title Description
“Diagnostics and Contacting Contains basic diagnostic information and contact
Syncsort Product Support” information for Syncsort Product Support.
SECTION VII: Ironstream Audit Reporting
“Using the Ironstream Data Provides information about how to use Ironstream
Usage Reporter” auditing reports.
SECTION VIII: Integration with Splunk Premium Applications
“Splunk Enterprise Security and Describes how Ironstream Technology Add-on can be
Ironstream” configured to work with the Splunk Enterprise
Security application.
SECTION IX: Appendices
“Forwarded Data Formats” Contains the data formats that are forwarded to
Splunk.
“The SSDFCPR Utility” Describes how to use the SSDFCPR utility.
Audience
This document is intended for system administrators who are configuring and running
Ironstream.
Related Resources
For more information about Ironstream functionality and enhancements, refer to the
Syncsort Knowledge Base and the additional Ironstream manuals described below.
Syncsort Knowledge Base

Ironstream is continually enhanced to add more functionality. Enhancements are
documented in Syncsort Knowledge Base articles. The Syncsort Knowledge Base contains
information about enhancements, topics of interest and product defects. The Knowledge
Base is available to licensed users and is accessible through the ‘MySupport’ section of the
Syncsort website. Search on the Ironstream product by release to find all relevant
information about Ironstream.
To improve the search process for Ironstream V2.1 enhancements, all enhancement-related
Knowledge Base articles are indicated with the inclusion of “Enhancement” in the article
title. When querying the Knowledge Base, you can also enter “enhancement” in the Search
for field to list all enhancement-related articles for Ironstream 2.1.

Introduction
Additional Documentation
The following documentation is available for download in the Ironstream section of the
Syncsort MySupport portal:
• Ironstream Features and Functions V2.1 – A detailed compendium of all Ironstream
V2.1 enhancements.
• Ironstream Program Directory V2.1 – For system programmers responsible for program
installation and maintenance. It contains information concerning the materials and
procedures associated with the installation of Ironstream V2.1.
• Ironstream SMF Record Field Reference – An HTML-based reference that describes all
of the SMF record fields that are forwarded to Splunk. This reference is available on the
“Ironstream V2.1 Documents” page on Syncsort’s MySupport page for Ironstream.
• Network Management Component (NMC) Manuals – Full details of all of the
configuration options outlined in “Alerts and SyslogD Forwarding” on page 14-1 are
available in the appropriate Configuration and Reference or Administration manual for
the ZEN component concerned and/or in the ZEN Help system.
Conventions
The following text conventions are used in this document:
Table 1-2: Text Conventions
Convention Meaning
boldface Boldface type indicates graphical user interface
elements associated with an action, or terms
defined in text or the glossary.
italic Italic type indicates book titles, emphasis, or
placeholder variables for which you supply
particular values.
monospace Monospace type indicates commands within a
paragraph, URLs, code in examples, text that
appears on the screen, or text that you enter.

Introduction

Chapter 2 Understanding Ironstream
This chapter provides an overview of Ironstream and its components.
Topics:
• “What Is Ironstream?” on page 2-1
• “Ironstream Components” on page 2-2
• “Supported Data Sources” on page 2-5
• “Ironstream Design Roadmap” on page 2-7
• “Ironstream Starter Edition” on page 2-8
• “Integration with Splunk Premium Applications” on page 2-9
What Is Ironstream?
Ironstream enables you to access real-time, mainframe operational insights through a
number of supported data destination platforms, such as Splunk®, Elastic, and Kafka.
Ironstream captures many different types of data from your z/OS mainframe and generates
JSON formatted data that is forwarded via TCP/IP connections directly into a target
destination repository.
Note: While most examples in this guide are shown using Splunk, there is no restriction on
which supported destination repository can be used, unless specifically noted in that
example.
What Data Does Ironstream Collect from z/OS?

Ironstream can collect, transform and securely forward SMF records, IMS logs, JES
SYSOUT data, syslogs, log4j messages, flat files, and system state performance metrics into
a destination platform. Ironstream can also forward entire USS files and file changes, as
well as RMF Monitor III metrics from the RMF distributed data server (DDS). There is also

Understanding Ironstream
an API for users of COBOL, C, PL/I, REXX, and Assembler applications for forwarding
user-defined data to a target destination.
What Happens to z/OS Data in a Destination?

Once the z/OS data is in a supported destination, it can be easily searched, analyzed, and
visualized to gain valuable operational information. Ironstream thus enables you to have a
real-time, 360-degree view of your IT infrastructure, including your mainframes.
With all your machine data coming into your chosen destination, you can correlate data from
multiple mainframe sources, along with log data from distributed platforms, providing
insights that were not previously possible.
What Happens If Ironstream Is Unable to Deliver Data to a

Destination?
There may be operational situations when Ironstream cannot deliver data to a destination.
There are two options:
• For critical data sources being forwarded to Splunk, the Data Loss Prevention (DLP)
feature stores the data in a coupling facility log stream. When the connection is
restored, Ironstream automatically forwards the data to Splunk.
• For non-critical data sources that do not require DLP, there is on offline forwarder batch
utility.
When using DLP, you must make also minor configuration changes to your Splunk server.
For more information about DLP, see Chapter 10, “Configuring Data Loss Prevention”.
Note: Ironstream DLP uses the Splunk Indexer Acknowledgment function and therefore
cannot be configured to work with Elastic destinations.
Fast and Efficient Performance

Ironstream is fast and efficient while having very limited impact on z/OS system resources.
Processing is offloaded to zIIP engines as appropriate to reduce CPU time consumption.
Ironstream Components
Ironstream Forwarders
Ironstream delivers data to configured destination using what is referred to as a forwarder
and each forwarder is configured for a specific data source. For some data sources, the
forwarder is also a data gatherer and it filters and formats data before it is forwarded to
destinations. To illustrate this, consider SMF and syslog data sources:
• SMF data is filtered by record type, in some cases by subtype. Many of the fields across
all SMF records contain numeric data, often in binary format. Ironstream performs
significant formatting that is required to forward these fields in a way that makes them
useful and usable in destinations.

• Syslog data is filtered by product/subsystem or message prefix, but the data is entirely
EBCDIC, so Ironstream converts it to ASCII and delivers it to destinations.
Whereas, other data sources, such as the USS file monitor, use a combination of the Data
Collection Extension (DCE) and the Ironstream Desktop (IDT) for filtering and gathering,
but still rely on a forwarder to deliver the data to destinations. Ultimately, an Ironstream
forwarder delivers a specific data source to destinations, but different data sources require
different processing to prepare the data being sent to destinations.
For more information about how Ironstream forwarders interact with other Ironstream
components, see “DCE, IDT, and XCF Configuration Considerations” on page 6-8.
Data Collection Extension (DCE)

The DCE component provides extensions for collection of data from a variety of sources. DCE
currently provides support for:
• Monitoring UNIX System Services (USS) directories and files, which can be offloaded to
Ironstream to a specified destination, like a Splunk index.
• Collecting Resource Measurement Facility (RMF) III system performance and
utilization data in real time to help prevent potential bottlenecks and performance
delays.
Other DCE data types may be added in the future. For more information, see Chapter 21,
“Configuring the DCE Parameters”.
The Ironstream Desktop (IDT)

The IDT component provides GUI-based administration capabilities for some of Ironstream’s
key features. IDT administration includes defining the criteria required to control data
collected by Ironstream and forwarded to destinations, such as:
• For USS file processing, IDT can dynamically make changes to the USS defaults, filters,
and directories, as well as monitor the status of USS file offloads in real-time. See
Chapter 22, “Setting Up USS File Collection”.
• For RMF III metric collection, IDT can be used to configure and monitor the RMF Data
Forwarder, and to control the filtering of RMF fields. For more information, see Chapter
23, “Setting Up the RMF Data Forwarder”.
• For SMF record filtering, IDT provides an “SMF Filter Configuration Builder” that
presents all supported SFM types in an easy-to-navigate expandable/collapsible tree
format for creating a variety of SMF filtering configurations that can filter specific
combinations of selected record types, subtypes, and fields. For more information, see
Chapter 12, “SMF Record Filtering”.
Network Monitoring Components Alerts

Optionally, you can install the set of network monitoring tools collectively known as
“Network Monitoring Components” or NMC. These enable you to generate network-related
alerts and capture SyslogD messages that Ironstream can forward to destinations.

SyslogD support can collect SyslogD messages from the z/OS Syslog Daemon, remote z/OS
Syslog Daemons, or any other network device. Messages can be filtered based on Origin,
Facility, and/or Priority.
Table 2-1 describes how each component can generate alerts for a variety of events that can
occur in the z/OS system. For more information, see Chapter 14, “Alerts and SyslogD
Forwarding”.
Table 2-1: Network Monitoring Components
Component Description
ZEN ZEN is the core of the Network Monitoring component set and
provides many common functions for all other ZEN
components: a browser-based online interface; software
routing; a centralized alerting function (including
user-defined alerts); enhanced system log; SyslogD support;
IP tools; CSM, ECSA and USS panels; common reporting;
REXX support with ZEN Function Pack; user-definable
menus and panel support; timer, message and alert-driven
automation.
ZEN IP MONITOR Real-time IP stack monitor providing full insight into all IP
network data via both 3270 VTAM and ZEN-based panels.
Many IP monitors are provided such as: IP stack (services,
interfaces, activity, connections, gateways), TN3270 response
time, OSPF, EE, X.25, MIBs, OMVS thresholds. Many alerts
available in several categories such as Availability,
Performance, Capacity and Message. Several utilities
available for network analysis and monitoring. Handles single
or multiple stacks on single or multiple LPARs and across as
many CPUs and Sysplex configurations as required.
ZEN EE MONITOR Sophisticated monitor for EE and APPN/HPR data providing:
insight into EE activity and performance; dynamic alerting
and incident reporting; online and offline historical data
recording; comprehensive diagnostic toolset; Netview/REXX
interface for automated network monitoring via ZEN; optional
collection and display of SNA session awareness data.
ZEN OSA MONITOR Provides a convenient single point from which you can
monitor all OSAs accessible to the LPAR on which ZEN is
running. Provides both event and threshold monitoring and
panels for OSA information, channels and ports, interfaces,
LPARs, VTAM and interface information. Particularly useful
is the Health Check function which provides a way of
dynamically checking whether there are any problems or
potential problems with your OSAs.

Table 2-1: Network Monitoring Components (continued)
Component Description
ZEN LINUX MONITOR Enables you to monitor all of your Linux systems using a set
of clear panels. Also enables you to set thresholds for key
Linux resources such as the System and User CPU, memory
and swap utilization, TCP connections and retransmissions
and number of active processes, which are monitored and an
alert raised should the usage exceed the threshold set.
ZEN FTP CONTROL Monitors activity in all z/OS FTP servers and clients. History
file available for browsing online that records all FTP activity.
Provides many monitoring panels both as 3270 VTAM and
ZEN-based panels. Every FTP action such as RACF logon
failures, invalid userid/password, unrecognized command,
complete or incomplete transfers both inbound and outbound,
cause an alert message to be issued.
Supported Data Sources

The sources of mainframe data that can be captured and forwarded by Ironstream are
provided in Table 2-2:
Table 2-2: Ironstream Mainframe Data Sources
Source Description
API User applications can create and send user data and forward it to
a destination. Ironstream supports two user API functions:
• Single-send for use where a persistent environment is not avail-
able, such as in a CICS transaction.
• Multi-send for use where the environment is consistent from
call-to-call, such as in a batch job.
See “Configuring and Using the Ironstream API,” on page 18-1.
DB2 Data inserted into DB2 tables. See “DB2 Data Forwarding,” on
page 15-1.
FILELOAD Any file containing records that have displayable EBCDIC data.
See “Sequential File Forwarding,” on page 16-1.
IMS Many IMS log records can be captured by Ironstream. For a list of
all supported IMS record types, see “IMS Log Record Forwarding,”
on page 20-1.
Log4j Application user log data. See “Setting Up Log4j,” on page 19-1.
Network Alerts Alerts generated by the ZEN suite of Network Monitoring
components. See “Alerts and SyslogD Forwarding,” on page 14-1.

Table 2-2: Ironstream Mainframe Data Sources (continued)
Source Description
RMF DCE data type that collects user-selected RMF III system
performance and utilization data. See “Setting Up the RMF Data
Forwarder,” on page 23-1.
SMF Many SMF record types can be captured by Ironstream. For a list
of all supported SMF record types, see “SMF Record Filtering,” on
page 12-1.
Syslog All messages can be captured, or selected messages from ACF2,
CICS, DB2, IMS, RACF, Top Secret, USS, WebSphere Application
Server and WebSphere MQ and z/OS IEF messages. You may also
specify three and four-character message prefixes to capture. See
“Syslog Message Filtering,” on page 11-1.
SyslogD Any messages written to SyslogD and captured by the ZEN
Network Monitoring core component. See “Alerts and SyslogD
Forwarding,” on page 14-1.
SYSOUT Spool data sets for both active and completed jobs as well as input
data sets and JES system data sets: JESJCLIN, JESMSGLG,
JESJCL and JESYSMSG. See “SYSOUT Forwarding,” on
page 13-1/
SYSTEMSTATE Generates z/OS system-level metrics data to forward to a
destination. See “System State Forwarding,” on page 17-1.
USS DCE data type that monitors USS directories and files at specified
intervals for offloading to Ironstream according to user-defined
filters. See “Setting Up USS File Collection,” on page 22-1.
For descriptions of all the fields in the supported SMF record types, refer to the
HTML-based Ironstream SMF Record Field Reference available on the “Ironstream V2.1
Documents” page on Syncsort’s MySupport page for Ironstream.
For syslog and FILELOAD data, refer to “Forwarded Data Formats” on page A-1, where a
list of the fields and an example of the fields’ formatting in a chosen destination is provided.
Ironstream forwards one type of data in each Ironstream instance. As an example, this
means that to collect syslog, SMF and log4j data requires three address spaces to be started.
Each instance of Ironstream requires a separate configuration file member that includes a
NAME parameter in the SYSTEM section. This parameter defines the unique ‘instance
name’ of that specific instance of Ironstream running in the LPAR.

Ironstream Design Roadmap

This section provides some design decision points to consider when initially installing
Ironstream in your z/OS environment.
Which destination is your data being forwarded data to?

• Splunk – Requires authorized Splunk resource to open one or more ports to Splunk
server(s), define TCP data inputs (SSL or non-SSL), and set up Splunk indexes to store
data.
• Elastic – Requires authorized Elastic resource to open one or more ports to Logstash
server(s), define TCP input plug-ins (SSL or non-SSL), and set up Elastic search indexes
to store data.
• Kakfa – The Ironstream Kafka modules and the Java libraries must be APF-authorized.
What type of z/OS environment?

• IBM Cross System Coupling Facility (XCF). Required for these forwarders:
▪ DCE USS
▪ DCE RMF
▪ IRONSTREAM API
▪ ZEN Network Monitoring Component (NMC)
• IBM coupling facility log stream. Required for these functions:
▪ Data Loss Prevention (DLP)
▪ SMF Real-time InMemory (INMEM)
• IBM System Authorization Facility (SAF). Optional for DLP
• VTAM application major node. Required for:
▪ Ironstream Desktop (IDT)
▪ ZEN Network Management Component (NMC)
• RMF Distributed Data Server (DDS) for DCE RMF
What type of security?

▪ System (default)
▪ RACF
▪ AFC2
▪ Top Secret
What data types are going to be forwarded?

• SMF data capture method:
▪ SMF System Exits – Must be defined in all SYS and SUBSYS EXIT parameter lists
in the SMFPRMnn member of SYS1.PARMLIB or one of its related data sets
▪ Real-time SMF INMEM interface – Requires IBM coupling facility log stream

• Data Collection Extension for USS monitoring and RMF III metric collection:
▪ Requires IBM Cross System Coupling Facility (XCF)
▪ Requires IDT for dynamic monitoring and configuration changes
▪ DCE USS requires file permissions in HFS
▪ DCE RMF requires RACF user ID to access the RMNF Distributed Data Server
(DDS)
• Syslog – No access restrictions to OPERPARM segment of a RACF user ID:
▪ If the z/OS uses the Message Processing Facility, or any similar product, all messages
to be forwarded by SDFLOG are set to AUTO(YES) in the MPF configuration.
• SYSOUT – Requires READ access to any JESSPOOL data set to be forwarded
• ZEN NMC –Requires VTAM application major node
Does your environment require minimal data loss?

• Data Loss Prevention:
▪ Splunk only via the “Splunk Indexer Acknowledgment” function
▪ HTTP or HTTPS
▪ Does not support DCE USS
Should I manually configure Ironstream or use the Configurator Tool?

Syncsort strongly recommends initially using the ISPF-based Ironstream Configurator tool,
which generates the started task JCL and configuration files for the following data sources:
• SMF
• Syslog
• SYSOUT
• DCE (RMF and USS)
• Network Monitoring Component (NMC)
• The log4j appender
• IDT
These resulting configuration files provide a good starting point from which additional
customizations can be added.
Ironstream Starter Edition

The Ironstream Starter Edition is a free version of Ironstream, with limited product support,
for forwarding z/OS syslog data and SMF 205 type records to Splunk. Syslog data and SMF
record type 205 are the only supported data sources in this version and technical support is
only provided for installation and configuration via email to zos_tech@syncsort.com.
If you want to forward other sources of data besides z/OS syslog or SMF record type 205, or
require technical support, you will need to license the fully functional and supported version
of Ironstream. Email us at info@syncsort.com for additional information.

Integration with Splunk Premium Applications

Splunk offers a premium application called “Enterprise Security” (ES), a large, multi-faceted
application that provides comprehensive security surveillance of an organization’s
computing infrastructure. To leverage the Splunk ES application in Ironstream, Syncsort
has created an “Ironstream® Technical Add-on for Splunk Enterprise Security” (or
Ironstream TA-ES), which collects, formats, and manages the data from several z/OS
mainframe sources powered by Ironstream. For more information, see Chapter 24, “Splunk
Enterprise Security and Ironstream”.
Other Ironstream TAs may be added in the future for Splunk premium applications.


SECTION II Configuring Ironstream Target
Destinations
This section provides instructions for configuring Ironstream target destinations.

• “Setting Up Splunk for Ironstream”
• “Setting Up Elastic for Ironstream”
Chapter 3 Setting Up Splunk for
Ironstream
This chapter describes how a Splunk administrator needs to set up one or more indexes for
forwarding records to Splunk, as wells as a custom TCP port for the mainframe data.
Topics:
• “Overview of Setting Up Splunk” on page 3-1
• “Setting Up a Non-SSL Port” on page 3-2
• “Setting Up an SSL Port” on page 3-2
• “Setting Up a Splunk Index” on page 3-3
• “Next Steps” on page 3-3
Overview of Setting Up Splunk

As a Splunk administrator, you will need to either define an index or identify an existing
index for forwarding records to Splunk. Additionally, you will need to define a custom port
for the mainframe data.
For example, if you attempt to send Ironstream data to Splunk using an existing default
Splunk port, it uses a proprietary protocol, SPLUNKTCP, in order to communicate.
Ironstream will send data to the default port and Splunk will accept it. However, when
Splunk then attempts to communicate with the Ironstream port (part of the Splunk TCP
protocol), there will be no response and Splunk will terminate the TCP connection.
Therefore, it is necessary to define a TCP port specifically for Ironstream to transmit its data
to Splunk.
For reliability and performance reasons, we recommend defining and using multiple ports
on one or more Splunk Indexers. Refer to the Splunk documentation for more information.
The following sections provide some samples for setting up a port and an index.

Setting Up Splunk for Ironstream
Setting Up a Non-SSL Port

Follow these steps to set up Splunk ports.
1. In the Splunk web launcher page, in the Data box, click Add Data.
2. In the Add Data to Splunk box, under Or choose a Data Source, click From a TCP
port link.
3. Enter the port number in the TCP port box.
4. Set Manual and json for sourcetype options.
5. Click Save.
6. Repeat as needed.
Setting Up an SSL Port

Setting up an SSL port requires action on both the Splunk and mainframe platforms.
Splunk Platform
Following is a sample procedure to set up a Splunk SSL port. In this example, cacert.pem is
used for the default Splunk SSL CA certificate, 9998 is used for the SSL port number, and
server.pem is used for the Splunk server’s certificate.
1. Edit $SPLUNK_HOME/etc/system/local/inputs.conf:
[tcp://9998]
connection_host = dns
sourcetype = json
[tcp-ssl:9998]
compressed = false
[SSL]
password = password
rootCA = $SPLUNK_HOME/etc/auth/cacert.pem
serverCert = $SPLUNK_HOME/etc/auth/server.pem
2. Restart Splunk services: $SPLUNK_HOME/bin/splunk restart.

3. Send a copy of cacert.pem to the client on the mainframe.
Mainframe Platform
Follow these steps to configure mainframe security when using a Splunk SSL port.
1. Set up a keyring database in the OMVS keyring database, using a RACF key data set or
with a key token.
2. Import the Splunk CA certificate (cacert.pem) sent from the Splunk platform to one or
all key databases.
3. Assign a label to this certificate in the key data set.

Setting Up a Splunk Index

Follow these steps to set up a Splunk index.
1. In the Splunk web launcher page, in the upper right corner, click Settings.
2. Click Indexes under Data.
3. Click New.
4. Enter the index name.
5. Click Save.
Next Steps
These chapters have information on configuring Ironstream for Splunk destinations:
• Chapter 6, “Configuring Ironstream Components” – Describes how to configure the
Ironstream forwarder components for newly installed Ironstream instances using the
Ironstream Configurator utility.
• Chapter 7, “Manually Setting Ironstream Parameters” – How to configure the
Ironstream configuration file parameters to define data sources and target destinations.
• Chapter 10, “Configuring Data Loss Prevention” – How to configure Ironstream to
minimize any loss of forwarded Splunk data due to extended network or Splunk
outages.


Chapter 4 Setting Up Elastic for
Ironstream
This chapter describes how an Elastic administrator needs set up the Logstash,
Elasticsearch, and Kibana products to ingest data forwarded by Ironstream.
Topics:
• “Overview of Elastic Support in Ironstream” on page 4-1
• “Forwarding Data to Logstash” on page 4-2
• “Receiving Ironstream Data in Elasticsearch” on page 4-4
• “Displaying Ironstream Data in Kibana” on page 4-4
• “Field Mappings and Elastic Defaults” on page 4-4
Overview of Elastic Support in Ironstream

Data from Ironstream is sent to Elastic in single-line JSON format and is readily consumed.
Standard processing across Logstash, Elasticsearch, and Kibana is applied after some
typical configuration has been carried out be an Elastic administrator. It is assumed that
you are familiar with the general mechanics and configuration of Elastic.
The following sections cover the requirements for Logstash, Elasticsearch, and Kibana.
Elastic Limitations with Ironstream

In the current release, some Ironstream features are not compatible with the Elastic.
• Data Loss Prevention (DLP) – The DLP feature uses the Splunk Indexer
Acknowledgment function and therefore cannot be configured to work with the Elastic.
• DCE RMF – Due to the large volume of fields that can be generated for RMF, Syncsort
highly recommends using the RMF field filtering capabilities provided in the Ironstream
Desktop. For more information, see Chapter 23, “Setting Up the RMF Data Forwarder”.

Setting Up Elastic for Ironstream
• DCE USS – Data can be delivered to Elastic, but due to current limitations the source
(file name) will not be supplied. For more information, see Chapter 22, “Setting Up USS
File Collection”.
Forwarding Data to Logstash

To get data flowing into your Elastic environment an open port will need to be available on
your Logstash server.
Sending Data to Logstash

Ironstream can send data using either TCP or HTTP(S). For all connection methods, the
DESTINATION section of the Ironstream configuration file must be configured as follows:
[DESTINATION]
"TARGET":"ELASTIC" [TARGET for Elastic MUST be specified]
"TYPE":"TCP|HTTP|HTTPS"
"IPADDRESS":"123.456.78.90"
"PORT":"1000"
For more information, refer to the “DESTINATION Section” in Chapter 7, “Manually

Setting Ironstream Parameters”.
Logstash Configuration
Logstash is an open source data collection engine with real-time pipe-lining capabilities.
Data arriving from Ironstream is processed in the usual way by Logstash.
Here is an example Logstash configuration file (logstash.yml) that shows the “input”,
“filter”, and “output” sections, where different types of data are received (input) over
different ports, processed (filter), and sent (output) to different indexes:
input {
# Port 4300 receives SMF data
tcp {
port => 4300
type => "smf"
codec => "json"
}
# Port 4310 receives SYSLOG data
tcp {
port => 4310
type => "syslog"
codec => "json"
}
# Port 4315 receives SYSTEMSTATE data
tcp {
port => 4315
type => "systemstate"
codec => "json"
}
}

filter {
#
# Use grok, mutate, ruby etc. to manipulate data to requirements.
#
}
# Send the result to Elasticsearch

output {
if [type] == "smf" and [MFSOURCETYPE] == "SMF110" {
elasticsearch {
hosts => "<elastic-server>:<port-number>"
user => "<username>"
password => "<password>"
index => "ironstream-example-smf110"
}
}
else if [type] == "smf" and [MFSOURCETYPE] == "SMF080" {
elasticsearch {
index => "ironstream-example-smf80"
}
}
else if [type] == "syslog" {
elasticsearch {
index => "ironstream-example-syslog"
}
}
else if [type] == "systemstate" {
elasticsearch {
index => "ironstream-example-systemstate"
}
}
}
Notes
• In the “input” section of the above Logstash configuration, each “tcp” section has:
codec => "json"
Which could equally be:
codec => "line"
Or:
codec => "json_lines"
Even though Ironstream sends JSON formatted data, it arrives as a single-line of
data for each event/record. Therefore, all three codecs can be used.
• To send data via HTTP (non-SSL) or secure TCP, refer to the Elastic documentation.
Standard Elastic configuration and processing is supported.

Receiving Ironstream Data in Elasticsearch

Elasticsearch requires at least one index to receive data from Ironstream. Use standard
Elastic processing and commands to create the index according to your requirements.
Displaying Ironstream Data in Kibana

Once the data from Ironstream is available in Elasticsearch, it can be displayed on Kibana
visualizations and dashboards. Again, this only requires standard processing. See “Field
Mappings and Elastic Defaults” below for more information.
Field Mappings and Elastic Defaults

Elastic has a default setting for a maximum of 1000 mapped fields per index. Some
mainframe data sources can produce documents (JSON structures) that exceed this limit.
To mitigate this situation, there are two options:
1. Increase the number of mapped fields for a given index by setting the following value:
index.mapping.total_fields.limit
Refer to the Elastic documentation for details on how to update this setting.
2. Use Ironstream filtering to decrease the number of fields sent to Elastic, and keep under
the default limit. Refer to chapters in the Ironstream documentation that describe
message or record filtering.
Next Steps
These chapters have information on configuring Ironstream for Elastic destinations:
• Chapter 7, “Manually Setting Ironstream Parameters” – Describes how to manually
configure the Ironstream configuration file parameters to define data sources and target
destinations.

Chapter 5 Setting Up Kafka for Ironstream
This chapter describes how to configure Ironstream’s internal Kafka producer to publish
z/OS data to Kafka brokers via Ironstream.
Topics:
• “Overview of Apache Kafka Support in Ironstream” on page 5-2
• “Downloading and Installing Kafka to z/OS OMVS Systems” on page 5-3
• “Applying the Kafka Function to Ironstream” on page 5-4
• “Providing APF Authorization for Ironstream Programs” on page 5-5
• “Configuring Ironstream to Use the Kafka Producer” on page 5-6
• “Confirming Kafka Activity Status in Ironstream” on page 5-8

Setting Up Kafka for Ironstream
Overview of Apache Kafka Support in Ironstream

Many organizations are challenged with accessing mainframe data for processing by data
analytics platforms. Ironstream can capture mainframe data and publish it to Apache Kafka
clusters. Through Kafka, mainframe data can be accessed by Hadoop, Spark, and other open
systems. If you are new to Kafka, refer to the Apache Kafka documentation for more
information: https://kafka.apache.org/documentation/
How Does Kafka Work with Ironstream?

Kafka is a distributed, partitioned, replicated commit log service that functions like a
high-capacity publish-subscribe messaging system. Ironstream has implemented an internal
Kafka producer that publishes data from z/OS to Kafka brokers via Ironstream topics, which
are configured as a target DESTINATION in the configuration file. Ironstream customers
can write their own Kafka consumer code to capture the data from Kafka brokers and make
it accessible for data analytics platforms.
Kafka Requirements and Limitations with Ironstream

In the current Ironstream release, running Kafka requires:
• Receive and Apply the Kafka Function and prerequisite PTF.
• Kafka version 0.9.0.1 or higher.
• Java 8.0 or higher, either 31-bit or 64-bit.
In the current release, some Ironstream features are not compatible with Kafka.
• Data Loss Prevention only works with the Splunk Indexer Acknowledgment function.
• Using the offline log4j reader.
• Forwarding IMS log records.
• Batching sequential FILELOAD data using these BATCH parameters:
“BATCH_AND_BREAK_ON_CONDITION" and "BATCH_RECORDS":"YES"
Instructions for Downloading and Configuring Kafka on Ironstream

The steps to configure Kafka on Ironstream must be followed in this order:
1. “Downloading and Installing Kafka to z/OS OMVS Systems”
2. “Applying the Kafka Function to Ironstream”
3. “Providing APF Authorization for Ironstream Programs”
4. “Configuring Ironstream to Use the Kafka Producer”
5. “Configuring Ironstream to Use Other Kafka Producer Configurations”

Downloading and Installing Kafka to z/OS OMVS Systems

Follow these steps to download Kafka to your mainframe OMVS system:
1. Download the appropriate Kafka binary from http://kafka.apache.org/downloads.html to
a directory on your PC or Unix/Linux system.
2. From your PC or Unix/Linux system, unzip the downloaded kafka_version.tgz file to
extract the kafka_version.tar file.
3. On your OMVS system, create a new directory for use by Kafka. For example, you can
create a directory named /usr/lpp/kafka.
4. FTP the kafka_version.tar file to the OMVS Kafka directory using binary mode.
5. From the OMVS Kafka directory, type tar -xvf kafka_version.tar to extract the file
to the current directory.
This creates a kafka_version directory under your OMVS Kafka directory.
For example: /usr/lpp/kafka/kafka_2.11-0.10.0.0
6. Under the new kafka_version directory, note that there is also a /libs directory. It
contains all the JAR files that Apache Kafka provides, and Ironstream will use the
producer APIs in these JARs to access data for Kafka brokers.
For example: "KAFKHOME":"/usr/lpp/kafka/kafka_2.11-0.10.0.0/libs"
Important! The Kafka /libs directory will be used by Ironstream as the KAFKHOME
in the Ironstream configuration file.
Converting Binary Kafka Files from ASCII to EBCDIC (Optional)

Since you must FTP the Kafka package in binary mode, all files under the /bin or /config
directories are still in ASCII encoding; therefore, you cannot run any Kafka shell commands
on OMVS. Ironstream calls the Kafka producer APIs directly from the /libs directory, so
starting a Kafka Server on OMVS or issuing any Kafka shell commands is not required for
Ironstream.
If your Kafka server is not running on OMVS, you can skip this step. If you want to run
Kafka as a server on OMVS and use Kafka support shell commands, then you must first
convert all files under /bin or /config from ASCII to EBCDIC.
To perform the ASCII to EBCDIC conversion, use this command:
iconv -f ISO8859-1 -t IBM-1047 file1 > file2

Applying the Kafka Function to Ironstream

The IronstreamV21.Kafka.zip file provided by Syncsort contains the Kafka LSDK210
function. LSDK210 contains a binary image of a TSO XMIT’d data set in flat 80*3120 FB
format.
To get this data set onto your system and apply LSDK210 to Ironstream:
1. Create a ZFS subdirectory in the directory defined by DDDEF SSDFHFS. For example:
<SSDFHFS>/kafka, where <SSDFHFS> is /user/ironstream_home_directory/
2. BINary FTP the LSDK210.FNCT.bin XMIT file to your system as an FB 80*3120 file.
3. Use the TSO RECEIVE command to receive it into <your.hlq>.SDFPTF.PTFLIB library.
4. SMP/E RECEIVE FUNCTION LSDK210. If RC0, APPLY with the CHECK option. If
the APPLY CHECK is successful and yields an RC0, then APPLY without the CHECK
option and ensure an RC0.
Sample JCL:
//RECEIVE EXEC PGM=GIMSMP,REGION=0M,PARM='CSI=<your.hlq>.SMP.CSI'
//SMPPTFIN DD DISP=SHR,DSN=<your.hlq>.SDFPTF
//SMPCNTL DD *
SET BDY(GLOBAL).
RECEIVE SYSMODS LIST.
//APPLY EXEC PGM=GIMSMP,REGION=0M,PARM='CSI=<your.hlq>.SMP.CSI'

//SMPCNTL DD *
SET BDY(TgtZone).
APPLY CHECK
C(ALL) GROUP SELECT(LSDK210) BYPASS(HOLDSYSTEM).
If the above APPLY CHECK was successful, resubmit with the following change:
APPLY
C(ALL) GROUP SELECT(LSDK210) BYPASS(HOLDSYSTEM).
If you encounter any problems, contact Syncsort Product Support.

Providing APF Authorization for Ironstream Programs

Ironstream must run in APF-authorized mode; therefore, all programs that Ironstream
invokes must also be APF-authorized, including the Ironstream Kafka modules and the Java
libraries.
First, ensure that the SYS1.SIEALNKE data set is in the link list. The system automatically
places this data set at the beginning of the link list, unless it is overridden by a SYSLIB
statement in PROGxx. The default IEASYSxx value LNKAUTH=LNKLST must be in effect, or
SYS1.SIEALNKE must be APF-authorized.
After applying FUNCTION LSDK210 on your OMVS system (as described in “Applying the
Kafka Function to Ironstream” on page 5-4), verify that there is sufficient authorization for
the modules libSDFKaf64JNI.so and libSDFKafkaJNI.so under the Ironstream Kafka
library, as well as for the Java libraries.
Authorizing the Ironstream Kafka Modules

The Ironstream Kafka libraries are in the /ironstream_home_directory/kafka directory.
You can check the authorization by entering the following command at a Unix shell prompt:
extattr /usr/lpp/ironstream/kafka/*
The following modules must be APF-authorized:

• libSDFKaf64JNI.so
• libSDFKafkaJNI.so
You can define APF authorization by entering these commands:
extattr +a libSDFKaf64JNI.so
extattr +a libSDFKafkaJNI.so
Authorizing the Java Libraries

The Java library is in the /usr/lpp/java/ directory and contains different Java versions.
Note: Java 8.0 or higher is required when running Kafka with Ironstream.
You must ensure that the Java library you are running for Ironstream is APF-authorized.
You can APF-authorize all modules under the Java library by entering this command:
find /usr/lpp/java/J7.1/ -name "*.so" | xargs extattr +a
The Unix “find” command searches all the subdirectories for the *.so file names and pipes
the results into xargs, which converts them into the appropriate input format for extattr.

Configuring Ironstream to Use the Kafka Producer

For Kafka configuration, only the DESTINATION section of the Ironstream configuration
file is different from the standard TCP/IP parameters for Splunk or Elastic as an Ironstream
target destination. For detailed explanations for all Ironstream configuration file
parameters, refer to Chapter 7, “Manually Setting Ironstream Parameters”.
Setting the Ironstream DESTINATION

The [DESTINATION] section describes where the data is to be sent and how it is to be
forwarded. Multiple Kafka broker addresses and ports can be specified by repeating the
IPADDRESS/PORT for each topic.
[DESTINATION] - The required section heading.
"TARGET": "target_name" - This required parameter defines Kafka as the data target for
this Ironstream instance. The valid values are ELASTIC, KAFKA, or SPLUNK.
If a target is not specified, the default value for TARGET is SPLUNK.
"TOPIC":"topic_name" - This required parameter defines the name of the Kafka topic for
this Ironstream instance.
"JAVAHOME":"Java_home address" - This required parameter specifies which JRE (Java

Runtime Environment) to use for execution and must correspond with the
JAVA64BIT parameter. This is an OMVS directory path pointing to a 31-bit or 64-bit
version of Java. For example: "/usr/lpp/java/J7.0"
Note: JRE 7.0 or higher is required when running Kafka with Ironstream.
"JAVA64BIT":"YES" | "NO" - This required parameter specifies whether to use the 64-bit
or 31-bit version of the JVM. This value is based on which directory the JAVAHOME
parameter points to.
• YES - 64-bit version of Java is used
• NO - 31-bit version of java is used
"SSDFHOME":"ssdf address in OMVS" - This required parameter specifies the address

where the Ironstream Kafka producer class is available.
Example: /usr/lpp/ironstream/kafka
"KAFKHOME":"KAFKA API library in OMVS" - This required parameter specifies the

address of the Kafka API library in OMVS.
For example: /usr/lpp/kafka/kafka_2.11-0.9.0.1/libs
"IPADDRESS":"ipaddress" - This required parameter specifies the IP address (up to 36

characters) of a Kafka broker.
"PORT": "port" - This required parameter specifies the port number on which the Kafka
broker is listening.

Note: Any number of IPADDRESS and PORT combinations can be specified. This would be
considered as the broker list for the Kafka cluster, and it is solely used by the Kafka
producer for load balancing.
Example Ironstream JCL for Sending Data to Kafka Brokers

//KAFKA EXEC PGM=SSDFMAIN
//STEPLIB DD DISP=SHR,DSN=&HLQ.. SSDFAUTH
//SYSPRINT DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//CEEOPTS DD DISP=SHR,DSN=&HLQ..SSDFSAMP(CEEOPTS)
//SSDFCONF DD *
[KEYS]
"KEY_WARN_DAYS":"30"
"KEY":"NNNNNNNNNNNNNNNN"
[SYSTEM]
"NAME":"SDF"
[DESTINATION]
"TARGET":"KAFKA"
"TOPIC":"syslog1"
"JAVAHOME":"/usr/lpp/java/J7.1"
"JAVA64BIT":"NO"
"SSDFHOME":"/usr/lpp/ironstream/kafka"
"KAFKHOME":"/usr/lpp/kafka/kafka_2.11-0.10.0.0/libs"
"IPADDRESS":"192.168.61.3"
"PORT":"9092"
[SOURCE]
"DATATYPE":"SYSLOG"
"FILTER":"SSDFFLOG"
Configuring Ironstream to Use Other Kafka Producer Configurations

Ironstream’s internal Kafka producer needs Topic, IPADDRESS, and PORT information for
publishing data to Kafka brokers. The internal producer uses Kafka’s default producer
settings. However, if you want to use other producer configurations, Ironstream also
supports all Kafka producer key-value pairs in the producer properties file format. The
producer.properties configuration file under SSDFHOME is parsed and the values inside
are honored by Ironstream.
Ironstream provides a template file named producer.properties.template under
SSDFHOME that you can modify and save your preferred configuration to
producer.properties.

Confirming Kafka Activity Status in Ironstream

For a typical Ironstream job, the STATUS command instructs Ironstream to print interim
statistics to the SYSPRINT file (via messages SDF0400I through SDF0408I). When Kafka is
being used as the target destination, however, the transmission status is sent to STDOUT
instead of to SYSPRINT.
To run the STATUS command from a system console (an SDSF console requires using a
backlash):
F jobname,STATUS
Figure 5-1. Example Kafka Statistics Output in STDOUT
--------------------------------------------------------
* KAFKA STATISTICS *
--------------------------------------------------------
Status Blocks sent Bytes transmitted
ACTIVE 69 1668159
--------------------------------------------------------
Note that the Status is ACTIVE. When a KAFKA broker becomes unavailable to send data,
the status will change to INACTIVE.
For more information about the Ironstream commands, refer to Chapter 25, “Ironstream
Commands”.

Messages Issued by Kafka

Ironstream’s Kafka-related messages occur mainly in the SDF0906I–SDF0915A range. They
are fully described in “Ironstream Messages,” on page 27-1.

Next Steps
These chapters have information on configuring Ironstream for Kafka destinations:
• Chapter 7, “Manually Setting Ironstream Parameters” – Describes how to manually
configure the Ironstream configuration file parameters to define data sources and target
destinations.

SECTION III Configuring and Running
Ironstream
This section provides instructions for configuring and running Ironstream forwarders
and components.
• “Configuring Ironstream Components”
• “Manually Setting Ironstream Parameters”
• “Controlling Ironstream Components”
• “Dynamically Modifying a Running Ironstream Configuration”
• “Configuring Data Loss Prevention”
Chapter 6 Configuring Ironstream
Components
This chapter describes how to configure the Ironstream forwarder components for newly
installed Ironstream instances, either manually or using the Ironstream Configurator. The
ensuing chapters in this manual describe how to configure the data source parameters to
optimize data collection and forwarding efficiency for your environment.
Topics:
• “Overview” on page 6-2
• “Manually Configuring Ironstream” on page 6-4
• “About the Ironstream Configurator Utility” on page 6-7
• “Running the Ironstream Configurator Utility” on page 6-11
• “Post Configurator: Additional Actions” on page 6-23
Note: The configuration instructions in this chapter assume that the Ironstream V2.1
SMP/E installation steps have been successfully completed. For installation instructions, see
the Ironstream Program Directory for version 2.1. This guide is for system programmers
responsible for program installation and maintenance.

Configuring Ironstream Components
Overview
Ironstream delivers data to destinations using what is referred to as a forwarder and each
forwarder is configured for a specific data source. Data source parameters are defined in the
Ironstream configuration file, along with other configurable parameters such as license
keys, local system symbols, and various system-related values. Every data source requires a
forwarder with an appropriate configuration file. Some data sources have additional
components requiring additional configuration files.
The configuration file is fully described in “Manually Setting Ironstream Parameters,” on
page 7-1.
Manually Configuring Data Sources vs. Using the Configurator Utility

The Ironstream Configurator Utility is optional when configuring the basic forwarding of
data sources. However, Syncsort strongly recommends using the Configurator Utility to
configure IDT, DCE (for USS file offloading and RMF III monitoring), and NMC alerts.
Consider the following scenarios when deciding whether to manually configure data sources
or use the Configurator Utility:
• Manually configuring data sources – Some data sources, like syslog and SMF, use a
single forwarder task to gather, format, and forward data to a destination. For these
data sources, simple JCL and a configuration file are all that is required to start
forwarding data to a destination.
For more information, see “Manually Configuring Ironstream” on page 6-4.
• Programmatically configuring data sources – Other data sources, like the RMF III and
USS data types supported by DCE and IDT require multiple Ironstream components.
For these data sources, Syncsort recommends using the Configurator Utility (SDFSETUP),
which generates customized JCL and configuration files for your environment.
For more information, see “About the Ironstream Configurator Utility” on page 6-7.
The various z/OS runtime components can be executed as started tasks, which is the
recommended method, or batch jobs. In all cases, Ironstream requires the data set
yourhlq.SSDFAUTH to be authorized.
Installation Verification Process (IVP)

Using the Ironstream Configurator Utility helps to ensure that Ironstream is correctly
configured. Each supported data source has its own configuration and there is no single
activity that tests the entire Ironstream installation, but there are some basics that must be
correct for all data sources, specifically:
• The product license key must be valid.
• The runtime load library must be APF authorized.
• The target destination connection must be configured for TCP.
If you are planning to collect SMF data, there is an additional verification task to ensure
that the system IUEFU8* exits are correctly defined for Ironstream. Note that detailed
instructions for defining the required z/OS SMF record exits are in the Ironstream Program
Directory.

To validate all the above, there are two tests that we recommend you perform.
1. Configure the SYSTEMSTATE data source as described in Chapter 17, “System State
Forwarding” and start the forwarder. We recommend using the SYSTEM STATE data
source as it is the easiest to configure.
a. The following message is issued if the dataset your-hlq.SSDFAUTH is not APF
authorized.
SDF0615A SDF LOAD LIBRARY MUST BE APF AUTHORIZED. TERMINATING
b. The following message is issued if the product license key in the configuration file is
invalid:
SDF0151S SDF IS TERMINATING BECAUSE NO VALID KEY WAS FOUND
The Ironstream forwarder ends with Return Code 16 in both these error situations.
Configure the target destination’s port by following the instructions in Chapter 3,
“Setting Up Splunk for Ironstream” or Chapter 4, “Setting Up Elastic for Ironstream”
and verify that the SYSTEM STATE data is being successfully forwarded.
2. Configure the SMF data source as described in “Manually Defining SMF Filtering
Configurations” on page 12-7 and specify a low volume SMF record type that you are
collecting: "SELECT":"SMFnnn". Review the messages issued by the SMF forwarder task
during initialization.
a. Message SDF0706A indicates that Ironstream is unable to activate its SMF exits.
The forwarder task terminates.
b. Any message in the range SDF0707I to SDF0711I indicates an issue with the
definition of the IEUF83/4/5 exits in your SMFPRMxx member, meaning that not all
SMF records are available to Ironstream. The Ironstream forwarder remains active.
c. If your SMFPRMxx member correctly defines the IEFU83/4/5 exits, you will see
multiple instances of message SDF0705I for all three exits for SYSTEM, and for each
subsystem (SUBSYS=STC, SUBSYS=TSO, etc.).
If you encounter the messages described either a.) or b.), issue the “D SMF,O” system
command, review the output, and correct any omissions.

Manually Configuring Ironstream

After Ironstream is installed on your system, simple started-task JCL and a configuration
file are all that is required for the following data sources to start forwarding data to a
configured destination:
• SMF
• syslog
• log4j
• DB2 table data
• FILELOAD (loading sequential files)
• Ironstream API
• System state
Important! Some data sources need additional configuration to optimize data collection and
forwarding efficiency. Table 6-1 describes the data sources listed here and provides links to
the corresponding configuration chapters in this manual.
In order to manually configure data sources to start forwarding data, you need to:
1. “Set Up Your Configuration File”
2. “Set Up the Ironstream Tasks”
3. “Configure Selected Data Sources”
Set Up Your Configuration File

Modifications to the Ironstream configuration file are required for manually configured data
sources, The configuration files are used to specify information about data sources and
destinations. The SSDFSAMP library contains members with sample JCL and configuration
files for collecting SMF, syslog, log4j, DB2 table data, and loading sequential files. The
members contain templates for the JCL and configuration options that you need to specify.
Figure 6-1. Sample Ironstream Configuration File for syslog
"SYSTEM"
"NAME":"SLOG"
"DESTINATION"
"INDEX":"mfslogindex"
"TYPE":"TCP"
"IPADDRESS":"nnn.nn.nn.nnn"
"PORT":"nnnnn"
"SSL":"NO"
"SOURCE"
"DATATYPE":"SYSLOG"
"FILTER":"SSDFFLOG"
For more information about modifying the configuration file, see “Manually Setting
Ironstream Parameters,” on page 7-1.

Set Up the Ironstream Tasks

The SSDFSAMP data set contains members with sample JCL to set up the Ironstream
tasks. Following are the names of some of the SSDFSAMP members and a description of
their contents:
• SDFDB2 – JCL PROC to capture DB2 data
• SDFLOG – JCL PROC to capture syslog data
• SDFLOG4 – JCL PROC to capture log4j data
• SDFSMF – JCL PROC to capture SMF data
You need to copy the SDFxxx members to an appropriate PROCLIB and edit them to your
site standards as appropriate. You must specify the name of the configuration file
(SSDFSAMP library and member) in the appropriate SDFxxx member in the SSDFCONF
DD statement.
Figure 6-2 shows sample JCL to run an Ironstream forwarder.
Figure 6-2. Sample Started Task JCL
//SDFSLOG PROC CFGMEM=CFGaaaa

//SSDF EXEC PGM=SSDFMAIN,REGION=0M
//STEPLIB DD DISP=SHR,DSN=yourhlq.SSDFAUTH
//SSDFCONF DD DISP=SHR,DSN=yourhlq_parmlib(&CFGMEM)
Configure Selected Data Sources

Some data sources have additional optional parameters that can be used to filter or fine-tune
the data that is extracted and forwarded to a destination. For example, when you configure
Ironstream to capture syslog data, the message filtering is accomplished by building a
message filtering module using the SSDFFLOG macro.
Table 6-1 lists the data sources that may require additional configuration when manually
configuring Ironstream and provides links to the corresponding data source configuration
chapters in this manual.
Table 6-1: Ironstream Data Sources
Source Description
Syslog Syslog message filtering is accomplished by building a message
filtering module using the SSDFFLOG macro. See “Syslog
Message Filtering,” on page 11-1.
SYSOUT There is a specific sequence in which the SELECT and FILTER
parameters must be specified or the Ironstream initialization will
fail. See “SYSOUT Forwarding,” on page 13-1.

Table 6-1: Ironstream Data Sources (continued)
Source Description
SMF Ironstream provides an SMF filtering facility for selecting specific
fields within an SMF record or subtype, so you can control how
much data is forwarded to a destination. See “SMF Record
Filtering,” on page 12-1.
IMS Many IMS log records can be captured by Ironstream. For a list of
all supported IMS record types, see “IMS Log Record Forwarding,”
on page 20-1.
DB2 To enable the collection of DB2 data, you must use the SSDFTRIG
and SSDFPROC members of SDFSAMP to create the necessary
DB2 objects and modify the configuration file. See “DB2 Data
FILELOAD Multiple files can be loaded in a single invocation of Ironstream,
either by concatenation using the standard rules of concatenation,
or by using multiple DD statements and multiple FILELOAD
configuration commands. See “Sequential File Forwarding,” on
page 16-1.
IRONSTREAM_API User applications can create and send user-defined EBCDIC data
and forward it to a destination as ASCII. See “Configuring and
Using the Ironstream API,” on page 18-1.
SYSTEMSTATE Generates z/OS system-level metrics data to forward to a
destination. See “System State Forwarding,” on page 17-1.
Note: There are no required parameters for SYSTEMSTATE.
Next Steps
• Configure destination targets for Ironstream:
▪ Set Up Splunk for Ironstream – You need to set up dedicated TCP ports and one
or more indexes in Splunk so that Ironstream can successfully forward your chosen
data sources to it. For more information, see “Setting Up Splunk for Ironstream,” on
page 3-1.
▪ Set Up Elastic for Ironstream – You need to set up an open port on your Logstash
server so that Ironstream can successfully forward your chosen data sources to it. For
more information, see “Setting Up Elastic for Ironstream,” on page 4-1.
• Start the Ironstream Forwarder – After manually configuring your data source you
can start the Ironstream forwarder tasks, as described in “Controlling Ironstream
Components,” on page 8-1.

About the Ironstream Configurator Utility

Ironstream provides an ISPF-based utility (SDFSETUP) to customize the JCL and
configuration for your environment. It is strongly recommended for configuring DCE, IDT,
NMC, and log4j. This section includes the following main topics:
• “How the Configurator Utility Works”
• “DCE, IDT, and XCF Configuration Considerations”
• “Running the Ironstream Configurator Utility”
• “Post Configurator: Additional Actions”
How the Configurator Utility Works

The Configurator Utility creates customized JCL, configuration files, and other tailored
members (based on your input values) in a single PDS that you specify at the start of the
process. When you have completed the configuration, you can move (or copy) members to the
appropriate run-time libraries of your choice.
The started task names you specify are the member names in the output configuration file.
For example, if you specify “SDFUSS” as the started task name for the USS forwarder,
member SDFUSS is created. Members containing forwarder run-time parameters are
prefixed with “CFG” for Splunk and “CFE” for Elastic. For example, “CFGUSS” is the
member name for the USS forwarder for Splunk.
The configuration members for DCE are prefixed with “DCE”. The name of the DCE
configuration file for the USS file forwarder is “DCEUSS”. Member ZENPARM is shared by
the Ironstream Desktop (IDT), DCE, and several of the NMC components.
Configuration file member names are included in the generated started task JCL, so if you
rename a member, you must change the appropriate shared task JCL.
Manual Post-Configurator Steps

Although the Ironstream Configurator generates JCL and control statements, additional
manual tailoring is required for every data source, and appropriate instructions are included
in the ensuing chapters in this manual. In addition, you should note the following:
• Generated JCL – Any JCL parameters in lower case, require customization. In some
cases, the data sets to be tailored have an upper case low-level qualifier that
corresponds to an SMP/E data set, such as your_hlq.SSDFAUTH.
• Started Task Members – After running the Configurator, the started task members
created for the Ironstream Forwarder, DCE, IDT, and log4j require some additional
manual configuration. These steps are listed after each of the corresponding sample
configuration panels in “Running the Ironstream Configurator Utility” on page 6-11.
• Date Collection Extension – The DCE global parameters and the RMF and USS data
types need additional configuration, such as changing the default RMF scan frequency
or specifying the USS server log files to be collected. These steps are explained in “Post
Configurator: Additional Actions” on page 6-23.

DCE, IDT, and XCF Configuration Considerations

Correctly configuring DCE data types, IDT, and XCF (Cross System Coupling Facility) is
crucial and there are a number of configuration parameters that are interdependent.
Figure 6-3. DCE Component Architecture
The components involved are as follows:

• One or more Ironstream forwarder tasks for each supported DCE data type, each with
DATATYPE XCF. Multiple forwarder tasks in the same XCF group provide automatic
failover.
• Separate DCE tasks for each data type, currently USS and RMF data collection, each
with different XCF group and member parameters.
• A single IDT task for dynamically configuring USS file collection and RMF filters.
Each forwarder task has a separate configuration file. Each DCE task has two configuration
files, one of which is shared with IDT.
Ironstream XCF Instances

Ironstream XCF instances are defined in the Ironstream forwarder using the XCFGROUP
and XCFMEMBER parameters for a data source of XCF. Target Ironstream XCF instances
are specified in the DCE configuration to receive USS data and RMF metrics and forward
them to a destination.
The XCF instances are also relevant for the Ironstream Desktop (IDT) and when you plan to
use one or more Network Monitoring components (NMC) to forward alerts and/or SyslogD
data via Ironstream to a destination; this facility also requires some configuration in IDT.

Ironstream Forwarder(s)
Each Ironstream forwarder is a separate started task and so must have a unique
four-character instance name in its configuration file, in the format of "NAME":xxxx". The
instance name must be unique within a SYSPLEX. The Ironstream configuration file also
includes the XCF group to which the forwarder belongs, and the XCF member name within
the group.
Figure 6-4 shows a configuration that defines an XCF forwarder for USS processing:
Figure 6-4. Ironstream Configuration for the USS Data Type
"SYSTEM"
"NAME":"USS1"
"DESTINATION"
"INDEX":"ussindex"
"TYPE":"TCP"
"SOURCE"
"DATATYPE":"XCF"
"XCFGROUP":"USSXCFG1"
"XCFMEMBER":"USSXCFM1"
Figure 6-5 shows an Ironstream configuration that defines an XCF forwarder for RMF
processing:
Figure 6-5. Ironstream Configuration for the RMF Data Type
"SYSTEM"
"NAME":"RMF1"
"DESTINATION"
"INDEX":"rmfindex"
"TYPE":"TCP"
"SOURCE"
"DATATYPE":"XCF"
"XCFGROUP":"RMFXCFG2"
"XCFMEMBER":"RMFXCFM1"
DCE Tasks
Each DCE data type must have its own DCE task and associated Ironstream forwarder
task(s). For example, for the USS data type, the DCE configuration specifies only
parameters for USS data collection.
Note: DCE USS data can be delivered to Elastic Stash destinations, but due to current
limitations the source (file name) will not be supplied. For more information, see “Setting Up
Elastic for Ironstream,” on page 4-1.

Figure 6-6 shows the significant DCE Global Settings parameters for USS.
Figure 6-6. DCE Configuration for USS
• InstanceName – This parameter, which can be up to eight characters long, is unique to

each instance of DCE on an LPAR and has no interdependency with anything else, but it
does identify the DCE instance to IDT for administrative purposes. The instance_name
must be a maximum eight characters long.
Define Globals
InstanceName DCEUSS
Maxthreads 4
• IronstreamCluster – This parameter, which can be up to eight characters long,

defines a group of Ironstream systems to forward data a destination; it is unique and
has no interdependency with anything else. Multiple cluster definitions are not required
but using clustered DCE configurations provides failover. Note that the XCFGroup
parameter defines the relationship between DCE and the forwarder tasks.
Define IronstreamCluster ClusterUSS1
XCFGroup USSXCFG1 XCFMember USSXCFM1
On start-up, an XCF connection is established between DCE and all of the currently active
members in the same XCF group. RMF is a single thread process and the first member in
the DCE Global Settings is used. If this primary forwarder is stopped or terminates,
forwarding is automatically switched to the second task. USS is a multi-threaded process
and the workload is balanced across all available XCF forwarders.
For more information about configuring DCE parameters for USS and RMF, see
“Configuring the DCE Parameters,” on page 21-1.
Ironstream Desktop Task

The Web browser interface to IDT allows you to control many operational aspects of
Ironstream. For example, you use IDT to define the RMF III metrics to be collected and the
USS files to monitor. IDT is also used for defining SMF record filtering.
The IDT started task has a single configuration parameter member called ZENPARM and
this same parameter member is allocated in your RMF and USS DCE started tasks JCL.
This is how IDT interacts with the DCE sources. In some cases, you might have multiple
DCE USS instances. Every instance that shares the same ZENPARM member can be
controlled from the associated IDT.
Access to IDT is controlled by a RACF CLASS FACILITY profile called WDS.ZEN.groupname.
The configurator defaults the started task name as the groupname.

Running the Ironstream Configurator Utility

The Ironstream configurator includes the following configuration panels:
• “Launch the Ironstream Configurator”
• “Select the Ironstream Components to Configure”
• “Specify the Ironstream Forwarder Parameters”
• “Specify the DCE Parameters”
• “Specify the Ironstream Desktop (IDT) Parameters”
• “Specify the Log4j Parameters”’
• “Configure the Network Monitoring Components”
Launch the Ironstream Configurator

The Ironstream Configurator is shipped in the your_hlq.SDFCFG library, which is one of the
three files that are part of the Ironstream package that your system programmer uploaded.
Launch the configurator by executing the member SDFSETUP. The configured objects created
by the tool are written to a new FB/80 library, which the configurator creates if it doesn’t
already exist.
There is an explanatory panel displayed when SDFSETUP is executed for the first time. Press
Enter to continue to Panel 6-1.
Panel 6-1: Initial Configuration

Notes:
• Specify the Ironstream key that Syncsort has provided. The key is added to all of the
generated configuration files.
• The Ironstream load library name must be syntactically valid, although the data set
does not need to exist. The data set name you specify is added to all the generated
started task JCL. Ironstream requires the data set yourhlq.SSDFAUTH to be authorized.

• The zFS root name is not required if you are configuring the base Ironstream
component only, in which case leave the default value. If you blank out the zFS root
name field, the only component that is configurable is base Ironstream.
Press Enter to continue to Panel 6-2.
Select the Ironstream Components to Configure

The selection panel allows you to configure a single component or a combination of
components at the same time. Panel 6-2 shows the default settings with all components
selected.
Panel 6-2: Ironstream Component Selection

• Specifying S in the Opt column selects a component and Selected is shown in the
Status column. Selected components can be deselected by specifying U.
Each time you add or change an option and press Enter, the panel is redisplayed with
the updated Status information.
Important! You must also configure IDT if you are configuring DCE or NMC.
• Option I lists all of the outputs that are created for each component. Noting which
members are associated with each component helps you identify what needs to be
manually tailored.
• Pressing F3 on a component configuration screen ends the configuration of that
component and moves to the next one you have selected. Configuration members for
that specific component are not created if you press F3.
Press Enter to proceed to the appropriate configuration panel based on your selection.
Panel 6-3 shows the result of option I for the Network Monitoring Components. The
Date and Time values are built from ISPF statistics in the your_hlq.SDF.CUSTOM data set
and are unpopulated for a component not yet configured.

Note that the Date column in this example is displayed in national language format.
Panel 6-3: List NMC Configuration Members

Specify S on Panel 6-3 to view any configured member.
Press Enter to return to the Component Selection panel shown in Panel 6-2.

Specify the Ironstream Forwarder Parameters

When Ironstream is selected on Panel 6-2, the configurator displays the Forwarder
Tasks selection panel shown in Panel 6-4.
The data entered in Panel 6-4 is added to the generated configuration files for four data
sources, which can be manually edited afterward if necessary.
Panel 6-4: Ironstream Forwarder Tasks

For each data source that you want to configure:
• Specify the name of the started task (STC Name) associated with the required data
source, the Index Name, and the IP Address and Port of the Splunk or Logstash
server. You can leave the default values for fields applying to data sources that you are
not configuring.
Note: The Index Name must be specified using lower case.
• Specify Y for SSL. if required
• To add additional ports, specify Y in the More field. This opens a pop-up window that
enables you to specify additional IP addresses and ports.
Press Enter to proceed to the DCE configuration panel shown in Panel 6-5.
Additional Actions for Ironstream Started Task Members

The following manual tasks are required prior to starting the started task for basic
Ironstream data sources.
1. In the started task JCL members, specify the name of the library containing the
configuration file for each required data source, as shown in Figure 6-7.

Figure 6-7. Sample Started Task JCL
//SDFSMF PROC
//*------------------------------------------*
//* IRONSTREAM SMF data forwarder task *
//*------------------------------------------*
//IEFPROC EXEC PGM=SSDFMAIN
//STEPLIB DD DISP=SHR,
// DSN=yourhlq.SSDFAUTH
//SSDFCONF DD DISP=SHR,
// DSN=yourhlq_parmlib(CFGSMF)
//CEEOPTS DD DISP=SHR,
// DSN=yourhlq_parmlib(CEEOPTS)
// PEND
2. A CEEOPTS DD statement is included in each started task member. This is optional for
all data sources except SMF and log4j, and can be commented out elsewhere.
3. The SYSABEND DD statement is optional but it is advisable to have it for a period after
installation.
Specify the DCE Parameters

There are at least two separate run-time tasks for each DCE data source: a DCE task for
each specific data type and one or more forwarder tasks. A single instance of IDT is a
co-requisite component for setting RMF filters and for defining filters for files and
directories in the USS file monitor. Before you start the DCE configuration, carefully review
the “DCE, IDT, and XCF Configuration Considerations” on page 6-8.
Panel 6-5 shows the DCE configuration panel.
Panel 6-5: DCE Configuration

• Forwarder Parameters – Specify the STC Name of the Ironstream Forwarders for
RMF and USS, the Index Names, and the IP Addresses and Port numbers of the
Splunk or Logstash servers.
Note: The Index Name is valid for RMF data forwarding; however, for the USS data
type, this field is ignored: the actual USS index names are defined in the USS filters.
For more details, see Chapter 22, “Setting Up USS File Collection”.
• XCF Group Parameters – Each DCE data source uses XCF, so provide separate XCF
Group and Member names. For optional failover, you can manually add additional
XCF members to the generated DCERMF and DCEUSS configuration members. For
instruction on adding additional XCF members, see “Configuring the DCE Parameters,”
on page 21-1.
• DCE Parameters – Specify the STC Name for RMF and USS. For RMF, provide the
IP Address and Port of the RMF III Distributed Data server (DDS). This is typically
defined in a system PARMLIB member called GPMSRVnn. The help screen provides
additional information about RACF authorities that are needed for the RMF DDS.
Press Enter to Proceed to the Ironstream Desktop configuration panel shown in Panel 6-6.
Additional Actions for DCE Started Task Members

The following manual tasks are required prior to starting DCE.
1. The RMF data source uses checkpointing and requires a checkpoint data set to be
created and allocated in the DCE RMF JCL. Member DCEDEFDV is sample JCL to
create the data set. The USS data source does not require a checkpoint data set.
2. In the started task JCL, update the DCEPARM DD statement and specify the library
for the DCE configuration member. The default names are DCERMF and DCEUSS.
Important! There are run-time options for starting the DCE instances for RMF and USS.
For normal operation, a HOT start is appropriate and this is the start parameter in the
generated started task members. However, the first time you start either the RMF or the
USS DCE instances, you must specify WARM. For a detailed explanation of the implications
of the different start options, see “Controlling the Data Collection Extension (DCE)” on
page 8-4.

Specify the Ironstream Desktop (IDT) Parameters

IDT is a combination of a z/OS started task and a GUI that provides administration
capabilities for certain Ironstream functions.
Panel 6-6 shows the IDT configuration panel.
Panel 6-6: IDT Configuration

• Specify the name of the Ironstream forwarder started task (STC Name) for IDT.
• Specify the IP Name or Address of the z/OS system where the started task runs, as
well as an HTTP Server Port and a Domain Server Port that are not already used
by other applications.
• IDT requires names for a VTAM Application Major Node and a VTAM ACB.
• RACF Class FACILITY profiles are required for IDT. The RACF commands that are
generated in your_hlq.SDF.CUSTOM member IDTRACF provide the means to control
which users can use IDT. You can also provide further security granularity within IDT if
required, as explained in “Controlling Authority Levels within IDT” on page 6-17.
Press Enter to proceed to the Log4j Forwarder Parameters panel.
Additional Actions for IDT Started Task Members

The following manual tasks are required prior to starting IDT:
1. Customize and run member IDTDEFLG to create the alert run-time VSAM data set.
2. Update the IDT started task JCL with the alert data set name.
3. Member IDTRACF contains the commands to create the required RACF entities. The
following section explains how to optionally control access to functions within IDT.
Controlling Authority Levels within IDT

The RACF commands in member IDTRACF provide the means to define the users that are
authorised to use IDT, but there may be cases where you want to add finer access
granularity. For example, you might want some users to generate SMF record filters, but

you don’t want them to be able to change RMF III or USS definitions. Using this scenario,
here are the required steps:
1. Designate an IDT administration user. For this example, let’s assume their RACF
userid is IDTADM.
2. Create the class FACILITY profile WDS.ZEN.MASTER, with UACC(NONE).
3. Permit IDTADM READ access to WDS.ZEN.MASTER.
4. Within IDT, user IDTADM uses the Admin menu to select Ironstream(ussn) > USS
Defaults. (For a sample screenshot, refer to Panel 22-4, “USS Defaults”.)
5. Right-click in the USS Defaults panel and select Set Security. This opens a pop-up
that allows you to set the access level for the USS Defaults panel.
Panel 6-7: Setting Authority Level within IDT

6. In the Authority Level field, specify an upper case name to represent the USS
Defaults panel. In this scenario, a panel name of SMFONLY could be appropriate.
Click Close.
7. Create a new class FACILITY profile called WDS.ZEN.SMFONLY. Note that the profile
name is case sensitive.
8. PERMIT READ access to those users who you want to access the USS Defaults pane.
Repeat actions 4-8 for other IDT panels that you want to control in the same way.
Configuring IDT to Use Secure HTTPS and AT-TLS

By default, IDT uses the HTTP protocol both for user interaction and for transferring
between systems in your network. However, if your environment requires using HTTPS, the
HTTPProtocol parameter in the IDT configuration must be changed to HTTPS after running
the Configurator utility. The IDT configuration is stored in the ZENPARM member in your
started tasks JCL.
And because IDT is a Basic-mode AT-TLS application, you must also configure the z/OS
Policy Agent to provide TLS on all the ports involved in browser-to-IDT and IDT-to-IDT
communication. When updating the Policy Agent settings, you should first consult your
network or security administrator.
Note: No AT-TLS configuration is required, nor should be specified, for the Ironstream
forwarder when using the internal Ironstream SSL configuration. For more information
about AT-TLS, refer to IBM’s z/OS V2R3 Communications Server manual.

Specify the Log4j Parameters

Log4j data can be dynamically forwarded to destinations as the log records are created; it
can also be forwarded using an offline process. The parameters defined on this panel cover
both of these scenarios. For further information on the configuration parameters. See
“LOG4J Subparameters” on page 7-24 and “Setting Up Log4j,” on page 19-1.
Panel 6-8 shows the log4j configuration panel.
Panel 6-8: Log4j Forwarder Parameters

• Forwarder Parameters – Specify the name of the log4j appender z/OS started Task
Name, the Index Name, the name of the Named Pipe, and the IP Address and Port
of the Splunk or Logstash server.
• Offline Log4J Reader Parameters – Optionally, specify the Java64Bit, Java Home,
and File Name parameters for the Offline Log4j Reader.
• zFS Path – The JAR file that log4j requires must be available in the zFS path that is
displayed in Panel 6-8.
Additional Actions for Log4j Started Task Members

The following manual tasks are required prior to starting the started task for the log4j
appender.
1. In the started-task JCL members, specify the name of the library containing the
configuration file for log4j.
2. A CEEOPTS DD statement is required and is included in the log4j started-task
member. The generated member CEEOPTS specifies the options that are appropriate
for log4j. The SYSABEND DD statement is optional, but it is advisable to have it for a
period after installation.

Configure the Network Monitoring Components

The NMC data source is based on Syncsort’s ZEN network monitoring suite. For Ironstream,
it is a collection of 5 discrete components each with its own started task VTAM application
attributes. Each component has a single configuration screen.
Some NMC components require VSAM data sets and the configurator generates skeleton
JCL and control cards. You must tailor the appropriate started task JCL members with the
names of the data sets you create. This is described further in “Create the NMC Run-time
Objects” on page 6-23.
From an Ironstream perspective, NMC is a single component that requires all five ZEN
components. Knowledge of z/OS networking is advantageous. You can accept all default
values, although these may not conform to your local site standards.
The NMC configuration instructions that follow are summarized. Comprehensive
instructions are part of the ZEN product suite and can be found in the appropriate chapters
of the Installing and Maintaining ZEN and ZEN Components manual, which is included in
the zipped “Ironstream and ZEN” documentation file. You can download individual ZEN
manuals from the Ironstream download site in MySupport.
For more detailed information about using each Network Monitoring Component with
Ironstream, see “Alerts and SyslogD Forwarding,” on page 14-1.
Configure the EE Monitor

Panel 6-9 shows the EE Monitor configuration panel.
Panel 6-9: EE Monitor Configuration

• Specify the values for the EE Monitor Started Task Name and the VTAM Major
Node Names.
• Specify the Session Awareness (SAW) applications, plus application names for the
other EE monitor required components.

Configure FTP Control

Panel 6-10 shows the FTP Control configuration panel.
Panel 6-10: FTP Control Configuration

Specify values for the FTP Control Started Task Name and the VTAM Major Node and
VTAM ACB names.
Configure the IP Monitor

Panel 6-11 shows the IP Monitor configuration panel.
Panel 6-11: IP Monitor Configuration

There are two started tasks associated with the IP Monitor:
• Specify the STC names and the VTAM application node and ACB names.
• Specify an available TCP/UDP Port Number and the name of the TCP/IP tasks that
run on the system to be monitored.

Configure the OSA Monitor

Panel 6-10 shows the OSA Monitor configuration panel.
Panel 6-12: OSA Monitor Configuration

Specify the values for the OSA Monitor Started Task Name and the VTAM Major Node
and VTAM SPO application names.
Configure the UNIX Server

The final NMC component to be configured is the UNIX Server. Panel 6-10 shows the
configuration panel.
Panel 6-13: UNIX Server Configuration

Specify the IP Address and Port of the UNIX server. The default value of 15 for the
Maximum clients is adequate for most NMC deployments.

Create the NMC Run-time Objects

Run-time data sets are required for some of the NMC components so the configurator creates
the necessary skeleton JCL and control cards. The member names in Table 6-2 must be
customized for your local data set names and executed. The Related Member column
indicates which started JCL members reference data sets are created by the four jobs.
Table 6-2: Generated NMC Member Names for Manual Tailoring
Member Description Related Member

ZEMDEFDV Job to define EE Monitor VSAM files SDFZEM
ZFCDEFDV Job to define FTP Control VSAM files SDFZFC
ZIMDEFDS Job to define IP Monitor VSAM files SDFZIMI,
SDFZIMD
ZOMDEFDV Job to define OSA Monitor VSAM files SDFZOM
For more detailed information about using each Network Monitoring Component with
Ironstream, see Chapter 14, “Alerts and SyslogD Forwarding”.
Post Configurator: Additional Actions

The Ironstream configuration tool creates started task JCL, run-time configuration
members, VTAM definitions, plus some other outputs that are required for the initial
deployment. The JCL is largely static but the configuration files for some data sources need
to be customized to match your requirements.
You can find detailed information about additional required configuration in the following
chapters:
• Chapter 19, “Setting Up Log4j”
• Chapter 21, “Configuring the DCE Parameters”
• Chapter 22, “Setting Up USS File Collection”
• Chapter 23, “Setting Up the RMF Data Forwarder”
About the Forwarder Tasks and Additional Tasks

Chapter 6, “Configuring Ironstream Components”All data sources use an Ironstream
forwarder task, and starting/stopping it is the same in each case, whether it is for a basic
data source, such as syslog, or a DCE data type, such as RMF. Instructions for starting and
stopping Ironstream forwarders are provided in Chapter 8, “Controlling Ironstream
Components”.
Data source types that use that use DCE and IDT have additional started tasks, and in some
cases these tasks have various start parameters. These are described in the following
sections:

• “Controlling the Ironstream Desktop (IDT)” on page 8-3 explains the options for
managing IDT for NMC components and for DCE data types.
• “Controlling the Data Collection Extension (DCE)” on page 8-4 describes the options for
managing DCE.
• “Controlling the Network Monitoring Components (NMC)” on page 8-7 discusses the
options for the NMC components.
Next Steps
• Modify Basic Configuration File Parameters – After running the Configurator,
minor modifications to the Ironstream configuration file are required for some data
sources, such as log4j and the Ironstream API. Sample configuration members for some
data sources are provided in the your_hlq.SSDFSAMP library. For more information
about modifying the configuration file, see Chapter 7, “Manually Setting Ironstream
Parameters”.
• Configure target destinations for Ironstream:
▪ Set Up Splunk for Ironstream – You need to set up dedicated TCP ports and one
or more indexes in Splunk so that Ironstream can successfully forward your chosen
data sources to it. For information on how you do this, see Chapter 3, “Setting Up
Splunk for Ironstream”.
▪ Set Up Logstash for Ironstream – You need to set up an open port on your
Logstash server so that Ironstream can successfully forward your chosen data
sources to it. For more information, see Chapter 4, “Setting Up Elastic for
Ironstream”.

Chapter 7 Manually Setting Ironstream
Parameters
This chapter explains how to configure the Ironstream configuration file parameters to
define data sources and target destinations. It also includes descriptions of typical
Ironstream parameters and example configuration files.
Topics:
• “Overview of the Configuration File” on page 7-2
• “General Syntax Rules” on page 7-3
• “Configuration Parameters” on page 7-6
• “Typical Ironstream Parameters” on page 7-27
• “Configuration File Examples” on page 7-29

Manually Setting Ironstream Parameters
Overview of the Configuration File

The primary purpose of the configuration file is to define data sources and destinations
using the SOURCE and DESTINATION parameters and the keywords they provide. The
other parameters, KEYS, SYMBOLS, and SYSTEM, are used to define the license key, local
system symbols, and various system-related values, such as the name of the Ironstream
instance.
When you use the automated Ironstream Configurator process described in “Configuring
Ironstream Components,” on page 6-1, correctly defined and working configuration members
and their associated JCL procedures for each of the primary data sources will have been
built according to the values you provided on the configuration panels.
The data set your_hlq.SDFSAMP created during the configuration process contains a variety
of other configuration files as examples of other ways in which you can use Ironstream’s
parameters to specify your chosen destination’s data streaming requirements. The ‘CFGxxx’
members are models for non-secure socket configurations and the ‘CFGxxxS’ members are
models for secure socket configurations.
Configurations are implemented by specifying the name of the configuration file on the
SSDFCONF DD statement in the appropriate SDFxxx member of your_hlq.SDFSAMP. The
automated Ironstream Configurator will have done this for you for each of the data sources
you configured during Ironstream configuration.
Always bear in mind that Ironstream can collect and forward only one data source in each
Ironstream instance. So collecting three data sources requires three address spaces to be
started. Each instance of Ironstream requires a separate configuration file member that
includes a NAME parameter in the SYSTEM section. This parameter defines the unique
‘instance name’ of that specific instance of Ironstream running in the LPAR.
Static versus Dynamic Modification of an Ironstream Configuration

In order to make configuration changes for most data sources, you must first stop the
Ironstream instance, modify the configuration file, then restart the instance.
However, a running Ironstream instance collecting SMF records can have its existing
SOURCE configuration parameters dynamically modified without having to stop and restart
it. This includes switching from a currently-configured SMF record type to another SMF
type, changing/adding the subtypes, and tuning the SMF filtering parameters, such as
INCLUDE and WHERE. Such dynamic reconfiguration alleviates the need to stop running
tasks, thereby preventing the loss of records by eliminating unnecessary downtime while
gathering SMF data.
It is important to note that if any other configuration parameter changes are made when
dynamically changing SMF type parameters – such as adding another TCP connection – the
changes are verified as correct by the reconfigure commands, but are not implemented until
the Ironstream instance is restarted. For more information, see Chapter 9, “Dynamically
Modifying a Running Ironstream Configuration”.

General Syntax Rules

This section describes the syntax rules for the configuration file.
Keywords
• All keywords must be entered in upper case. Most values should also be entered in
upper case. However, there are certain exceptions, including:
▪ Log4j SOURCE parameters NAMEDPIPE, JAVA HOME, SDFHOME, FILENAME,
TIMESTAMP and PATTERN keywords.
▪ Certain DESTINATION parameters, such as INDEX, IPADDRESS, and
CERTIFICATE.
▪ SMF record filtering selection INCLUDE and WHERE statements.
Comments and Columns

• An all-blank record or a record that has an asterisk '*' in column 1 is a comment record.
• Comment records cannot be continued and are not checked for a continuation indicator.
• Comment blocks can be defined using /* and */ as delimiters and can span one or more
statements.
• Comments are not permitted within the range of any continued command statement.
• Section identifiers and command keywords can start in any column in a record.
• Only columns 1 through 71 can contain functional data. Columns 73 through 80 are
ignored and can contain anything.
Parameter List Delimiters and Continuation Methods

• Comma delimited parameter lists cannot have blanks between commas and parameters
on the same physical record.
• The continuation of a command can be indicated using one of two methods for each
logical record. In either case, the maximum combined length of a logical record is 2048
bytes, which can be twenty-eight 71-character records or around 225 fields of eight bytes
and a comma.
▪ In the first method, a comma delimited parameter string can indicate continuation by
having a comma being the last character on a record and column 72 being blank. The
data on the continuation statement can start in any column. Blanks at the start or
end of a record using this method do not count towards the 2048 byte limit.
An example of a valid continued parameter string using 38 of 2048 bytes is:
INCLUDE":"SMF30DTE,SMF30TME,
SMF30JNM"
An example of an invalid parameter string is:
"INCLUDE":"SMF30DTE, SMF30TME,
SMF30JNM"
The blanks between the commas and the value are invalid.

▪ In the second method, column 72 is used to indicate the continuation of data on the
following record. The continued data starts in column 1 and is logically concatenated
to the data in column 71 of the previous record. This method is typically used for a
long single parameter, such as a NAMEDPIPE name. This method overrides the first
method and is incompatible with it.
▪ An example of this method, with column numbers as the first two lines for clarity, is:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
¨SOURCE¨
"DATATYPE":"LOG4J"
"NAMEDPIPE":"\user\directory_level_1\directory_level_2\directory_level_+
003100 3\filename.type"
Note that the plus sign ‘+’ in column 72 could be any non-blank character.
Section Identifiers and Parameters

• Section identifiers and parameters may start in any column in a record.
• The KEYS, SYMBOLS, SYSTEM, DESTINATION, and SOURCE section identifiers
must be on individual records and must be enclosed in double quotes, as in "KEYS",
"SYMBOLS", or in square brackets, as in [KEYS], [SYMBOLS].
You cannot mix square brackets and double quotes: For example:
"SYSTEM" Correct
[SYSTEM] Correct
[SYSTEM" Incorrect
• Parameters are specified as "keyword":"value" pairs and must start on a new record; for
example: "SCOPE":"SYSPLEX". All the text between the double quotes that delimit the
value string, including blanks, is significant and is included in the value data. Values
can contain system symbols and/or local system symbols. A comment can follow a
"keyword":"value" pair by having at least one blank character preceding the comment.
• System symbols can be used at any location in the configuration file. Locally defined
symbols can be used any time after they are defined in the SYMBOLS section. Both
system and local symbols are evaluated prior to processing by the syntax parser. A
record that has a symbol in its text is printed first as a SDF0101I message, and again
after symbol substitution as a SDF0901I message.
• Some parameters are sequence-sensitive and must be specified in the order they are
shown in this manual. Some parameters are optional but if present, they must be in the
sequence given in the manual. Some sections have relaxed syntax sequence structures,
as follows:
▪ In the KEY and SYSTEM sections, most parameters can appear in any sequence,
except for the NAME, USAGE_SMF_NUMBER, and IMPORT parameters.
▪ In the DESTINATION the optional parameters that precede the
DATA_LOSS_PREVENTION or INDEX parameters can occur in any sequence. This
includes the following parameters:
DATASTORESIZE, DATASTOREQUEUE, SOURCE, SOURCETYPE,
THROTTLING_RATE, KEEP_ALIVE, RETRY_ON_START,
RETRY_ON_START_INTERVAL, and RETRY_ON_START_LIMIT.

Configuration Records Echoed to SYSPRINT

Each record read in from the configuration file will be echoed to the SYSPRINT file as an
SDF0101I message. Records that contain user or system symbols are reprinted after
substitution as a SDF901I message. Continued records with user or system symbols are
concatenated together and printed as a single SDF901I message over multiple lines.
Syntax Note about the Ironstream Starter Edition

To trigger the Starter Edition the KEYS section must not be specified. If a KEYS section is
specified, normal processing, including validation of KEY parameters, will be carried out.

Configuration Parameters
The configuration file starts with the KEYS section and is followed by one each of the
SYMBOLS (optional), SYSTEM, DESTINATION, and SOURCE sections. The combination
of the parameters defined in these sections forms the characteristics of the run-time
environment of an Ironstream instance to handle one data source. Should you require
multiple data sources, simply define several configuration files, one for each data source.
Some of the parameters described in this chapter have further optional subparameters that
can be used to fine-tune the data that is extracted and forwarded. These are fully covered in
other chapters and appropriate references are made in the text that follows.
• “KEYS Section” on page 7-6
• “SYMBOLS Section” on page 7-6
• “SYSTEM Section” on page 7-7
• “DESTINATION Section” on page 7-11
• “SOURCE Section” on page 7-16
KEYS Section
The KEYS section is used to supply the Ironstream license keys and optionally to set an
expiration warning period. License keys are provided by Syncsort, Inc.
Note: If you are using the Ironstream Starter Edition to forward only syslog and/or SMF
record type 205 data, then you cannot have a KEYS section in your configuration; otherwise,
this section is mandatory.
You may need to generate an SSDFCPR report to provide information for the creation of
license keys. For more information, refer to “The SSDFCPR Utility” on page B-1.
"KEYS" - Mandatory parameter that identifies the start of the KEYS section.
"KEY_WARN_DAYS":"nnn" - Optional parameter that specifies a 1-3 digit number of days

to print out the key expiration notice. For example if nnn=45, the expiration notice
will start appearing 45 days before the key will expire. nnn can be 1-999; the default
is 45.
"KEY":"license key" - Mandatory parameter that specifies the 16-hexadecimal character

key provided by Syncsort, Inc. If you have more than one key, supply a KEY
statement for each additional key. Ironstream will not initialize without a valid key.
SYMBOLS Section
The SYMBOLS section is used to define local system symbols that can be used for
substitution in any subsequent configuration parameters (symbols may not be used in this
section).
This section is optional, but if defined it must appear immediately after the KEYS section
and precede the SYSTEM section.
To define a local system symbol use the following parameter format:

"&symbol.":"substitution_text" - symbol is the name of the local system symbol to be

created and substitution_text is the value that is substituted when the symbol is used.
The length of substitution_text cannot exceed the length of symbol’s name plus one.
symbol must:
• Begin with an ampersand
• End with a period
• Contain from 1-253 additional characters
• In general not start with &SYS unless you are intentionally overriding
substitution text for system symbols. A DISPLAY SYMBOLS console command
will display the system symbols and associated substitution texts that are
currently in effect. For example, ‘&MYSYM.’ is valid but ‘&.’ and ‘&SYSMINE.’ are
not. Ironstream reserves 4060 bytes for local system symbols. Each symbol uses 18
bytes plus the symbol length and the length of the substitution text. For example,
Ironstream would support 119 locally defined symbols if each symbol and
substitution_text field were 8 bytes long.
SYSTEM Section
The SYSTEM section specifies the name of this Ironstream instance that is running and
other global parameters. With the exception of the "NAME", "USAGE_SMF_NUMBER", and
"IMPORT" parameters, the SYSTEM parameters can appear in any sequence.
"SYSTEM" - Mandatory parameter that identifies the start of the SYSTEM section.
"NAME":"instance_name" - Mandatory parameter that specifies the 4-character name of

the Ironstream instance. instance_name does not have to match either the task or job
name although the name specified must be unique among all Ironstream instances
running on the LPAR.
All alphanumeric and national characters are valid but for syslog collection (see
“SYSLOG Subparameters” on page 7-20) instance_name must begin with one of the
letters A through Z, or with #, $, or @. Each Ironstream instance running on an LPAR
is identified by its unique instance_name.
"USAGE_SMF_NUMBER":"nnn" - (optional) By default, the Ironstream Data Usage

Reporter collects SMF records using SMF record number 207. If you need to use a
different SMF record number, you can designate the desired SMF number. For more
information, see “Overriding the Default SMF Record Number” on page 29-6.
"LOADLIB":"library" - (optional) library is the data set name of the load library where the
Ironstream modules reside. If this is not specified, the load modules must reside in
the LINKLST or in a library specified by a JOBLIB or STEPLIB DDNAME
concatenation.
"FILELOAD":"ddname" - ddname is the name of the DD statement for the sequential file to
be loaded in the step that executes PGM=SSDFMAIN. Multiple files can be loaded in
a single run. Use multiple FILELOAD parameters with different ddname values to

load multiple files. Refer to the section “Capturing Sequential Data” on page 16-1 for
an example of the JCL required to load sequential files.
"RACFLOAD":"ddname" - ddname is the DD statement name in the Ironstream job control

that references an unloaded RACF database to be forwarded to a destination. The
unloaded database must have already been created on the system using the RACF
database unload utility IRRDBU00. The DATATYPE defined in the SOURCE section
(see page 19) must specify RACF to use this facility.
"IMPORT":"ON" - Optional parameter that specifies that data is to be imported from a flat
file rather than an active data source and forwarded to a destination in the usual
way. Ironstream can import data from syslog, SMF, log4j or other USS data files.
Important!
• The RECOVERY parameter that performed this function in Ironstream V1.2 is
still available for backward compatibility. Existing JCL decks will continue to
work without change. However, Syncsort strongly recommends that you change
any RECOVERY parameters to IMPORT as soon as practical since V2.1 will be
the last release to support the RECOVERY parameter.
• IMPORT is incompatible with Data Loss Recovery (DLP). Configuring both
functions will generate message SDF0190A and cause the Ironstream instance to
terminate. For more information about DLP parameters, refer to Chapter 10,
“Configuring Data Loss Prevention”.
When the IMPORT parameter is used, the START DATE, START TIME, END DATE
and END TIME parameters must also be specified and be in the format appropriate
to the data source you intend to import.
For syslog and SMF data the formats are:
"START DATE":"mm/dd/yyyy"
"START TIME":"hh:mm:ss.th"
"END DATE":"mm/dd/yyyy"
"END TIME":"hh:mm:ss.th"
For log4j data the formats are:
"START DATE":"yyyy/mm/dd"
"START TIME":"HH:mm:ss,SSS"
"END DATE":"yyyy/mm/dd"
"END TIME":"HH:mm:ss,SSS"
Only records within the specified date and time boundaries are forwarded to a
destination.
"TIMEZONE OFFSET":"+HHMM" - Optional parameter that manually specifies the time

zone offset from the operating system. Ironstream automatically determines the time
zone offset from the operating system. If the offset stored in the operating system is
incorrect, this parameter can be used to manually set the time zone offset. The format
is " ±HHMM". The valid range is "-1259" to "+1259".

"DATE_OFFSET":"+/-nnn or PHYSICAL" - Optional parameter that manually specifies

the date portion of date fields or date/time fields in SMF records, as recorded in a
destination repository by a given number of days, either forward or backward, to a
value other than that returned by a Store Clock instruction.
• +nnn – The number of days in advance to set the date relative to the current Store
Clock value.
• -nnn – The number of days backwards to set the date relative to the current Store
Clock value.
The + or - sign is required. The maximum number of days is 999.
• PHYSICAL – Instructs Ironstream to use the Physical Clock as returned by the
PTFF instruction using the Query TOD Offset function.
Along with the DATETIME header field, all SMF fields that report a date (in the
format YYYY-MM-DD) will have the date adjusted by the value specified in the
DATE_OFFSET parameter. The time of day value in any date/time field is not
modified.
SMF WHERE processing filters on the dates in the SMF fields. DATE_OFFSET is
applied to the formatted date as sent to the data repository; therefore, any WHERE
processing needs to be based on the original date stored in the SMF record.
"KEEP_ALIVE":"nnnn" - Optional parameter that manually specifies whether to keep a

TCP connection active on all PORTS definitions (in the DESTINATION section), even
during periods when there is no reportable Ironstream activity. You can define the
duration in seconds between keep-alive packets being sent between a range of 1-9999.
The default value is zero seconds, which disables keep-alive packets.
KEEP_ALIVE can be specified in the SYSTEM section and/or for each
"PORT":"value" definition in the DESTINATION section.
• When specified in this SYSTEM section, it sets a default value for all
"IPADDRESS"/"PORT" definitions. It must be the last SYSTEM parameter.
• When specified immediately following a "PORT" command, it will override any
default specified in the SYSTEM section for that PORT only. A command of
"KEEP_ALIVE":"0" following a "PORT" command, will disable the KEEP_ALIVE
function for that PORT.
For a configuration usage example, see “Using KEEP ALIVE at the SYSTEM and
PORT Level” on page 7-34.
"AUTO_RESTART":"YES" | "NO" - Optional parameter that causes Ironstream to

automatically restart a failing task. If the same task fails again in 10 seconds, no
additional automatic restarts are attempted and the task will be suspended. A
suspended task can be restarted using the RESTART command. If NO is selected, an
automatic restart will not be attempted and the task will be suspended.
The task can be restarted using the RESTART command, as described in “Ironstream
Commands,” on page 25-1.

"TERMINATE_ON_FAILURE":"NO" | "YES" - Optional parameter that instructs

Ironstream to not terminate if any subtask fails. By default, Ironstream will only stop
if instructed to by using the z/OS stop command to stop a forwarder. If YES is
selected, Ironstream will cancel any and all subtasks and terminate.
Note that TERMINATE_ON_FAILURE=YES is incompatible with
AUTO_RESTART=YES.

DESTINATION Section
The DESTINATION section describes where the Ironstream data is to be sent and how it is
to be forwarded.
For Splunk destinations, multiple indexers and ports can be specified by repeating the
IPADDRESS and associated parameters for each indexer and/or port. Since each indexer
and port are individually specified, a mix of TCP and TCP/SSL destinations may be
specified. All indexers addressed must be able to store data in the index_name specified by
the INDEX parameter.
Figure 7-1 provides a summary of all the possible parameters in DESTINATION section.
The following sections provide detailed explanations for each parameter.
Figure 7-1. Summary of all DESTINATION Parameters
"DESTINATION" Required section heading.

General Optional Parameters: Refer to “General DESTINATION Parameters”
"DOUBLEQ_NUMERIC":"NO|YES" on page 7-12.
"TARGET":"SPLUNK|ELASTIC|KAFKA"
"DATASTORESIZE":"nnnn"
"DATASTOREQUEUE":"nnnn"
"SOURCE":"DSNAME"
"SOURCETYPE":"ds_type"
"THROTTLING_RATE":"nnnn"
"RETRY_ON_START":"NO|YES"
"RETRY_ON_START_INTERVAL":"30|nnn"
"RETRY_ON_START_LIMIT":"10|nnn"
DLP Parameters:
"DATA_LOSS_PREVENTION":"NO|YES" Refer to “Data Loss Prevention Parameters” on
"DLP_STREAM_NAME":"value" page 7-13.
"AUX_SPACE_NAME":"SSDFAUX/
auxiliary_space_name"
"ACK_TIMEOUT_LIMIT":"60/nnnn"
"ACK_RETRY_LIMIT":"1/nn"
"DLP_COLD_START":"NO|YES"
Target Index Parameters: Refer to “Target Index Parameters” on page 7-14.

"INDEX":"value"
"TYPE":"TCP|HTTP|HTTPS"
"IPADDRESS":"value"
"PORT":"value"
"KEEP_ALIVE":"nnnn"
"TOKEN":"value"
"SSL":"YES|NO"
"SSL":"YES" Parameters: Refer to “SSL Enabled Parameters” on page 7-16.

"KEYRING":"keyring"
"PASSWORD":"password"
"STASH_FILE":"stash"
"CERTIFICATE":"label"

General DESTINATION Parameters

This set of general parameters must precede the Splunk-only DATA_LOSS_PREVENTION
or INDEX parameters, but can occur in any sequence before those parameters.
"DESTINATION" - The required section heading.
"DOUBLEQ_NUMERIC":"NO|YES" - Optional parameter for applying double quotes to all

numeric fields in the JSON output of SMF records. This parameter must be placed
directly before the TARGET parameter or it will produce an out-of-sequence error.
If DOUBLEQ_NUMERIC is not specified, the default of NO is used and numeric
fields will not be output in double quotes.
"TARGET": "SPLUNK|ELASTIC|KAFKA" - optional parameter that defines Splunk,

Elastic, or Kafka as the data target destination for this Ironstream instance. If a
target is not specified, the default value for TARGET is SPLUNK. For information
the supported target destinations, refer to:
• Chapter 3, “Setting Up Splunk for Ironstream”
• Chapter 4, “Setting Up Elastic for Ironstream”
• Chapter 5, “Setting Up Kafka for Ironstream”
"DATASTORESIZE":"nnnn" - Optional parameter that specifies the size of the data store
in megabytes. Valid range is 100–2000. The default value is a calculated value based
on the MAXUSER value in the IEASYSnn member of PARMLIB as 400K *
MAXUSER / 1M.
Important! For more information about correctly configuring size of the data store,
see “Data Store Filling or Full Condition” on page 26-2.
"DATASTOREQUEUE":"nnnn" - Optional parameter that specifies the number of

messages queued in the data store. Ironstream monitors the number of queued
messages once a minute. If the number of messages in the data store exceeds this
value, a SDF0126S message is issued. The default value is 1000, with a valid range of
15–32000.
Note: The Splunk-only SOURCE and SOURCETYPE parameters are optionally used to set
the Splunk source and sourcetype metadata fields. These metadata fields can only be set for
specific DATATYPES specified in the SOURCE section of the configuration file, as described
in “Subparameter Definitions for SOURCE Data Types” on page 7-20.
"SOURCE":"DSNAME" - Optional parameter that specifies the “source metadata” value

passed to Splunk when the Ironstream SOURCE data type is set to “FILELOAD”.
FILELOAD will use the data set name of the source file to set the “source metadata”
value passed to Splunk. Any other value will be flagged as an error, as will the use of
"SOURCE":"DSNAME" for any DATATYPE other than FILELOAD. The default
value is “syncsort”.
Note: If multiple files are concatenated under a single dd_name, all data will have
the data set name of the first data set as the "source_value". If each file is assigned a
separate dd_name, the data from each file will have the data set name from which
the data was read.

"SOURCETYPE":"ds_type" - Optional parameter that when set to “log4j”, specifies the

“sourcetype metadata” value passed to Splunk when the Ironstream SOURCE data
type is set to “LOG4J”. The default value is “syncsortMF”.
"THROTTLING_RATE":"nnnn" - Optional parameter that specifies a throttling rate value

to be enforced in KB/second. When multiple TCP connections are defined, the
specified rate is applied to each connection. Only one "THROTTLING_RATE"
parameter can be defined. If nnnn is 0 or the parameter is absent, no throttling cap
will be set and Ironstream transmits data as fast as the network allows.
"RETRY_ON_START": "NO" | "YES" - Optional parameter that when set to YES instructs
Ironstream to make multiple attempts to connect to the destination repository when
an Ironstream instance is starting up. The NO default means that Ironstream will
terminate when no connection is made upon start-up.
"RETRY_ON_START_INTERVAL": "30/nnnn" - Optional parameter that specifies the

number of seconds Ironstream will wait between attempts to connect. The minimum
time value is 5 seconds and the maximum value is 999 seconds
Note: Each connection attempt can take up to 30 seconds; therefore, when using the
default of 30 seconds there will appear to be 60 seconds between connection attempts.
"RETRY_ON_START_LIMIT": "10/nnnn" - Optional parameter that specifies the number

of start retry attempts Ironstream will perform. The minimum value is zero (0),
which instructs Ironstream there is no limit to the number of connection retry
attempts. The maximum value is 999 retry attempts.
Data Loss Prevention Parameters

The next set of Splunk-only parameters are used to configure the optional Data Loss
Prevention (DLP) feature, which prevents the loss of forwarded data due to extended
network or Splunk outages. The DLP parameters must immediately precede the INDEX
parameter.
Important! The SYSTEM-level IMPORT data parameter is not compatible with DLP.
Ironstream verifies whether both parameters are configured, and if true, message
SDF0190A is generated and the Ironstream instance is terminated.
For more information about configuring and using DLP for Splunk, see Chapter 10,
“Configuring Data Loss Prevention”.
"DATA_LOSS_PREVENTION": "NO" | "YES" - Specify YES to activate DLP. The default

is NO.
"DLP_STREAM_NAME":"stream_name" - Required DLP parameter that specifies the log

stream name defined in the coupling facility (up to 26 characters).
Note: When DLP is enabled, the next four parameters are optional if their default value
(underlined) is used. They cannot be specified for "DATA_LOSS_PREVENTION":"NO".

"AUX_SPACE_NAME":"SSDFAUX/auxiliary_space_name" - Optional DLP parameter

(depending on the Ironstream forwarder) that defines SSDFAUX as the default
auxiliary address space name that is started when SMF data is being captured via
system exits. You can also specify any name of up to eight characters as the name of
an auxiliary address space started using a PROC of the same name. This parameter
is optional when using the SSDFAUX default.
Additionally, the auxiliary address space is not used in the following situations:
• SMF data is not being collected. That is, Ironstream is collecting data using any
other forwarder with DLP.
• SMF data is being collected via the SMF real-time interface using the
"SMF_SOURCE":"INMEM" option, as explained in “SMF Subparameters”.
"ACK_TIMEOUT_LIMIT":"60/nnnn" - Optional DLP parameter that defines the number of

seconds Ironstream will wait for an acknowledgement message from the Splunk
indexer. If acknowledgement is not received within the time-out limit, Ironstream
will retry to send the data. The default is 60 seconds, but you can define the number
of seconds to wait for a response between a range of 1-9999.
This parameter is optional if the default of “60” seconds is used.
"ACK_RETRY_LIMIT":"1/nn" - Optional DLP parameter that defines the number of

attempts Ironstream will make to resend data to the Splunk Indexer before recording
the data as lost. You can define the number of retries between a range of 1-99. This
parameter is optional if the default of “1” retry is used.
A message can be resent to Splunk for two basic reasons:
• Ironstream does not receive a response in the time expected as defined by the
ACK_TIMEOUT_LIMIT value.
• Ironstream receives a negative acknowledgement back from the Splunk indexer.
Ironstream will print in SYSPRINT the contents of the data that is considered lost.
"DLP_COLD_START":"NO | YES" - Optional DLP parameter that determines whether

data is retained in the coupling facility’s log stream when Ironstream is restarted.
The default value NO means that any data currently in the log stream is retained.
Specifying YES will cause all data currently in the log stream to be deleted.
This parameter is optional if the default of NO is used.
Important! When DLP is enabled, the TYPE and TOKEN parameters described in “Target
Index Parameters” are DLP-related parameters. The TYPE parameter must immediately
follow the INDEX parameter, and TOKEN must immediately follow the IPADDRESS and
PORT parameters.
Target Index Parameters

These parameters are used to configure the Splunk index, the transmission protocol, the
location of the index via the IP address/port, and optional token and SSL parameters.

"INDEX":"index_name" - Required Splunk-only parameter that defines the name of the

Splunk index_name into which the data will be indexed.
Note: The USSDefaults group parameter settings in the DCE configuration file
overrides the mandatory Splunk INDEX parameter. Whereby, all offloaded USS data
is sent to the Splunk index specified in the USSDefaults group, unless that index is
overridden at the USS directory level. The USS configuration file also has an option
to override the SOURCETYPE parameter described below to set the Splunk
sourcetype metadata field to the path or filename of the USS files. For more
information, see “Configuring DCE for USS File Offload” on page 22-4.
"TYPE":"TCP | HTTP | HTTPS" - The required transmission protocol record.

Notes: If Splunk is using the Data Loss Prevention function, you must specify either
HTTP or HTTPS.
• TCP – The default, signifies that standard TCP protocol will be used.
• HTTP – Signifies that HTTP protocol will be used. See "TOKEN" parameter below.
When HTTP is specified, all Ironstream connections must specify "SSL":"NO" .
For Splunk indexes, SSL must also be disabled in Splunk’s global settings.
• HTTPS – Signifies that HTTP with SSL protocol will be used. See "TOKEN"
parameter below.
When HTTPS is specified, all Ironstream connections must specify "SSL":"YES".
For Splunk indexes, SSL must also be enabled in the Splunk’s global settings.
You can specify multiple groups of the following parameters that specify the location of the
target destination, but they must be defined in the sequence listed.
Using multiple indexers and ports can improve overall throughput and reliability.
Ironstream automatically detects which connections are the fastest and forwards more data
through those connections. Ironstream also automatically recovers from a connection failure
and re-forwards the data on an active TCP connection.
"IPADDRESS":"ipaddress" - Mandatory parameter that specifies the IP address (up to 36

characters) of a targeted destination.
"PORT": "port" - Mandatory parameter that specifies the port number on which the
targeted destination is listening. Any available and valid port number can be used.
"KEEP_ALIVE":"nnnn" - Optional parameter that manually specifies whether to keep a

TCP connection active on a specified PORT even during periods when there is no
reportable Ironstream activity. You can define the duration in seconds between
keep-alive packets being sent between a range of 1-9999. The default value is zero
seconds, which disables keep-alive packets.
When a KEEP_ALIVE value is specified immediately following a "PORT" parameter,
it will override any default specified in the SYSTEM section for that PORT only. A
command of "KEEP_ALIVE":"0" following a "PORT" command, will disable the
KEEP_ALIVE function for that PORT.

"TOKEN":"token_value" - If Data Loss Prevention is active, this required token_value is

the same value provided by Splunk when defining the HTTP or HTTPS port on the
Splunk indexer machine.
The token_value has the format of HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH.
Each PORT will have a unique token_value.
"SSL": "YES" | "NO" - Specify YES if SSL is active or NO if SSL is not active.
SSL Enabled Parameters

The following parameters are mandatory when "SSL":"YES" is specified and cannot be
specified for "SSL":"NO".
"KEYRING":"keyring" - keyring is the name of the user keyring file, such as

/u/sdf/mykey.kdb for environments with the OMVS gskssl security database; or
specify the digital certificate information for environments with a security product
such as RACF for example: sdf/SYSTEMSSL, where sdf is the owner of SYSTEMSSL,
which is the name of the RACF key data set.
If a key token is used, specify *TOKEN*/key token name; for example,
*TOKEN*/SYSTOKEN. *TOKEN* indicates that a key token is used; SYSTOKEN in the
example is the key token name.
"PASSWORD":"password" - password is the password for an OMVS keyring file. It can be

null ("") if STASH_FILE is specified for the OMVS keyring file. For a RACF-type
environment or for a key token, specify "" after the colon to signify a null value.
"STASH_FILE":"stash" - stash is the name of the stash file for an OMVS keyring file, such
as /u/sdf/mykey.sth. If a password is specified for the OMVS keyring file, this stash
value will be ignored and password will be used. For a RACF-type environment or for
a key token, specify "" after the colon to signify a null value.
"CERTIFICATE":"label" - label is the certificate label of the client End Entity certificate
that must be supplied when the destination server requires a client certificate; for
example, “CLSPLUNK” for Splunk servers. To complete the SSL configuration, the
client certificate must be signed by a CA certificate installed on the destination
server.
For more information about Splunk client certificates, refer to the descriptions of
“requireClientCert” in the “inputs.conf” section of the Splunk Admin Manual.
SOURCE Section
The SOURCE section specifies the data source that is being collected and sent to the target
destination specified in the DESTINATION section. Only one SOURCE section can be
specified because each Ironstream instance is dedicated to forwarding one specific data
source.
When the TRANSLATE_TABLE parameter is specified it defines a different EBCDIC to
ASCII translate table that Ironstream uses when forwarding data to a destination. All other
parameters are dependent on the specification of the DATATYPE parameter.

"SOURCE" - Mandatory parameter that identifies the start of the SOURCE section.
"TRANSLATE_TABLE":"table" - Optional parameter for providing the name of an

alternative EBCDIC to ASCII translate table module used when forwarding z/OS
data of all types to Splunk. By default the z/OS code page is assumed to be 037 and
the Splunk platform code page to be 437 module (SSDF0037).
Depending on whether you are forwarding data in JSON format or in raw data
format, Ironstream provides translation tables to properly convert new lines (NL)
and carriage returns (CR) in Splunk.
• For the “Remove ASCII Control Characters” format, use the SSDFAxxx modules
listed below. See Table 7-2 for a list of EBCDIC hex values that are not converted
into spaces.
• For raw data format, use the SSDUxxxx modules listed below. NL and CR are
translated to X'0A' (LF).
• For JSON format, use the SSDFxxxx modules listed below. NL and CR are
translated to X'20' (space).
The following modules are available:
Table 7-1: EBCDIC to ASCII Translate Modules
Remove ASCII Raw Data JSON Data

Control Characters Format Format z/OS Splunk
Format Module Module Module Code Page Code Page
SSDFA037 SSDU0037 SSDF0037 EBCDIC 037 ASCII 437
SSDFA047 SSDU1047 SSDF1047 EBCDIC 1047 ASCII 437
SSDFA500 SSDU0500 SSDF0500 EBCDIC 500/1148 ASCII 437
SSDFA141 SSDU1141 SSDF1141 EBCDIC 273/1141 ASCII 437
You can create your own translate tables and add them to a library in the SDFxxx
STEPLIB concatenation using a member name of the format SSDFUxxx. The module
must be 256 bytes in size. Reminder: All libraries in the concatenation must be
APF-authorized.
For example, if your system’s code page is EBCDIC 273 or 1141, add
"TRANSLATE_TABLE":"SSDF1141" to your configuration’s SOURCE section.
If your system’s code page is EBCDIC 1141 or 1148, and you would like to display "€"
correctly in Splunk, set CHARSET=ISO8859-15 in the Splunk props.conf file. Refer
to the Splunk documentation for instructions on how to set CHARSET.

Unconverted EBCDIC Hex Values When Using “Remove ASCII Control Characters”
Format Module
The following EBCDIC hex values are the only values that are not converted into spaces.
Table 7-2: Unconverted EDBCDIC Hex Values
EBCDIC Hex Value Description

40 ( ) space
4B-4F (.<(+|) period, less than, open (left) parenthesis,
plus sign, vertical line
50 (&) ampersand
5A-5F (!$*);) exclamation mark, dollar, asterisk, close
(right) parenthesis, semicolon
60-61 (-/) dash, slash
6B-6F (,_%>?) comma, underscore, percent, greater than,
question mark
79-7F (`:#@'=") grave accent, colon, hash, at sign, single
quote, equal sign, double quote
81-89 (a-i)
91-99 (j-r)
A1 (~) tilde or swung dash
A2-A9 (s-z)
B0 (^) up caret
BA ([) open square bracket
BB (]) close square bracket
C0 ({) open curly bracket
C1-C9 (A-I)
D0 (}) close curly bracket
D1-D9 (J-R)
E2-E9 (S-Z)
F0-F9 (0-9)

"DATATYPE":"DB2TRIGGER | SYSLOG | SMF | SYSOUT | LOG4J | XCF

| FILELOAD | RACF | IRONSTREAM_API | SYSTEMSTATE | IMSLOG" -
Mandatory parameter that specifies the type of data to be forwarded. Only one such
parameter may be specified for an Ironstream instance. The additional
subparameters that apply to each of the data sources are described in “Subparameter
Definitions for SOURCE Data Types” on page 7-20.
Table 7-3: SOURCE Data Types
Name Definition
DB2TRIGGER Specify DB2TRIGGER to capture and forward messages
generated by a DB2 trigger procedure driving a DB2 Stored
Procedure.
See “DB2TRIGGER Subparameters” on page 7-20.
SYSLOG Specify SYSLOG to capture and forward messages sent to syslog.
See “SYSLOG Subparameters” on page 7-20.
SMF Specify SMF to capture and forward any supported SMF records.
See “SMF Subparameters” on page 7-21.
SYSOUT Specify SYSOUT to forward spool data sets from active or
completed jobs to a destination.
See “SYSOUT Subparameters” on page 7-25.
LOG4J Specify LOG4J to capture and forward messages from log4j
processes sent to z/OS.
See “LOG4J Subparameters” on page 7-24.
XCF Specify XCF to capture USS files and file updates, as well as RMF
III DDS metrics. XCF is also specified if you intend to forward
alerts and/or SyslogD data from the ZEN Network Monitoring
components to a destination.
See “XCF Subparameters” on page 7-25.
FILELOAD Specify FILELOAD to read and transmit sequential records from
DD statements defined by the FILELOAD parameter in the
(“SYSTEM Section” on page 7-7).
See “Batching FILELOAD Data” on page 16-3.
RACF Specify RACF to read and transmit an unloaded RACF database
from the DD statement defined by the RACFLOAD parameter in
the SYSTEM section (page 8). Ironstream processes the unloaded
RACF database and forwards each record to a destination
formatted as name pairs (JSON format) and then shuts down.
IRONSTREAM_API Specify IRONSTREAM_API to create user-defined data to send to
one or more Ironstream instances to forward on to a destination.
See “IRONSTREAM_API Subparameters” on page 7-26.

Table 7-3: SOURCE Data Types
Name Definition
SYSTEMSTATE Specify SYSTEMSTATE to generate z/OS system-level metrics
data to forward to a destination.
There are no required parameters for SYSTEMSTATE. See
“System State Forwarding” on page 17-1 for a description of all
the generated data elements.
IMSLOG Specify IMSLOG to capture and forward any supported IMS
record logs.
See “IMS Subparameters” on page 7-27.
Subparameter Definitions for SOURCE Data Types

This section describes the additional subparameters for the SOURCE data types that
require additional configuration. Certain data types, like RACF and SYSTEMSTATE, do not
require further configuration, and so are not listed in this section.
DB2TRIGGER Subparameters
An Ironstream instance must be active to receive the DB2 data from the Stored Procedure
program.
"DB2TOKEN":"token" - Optional parameter that specifies a user-defined token that must

be 16 bytes long. It can be any combination of letters, numbers or symbols. This token
must match the value that you specify in your DB2 trigger. Multiple DB2TOKEN
parameters can be specified to match multiple individual tokens for each DB2
trigger. Alternatively, the same token can be used by multiple DB2 triggers.
Each token specified must be unique both within an Ironstream instance and across
all Ironstream instances on an LPAR. If a duplicate is discovered, message
SDF0139A is issued.
For details about DB2 table data forwarding, refer to Chapter 15, “DB2 Data Forwarding”.
SYSLOG Subparameters
In addition to the parameters required when selecting syslog records for forwarding, you
must also filter syslog messages by application, or any defined 3 or 4-character message
prefix. Otherwise, you may be forwarding far more messages than you actually require. The
filter module name is specified using the FILTER subparameter. For more details about the
syslog filtering facility and examples, see Chapter 11, “Syslog Message Filtering”.
"SCOPE":"scope" - This optional parameter enables you to select the scope of syslog
message forwarding, either sysplex-wide, or local to the LPAR on which Ironstream is
running. Valid settings for scope are SYSPLEX, which is the default value when the
parameter is omitted, or LOCAL.

In SYSPLEX mode only one Ironstream instance per sysplex should be started which
will process syslog messages for all LPARs in the sysplex. When LOCAL is specified,
an Ironstream instance is required for each LPAR in the sysplex, and each instance
will only process syslog messages for the LPAR in which Ironstream is active. Note
that each instance requires a unique NAME value in the SYSTEM section of the
configuration member.
"HARDCOPY":"NO | YES" - Optional parameter that can be used to cause Ironstream to

capture and forward all HARDCOPY messages to a destination. Specify YES for this
parameter to forward HARDCOPY messages. When NO is specified HARDCOPY
messages are not selected for forwarding which is also the default when this
parameter is omitted.
"ROUTCDE":"rout_cde" - Optional parameter that specifies the route code for syslog
gathering. Individual codes or ranges of codes can be specified. Codes can be repeated
and can overlap, but a range specification must be in low to high sequence, for
example: "1,2,3-96". The default is 1-96.
"FILTER":"filter_module" - Mandatory parameter that defines the 1 to 8-character name

of your filter module for syslog message filtering. See the section “Syslog Message
Filtering” on page 11-2 for full details.
"LINE_BREAK":"YES | NO" - Optional parameter that specifies whether to add the \n

(new line) character at the end of each line of a multi-line message. A line break
makes a multi-line message appear in a query in the same format that it would on an
operator console. The default is YES, which is the existing Ironstream behavior.
When NO is specified, Ironstream suppresses the addition of the \n character and
multi-line messages appear as a single string of contiguous characters.
SMF Subparameters
These parameters are required when you select SMF records for forwarding to a destination.
You can control how much information is forwarded to a destination, by selecting specific
fields within an SMF record and subtype. Field-level filtering is accomplished by using the
SUBTYPE and INCLUDE parameters for the SMF record specified in SELECT.
For a detailed description of how to filter SMF records, along with some sample
configurations, see Chapter 12, “SMF Record Filtering”.
Note: A running Ironstream instance collecting SMF records can have its existing SOURCE
configuration parameters dynamically modified without having to stop and restart it. This
includes switching from a currently-configured SMF record type to another SMF type,
changing/adding the subtypes, and tuning the SMF filtering parameters, such as INCLUDE
and WHERE. Such dynamic reconfiguration alleviates the need to stop running tasks,
thereby preventing the loss of records by eliminating unnecessary downtime while gathering
SMF data. For more information, see Chapter 9, “Dynamically Modifying a Running
Ironstream Configuration”.
"SECURITY_PRODUCT":"SYSTEM | RACF | ACF2 | TS" - Optional parameter that

specifies which security system is being used with Ironstream.

• SYSTEM – The default. Use the security product running on the z/OS system.
• RACF – Process SMF Type 80 RACF data.
• ACF2 – Process SMT Type 230 ACF2 data (same as RACF).
• TS – Process SMF Type 80 “Top Secret” data.
"SMF_SOURCE":"EXIT | INMEM" - Optional parameter that specifies how Ironstream

captures SMF records. The default is EXIT, the existing Ironstream behavior, which
means records are captured via the SMF system exits IEFU83/IEFU84/IEFU85.
Detailed instructions for defining the required z/OS SMF record exits are in the
Ironstream Program Directory.
When INMEM is specified, Ironstream captures records via the SMF real-time
interface. When Ironstream is selecting SMF records via the SMF real-time interface,
INMEM resource names defined to SMF log streams are acquired dynamically.
Ironstream will retrieve the names from SMF, ensure security access, ensure no
duplicate SMF types are captured, connect to the INMEM resource, and retrieve
records. All information is reported via SDF71xx messages in SYSPRINT. Ironstream
commands for INMEM are described in Chapter 25, “Ironstream Commands”.
Note: INMEM requires an IBM coupling facility log stream to use the SMF real-time
interface. Ironstream recommends using INMEM if possible, but it is not required.
"INMEM_RESOURCE":"<logstream>" - Optional SMF INMEM parameter for providing a

log stream name to Ironstream that is not yet available in SMF, where <logstream>
is the name of the placeholder log stream. The SMF_SOURCE parameter must be set
to INMEM to specify an Ironstream <logstream>. This log stream can be defined and
used at a later date for Ironstream to use.
Important! Per PTF TYF3339, this parameter is recognized but is no longer
supported. If it is detected in the configuration file, Ironstream will issue message
SDF0194I and continue processing. It should be removed from the configuration file.
"INMEM_DEBUG":"NO | YES" - Optional SMF INMEM parameter that should not be

used except when directed by Syncsort Technical Support.
"VERSION":"Z/OS(vv.rr.nn)" - Optional parameter that enables forwarding SMF record

events that are sensitive to the creation level of the operating system (z/OS) on which
Ironstream is running. By default, Ironstream uses routines that create JSON events
at the level of the z/OS on which Ironstream is currently executing. When using the
SMF offline loader facility ("IMPORT":"ON"), the version of the input file may be
different than the version of the z/OS on which Ironstream is running.
To ensure accurate values of the JSON name/value pairs in SMF fields, VERSION
can override the default z/OS level used to create the JSON name/value pairs. This
parameter ensures forwarding SMF record events that match the level of the z/OS
that created the input data set. The supported syntax for z/OS(vv.rr.mm) is:
"Z/OS(01.13.00)"
"Z/OS(02.01.00)"
"Z/OS(02.02.00)"
"Z/OS(02.03.00)"
where vv is the version, rr is the release level, and mm is the modification level.

This command lists active modules in the JPA CDE chain by way of message
SDF0831I: F <Ironstream jobname>,LIST=MODULES
For more information about the LIST=MODULES command, refer to Chapter 25,
“Ironstream Commands”.
"SELECT":"SMFnnn" - Mandatory parameter that identifies one or more SMF record types
to collect. The SMFnnn value is a decimal number, with or without leading zeros, of
one or more SMF record types to collect. If multiple record types are specified, no
SUBTYPE or INCLUDE options are permitted for those record types.
"DATA_FORMAT":"SMF_type:<alternate_format_number>" - Optional parameter that

tells Ironstream to use an alternate SMF record formatting routine (if available) for
processing the SMF records instead of using the default format. The parameter
comprises a SELECTed SMF record number (nnnn valued in the range 0-2047) and
the alternate formatting routine number. The colon identifies the end of the SMF
number and the start of the alternate routine number.
For example, the SMF 116 record type could be entered in the configuration file as
follows:
"DATATYPE":"SMF"
"SELECT":"SMF116"
"DATA_FORMAT":"116:1"
DATA_FORMAT can appear anywhere in the configuration file after the
"DATATYPE":"SMF" parameter.
Note: In the current release, this parameter is only supported for SMF type 116 for
WebSphere MQ Accounting Data, which has an alternate format routine of “1”. The
default format of “0” puts all MQ queue names in one created JSON event (the SMF
field name is BASENAME and appears in Splunk as BASENAME_nnnn). Whereas,
the alternate format creates a separate JSON event for each queue named in the
SMF record.
"SUBTYPE":"nn" - Optional parameter that identifies one or more subtypes to be collected

for the specified SMF record. The nn value is a decimal number that identifies one or
more record subtypes as a comma separated list. If the SUBTYPE parameter is
omitted, all subtypes are collected.
"INCLUDE":"ALL | field_list" - Optional parameter that identifies the fields to be

collected for the specified SMF record and SUBTYPE(s). If the default ALL is
specified, it must be the only value. When specific fields are to be selected, they are
specified as a comma separated list. Any number of names can be specified in a field
list. A comma or the closing double quote (") defines the end of a name.
For example:
"SELECT":"SMFnnn"
"INCLUDE":"FIELD1,FIELD2,FIELD3"
The Ironstream standards for continuation are observed. The limit for continuation is
2048 characters, which can be twenty-eight 71-character records, or around 255 fields
of eight bytes and a comma. For more information about Ironstream’s command
continuation methods, see “General Syntax Rules” on page 7-3.

"WHERE":"Where_clause" - Optional parameter that enables you to specify a set of field

search conditions to select SMF records for forwarding when the search conditions
are met. Only a single WHERE statement is permitted per SMF record type. WHERE
statements are not required to be part of an INCLUDE statement.
Multiple search conditions are separated by AND or OR operators and are evaluated
from left to right. The basic syntax has the form of:
"WHERE":"search_condition [AND/OR search_condition]"
For a detailed explanation of WHERE syntax options, see “Limiting SMF Record
Selection with WHERE Search Conditions” on page 12-7.
LOG4J Subparameters
To forward log4j data to a destination requires changes to both your log4j configuration file
and the definition of appropriate parameters in Ironstream. For full details of how to set up
this facility see also Chapter 19, “Setting Up Log4j”.
"NAMEDPIPE":"pipe" - Mandatory parameter that specifies the name of the path that the
Ironstream’s Log4j Appender, SDFAppender or SDF2Appender, is using to send log4j
records to Ironstream. It must be a valid absolute path name for USS, for example:
/tmp/.mfsplunk or /tmp/afile. Relative pathnames are not supported.
Subparameters for the Offline Reader Facility

The following set of log4j subparameters are optional and all apply only if you intend to use
the Offline Log4j Reader Facility. You can skip the remainder of this section if you do not
intend to take advantage of this facility. See Chapter 19, “Setting Up Log4j”.
"JAVAHOME":"javahome" - Specifies the location of the IBM JAVA SDK for z/OS which
the Offline Log4j Reader Facility requires to read log data and parse information.
The SDK is usually installed in the OMVS directory /usr/lpp/java.
Enter the UNIX command: ‘ls /usr/lpp/java’ to determine whether the SDK is
installed there. The installed releases of the SDK will be displayed. If J6.0 is
displayed for example, then the SDK 8 version is installed under directory
/usr/lpp/java/J8.0. In this case, you would specify /usr/lpp/java/J8.0 for the
javahome keyword value.
"JAVA64BIT":"NO" |"YES" - Specifies the address mode of the IBM JAVA SDK for z/OS.
Specify YES for 64-bit JAVA, or NO for 31-bit JAVA. The default when this
parameter is omitted is NO.
"SDFHOME":"/your_directory/lib" - Specifies the pathname of the Ironstream jar files

(and should be the same as the pathname you specified in your CLASSPATH). It
must be a valid absolute path name for USS. A relative pathname is not supported.
"FILENAME":"your_log_file" - Specifies the name (or DD) of the log file(s). For a log4j log
file or USS log file under OMVS, it can be a valid absolute path name for USS, for
example, "/tmp/logfile1". If the log file is a z/OS data set or a member of a z/OS data
set, "//X.Y.Z" or "//X.Y.Z(M)" can be used. "//DD:ddname" can also be used for multiple
log files.

"TIMESTAMP":"your_timestamp" - Optional parameter that is required only when the

date/time field of the log records is not in the default log4j date/time format. The
default log4j date/time format is: "yyyy-MM-dd HH:mm:ss,SSS". The TIMESTAMP
parameter accepts the same syntax as the time pattern string of the
java.text.SimpleDateFormat, for example,
"dd MMM yyyy HH:mm:ss", "yyMMddHHmmssZ", or "EEE, MMM d, yy"
"PATTERN":"pattern" - Optional parameter that is required only when the first field of the
log record is not a date/time field. When PATTERN is specified, the TIMESTAMP
parameter must be specified even if date/time is in the default log4j format. For
instructions on constructing the PATTERN keywords, see “How to use PATTERN in
the Log4j Reader Facility” on page 19-4.
SYSOUT Subparameters
You can specify one or more SELECT and FILTER parameters following a specification of
SYSOUT for the DATATYPE to control the selection of files; further parameters are
available to manage the way in which the lines and blocks of data are formed and forwarded.
For full details of all available parameters and a description of this facility, see Chapter 13,
“SYSOUT Forwarding”.
The basic parameters required for SYSOUT forwarding are:
"SELECT_JOB_IF_job_keyword":"job_keyword_value"
"SELECT_DATA_SET_IN_JOB_WITH_data_set_keyword":"data_set_keyword_value"
"FILTER_JOB_ON_filter_keyword":"filter_keyword_value"
"PRINT_MODE":"print_mode
"PRINT_WRAP":"print_wrap"
"PRINT_SEND":"print_send"
"SYSOUT_NEW_JOB_SCAN_WAIT_TIME":"nnnnn"
"SYSOUT_NEW_OUTPUT_SCAN_WAIT_TIME":"nnnnn"
"EXCLUDE_JOB_IF_JOBNAME":"<jobname1>,<jobname2>,…<jobname8>"
"EXCLUDE_JOB_WHEN_OUTCLASS":"<outclass1>,<outclass2>,…<outclass8>"
This set of parameters is only available when using a data type of SYSOUT. The first three
parameters together specify the criteria by which data sets are selected for forwarding to a
destination. The last three parameters are concerned with the way the lines and blocks of
data are formed and forwarded to a destination. For details of these parameters see Chapter
13, “SYSOUT Forwarding”.
XCF Subparameters
Cross System Coupling Facility (XCF) parameters are specified in the Data Collection
Extension (DCE) configuration to capture USS files and file updates, and when collecting
RMF III metrics. For more information on correctly configuring the XCF parameters for the
DCE data types, see “DCE, IDT, and XCF Configuration Considerations” on page 6-8.
The XCF parameters are also relevant when you plan to use one or more Network
Monitoring components (NMC) to forward alerts and/or SyslogD data via Ironstream to a
destination; this facility also requires some configuration in the Ironstream Desktop (IDT).
For more information, see “Alerts and SyslogD Forwarding” on page 14-1.

When you use the XCF data type, you must specify the XCFGROUP and XCFMEMBER
parameters that together specify the XCF group and member name that this instance of
Ironstream will join.
"XCFGROUP":"XCF_groupname" - Must be a maximum 8 characters long; valid

characters are A-Z, 0-9, $, #, and @. To avoid using the names IBM uses for its XCF
groups, do not begin group names with the letters A through I or the character string
SYS. Also, do not use the name UNDESIG, which is reserved.
"XCFMEMBER":"XCF_membername" - Must be a maximum eight characters long; valid

characters are A-Z, 0-9, $, #, and @.
XCF is the mechanism used by Ironstream to forward alerts and SyslogD data from
ZEN components to a destination. It follows that a corresponding
Ironstream XCF-groupname XCF-membername
parameter should also be specified in the DCE configuration for USS files RMF III
metrics, as well as in the ZEN configuration file for NMC to forward alerts and/or
SyslogD data.
IRONSTREAM_API Subparameters
These parameters are required when you plan to use the Ironstream API to create
user-defined EBCDIC or ASCII data to send to a destination. When you use this data type you
must also specify the XCFGROUP, XCFMEMBER, and CLASS parameters. For more
information, see Chapter 18, “Configuring and Using the Ironstream API”.
These parameters are specified when using a data type of IRONSTREAM_API and together
specify the XCF group and member name that this instance of Ironstream will join. You can
also categorize the collected data by CLASS, and optionally by TYPE and SUBTYPE.
"XCFGROUP":"XCF_groupname" - Mandatory parameter that is a user-defined XCF

group name that is common to a set of Ironstream instances. It must be a maximum 8
characters long; valid characters are A–Z, 0–9, $, #, and @. To avoid using the names
IBM uses for its XCF groups, do not begin group names with the letters A–I or the
character string SYS. Also, do not use the name UNDESIG, which is reserved.
"XCFMEMBER":"XCF_membername" - Mandatory parameter that is a unique

user-defined member name for each Ironstream instance. It must be a maximum 16
characters long; valid characters are A–Z, 0–9, $, #, and @.
"CLASS":"nnn" - Mandatory parameter that defines at least one CLASS entry. The nnn
value can be any value in the range of 128–255. Values in the range of 1–127 are
reserved for use by Ironstream.
"TYPE":"ttt" - Optional parameter that defines one or more TYPE entries under a "CLASS"
entry. The ttt value can be any value in the range of 0–255.
"SUBTYPE":"sss" - Optional parameter that defines one or more SUBTYPE entries under a
"TYPE" entry. The sss value can be any value in the range of 0–255.

IMS Subparameters
These parameters are required when you select IMS log records for forwarding to a
destination. For more information, see Chapter 20, “IMS Log Record Forwarding”.
"IMS_SYSTEM_ID":"ims-id" - Mandatory parameter that defines the value used to

populate the "IMSID" JSON pair. You must use a different value for the Ironstream
[SYSTEM] "NAME" parameter than value being used for the "ims-id".
"CATEGORY":"ims_record-category" - Mandatory parameter that defines the level of

data you want to gather by entering the supported IMS record categories, such as
MTOMSG, SYSSTAT, TRANSTAT, and TRANDET.
Typical Ironstream Parameters

Typical parameters for a TCP non-SSL member are displayed below:
Figure 7-2. Typical Parameters for a TCP Non-SSL Member
"KEYS"
"KEY_WARN_DAYS":"value" (optional)
"KEY":"value"
"SYSTEM"
"NAME":"value"
"LOADLIB":"value" (optional)
"DESTINATION"
"INDEX":"value"
"TYPE":"TCP"
"IPADDRESS":"value" (see Load Balancing and Reliability section)

"PORT":"value"
"SSL":"NO"
"IPADDRESS":"value" (repeat these lines for multiple connections)

"PORT":"value"
"SSL":"NO"
"SOURCE"
"DATATYPE":"value"
"SCOPE":"value" (optional,for syslog)
"FILTER":"value" (for syslog)
"SELECT":"value" (for SMF)
"NAMEDPIPE":"value" (for Log4j)
"TRANSLATE_TABLE":"value" (optional)

Typical parameters for a TCP SSL member are displayed below:
Figure 7-3. Typical Parameters for a TCP SSL Member
"KEYS"
"KEY_WARN_DAYS":"value" (optional)
"KEY":"value"
"SYSTEM"
"NAME":"value"
"LOADLIB":"value" (optional)
"DESTINATION"
"INDEX":"value"
"TYPE":"TCP"
"IPADDRESS":"value"
"PORT":"value"
"SSL":"YES"
"KEYRING":"value"
"PASSWORD":"value"
"STASH_FILE":"value"
"CERTIFICATE":"value"
"IPADDRESS":"value" (repeat these lines for multiple connections)

"PORT":"value"
"SSL":"YES"
"KEYRING":"value"
"PASSWORD":"value"
"STASH_FILE":"value"
"CERTIFICATE":"value"
"SOURCE"
"DATATYPE":"value"
"SCOPE":"value" (optional,for syslog)
"FILTER":"value" (for syslog)
"SELECT":"value" (for SMF)
"NAMEDPIPE":"value" (for Log4j)
"TRANSLATE_TABLE":"value" (optional)

Configuration File Examples

Note that blank lines and comments in these examples are for readability only and none are
required. Each section header and each "name":"value" pair must start on a separate record.
Provided configurations have a unique "NAME":"xxxx" specified, they may be run
concurrently.
Forwarding SMF Data (Single Indexer)

This configuration is collecting SMF data and sending it to a Splunk index called zsmf using
a single indexer with a TCP connection. It is using two SELECT statements: the first
statement collects all SMF fields for the specified record types; whereas, the second SELECT
statement collects only the specified field-level data for subtypes 4 and 5, and in the WHERE
statement, the JOBNAME is checked for starting with either TST (test) or PRD (production) in
order to be included.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SDF"
"DESTINATION"
"INDEX":"zsmf"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9999"
"SSL":"NO"
"SOURCE"
"DATATYPE":"SMF"
"SELECT":"SMF14,SMF15,SMF50,SMF80,SMF101,SMF110"
"SELECT":"SMF30"
"SUBTYPE":"4,5"
"INCLUDE":"SMF30JBN,SMF30STN,SMF30CPT,SMF30CPS,
SMF30_TIME_ON_ZIIP,SMF30_TIME_zIIP_ON_CP"
"WHERE":"SMF30JBN EQ 'TST*' OR SMF30JBN EQ 'PRD*'"
Note: For reliability and scalability purposes, the use of a single connection is not
recommended.

Forwarding Syslog Data using SSL (Two Indexers)

This configuration is collecting syslog data and sending it to a Splunk index called zsyslog
using two indexers with TCP/SSL connections. It is using a filter called SSDFFLOG.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD1"
"DESTINATION"
"INDEX":"zsyslog"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9997"
"SSL":"YES"
"KEYRING":"/u/sdf/mykey.kdb"
"PASSWORD":"MyKey"
"STASH_FILE":""
"CERTIFICATE":"CASPLUNK1"
"IPADDRESS":"192.168.1.2"
"PORT":"9998"
"SSL":"YES"
"PASSWORD":"MyKey"
"STASH_FILE":""
"SOURCE"
"DATATYPE":"SYSLOG"
"FILTER":"SSDFFLOG"
Forwarding Log4j Data (Single Indexer)

This configuration is collecting log4j data and sending it to a Splunk index called zlindex
using a single TCP connection. There is no filter, but the NAMEDPIPE parameter is
required. The configuration is exactly same for Log4j 1.n and Log4j 2.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD2"
"DESTINATION"
"INDEX":"zlindex"
"TYPE":"TCP"
"IPADDRESS":"192.168.2.114"
"PORT":"10007"
"SSL":"NO"
"SOURCE"
"DATATYPE":"LOG4J"
"NAMEDPIPE":"/tmp/.mfxsplunk"

Offline Ingestion of SMF Data (Single Indexer)

This configuration is comparable to the first SMF example except that offline data ingestion
is used and the z/OS version is specified.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SDF2"
"IMPORT":"ON"
"START DATE":"01/01/2014"
"START TIME":"00:00:00.00"
"END DATE":"01/31/2014"
"END TIME":"23:59:59.99"
"DESTINATION"
"INDEX":"zsmf"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9999"
"SSL":"NO"
"SOURCE"
"DATATYPE":"SMF"
"VERSION":"Z/OS(02.03.00)"
"SELECT":"SMF14,SMF15,SMF50,SMF80,SMF101,SMF110"
"SELECT":"SMF30"
"SUBTYPE":"4,5"
Offline Ingestion of Log4j Data (Single Indexer)

This configuration is comparable to the earlier log4j example except that offline data
ingestion is used, the date/time field of the log record is the first field and the date/time
format is the log4j default.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD3"
"IMPORT":"ON"
"START DATE":"2014-09-25"
"START TIME":"14:04:32,383"
"END DATE":"2014-09-25"
"END TIME":"16:24:32,471"
"DESTINATION"
"INDEX":"log4jtst"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9999"
"SSL":"NO"

"SOURCE"
"DATATYPE":"LOG4J"
"JAVA64BIT":"NO"
"SDFHOME":"/u/wwczxl/ssdfrec"
"FILENAME":"file:/u/wwczxl/ssdfrec/logfiledefault.log"
Offline Ingestion of Log4j Data from a z/OS Data Set

This configuration is comparable to the previous example except that the log file is a z/OS
data set and the date/time format is not the log4j default.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD4"
"IMPORT":"ON"
"START DATE":"2014-09-25"
"START TIME":"14:04:32,383"
"END DATE":"2014-09-25"
"END TIME":"16:24:32,471"
"DESTINATION"
"INDEX":"log4jtst"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9999"
"SSL":"NO"
"SOURCE"
"DATATYPE":"LOG4J"
"JAVA64BIT":"NO"
"FILENAME":"//'WWCZXL.LOGSIMP'"
"TIMESTAMP":"EEE, d MMM yyyy HH:mm:ss Z"
Offline Ingestion of Log4j Data using PATTERN

This configuration is also similar to earlier log4j examples, except that in this case the
date/time field of the log record is not the first field. The PATTERN parameter is used.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD5"
"IMPORT":"ON"
"START DATE":"2014-09-25"
"START TIME":"14:04:32,383"
"END DATE":"2014-09-25"
"END TIME":"16:24:32,471"

"DESTINATION"
"INDEX":"log4jtst"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9999"
"SSL":"NO"
"SOURCE"
"DATATYPE":"LOG4J"
"JAVA64BIT":"NO"
"FILENAME":"//'WWCZXL.LOGSIMP'"
"TIMESTAMP":"EEE, d MMM yyyy HH:mm:ss Z"
"PATTERN":"LEVEL TIMESTAMP MESSAGE"
Forwarding Syslog Data using SSL and Translate Table

This configuration is comparable to the second example except that the z/OS system has
code page EBCDIC 1141.
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD6"
"DESTINATION"
"INDEX":"zsyslog"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9997"
"SSL":"YES"
"PASSWORD":"MyKey"
"STASH_FILE":""
"IPADDRESS":"192.168.1.2"
"PORT":"9998"
"SSL":"YES"
"PASSWORD":"MyKey"
"STASH_FILE":""
"SOURCE"
"DATATYPE":"SYSLOG"
"FILTER":"MSG001"
"TRANSLATE_TABLE":"SSDF1141"

Using KEEP ALIVE at the SYSTEM and PORT Level

KEEP_ALIVE is valid as the last [SYSTEM] section command or immediately following the
"PORT" command. Here are some usage examples:
[SYSTEM]
"NAME":"value"
"LOADLIB":"value"
"KEEP_ALIVE":"350" > Default value when KEEP_ALIVE is not specified for any PORT
[DESTINATION]
"INDEX":"value"
"TYPE":"TCP"
"IPADDRESS":"value"
"PORT":"value"
"KEEP_ALIVE":"100" > Applies only to this IP/PORT
"SSL":"NO"
"IPADDRESS":"value"
"PORT":"value"
"KEEP_ALIVE":"260" > Applies only to this IP/PORT
"SSL":"NO"
"IPADDRESS":"value"
"PORT":"value"
"KEEP_ALIVE":"0" > KEEP_ALIVE turned off for this IP/PORT
"SSL":"NO"
"IPADDRESS":"value"
"PORT":"value"
"SSL":"NO" > Use the System KEEP_ALIVE - not specified for this IP/PORT

Chapter 8 Controlling Ironstream
Components
This chapter contains instructions for starting and stopping the basic Ironstream data type
forwarders, like SMF and Syslog, as well as for the IDT, DCE, and NMC components:
Topics:
• “Controlling Ironstream Forwarders” on page 8-1
• “Controlling the Ironstream Desktop (IDT)” on page 8-3
• “Controlling the Data Collection Extension (DCE)” on page 8-4
• “Controlling the Network Monitoring Components (NMC)” on page 8-7
Controlling Ironstream Forwarders

The Ironstream load library your_hlq.SSDFAUTH must be authorized. Forwarders should
run as started tasks and should be in a WLM authorized performance group that is higher
than TSO and batch.
Starting Ironstream Forwarders

Except for IRONSTREAM_API instances, there are no start-up parameters and a forwarder is
initiated with the regular z/OS start command, as follows:
S sdffwd
For example, to start an SMF forwarder, use this command:
S SDFSMF
Similar commands should be used for the other basic Ironstream data types:
• SYSLOG = SDFLOG
• SYSOUT = SDFOUT
• NMC = SDFNMC
• LOG4J = SDFLOG4J

Controlling Ironstream Components
Starting an Ironstream API Forwarder

When starting Ironstream API instances ("DATATYPE":"IRONSTREAM_API"), you must use
the following command:
S SDFAPI,REUSASID=YES
Important! Failing to use the REUSASID=YES parameter when starting Ironstream API
instances can cause address spaces to become marked as non-reusable and, in extreme
cases, can require an IPL of the system if Ironstream API instances are started and stopped
multiple times. This parameter is not required for any other type of Ironstream forwarder.
Stopping Ironstream Forwarders

Use the z/OS stop command to stop a forwarder:
P sdffwd
For example, to stop an SMF forwarder, use this command:
P SDFSMF
Checking Ironstream Forwarder Status

There is a forwarder command that issues status information with the z/OS modify
command:
F sdffwd,STATUS
The SDF0601I message in Figure 8-1 that precedes the remaining responses to the STATUS
command is not written to the requesting console.
Figure 8-1. Example STATUS Output
SDF0601I OPERATOR REQUESTED STATISTICS AT TIME - 18:13:10.76 DATE - 2/02/2017

SDF0400I PERFORMANCE STATISTICS
SDF0401I TASK NAME TCB TIME MESSAGES IN MESSAGES OUT MAX RECORD LENGTH
SDF0402I MASTER 0.009693 N/A N/A N/A
SDF0402I GATH0001 0.002197 1036 159 N/A
SDF0402I EXTR0001 0.007816 159 159 32902
SDF0402I USAG0001 0.000201 N/A 1
SDF0403I SPLUNK INDEX NAME TCP TIME
SDF0404I SMF014 0.001219
SDF0405I IP ADDRESS PORT STATUS RECORDS TOTAL BYTES
SDF0406I --------------- ----- ------------ --------------- ----------------
SDF0407I 172.30.40.126 10010 CONNECTED 42 149340
SDF0407I 172.30.40.126 10009 CONNECTED 49 167298
SDF0407I 172.30.40.126 10008 CONNECTED 46 158638
SDF0407I 172.30.40.126 10007 CONNECTED 22 101338
SDF0406I --------------- ----- ------------ --------------- -----------------
SDF0408I TOTALS 159 576614

Controlling the Ironstream Desktop (IDT)

IDT provides Ironstream administration capabilities. There are two components that make
up IDT:
• A z/OS started task
• A browser-based GUI
IDT controls the alerts produced by the NMC components, provides SMF field-level filtering
capability, and is an essential part of DCE for setting RMF filters and defining filters for
files and directories in USS file monitoring.
Starting the IDT

Start the started task with the regular z/OS start command as follows:
S sdfidt
Always use the default start parameter WARM.
The browser-based GUI connects to the started-task HTTP port, which is defined in the IDT
started task input member ZENPARM parameter HttpServer. RACF sign-on processing is
invoked each time you connect, as shown in Panel 8-1.
Panel 8-1: Ironstream Desktop Login Panel

To log onto IDT, RACF READ access to the RACF FACILITY class profile
WDS.ZEN.Groupname is required, where Groupname is the value specified in the IDT
ZENPARM parameter. The “Additional Actions for IDT Started Task Members” section in
“Specify the Ironstream Desktop (IDT) Parameters” on page 6-17 includes the instructions
to create the RACF commands.
Stopping the IDT

Stop IDT with the regular z/OS stop command:
P sdfidt

Deploying Multiple IDT Instances

Deploying DCE data sources and NMC across multiple LPARs in a Sysplex requires an IDT
started task in each LPAR. The default start-up option WARM should always be used. It is
possible to deploy multiple IDT started tasks across multiple LPARs and control them from
a single instance of the desktop GUI using a client/server approach. In each IDT task,
specify the same DomainClient definition in each ZENPARM.
Controlling the Data Collection Extension (DCE)

DCE currently supports two data types:
• USS
• RMF
Because of the disparate nature of the data they collect, you must have separate DCE
instances for the USS and RMF data types, each with its own configuration file. A
configuration file defines global parameters, such as the name of the DCE instance and XCF
group and member names, plus parameters relating to the data type. For detailed
instructions about the DCE configuration file parameters, see “Configuring the DCE
Parameters,” on page 21-1.
To run an instance of DCE for a single data type, remove the start parameter for the other
data type. For example, to run a USS-only DCE instance, the parameter
RMF=HOT/WARM/COLD should be absent.
Starting DCE
The started task JCL for DCE has the following PROC statement:
//DCE PROC MEMBER=DCEXCF,

// USS=HOT,RMF=HOT,
// ZEN=ZENPARM,TRACE=
The MEMBER variable value resolves to a parameter in the EXEC PGM=SSDFDCE statement
and identifies the name of the configuration file in the DCEPARM data set. The ZEN
parameter is similar and TRACE can be ignored from the perspective of routinely started
DCE.
The USS and RMF parameters can have one of the following start-type values:
• HOT
• WARM
• COLD
There are differences in how each start type effects RMF and USS. The affects and
implications of each start-up parameter are described in Table 8-1. Ensure you read these
instructions in conjunction with “Starting RMF for the First Time” on page 8-5 and “Starting
USS for the First Time” on page 8-6.

Each DCE start type has a different impact, as described in the following table.
Table 8-1: DCE Start Types
Start Data
Type Type Explanation
HOT USS USS processes the configuration that is saved in its entirety
to zFS each time changes are applied with IDT. Processing is
resumed from the status information that was saved when
the task previously ended.
HOT start is the default set in the DCE procedure by the
configurator.
RMF RMF restarts collection using the previously set filters. No
discovery of any new resources is done.
HOT start is the default set in the DCE procedure generated
by the configurator.
WARM USS USS processes the configuration from the configuration file,
ignoring previous changes made with IDT.
RMF RMF restarts collection using the previously set filters and
performs a discovery to identify any more resources that
have been added since the last COLD/WARM start.
COLD USS USS processes the configuration from the z/OS member and
disregards all previous USS file offload activity. This type is
normally for recovery since the base z/OS configuration is
used and every eligible USS file is re-offloaded.
RMF RMF deletes all previously set filters and metrics and
reverts to “factory settings” for filters. RMF performs
discovery for metrics and rebuilds the knowledge base.
Starting RMF for the First Time

The JCL generated by the configurator specifies a HOT start for RMF. This is prefereable
except when you initially start DCE, which requires a WARM start to force DCE to perform
the discovery process. Therefore, use the following command the first time you start DCE for
RMF:
S sdfDCE,RMF=WARM
Thereafter, the default HOT start is correct.

Starting USS for the First Time

USS file monitoring definitions exist in two sources:
• The DCEPARM member that is allocated by the started task JCL
• The IDT registry
It is essential to understand that DCE only uses one source at start-up, based on the
start-up parameter. A COLD or WARM start reads the DCEPARM member and ignores any
definitions in the IDT registry. A HOT start reads the IDT registry file and ignores the
definitions in DCEPARM definitions. These factors affect how you should start USS for the
very first time and how you start it thereafter. The following rules must be observed:
• The very first time you start USS must be either a COLD or WARM start.
• You must never use a HOT start until you have added a directory using IDT.
• Once you have added a file or directory with IDT, you must always use a HOT start.
In effect, COLD/WARM starts should be used if you define all files, directories and filters in
the configuration file, and if you use IDT you should only ever perform a HOT start.
In the started task JCL generated by the configurator, HOT is the default start so the first
time you run DCE use this start command:
S sdfDCE,USS=WARM,[RMF=WARM]
If you don't plan to use IDT, change the started task USS option to WARM and thereafter
issue:
S sdfDCE
If you plan to use IDT, consider adding and immediately deleting a directory to initiate the
process of copying the DCEPARM definitions to the IDT registry. Thereafter, you must
always do a HOT start to ensure IDT changes are included. You should consider
implementing a process to periodically equalize the IDT and the USS configuration file
definitions as a backup.
At any time you can review the IDT registry by browsing the USS file
dce/hotrestart/uss.conf in your Ironstream root directory.
Stopping DCE
Use the regular z/OS stop command to stop DCE:
P sdfdce

Controlling the Network Monitoring Components (NMC)

The various NMC components run as individual started tasks, in some cases with differing
start-up parameters.
EE Monitor
There are two start-up options for EE Monitor:
• VERIFY option (default)
• COLD option
The start-up option is a symbolic parameter in the started task JCL and the default is
VERIFY. Start EE Monitor with a regular z/OS start command:
S sdfzem
Use the regular z/OS command to stop the EE Monitor:
P sdfzem
COLD should only be used if product maintenance requires it, or if the topology DIV needs to
be initialized. Refer to the full set of ZEN product documentation for further information.
FTP Control
The only start-up parameter is the VTAM ACB name, which is specified in the started task
JCL. Use the regular z/OS start and stop parameters.
IP Monitor
The IP monitor has at least two started tasks: one for the IP monitor and one for the
Dataspace Manager for each TCP/IP stack. In all cases, start-up parameters are coded in the
started task JCL.
Use the regular z/OS start and stop commands for the IP monitor and each Dataspace
Manager.
OSA Monitor
The default start-up option WARM is coded in the started task JCL. Use the regular z/OS
start and stop commands.
UNIX Server
The UNIX Server has no start-up options. Use the regular z/OS start and stop commands.


Chapter 9 Dynamically Modifying a
Running Ironstream
Configuration
This chapter describes how Ironstream allows you to dynamically reconfigure a running
instance that is collecting SMF data.
Topics:
• “Overview”
• “Dynamic Reconfiguration Limitations”
• “How Ironstream Performs a Dynamic Change in the Current Configuration”
• “Dynamic Reconfiguration Commands”
• “Dynamic Reconfiguration Procedure”
• “Messages Issued by Dynamic Reconfiguration”
Overview
A running Ironstream instance collecting SMF records can have its existing SOURCE
configuration parameters dynamically modified without having to stop and restart the
instance. This includes switching from a currently-SELECTed SMF record type to another
record type, changing/adding/deleting any supported subtypes, and also modifying the SMF
filtering parameters via the INCLUDE and WHERE statements. Such dynamic
reconfiguration alleviates the need to stop your running tasks, thereby preventing the loss of
records by eliminating unnecessary downtime while gathering SMF data.
You can dynamically modify most of the "DATATYPE":"SMF" parameters described in “SMF
Subparameters” on page 7-21 while an instance of Ironstream is running. Then execute the
reconfiguration commands described in “Dynamic Reconfiguration Commands” on page 9-3.

Dynamically Modifying a Running Ironstream Configuration
It is important to note that if any other configuration parameter changes are made when
dynamically changing SMF type parameters – such as adding another TCP connection – the
changes are verified as correct by the reconfigure commands, but are not implemented until
that Ironstream instance is restarted. There are additional initial limitations in the current
version that are outlined in “Dynamic Reconfiguration Limitations” on page 9-2.
Dynamic Reconfiguration Limitations

In the current release, dynamic reconfiguration is not supported for the following scenarios:
• Ironstream only supports the use of dynamic reconfiguration when collecting SMF data.
Therefore, you cannot dynamically switch from an SMF data source to any other type of
data source.
• The SMF_SOURCE parameter cannot be dynamically changed. Therefore, you cannot
switch between using SMF user exits (the default setting) and the SMF Real-time
interface ("SMF_SOURCE":"INMEM"). See “SMF Subparameters” on page 7-21.
• No dynamic changes are permitted when "SMF_SOURCE":"EXIT" is specified (or
defaulted to) and the Data Loss Prevention (DLP) function is also enabled via the
"DATA_LOSS_PREVENTION":"YES" parameter. However, changes are always
permitted when "SMF_SOURCE":"INMEM" is specified with DLP enabled. For more
information about DLP, see Chapter 10, “Configuring Data Loss Prevention”.
• During dynamic reconfiguration, Ironstream will not recognize a newly-built CICS
monitor Dictionary (SSDFCICT) for SMF 110 type records. Instead, a running
Ironstream job assumes that the new custom CICS dictionary is the same as the original
version when dynamic reconfiguration was requested. Therefore, you will need to start a
new Ironstream instance instead of reconfiguring an existing job if you want a new
CICS custom dictionary to take effect.
Note: If any other configuration parameter changes are made while dynamically changing
an SMF data source, such as adding another TCP connection, the changes are verified as
correct, but they will not be implemented until the Ironstream instance is restarted.
How Ironstream Performs a Dynamic Change in the Current

Configuration
When commanded to perform a reconfiguration, Ironstream rereads the SSDFCONF file.
Because Ironstream is rereading the file (or files in the case of embedded
"READ":"data_set_name" usage), the modified files have to be sequential files or PDS
members, and not a JES input file. The only exception to this occurs when a JES input file
uses "READ" commands and the changes are in the referenced file.

Dynamic Reconfiguration Commands

There are two commands associated with dynamic reconfiguration.
This command validates the reconfiguration:
F jobname,RECONFIGURE,VALIDATE
This command both validates and executes the reconfiguration:
F jobname,RECONFIGURE,EXECUTE
Command Notes:
• When a valid RECONFIGURE command is issued for either VALIDATE or EXECUTE,
the configuration is printed in the SYSPRINT file.
• When an invalid configuration change is encountered, the RECONFIGURE command
will not change the current configuration.
For information about all Ironstream commands, see Chapter 25, “Ironstream Commands”.
Dynamic Reconfiguration Procedure

In the following outline of reconfiguration steps, only steps 2 and 6 are required. However, to
ensure data integrity Syncsort strongly recommends following all of the steps.
1. Back up the Ironstream configuration file you are going to modify.
2. Make the desired changes to the configuration file. For example, add the SMF type 30
collection to your existing configuration and delete SMF types 14 and 15:
Original SOURCE SMF Parameters:
"SOURCE"
"DATATYPE":"SMF"
"SELECT":"SMF14,SMF15
Reconfigured SOURCE SMF Parameters:
"SOURCE"
"DATATYPE":"SMF"
"SELECT":"SMF30"
"SUBTYPE":"4,5"
3. Issue the validate reconfiguration command:

4. If you get message SDF2003S, correct the errors listed.
5. When message SDF2004I is issued, you can proceed to step 6.
6. Issue the execute reconfiguration command:

While a VALIDATE command is not required before an EXECUTE command, Syncsort

strongly recommends performing the validation. An EXECUTE command does a validation
call internally to prevent an invalid configuration from being implemented.
Messages Issued by Dynamic Reconfiguration

Ironstream’s dynamic reconfiguration-related messages are mainly in the SDF2001–
SDF2009 range and are fully described in “Ironstream Messages,” on page 27-1.

Chapter 10 Configuring Data Loss
Prevention
This chapter describes how to configure Ironstream to minimize the loss of forwarded
Splunk data due to extended network or Splunk outages.
Note: Ironstream DLP uses the Splunk Indexer Acknowledgment function and therefore
cannot be configured to work with Elastic destinations.
Topics:
• “Overview”
• “Ironstream System Requirements for Using DLP”
• “Configuring Ironstream DLP Parameters”
• “Configuring Splunk Parameters”
• “Best Practices When Using DLP”
• “Messages Issued by DLP”
Overview
Data Loss Prevention (DLP) is an optional Ironstream feature that minimizes data loss
through the use of IBM’s Coupling Facility’s System Logger functions, combined with the
use of Splunk’s Indexer Acknowledgement feature.
Data received by Ironstream is logged in the coupling facility and is only deleted from there
once a positive acknowledgement has been received from the Splunk indexer. The use of the
coupling facility allows Ironstream to continue to collect and retain data during extended
network or Splunk outages.
Unless DLP is explicitly activated via Ironstream configuration file changes, there are no
modifications required to existing Ironstream configuration files.
Note: In this release of Ironstream, DLP cannot be configured to work with the Data
Collection Extension’s USS file monitoring data source.

Configuring Data Loss Prevention
Ironstream System Requirements for Using DLP

If DLP is activated in the Ironstream configuration file, then each forwarder requires a
dedicated coupling facility log stream. when collecting SMF data via system exits, then a
separate task with the default name SSDFAUX is required and the JCL must be added to a
system PROCLIB. However, when using the INMEM option to collect SMF data or when
using all other supported data sources, running Ironstream with DLP does not require a
separate SSDFAUX task.
For the coupling facility log stream, Ironstream requires the availability of a Monoplex or
Sysplex Coupling Facility (CF) processor. For more information, see the MVS Programming:
Sysplex Services Guide or contact your system programmer.
System Authorization Facility (SAF) processing is optional for all supported data sources,
but is strongly recommended to protect the integrity of data in a log stream.
The SSDFAUX procedure in the SAMPLIB library needs to be customized and copied into a
PROCLIB library that the START command can access. See “Modifying the SSDFAUX
Procedure” on page 10-3. Ironstream configuration parameter changes are described in
“Configuring Ironstream DLP Parameters” on page 10-3.
Coupling Facility Log Stream

Important! You must define a coupling facility log stream environment for each Ironstream
instance that will utilize the DLP feature. That is, each Ironstream instance must run with
its own log stream.
Because there are many factors that need to be considered for each Ironstream instance,
such as message rates and size, acknowledge time-out and retry limits, Syncsort cannot
provide a single set of recommended parameters for sizing the coupling facility resources.
Before using the DLP feature, Syncsort strongly recommends following these data sizing
suggestions:
• Run Ironstream for a period of several days to determine the volume of data being
processed in terms of records per second, average size, and maximum size.
• Once this data has been determined, you should utilize the IBM CF Structure Sizer Tool
(CFSizer). For more information, visit www.ibm.com/systems/support/z/cfsizer.
When defining a log stream, Syncsort strongly recommends the use of RETPD(0) and
AUTODELETE(NO) parameters. Using this combination will keep the data in the coupling
facility only until it has been acknowledged as received by the destination process.
System Authorization Facility

If the System Authorization Facility (SAF) is available, the system performs SAF
authorization checks on all IXGCONN REQUEST=CONNECT requests in order to protect the
integrity of data in a log stream.
To connect successfully to a log stream, the caller must have SAF authorization that
matches the authorization required for the log stream:

• To connect to a log stream with an authorization level of READ, the caller must have
read access to RESOURCE(log_stream_name) in SAF class CLASS(LOGSTRM).
• To connect to a log stream with an authorization level of WRITE, the caller must have
alter access to RESOURCE(log_stream_name) in SAF class CLASS(LOGSTRM).
If SAF is not available or if CLASS(LOGSTRM) is not defined to SAF, no security checking is
performed. In that case, the caller is connected to the log stream with the requested or
default AUTH parameter value.
Modifying the SSDFAUX Procedure

When collecting SMF data vis system exist with the DLP feature, Ironstream will start an
auxiliary address space called, by default, SSDFAUX. You will need to copy the model
SSDFAUX procedure in SAMPLIB member SSDFAUX to a procedure library that is
accessible to the Ironstream START command and modify it to your standards. Contact your
system programmer for the appropriate library to use. See “Configuring SMF Record
Collection When Using DLP” on page 10-4 for more information about this procedure.
Configuring Ironstream DLP Parameters

The DLP-related configuration parameters are defined in the DESTINATION section of the
configuration file, which describes where the data is to be sent and how it is to be forwarded.
Certain DLP parameters must immediately precede the INDEX parameter, while others must
immediately follow INDEX, as shown in Figure 10-1.
Figure 10-1. Required Ordering of Parameters when Using DLP
"DESTINATION"
"DATA_LOSS_PREVENTION":"YES"
"DLP_STREAM_NAME":"value"
"AUX_SPACE_NAME":"SSDFAUX" (Optional if DLP default SSDFAUX is used or

when SMF data is being collected via INMEM)
"ACK_TIMEOUT_LIMIT":"60" (Optional if DLP default of 60 is used)
"ACK_RETRY_LIMIT":"1" (Optional if DLP default of 1 is used)
"DLP_COLD_START":"NO" (Optional if DLP default of NO is used)
"INDEX":"value"
"TYPE":"HTTP" (DLP requires either HTTP or HTTPS)
"IPADDRESS":"value"
"PORT":"value"
"TOKEN":"value" (DLP value provided by Splunk when defining
the HTTP or HTTPS port on the Splunk indexer)
"SSL":"NO" (Must be set to YES when TYPE is HTTPS)

Important! The SYSTEM-level IMPORT data parameter is not compatible with (DLP).
Ironstream verifies whether both parameters are configured, and if true, message
SDF0190A is generated and the Ironstream instance is terminated.
For detailed descriptions of all DLP-related configuration file parameters, refer to “Data
Loss Prevention Parameters” on page 7-13.
Configuring Splunk Parameters

The minimum version of Splunk required for using DLP is Splunk Enterprise Release 6.4.0.
To enable DLP on your Splunk server, you must ensure that the Splunk HTTP Event
Collector (HEC) endpoint is correctly configured. Therefore, we recommend reading the “Set
up and use HTTP Event Collector” instructions in the Splunk Enterprise Getting Data In
6.5.1 manual.
Best Practices When Using DLP

This section contains recommended best practices when using DLP with Ironstream.
Configuring SMF Record Collection When Using DLP

When Ironstream is using the DLP feature and collecting SMF data via system exists, it
automatically starts an auxiliary address space called SSDFAUX, or whatever is specified as
the AUX_SPACE_NAME parameter value, using a PROC of the same name, as described in
the “Data Loss Prevention Parameters” on page 7-13.
Important! You must not manually start the auxiliary address space from a console. It
requires programmatically-passed parameters from the main Ironstream task.
This address space is automatically stopped if Ironstream is stopped normally. If Ironstream
abnormally terminates, the auxiliary address space will continue to collect SMF data via
system exits and store it into the coupling facility.
You can restart Ironstream using the default "DLP_COLD_START":"NO" parameter, and
data retained in the coupling facility during the outage will be processed. If you restart
Ironstream using the "DLP_COLD_START":"YES" option, Ironstream will stop an existing
auxiliary task, if running, delete all data held in the coupling facility, and start a new
auxiliary task.
Important! You cannot change any collection parameters on a restart from a failure. To
change collection parameters you must use the "DLP_COLD_START":"YES" option. If not, it
will cause unpredictable results.

Messages Issued by DLP

Ironstream DLP-related messages are mainly in the SDF0450–SDF0470A and SDF8005A–
SDF8014S ranges and are fully described in “Ironstream Messages,” on page 27-1.
Because Ironstream requires the availability of a Monoplex or Sysplex Coupling Facility
(CF) processor, there is a possibility that Ironstream may also generate return and reason
codes from IBM’s IXGWRITE macro, which writes log data to a log stream.
For more information about the reason and return codes for the IXGWRITE macro, see the
MVS Programming: Assembler Services Reference, Volume II, or contact your system
programmer.


SECTION IV Setting Up Ironstream Data
Sources
This section provides instructions for setting up Ironstream data sources.

• “Syslog Message Filtering”
• “SMF Record Filtering”
• “SYSOUT Forwarding”
• “Alerts and SyslogD Forwarding”
• “DB2 Data Forwarding”
• “Sequential File Forwarding”
• “System State Forwarding”
• “Configuring and Using the Ironstream API”
• “Setting Up Log4j”
• “IMS Log Record Forwarding”
Chapter 11 Syslog Message Filtering
This chapter describes how to configure syslog message filtering.
Topics:
• “Overview of Filter Modules” on page 11-1
• “Syslog Message Filtering” on page 11-2
Overview of Filter Modules

The filter modules contain your specifications for the syslog message types that you want to
forward to a destination. The name of the filter modules used for an Ironstream instance are
specified using FILTER parameters in the configuration file.
The SDFSAMP data set contains a member called ASMFILTR that is used to set up your
filters. The JCL in ASMFILTR assembles macros and links your options into a module. Edit
ASMFILTR, following the instructions embedded in the job.
Important! If the syslog forwarder (SDFLOG) is used on a z/OS system that is using the
MPF (Message Processing Facility), or any similar product, then you must ensure that all
messages that are going to be forwarded by SDFLOG are set to AUTO(YES) in the MPF
configuration. The z/OS PARMLIB member containing the MPF information is MPFLSTxx.

Syslog Message Filtering

Syslog message filtering is accomplished by building a message filtering module by using the
SSDFFLOG macro. The SSDFFLOG macro allows you to select one or more of the following
syslog message types.
Table 11-1: Syslog Record Types for Filtering
Message Type Description

ALL All syslog messages are selected. If this option is used it must
be the only option specified.
ACF2 This selects all messages that have a message ID that starts
with ACF or CIA.
CICS This selects all messages that have a message ID that starts
with DFH.
DB2 This selects all messages that have a message ID that starts
with DSN, but not DSNJ.
DB2L This selects all messages that have a message ID that starts
with DSNJ.
IEF This selects all messages that have a message ID that starts
with IEF.
IMS This selects all messages that have a message ID that starts
with DFS.
RACF This selects all messages that have a message ID that starts
with ICH.
TOPS This selects all messages that have a message ID that starts
with CAS or TSS.
USS This selects all messages that have a message ID that starts
with BPX. These messages can be log records from USS. Please
make sure that USS log records are routed to console if you
would like to capture them.
WAS This selects all messages that have a message ID that starts
with BBO.
WEBS This selects all messages that have a message ID that starts
with CSQ.
A typical macro definition might look like the following:

SSDFFLOG TITLE '- SYSLOG SAMPLE MESSAGE SELECTION TABLE'
SSDFFLOG SELECT=(DB2,CICS,IMS,RACF)
END

You can also select messages by specifying a 3 or 4-character message prefix using the
CHAR3 =(3-byte prefix list), and CHAR4=(4-byte prefix list) parameters.
SELECT, CHAR3 and CHAR4 are all optional parameters. Parameter values are separated
by commas and any number can be specified.
The specified parameters are processed in the order in which they are specified and there is
no checking for duplicates or overlaps (such as those illustrated in the following example):
SSDFFLOG SELECT(ACF2,CICS,DB2),CHAR3=(ACF,CIA,DSN), *
CHAR4=($HAS,DSNL)
In this example, ACF2 builds table entries for messages prefixed ACF and CIA, while DB2
builds an entry for message prefix DSN. The selection table will therefore have two entries
for each message prefix because the values in the CHAR3 parameter duplicate both ACF
and CIA. This will not cause any problems in the message selection processing, but it will
consume slightly more CPU time unnecessarily.
The DSNL value will never be matched since the message prefix matches the DSN specified
in the CHAR3 list which is processed first.
You should therefore be aware of the way in which the message prefixes are processed when
you define the message prefixes that are to be selected for forwarding to a destination.


Chapter 12 SMF Record Filtering
This chapter describes how to configure field-level filtering for SMF record types, either by
manually creating control records in the Ironstream configuration file or by using the
GUI-based “SMF Filter Configuration Builder” in the Ironstream Desktop GUI.
Topics:
• “Overview of SMF Record Filtering” on page 12-2
• “Gathering SMF Data” on page 12-3
• “Supported SMF Record Types” on page 12-4
• “Manually Defining SMF Filtering Configurations” on page 12-7
• “Limiting SMF Record Selection with WHERE Search Conditions” on page 12-7
• “Using the SMF Filter Configuration Builder in IDT” on page 12-13
• “Using the READ Command to Share SMF Filter Configurations” on page 12-22
• “Implementing a Custom CICS Monitor Dictionary in Ironstream” on page 12-23
• “Sample SMF Filter Configurations” on page 12-31

SMF Record Filtering
Overview of SMF Record Filtering

Ironstream provides an SMF filtering facility that enables you to select specific fields within
SMF record types and subtypes, so you can precisely control which pertinent SMF
information is forwarded to a destination.
Using the Ironstream Configuration File to Create SMF Filter

Configurations
For the SMF data type, filters are defined by the SELECT, SUBTYPE, INCLUDE, and
WHERE parameters in the SOURCE section of the configuration file.
• The SELECT and SUBTYPE parameters specify which SMF records to filter by type
and subtype.
• The INCLUDE parameter can precisely identify which fields from the filtered SMF
record types and subtypes are used to gather records for forwarding.
• The WHERE parameter can specify a set of field search conditions to select records for
forwarding only when all search conditions are met.
See “Manually Defining SMF Filtering Configurations” on page 12-7 and “Limiting SMF
Record Selection with WHERE Search Conditions” on page 12-7.
Using IDT to Create SMF Filter Configurations

The Ironstream Desktop (IDT) provides a GUI-based “SMF Filter Configuration Builder”
that allows you to easily filter specific fields within SMF record types and subtypes. Using
these panels, you can easily create multiple filtering configurations with various
combinations of record types and subtypes that collect only those fields you want to be
forwarded.
See “Using the SMF Filter Configuration Builder in IDT” on page 12-13.
Note: The WHERE processing syntax is not supported by the IDT.
Using the READ Command

You can use READ commands in the configuration file to include groups of SELECT,
SUBTYPE, and INCLUDE statements that may be common across Ironstream instances, so
that they do not have to be duplicated in each configuration file.
See “Using the READ Command to Share SMF Filter Configurations” on page 12-22.
Tip: A combination of the SMF Filter Configuration Builder and READ commands is the
recommended approach.

Gathering SMF Data

Ironstream provides two ways to gather SMF data:
• SMF user exits – Ironstream uses the standard z/OS SMF record exits IEFU83,
IEFU84, and IEFU85 for real-time capture. For more information, see “Define z/OS
SMF Record Exits” in the Ironstream Program Directory manual.
• SMF real-time interface – Ironstream can be configured to select SMF records via the
SMF real-time interface. The SMF real-time interface provides applications with a
high-speed data feed with low system overhead, both in terms of CPU time and elapsed
time; therefore, Syncsort recommends using this method if your system is configured to
access SMF log streams, but it is not required.
When enabled, INMEM resource names defined to SMF log streams are acquired
dynamically. Ironstream will retrieve the names from SMF, ensure security access,
ensure no duplicate SMF types are captured, connect to the INMEM resource, and
retrieve records.
For more information INMEM configuration parameters and MODIFY commands, refer
to:
▪ “SMF Subparameters” on page 7-21
▪ “SMF Real-time INMEM Commands” on page 25-5

Supported SMF Record Types

You can select any of the SMF record types currently supported by Ironstream.
For descriptions of all the fields in the supported SMF record types, refer to the
HTML-based Ironstream SMF Record Field Reference available on the “Ironstream V2.1
Documents” page on Syncsort’s MySupport page for Ironstream.
Table 12-1 briefly describes the SMF records that are currently supported.
Table 12-1: Supported SMF Records
Record Type Definition

SMF Type 00 IPL Activity
SMF Type 02 Dump Header
SMF Type 03 Dump Trailer
SMF Type 04 Step Termination
SMF Type 07 Data Lost
SMF Type 08 I/O Configuration
SMF Type 09 VARY Device ONLINE
SMF Type 11 VARY Device OFFLINE
SMF Type 14, 15 Data Set Activity
SMF Type 16 DFSORT Statistics
SMF Type 17 Scratch Data Set Status
SMF Type 18 Rename Non-VSAM Data Set Status
SMF Type 19 Direct Access Volume
SMF Type 28 Software Diversified Systems - Vital Signs for VTAM
SMF Type 30 Common Address Space Work
SMF Type 40 Dynamic DD
SMF Type 41 DIV Objects and VLF Statistics
(Subtypes 1,2,3)
SMF Type 42 DFSMS Statistics and Configuration
(Subtypes 1, 2, 3, 5, 6, 9, 10, 15, 17, 19, 20, 21, 24, 25)
SMF Type 50 VTAM Tuning Statistics
SMF Type 57 JES2 Network SYSOUT Transmission
SMF Type 60 VSAM Volume Data Set Updated

Table 12-1: Supported SMF Records (continued)

SMF Type 61 Integrated Catalog Facility Define Activity
SMF Type 62 VSAM Component or Cluster Opened
SMF Type 64 VSAM Component or Cluster Status
SMF Type 65 Integrated Catalog Facility Delete Activity
SMF Type 66 Integrated Catalog Facility Alter Activity
SMF Type 70 RMF Processor Activity
SMF Type 71 RMF Paging Activity
SMF Type 72 RMF Activity (Subtypes 1-5)
SMF Type 73 RMF Channel Path Activity
SMF Type 74 RMF Activity of Several Resources (Subtypes 1-8)
SMF Type 75 RMF Page Data Set Activity
SMF Type 76 RMF Trace Activity
SMF Type 77 RMF Enqueue Activity
SMF Type 78 RMF Virtual Storage and I/O Queueing Activity
(Subtypes 1, 2)
SMF Type 79 RMF - Monitor II Activity (Subtype 15)
SMF Type 80 Security Product (RACF) Processing
Note: Ironstream supports the Top Secret version of
Type 80 records that are similar to the RACF version
(subtype 109). Ironstream automatically identifies
whether the record is the RACF or Top Secret version.
SMF Type 81 Security Product (RACF) Initialization
SMF Type 82 Integrated Cryptographic Service Facility (ICSF) Record
(All subtypes 1-29)
SMF Type 83 Security Product (RACF) Event
SMF Type 90 System Status
(Subtypes 5, 6, 11, 13, 14, 15, 18, 19, 20, 21, 22, 24, 25,
29, 30, 31, 32)
SMF Type 92 File System Activity
SMF Type 99 System Resource Manager (SRM) Decisions
SMF Types 100, 101, 102 DB2 Records

Table 12-1: Supported SMF Records (continued)

SMF Type 110 CICS SMF Data Records
• Subtype 1 Class 3 - Performance Data
• Subtype 1 Class 4 - Exception Data
• Subtype 2 - CICS Statistics
Note: Ironstream can capture all CICS monitoring fields
in the SMF 110 record, including user-defined fields
beyond the standard set of monitoring fields, as
described in “Implementing a Custom CICS Monitor
Dictionary in Ironstream” on page 12-23.
SMF Type 113 Hardware Capacity, Reporting, and Statistics
(all subtypes)
SMF Type 115 WebSphere MQ Performance Statistics
(Subtypes 1, 2)
SMF Type 116 WebSphere MQ Accounting Data
(Subtypes 0, 1, 2)
SMF Type 117 Message Flow Accounting and Statistics
SMF Type 118 TCP/IP Statistics
SMF Type 119 TCP Statistics
SMF Type 120 WebSphere Application Records
(Subtype 9)
SMF Type 123 IBM z/OS Connect EE V3.0.
SMF Type 132 Connect:Direct Statistic Records
SMF Type 205 Compuware Abend-AID SMF Records
SMF Type 207 Syncsort Ironstream SMF Records
SMF Type 208 Syncsort MFX SMF Records
SMF Type 220 Compuware Hiperstation SMF Records
SMF Type 230 ACF2 SMF Records
SMF Type 240 BMC CMF Monitor Records
SMF Type 241 DFSMShsm Function Statistics
SMF Type 250 IBM Session Manager

Manually Defining SMF Filtering Configurations

The SMF data source and filtering parameters are defined as a data type of “SMF” in the
SOURCE section of the configuration file, as follows:
"SOURCE"
"DATATYPE":"SMF"
"SELECT":"SMFnnn,SMFnnn,SMFnnn"
"SELECT":"SMFnnn"
"SUBTYPE":"NN,NN,NN"
"INCLUDE":"ALL | field_list"
"WHERE":"where_clause"
Note: The indentations used here are for readability purposes and are not required.
For detailed descriptions of all SMF-related configuration file parameters, refer to the “SMF
Subparameters” on page 7-21.
Limiting SMF Record Selection with WHERE Search Conditions

A WHERE statement enables you to specify a set of field search conditions to select records
for forwarding to a destination only when all search conditions are met. This optional
feature is for Ironstream users who want to reduce the number of SMF records being sent to
a destination.
Topics Include:
• “Overview of WHERE Statements” on page 12-7
• “Understanding the WHERE Syntax” on page 12-8
• “WHERE Search Conditions” on page 12-9
• “Validating Command Syntax with a PARM Option” on page 12-12
Overview of WHERE Statements

You can only specify one WHERE statement for each SMF record type you SELECT, and the
statement can include one or more search conditions. WHERE statements are not required
to be part of an INCLUDE statement.
Multiple search conditions are separated by AND or OR operators and are evaluated from
left to right. Parentheses can be used to modify the normal left-to-right evaluation of
operators, as discussed in “Parenthetical WHERE Clauses” on page 12-11. Each search
condition results in a TRUE or FALSE evaluation. Records are only included in the output if
the result of the evaluation of all search conditions is TRUE.
Basic WHERE Syntax:
The basic syntax has the form of:
"WHERE":"search_condition [AND/OR search_condition]"
The basic field search condition has the form of:
[NULL=TRUE/FALSE] fieldname operator operand

Acceptable operands are:

'string' | number | hexadecimal | Date | Time | field | (list)
Items within square brackets are optional. Items separated by vertical bars are mutually
exclusive.
A typical field search comparison condition could have the form of:
[NULL=TRUE/FALSE] field1 operator operand AND/OR field2 operator operand
Example WHERE Statements:

Here is a simple case when searching for included SMF 30 type fields, where the JOBNAME is
checked for starting with either TST (test) or PRD (production):
"SELECT":"SMF030"
"SUBTYPE":"4,5"
This example expands on the previous one by adding a test for any zIIP processing:
"WHERE":"SMF30JBN EQ 'TST*' OR SMF30JBN EQ 'PRD*' AND
SMF30_TIME_ON_ZIIP GT 0"
Understanding the WHERE Syntax

The WHERE clause syntax supports the following comparison operators and operands:
Table 12-2: WHERE Statement Parameters
Parameter Description
NULL=TRUE/FALSE An optional directive, as described in “NULL Processing Command”
on page 12-11.
field1 The name of a field defined by the SMF DSECT for that record.
operator Comparison operators: EQ, NE, GT, GE, LT, LE, IN, and NOTIN, as
described in “WHERE Search Conditions” on page 12-9.
'string' A character string of characters and numbers enclosed in single
quotes. The maximum length is 2037 bytes. Wildcards are supported.
See “‘string’ Operand” on page 12-9.
number An integer value that is a string of digits not enclosed in quotes. The
maximum size is 19 digits with no commas or decimal points. See
“Number Operand” on page 12-10.
hexadecimal A string of up to 32 hexadecimal character pairs in single quotes,
preceded by an X. See “Hexadecimal Operand” on page 12-10.
field2 Another included SMF field name in the same record.

Table 12-2: WHERE Statement Parameters
Date A date enclosed in single quotes and preceded by a D, as in
D'mm/dd/yyyy'. See “Date Operand” on page 12-10.
Time A time of day enclosed in single quotes and preceded by a T, as in

T'hh:mm:ss.th'. See the “Time Operand” on page 12-10.
(list) A list consists of one or more quoted strings separated by a comma

and can only be used with the IN or NOTIN operator:
('STRING_1','STRING_2','STRING_3',...,'STRING_n')
See the “(list) Operand Using IN/NOTIN Comparisons” on
page 12-11.
WHERE Search Conditions

WHERE search conditions can include common comparison operators and date and time
operands.
Comparison Operators
The following comparison operators are case-sensitive and must be specified as shown:
• EQ – Equal
• NE – Not equal
• GT – Greater than
• GE – Greater than or equal
• LT – Less than
• LE – Less than or equal
• IN – Returns a TRUE condition when a string in the (list) operand matches the
fieldname value
• NOTIN – Returns a TRUE condition when no string in the (list) operand matches the
fieldname value
Comparison Operands
The following comparison operands can be used to further filter WHERE clauses.
‘string’ Operand
A quote-delimited character string of characters and numbers enclosed in single quotes, as
in 'A STRING OF LETTERS, BLANKS AND NUMBERS 0123456789'. The maximum length is
2037 bytes.
Wildcards can be used with character strings. A ‘string’ operand with wildcards can be used
only with the EQ and NE comparators.
• * – Asterisk matches zero or more characters

• % – Percent symbol matches any single character

All other characters match 1-for-1. For example, ‘C*B’ will match fields named CB123,
CYB123, CXYB123, and CXYZB.
Whereas, ‘C%B*’ only matches CYB123 and would reject the rest of the fields from the
previous example.
Hexadecimal Operand
A string of up to 32 hexadecimal character pairs, enclosed in single quotes and preceded by
an X, as in: X'0123456789ABCDEF'. The maximum size is 32 pairs of digits.
Number Operand
An integer value that is a string of digits not enclosed in quotes. Maximum size of 19 digits
with no commas or decimal points.
An integer value that is a string of digits not enclosed in quotes. Maximum size of 19 digits
with no commas or decimal points. Values less than 231 are evaluated as 4-byte binary
values. Values greater than 231 are evaluated as 8-byte binary values. Comparisons using
integer values against SMF fields of unequal lengths will result in erroneous results.
Comparing fields of unequal lengths should be done using a hexadecimal constant.
Date Operand
Defines a date enclosed in single quotes and preceded by a D, as in: D'mm/dd/yyyy', where
mm is the month in the range of 01–12; dd is the day in the range 01–31 (as appropriate for
the month); and yyyy is the year in the range of 1900–9999.
The specified date is converted into a form consistent with the date when the record was
moved into the SMF buffer, in the form 0cyydddF (where c is 0 for 19xx and 1 for 20xx; yy is
the current year (0–99); ddd is the current day (1–366); and F is the sign).
Time Operand
Defines a time of day enclosed in single quotes and preceded by a T, as in: T'hh:mm:ss.th',
and converts it into a time of day in hundredths of a second, which is consistent with most
SMF time fields. A time value where hh is the hours in the range 00–23; mm is the minutes
in the range 00–59; ss is the seconds in the range of 00–59; and t is tenths of a second and h
is hundredths of a second in the range of 00–99.
The time can be specified truncated as T'hh', T'hh:mm', T'hh:mm:ss', or fully as
T'hh:mm:ss.th'. Missing digits are defaulted to zeros.
The Time operand can be used in two ways: first, as a “time of day”; secondly, as an “elapsed
time”. This is because the time specified is converted into hundredths of a second since 12:00
AM.
These four examples result in the same records being selected; namely, all SMF type 30
records that show an elapsed zIIP time of greater than one second:
"WHERE":"SMF30_TIME_ON_ZIIP GT T'00:00:01.00'"
"WHERE":"SMF30_TIME_ON_ZIIP GT T'00:00:01'"
"WHERE":"SMF30_TIME_ON_ZIIP GT 100"

"WHERE":"SMF30_TIME_ON_ZIIP GT X'00000064'"
Whereas, these three examples demonstrate using the “time of day” to select jobs that start
after 13:30 hours. The first example uses the full time format, while the second and third
examples use truncated forms, but all result in the same selection of jobs.
"WHERE":"SMF30SIT GT T'13:30:00.00'"
"WHERE":"SMF30SIT GT T'13:30:00'"
"WHERE":"SMF30SIT GT T'13:30'"
(list) Operand Using IN/NOTIN Comparisons

The (list) operand can only be used with the IN/NOTIN operators. They allow can you to
create more concise and efficient SMF field search conditions when compared to searching
via numerous conditions connected by multiple AND/OR comparisons.
The elements of the (list) operand must be quoted strings (255 bytes maximum) no longer
than the field length defined by the associated fieldname. The use of wildcard characters is
not supported. If additional quoted strings are included, a comma must immediately follow
the quoted string. Blanks can precede a quoted string.
The following examples show valid (list) syntax:
"WHERE":"SMF30JBN IN ('JOBNAME1','JOB2 ', 'JOBNAME3', +
'JOBNAME4')"
"WHERE":"SMF30JBN IN ('JOBNAME1','JOB2 ', 'JOBNAME3', +
'JOBNAME4') AND +
SMF30SCC EQ 0"
Parenthetical WHERE Clauses

If multiple search-conditions are specified, each condition must be separated by an AND or
an OR. Parentheses can also be used to modify the normal left-to-right evaluation of
operators.
"WHERE":"SMF30JBN EQ 'TST*' OR SMF30JBN EQ 'PRD*' AND
(SMF30_TIME_ON_ZIIP GT 0 OR SMF30_TIME_ON_CP GT 0)"
Because precedence is left to right, this is the same as:
"WHERE":"(SMF30JBN EQ 'TST*' OR SMF30JBN EQ 'PRD*') AND
(SMF30_TIME_ON_ZIIP GT 0 OR SMF30_TIME_ON_CP GT 0)"
NULL Processing Command

Because all fields may not be represented in all records, Ironstream supports NULL
processing with the NULL=TRUE/FALSE command.
The NULL command is used to set the default of how to handle a situation where a field has
been specified, but is not present in the record being processed. Generally, this occurs
because the field only appears in a record subtype and the current record is not that subtype.
A missing field has no value; it is simply “not present”.
• NULL=TRUE (default) indicates a search condition with a missing operand field will
always evaluate to a TRUE condition. For example, when there are multiple conditions
and you want the SMF record to be forwarded to a destination even if there is no data
for one or more search fields.

• NULL=FALSE indicates a search condition with a missing operand field will always
evaluate to a FALSE condition. For example, when you don’t want the SMF data to be
forwarded to a destination unless all search conditions are satisfied.
The NULL=TRUE/FALSE parameter can be specified before any search condition and will be in
effect until another NULL parameter is encountered. Its precedence is strictly left to right.
In the following example, if SMF30JBN or SMF30_TIME_ON_ZIIP is not in the record being
processed, then the search condition for each will evaluate as TRUE. And if
SMF30_TIME_ON_CP or SMF30JBN is not in the record, those search conditions will evaluate as
FALSE.
"WHERE":"NULL=TRUE
(SMF30JBN EQ 'TST*' AND (SMF30_TIME_ON_ZIIP GT T'00:00:01.00'
OR NULL=FALSE
SMF30_TIME_ON_CP GT 0)) OR SMF30JBN EQ 'PRD*'"
When examined in order of precedence, only SMF30_TIME_ON_CP would result in a FALSE
condition.
Validating Command Syntax with a PARM Option

You can validate command syntax outside of a running Ironstream instance by adding
“SYNTAXONLY” as a PARM option to the JCL for an Ironstream instance. This option will
validate all command statements and then terminate; thereby, eliminating any conflicts
with currently-running Ironstream instances, without having to manually stop Ironstream
instances in order to test new syntax.
When SYNTAXONLY is specified as a PARM option:
• Upon start-up, Ironstream issues message SDF0018I STARTING SYNTAX ONLY
RUN.
• Processes all the input configuration statements.
• Generates any error messages.
• Terminates after issuing message SDF0019I ENDING SYNTAX ONLY RUN.
If no errors are detected, the Ironstream instance ends with a RETURN CODE=0. If errors
are detected, the instance ends with a RETURN CODE=16.
Configuring the SYNTAXONLY Parameter

To utilize this feature, add a PARM=SYNTAXONLY option to the EXEC statement for a
new or existing set of JCL for a running Ironstream instance. Here is an example EXEC
statement:
//SSDF EXEC PGM=SSDFMAIN,PARM=SYNTAXONLY

Using the SMF Filter Configuration Builder in IDT

Selecting individual SMF fields from the hundreds of available fields for each record type
and manually building the required control records can be both tedious and error prone. To
facilitate this process, Ironstream provides a GUI-based “SMF Filter Configuration Builder”
in the Ironstream Desktop (IDT). The online panels present all supported SMF record types
in an expandable/collapsible tree format, enabling you to easily create a variety of SMF filter
configurations that capture highly-specific combinations of selected SMF record types,
subtypes, and fields that you want to analyze.
The SMF Filter Configuration Builder generates the appropriate SMF filter configuration
statements at the end of the field selection and saves them in a readable, text format
INCLUDE file for Ironstream instances. These configurations can be read into the
Ironstream forwarder task through the READ command so they can be shared across
multiple Ironstream instances, as described in “Using the SMFOUT Data Set in a READ
Statement” on page 12-14.
Notes:
• The range of supported SMF record types continually evolves and each additional
supported type or subtype requires an associated update to the Configuration Builder
metadata, which is the data set specified in the SMFDICT DD statement described
below. Updates are delivered as PTFs and include ++HOLD REASON(ACTION) instructions
that you must follow. See “SMP/E Updates to the SMF Dictionary” on page 12-14.
• The WHERE processing syntax is not supported by the IDT.
Required JCL to Run the SMF Filter Configuration Builder

The Ironstream Configurator generates started task JCL to run the IDT. However, you also
need to update this JCL with the SMFDICT input and SMFOUT output parameters for the
SMF data dictionary, as shown in Figure 12-1.
Figure 12-1. Sample IDT JCL for SMF Filter Configuration Panels
//SSDFIDT EXEC PGM=SSDFIDT

//ZENPARM DD DISP=SHR,
// DSN= yourhlq_parmlib(ZENPARM)
//SMFDICT DD DISP=SHR,DSN= yourhlq.SMF.XML.PDS <<< add for SMF Filter GUI
//SMFOUT DD DISP=SHR,DSN=yourhlq.DICT.OUT <<< add for SMF Filter GUI
SMFDICT DD
The SMF Filter Configuration Builder gets the SMF record type layout from the Ironstream
data dictionary that is packaged with Ironstream V2.1. The dictionary must be a PDS or
PDSE data set with a fixed block format (RECFM=FB) and a record length of 255 bytes.
Sample JCL to create the dictionary is provided in the your_hlq.SSDFSAMP member,
IDTSMFAL. The data format in the dictionary is XML and the your_hlq.SSDFSAMP
member, IDTSMFAL, executes a batch RECEIVE to create the member DEFAULT.

You can use the New Configuration button on the SMF Filter Configuration panel to
create new configurations by either copying the default SMFDICT (read-only) dictionary or
by using a previously-customized filter configuration as a template. The New
Configuration operation adds a new configuration in the SMFDICT dictionary that can be
reloaded, customized, and re-saved whenever necessary. At the same time, it creates a
member in the SMFOUT data set with SELECT statements in it for other Ironstream
instances to use.
Whenever the Save operation is executed, both the dictionary and SMFOUT data set
member are updated. If you manually change a member in the SMFOUT data set, the IDT
does not parse the change, and instead uses the member in the dictionary for input.
SMFOUT DD
The SMF Filter Configuration panels creates standard Ironstream control records in the
data set specified by SMFOUT DD, which you must create as a PDS or PDSE with fixed-
block, 80-byte records. When you use the SMF Filter Configuration Builder in IDT to select
the SMF records and fields that you want to forward, clicking Save prompts you for a name,
which is the member name that is created in the SMFOUT data set. You must manually add
this saved configuration syntax to the SMF forwarder configuration file.
Using the SMFOUT Data Set in a READ Statement

The configuration members stored in the SMFOUT DD data set have SELECT statements
for all the selected SMF records. These configurations can be read into Ironstream instances
using a READ command, as follows:
"SOURCE"
"DATATYPE":"SMF"
"READ":"yourhlq.DICT.OUT(YOURCONF)"
where the READ command points to a configuration member (for example, YOURCONF) in the
SMFOUT data set that has control statements for the selected SMF record types.
See “Using the READ Command to Share SMF Filter Configurations” on page 12-22.
SMP/E Updates to the SMF Dictionary

Updates to SMF record types or subtypes supported by Ironstream require an associated
update to the Configuration Builder metadata, which is the DEFAULT member in the data
set specified in the SMFDICT DD statement. Updates are delivered as PTFs and include
++HOLD REASON(ACTION) instructions that you must follow. Applying these PTFs creates an
updated version of SSDFSAMP member IDTSMFXM.
After applying an SMF update PTF, you must:
1. Stop IDT.
2. Edit and run SSDFSAMP member IDTSMFRC to TSO RECEIVE the new DEFAULT
member to a temporary data set.
3. Copy the new DEFAULT member to the SMFDICT DD data set.
4. Restart IDT.

Using the SMF Filter Configuration Panels

To access the IDT to define filters for SMF record types:
1. Activate the IDT browser. (See “Controlling the Ironstream Desktop (IDT)” on page 8-3.)
2. On the Admin menu, select SMF Filter Configuration.
The SMF Filter Configuration panel is displayed.
About the SMF Filter Configuration Panel

The table on this panel always lists the read-only DEFAULT configuration in the data
dictionary provided by Ironstream. The DEFAULT configuration contains all the
Ironstream-supported SMF record types and metadata information; it cannot be modified
nor deleted.
The table will also list your user-defined filter configurations for gathering specific
field-level data from selected record types. Action buttons are provided so you can add new
configurations, refresh, and close the panel.
Panel 12-1 illustrates the SMF Filter Configuration panel with only the DEFAULT
configuration listed:
Panel 12-1: SMF Filter Configuration - DEFAULT only

Table 12-3 describes the controls available on the SMF Filter Configuration panel.
Table 12-3: SMF Filter Configuration Panel Controls
Control What it does...

New Configuration Invokes the Add Configuration panel, where you can add
an SMF filter configuration using an existing configuration
(e.g., DEFAULT) as a template.
See “Adding a Custom Filter Configuration” on page 12-17.
Refresh Refreshes the panel content taking into account the most
recent updates to have taken place.

Table 12-3: SMF Filter Configuration Panel Controls (continued)

Clicking a configuration name next to the File Icon icon
opens the Configuration CONFNAME panel to view and
modify the configuration’s filter settings.
You can open the DEFAULT configuration for viewing, but
it is in read-only mode with all filters turned on by default.
You can create a customizable copy of the DEFAULT
configuration by clicking the New Configuration button
and use DEFAULT as a template on the Add
Configuration dialog.
To remove an SMF filter configuration, click the Delete
Configuration icon. You will be required to confirm the
delete request in the Confirm Deletion pop-up window.
You cannot delete the DEFAULT configuration.

Adding a Custom Filter Configuration

You can quickly create new configurations by either copying the DEFAULT configuration or
using a previously-customized configuration as a template.
To add a new configuration for customization:
1. On the SMF Filter Configuration panel, click New Configuration.
The Add Configuration panel is displayed:
Panel 12-2: Add Configuration

2. Enter a name for the configuration and an optional description. The configuration name
cannot be longer than eight characters and must follow the standard naming rules for
PDS members.
3. Use the Copy From menu to select a filter configuration to use as a template for the
new configuration.
Note that the read-only DEFAULT configuration contains all supported SMF record
types in the data dictionary with all filters enabled by default. This way you can use it
as a template to create customized configurations.
4. Click Add.
The new configuration is added to the list in the SMF Filter Configuration panel,
where you can then click the configuration name to open it for customization, as
described in “Editing a Filter Configuration” on page 12-18.
Panel 12-3: SMF Filter Configurations

Editing a Filter Configuration

The Configuration CONFNAME panel uses an expandable/collapsible tree format that
enables you to select specific fields within an SMF record type or subtype, so you can control
exactly how much information is forwarded to a destination. Each SMF record type and
subtype can be expanded and collapsed with the green plus and red minus icons. When a
record type is expanded, you can use the state switch icons to enable or disable filtering for
entire subtypes (if available); you can also expand subtypes and enable filtering for only
certain fields in those subtypes, as described in Table 12-4.
Panel 12-4 illustrates a customized Configuration BOBDYLAN panel with all the SMF
record types collapsed.
Panel 12-4: Configuration BOBDYLAN - Collapsed Record Types

Table 12-4 describes the controls available on the Configuration CONFNAME panel.
Table 12-4: Configuration CONFNAME Panel Controls

SMF Fields Lists all the supported SMF record types. When a record
type or subtype is expanded, the column displays all the
fields for which filtering can be controlled.
Description Provides a brief description for all listed SMF record types,
subtypes, and fields.
The state switch icons in the right column provide a visual
indication of whether filtering is enabled. Every record type,
subtype, and field has a state: enabled or disabled. Clicking
the state switch icons toggles their state: when the small
black bar is up and the icon is green, filtering is enabled;
filtering is disabled when the black bar is down and the icon
is red.
The state switch icons allow you to selectively
activate/deactivate filtering at each level: entire record
types, subtypes, and specific fields. For example, you can
define filtering for SMF 119 types but exclude filtering for
subtypes 50–52. While within selected subtypes 32–34, you
can select only the fields you need while excluding all
others.
The switch icon in the panel’s heading line allows you to
enable or disable filtering for all selected fields with a single
click.
The mixed state icon means that filtering for the record
type or subtype is enabled, but only for certain selected
fields within that record type or subtype.
Save Saves your filter configuration selections.
View Configuration Invokes the Viewing Configuration panel, which displays
your filter selections for that configuration in read-only
mode.

Panel 12-5 illustrates a customized Configuration BOBDYLAN panel with the filtering
completely switched off for SMF Type 04. For SMF Type16, filtering is switched off for
subtypes 1–3, as well as for the ICESUBSY, ICEMVSES, ICEMVSXA, and ICEMVS37
fields.
Panel 12-5: Configuration BOBDYLAN - Expanded Record Types

Note: This mechanism works differently for SMF 110 records for CICS monitoring. The
SMF 110 subtypes 1 and 2 do not list the CICS fields belonging to those subtypes when
expanded, which is due to the volume of shared fields in both subtypes. However, selected
fields are still filtered by subtype when either state switch is enabled.
Panel 12-6 illustrates the SMF 110 subtypes with SUBTYPE 1 expanded and enabled:
Panel 12-6: Viewing SMF 110 Subtypes 1 and 2

Viewing a Filter Configuration

Clicking the View Configuration button on the Configuration CONFNAME panel opens
a corresponding Viewing Configuration CONFNAME panel, which reflects the filtering
selections for the currently selected SMF configuration. This panel also uses an
expandable/collapsible tree format that enables you to view the selected fields within an
SMF record or subtype.
Panel 12-7 illustrates a Viewing Configuration BOBDYLAN panel:
Panel 12-7: Viewing Configuration BOBDYLAN

Note that this panel reflects the filtering selections made on the Configuration
BOBDYLAN shown in Panel 12-5: SMF Type 04 is not listed, nor does it list the SMF
Type16 subtypes and the ICESUBSY, ICEMVSES, ICEMVSXA, and ICEMVS37 fields.
The field selections shown on this panel are read-only for verification purposes. However, if
you change the field selections for the current configuration on the Configuration
CONFNAME panel and click Save, then the information displayed on this panel is updated
to reflect those changes.

Using the READ Command to Share SMF Filter Configurations

The READ command can be used to read a file containing any type of control statements,
including another READ command. The purpose of the READ command is to permit the
retention of SMF filtering configuration parameters that can be shared across multiple
instances of Ironstream. A typical scenario for using the READ command would be for the
SELECT, SUBTYPE, INCLUDE, and WHERE parameters.
The READ command is implemented as follows:
"READ":"dsname"
where dsname is the fully-qualified cataloged data set name. This will include a member
name if the file is a PDS (partitioned data set) or a PDSE (extended). All data sets must be
defined as fixed length (RECFM=F) or fixed block (RECFM=FB), with a record length of 80 bytes
(LRECL=80). System symbols and local SET symbols can be in the dsname.
The named data set can contain additional READ statements. There is no limit on the
number of stacked READ statements other than the memory required to have multiple open
data sets and TIOT limits.
The RACF user ID associated with the Ironstream forwarder must have READ access to the
specified data set(s).

Implementing a Custom CICS Monitor Dictionary in Ironstream

Ironstream has the capability to forward all CICS monitoring fields in the SMF 110 record,
including user-defined fields. User modifications are in the monitor control table (MCT) of
CICS and are read at CICS initialization. The resulting modifications are archived during
the start of each CICS instance by writing a custom monitoring dictionary record (Type 110,
Subtype 1, Monitor Class 1) to SMF. Information contained in these Monitor Class 1 records
must be understood by Ironstream for accurate parsing of the Monitor Class 3 records.
This section describes how to enable Ironstream to process SMF 110 monitor records (Class
3) with the standard or customized CICS monitor control table. It includes these topics:
• “The Need for CICS Monitor Dictionary Processing” on page 12-23
• “Process Flowchart: Steps to Implement” on page 12-23
• “Using the CICS DFHMNDUP Utility to Create SMF 110 Dictionary Records” on
page 12-25
• “Using the SSDFGDIC Utility to Process CICS Monitor Records” on page 12-25
• “Using The SSDFGDIC SYSIN Commands” on page 12-30
• “System Messages for a Custom CICS Monitoring Dictionary” on page 12-31
The Need for CICS Monitor Dictionary Processing

CICS provides a set of analytics for each CICS transaction, as described in IBM’s CICS
Transaction Server for z/OS Performance Guide, Part 3: “The CICS monitoring facility”.
This facility allows for inclusion of user fields beyond the initial default set of fields and the
exclusion of unwanted standard fields.
Changes to the monitor fields are implemented via the SIT’s Monitoring Control Table
(MCT) entries. The MCT describes which fields to monitor, their position, data type, and
length in the modified SMF 110 records. In order for Ironstream to be able to properly parse
the modified information contained in the Monitor Class 3 records, the information in the
MCT must be made available to Ironstream.
Process Flowchart: Steps to Implement

This section describes the process required to provide Ironstream with the ability to process
the modified CICS monitor records.

Figure 12-2. Process Flow to Implement a Custom CICS Monitor Dictionary
Step 1: Run DFHMNDUP

Ironstream uses SMF 110: Subtype 1, Monitor Class 1 to gain the ability to properly parse
Monitor Class 3 records. The DFHMNDUP utility creates an SMF 110: Subtype 1, Monitor
Class 1 record from the current MCT for a region.
The information in the MCT may be unique for each CICS version and each CICS region.
Ironstream associates the MCT information (field descriptions) to the data of a Monitor
Class 3 record by matching the APPLID and version of the Class 3 record (the raw CICS
monitor data in the Class 3 record) to the APPLID and version of the Class 1 record (the
dictionary of the CICS monitor data) created by the DFHMNDUP utility.
For more information on the DFHMNDUP utility, see “Chapter 11, Monitoring Dictionary
utility program” of the CICS Transaction Server for z/OS Version 5 Release 3 Operations
and Utilities Guide. The control statements for this utility describe how to specify the
APPLID required by Ironstream. The version is provided by the utility’s LOADLIB.
Ironstream requires a created record (output from the DFHMNDUP utility) for each unique
MCT and CICS version. Since Ironstream also requires APPLID information to be
associated with the MCT information, SSDFGDIC control statements provide the ability to
replicate the information in a single output record from DFHMNDUP for all APPLIDs using
a unique MCT. See the syntax of the CREATE command for SSDFGDIC.
Step 2: Run SSDFGDIC (STEP010 in JCL)

The selected dictionary records are input into Ironstream’s SSDFGDIC program, which
create assembler program statements that provide the dictionary knowledge to Ironstream.
JCL for STEP010 is provided in the Ironstream SAMPLIB member SSDFGDIC. See “Using
the SSDFGDIC Utility to Process CICS Monitor Records” on page 12-25.

Step 3: Run Assembler and Linker (STEP020, STEP030, STEP040,

and STEP050 in JCL)
Assemble and link the assembler program statements illustrated below into the load module
SSDFCICD and SSDFCICX in Ironstream’s load library, and then restart Ironstream.
JCL for these steps is provided in the Ironstream SAMPLIB member SSDFGDIC. For more
information, see “STEP020, STEP030, STEP040, and STEP050” on page 12-26.
Using the CICS DFHMNDUP Utility to Create SMF 110 Dictionary

Records
DFHMNDUP is a CICS utility for creating CICS dictionary records (Type 110, Subtype 1
Class 1). Sample JCL for Ironstream is provided as “STEP010” in SAMPLIB member
SSDFGDIC. The program is documented in “Chapter 11, Monitoring Dictionary Utility
Program (DFHMNDUP)” in the CICS Transaction Server for z/OS Version 5 Release 3
Operations and Utilities Guide. The purpose of this step is to create SMF 110’s Subtype 1
Class 1 records from an existing MCT.
JCL MEMBER for DFHMNDUP

This sample shows the necessary JCL to run the DFHMNDUP utility:
//STEP010 EXEC PGM=DFHMNDUP
//STEPLIB DD DSN=<CICS SDFHLOAD library for the regions using the noted MCT>
// DISP=SHR
//SYSUT4 DD DSN=<created dictionary record>,
// DISP=(NEW,CATLG),
// UNIT=3390,
// SPACE=(TRK,(1,1))
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
MCT=<MCS suffix for this region>
SYSID=<SYSID for LPAR>
GAPPLID=<APPLID of this region>
SAPPLID=<APPLID of this region>
Using the SSDFGDIC Utility to Process CICS Monitor Records

SSDFGDIC is an Ironstream utility to read the SMF 110 monitor dictionary records and
create an assembler program capable of instructing Ironstream how to process monitor
records for each individual CICS region.
There are five required JCL statements to execute this program:
• STEPLIB – to the Ironstream load library.
• SYSPRINT – to an output print data set.
• SMFIN DDNAME – the SMF archive records, or the selected records from the
IFASMFDP job output.
• SSDFDIC1 DDNAME – the created assembler statements.
• SSDFDIC2 DDNAME – the created assembler statements.

STEP010
Sample JCL is provided as STEP010 in the Ironstream SAMPLIB member SSDFGDIC.
STEP020, STEP030, STEP040, and STEP050

The output of STEP010 consists of two sets of assembler statements that can be assembled
into the module SSDFCICD and SSDFCICX. These four steps use the assembler and linkage
editor programs from IBM. Review and modify these steps to conform to your installation’s
standards.
JCL MEMBER for SSDFGDIC

This sample shows the necessary JCL to run the SSDFGDIC utility:
//STEP010 EXEC PGM=SSDFGDIC
//STEPLIB DD DISP=SHR,
// DSN=<IRONSTREAM LOADLIB>
//SMFIN DD DISP=SHR,
// DSN=<SELECTED SMF 110 RECORDS WITH CICS DICTIONARY DEFINITIONS>
//SSDFGDI1 DD DSN=&&STATMNT1,
// DISP=(NEW,PASS,DELETE),
// SPACE=(CYL,(3,1,0),RLSE),
// UNIT=3390,
// DSORG=PS,
// RECFM=FB,
// LRECL=80,
// BLKSIZE=0,
// STORCLAS=SC2,
// DSNTYPE=BASIC
//SSDFGDI2 DD DSN=&&STATMNT2,
// UNIT=3390,
// DSORG=PS,
// RECFM=FB,
// LRECL=80,
// BLKSIZE=0,
// STORCLAS=SC2,
// DSNTYPE=BASIC
//SYSIN DD *
//STEP020 EXEC PGM=ASMA90
//SYSIN DD DSN=&&STATMNT1,
// DISP=(OLD,DELETE,DELETE)
//SYSLIB DD DSN=&&SYSLIB,
// DISP=(NEW,DELETE,DELETE),
// UNIT=3390,
// DSORG=PS,
// RECFM=FB,
// LRECL=80,
// BLKSIZE=80,
// STORCLAS=SC2,
// DSNTYPE=BASIC
//SYSUT1 DD UNIT=SYSDA,
// SPACE=(TRK,(75,75))

// SPACE=(TRK,(75,75))
// SPACE=(TRK,(75,75))
//SYSLIN DD DSN=&&OBJ(SSDFCICD),
// UNIT=3390,
// SPACE=(TRK,(10,10,10)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000)
//STEP030 EXEC PGM=HEWLH096,
// PARM='MAP,LIST,LET,XREF,NCAL'
//SYSLIB DD DSN=<IRONSTREAM LOADLIB>,
// DISP=SHR
//SYSLMOD DD DSN=<IRONSTREAM LOADLIB>,
// DISP=SHR
// DCB=BLKSIZE=1024,
// SPACE=(1024,(200,20))
//SYSLIN DD DSN=&&OBJ(SSDFCICD),
// DISP=SHR
// DD *
ENTRY SSDFCICD
NAME SSDFCICD(R)
//STEP040 EXEC PGM=ASMA90
//SYSIN DD DSN=&&STATMNT2,
// DISP=(OLD,DELETE,DELETE)
//SYSLIB DD DSN=&&SYSLIB,
// DISP=(NEW,DELETE,DELETE),
// UNIT=3390,
// DSORG=PS,
// RECFM=FB,
// LRECL=80,
// BLKSIZE=80,
// STORCLAS=SC2,
// DSNTYPE=BASIC
// SPACE=(TRK,(75,75))
// SPACE=(TRK,(75,75))
// SPACE=(TRK,(75,75))
//SYSLIN DD DSN=&&OBJ(SSDFCICX),
// UNIT=3390,
// SPACE=(TRK,(10,10,10)),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000)
//STEP050 EXEC PGM=HEWLH096,
// PARM='MAP,LIST,LET,XREF,NCAL'
//SYSLIB DD DSN=<IRONSTREAM LOADLIB>,
// DISP=SHR
//SYSLMOD DD DSN=<IRONSTREAM LOADLIB>,
// DISP=SHR
// DCB=BLKSIZE=1024,
// SPACE=(1024,(200,20))

//SYSLIN DD DSN=&&OBJ(SSDFCICX),
// DISP=SHR
// DD *
ENTRY SSDFCICX
NAME SSDFCICX(R)
Understanding the SSDFGDIC Report

This section describes the report generated when running SSDFGDIC with a customized
monitor dictionary module in the Ironstream AUTHLIB.
The following lines are the header lines from the start of the SSDFGDIC program:
* * * SYNCSORT IRONSTREAM(TM) DICTIONARY CREATE PRGM - V2.1.0 - (C) 2014 - 2018
BY SYNCSORT, INC. - ALL RIGHTS RESERVED * * *
SDF7000I START TIME - hh:mm:ss.th DATE - mm/dd/yyyy CURRENT MAINTENANCE -
ptf_number
Next, the control statements are echoed along with the results of processing the commands
on the input file. “Using The SSDFGDIC SYSIN Commands” on page 12-30.
These are followed by an SDF7010I message for each recognized monitor dictionary record:
hh:mm:ss SDF7010I BUILDING CICS ENTRIES BASED ON DICTIONARY FOR JOBNAME
<CICS jobname>, APPLID <CICS applid>, AND CICS VERSION <CICS version> AS
TABLE <table number>
The CICS jobname, CICS APPLID, and CICS version are from the SMFMNJBN,
SMFMNSPN, and SMFMNRVN fields of the SMF 110 record. The SMF 110 record contains
a table of field definitions for this particular region, and is described next in the report. The
table number is an index number of the table of fields representing this region. Multiple
regions may have the same index when they have the same dictionary record.
The SDF7010I message will occur for each region found in the SMFIN DDNAME. The list of
regions represents all regions for which Ironstream will be able to properly format the
modified SMF 110 monitor records. This list should be examined to ensure that it contains
every region that will forward data by Ironstream.
The SDF7011I messages follow the SDF7010I messages:
hh:mm:ss SDF7011I GROUP <group name>, TYPE <field type>, LENGTH <field length>,
CONNECTION <connection id>, OFFSET <location>, NICKNAME <field name>, TABLE
<table index>
This message will occur for each field recognized to be a part of the dictionary table for a
given region. Group name, field type, field length, connection id, location, and field name are
part of the field description from the dictionary record. Table index is the link back to the
SDF7010I message identifying the CICS region in which this information will be used.
When duplicate field names (referenced in CICS manuals as nicknames) are found in the
dictionary record, an SDF7015I message will be written. Duplicate nicknames in the
dictionary record will cause Ironstream to create two JSON pairs with the same name and
possibly different values associated with that nickname. This duplication in the JSON event
causes confusion in follow-on processing as to which value to associate with the field name.

Ironstream resolves this dilemma by creating unique field names when duplicate nicknames
are recognized. The SDF7015I message indicates that a duplicate nickname was found in
the dictionary record and a new nickname has been created to take its place. The new
nickname will be used by Ironstream to create a JSON pair to reference the data originally
represented by the duplicate nickname. Follow-on processing will be required to use the new
unique name and not the duplicate name.
hh:mm:ss SDF7015I Nickname <duplicate field name> renamed as <unique field name>
to allow unique JSON Pair name values
SDF7020-SDF7023 report the number of times each input statement (SYSIN records) cause
a modification to the output created by SSDFGDIC. This should be carefully reviewed to
ensure the desired effect of the input command was realized.
The following messages complete the listing by describing dictionary records read
(SDF7012I), dictionary records skipped as a duplicate record of a region (SDF7013I), and the
number of assembler statements created (SDF7014I).
hh:mm:ss SDF7012I nnnnn SMF RECORDS READ
hh:mm:ss SDF7013I nnnnn SMF RECORDS SKIPPED
hh:mm:ss SDF7014I nnnnn DICTIONARY CARDS CREATED
SDF7007I END TIME - hh:mm:ss.th DATE - mm/dd/yyyy
Assemble and Link the Statements in the Ironstream Load Library

Next, the SSDFCICD and SSDFCICX statements need to be assembled and linked into the
Ironstream load library. Sample JCL is provided as STEP020, STEP030, STEP040, and
STEP050 in Ironstream’s SAMPLIB member SSDFGDIC, as described in “STEP020,
STEP030, STEP040, and STEP050” on page 12-26.

Using The SSDFGDIC SYSIN Commands

This section explains how to use the SSDFGDIC SYSIN commands.
Using SYSIN to Modify the Formatting of Monitor Fields

The specification of formatting routines for individual monitor fields is stated in the
dictionary records. The formatting routine used may be changed by the FORMAT verb in the
input stream. The syntax of the FORMAT statement is:
FORMAT <monitor field> AS <CHAR|HEX|NUMERIC|PACKED|TIME|SPECIAL|FLAG>
Specifying FORMAT will cause each occurrence of <monitor field> to be changed to the
new format. The resulting JSON pair in the CICS EVENT would look like this:
CHAR Created using move

HEX Created as hexadecimal
NUMERIC Created converting field as binary to decimal
PACKED Created converting packed decimal to decimal
TIME yy-mm-dd hh:mm:ss.nnnnnn
SPECIAL 8-byte numeric

1-byte flag
3-byte count
FLAG Binary 0’s and 1’s
Using SYSIN to Duplicate MCTs

DFHMNDUP will create a single SMF 110, subtype 1, class 1 (dictionary record) for the
MCT at a specific version and APPLID. To duplicate the MCT for use as the MCT for
additional regions, the CREATE verb can be used in SSDFGDIC. The syntax of the CREATE
verb is:
CREATE <target APPLID> FROM <source APPLID> AT <V4.2|V5.1|V5.2|V5.3|V5.4>
The source APPLID may be specific or contain the wild cards '*' (0-n character match) or
'%' (exactly one character match). SSDFGDIC will use each matched occurrence of <source
APPLID> to create information for parsing monitor fields in regions whose APPLID is
<target APPLID>.
Dictionary records change in CICS from release-to-release and the monitor record cannot be
used to create information to parse an alternate CICS version. That is, if the MCT is used in
a V5.3 CICS, it cannot be used by way of the CREATE version to support V5.4, etc. Message
SDF7026I will reflect all successful duplications of a MCT record. Statistics provided at the
end of the listing via the SDF7020I-SDF7023I message numbers will report the success of
the CREATE statements.

General Comments on the Control Statement Format for SSDFGDIC

When using SYSIN, the syntax parser for SSDFDIC observes these general rules:
1. The input statements must be fixed block, 80 bytes long.
2. Only the first 72 characters of the input statement are used. Columns 73-80 can be used
for numbering.
3. Statements with an asterisk ‘*’ in column 1 are consider to be comments.
4. Comments can be included in the text by beginning the comment with an /* and ending
the comment with an */. Comments can span multiple lines of text.
5. Commands can span multiple lines.
System Messages for a Custom CICS Monitoring Dictionary

Ironstream messages generated when using a Custom CICS Monitoring Dictionary are in
the SSDF7000–SSDF7027 range and are described in “Ironstream Messages,” on page 27-1.
Sample SMF Filter Configurations

This section provides some examples of typical SMF filter configurations.
Sample Filtering for All Fields in SMF Records

In Ironstream V1.4 and later, a typical configuration file for selecting SMF records and
specific subtypes within an SMF record could look like this:
"SOURCE"
"DATATYPE":"SMF"
"SELECT":"SMF030"
"SUBTYPE":"4,5"
"INCLUDE":"ALL"
Sample Filtering for Specific Fields in SMF Records

Here is an example of a configuration file with a SELECT parameter set for collecting all
data from the record types SMF014 and SMF015, along with another SELECT parameter
for SMF030, but which also uses the SUBTYPE and INCLUDE parameters to only collect
the specified field-level data for subtypes 4 and 5.
"SOURCE"
"DATATYPE":"SMF"
"SELECT":"SMF014,SMF015"
"SELECT":"SMF030"
"SUBTYPE":"4,5"
"INCLUDE":"SMF30WID,SMF30SIT,
SMF30STP,SMF30STD,
SMF30PNM,SMF30USR,
SMF30OSL,SMF30GRP,
SMF30SYN,SMF30RUD,
SMF30SYP,SMF30TID,
SMF30JBN,SMF30CPT,

SMF30PGM,SMF30CPS,
SMF30STM,SMF30ICU,
SMF30UIF,SMF30ISB,
SMF30JNM,SMF30ASR,
SMF30STN,SMF30ENC,
SMF30CLS,SMF30DET,
SMF30_TIME_ON_ZIIP,SMF30CEP,
SMF30_ENCLAVE_TIME_ON_ZIIP,SMF30_DEPENC_TIME_ON_ZIIP,
SMF30DDN,
SMF30BLK"
Note that this sample demonstrates:
• Multiple SMF record types can be selected at once, if there are no SUBTYPE or
INCLUDE commands for them.
• Commands do not have to start in column 1.
• Continuation of a record can be indicated by a trailing comma.
• Continuation records signalled by a comma do not have to start in a particular column.
With the addition of WHERE clause statements in V2.1, field-level filtering can be further
refined by setting field search conditions to select records only when all search conditions
are met. Refer to “Limiting SMF Record Selection with WHERE Search Conditions” on
page 12-7 for examples of WHERE clause usage.
Sample Filtering for All SMF Records Using Control Statements

The Ironstream V2.1 sample library (SSDFSAMP), has a sample configuration file that has
SELECT commands for all the supported SMF record types, which can be accessed using the
following READ command:
"SOURCE"
"READ":"SAMPLIB(ALLSMF)"
where the READ command points to an ALLSMF member in SSDFSAMP that has control
statements to select all the supported record types.

Chapter 13 SYSOUT Forwarding
This chapter describes how to configure the SYSOUT data forwarder to select and forward
data sets to a destination.
Topics:
• “Using the SYSOUT Forwarding Function” on page 13-1
• “SYSOUT Selection and Filtering” on page 13-4
• “Using the Advanced PRINT Data Block Parameters” on page 13-13
• “SYSOUT Forwarding Parameter Examples and Sample Output” on page 13-15
Using the SYSOUT Forwarding Function

Ironstream’s SYSOUT Data Forwarder enables you to select spool data sets and forward
them to a destination. Both active and complete jobs can be selected for forwarding as can
JES input and system data sets. As soon as Ironstream has completed its initialization all
currently active jobs and spool data for completed jobs is examined to see whether any are
eligible for forwarding.
When an active job is selected for forwarding, output lines are sent to a destination as soon
as they are created. For an output data set created as a SPIN data set (FREE=CLOSE), the
original data set is sent and subsequent data sets (assuming a data set with the same DD
name is created) are recognized as they are created and are forwarded to a destination
automatically.
This section of the manual provides an overview of the function; for full details of the
parameters required to set up and activate the SYSOUT forwarding feature of Ironstream,
see the section “SYSOUT Selection and Filtering” on page 13-4.

SYSOUT Forwarding
Configuring Ironstream for SYSOUT Forwarding

To forward SYSOUT data to a destination requires specifying a DATATYPE of SYSOUT in
the SOURCE section of the configuration file. This must be followed by one or more
parameters that together define the output job(s) and optionally the data set(s) within those
jobs that are to be forwarded to a destination.
The primary parameter that selects the job(s) is the SELECT_JOB_IF_job_keyword
parameter, and the parameter that selects data sets is the
SELECT_DATA_SET_IN_JOB_WITH_data_set_keyword. Both these parameters must be
specified in double apostrophes as must the value provided for each parameter. You may
also optionally fine tune the job selection process by using one or more
FILTER_JOB_ON_filter_keyword parameters. For full details of these parameters see
“SYSOUT Selection and Filtering” on page 13-4.
The Selection and Forwarding Process

The selection process occurs in two steps. The first step selects candidate jobs based on
attributes and/or selection values of spool data sets within a job. The second step optionally
qualifies a data set by step name, PROC step name and/or DD name.
The simplest selection is done by defining a job for which all spool data sets are to be
forwarded. You can refine this process by using one or more of a number of provided
selection criteria; examples might be to select data for all batch jobs, all held jobs, or all jobs
with data sets having a particular step name.
The job selection process can be made more granular by using one or more filter criteria once
the basic job selection has taken place. Many filters are available to choose from; examples
are class, destination id., priority, service class and so on. Both job and data set selections
must be specified in a defined sequence as shown later in the section “Job and Data Set
Selection” on page 13-4.
JES input and system data sets: JESJCLIN submitted JCL, JESMSGLG message logs,
JESJCL executed JCL, and JESYSMSG system messages, may also be selected for
forwarding.
Format of Forwarded Spool Data

Each selected data set is forwarded to a destination in block format. A block is defined as a
page of output data if the data set is created with RECFM carriage control, ‘page mode’, or
up to 256 lines of output with non-designated carriage control definitions, ‘line mode’. In
page mode, if a New Page carriage control is not detected within 150 lines Ironstream
considers the block complete and forwards it to a destination. In RECFM, carriage control
definition causes output formatting as if it were printed, causing single, double, triple, new
page, and ‘no advance’ carriage control designations to be enforced. Valid carriage control
options are ‘ASCII’ and ‘machine’.
Parameters are also provided that enable you to exercise control over the way in which the
blocks of data are formed, the insertion of new line characters before print lines are added to
the data block and the point at which Ironstream forwards the data to a destination. This is
discussed further in the following section “Advanced Spool Data Forwarder Options”.

SYSOUT Forwarding
Note that the JES system data sets (JESMSGLG, JESJCL, JESYSMSG, JESJCLIN) and
in-stream SYSIN are forwarded as a block, ignoring the RECFM definition of JES or SYSIN.
Controlling the Job and Output Scan Wait Time

Ironstream can reduce your CPU consumption by providing job and output scanning
wait-time parameters for SYSOUT processing.
Job Scan Wait Time Parameter

By default, Ironstream scans the execution queue for new jobs every 15 seconds. For
instances of Ironstream that forward long-running jobs, this wait time can be increased to
ten minutes (or higher), which can greatly reduce CPU consumption. This would also delay
the forwarding of new work entering the system until this timer expires, which can be as
long as ten minutes after the work enters the system.
The job scan wait time can be updated by including this statement in the configuration file:
"SYSOUT_NEW_JOB_SCAN_WAIT_TIME":"nnnnn"
where nnnnn is the number of seconds to wait from 15-99999. For example, it can be set to
600 for 10 minutes.
To change the default job scan wait time, this control statement must directly follow the
"DATATYPE":"SYSOUT" statement in the configuration file.
Output Scan Wait Time Parameter

When forwarding SYSOUT data to servers, Ironstream forwards all newly-created SYSOUT
data lines that it discovers before pausing. Once all recognized SYSOUT data has been
forwarded, Ironstream will pause for five seconds before searching for more SYSOUT data to
forward. For instances of Ironstream that forward significant numbers of SYSOUT files, this
wait time could be increased to one minute (or higher), which will greatly reduce CPU
consumption. This would also delay the forwarding of newly-created SYSOUT data lines
until this timer expires, which can be as long as one minute after being created.
The output scan wait time can be updated by including this statement in the configuration
file:
"SYSOUT_NEW_OUTPUT_SCAN_WAIT_TIME":"nnnnn"
where nnnnn is the number of seconds to wait from 5-99999. For example, it can be set to 60
seconds for one minute.
To change the default output scan wait time, this parameter must directly follow the
"SYSOUT_NEW_JOB_SCAN_WAIT_TIME":"nnnnn" parameter in the configuration file.
Advanced Spool Data Forwarder Options

The previous section covers the default way in which JES output is formed into data blocks
for forwarding to a destination, however, parameters are available that may be used to
modify the default behavior.
• The PRINT_MODE parameter controls the way in which blocks of data are formed for
forwarding to a destination.

SYSOUT Forwarding
• PRINT_WRAP controls the insertion or otherwise of a new line escape sequence at the
end of each line read from JES and concatenated into the print block.
• PRINT_SEND modifies the default behavior of Ironstream regarding the point at which
it forwards its data block to a destination.
• PRINT_MAXIMUM_LINE_COUNT suspends forwarding of SYSOUT dataset by
specifying a maximum forwarding count.
These facilities are provided to cater for unusual print line/page formats so that they are
easier to process in a destination, to override the normal default of waiting until a full page
of data is available before forwarding it, or to cope with data in JES that is folded in such a
way that wrapping occurs at a column rather than a word break (such as Java log data).
See the section “Using the Advanced PRINT Data Block Parameters” on page 13-13 for full
details of the way in which these parameters are used.
Fields Forwarded from SYSOUT to Ironstream Destinations

For a list of the fields and their format that are forwarded to a destination from SYSOUT
data, see “Forwarded Data Formats” on page A-1.
SYSOUT Selection and Filtering

Overview
When you have specified SYSOUT for the DATATYPE parameter you need to specify
SELECT parameters to tell Ironstream which jobs and data sets to select for forwarding to a
destination, as described in “Job and Data Set Selection” on page 13-4.
More granular selections for a spool job can be made using the FILTER parameter, as
described in “Filtering Criteria” on page 13-5.
You can also you use the EXCLUDE keyword to exclude specific jobs and data sets when
using wild-carded job selections by job name and filtered data sets by OUTCLASS values, as
described in “Job and Data Set Class Exclusion” on page 13-5.
There is a specific sequence in which the SELECT and FILTER parameters must be
specified or the Ironstream initialization will fail if the sequence is not strictly adhered to.
See the section “Selection and Filter Keywords and Rules” on page 13-6 for a full list of the
available parameters and the sequence in which they should be specified.
Job and Data Set Selection

Basic job selection is accomplished by selecting jobs like this:
"SELECT_JOB_IF_JOBNAME":"jobname"
where jobname is any name of a SYSOUT job. jobname can contain the asterisk ‘*’ wildcard
character to represent ‘any number of any character’, and the percent symbol ‘%’ to
represent ‘any one of any character’. The default value for each of these parameters is ‘*’ so
all jobs are selected by default.

SYSOUT Forwarding
For example:
• A specification of "MYJOB*" selects all jobs whose first five characters are ‘MYJOB’.
• A specification of "MYJOB%%*" requires all job names to be 7-bytes long, beginning
with "MYJOB" and having any two characters following "MYJOB".
Jobs may also be selected using a variety of other criteria such as batch jobs, started tasks,
APPC jobs, held jobs, and so on. Further, the FILTER parameter enables jobs to be selected
according to a range of criteria such as class, destination ID, priority, service class and so on.
For a complete list see the section “Selection and Filter Keywords and Rules” on page 13-6.
Once job selection has been made, you can select data sets within the selected job(s) using
the data set selection parameters provided:
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"ddname"
"SELECT_DATA_SET_IN_JOB_WITH_PROCSTEP":"procstep"
"SELECT_DATA_SET_IN_JOB_WITH_STEPNAME":"stepname"
Data sets are selected for forwarding when the given DD name, EXEC step name, or PROC
step name matches the name in the selected job.
As with job selection, for each case you can use the asterisk ‘*’ wildcard character to
represent ‘any number of any character’, and the percent symbol ‘%’ to represent ‘any one of
any character’. The default value for each of these parameters is ‘*’ so all data sets for the
specified job(s) are selected by default.
You can use multiple sets of SELECT_JOB and (optionally) SELECT_DATA_SET
parameters in combination with one another.
See the section “SYSOUT Forwarding Parameter Examples and Sample Output” on
page 13-15 for several examples of possible ways in which the SELECT parameters can be
used.
Filtering Criteria
Once basic job selection has been done, you can further filter the jobs to be forwarded
according to one or more filter criteria.
You can filter jobs based on a keyword using this parameter:
"FILTER_JOB_ON_filter_keyword":"filter_keyword_value"
The filter_keyword has many possible settings that provide great flexibility in the ways that
jobs can be selected. Examples of filter fields are: class, destination, owner, priority, service
class, subsystem and so on.
As with the SELECT parameters, the FILTER parameters must also conform to the
required sequence. See the following section for a complete list given in the required order.
Job and Data Set Class Exclusion

You can further filter the jobs to be forwarded by excluding specified jobs from wild-carded
selection candidates and/or exclude specific data set OUTCLASS values.
Use this statement to exclude candidate job selections from a wild-carded JOBNAME:
"EXCLUDE_JOB_IF_JOBNAME":"<jobname1>,<jobname2>,…<jobname8>"

SYSOUT Forwarding
There can be up to eight job names (or JOBNAME wild-card values) that can be excluded
from the set of jobs the JES matched to the SELECT_JOB_IF_JOBNAME values. This
statement must immediately follow the SELECT_JOB_IF_JOBNAME statement.
Use this statement to exclude candidate SYSOUT data sets by OUTCLASS:

"EXCLUDE_JOB_WHEN_OUTCLASS":"<outclass1>,<outclass2>,…<outclass8>"
Up to eight OUTCLASS values can be used to exclude SYSOUT data sets from processing
that were selected by matching other selection criteria. This statement must follow the
FILTER_JOB_ON_OUTCLASS statement. However, OUTCLASS is not required for
EXCLUDE_JOB_WHEN_OUTCLASS to be recognized.
Selection and Filter Keywords and Rules

This section describes all of the available SELECT, EXCLUDE, and FILTER keywords given
in the order in which they must be specified. Failure to specify the parameters in the correct
sequence will cause the Ironstream initialization to fail. The tables that follow give the
keywords available for job and data set selection.
The sequence number in the first column denotes the order in which they must be specified.
For further clarification, see the examples give in the section “SYSOUT Forwarding
Parameter Examples and Sample Output” on page 13-15.
Job Selection Keywords

This section describes the keywords available for job selection.
Table 13-1: SELECT_JOB_IF_ Keywords
Seqno Keyword Description

1 JOBNAME Select the specified job name. Up to
eight job names can be specified as
value1,value2, ... ,value8.
Note: When excluding specific job Exclude the specified job name(s) from
names from wild-carded job the wild-carded job selection. Up to eight
selections, the EXCLUDE filtering job names can be specified as
statement must directly follow the value1,value2, ... ,value8.
JOBNAME select statement:
"EXCLUDE_JOB_IF_JOBNAME":"jobname"
2 CLASS_IS_XEQ_CLASS_ONLY Select jobs submitted via NJE.

3 APPC Select APPC initiators.
4 BATCH Select batch jobs.
5 STC Select started tasks.

SYSOUT Forwarding
Table 13-1: SELECT_JOB_IF_ Keywords (continued)

6 TSU Select time sharing users.
7 HELD Select jobs that are currently held.
8 NOTHELD Select jobs not currently held.
9 OUTHELD Select jobs whose output is held.
10 OUTNOTHELD Select jobs whose output is not held.
11 OUTDISP Select jobs with the specified output
disposition.
12 OUTNJEWRITE Select jobs whose output is for the given
NJE node.
The SELECT_JOB_IF_JOBNAME keyword may have up to eight values specified as

value1,value2, ... ,value8. When more than one job name is specified the job is selected when
any of the names match. All of the other keywords take a value of YES or NO with the
exception of OUTDISP, which requires one of: WRITE, HOLD, LEAVE or KEEP.
Here are some examples:
"SELECT_JOB_IF_JOBNAME":"*" selects all jobs
"SELECT_JOB_IF_JOBNAME":"CICSPROD" selects only job CICSPROD
"SELECT_JOB_IF_JOBNAME":"CICS*" selects jobs whose name begins with ‘CICS’
"SELECT_JOB_IF_OUTHELD":"YES" selects all held output jobs
Data Set Selection Keywords

This section describes the keywords available for data set selection.
Table 13-2: SELECT_DATA_SET_IN_JOB_WITH Keywords

13 DDNAME Selects data sets having the specified
specific or generic DD name.
14 PROCSTEP Selects data sets having the specified
specific or generic PROC step name.
15 STEPNAME Selects data sets having the specified
specific or generic EXEC step name.
Once the job selection process is complete, each spool data set is examined for a match on DD
name, PROC step name and/or EXEC step name. When Ironstreamfinds a match it forwards
the corresponding spool data set to a destination.

SYSOUT Forwarding
For each keyword you can use the asterisk ‘*’ and the percent symbol ‘%’ wildcard
characters. The default value for each of these parameters is ‘*’ so all data sets for the
specified job(s) are selected by default. A maximum of eight characters in each case may be
specified.
Job Filtering Selection Keywords

This section provides the keywords available for job filtering.
Table 13-3: FILTER_JOB_ON Keywords

16 CLASS Select jobs for the specified class.
Up to eight classes may be specified
as value1,value2, ... ,value8.
17 DEST Select jobs with the specified
default destination. Up to four
destinations may be specified as
18 JOBID Select the job with the given
identifier.
19 JOBIDHI This keyword and the JOBIDLOW
keyword can be used together to
specify a range of job identifiers to
select.
20 JOBIDLOW This keyword and the JOBIDHI
keyword can be used together to
specify a range of job identifiers to
select.
21 MEMBER Selects jobs that ran on the
specified JES member.
22 OJOBID Select the job with the specified
original job identifier (JES2 only).
23 ORGNODE Select jobs with the specified origin
node (JES2 only).

SYSOUT Forwarding
Table 13-3: FILTER_JOB_ON Keywords (continued)

24 OUTCLASS Select jobs with the specified
SYSOUT class. Up to eight classes
may be specified as
Note: When excluding candidate SYSOUT Exclude candidate SYSOUT data

data sets by OUTCLASS, the EXCLUDE sets by OUTCLASS. Up to eight
filtering statement must directly follow the classes can be specified as
OUTCLASS select statement: value1,value2, ... ,value8.
"EXCLUDE_JOB_WHEN_OUTCLASS":"outclass"
However, OUTCLASS is not required for
EXCLUDE_JOB_WHEN_OUTCLASS to be
recognized.
25 OUTDEST Select jobs with the specified
SYSOUT destination. Up to four
destinations may be specified as
26 OUTOWNER Select jobs having the specified
SYSOUT owner.
27 OWNER Select jobs with the specified
owner.
28 PRIORITY The job priority (0 to 15)
29 SCHENV Select jobs assigned the specified
scheduling environment name.
(Jobs only have a scheduling
environment assigned if they have
completed conversion processing
and have not completed execution
processing).
30 SECLABEL Select jobs that are assigned the
specified SECLABEL by the
security product.
31 SRVCLASS Select jobs assigned the specified
WLM service class. (Jobs only have
service classes assigned if they
have completed conversion
processing and have not completed
execution processing).

SYSOUT Forwarding
Table 13-3: FILTER_JOB_ON Keywords (continued)

32 SUBSYS Select jobs for the specified
subsystem.
33 SYSTEM Select jobs for the specified system
identifier.
34 VOLSER Selects jobs residing on the
specified spool volume.
35 WRITER Select jobs associated with the
specified external writer name.
36 XEQNODE Select jobs for the specified NJE
node.
37 PHASE Select jobs with the specified
execute phase.
For descriptions of the valid
PHASE values for JES2 and JES3,
see “Values When Using the
PHASE Keyword for Filtering Jobs”
on page 13-10.
The FILTER_JOB_ON_CLASS and FILTER_JOB_ON_OUTCLASS can have up to eight

values specified as value1,value2, ... ,value8. FILTER_JOB_ON_DEST and
FILTER_JOB_ON_OUTDEST may have up to four values specified as
value1,value2, ..., value4. When more than one value is specified, the job is selected when
any of the given values match.
Remember that both the asterisk wildcard character and the single character wildcard
percent symbol can be used in any of the job selection keyword values.
Values When Using the PHASE Keyword for Filtering Jobs

This section provides the valid values for the PHASE keyword for filtering jobs. For valid
configuration file sequencing, “FILTER_JOB_ON_PHASE”:”value”, it must occur after the
FILTER_JOB_ON_XEQNODE keyword and before the PRINT_MODE keyword.
Table 13-4 describes the PHASE keyword values for JES2.
Table 13-4: JES2 PHASE Keyword Values
Value Description
NPUT Job is active in input processing.
WTCONV Job is queued for conversion.
CONVERT Job is actively converting.

SYSOUT Forwarding
Table 13-4: JES2 PHASE Keyword Values (continued)
Value Description
VOLWT Job is queued for setup (not currently used).
SETUP Job is active in setup (not currently used).
SELECT Job is queued for execution.
ONMAIN Job is actively executing.
SPIN JES2 is processing spin data sets for the job.
WTBKDN Job is queued for output processing.
BRKDWN Job is active in output processing.
OUTPT Job is on the hard copy queue.
WTPURG Job is queued for purge.
PURGE Job is currently being purged.
RECEIVE Job is active on an NJE SYSOUT receiver.
WTXMIT Job is queued for execution on another NJE node.
XMIT Job is active on an NJE job transmitter.
EXEC Job has not completed execution (combines multiple requests).
POSTEX Job has completed execution (combines multiple requests).
Table 13-5 describes the PHASE keyword values for JES3.

Table 13-5: JES3 PHASE Keyword Values
Value Description
NOSUB No sub-chain exists.
FSSCI Job is active in conversion/interpretation in an FSS address
space.
PSCBAT Job is awaiting post-scan (batch).
PSCDSL Job is awaiting post-scan (demand select).
FETCH Job is awaiting volume fetch.
VOLWT Job is awaiting start setup.
SYSSEL Job is awaiting or active in MDS system selection.
ALLOC Job is awaiting resource allocation.

SYSOUT Forwarding
Table 13-5: JES3 PHASE Keyword Values (continued)
Value Description
VOLUAV Job is awaiting unavailable volume(s).
VERIFY Job is awaiting volume mount(s).
SYSVER Job is awaiting or active in MDS system verification.
ERROR Job encountered an error during MDS processing.
SELECT Job is awaiting selection on main.
ONMAIN Job is scheduled on main.
BRKDWN Job is awaiting breakdown.
RESTART Job is awaiting MDS restart processing.
DONE Main and MDS processing complete for job.
OUTPT Job is awaiting output service.
OUTQUE Job is awaiting output service writer.
OSWAIT Job is awaiting RSVD services.
CMPLT Output service complete for job.
DEMSEL Job is awaiting selection on main (demand select job).
EFWAIT Ending function request waiting for I/O completion.
EFBAD Ending function request not processed.
MAXNDX Maximum request index value.

SYSOUT Forwarding
Using the Advanced PRINT Data Block Parameters

As well as the selection and filtering parameters described above, additional parameters are
available to modify the way in which the print data blocks are formed, inserts new line
characters before print lines are added to the data block, and you may also change the
timing of Ironstream’s forwarding of data to a destination.
Depending on the type of JES data you are forwarding to a destination, it may be useful to
change one or more of the default options to produce a more favorable outcome in a
destination. The examples given later show how these parameters can be used to achieve
specific outcomes.
"PRINT_MAXIMUM_LINE_COUNT":"<maximum allowed line count>"

This parameter can be used to discontinue forwarding SYSOUT data and close
the SYSOUT file when the forwarding count is at the maximum allowed line
count value. The value of maximum allowed line count can be 1-999999999.
"PRINT_MODE":"RECFM" | "LINE" | "ANY_ADVANCE"

This parameter controls the way in which Ironstream forms its blocks of print
data for forwarding to a destination.
RECFM – The default. A block is considered complete when a New Page carriage
control command is detected (page mode), or when 150 lines have been processed
without a New Page being detected. This means that full pages can be viewed in a
destination and makes searching for text by page data easy. It can mean,
however, that depending on the speed at which the print lines are being created,
it may take longer to appear in a destination than you require.
LINE – When LINE is specified for this parameter each line is sent immediately
as a block of data to a destination. Although this means that print data is sent
near real-time to a destination, it has the disadvantage that if lines are wrapped
they cannot be searched across the wrap point in most destinations:
Note: Since Splunk displays lines in “newest to oldest” sequence, wrapped lines
would be seen last-line first.
ANY_ADVANCE – This setting causes any page advance in the JES output with
the one exception of single line spacing, to force the block to be completed and
forwarded to a destination. Such ‘pseudo pages’ (as for example in log4j and
TRCDATA) will therefore be forwarded in near real-time to a destination.
Note: Similar to LINE mode, wrapped lines break the ability to search across
wrap point.
"PRINT_SEND":"PRINT_MODE" | "EOF" | "JAVA" | "JSON" | "RAW"

This parameter can be used to modify the timing of Ironstream’s transmission of
the data blocks to a destination.

SYSOUT Forwarding
PRINT_MODE – The default. Data is forwarded according to the setting of the

PRINT_MODE parameter. So, by default a block of data is forwarded when either
150 lines have been processed from the JES Spool, or a New Page carriage control
command is detected.
EOF – By specifying EOF (end-of-file) for this parameter, Ironstream sends any
data to the destination since the last EOF indications, regardless of the setting of
the PRINT_MODE parameter (although the PRINT_MODE setting will be
honored as far as is possible).
JAVA – For instances of SYSOUT data sets created by active Java logs, the JAVA
parameter enables Ironstream to recognize Java events by line lengths, syntax,
and indents, which reduces the number of times multiple Java log events are
forwarded as single events. As a result, the JAVA parameter reduces
Ironstream’s memory requirements, forward smaller, single events to improve
parsing, and makes Java logs independent of other SYSOUT transmission timing
attributes.
JSON – Provides the ability to insert SYSOUT data records in a JSON event. The
JSON named pair "TEXT":"" is removed and replaced with the SYSOUT data
record. The assumption is that the SYSOUT data record is legitimate JSON
syntax. A curly bracket completes the JSON event. For example output when
using the JSON option, see “JSON Output Using PRINT_SEND” on page 13-17.
RAW – Provides the ability to forward platform SYSOUT data records without
including any JSON syntax with the event; this way, each SYSOUT line becomes
a single forwarded event.
"PRINT_WRAP":"LEAVE" | "UNFOLD"
This parameter can be used to modify the way that Ironstream inserts new line
characters ‘\n’ at the end of each print line as it adds them to the current data
block in storage.
LEAVE – The default. Each line of print data read from JES is added with a new
line escape sequence appended.
UNFOLD – A specification of UNFOLD has the opposite effect, concatenating the
line directly with the preceding line without any new line being inserted. This
means that the lines appear in a destination as one long line.
Note: Splunk can be set to Format/Wrap/Yes to make the data easier to read.
Using Advanced Options to Process Log4j Data

Recognizing smaller event groups will enable data to be forwarded from Ironstream to the
destination sooner because the end of an event will be recognized more quickly, making the
data more useful for downstream diagnostics.
Some log4j data has been found to have a carriage control position inserted into the data
because of the RECFM designation. Also, each recorded incident may have a ‘0’ (double
space) as a carriage control character for the new incident. This can lead to data being
inappropriately formatted when it is forwarded to a destination. The advanced option
parameters can be used to get around issues such as these and derive better results when
the data is being viewed in a destination.

SYSOUT Forwarding
One impact of choosing all the default options for log4j data is that it will not arrive at the
destination near real-time since Ironstream will be waiting for the New Page carriage
control or the 150-line limit to be reached in its internal data block. Should it be important
that the data arrives near real-time, you could choose instead to specify LINE for the
PRINT_MODE parameter leaving the other two advanced options parameters to default.
This would cause the data to be forwarded line-by-line, but bear in mind that it has the
disadvantage that wrapped lines cannot be searched across the wrap point in most
destinations, and in Splunk they are also seen last-line first.
An alternative would be to choose the ANY_ADVANCE specification for the PRINT_MODE
parameter leaving the other two advanced options parameters to default. Since this causes
Ironstream to complete each data block at any page advance in the JES output (with the
exception of single line spacing), Ironstream would send the log4j data to a destination at
each “pseudo page” boundary. Although not as rapid as the LINE setting, data would appear
in a destination faster than using the default value, but again this has the disadvantage that
wrapped lines cannot be searched across the wrap point in most destinations, and in Splunk
they are also seen last-line first.
You could modify the disadvantage in each of the above two possible configurations using
the UNFOLD option for the PRINT_WRAP parameter, and EOF or JAVA for the
PRINT_SEND parameter. Even though using these options would mean that wrapped lines
would be merged to create long lines in most destinations, it is possible to aid viewing in
Splunk by using the Format/Wrap/Yes option.
The principles outlined in this section can be applied to other scenarios in which the print
data forwarded to a destination does not appear in the way you would expect or desire. By
examining the format of the data as it is created in JES by the application, you should be
able to choose a combination of advanced options that improve its appearance in Spunk and
thereby the ease with which it can be examined.
SYSOUT Forwarding Parameter Examples and Sample Output

This section contains a number of examples of the way in which the SYSOUT Data
Forwarding selection parameters can be used. It also includes examples of filtered SYSOUT
output.
SYSOUT Forwarding Examples

Select Output from a DD Name
This selection syntax will forward all output from job PRODJOB1 with DDNAME of
SYSPRINT created in a job step whose name matches STEP*.
"DATATYPE":"SYSOUT"
"SELECT_JOB_IF_JOBNAME":"PRODJOB1"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"SYSPRINT"
"SELECT_DATA_SET_IN_JOB_WITH_STEPNAME":"STEP*"

SYSOUT Forwarding
Select Output from Two Separate DD Names of a Job

This selection forwards all output from job PRODJOB2 with DDNAME of ACCOUNTS, or
TRIALBAL created in jobstep STEP010.
"DATATYPE":"SYSOUT"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"ACCOUNTS"
"SELECT_DATA_SET_IN_JOB_WITH_STEPNAME":"STEP010"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"TRIALBAL"
"SELECT_DATA_SET_IN_JOB_WITH_STEPNAME":"STEP010"
Select MSGUSR from all Jobnames Beginning with ‘CICS’

This selection syntax will forward all output from CICS started tasks or batch jobs, either
active or in the output queue, with job names beginning with ‘CICS’ and containing a DD
name of MSGUSR.
"DATATYPE":"SYSOUT"
"SELECT_JOB_IF_JOBNAME":"CICS*"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"MSGUSR"
Select JESMSGLG from a Production IMS Message Processor

This selection syntax will forward all JES messages from the JES message log (JESMSGLG)
to a destination for IMS jobs with the job name beginning with PRODIMS.
"DATATYPE":"SYSOUT"
"SELECT_JOB_IF_JOBNAME":"PRODIMS*"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"JESMSGLG"
Select JESYSMSG from jobs DFHSM and TM1

This selection syntax will forward all system messages from the JES system message log
(JESYSMSG) to a destination for archival job DFHSM and tape management job TM1.
"DATATYPE":"SYSOUT"
"SELECT_JOB_IF_JOBNAME":"DFHSM,TM1"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"JESYSMSG"
Select Submitting JCL from Started Tasks

This selection syntax will forward all submitted JCL for started tasks to a destination:
"DATATYPE":"SYSOUT"
"SELECT_JOB_IF_JOBNAME":"*"
"SELECT_JOB_IF_STC":"YES"
"SELECT_DATA_SET_IN_JOB_WITH_DDNAME":"JESJCLIN"

SYSOUT Forwarding
SYSOUT Data Forwarding Examples

JSON Output Using PRINT_SEND
This PRINT_SEND output shows a before-and-after example when using the JSON options
to insert SYSOUT data records in a JSON event. Note that in the “Forwarded Data”
example, the JSON named pair "TEXT":"" is removed and replaced with the SYSOUT data
record and that a curly bracket completes the JSON event.
SYSOUT Data
{"Id":"ABC01","TranID":"A9902","Logtime":12,"Archive":"Yes","Status":"Complete"}
{"Id":"ABC01","TranID":"B3200","Logtime":34,"Archive":"Yes","Status":"Complete"}
{"Id":"AMC05","TranID":"A9902","Logtime":15,"Archive":"No","Status":"Complete"}
Forwarded Data
{"MFSOURCETYPE":"SYSOUT","SYSNAME":"GD01","SMFID":"GD01",
"DATETIME":"2018-08-02 06:28:33.15 -0400","JOBNAME":"SDFPRTJ","JOBID":"JOB08113",
"PROCSTEP":"","STEPNAME":"PRINT","DDNAME":"SYSUT2","SYSNAME_WHERE_ACTIVE":"",
"DSID":"1",{"Id":"ABC01","TranID":"A9902","Logtime":12,"Archive":"Yes","Status":"Complete"}}
"DSID":"1",{"Id":"ABC01","TranID":"B3200","Logtime":34,"Archive":"Yes","Status":"Complete"}}
"DSID":"1",{"Id":"AMC05","TranID":"A9902","Logtime":15,"Archive":"No","Status":"Complete"}}

SYSOUT Forwarding

Chapter 14 Alerts and SyslogD Forwarding
This chapter describes the optional Network Monitoring components that enable alert
monitoring and SyslogD forwarding.
Topics:
• “Overview of Network Management Components” on page 14-2
• “Configuring ZEN for Ironstream” on page 14-2
• “ZEN Component Alert Generation” on page 14-3
• “The OSA MONITOR (ZOM)” on page 14-3
• “The LINUX MONITOR (ZLM)” on page 14-7
• “FTP CONTROL (ZFC)” on page 14-8
• “The EE MONITOR (ZEM)” on page 14-10
• “The IP MONITOR (ZIM)” on page 14-13
• “Routing SyslogD Messages to Ironstream” on page 14-19
• “More Information about Alerts and SyslogD Forwarding” on page 14-20

Alerts and SyslogD Forwarding
Overview of Network Management Components

There are five Network Management components whose monitoring creates alerts:
• IP MONITOR (ZIM)
• EE MONITOR (ZEM)
• FTP CONTROL (ZFC)
• OSA MONITOR (ZOM)
• LINUX MONITOR (ZLM)
These components are optional so you may not have installed them; if this is the case this
chapter can safely be ignored. All these components are available for download from the
Syncsort Customer Support Portal.
All alerts are routed centrally by ZEN according to the alert’s defined routing options which
can be set/updated according to your local requirements.
Updates to an alert definition is via the ZEN Desktop’s Admin/Alert Admin option which
invokes the ‘Update Alert Settings’ panel. This panel lists the alerts for all installed ZEN
components and any alert definition can be accessed for update using a left-click. (Alerts are
supplied in XML format and all are held in zFS/HFS directory \client\alerts in the directory
hierarchy).
Routing options for alerts are:
• SYSOUT
• Archive
• Console
• Netview
• SNMP Trap
• email
• Ironstream
ZEN has support built in to send alerts via XCF to Ironstream for onward routing to Splunk
Enterprise. ZEN also has support for routing SyslogD messages to Ironstream. This is
discussed later in the section “Routing SyslogD Messages to Ironstream” on page 14-19.
Configuring ZEN for Ironstream

One new parameter, ‘Ironstream’, is provided to activate and configure the ZEN to
Ironstream routing function. It is specified like this:
Ironstream XCF-groupname XCF-membername <Alerts <SyslogD>>
The XCF_groupname and XCF_membername tie up with the equivalent definitions in the
Ironstream configuration. Both the Alerts and SyslogD keywords are optional and ‘Alerts’ is
assumed if both are omitted. The provision of the two keywords enables either or both of the
available data sources to be routed to Ironstream. The full definition of this parameter can
be found in the ZEN Configuration and Reference manual.

The support in Ironstream for receiving alerts and SyslogD data from ZEN is configured by
specifying a source type of ‘XCF’ in the SOURCE section of the configuration file. Also in the
SOURCE section the XCFGROUP and XCFMEMBER parameters must be specified to
define the XCF group and member name that Ironstream should join to receive the data
from ZEN. See “XCF Subparameters” on page 7-25 for the description of these parameters.
ZEN Component Alert Generation

Although all alerts have the ‘Route to Ironstream’ option set as default, this does not
necessarily mean that Ironstream will immediately receive every alert defined in all ZEN
Network Management components. This is because not all alerts are generated by default,
indeed in some components most alerts are not generated by default.
This means that you may need to do at least some configuration in one or more of the ZEN
components you have downloaded and activated in order to transfer the alerts you require in
Splunk.
The remainder of this document lists for each ZEN component the alerts that are issued by
default, or ‘Out-Of-The-Box’ (‘OOTB’ for short), and which configuration or administration
options need to be reviewed in each ZEN component to activate alerts that are not issued by
default.
The OSA MONITOR (ZOM)

The Alert Monitoring Function in the OSA MONITOR is initially set immediately after
installation by the ‘Alerts’ parameter in the supplied OSA MONITOR’s Configuration
Profile. The default for this parameter is ‘Yes’ so all enabled OSA MONITOR alerts will
be issued by default.
Alert Monitoring can be deactivated should it not be required by changing this option to ‘No’
and restarting the OSA MONITOR. Alternatively it can be started and stopped dynamically
in the on-line OSA Alert Rules panel accessed using the ZEN drop-down menu option
Admin/OSA Admin/Rules and Alerts.
The OSA MONITOR has five alert types, however, three of them can be issued under many
circumstances. For example, the ‘Status Change’ alert is issued when one of a set of MIB
field values changes and there are 17 such MIB fields; similarly, the ‘New Errors
Encountered’ alert can be issued for any one of 49 different MIB counters. Further, each of
these two types of alert can be individually activated/deactivated.
The tables below show the ZOM-related alerts as they are grouped in the OSA Alert Rules
panel with an indication as to whether they are enabled out-of-the-box (OOTB).

The first table lists MIB Performance Thresholds which when exceeded cause the ‘Out Of
Range’ alert to be issued; this issues message ZOM4002I as well as sending the alert to ZEN:
Table 14-1: MIB Performance Threshold Alerts
MIB Name Low High OOTB?
ibmOSAExpChannelPCIBusUtil1Min 0 90 Yes
ibmOSAExpChannelProcUtil1Min 0 90 Yes
ibmOSAExpV2PerfProcUtil1Min 0 90 Yes
zomOSAExcessiveQDepth 0 90 Yes
Below is the table of MIBs which cause the ‘Status Change’ alert to be issued if the OSA
MONITOR detects that the MIB has changed state. Message ZOM4004I is issued when this
is the case as well as the alert being sent to ZEN:
Table 14-2: MIB Status Change Alerts
MIB Name OOTB?
ifOperStatus Yes
ibmOsaExpEthLanTrafficState Yes
ibmOsaExpEthDisabledStatus Yes
ibmOsaExpTRLanTrafficState Yes
ibmOsaExpTRDisabledStatus Yes
ibmOsaExpTRRingStatus Yes
ibmOsaExpTRRingState Yes
ibmOsaExpTRRingOpenStatus Yes
ibmOsaExpATMLanTrafficState Yes
ibmOsaExpATMDisabledStatus Yes
ibmOsaExpATMClientCurrentState Yes
ibmOsaExp10GigEthLanTrafficState Yes
ibmOsaExp10GigEthDisabledStatus Yes
ibmOsaExp3LanTrafficState Yes
ibmOsaExp3DisabledStatus Yes
ibmOsaExp5SLanTrafficState Yes
ibmOsaExp5SDisabledStatus Yes

There are two ‘special’ alerts issued when the OSA MONITOR directly detects a problem
with an OSA either congested or not responding at all:
Table 14-3: OSA MONITOR-Generated Alerts
OSA MONITOR Alerts OOTB?

zomOSACongested Yes
zomOSANotResponding Yes
The first condition causes the ‘Queue Congested’ alert to be issued and message ZOM4005I
is issued at the same time. For the second condition, the ‘OSA Not Responding’ alert is
issued and message ZOM4001I is issued at the same time.
Below is the table of MIBs which cause the ‘New Errors Encountered’ alert to be issued if the
OSA MONITOR detects that the MIB counter has increased in value since the last sample
was taken. Message ZOM4003I is issued when this is the case as well as the alert being sent
to ZEN:
Table 14-4: MIB Overall Counter Increase Alerts
MIB Name OOTB?

ibmOsaExpEthInUnknownIPFrames No
ibmOsaExpTRLineErrorCount No
ibmOsaExpTRBurstErrorCount No
ibmOsaExpTRACErrorCount No
ibmOsaExpTRAbortTransErrorCount No
ibmOsaExpTRInternalErrorCount No
ibmOsaExpTRLostFrameErrorCount No
ibmOsaExpTRRcvCongestionCount No
ibmOsaExpTRFrameCopyErrorCount No
ibmOsaExpTRTokenErrorCount No
ibmOsaExpTRFullDuplexErrorCount No
ibmOsaExpTRSoftErrorCount No
ibmOsaExpTRHardErrorCount No
ibmOsaExpTRSignalLossErrorCount No
ibmOsaExpTRTransmitBeaconCount No
ibmOsaExpTRRecoveryCounter No

Table 14-4: MIB Overall Counter Increase Alerts (continued)
MIB Name OOTB?

ibmOsaExpTRLobeWireFaultCount No
ibmOsaExpTRRemoveReceivedCount No
ibmOsaExpTRSingleStationCount No
ibmOsaExpATMErrLePDUDiscIn No
ibmOsaExpATMNonErrLePDUDiscOut No
ibmOsaExpATMSVCFailures No
ibmOsaExp10GigEthDeferCount No
ibmOsaExp10GigEthRemoteFaultCnt No
ibmOsaExp10GigEthLocalFaultCnt No
ibmOsaExp3AlignmentErrorCnt No
ibmOsaExp3CRCErrorcnt No
ibmOsaExp3MissedPacketCnt No
ibmOsaExp3SingleCollisionCnt No
ibmOsaExp3MultipleCollisionCnt No
ibmOsaExp3ExcessiveCollCnt No
ibmOsaExp3LateCollisionCnt No
ibmOsaExp3DeferCnt No
ibmOsaExp3SequenceErrorCnt No
ibmOsaExp3ReceiveNoBufferCnt No
ibmOsaExp3ReceiveLenErrorCnt No
ibmOsaExp3ReceiveJabberCnt No
ibmOsaExp3ReceiveUndersizeCnt No
ibmOsaExp3ReceiveOversizeCnt No
ibmOsaExp5SAlignmentErrorCnt No
ibmOsaExp5SFCSErrorCnt No
ibmOsaExp5SLengthErrorCnt No
ibmOsaExp5SReceiveJabberCnt No

Table 14-4: MIB Overall Counter Increase Alerts (continued)
MIB Name OOTB?

ibmOsaExp5SReceiveUndersizeCnt No
ibmOsaExp5SReceiveOversizeCnt No
ibmOsaExp5SNoFreeDescOnNIC No
ibmOsaExp5SNoFreeDescOnLANDriv No
ibmOsaExp5SNoFreeRecvDesc No
For each of the OSA MONITOR alerts, the full details of the MIB field involved, counter
value, or range exceeded is provided.
Key Points:
• The Alert Monitor is activated by default in the OSA MONITOR so all enabled alerts
will be issued.
• The following alerts are issued if the default settings in the ‘Rules and Alerts’ panel
remain as they are at installation time:
▪ The four forms of the ‘MIB Performance Threshold’ alert issued when a pre-defined
MIB value falls outside the range 0 to 90 percent
▪ The ‘OSA Not Responding’ alert
▪ All of the ‘Status Change’ alerts
▪ The ‘Queue Congested’ alert
▪ None of the forms of the ‘New Errors Encountered’ alerts will be issued without
activating the appropriate alert definition from the ‘OSA Alert Rules’ panel accessed
using the ZEN drop-down menu option Admin/OSA Admin/Rules and Alerts.
The LINUX MONITOR (ZLM)

Alert Monitoring in the LINUX MONITOR is achieved by defining one or more Monitoring
Profiles using the Administer Profiles option from the drop-down Admin/Linux Admin
menu. A Monitoring Profile contains a set of thresholds that the Alert Monitoring function
checks once a minute and raises appropriate alerts when it detects that thresholds have
been exceeded. Monitoring for a system is activated by assigning a Monitoring Profile that
has some thresholds defined to that system; it is possible to monitor several systems with
the values from the same Monitoring Profile.
Immediately after installation, although a default monitoring profile is supplied it will not
be assigned to any Linux systems and therefore no monitoring will take place. Consequently,
no LINUX MONITOR alerts will be issued by default.
The LINUX MONITOR has seven alerts that are directly related to the threshold values
that can be set in a Monitoring Profile. The alerts are:

• zLinux high memory utilization

• zLinux high active process count
• zLinux high user cpu utilization
• zLinux tcp retransmissions
• zLinux tcp connections
• zLinux high system cpu utilization
• zLinux high swap utilization
Note that even if the supplied default Monitoring Profile is assigned to a system, only the
first four alerts shown in the list above are active and each is set to a value of 50%. It is
therefore highly likely that some configuration will be required.
Key Points:
• Immediately after installation, no LINUX MONITOR alerts will be issued by default.
• It is necessary to assign a Monitoring Profile to a system to cause alerts to be issued.
This could be the default Monitoring Profile although if so it is highly recommended that
the provided values are reviewed before use. You would usually define one or more of
your own Monitoring Profiles to assign to systems.
You can display the contents of a Monitoring Profile and also assign a new Monitoring
Profile to a system using the ‘Display and Assign Monitoring Profiles’ panel accessed
using a left-click on the Profile name displayed against the system on the ‘Linux System
List’ panel accessed from the Linux drop-down menu.
• Once a profile has been assigned to a system, if any of the threshold values defined are
exceeded the associated alert will be issued.
FTP CONTROL (ZFC)

Alerts in ZEN FTP CONTROL are based on messages issued when a variety of FTP events
occur. Examples are when an FTP session completes, or when a user fails RACF login
security checks. All but two of the defined alerts are enabled at installation time.
Immediately after installation and all post-installation setup has been completed and ZEN
FTP CONTROL is active and intercepting FTP activity, of the thirty available alerts, all but
two are issued by default.
The table below shows all of the FTP-related alerts along with their ZEN-assigned Class and
Category:
Table 14-5: FTP Control Alerts
Alert Text Category OOTB?

Invalid userid/password security Yes
Successful inbound file transfer transfer Yes
Successful outbound file transfer transfer Yes

Table 14-5: FTP Control Alerts (continued)

Unsuccessful inbound file transfer failure Yes
Unsuccessful outbound file transfer failure Yes
Successful deletion data set Yes
Failed deletion failure Yes
Successful append to existing file data set Yes
Failed append to existing file failure Yes
Successful rename data set Yes
New file name data set Yes
Failed rename failure Yes
Unrecognized command command Yes
End of Server session session Yes
End of Client session session Yes
Incomplete rename failure Yes
Incomplete append failure Yes
Incomplete deletion failure Yes
Incomplete send failure Yes
Incomplete receive failure Yes
Successful Client transfer transfer Yes
Completed Client transfer transfer Yes
RACF login failure security No
Client connection rejected by RACF/SAF security No
Key Points:
• All but two of the FTP CONTROL alerts will be issued as soon as the component is
active and intercepting FTP activity.
• To activate the two alerts not activated at start-up requires RACF definitions to be
created that secure the FTP Server and Client. You can find a description of this process
in the ZEN FTP CONTROL Configuration and Reference manual, in “Chapter 5
Implementing FTP Security”, section “Lock Down the FTP Server and Client”.

• Note that currently no alerts related to client-FTP activity (that is, outbound FTP from
z/OS) are issued.
The EE MONITOR (ZEM)

EE MONITOR alerts are generated by more than one feature of this ZEN component and
although some alerts are issued ‘out-of-the-box’, others require configuration.
Alerts in the EE MONITOR are grouped into three classes:
• APPN. These alerts cover a variety of events ranging from changes in status of EE
endpoints and CP-CP connection outages to threshold-related events such as excessive
round-trip times and high RTP hop counts; some alerts depend on the definition of an
EE MONITOR configuration parameter. Some APPN alerts are issued by default
while others are not.
• Message. These alerts are issued when the EE MONITOR’s PPO interface detects
VTAM messages of a defined severity. None of these are issued by default primarily
because not all customers configure the EE MONITOR as a PPO.
• SAW. These are issued when the EE MONITOR’s ‘Session Awareness’ feature detects a
specific session event. None of these are issued by default.
The Alerting function in the EE MONITOR is driven both by certain VTAM events that
cause messages to be issued (automatic alerting) and by user-defined Monitoring Profiles
that are assigned to systems using Profile Assignments (user-defined alerting). The Profile
definition and assignment functions are both accessed via Admin/SNA Admin options
accessed from the ZEN Desktop.
Some of the EE alerts require the PKTTrace parameter in the EE MONITOR’s configuration
file to be set to ‘Start’ or ‘On’ and it should be noted that this is not the default. Without
packet tracing active some of the EE alerts will not be issued.
A set of default Monitoring Profiles are supplied with the EE MONITOR that define options
for monitoring APPN, VTAM sessions and local hosts. These default profiles enable some
alerts and disable others. In the case of the APPN alerts, a pre-defined supplied profile
assignment to all systems for the default monitoring profile is made. Therefore, all CPs will
be monitored using the default profile settings.
The table shown below lists the full set of alerts that can be issued from the EE MONITOR.
The final column contains an indication of whether that alert will be issued as soon as the
EE MONITOR is activated and therefore indicates whether that alert will be available to
Ironstream by default.
Table 14-6: EE MONITOR Alerts

No alternate routes availability Yes
New APPN endpoints detected configuration Yes

Table 14-6: EE MONITOR Alerts (continued)

ARB Critical Slowdowns performance Yes
CP-CP Connection outage availability Yes
CP-CP Connection outage availability Yes
EE Connection Inactive availability Yes
New APPN endpoints discovered configuration Yes
EE endpoint status changed configuration Yes
EE local endpoints active configuration Yes
EE local endpoint inactive configuration Yes
EE settings changed configuration Yes
EE XCA inactive configuration Yes
NLP Retransmissions performance Yes
High active RTP count performance Yes
High LU-LU session count performance Yes
High Send Rate performance Yes
High round trip time performance Yes
VTAM Start Option change configuration Yes
Ferret Restart security Yes
New EE connections detected configuration Yes
New IP Address detected configuration Yes
New NETID detected configuration Yes
XCA Major Nodename change configuration Yes
ARB Level 2 Slowdowns performance Yes
No CP-CP connections configuration Yes
Path switch notifications configuration Yes
No XCA node active configuration Yes
Ferret Password Warning security Yes
Path switch fail availability Yes

Table 14-6: EE MONITOR Alerts (continued)

ARB Level 1 Slowdowns performance Yes
Excessive Gap Packets performance No
NLPs waiting acknowledgement performance No
High RTP hopcount performance No
NLPs held on receive queue performance No
NLPs on resequencing queue performance No
Outbound NLPs queued performance No
VTAM Buffer Pool Expansion performance No
VTAM Buffer Pool Thrashing performance No
XCA Node GVRN Line availability configuration No
XCA Node Line availability configuration No
No CP-CP connections to a Netid availability No
XCA Node Total Line availability configuration No
XCA Node VRN Line availability configuration No
VTAM PPO Severity 1 Message availability No
SNA Session End availability No
SNA Session Failed availability No
SNA Session Start availability No
Key Points:
• Only selected alerts are issued ‘out-of-the-box’. These are indicated in the table above.
• Inactive alerts are enabled using Monitoring Profiles that are assigned to systems using
Profile Assignments. Both the Monitoring Profiles and the Profile Assignments panels
are accessed from the Admin/SNA Admin drop-down menu from the ZEN Desktop.

• Although default monitoring profiles are provided and the default profile for APPN
monitoring is active for all systems by default, it is highly likely that these will require
review before being used.
• Alerts for Session Awareness Monitoring require EE MONITOR configuration changes
(and possibly also some z/OS changes) as well as updates to the Monitoring Profiles and
Profile Assignments.
• The alert relating to EE HPR gap packets will only be able to be issued when the
PktTrace configuration parameter is set to ‘On’ or ‘Start’.
• Message alerts are only issued when the EE MONITOR is run as a PPO.
• The alert ‘No CP-CP connections to a Netid’ is disabled by default in its ZEN alert
definition. Therefore, irrespective of whether it is enabled in the EE MONITOR, it will
not be issued until this default is changed. This is the only EE MONITOR alert that
requires this action.
The IP MONITOR (ZIM)

The IP MONITOR issues more alerts than all of the other ZEN components combined. ZEN
alerts for the IP MONITOR are grouped into the following categories: Performance,
Availability, Capacity, Security, General and Message. Also, when the IP MONITOR is
running on a sysplex distributor (SD) system, an additional SD Monitor is automatically
activated that provides SD-related alerts.
Within the alert categories there are sub-groups of alerts that are issued for each specific
monitoring task. Some examples are the tasks that monitor and alert on: IP stack (both
ICMP and non-ICMP events), resource thresholds, TN3270 responses, EE, OSPF, XOT (X.25
over IP), NTT (for non-telnet TCP traffic), RTT, MIB values, OMVS thresholds and so on.
Most of the monitoring tasks while issuing some basic alerts will require specific
configuration using the IP MONITOR’s VTAM application before all possible alerts are
issued.
As an example, all of the OSPF alerts are grouped together and will become relevant as soon
as the IP MONITOR recognizes OSPF traffic flowing through the IP stack and generates the
relevant interface groups and OSPF Administration function (which is not even accessible if
there is no OSPF traffic). However, the alerts themselves will not be activated until the
appropriate settings have been made in the OSPF Administration panel. This is generally
the case with most of the IP MONITOR’s monitoring tasks.
The table below lists all of the IP MONITOR’s alerts with an indication in the rightmost
column of whether the alert is issued out-of-the-box.
Table 14-7: IP MONITOR Alerts
Description Category OOTB?

Idle interface Availability Yes
Interface status change Availability Yes

Table 14-7: IP MONITOR Alerts (continued)

No traffic on interface Availability Yes
Port status changed Availability Yes
ICMP port unreachable Availability Yes
Idle service Performance Yes
ICMP source quench Performance Yes
UDP port unreachable Availability Yes
ICMP router redirects Performance Yes
ICMP destination unreachable Availability Yes
TCP service unavailable Availability Yes
UDP service unavailable Availability Yes
IP packet fragmentation inbound Performance Yes
IP packet fragmentation outbound Performance Yes
IP retransmissions to host Performance Yes
Connection re-routing Availability Yes
Remote service rejecting connections Availability Yes
Security violation Security Yes
Implex password expiry General Yes
IP packet retransmissions Performance Yes
Sysplex Distributor connection acceptance Performance Yes
Sysplex Distributor connection receipt Performance Yes
Sysplex Distributor connection establishment Performance Yes
Sysplex Distributor connection efficiency Performance Yes
Low connection count on interface Performance No
High connection count on interface Capacity No
Low traffic on interface Performance No
High traffic on interface Capacity No
Low TCP window size on interface Performance No


High TCPIP CPU utilization Capacity No
ECSA CSM usage exceeded Capacity No
Fixed CSM usage exceeded Capacity No
Low traffic on port Performance No
High traffic on port Capacity No
Low connection count on port Performance No
High connection count on port Capacity No
Connections on port backlog queue Capacity No
Backlog limit exceeded Capacity No
Low connection count on host Availability No
High connection count to host Capacity No
Changed network route Performance No
Excessive RTT to monitored host Performance No
Monitored host unavailable Availability No
Low traffic volume on gateway Performance No
High traffic volume on gateway Capacity No
Low connections across gateway Performance No
High connections across gateway Capacity No
Low traffic volume on port Performance No
High traffic volume on port Capacity No
Low connection count on port Performance No
High connection count on port Capacity No
Incoming connection active Message No
Incoming connection ended Message No
Inbound connection reset Message No
Connection attempt timed out Availability No
Connection reject Message No


Interface active Message No
Outbound connection established Message No
Outbound connection ended Message No
Outbound connection reset Message No
Outbound connection rejected Message No
Connection to remote host reset Message No
Outbound connection reset Message No
Forced timeout on connection Message No
Incomplete SYN exchange Message No
Incomplete FIN exchange Message No
Service active Message No
Low inbound TCP window size Performance No
Low outbound TCP window size Performance No
Low TN3270 response time Performance No
High TN320 response time Performance No
FTP transfers limit exceeded Capacity No
FTP limit reached for user Capacity No
FTP terminated due to excessive volume Capacity No
Low OSPF inbound traffic Availability No
Low OSPF outbound traffic Availability No
High OSPF inbound traffic Capacity No
High OSPF outbound traffic Capacity No
No OSPF hello packets in dead interval Availability No
New OSPF designated router detected Availability No
New OSPF designated router Availability No
OSPF neighbor count changed Availability No
OSPF Link state updates Availability No


Low network transit time Performance No
Excessive network transit time Performance No
Excessive network transit time to host Performance No
Low EE traffic Performance No
High volume of EE packets Capacity No
Low volume of EE LLC packets Performance No
High volume of EE LLC packets Capacity No
Low volume of EE network priority packets Performance No
High volume of EE network priority packets Capacity No
Low volume of EE high priority packets Performance No
High volume of EE high priority packets Capacity No
Low volume of EE medium priority packets Performance No
High volume of EE medium priority packets Capacity No
Low volume of EE low priority packets Performance No
High volume of EE low priority packets Capacity No
EE gap packets Performance No
EE ARB slowdown level 1 Performance No
EE fault segments detected Capacity No
Outbound X.25 calls rejected Availability No
Inbound X.25 calls rejected Availability No
Reject packets causing retransmissions Availability No
X.25 Diag packets received Availability No
X.25 RNR packets received Performance No
High X.25 calls on router Capacity No
High RR packets on X.25 calls Performance No


High X.25 concurrent calls Capacity No
SNMP Manager unavailable Availability No
High value detected in MIB Performance No
Low value detected in MIB Performance No
High USS AF_INET sockets Capacity No
High USS AF_UNIX sockets Capacity No
High USS processes Capacity No
High USS userids Capacity No
High USS active pseudo terminals Capacity No
High USS memory map pages Capacity No
High USS shared pages Capacity No
High USS message queue IDs Capacity No
High USS semaphore IDs Capacity No
High USS shared memory IDs Capacity No
High USS shared memory pages Capacity No
High USS shared library region Capacity No
High USS shared library pages Capacity No
High USS open files for a process Capacity No
High USS queued signals for a process Capacity No
High USS threads per process Capacity No
High USS thread tasks Capacity No
High USS shared memory segments Capacity No
Low LPAR count Availability No
Low TCPIP stack count Availability No
Low Implex focal points Availability No
Inactive sysplex interface Availability No


Low sysplex server instances Availability No
No connection id Message No
Key Points:
• Only a few of the IP MONITOR’s alerts are issued ‘out-of-the-box’ as indicated in the
rightmost column of the table above.
• Alerts that are not issued out-of-the-box are generated by separate monitoring tasks
each of which may require configuration using the appropriate Administration function
of the IP MONITOR’s VTAM interface in order to activate the required alerts.
Specifically:
▪ Services/PortsTN3270 Settings
▪ InterfacesFTP Settings
▪ HostsEE Settings
▪ SubnetsOSPF Settings
▪ GatewaysNTT Settings
▪ ThresholdsX.25 Settings
▪ AlertsSystem Monitors
▪ Monitored MIBsTelnet Services
Routing SyslogD Messages to Ironstream

Overview
ZEN’s SyslogD support extends ZEN’s system and network log services to messages
originating from the Syslog Daemon (SyslogD). SyslogD messages on z/OS systems tend to
originate from USS based services including many of the Communications Services such as
FTP, AT-TLS and security services. SyslogD is also heavily used by traditional UNIX/Linux
based systems and can often be seen in use on routers, switches and other network based
devices.
In addition to the message text, SyslogD messages have attributes including a facility code
(the type of service which generated the message) and a priority code ranging from Debug to
Emergency. ZEN’s SyslogD support can do the following:
• Collect SyslogD messages from z/OS Syslog Daemon
• Collect SyslogD messages from remote z/OS SyslogD Daemons
• Collect SyslogD messages from any other network device
• Filter SyslogD messages based on Origin, Facility and/or Priority
• Display filtered SyslogD messages in the Zen System Log

• Forward SyslogD messages to the Zen Network Log (kept historically)

• Drive automation commands/REXX procedures for SyslogD messages
Any SyslogD-enabled device whose messages you want to see on the ZEN System Log and
potentially also automate and/or send to Ironstream should be set to route its SyslogD
messages to the IP address and port specified by the SyslogDServer ZEN Profile
(Configuration) Parameter.
Configuring ZEN to Route SyslogD Messages to Ironstream

Provided that both ZEN and Ironstream have been suitably configured, SyslogD messages
will be eligible for forwarding to Splunk Enterprise. Note that you will also need to make a
suitable addition (or additions) to your SyslogD configuration to route messages to ZEN, for
example:
*.*.*.* your_IP-address
which will route all SyslogD messages to ZEN. Even after these changes have been made, it
should be noted that messages are selected for inclusion according to ZEN’s SyslogD filter
definitions and that by default no messages are included.
SyslogD filter definitions are created/updated using the SyslogD Filter List panel that is
accessed using the ‘Admin/Log Admin/Administer SyslogD Filters’ drop-down ZEN Desktop
menu item. Since there are no filters provided by default all SyslogD messages are excluded.
The fields available in the Filter Edit panel are based on RFC5424 (which obsoleted
RFC3164) and also copes as well as it can with IBM’s z/OS implementation of SyslogD.
Key Points:
• No SyslogD messages are eligible for routing to Ironstream by default.
• SyslogD requires configuration to route messages to ZEN.
• After providing suitable configuration parameters to both ZEN and Ironstream, further
configuration work is required to set up the filter definitions in ZEN to include all
required SyslogD messages.
• There may be some TCP/IP configuration to do (for example to remove any port
reservation on the port used by ZEN to receive SyslogD messages).
More Information about Alerts and SyslogD Forwarding

Although all alert definitions in ZEN are enabled for forwarding to Ironstream, this does not
mean that these will all be sent to Ironstream for onward forwarding to Splunk as soon as
the relevant ZEN component that issues the alert is activated, even assuming all the basic
configuration to activate the ZEN to Ironstream interface has been completed successfully.
Similarly, even when the basic SyslogD configuration has been completed and is active, no
SyslogD messages will be forwarded to Ironstream since ZEN’s default SyslogD filtering
option is for all messages to be excluded.

This chapter of the manual is provided so that you are aware of which alerts are issued
‘out-of-the-box’ for each of the ZEN components. At the same time it provides an overview of
what needs to be done in each ZEN component to activate the alerts that are optional and
also how to access the SyslogD filter panel to set up message inclusion filters.
Full details of all of the configuration options outlined in this chapter are available in the
appropriate Configuration and Reference or Administration manual for the ZEN component
concerned and/or in the ZEN Help system.


Chapter 15 DB2 Data Forwarding
This chapter describes how to configure DB2 table data for forwarding to a destination.
Topics:
• “Overview of DB2 Tables” on page 15-1
• “Configuration for DB2 Table Data” on page 15-1
Overview of DB2 Tables

Data inserted into DB2 tables can optionally be captured and forwarded to a destination
using Ironstream. This is achieved by a combination of a DB2 insert trigger calling a stored
procedure and a utility which calls an Ironstream instance to forward the data to a
destination. A similar process using an update trigger can also forward data to a destination.
Configuration for DB2 Table Data

To enable the collection of DB2 data, you must use the SSDFTRIG and SSDFPROC
members of SDFSAMP to create the necessary DB2 objects and modify the configuration
file.
DB2 Definitions
Member SSDFTRIG in the SDFSAMP data set contains sample DDL to create a DB2 insert
trigger. Member SSDFPROC in the SDFSAMP data set contains sample DDL to create a
stored procedure.

DB2 Data Forwarding
Sample SSDFTRIG
The DB2 trigger builds a single VARCHAR parameter that is passed to the stored
procedure. The parameter concatenates an Ironstream token, followed by one or more
name/value pairs corresponding to columns in the table. The parameter must conform to the
following rules:
• A two-part name specifying the Ironstream parameter SSDFDB2TOKEN and a 16
character token name. The parameter value in the sample SSDFTRIG is:
'"SSDFDB2TOKEN":"nnnnnnnnnnnnnnnn"'
The entire parameter must be enclosed in single quotes and each of the two parts must
be enclosed in double quotes separated by a colon.
• A concatenated list of the name/value pairs for each column value to be passed to a
destination, enclosed in curly brackets { and }. Each name/value pair must be enclosed
in single quotes and each of the two parts must be enclosed in double quotes separated
by a colon.
• At least one name/value pair must include a TIMESTAMP as the value. If your data
does not include one, this can be accomplished as shown in the sample SSDFTRIG.
Use appropriate DB2 scalar functions to convert values in non-character columns. The
sample SSDFTRIG shows the CHAR function for a DATE column, and the combination of
CHAR and DIGITS functions for DECIMAL and INTEGER/SMALLINT column types.
Sample SSDFPROC
The DB2 stored procedure calls the Ironstream utility SSDFDB2F. SSDFDB2F takes the
DB2 data, locates an instance of Ironstream that is active for the DB2 data identified by the
token and then forwards the data to it. SSDFDB2F assigns "MFSOURCETYPE":"DB2TABLE" to
all records it forwards.
The value of the input parameter must be large enough to contain the parameter list that is
passed by the trigger.
The DB2 stored procedure address space that is set up to run SSDFDB2F must be
authorized, that is, all libraries in the STEPLIB JCL must be APF authorized. You may
decide to have a WLM environment that is dedicated to Ironstream for this reason.
The same stored procedure can be called by multiple triggers.
Ironstream DB2 Data Definitions

An Ironstream instance must be active to receive the DB2 data from the Stored Procedure
program. In the SOURCE section of the Ironstream configuration file, specify
"DB2TRIGGER" as the "DATATYPE" and set up the "DB2TOKEN " value.
For complete information, refer to the “Data Type DB2TRIGGER Subparameters”
instructions in Chapter 7, “Manually Setting Ironstream Parameters”.

DB2 Data Forwarding
Enabling Data Loss Prevention in Splunk for DB2 Forwarding

The DB2TRIGGER data source can be configured to use Ironstream’s Data Loss Prevention
(DLP) feature, which minimizes the loss of forwarded Splunk data due to extended network
or Splunk outages.
Note: DLP uses the Splunk Indexer Acknowledgment function and therefore cannot be
configured to work with Elastic destinations. For more information about using DLP with
Splunk, see Chapter 10, “Configuring Data Loss Prevention”.
Configuration File Example for DB2 Data with DLP

An Ironstream instance receiving DB2 data with "DB2TRIGGER" as the "DATATYPE" must
also be configured to use DLP. The DLP parameters are defined in the DESTINATION
section of the Ironstream configuration file, as shown in the following example:
[DESTINATION]
"DATA_LOSS_PREVENTION":"YES"
"DLP_STREAM_NAME":"IRONLOG.RECOVERY"
"DLP_COLD_START":"YES"
"INDEX":"db2dlp"
"TYPE":"HTTP"
"IPADDRESS":"172.30.40.126"
"PORT":"8088"
"TOKEN":"ABA9854F-C280-4F98-84F0-F75384E95975"
"SSL":"NO"
[SOURCE]
"DATATYPE":"DB2TRIGGER"
**************************************************************
* THE DB2TOKEN VALUE IS USED TO ASSOCIATE THE DB2 TRIGGER *
* STORED PROCEDURE TO THIS INSTANCE OF IRONSTREAM. *
* THE VALUE SPECIFIED MUST BE 16 CHARACTERS. *
**************************************************************
"DB2TOKEN":"abcdefghijklmnol"
For detailed descriptions of the DLP parameters, refer to the “Data Loss Prevention
Parameters” section in Chapter 7, “Manually Setting Ironstream Parameters”.
Command to Run Ironstream for DB2 Data with DLP

An Ironstream instance using the DB2TRIGGER data source with DLP must be started
with the following command to avoid creating non-reusable address spaces:
S JOBNAME,REUSASID=YES

DB2 Data Forwarding

Chapter 16 Sequential File Forwarding
This chapter describes how to capture sequential data to send to a destination.
Topics:
• “Capturing Sequential Data” on page 16-1
• “Sequential File Forwarding Example” on page 16-2
• “Batching FILELOAD Data” on page 16-3
Capturing Sequential Data

Sequential data can be sent to a a destination index by using a data source of FILELOAD in
the configuration file.
The FILELOAD process is designed to run as a unique job or step for each set of files to be
processed and forwarded by Ironstream. An instance of Ironstream performing a
FILELOAD function will terminate once End-of-File of the last file has been detected.
Multiple files can be loaded in a single invocation of Ironstream, either by concatenation
using the standard rules of concatenation, or by using multiple DD statements and multiple
FILELOAD configuration commands.

Sequential File Forwarding
Sequential File Forwarding Example

This example shows the JCL and configuration commands needed to transmit four files to a
a destination.
//Jobname JOB Accounting-Info,
// CLASS=A,NOTIFY=&SYSUID,MSGCLASS=H
//*
//SSDF EXEC PGM=SSDFMAIN
//FILE0001 DD DISP=SHR,DSN=MY.RECFMFB.FILE1
// DD DISP=SHR,DSN=MY.RECFMFB.FILE2
//FILE0002 DD DISP=SHR,DSN=MY.RECFMVB.FILE3
// DD DISP=SHR,DSN=MY.RECFMVB.FILE4
//CEEOPTS DD DISP=SHR,DSN=&HLQ..SDF.R12.SDFSAMP(CEEOPTS)
//SSDFCONF DD *
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"SSD9"
"FILELOAD":"FILE0001"
"FILELOAD":"FILE0002"
"DESTINATION"
"INDEX":"zfile"
"TYPE":"TCP"
"IPADDRESS":"192.168.1.1"
"PORT":"9997"
"IPADDRESS":"192.168.1.2"
"PORT":"9998"
"SSL":"YES"
"PASSWORD":"MyKey"
"STASH_FILE":""
"SOURCE"
"DATATYPE":"FILELOAD"
"TRANSLATE_TABLE":"SSDF1141"
"BATCH_AND_BREAK_ON_CONDITION":"<character string>"
"BATCH_COUNTER":"NO" | "YES"
"BATCH_RECORDS":"YES" | "NO"
The TRANSLATE_TABLE parameter defines a different EBCDIC to ASCII translate table

that Ironstream uses when forwarding data to a destination. If a TRANSLATE_TABLE is
used, it must immediately follow the "DATATYPE":"FILELOAD" command and precede any
of the BATCH commands that are described in the following sections of this chapter.

Batching FILELOAD Data

Ironstream can cause the file load facility to recognize that the file being forwarded to a
destination comprises several record groups or data segments. Segments might be several
instances of the same type of data or business transaction, or data grouped according to a
unique identifiable character string.
Provided each set of records has a unique identifiable character string in the first record of
the set, all records in the set can be forwarded to a destination with qualifiers, so for
example, a Splunk application can recognize that the records belong to the same set, or
‘batch’.
According to the control statements specified, records can be sent to a destination
individually or the set of records that comprise a batch can be sent as a single event.
FILELOAD Batching Control Statements

To activate the batching facility, the mandatory control statement:
"BATCH_AND_BREAK_ON_CONDITION":"<character string>"
must be specified. The character string, up to a maximum of 36 bytes long, is compared to
each record read and when a match occurs the batch processing feature recognizes the
beginning of the next batch of records.
The character string may contain the standard wild cards ‘*’ or ‘%’ where ‘*’ indicates an
automatic match of length zero to the complete length of the input record and ‘%’ indicates
an automatic match of exactly one byte in length.
The optional statement:
"BATCH_COUNTER":"NO" | "YES"
when specified immediately after the "BATCH_AND_BREAK_ON_CONDITION", adds the
metadata: "BATCH":"nnnn" and "STEP":"nnn" to each event sent to a destination. See
“BATCH_COUNTER Usage Notes” on page 16-3 for details.
The optional statement:
"BATCH_RECORDS":"YES" | "NO"
can cause batches of data to be sent to a destination as a single event (the default). See
“BATCH_RECORDS Usage Notes” on page 16-4 for details.
BATCH_COUNTER Usage Notes

The metadata "BATCH":"nnnn" built when the BATCH_COUNTER option is set to YES
indicates the number of times an event break has occurred due to a match on the specified
character string.
When this metadata is assigned to an event in a destination it indicates that the event is
part of a record set with each record having the same number assigned to the BATCH
keyword. The counter is set to one at the beginning of each instance of Ironstream. Note that
the BATCH_COUNTER statement is optional and defaults to "NO".
To cater for the possibility of there being multiple instances of Ironstream in a single batch
job and the need to separate the data between those instances, the position of the

Ironstream instance in a set of batch steps is sent to a destination in each event where the
BATCH keyword is sent. The additional keyword is "STEP" and is assigned the relative
number of the step of the batch job invoking Ironstream.
As an example, if Ironstream were to be invoked in the first step of a batch job, the keyword
would be set to "STEP":"1". The maximum value for STEP is 255. This value should be used
with the BATCH value to uniquely identify batches of data.
BATCH_RECORDS Usage Notes

When the optional "BATCH_RECORDS":"YES" is specified or defaulted, it indicates that
data sent to a destination should be sent with all data of a batch in one event. A specification
of "BATCH_RECORDS":"NO" causes each input record to be a separate event in a
destination.
The size of the event is limited to the size of internal buffers of Ironstream and the
destination, and is currently 384K. If a BREAK_ON_CONDITION is not recognized before a
buffer overflow occurs, the JSON pair "BUFFER_CONTINUED":"YES" is added to the
buffer sent to the destination and the batch continues with an empty buffer in which to
continue to gather a batch of records.
FILELOAD Batching Example

Suppose we have a data set in which transaction records are grouped by customer. By using
the batching facility and sending the records to a destination as a single event the
relationship between the input data and the data sent to the destination looks like this:
Table 16-1: FILELOAD Batching Example 1
Original File Data Data Sent to a Destination

Cust 1 Header
Trans 1
Trans 2
Trans 3 Cust 1 Header Trans 1 Trans 2 Trans 3
Cust 2 Header
Trans 1
Trans 2
Trans 3
Trans 4 Cust 2 Header Trans 1 Trans 2 Trans 3 Trans 4
...
Cust n Header
Trans t

Table 16-1: FILELOAD Batching Example 1 (continued)

Trans t+1
Trans t+2
... Cust n Header Trans t Trans t+1 Trans t+3 Trans
t+4
If instead you were to use the batching facility, but specifying NO for the
BATCH_RECORDS statement and YES for the BATCH_COUNTER statement, the records
would be sent as individual records to the destination but with the Batch metadata added as
illustrated below:
Table 16-2: FILELOAD Batching Example 2

Cust 1 Header Cust 1 Header Batch 1
Trans 1 Trans 1 Batch 1
Cust 2 Header Cust 2 Header Batch 2
...
Cust n Header Cust n Header Batch m
Trans t Trans t Batch m
Trans t+1 Trans t+1 Batch m
Trans t+2 Trans t+2 Batch m
...


Chapter 17 System State Forwarding
This chapter describes how to capture z/OS LPAR system performance metrics to send to a
destination.
Topics:
• “Configuring Ironstream for System State Forwarding” on page 17-2
• “System-level Data Fields Forwarded to Destinations” on page 17-2
Overview
The SYSTEMSTATE data source captures z/OS LPAR system performance metrics.
• This data source provides low overhead data collection that gets information from
system control blocks every few seconds and sends this state data as a record to a
destination.
• System state information includes metrics like MSUs, CPU utilization, storage
utilization, and paging rates.
• Ironstream produces a dashboard with metrics, including 4HRA of MSUs for each LPAR
mapped against the CEC defined MSU capacity.
• Optionally, the TRANSLATE_TABLE parameter can be used to specify a user-defined
EBCDIC to ASCII translate table.

System State Forwarding
Configuring Ironstream for System State Forwarding

To cause Ironstream to forward system state metrics to a destination requires a DATATYPE
of SYSTEMTSTATE to be specified in the SOURCE section of the configuration file, as
described in configuring the “SOURCE Section” on page 7-16.
No other configuration parameters are required.
System-level Data Fields Forwarded to Destinations

The names of system-level data elements that SYSTEMSTATE generates are the names of
the source fields from system control blocks, with the exceptions of ABARFIX,
ABARFRAME, AVAILFRAME and FREEFRAME, with their sources noted in Table 17-1.
For additional information on any other field, consult the MVS Data Areas manuals.
Table 17-1: System State Data Fields
System Field Name Description

ABARFIX The number of fixed frames above the 2 GB bar.
ABARFRAME The number of real frames above the 2 GB bar defined and
usable by the LPAR. Calculated from RCEPOOL –
RCEBELPL – RCEABVPL.
AVAILFRAME The second word returned by the SYSEVENT STGTEST
macro. This is generally the number of frames from
FREEFRAME plus those frames that have a UIC equal to or
greater than the current system target UIC value.
ECVTSPLX The name of the SYSPLEX.
FREEFRAME The first word returned by the SYSEVENT STGTEST
macro. This is generally the number of unassigned real
frames from RCEAFC minus a machine-dependent fixed
number of frames.
GDACSACV The amount of CSA converted to SQA.
GDACSAHWM The high-water mark for CSA.
GDACSARE The amount of unallocated common storage, CSA + SQA.
GDACSASZ The size of CSA.
GDAECSAHWM The high-water mark for ECSA.
GDAECSAS The size of ECSA.
GDAEPVTS The size of the extended private area.
GDAESQAHWM The high water mark for ESQA.

Table 17-1: System State Data Fields (continued)

GDAESQAS The size of ESQA.
GDAPVTSZ The size of the private area.
GDASQAHWM The high-water mark for SQA.
GDASQASZ The size of SQA.
GDATOTALCSAHW The high water mark for CSA plus CSA converted to SQA.
M
GDATOTALECSAH The high water mark for ECSA plus ECSA converted to
WM ESQA.
GDA_CSA_ALLOC The amount of CSA currently GETMAINed.
GDA_CSA_CONV The amount of total CSA converted to SQA.
GDA_ECSA_ALLOC The amount of ECSA currently GETMAINed.
GDA_ECSA_CONV The amount of total ECSA converted to ESQA.
GDA_ESQA_ALLOC The amount of ESQA currently GETMAINed.
GDA_SQA_ALLOC The amount of SQA currently GETMAINed.
LPDATCAPACITYG The capacity groupname, if specified.
ROUPNAME
LPDATCECCAPACI The total CEC capacity in MSU.
TY
LPDATIMGCAPACI The LPAR capacity in MSU.
TY
LPDATIMGLOGICA The LPAR name.
LPARTITIONNAME
LPDATPHYCPUAD The CPU to SU adjustment factor.
JFACTOR
RCCFXETH The percentage below the line high MPL threshold.
RCCFXETL The percentage below the line low MPL threshold.
RCCFXTTH The percentage of all real high MPL threshold.
RCCFXTTL The percentage of all real low MPL threshold.
RCEABVFX The number of fixed frames above the 16 MB line and below
the 2 GB bar.


RCEABVPL The number of real frames located above the 16 MB line and
below the 2 GB bar defined and usable by the LPAR.
RCEAFC The total number of free frames.
RCEBELFX The number of fixed frames below the 16 MB line.
RCEBELPL The number of real frames located below the 16 MB line
defined and usable by the LPAR.
RCEPOOL The total number of real frames defined and usable by the
LPAR.
RCETOTFX The total number of fixed frames for the LPAR.
RCTCECWU The Workload Units capacity of CEC.
RCTIMGWU The Workload Units available to MVS image when not
running as a VM guest.
RCTLACS The long-term average CPU service used by this logical
partition, in millions of service units per hour (AKA 4-hour
rolling average).
RCVAFQA The average available frame count.
RCVAVQC The available frame queue low count.
RCVBPPCT The base total page count.
RCVBPTTM The base page fault time.
RCVCPUA The CPU usage average. Scaled by 4 bits.
RCVCPUAA The total processor usage average. Scaled by 4 bits.
RCVCPUAC The total processor usage accumulator.
RCVF2GCA The average fixed frame count between 16 MB and 2 GB.
RCVFXCA The average count of below 16 MB fixed frames.
RCVFXIOP The average percentage of total frames that are fixed or in
I/O.
RCVIFAA The average IFA usage.
RCVMFXA The average percentage of below 16 MB frames that are
fixed or in I/O.
RCVNSQLA The non-swap ASM queue length average.
RCVPAGRT The total paging rate.


RCVPTR The paging rate.
RCVSUPA The SUP usage average. Scaled by 4 bits.
RCVSWRT The SWAPIN rate.
RCVUICA The average Unused Interval Count.


Chapter 18 Configuring and Using the
Ironstream API
This chapter describes how to configure the Ironstream API to capture application
information for analysis and visualization.
Topics:
• “Overview of the Ironstream API” on page 18-2
• “Defining the IRONSTREAM_API Data Type” on page 18-3
• “Using the Single-send API” on page 18-5
• “Using the Multi-send API” on page 18-12
• “Troubleshooting the Ironstream API” on page 18-17
• “Ironstream API Coding Examples” on page 18-21

Configuring and Using the Ironstream API
Overview of the Ironstream API

The Ironstream API enables Ironstream instances to programmatically collect user-defined
EBCDIC or ASCII data and forward it on to a destination. For example, the API can be used
to target user-defined DB2 or CICS transactions and send that data to a destination for
translation.
The Ironstream API includes a configurable IRONSTREAM_API data source with
configuration parameters that allow you to categorize your data by class, and optionally by
type and subtype. Using these parameters, you can construct a message in any format
desired and then assign a class, and optionally, a type and subtype and present it to the API.
The Ironstream API will scan the running instances of Ironstream for all instances that are
accepting the defined type of data, and then sends the data to all of those instances. For
example, one Ironstream instance could handle types 128–130, while another instance could
handle types 130–131.
Model code for calling the API is provided for COBOL, C, Assembler, REXX, and CICS.
There are API code examples for each of these in “Ironstream API Coding Examples” on
page 18-21.
Single-send versus Multi-send API

Ironstream supports two user API functions:
• The Single-send API should be used where a persistent environment is not available,
such as in a CICS transaction.
• The Multi-send API is appropriate where the environment is consistent from call-to-call,
such as in a batch job.
Each API type uses a standalone load module that can be called or link edited statically into
the calling program:
• Single-send requires the SSDFAPI routine, as described in “Using the Single-send
SSDFAPI Routine” on page 18-7.
• Multi-send requires the SSDFPAPI routine, as described in “Using the Multi-send
SSDFPAPI Routine” on page 18-15.
Note: The Multi-send API does not support sending data from CICS applications.
System Requirements
The Ironstream API requires the availability of a Monoplex or Sysplex Cross System
Coupling Facility (XCF) service. For more information, see the MVS Programming: Sysplex
Services Guide or contact your system programmer.

Defining the IRONSTREAM_API Data Type

Irrespective of which API type best suits your environment, you must configure an
Ironstream API data source by specifying a data type of IRONSTREAM_API in the
SOURCE section of the configuration file. Also in the SOURCE section, the XCFGROUP and
XCFMEMBER parameters are specified to define the XCF group and member name that
each Ironstream instance should join to receive the data. The Ironstream API also provides
parameters that allow you to categorize your data by class, and optionally by type and
subtype.
Data Type Parameters

The IRONSTREAM_API data type and required XCF parameters are defined in the
SOURCE section of the configuration file as follows:
"SOURCE"
"DATATYPE":"IRONSTREAM_API"
"XCFGROUP":"group_name"
"XCFMEMBER":"member_name"
"DATATYPE":"IRONSTREAM_API" - This record is required and must be entered exactly

as "IRONSTREAM_API".
"XCFGROUP":"XCF_groupname" - This record is required. The group_name value is a

user-defined XCF group name that is common to a set of Ironstream instances.
XCF_groupname must be a maximum 8 characters long; valid characters are A–Z, 0–
9, $, #, and @. To avoid using the names IBM uses for its XCF groups, do not begin
group names with the letters A–I or the character string SYS. Also, do not use the
name UNDESIG, which is reserved.
"XCFMEMBER":"XCF_membername" - This record is required. The member-name value

is a unique user-defined member name for each Ironstream instance.
XCF_membername must be a maximum 16 characters long; valid characters are A–Z,
0–9, $, #, and @.
CLASS, TYPE, and SUBTYPE Parameters

The CLASS, TYPE, and SUBTYPE selections for the Ironstream API are made using
additional parameters in a hierarchical structure, as follows:
"CLASS":"nnn"
"TYPE":"ttt"
"SUBTYPE":"sss"
Note: The indentations used here are for readability purposes and are not required.
"CLASS":"nnn" - At least one CLASS entry is required. The nnn value can be any value in
the range of 128–255. Values in the range of 1–127 are reserved for use by
Ironstream.
"TYPE":"ttt" - Optionally, you can define one or more TYPE entries under a CLASS entry.
The ttt value can be any value in the range of 1-255.

"SUBTYPE":"sss" - Optionally, you can define one or more SUBTYPE entries under a TYPE
entry. The sss value can be any value in the range of 1-255.
CLASS Configuration Behavior

A CLASS definition with no following TYPE, or a definition of "TYPE":"0", means that all
messages of that CLASS are processed by that instance of Ironstream regardless of the
TYPE or SUBTYPE specified for the message by the sender.
Similarly, a TYPE definition with no following SUBTYPE definition, or a definition of
"SUBTYPE":"0" means that all messages of that CLASS and TYPE will be processed by that
instance of Ironstream regardless of the SUBTYPE specified for the message by the sender.
The omission of a TYPE or SUBTYPE definition has the effect of wildcarding the TYPE or
SUBTYPE selection. However, the API cannot wildcard the data it sends.
CLASS Configuration Example

In the following example, an Ironstream instance with the following configuration has
messages issued by the Ironstream API:
"CLASS":"151"
"TYPE":"15"
"SUBTYPE":"1"
"SUBTYPE":"3"
"SUBTYPE":"2"
"TYPE":"1"
"CLASS":"130"
• Message sent with CLASS=151,TYPE=1 and any SUBTYPE will be processed.

• Message sent with CLASS=151,TYPE=1,SUBTYPE=27 will be processed because by
omitting the SUBTYPE definition, all SUBTYPEs are accepted.
• Message sent with CLASS=151,TYPE=15,SUBTYPE=3 will be processed.
• Message sent with CLASS=151,TYPE=15,SUBTYPE=0 will not be processed because
there is no SUBTYPE specified for the message and the configuration file requires one.
• Message sent with CLASS=130 and any TYPE or TYPE/SUBTYPE will be processed.
Note: CLASS, TYPE, and SUBTYPE values do not have to be defined in the configuration
file in numerical sequence as demonstrated in this example, although for maintainability
purposes it is recommended.
Ironstream API Configuration Example

This example shows the Ironstream instance that is a member of XCF group SSDF1 and
member XCF1, which can handle messages for classes 128, 168, 192, and 224, and any
specified types and subtypes.
"SOURCE"
"DATATYPE":"IRONSTREAM_API" <<< Must be coded as shown
"XCFGROUP":"SSDF1" <<< 8 Characters max
"XCFMEMBER":"XCF1" <<< 16 Characters max
"CLASS":"128" <<< values 128 to 255 are valid
"TYPE":"1" <<< values 1 to 255 are valid

"SUBTYPE":"1" <<< values 1 to 255 are valid

"SUBTYPE":"7"
"SUBTYPE":"15"
"TYPE":"9"
"TYPE":"15"
"SUBTYPE":"5"
"CLASS":"168"
"TYPE":"32"
"SUBTYPE":"1"
"SUBTYPE":"2"
"TYPE":"64"
"SUBTYPE":"1"
"TYPE":"96"
"CLASS":"192"
"CLASS":"224"
"TYPE":"5"
"SUBTYPE":"7"
"TYPE":"10"
"SUBTYPE":"3"
"SUBTYPE":"5"
Using the Single-send API

The Single-send API is designed to send user-defined data to Ironstream in cases where a
persistent environment is not available, such as in a CICS transaction. It utilizes a pass-by
reference method to SEND information to the application interface.
The Single-send API requires a configured IRONSTREAM_API data source and uses the
SSDFAPI routine, which is a standalone load module that can be called or link edited
statically into the calling program.
This section includes the following topics:
• “Single-send API Parameters” on page 18-6
• “RACF Authorization for the Single-send API” on page 18-7
• “Using the Single-send SSDFAPI Routine” on page 18-7
• “Performance and Maintenance Considerations” on page 18-10
• “Linking SSDFAPI Into a Load Module” on page 18-10
• “Starting a Single-end API Instance” on page 18-10
• “Using the Single-send API in CICS” on page 18-11
• “Single-Send API Examples” on page 18-21

Single-send API Parameters

To use the Single-send API, you need to call the SSDFAPI routine using the following
required parameters.
Table 18-1: Required SSDFAPI Parameters for the Single-send API
NUMPARM 4-byte integer field with the number of parameters.
This value must at least equal the eight mandatory
parameters. If the optional CCSID parameter is
passed, then the parameter count must equal nine.
REQUEST 4-byte character string of "SEND".
CLASS Identifies the Ironstream instance running with the
same class.
1-byte value in the range 128–255.
TYPE Identifies the Ironstream instance running with the
same CLASS and TYPE combo.
1-byte value in the range of 1-255. A value of 0
indicates no type is assigned.
SUBTYPE Identifies the Ironstream instance running with the
same CLASS, TYPE, and SUBTYPE combination.
DATA The EBCDIC/ASCII data address to be sent.
Maximum length is 384K.
LENGTH 4-byte integer field with the length of the data to be
sent.
RETCODE 4-byte field the return code will be stored in.

Table 18-1: Required SSDFAPI Parameters for the Single-send API
REASON 4-byte field the reason code will be stored in.
CCSID 4-byte field the CCSID code will be stored in.
CCSID optionally specifies if the type of data is
ASCII or EBCDIC. When specified, the parameter
count must equal nine. Valid CCSID values are:
• 0037, 1047, 0500 and 1141 are supported for
EBCIDIC to ASCII translation.
• 0437 (ASCII) – When specified, Ironstream will
not translate ASCII, but will instead perform the
translation based on the TRANSLATE_TABLE
parameter specified in the Ironstream job.
For more information on translation tables, see
“"TRANSLATE_TABLE":"table"” on page 7-17.
Note: All the above are 4-byte address pointers (for 31 bit) or 8-byte address pointers (for 64
bit).
For descriptions of the SSDFAPI parameter formats, see “Single-send API Parameter List
Format” on page 18-9.
RACF Authorization for the Single-send API

The Ironstream API is protected from unauthorized access via the use of RACF, or its
functional equivalent. The API is defined as a FACILITY to RACF with the name
WCS.SSDF.STRM. Ironstream checks for a user authorization of at least READ.
Note: It is the administrator’s responsibility to determine which set of users should be
authorized to use the Ironstream API. Contact your RACF, or equivalent product,
administrator for assistance in setting these parameters in RACF.
Using the Single-send SSDFAPI Routine

The SSDFAPI routine is provided as a standalone load module that can be called or link
edited statically into a calling program. To use it as a called routine, you only need to have
the SSDFAPI module in a library that the calling program can access, such as a STEPLIB or
JOBLIB.
To statically link the SSDFAPI routine into a program you will have to add an INCLUDE
statement in the linkage or binder control statement file. You will also have to add a DD
statement that identifies the library that has the SSDFAPI routine in it.
Single-send API Environment

The Single-send API processes the parameters passed to it based on the addressing mode of
the calling program. If the caller is in 64-bit mode, using SYSSTATE AMODE64=YES, then all

parameters are passed as 64-bit addresses. If the caller is not in 64-bit mode, all parameters
are passed as 31-bit parameters.
Table 18-2: Ironstream API Environment
Environmental Factor Requirement

Minimum Supervisor state or problem state and any PSW key
Authorization
Dispatchable Unit Task or SRB
Mode
Cross Memory Mode PASN=HASN=SASN
AMODE 31-bit or 64-bit
ASC Mode Primary
Interrupt Status Enabled for I/0 and external interrupts
Locks No locks held
Control Parameters Must be in the primary address space
Register Conventions
When calling the SSDFAPI routine, the following registers have to be set.
Table 18-3: Ironstream API Input Registration
Convention Description
R1 Contains the address of the parameter list.
R13 Contains the address of an 18-word save area
(AMODE31) or 36-word save area (AMODE64).
R14 Contains the return address.
R15 Contains the address of the SSDFAPI routine.
On return from the SSDFAPI routine, the registers are set as follows:
Table 18-4: Ironstream API Output Registration
Convention Description
R0–R1 Used as work registers.
R2–R13 Unchanged.
R14 Used as work register.
R15 Return code.

Single-send API Parameter List Format

The API parameter list begins with the parameter count total, followed by eight mandatory
fullword addresses that point to the parameters. There is also an optional parameter that
specifies the CCSID code page number of the user data. When CCSID is specified, the
parameter count must equal nine. It is important to maintain the class order.
Table 18-5: Ironstream API Parameter List
Address Description
+0 Fullword that contains the total count of mandatory
parameters, plus any optional parameters.
+4 4-byte string that contains the SEND request.
+8 4-byte string that contains the CLASS value.
+12 4-byte string that contains the TYPE value.
+16 4-byte string that contains the SUBTYPE value.
+20 The start of the EBCDIC or ASCII data to send.
+24 Fullword that contains the length of the data.
+28 Fullword that on return is set with the return code.
+32 Fullword that on return is set with the reason code.
+36 (Optional) Fullword that specifies the CCSID code
page number of the collected data. If this option is
not specified, the user data is treated as EBCDIC.

Performance and Maintenance Considerations

For performance reasons, Syncsort recommends that the SSDFAPI module be loaded once
and called repeatedly, or statically linked into the calling routine.
Loading the SSDFAPI routine once can be done in assembler using the LOAD macro.
Syncsort does not recommend the use of the LINK macro.
Loading the SSDFAPI routine can be done in COBOL by using the CALL literal statement
in a program that is compiled using the DYNAM and the NODLL compiler options, or when
you use the CALL identifier statement in a program that is compiled using the NODLL
compiler option.
Statically linking SSDFAPI with its caller into a single load module also provides a high
level of performance; however, if maintenance is ever required for SSDFAPI it will require a
re-link of the program.
Linking SSDFAPI Into a Load Module

These control statements can be used by either the linkage editor or the binder, as shown in
Figure 18-1.
Figure 18-1. Control Statement for SSDFAPI
//STUBLIB DD DISP=SHR,DSN=hlq.SSDF011.R14.LOADLIB
//SYSLIN DD *
.
.
.
INCLUDE STUBLIB(SSDFAPI)
.
.
.
NAME YOURPGM(R)
/*
Starting a Single-end API Instance

When starting an IRONSTREAM_API instance, you must use the following command:
S SDFAPI,REUSASID=YES
Starting an Ironstream API instance ("DATATYPE":"IRONSTREAM_API") as a user job, or
without using the REUSASID=YES parameter, will cause the address space that the instance
runs in to be marked as non-reusable and, in extreme cases, can require an IPL of the
system if Ironstream API instances are started and stopped multiple times.
This parameter is not required for any other type of Ironstream forwarder.

Using the Single-send API in CICS

The Single-send API enables CICS applications to create and send user-defined data to
Ironstream.
In order to use the Single-send API in CICS, you need to link edit the SSDFCAPI routine,
and then define SSDFCAPI to CICS. To accomplish this, Syncsort recommends using the
sample JCL provided in the SDFCICSJ member in your_hlq.SSDFSAMP.
Additionally, the Ironstream load library must be added to the CICS DFHRPL
concatenation.
Define the Ironstream API Parameters in a CICS Program

The Ironstream API parameter list should be defined in the CICS Application, as described
in Table 18-5, “Ironstream API Parameter List,” on page 18-9. Ensure that the parameter
list is set up with address pointers to each parameter value.
A COBOL example of this can be found in the “COBOL on CICS Single-send API Example”
on page 18-34.
Calling the Single-send API in CICS

To call the API in CICS, use the following statement:
EXEC CICS LINK PROGRAM('SSDFCAPI') COMMAREA(api-parm) LENGTH(api-parm-length)
where api-parm is the API parameter list and api-parm-length defines the parameter list
length.
The application can then interrogate the return and reason code fields on return from the
Ironstream API to ensure successful completion.

Using the Multi-send API

The Multi-send API is designed to send user-defined data to Ironstream in environments
that are consistent from call-to-call and where it is necessary to send multiple records in
batch mode. In such environments, the Multi-send API can achieve significant ELAP and
CPU performance improvements on a per-record basis as compared to the Single-send API
(SSDFAPI).
The Multi-send API requires a configured IRONSTREAM_API data source and uses the
SSDFPAPI routine. Like the Single-send SSDFAPI routine, it is a standalone load module
that can be called or link edited statically into the calling program.
Note: The Multi-send API does not support sending data from CICS applications.
This section includes the following topics:
• “Multi-send API Request Types” on page 18-12
• “Multi-send API Parameters” on page 18-13
• “RACF Authorization for the Multi-send API” on page 18-14
• “Using the Multi-send SSDFPAPI Routine” on page 18-15
• “Performance and Maintenance Considerations” on page 18-16
• “Linking SSDFPAPI Into a Load Module” on page 18-17
• “Starting a Multi-send API Instance” on page 18-17
• “Multi-send API Coding Examples” on page 18-36
Multi-send API Request Types

The Multi-send API supports three request types to the application interface:
• INIT - Initializes the API environment.
• SEND - Sends data to one or more Ironstream target systems.
• TERM - Terminates the API environment.
The required parameters for each request are described in Table 18-6, “Required SSDFPAPI
Parameters for the Multi-send API,” on page 18-13.
INIT Request
The INIT request initializes the Multi-send API environment and finds the Ironstream
targets through the Ironstream configuration file’s CLASS/TYPE/SUBTYPE parameters. If
the initialization is successful, the Multi-send API will return a HANDLE that must be
supplied on all subsequent calls to the Multi-send API using the environment created. The
handle should be a pointer to a list of all the target Ironstream instances (or name/token
pair) for the CLASS/TYPE/SUBTYPE. The RACF authorization is done during the INIT
process.
CALL SSDFPAPI,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,TOKEN,RETCODE,RSNCODE)

SEND Request
The SEND request is the Multi-send API call used to send data to the Ironstream instances.
Callers can call the SEND routine multiple times by using the HANDLE returned by the
INIT request.
CALL SSDFPAPI,(NUMPARM,REQUEST,TOKEN,DATA,LENGTH,RETCODE,RSNCODE,CCSID)
All the above are mandatory parameters except CCSID. Only ASCII and EBCIDIC codes are
allowed for CCSID. This is similar to the Ironstream API.
TERM Request
The TERM request is used to terminate the Multi-send API environment established with
the INIT request. This request will free any storage or resources allocated.
CALL SSDFPAPI,(NUMPARM,REQUEST,TOKEN,RETCODE,RSNCODE)
Multi-send API Parameters

To use the Multi-send API, you need to call the SSDFPAPI routine using the following
required parameters, depending on the request type.
Table 18-6: Required SSDFPAPI Parameters for the Multi-send API
Parameter Description INIT SEND TERM

NUMPARM 4-byte integer field with the number of parameters.   
This value must at least equal the eight mandatory
parameters. If the optional CCSID parameter is
passed, then the parameter count must equal nine.
REQUEST 4-byte character string of INIT, SEND, or TERM.   
CLASS Identifies the Ironstream instance running with
the same class.

1-byte value in the range 128-255.
TYPE Identifies the Ironstream instance running with
the same CLASS and TYPE combo.

SUBTYPE Identifies the Ironstream instance running with
the same CLASS, TYPE, and SUBTYPE

combination.

Table 18-6: Required SSDFPAPI Parameters for the Multi-send API
Parameter Description INIT SEND TERM

TOKEN After successful INIT, the Multi-send API sends
the caller a token address that should be later
  
supplied when doing the SEND and TERM call. If
RACF authorization fails during the INIT call, the
TOKEN will not be populated.
DATA The EBCDIC/ASCII data address to be sent.
Maximum length is 384K.

LENGTH 4-byte integer field with the length of the data to be
sent.

RETCODE 4-byte field the return code will be stored in.   
REASON 4-byte field the reason code will be stored in.   
CCSID 4-byte field that optionally specifies if the type of
data is ASCII or EBCDIC. When specified, the

parameter count must equal nine. Valid CCSID
values are:
• 0037, 1047, 0500 and 1141 are supported for
EBCIDIC to ASCII translation.
• 0437 (ASCII) – When specified, Ironstream will
not translate ASCII, but will instead perform
the translation based on the
TRANSLATE_TABLE parameter specified in
the Ironstream job.
Note: All the above are 4-byte address pointers (for 31-bit) or 8-byte address pointers (for
64- bit).
For descriptions of the Multi-send SSDFPAPI parameter formats, see “Multi-send API
Parameter List Format” on page 18-15
RACF Authorization for the Multi-send API

Similar to the Single-send API, the Multi-send API is protected from unauthorized access
via the use of RACF, or its functional equivalent. For the Multi-send API, however, the
RACF authorization is done during the INIT process. For more information, see “RACF
Authorization for the Single-send API” on page 18-7.

Using the Multi-send SSDFPAPI Routine

The Multi-send SSDFPAPI routine is provided as a standalone load module that can be
called or link edited statically into a calling program. To use it as a called routine, you only
need to have the SSDFPAPI module in a library that the calling program can access, such as
a STEPLIB or JOBLIB.
To statically link the Multi-send SSDFPAPI routine into a program you will have to add an
INCLUDE statement in the linkage or binder control statement file. You will also have to
add a DD statement that identifies the library that has the Multi-send SSDFPAPI routine in
it.
For more information about the Ironstream API Environmental Factors and Register
Conventions, see “Using the Single-send SSDFAPI Routine” on page 18-7
Multi-send API Parameter List Format

The Multi-send API parameter lists for the INIT, SEND, and TERM requests begin with the
parameter count total, followed by eight mandatory fullword addresses that point to the
parameters. For SEND there is also an optional parameter that specifies the CCSID code
page number of the user data. When CCSID is specified, the parameter count must equal
nine. It is important to maintain the class order.
INIT Parameter List
Table 18-7: INIT Request Parameter List
Address Description
+4 4-byte string that contains the INIT request.
+8 4-byte string that contains the CLASS value.
+12 4-byte string that contains the TYPE value.
+16 4-byte string that contains the SUBTYPE value.
+20 Fullword that is empty when calling the Multi-send API.
Upon return from the stub module, it will have an address
that needs to be used for SEND. (TOKEN)

SEND Parameter List

Table 18-8: SEND Request Parameter List
Address Description
+4 4-byte string that contains the SEND request.
+8 Fullword whose value is populated by the stub module after
successful completion of INIT. (TOKEN)
+12 The start of the EBCDIC or ASCII data to send.
+16 Fullword that contains the length of the data.
+28 Fullword (optional) that specifies the CCSID code page
number of the collected data (0037 for EBCIDIC and 0437 for
ASCII). If not specified, the data is treated as EBCDIC.
TERM Parameter List

Table 18-9: TERM Request Parameter List
Address Description
+4 4-byte string that contains the TERM request.
+8 4-byte string that contains the token address.
+12 Full word that on return is set with the return code.
+16 Full word that on return is set with the reason code.
Performance and Maintenance Considerations

In environments that are consistent from call-to-call and where it is necessary to send
multiple records in batch mode, the Multi-send API can achieve significant performance
improvements in ELAP and CPU on a per-record basis as compared to the Single-send API.
For performance reasons, Syncsort recommends that the Multi-send SSDFPAPI module be
loaded once and called repeatedly, or statically linked into the calling routine. Loading the
SSDFAPI routine once can be done in assembler using the LOAD macro.
For more information, see “Performance and Maintenance Considerations” on page 18-10.

Linking SSDFPAPI Into a Load Module

These control statements can be used by either the linkage editor or the binder, as shown in
Figure 18-2.
Figure 18-2. Control Statement for SSDFPAPI
//STUBLIB DD DISP=SHR,DSN=hlq.SSDF011.R14.LOADLIB
//SYSLIN DD *
.
.
.
INCLUDE STUBLIB(SSDFPAPI)
.
.
.
NAME YOURPGM(R)
/*
Starting a Multi-send API Instance

Use the following command when starting a Multi-send API instance:
S SDFPAPI,REUSASID=YES
Starting a Multi-send API instance ("DATATYPE":"IRONSTREAM_API") as a user job, or
without using the REUSASID=YES parameter, will cause the address space that the instance
runs in to be marked as non-reusable and, in extreme cases, can require an IPL of the
system if API instances are started and stopped multiple times.
This parameter is not required for any other type of Ironstream forwarder.
Troubleshooting the Ironstream API

The following sections contain information that can help you troubleshoot the Ironstream
API using return and reason codes and system messages.
Note: Using the Data Loss Prevention (DLP) feature and the Ironstream API requires the
availability of a Monoplex or Sysplex Coupling Facility processor for logging data in a log
stream. Therefore, it’s possible that Ironstream may also generate return and reason codes
from IBM’s IXGWRITE macro, which writes log data to a log stream.
• For more information about the reason and return codes for the IXGWRITE macro, see
the MVS Programming: Assembler Services Reference, Volume II, or contact your system
programmer.
• For more information about configuring and using DLP, see Chapter 10, “Configuring
Data Loss Prevention”.

Return Codes and Reason Codes Generated by the Ironstream API

The following Reason and Return codes may be returned by the both Single-send and
Multi-send API. In most cases, you should contact your local Syncsort office for technical
support (see “Diagnostics and Contacting Syncsort Product Support,” on page 28-1).
** RETURN CODE 12 , REASON CODE 01 - SSANCHOR STRUCTURE NOT FOUND
Explanation: An expected data structure was not found.
Action: Contact Syncsort Product Support.
** RETURN CODE 12 , REASON CODE 02 - SSDFSTAT STRUCTURE NOT FOUND

** RETURN CODE 12 , REASON CODE 03 - SSDFCVEC STRUCTURE NOT FOUND

** RETURN CODE 12 , REASON CODE 04 - CLASS ENTRY NOT FOUND

Explanation: No instances of Ironstream were found that support the
specified CLASS.
Action: Validate that at least one instance of Ironstream supports the
CLASS specified in the API call.
** RETURN CODE 12 , REASON CODE 05 - NO MATCHING INSTANCES TO PROCESS REQUEST

Explanation: No instances of Ironstream were found that support the
the CLASS/TYPE/SUBTYPE combination specified.
Action: Validate that at least one instance of Ironstream supports the
CLASS/TYPE/SUBTYPE specified in the API call.
** RETURN CODE 12 , REASON CODE 06 - SSANCHOR NOT VALID

Explanation: An expected data structure could not be validated.
** RETURN CODE 12 , REASON CODE 07 - SSDFSTAT NOT VALID

** RETURN CODE 12 , REASON CODE 09 - SSDFINST NOT VALID

** RETURN CODE 12 , REASON CODE 10 - STORAGE OBTAIN FAILURE

Explanation: The API could not acquire working storage.
** RETURN CODE 12 , REASON CODE 11 - RACF VERIFICATION FAILED

Explanation: The user ID associated with this caller of the API lacks
sufficient RACF authorization.
Action: Contact your RACF, or functional equivalent, administrator.
** RETURN CODE 12 , REASON CODE 12 - WRONG REQUEST PARM

Explanation: The REQUEST parameter was not "SEND".
Action: Correct the parameter passed.
** RETURN CODE 12 , REASON CODE 13 - WRONG CLASS PARAMETER


** RETURN CODE 12 , REASON CODE 14 - DATA LENGTH >= 384K

Explanation: The message to be sent is greater than 384K.
Action: Segment the message into less than 384K pieces.
** RETURN CODE 12 , REASON CODE 15 - DATASTORE IS FULL

Explanation: A DATASTORE FULL condition occurred when writing a message to the
internal data store. The message was not written
Action: See “Handling Data Store Full Conditions” on page 18-20.
** RETURN CODE 12 , REASON CODE 16 - NAME TOKEN ERROR

** RETURN CODE 12 , REASON CODE 17 - WRITE DATASTORE ERROR

Explanation: A DATASTORE FULL condition was detected before attempting to
write the message to the internal data store.
Action: See “Handling Data Store Full Conditions” on page 18-20.
** RETURN CODE 12 , REASON CODE 18 - SSDFUAPI NOT VALID

Explanation: The version of SSDFUAPI was inconsistent with the SSDFAPI code.
** RETURN CODE 12 , REASON CODE 19 - STORAGE RELEASE FAILURE

Explanation: The API could not release working storage.
** RETURN CODE 12 , REASON CODE 20 - STEPPING STONE ROUTINE NOT PRESENT

Explanation: The expected routine address was not found.
** RETURN CODE 12 , REASON CODE 21 - NUMBER OF PARAMETERS IS INVALID

Explanation: The total number of parameters must be equal to or greater than
the mandatory number of eight parameters.
Action: Correct the number of parameters.
** RETURN CODE 12 , REASON CODE 22 - ZERO VALUE PASSED FOR LENGTH PARAMETER
Explanation: The LENGTH parameter cannot have a value of zero.
Action: Supply a non-zero value for the LENGTH parameter.
** RETURN CODE 12 , REASON CODE 23 - INVALID TOKEN SUPPLIED

Explanation: The TOKEN that was obtained after the INIT process should be supplied
to the SEND and TERM processes. If the TOKEN is zero, then it is invalid.
Action: Supply the correct value for the TOKEN parameter.
** RETURN CODE 4, REASON CODE 1 - ONE OR MORE INSTANCES OF IRONSTREAM NOT FOUND
DURING SEND PROCESS
Explanation: At the time of the INIT process, the number of Ironstream instances that
matched the specified CLASS/TYPE/SUBTYPE combination were not found.
Action: Verify whether all your Ironstream instances are running.
** RETURN CODE 12 , REASON CODE 23 - INVALID TOKEN SUPPLIED

Explanation: The TOKEN that was obtained after the INIT process should be supplied
to the SEND and TERM processes. If the TOKEN is zero, then it is invalid.
Action: Supply the correct value for the TOKEN parameter.
** RETURN CODE 4, REASON CODE 1 - ONE OR MORE INSTANCES OF IRONSTREAM NOT FOUND
DURING SEND PROCESS

Explanation: At the time of the INIT process, the number of Ironstream instances that
matched the specified CLASS/TYPE/SUBTYPE combination were not found.
Action: Verify whether all your Ironstream instances are running.
Handling Data Store Full Conditions

Data Store full conditions should rarely occur in a well-configured environment. Generally,
multiple messages should have been reported by the Ironstream address space prior to this
occurring. These messages include SDF0126S, SDF0127S, and SDF0128S, which report on
the number of messages held in the data store and the status of the TCP connections.
Data Store full conditions are reported to the caller of the Ironstream API using two
different Reason Codes:
• Reason Code 15 is returned when an attempt is made to write a message into the data
store and there is no space in the data store to hold the message. At that point an
internal flag is set to prevent any more attempts to store data in the data store until all
the current data in the data store has been forwarded and the flag is reset.
• During the interval between detecting the data store is full and when the flag is reset,
Reason Code 17 is returned to the caller of the API. Once the flag has been reset, the
API will return a Return Code of 0.
How individual users of the Ironstream API deal with a Data Store full condition depends on
the nature of the application.
• Real-time application — When a Reason Code 15 is detected it may output a message
indicating the time and date when the event occurred and continue processing. The
application could continue to attempt to send messages via the API and ignore the
Reason Code 17 occurrences, and when it receives a Return Code of 0, it outputs another
message to indicate when collection resumed.
• Batch application — When a Reason Code 15 is detected, the application may output a
message, as in the real-time case, but in this case it could wait 1–5 seconds and then try
to send the message again and repeat this until a return code 0 is received, and then
send another message to indicate collection has resumed. Therefore, it may be prudent
to put a limit count for the number of failures so the program does not sit in an infinite
loop.

Ironstream API Coding Examples

This section contains codding examples for both the Single-send and the Multi-send APIs.
• “Single-Send API Examples” on page 18-21
• “Multi-send API Coding Examples” on page 18-36
Single-Send API Examples

This section contains Assembler (non-reentrant, reentrant, and 64-bit non-reentrant), C,
COBOL, and REXX coding examples for using the Ironstream SSDFAPI routine to send
data to Ironstream. There is also an example of a COBOL program for CICS that uses the
CICS SSDFCAPI routine.
• “Assembler Single-send API Examples” on page 18-21
• “C Single-send API Example” on page 18-28
• “COBOL Single-send API Example” on page 18-30
• “REXX Single-send API Example” on page 18-32
• “COBOL on CICS Single-send API Example” on page 18-34
Assembler Single-send API Examples
Assembler: Non-Re-entrant Using a Static Call

*******************************************************
* MODULE NAME: BIBDASM1 (ASM CALLER) *
* SAMPLE ASM CODE WHICH CALLS THE IRONSTREAM STUB *
* ROUTINE AND SENDS DATA TO IRONSTREAM *
* THIS IS A NON-REENTRANT VERSION *
* *
* PARAMETERS MUST BE IN THE FOLLOWING ORDER *
* *
* MANDATORY PARAMETERS *
* -------------------- *
* NUMPARM - PARAMETER COUNT *
* REQUEST - THIS HAS TO BE 'SEND' *
* CLASS - THIS CAN BE FROM X'80' TO X'FF' *
* TYPE - THIS CAN BE FROM X'00' TO X'FF' *
* SUBTYPE - THIS CAN BE FROM X'00' TO X'FF' *
* DATA - USER DATA *
* DATA LENGTH - THE LENGTH OF THE USER DATA *
* RETURN CODE - *
* REASON CODE - *
* *
* OPTIONAL PARAMETERS *
* -------------------- *
* CCSID - CODE PAGE (0037- EBCDIC OR 0437 - ASCII) *
***************************************************** *
BIBDASM1 CSECT
BIBDASM1 AMODE 31
BIBDASM1 RMODE ANY
BAKR R14,0
LR R12,R15 GET BASE ADDRESS
USING BIBDASM1,R12 IDENTIFY BASE REGISTER

CALL
SSDFAPI,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,DATA,LENGTH,-
RETCODE,RSNCODE,CCSID)
LTR R15,R15
BZ CALLOK
*********************************************************************
* ERROR OCCURED, R15 HAS THE RETURN CODE *
* RETCODE AND RSNCODE WILL HAVE RETURN AND REASON CODE TOO *
*********************************************************************
LR R5,R15
WTO 'USER API ERROR IN ASM PROGRAM',ROUTCDE=(11)
B CLEANUP
*********************************************************************
* SENDING DATA SUCCESSFUL, FREE THE STORAGE WE GET AT THE BEGINNING *
*********************************************************************
CALLOK DS 0H
LR R5,R15
WTO 'USER API ASM PROGRAM SUCCESSFULLY FINISHED',ROUTCDE=(11+
)
*
CLEANUP DS 0H
*
LR R15,R5
PR ,
*
*
REQUEST DC CL4'SEND'
DATA DC CL40'TEST DATA BEING SENT TO SPLUNK USING ASM'
LENGTH DC F'40'
RETCODE DC F'0'
RSNCODE DC F'0'
CLASS DC X'80' ONLY SUPPORT FROM X'80' TO X'FF' FOR USER API
TYPE DC X'01' TYPE CAN BE FROM X'00' TO X'FF' FOR USER API
SUBTYPE DC X'01' SUBTYPE CAN BE FROM X'00' TO X'FF'
CCSID DC F'0037'
NUMPARM DC F'9'
**************************************************************
* *
* REGISTER EQUATES *
* *
**************************************************************
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12
R13 EQU 13
R14 EQU 14
R15 EQU 15
END BIBDASM1

Assembler: Re-entrant Using a Dynamic LOAD

*******************************************************
* MODULE NAME: BIBDASM2 (ASM CALLER) *
* ROUTINE SSDFAPI AND SENDS DATA TO IRONSTREAM *
* THIS IS A REENTRANT VERSION *
* *
* *
* -------------------- *
* RETURN CODE - *
* REASON CODE - *
* *
* -------------------- *
***************************************************** *
BIBDASM2 CSECT
BIBDASM2 AMODE 31
BIBDASM2 RMODE ANY
BAKR R14,0
LR R12,R15
USING BIBDASM2,R12
*****************************************************
* GET STORAGE FOR TEMPORARY WORKING DATA
*****************************************************
ASMC0100 DS 0H
LA R0,WORKLEN
GETMAIN RC,LV=(0),SP=0,LOC=31
LR R8,R1
USING SAVEWORK,R8
***********************************************************
* SETUP THE PARAMETERS AND CALL IRONSTREAM STUB ROUTINE *
***********************************************************
MVC REQUEST(4),MYREQUST
MVI CLASS,MYCLASS
MVI TYPE,MYTYPE
MVI SUBTYPE,MYSUBTP
MVC DATA(40),MYDATA
LHI R5,40
ST R5,LENGTH
MVC CCSID,MYCCSID
MVC NUMPARM,=F'9'
*
LA R5,NUMPARM
ST R5,PARMADDR+0
LA R5,REQUEST
ST R5,PARMADDR+4
LA R5,CLASS
ST R5,PARMADDR+8

LA R5,TYPE
ST R5,PARMADDR+12
LA R5,SUBTYPE
ST R5,PARMADDR+16
LA R5,DATA
ST R5,PARMADDR+20
LA R5,LENGTH
ST R5,PARMADDR+24
LA R5,RETCODE
ST R5,PARMADDR+28
LA R5,REASON
ST R5,PARMADDR+32
LA R5,CCSID
ST R5,PARMADDR+36
CALL
SSDFAPI,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE, -
DATA,LENGTH,RETCODE,REASON,CCSID),MF=(E,PARMADDR)
LTR R15,R15
BZ CALLOK
*********************************************************************
*********************************************************************
LR R5,R15
B CLEANUP
*********************************************************************
*********************************************************************
CALLOK DS 0H
LR R5,R15
)
*
CLEANUP DS 0H
LA R0,WORKLEN
FREEMAIN RC,LV=(R0),A=(R8)
*
LR R15,R5
PR ,
DROP R8,R12
*
*
MYCLASS EQU X'80' ONLY SUPPORT FROM X'80' TO X'FF' FOR USER API
MYTYPE EQU X'01' TYPE CAN BE FROM X'01' TO X'FF' FOR USER API
MYSUBTP EQU X'01' SUBTYPE CAN BE FROM X'01' TO X'FF'
MYCCSID DC F'037' CCID EBCDIC (0037) OR ASCII (0437)
MYREQUST DC CL4'SEND'
MYDATA DC CL40'TEST DATA BEING SENT TO SPLUNK USING ASM'
*********************************************************************
* TEMPORARY WORK AREA DSECT *
*********************************************************************
SAVEWORK DSECT
NUMPARM DS F
REQUEST DS F
DATA DS CL80
LENGTH DS F
RETCODE DS F
REASON DS F
CLASS DS XL1

TYPE DS XL1
SUBTYPE DS XL1
CCSID DS F
PARMADDR CALL ,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,DATA,LENGTH, -
RETCODE,REASON,CCSID),MF=L
WORKLEN EQU *-SAVEWORK
**************************************************************
* *
* *
**************************************************************
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12
R13 EQU 13
R14 EQU 14
R15 EQU 15
END BIBDASM2

Assembler 64-bit: Non-Re-entrant Using a Static Call

In order to enable the Single-send API to use 64-bit Assembler programs, you must set the
SYSSTATE parameter to AMODE64=YES.
*******************************************************
* MODULE NAME: BIBDAS64 (ASM CALLER) *
* *
* *
* -------------------- *
* RETURN CODE - *
* REASON CODE - *
* *
* -------------------- *
***************************************************** *
BIBDAS64 CSECT
BIBDAS64 AMODE 64
BIBDAS64 RMODE ANY
BAKR R14,0
SYSSTATE AMODE64=YES
LARL R12,BIBDAS64
USING BIBDAS64,R12 IDENTIFY BASE REGISTER
CALL SSDFAPI,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,DATA,LENGTH,-
RETCODE,RSNCODE,CCSID)
LTR R15,R15
BZ CALLOK
*********************************************************************
*********************************************************************
LR R5,R15
B CLEANUP
*********************************************************************
*********************************************************************
CALLOK DS 0H
LR R5,R15
)
*
CLEANUP DS 0H
*
LR R15,R5

PR ,
*
*
REQUEST DC CL4'SEND'
DATA DC CL40'TEST DATA BEING SENT TO SPLUNK USING ASM'
LENGTH DC F'40'
RETCODE DC F'0'
RSNCODE DC F'0'
CCSID DC F'0037'
NUMPARM DC F'9'
**************************************************************
* *
* *
**************************************************************
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12
R13 EQU 13
R14 EQU 14
R15 EQU 15
END BIBDAS64

C Single-send API Example

/******************************************************
* MODULE NAME: BIBDCPGM (C LANGUAGE CALLER) *
* SAMPLE C CODE WHICH CALLS THE IRONSTREAM STUB *
* *
* *
* -------------------- *
* RETURN CODE - *
* REASON CODE - *
* *
* -------------------- *
***************************************************** */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define ironstream_load() (funcV*) fetch("SSDFAPI")

#define ironstream_send(n,c,t,s,d,l,rt,rsn,cs) \
(*stub)(n,"SEND",c,t,s,d,l,rt,rsn,cs)
typedef int funcV();
#pragma linkage(funcV, OS)
main(int argc, char *argv[])
{
int numparm;
char *request;
char class;
char type;
char subtype;
char *data;
int length;
int retcode;
int rsncode;
int ccsid;
int rc;
numparm=9;
request= "SEND";
class=0x80;
type=0x01;
subtype=0x01;
ccsid=37;
funcV *stub;
data="TEST DATA BEING SENT TO SPLUNK USING CPG";

length = strlen(data);

printf("Fetching the SSDFAPI\n");
stub = ironstream_load();
if (stub == NULL)
{
printf("Error: Fetch of SSDFAPI Failed\n");
}
else
{
printf("Executing the fetched module\n");
rc = ironstream_send(&numparm,&class,&type,&subtype,data,
&length,&retcode,&rsncode,&ccsid);
if (rc != 0)
printf("C PGM ERROR, RETURN CODE %d, REASON CODE %d\n",
retcode,rsncode);
else
printf("USER API C PROGRAM SUCCESSFULLY FINISHED");
return rc;
}
}

COBOL Single-send API Example

*******************************************************
* MODULE NAME: BIBDCOBC (COBOL CALLER) *
* SAMPLE COBOL CODE WHICH CALLS THE IRONSTREAM STUB *
* *
* *
* -------------------- *
* RETURN CODE - *
* REASON CODE - *
* *
* -------------------- *
*******************************************************
IDENTIFICATION DIVISION.
PROGRAM-ID. BIBDCOBC.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 PARMVALS.
05 NUMPARM PIC S9(8) USAGE BINARY.
05 REQUEST PIC X(4).
05 CLASSV PIC X(1) VALUE X'80'.
05 TYPEV PIC X(1) VALUE X'01'.
05 SUBTYPE PIC X(1) VALUE X'01'.
05 DATAV PIC X(80).
05 LENGTHV PIC S9(8) USAGE BINARY.
05 RETCODE PIC S9(8) USAGE BINARY.
05 RSNCODE PIC S9(8) USAGE BINARY.
05 CCSID PIC S9(8) USAGE BINARY.
*****************************************************************
LINKAGE SECTION.
PROCEDURE DIVISION.
A100-MAIN.
PERFORM A200-SEND-PARA THRU A200-EXIT.
GOBACK.
A100-EXIT.
EXIT.
A200-SEND-PARA.
MOVE 9 TO NUMPARM
MOVE "SEND" TO REQUEST
MOVE "TEST DATA BEING SENT TO SPLUNK USING COBOL" TO DATAV
MOVE 42 TO LENGTHV
MOVE 37 TO CCSID
CALL 'SSDFAPI' USING NUMPARM

REQUEST
CLASSV
TYPEV
SUBTYPE
DATAV
LENGTHV
RETCODE
RSNCODE
CCSID.
IF (RETCODE EQUAL ZEROS AND RSNCODE EQUAL ZEROS) THEN
DISPLAY "USER STUB COBOL PROGRAM SUCCESSFULLY FINISHED"
ELSE
DISPLAY "COBOL PGM ERROR: "
DISPLAY "RETURN CODE " RETCODE ", REASON CODE " RSNCODE
END-IF.
A200-EXIT.
EXIT.

REXX Single-send API Example

/*REXX*/
/*******************************************************/
/* MODULE NAME: BIBDREXC (REXX LANGUAGE CALLER) */
/* SAMPLE REXX CODE WHICH CALLS THE IRONSTREAM STUB */
/* ROUTINE AND SENDS DATA TO IRONSTREAM */
/* */
/* PARAMETERS MUST BE IN THE FOLLOWING ORDER */
/* */
/* MANDATORY PARAMETERS */
/* -------------------- */
/* NUMPARM - PARAMETER COUNT */
/* REQUEST - THIS HAS TO BE 'SEND' */
/* CLASS - THIS CAN BE FROM X'80' TO X'FF' */
/* TYPE - THIS CAN BE FROM X'00' TO X'FF' */
/* SUBTYPE - THIS CAN BE FROM X'00' TO X'FF' */
/* DATA - USER DATA */
/* DATA LENGTH - THE LENGTH OF THE USER DATA */
/* RETURN CODE - */
/* REASON CODE - */
/* */
/* OPTIONAL PARAMETERS */
/* -------------------- */
/* CCSID - CODE PAGE (0037- EBCDIC OR 0437 - ASCII) */
/***************************************************** */
NUMPARM = 9
REQUEST = 'SEND'
CLASS = 128
TYPE = 1
SUBTYPE = 1
CCSID = 37
DATA = 'TEST DATA BEING SENT TO SPLUNK USING REXX'
LENGTHA = length(DATA)
RETCODE = 0
RSNCODE = 0
rc1 = CALL_IRONSTREAM(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,DATA,LENGTHA,
,RETCODE,RSNCODE,CCSID)
if (rc1==0) then do
Say 'USER API REXX PROGRAM SUCCESSFULLY FINISHED'
end
EXIT
CALL_IRONSTREAM:
NUMPARM = d2c(arg(1),4)
CLASS = d2c(arg(3),1)
TYPE = d2c(arg(4),1)
SUBTYPE = d2c(arg(5),1)
LENGTHA = d2c(arg(7),4)
RETCODE = d2c(arg(8),4)
RSNCODE = d2c(arg(9),4)
CCSID = d2c(arg(10),4)
address linkpgm 'SSDFAPI NUMPARM REQUEST CLASS TYPE SUBTYPE DATA

LENGTHA RETCODE RSNCODE CCSID'

RETCODD = c2d(RETCODE,4)
RSNCODD = c2d(RSNCODE,4)
if (RETCODD > 0) then do

Say 'REXX PGM ERROR, RETURN CODE' RETCODD ', REASON CODE ' RSNCODD
exit RETCODD
end
RETURN RETCODD

COBOL on CICS Single-send API Example

CBL LIB,APOST
CBL XOPTS(DLI,CICS)
CBL LIST
*******************************************************
* MODULE NAME: BIBDCOBC (CICS COBOL CALLER) *
* SAMPLE CICS CODE WHICH CALLS THE IRONSTREAM STUB *
* *
* *
* --------------------
* RETURN CODE - *
* REASON CODE - *
* *
* -------------------- *
*******************************************************
PROGRAM-ID BIBDAPI1.
*--------------------------------------------------------------*
*- THIS IS A CICS PROGRAM THAT USES THE IRONSTREAM API -*
*--------------------------------------------------------------*
DATA DIVISION.
******************************************************************
01 APIPARM .
05 NUMPARM-PTR USAGE IS POINTER.
05 REQUEST-PTR USAGE IS POINTER.
05 CLASSV-PTR USAGE IS POINTER.
05 TYPEV-PTR USAGE IS POINTER.
05 SUBTYPE-PTR USAGE IS POINTER.
05 DATAV-PTR USAGE IS POINTER.
05 LENGTHV-PTR USAGE IS POINTER.
05 RETCODE-PTR USAGE IS POINTER.
05 RSNCODE-PTR USAGE IS POINTER.
05 CCSID-PTR USAGE IS POINTER.
05 NUMPARM PIC S9(8) USAGE BINARY VALUE 9.
05 DATAV PIC X(80).
05 CCSID PIC S9(8) USAGE BINARY VALUE 37.

******************************************************************
01 K-LEN PIC 99 COMP VALUE 5 .
01 K-VAL PIC X(05) .
01 OUT-LEN PIC S9999 COMP VALUE 27.

01 OUT-BLOCK .
02 TEXT1 PIC X(8) VALUE 'BIBDAPI1' .
02 FILLER PIC X(1) VALUE ' ' .
02 TEXT2 PIC X(5) VALUE 'BEGUN' .
02 FILLER PIC X(1) VALUE ' ' .
02 TEXT3 PIC X(12) VALUE 'SUCCESSFULLY'.
PROCEDURE DIVISION.
MAIN-START.
SET NUMPARM-PTR TO ADDRESS OF NUMPARM.
SET REQUEST-PTR TO ADDRESS OF REQUEST.
SET CLASSV-PTR TO ADDRESS OF CLASSV .
SET TYPEV-PTR TO ADDRESS OF TYPEV .
SET SUBTYPE-PTR TO ADDRESS OF SUBTYPE.
SET DATAV-PTR TO ADDRESS OF DATAV .
SET LENGTHV-PTR TO ADDRESS OF LENGTHV.
SET RETCODE-PTR TO ADDRESS OF RETCODE.
SET RSNCODE-PTR TO ADDRESS OF RSNCODE.
SET CCSID-PTR TO ADDRESS OF CCSID.
A200-SEND-PARA.
MOVE "SOURCE1 IRONSTREAM_API FROM COBOL *CICS*" TO DATAV
MOVE 40 TO LENGTHV
PERFORM A400-SEND-PARA.
MOVE 'ENDED' TO TEXT2.

EXEC CICS SEND FROM (OUT-BLOCK)
LENGTH(OUT-LEN) ERASE END-EXEC.
MOVE 0 TO RETURN-CODE .
EXEC CICS RETURN END-EXEC.
MAIN-END .
STOP RUN.
GOBACK.
A400-SEND-PARA.
EXEC CICS LINK PROGRAM('SSDFCAPI')
COMMAREA(APIPARM) END-EXEC.
NEXT SENTENCE
ELSE
DISPLAY "COBOL PGM ERROR: "
END-IF.
A400-SEND-PARA-END.

Multi-send API Coding Examples

This section contains Assembler (non-reentrant, reentrant, and 64-bit non-reentrant), C,
COBOL, and REXX coding examples for using the Multi-send SSDFPAPI routine to send
data to Ironstream.
• “Assembler Multi-send API Examples” on page 18-37
• “C Multi-send API Example” on page 18-43
• “COBOL Multi-send API Example” on page 18-46
• “REXX Multi-send API Example” on page 18-49

Assembler Multi-send API Examples
Assembler: Non-Re-entrant Using a Static Call

*******************************************************
* MODULE NAME: PAPIASM1 (ASM CALLER) *
* SAMPLE ASM CODE THAT CALLS THE IRONSTREAM STUB *
* *
* *
* PARAMETER LIST *
* -------------- *
* INIT *
* ==== *
* NUMPARM - NUMBER OF PARAMETERS *
* REQUEST - THIS HAS TO BE 'INIT' *
* TOKEN - TOKEN WILL BE PASSED TO YOU AFTER INIT *
* RETURN CODE - *
* REASON CODE - *
* *
* SEND *
* ==== *
* TOKEN - USE THE PASSED TOKEN FROM INIT HERE *
* RETURN CODE - *
* REASON CODE - *
* (CCSID IS A OPTIONAL PARAMETER) *
* *
* TERM *
* ==== *
* REQUEST - THIS HAS TO BE 'TERM' *
* RETURN CODE - *
* REASON CODE - *
***************************************************** *
PAPIASM1 CSECT
PAPIASM1 AMODE 31
PAPIASM1 RMODE ANY
BAKR R14,0
USING PAPIASM1,R12 IDENTIFY BASE REGISTER
**INIT CALL
CALL SSDFPAPI,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,TOKEN,RETCO-
DE,RSNCODE)
LTR R15,R15
BZ CALLOK

*********************************************************************
*********************************************************************
LR R5,R15
B CLEANUP
*********************************************************************
*********************************************************************
LHI R10,0
CALLOK DS 0H
**SEND CALL
MVC REQUEST,=CL4'SEND'
CALL SSDFPAPI,(NUMPARM,REQUEST,TOKEN,DATA,LENGTH,RETCODE,RSNC-
ODE,RSNCODE,CCSID)
LTR R15,R15
JNZ CALLTERM
L R7,RETCODE
L R8,RSNCODE
AHI R10,1
C R10,=F'50' EXECUTE IT FOR 50 TIMES

JE CALLTERM
J CALLOK
*
CALLTERM DS 0H
MVC REQUEST,=CL4'TERM'
*
LR R5,R15
)
*
CLEANUP DS 0H
LR R15,R5
PR ,
*
*
REQUEST DC CL4'INIT'
DATA DC CL40'HELLO THIS IS PERSISTENT API TEST'
LENGTH DC F'40'
TOKEN DC F'0'
RETCODE DC F'0'
RSNCODE DC F'0'
NUMPARM DC F'8'
CCSID DC F'0037'
TIMERID DS F
STIMERMS STIMERM SET,MF=L

**************************************************************
* *
* *
**************************************************************
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12
R13 EQU 13
R14 EQU 14
R15 EQU 15
END PAPIASM1

Assembler 64-bit: Non-Re-entrant Using a Static Call

In order to enable the Multi-send API to use 64-bit Assembler programs, you must set the
SYSSTATE parameter to AMODE64=YES.
*******************************************************
* MODULE NAME: PAPIAS64 (ASM CALLER) *
* SAMPLE ASM CODE THAT CALLS THE IRONSTREAM STUB *
* *
* *
* PARAMETER LIST *
* -------------- *
* INIT *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* SEND *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* TERM *
* ==== *
* RETURN CODE - *
* REASON CODE - *
***************************************************** *
PAPIAS64 CSECT
PAPIAS64 AMODE 64
PAPIAS64 RMODE ANY
BAKR R14,0
SYSSTATE AMODE64=YES
LARL R12,PAPIAS64
USING PAPIAS64,R12 IDENTIFY BASE REGISTER
**INIT CALL
CALL SSDFPAPI,(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,TOKEN,RETCO-
DE,RSNCODE)
LTR R15,R15
BZ CALLSEND

*********************************************************************
* ERROR OCCURED IN INIT PHASE *
*********************************************************************
LR R5,R15
WTO 'USER API ERROR IN INIT CALL',ROUTCDE=(11)
B CLEANUP
**SEND CALL
CALLSEND DS 0H
MVC REQUEST,=CL4'SEND'
CALL SSDFPAPI,(NUMPARM,REQUEST,TOKEN,DATA,LENGTH,RETCODE,RSNC-
ODE,CCSID)
*
LTR R15,R15
BZ CALLTERM
*********************************************************************
* ERROR OCCURED IN SEND PHASE *
*********************************************************************
LR R5,R15
WTO 'USER API ERROR IN SEND CALL',ROUTCDE=(11)
B CLEANUP
*TERM CALL
CALLTERM DS 0H
MVC REQUEST,=CL4'TERM'
*
LTR R15,R15
BZ CALLOK
*********************************************************************
* ERROR OCCURED IN SEND PHASE *
*********************************************************************
LR R5,R15
WTO 'USER API ERROR IN TERM CALL',ROUTCDE=(11)
B CLEANUP
CALLOK DS 0H
LR R5,R15
)
*
CLEANUP DS 0H
*
LR R15,R5
PR ,
*
*
REQUEST DC CL4'INIT'
DATA DC CL40'TEST DATA BEING SENT FROM ASM 64 BIT'
LENGTH DC F'40'
RETCODE DC F'0'
RSNCODE DC F'0'
TOKEN DC F'0'
CCSID DC F'0037'
NUMPARM DC F'8'

**************************************************************
* *
* *
**************************************************************
R0 EQU 0
R1 EQU 1
R2 EQU 2
R3 EQU 3
R4 EQU 4
R5 EQU 5
R6 EQU 6
R7 EQU 7
R8 EQU 8
R9 EQU 9
R10 EQU 10
R11 EQU 11
R12 EQU 12
R13 EQU 13
R14 EQU 14
R15 EQU 15
END PAPIAS64

C Multi-send API Example

*******************************************************
* MODULE NAME: PAPICPGM (C LANGUAGE CALLER) *
* SAMPLE C CODE THAT CALLS THE IRONSTREAM STUB *
* *
* PARAMETER LIST *
* -------------- *
* INIT *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* SEND *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* TERM *
* ==== *
* RETURN CODE - *
* REASON CODE - *
***************************************************** */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define ironstream_load() (funcV*) fetch("SSDFPAPI")

#define ironstream_init(n,c,t,s,tk,rt,rsn) \
(*stub)(n,"INIT",c,t,s,tk,rt,rsn)
#define ironstream_send(n,tk,d,l,rt,rsn,cs) \
(*stub)(n,"SEND",tk,d,l,rt,rsn,cs)
#define ironstream_term(n,tk,rt,rsn) \
(*stub)(n,"TERM",tk,rt,rsn)
typedef int funcV();
#pragma linkage(funcV, OS)
main(int argc, char *argv[])
{
int numparm;
char *request;
char class;
char type;

char subtype;
char *data;
int token;
int length;
int retcode;
int rsncode;
int ccsid;
int rc;
numparm=9;
token = 0;
request= "SEND";
class=0x80;
type=0x01;
subtype=0x02;
ccsid=37;
funcV *stub;
data="TEST DATA BEING SENT TO SPLUNK USING CPG";

length = strlen(data);
printf("Fetching the SSDFPAPI\n");
stub = ironstream_load();
if (stub == NULL)
{
printf("Error: Fetch of SSDFAPI Failed\n");
}
else
{
rc = ironstream_init(&numparm,&class,&type,&subtype,
&token,&retcode,&rsncode);
if (rc == 0)
printf("INIT completed successfully\n");
else
{
printf("INIT ERROR, RETURN CODE %d, REASON CODE %d\n",
retcode,rsncode);
return rc;
}
rc = ironstream_send(&numparm,&token,data,
&length,&retcode,&rsncode,&ccsid);
if (rc == 0)
printf("SEND completed successfully\n");
else
{
printf("SEND ERROR, RETURN CODE %d, REASON CODE %d\n",
retcode,rsncode);
return rc;
}
rc = ironstream_term(&numparm,&token,&retcode,&rsncode);

if (rc == 0)
printf("TERM completed successfully\n");
else
{
printf("TERM ERROR, RETURN CODE %d, REASON CODE %d\n",
retcode,rsncode);
return rc;
}
return rc;
}
}

COBOL Multi-send API Example

*******************************************************
* MODULE NAME: PAPICOBC (COBOL CALLER) *
* SAMPLE COBOL CODE THAT CALLS THE IRONSTREAM STUB *
* *
* *
* PARAMETER LIST *
* -------------- *
* INIT *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* SEND *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* TERM *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
*******************************************************
PROGRAM-ID. PAPICOBC.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
01 PARMVALS.
05 NUMPARM PIC S9(8) USAGE BINARY.
05 TOKEN PIC X(4).
05 DATAV PIC X(80).


05 CCSID PIC S9(8) USAGE BINARY.
01 PGM-NAME PIC X(10).
*****************************************************************
LINKAGE SECTION.
PROCEDURE DIVISION.
A100-MAIN.
PERFORM A200-INIT-PARA.
PERFORM A300-SEND-PARA 10 TIMES.
PERFORM A400-TERM-PARA.
GOBACK.
A100-EXIT.
EXIT.
A200-INIT-PARA.
MOVE 8 TO NUMPARM
MOVE "INIT" TO REQUEST
MOVE "SSDFPAPI" TO PGM-NAME
CALL PGM-NAME USING NUMPARM
REQUEST
CLASSV
TYPEV
SUBTYPE
TOKEN
RETCODE
RSNCODE.
DISPLAY "INIT STEP COMPLETED SUCCESSFULLY"
ELSE
DISPLAY "ERROR IN INIT CALL"
MOVE 12 TO RETURN-CODE
GOBACK
END-IF.
A200-EXIT.
EXIT.
A300-SEND-PARA.
MOVE 8 TO NUMPARM
MOVE '{"TYP":"TXT","TEXT":"TEST DATA FROM COBOL"}'
TO DATAV
MOVE LENGTH OF DATAV TO LENGTHV
MOVE 37 TO CCSID
REQUEST
TOKEN
DATAV
LENGTHV
RETCODE
RSNCODE
CCSID.
DISPLAY "SEND COMPLETED SUCCESSFULLY"
ELSE
DISPLAY "ERROR IN SEND CALL"

END-IF.
A300-EXIT.
EXIT.
A400-TERM-PARA.
MOVE 5 TO NUMPARM
MOVE "TERM" TO REQUEST
REQUEST
TOKEN
RETCODE
RSNCODE.
DISPLAY "TERM COMPLETED SUCCESSFULLY"
ELSE
DISPLAY "ERROR IN TERM CALL"
END-IF.
A400-EXIT.
EXIT.

REXX Multi-send API Example

*******************************************************
* MODULE NAME: PAPIREXC (REXX LANGUAGE CALLER) *
* SAMPLE REXX CODE THAT CALLS THE IRONSTREAM STUB *
* INIT *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* SEND *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
* TERM *
* ==== *
* RETURN CODE - *
* REASON CODE - *
* *
***************************************************** *
** ASSIGN INITIAL VALUES FOR THE VARIABLES */
NUMPARM = 9
REQUEST = 'INIT'
CLASS = 128
TYPE = 1
SUBTYPE = 2
TOKEN = '00000000'X
CCSID = 37
DATA = 'TEST DATA BEING SENT FROM REXX'
RETCODE = 0
RSNCODE = 0
/*PREP AND CALL THE INIT ROUTINE */
NUMPARM = 7
REQUEST = 'INIT'
RC1 = CALL_INIT(NUMPARM,REQUEST,CLASS,TYPE,SUBTYPE,TOKEN,RETCODE,
,RSNCODE)
if rc1 = 0 then do
say 'init completed successfully'
end

/*PREP AND CALL THE SEND ROUTINE */

NUMPARM = 7
REQUEST = 'SEND'
RETCODE = 0
RSNCODE = 0
RC1 = CALL_SEND(NUMPARM,REQUEST,TOKEN,DATA,LENGTHA,RETCODE,
,RSNCODE,CCSID)
if rc1 = 0 then do
say 'send completed successfully'
end
/*PREP AND CALL THE TERM ROUTINE */
NUMPARM = 4
REQUEST = 'TERM'
RETCODE = 0
RSNCODE = 0
RC1 = CALL_TERM(NUMPARM,REQUEST,TOKEN,RETCODE,RSNCODE)
if rc1 = 0 then do
say 'term completed successfully'
end
EXIT
/* INIT ROUTINE */
CALL_INIT:
CLASS = d2c(arg(3),1)
TYPE = d2c(arg(4),1)
SUBTYPE = d2c(arg(5),1)
ADDRESS LINKPGM 'SSDFPAPI NUMPARM REQUEST CLASS TYPE SUBTYPE

TOKEN RETCODE RSNCODE'

SAY 'ERROR AT INIT, RETURN CODE' RETCODD ', REASON CODE ' RSNCODD
exit RETCODD
end
RETURN RETCODD
/* SEND ROUTINE */
CALL_SEND:
LENGTHA = d2c(arg(5),4)
CCSID = d2c(arg(8),4)
ADDRESS LINKPGM 'SSDFPAPI NUMPARM REQUEST TOKEN DATA LENGTHA

RETCODE RSNCODE CCSID'

SAY 'ERROR AT SEND, RETURN CODE' RETCODD ', REASON CODE ' RSNCODD

exit RETCODD
end
RETURN RETCODD
/* TERM ROUTINE */
CALL_TERM:
RETCODE = d2c(ARG(4),4)
RSNCODE = d2c(ARG(5),4)
ADDRESS LINKPGM 'SSDFPAPI NUMPARM REQUEST TOKEN RETCODE

RSNCODE'

SAY 'ERROR AT TERM, RETURN CODE' RETCODD ', REASON CODE ' RSNCODD
exit RETCODD
end
RETURN RETCODD


Chapter 19 Setting Up Log4j
This chapter describes how to configure log4j configuration files to collect log4j records.
Topics:
• “Overview of Log4j” on page 19-1
• “Defining the Log4j Parameters” on page 19-2
• “Sample Log4j Configurations” on page 19-2
• “How to use PATTERN in the Log4j Reader Facility” on page 19-4
Overview of Log4j
On OMVS, you must change your log4j configuration file (log4j.xml or log4j.properties,
log4j2.xml or other files defined in log4j.configurationFile) to collect log4j log records and
send them to a destination.
The SDFAppender is used to collect Log4j 1.x log records on OMVS and send these records to
Ironstream through a namedpipe. The SDF2Appender is used to collect Log4j 2.x records.
The namedpipe must be unique for each Ironstream instance on your system. The
SDFAppender.class and SDF2Appender.class are included in the jar file in
your_directory/sdf, where your_directory is the zFS root name that you specified in
Panel 6-1, “Initial Configuration,” on page 6-11.
The SDFAppender and SDF2Appender both support all log4j pattern layouts and filters.
Since they append date/time information automatically, you don’t need to add date/time in
the pattern layout.
Note that the Websphere Application Server allows you to configure the log4j logging utility
on the server level or application level. You must configure the log4j components together
with Ironstream’s log4j appender at the application level.

Setting Up Log4j
Defining the Log4j Parameters

Both the SDFAppender and SDF2Appender accept parameters. The "namedpipe" parameter
is required by the appenders. This value assigned to this parameter must be exactly the
same as the NAMEDPIPE parameter in the configuration file.
Note: User applications that use “namedpipe” can send up to 64K bytes per record.
• timezone – An optional parameter that can be used to specify a time zone other than
the system default.
• jzos – An optional parameter that defaults to "yes". If your system is not jzos ready set
this parameter to "no".
• dateformat – An optional parameter that can be set to "zos" to cause the datetime for
log4j records forwarded to a destination to have the default z/OS datetime format (the
same as for SMF and syslog).
• datatype – An optional parameter that can be set to “original” to send original log4j
data to a destination. Otherwise, Ironstream JSON format will be sent to a destination.
Sample Log4j Configurations

This section contains samples of log4j configuration files.
SDFAppender Sample in log4j.xml

Following is a sample for using the SDFAppender in log4j.xml:
<?xml version="1.0"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration debug="true"
xmlns:log4j='http://jakarta.apache.org/log4j/'>
<appender name="myzlAppender" class="com.syncsort.ironstream.SDFAppender" >
<param name="namedpipe" value="/tmp/.mfxsplunk"/>
<param name="timezone" value="EST5DST"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value=" %t %-5p %c{1} %x - %m%n"/>
</layout>
</appender>
<root>
<level value="TRACE"/>
<appender-ref ref="myzlAppender"/>
</root>
</log4j:configuration>

Setting Up Log4j
SDFAppender Sample in log4j.properties

Following is a sample for using the SDFAppender in log4j.properties:
# Root logger option
log4j.rootLogger=INFO, file, stdout, REMOTE
# For Ironstream
log4j.appender.REMOTE=com.syncsort.ironstream.SDFAppender
log4j.appender.REMOTE.namedpipe=/tmp/.mfxsplunk
log4j.appender.REMOTE.timezone=EST5DST
log4j.appender.REMOTE.layout=org.apache.log4j.PatternLayout
log4j.appender.REMOTE.layout.ConversionPattern=%t %-5p %c{1} %x - %m%n
Note: You have to start Ironstream before you run your application and collect log4j log data
otherwise your data may be discarded.
SDF2Appender Samples for Log4j 2.x

Following is a sample for using the SDF2Appender in log4j2.xml:
<?xml version="1.0"?>
<Configuration status="WARN" packages="com.syncsort.ironstream">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %t %-5level %logger{36} - %msg%n"/>
</Console>
<SDF2 name="MyFile" namedpipe="/u/wwczxl/.mfxsplunk" timezone="GMT">
<PatternLayout>
<Pattern>%p %c{1.} %t %m%n</Pattern>
</PatternLayout>
</SDF2>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="MyFile"/>
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration>

Setting Up Log4j
How to use PATTERN in the Log4j Reader Facility

PATTERN is an optional parameter for the Offline Log4j Reader Facility. It is required only
when the first field of the log record is not a date/time field.
The PATTERN parameter is specified in the SOURCE section of the configuration file the
LOG4J data type, as described in “LOG4J Subparameters” on page 7-24. When PATTERN is
specified, the TIMESTAMP parameter must also be specified even if date/time is in the
default log4j format.
Apache’s org.apache.log4j.receivers.varia.LogFilePatternReceiver is used to parse
log files, converting log records to the format that Ironstream needs.
The PATTERN parameter is constructed by keywords from the following list:
TIMESTAMP
LOGGER
LEVEL
THREAD
CLASS
FILE
LINE
METHOD
RELATIVETIME
MESSAGE
NDC
PROP(key)
Example:
If your log4j log file’s pattern layout is this:
%-5p %d [%t] %C{2} (%F:%L) - %m%n
specify the following as the PATTERN parameter:
LEVEL TIMESTAMP [THREAD] CLASS (FILE:LINE) - MESSAGE
Important! Do not use the PATTERN parameter when the first field of your log records is a
date/time field.

Chapter 20 IMS Log Record Forwarding
This chapter describes how to configure Ironstream to gather IMS log records, either
synchronously or asynchronously. It also lists and describes the IMS log record fields
supported in this release of Ironstream.
Topics:
• “Overview of IMS Log Record Forwarding” on page 20-2
• “Synchronous IMS Log Gathering” on page 20-3
• “Asynchronous IMS Log Gathering” on page 20-4
• “IMS Log Record Extraction Process” on page 20-5
• “IMS Log Record Processing” on page 20-7
• “IMS Log Record Field Descriptions” on page 20-8
• “Messages Issued by IMS Log Records” on page 20-85

IMS Log Record Forwarding
Overview of IMS Log Record Forwarding

Ironstream can be configured to deliver IMS log data to analytics platforms, such as Splunk
or Elastic, providing insight into IMS transaction performance and IMS system statistics.
The initial release of IMS log forwarding support in Ironstream includes the following
functionality:
• Synchronous log record capture – For online regions using the “log write” exit point.
• Asynchronous log record capture – For online regions using a separate step in the
Archive JCL.
• Certain log records only – Those relating to transaction performance and IMS system
statistics.
• IMS version 14 and higher.
Excluded Functionality
Specific functionality excluded from this release of IMS support in Ironstream is:
• Command capture
• Capture from DLI jobs
• Capture from ancillary IMS address spaces (IMS Connect, Common Queue Server)
• Ironstream’s Data Loss Prevention (DLP) function
Synchronous versus Asynchronous IMS Log Record Capture

The two IMS log capture methods are alternatives: Synchronous log record gathering
provides the information in real-time, but at the cost of a small reduction in the response
time of IMS online users.
Panel 20-1: Synchronous IMS Log Capture

Whereas asynchronous log record gathering provides the information when the IMS logs
switch without impact to the IMS online service.
Panel 20-2: Asynchronous IMS Log Capture

Both methods use an intermediate data space to hold log data while it is being processed,
which means that unless the data space fills, the gatherer is not affected by delays in the
extractor.
Synchronous IMS Log Gathering

IMS calls the “log write” exit after a block of data has been written to the IMS online log data
set. The exit gathers the entire block of data. Record selection from within that block occurs
later (during extraction). The exit knows whether Ironstream is active using the name-token
pair mechanism already in use within Ironstream. If Ironstream is not active, the exit takes
no action.
If you need to ensure that all log records are processed (perhaps you have an integrity or
completeness requirement), it is possible to gather the missing log records using
asynchronous log gathering (and specifying a range of log records), as described in
“Asynchronous IMS Log Gathering” on page 20-4.
Activating the log write Exit

You activate the “log write” exit by:
• Adding the SSDFISLG module to the IMS Control region STEPLIB.
• Adding EXITDEF=(TYPE=LOGWRT,EXITS=(SSDFISLG)) to <SECTION=USER_EXITS> in
PROCLIB member DFSDFxxx.
• Issuing the REFRESH USEREXIT command (or stopping and starting IMS).
Look for message SDF1200I in the Control Region JES message log to indicate that the exit
is active.
In the synchronous case, most of the Ironstream process runs in a separate forwarder
address space. There is one such address space per IMS control region. To prevent losing log

records, you should start this address space before starting IMS.
Forwarder Task JCL

The JCL for the forwarder is similar to other Ironstream tasks:
//IMSASSDF EXEC PGM=SSDFMAIN
//SSDFCONF DD DISP=SHR,DSN=yourhlq_parmlib(CFGIMSS) see below
//CEEOPTS DD DISP=SHR,DSN=yourhlq_parmlib(CEEOPTS)
SSDFCONF keywords for the extractor are as follows:
[KEYS]
…
[SYSTEM]
"NAME":"name"
…
[DESTINATION]
…
[SOURCE]
"DATATYPE":"IMSLOG"
"IMS_SYSTEM_ID":"<ims-id>"
"CATEGORY":"MTOMSG,SYSSTAT,TRANSTAT,TRANDET"
• Use a different value for the Ironstream [SYSTEM] "NAME" than the one being used for
<ims-id>.
• IMS_SYSTEM_ID must contain the <ims-id>, which is the value used to populate the
"IMSID" JSON pair.
See the “IMS Log Record Extraction Process” on page 20-5 for details about the available
categories.
Asynchronous IMS Log Gathering

The asynchronous log gatherer processes the IMS Archive file (SLDS in IMS-speak)
produced by a previous job step. In this case, the entire Ironstream process runs as a step
within the IMS archive job. Assuming you use the IMS standard SLDS name and DBRC
symbolic variables, you should add a step like this:
// IF RC = 0 THEN
//IMSASSDF EXEC PGM=SSDFMAIN
//CEEOPTS DD DISP=SHR,DSN=yourhlq_parmlib(CEEOPTS)
//SYSUT1 DD DISP=SHR,
// DSN=IMS.SLDSP.%SSID.D%ARDATE.T%ARTIME.V%ARVERS
//SSDFCONF DD *
[KEYS]
…
[SYSTEM]
"NAME":"name"

"IMPORT":"IMSLOG"
"SEQUENCE_START":"hhhhhhhhhhhhhhhh"
"SEQUENCE_END":"hhhhhhhhhhhhhhhh"
…
[DESTINATION]
…
[SOURCE]
"DATATYPE":"IMSLOG"
"IMS_SYSTEM_ID":"%SSID"
"CATEGORY":"MTOMSG,SYSSTAT,TRANSTAT,TRANDET"
// ENDIF
• Use a different value for the Ironstream [SYSTEM] "NAME" than the one being used for
<ims-id>.
• IMS_SYSTEM_ID must contain the <ims-id>, which is the value used to populate the
"IMSID" JSON pair.
Log sequence numbers are optional (they default to the start and end of the current file)
because they are intended for exceptional use (when data has gone missing). If you specify a
log sequence number, it must be 16 hexadecimal characters with leading zeros (this is how
they appear in Ironstream messages).
See the “IMS Log Record Extraction Process” on page 20-5 for details about the available
categories.
IMS Log Record Extraction Process

The extraction process handles the following IMS log record types (all are hex).
• 01 – Input message (from an external source)
• 03 – Output message (from a program)
• 06 – IMS start/stop
• 07 – Application end
• 08 – Application start
• 0A – CPI-driven program start/end
• 31 – GU message (start of a new transaction)
• 32 – Message rejected
• 33 – DRRN released
• 34 – Message cancelled
• 35 – Message enqueued
• 38 – Message re-queue after Abend
• 45 – System statistics (includes logger and database buffer pool statistics)
• 56 – External subsystems (typically DB2 or MQ)
• F9 – Program record from BMC’s Mainview
• FA – Transaction record from BMC’s Mainview

Using the Category Keyword

You can select the level of data you want to gather by using the CATEGORY keyword in
SSDFCONF.
The supported categories are:
• MTOMSG collects only 01 and 03 records for DFSMTCNT
• SYSSTAT collects some subtypes of the 45 record
• TRANDET collects:
▪ 01 and 03 records except those for DFSMTCNT
▪ 06, 07, 08, and 0A records
▪ 32, 33, 34, and 38 records
▪ 56 records
• TRANSTAT is a subset of TRANDET and collects:
▪ 06, 07, 08, and 0A records
▪ 32, 33, 34, and 38 records
• MVF9DET collects F9 records created by BMC’s Mainview.
• MVF9STAT collects a subset of fields from F9 records created by BMC’s Mainview.
• MVF9SUMM collects a small subset of fields from F9 records created by BMC’s
Mainview.
• MVFADET collects FA records created by BMC’s Mainview.
• MVFASTAT collects a subset of fields from FA records created by BMC’s Mainview.
• MVFASUMM collects a small subset of fields from FA records created by BMC’s
Mainview.
• MVDET collects F9 and FA records created by BMC’s Mainview.
• MVSTAT collects a subset of fields from F9 and FA records created by BMC’s Mainview.
• MVSUMM collects a small subset of fields from F9 and FA records created by BMC’s
Mainview.

IMS Log Record Processing

Most fields in the selected IMS log records can be formatted to JSON pairs before forwarding
to a destination. Principal exceptions are:
• Fields that have no value (blank for character, zero for numeric or hex fields).
• Control fields, such as subrecords, lengths, and identifiers.
• The contents of the input or output message itself are not formatted. This is because the
data:
▪ Generally is in an application-defined format
▪ May contain confidential business information
▪ Isn’t needed for performance analysis
Most fields have the names from their respective macros. Principal exceptions are fields
from disparate records that are needed in an analytics platform for correlation, such as:
• Log record sequence number is called LOGRC_SEQ.
• Log record timestamp is called LOGRC_STCK and is reported as UTC.
• A truncated timestamp called DATETIME is reported with an offset from UTC,
consistent with other Ironstream-created records.
• Recovery token is called RTKN.
• The PCB address used to correlate 3x records is called PCBA.
• The originating IMS system ID and token used to correlate 01/03 and 3x records are
called ORID and ORTK respectively.
• The processing IMS system ID and token used to correlate 01/03 and 3x records are
called PRID and PRTK respectively.
• The CQS flags used to correlate 01/03 and 3x records are called UFLG1 and UFLG2.

IMS Log Record Field Descriptions

This section lists all the supported IMS log record fields, including each field’s format and
brief description.
• “Log Records 01 – (Input Message) and 03 (Output Message)” on page 20-9
• “Log Record 06 – IMS Stop/Start” on page 20-22
• “Log record 07 – Application End” on page 20-23
• “Log record 08 – Application Start” on page 20-27
• “Log Record 0A – CPIC Application Start/End” on page 20-29
• “Log Record 31 – Message GU Call” on page 20-31
• “Log Record 32 – Message Rejected” on page 20-33
• “Log Record 33 – Message Freed” on page 20-34
• “Log Record 34 - Message Cancelled” on page 20-35
• “Log Record 35 – Message Enqueued” on page 20-36
• “Log Record 38 – Message Re-queued after an Abend” on page 20-39
• “Log Record 45 – System Statistics” on page 20-41
• “Log Record 56 – Unit-of-Recovery” on page 20-62
• “Log Record F9 – User Record” on page 20-72
• “Log Record FA – User Record” on page 20-75

Log Records 01 – (Input Message) and 03 (Output Message)

Notice that 01 and 03 records for the Master Terminal Operator are suppressed unless you
specify category MTOMSG. If 01 and 03 records are formatted only because you have
specified MTOMSG (and not another category that also processes 01 and 03 records), only 01
and 03 records for the Mater Terminal Operator will be formatted. Some fields are only
formatted when a particular category is selected and these are noted in the description.
Field name Format Description

MFSOURCETYPE IMS01 or IMS03 IMS ID
IMSID up to 8 characters IMS ID
SYSNAME 4 characters z/OS system where extracted
MSGFLAGS 2 hex characters Flags (TRANDET only)
MSGDFLG2 2 hex characters Flags (TRANDET only)
MSGFPADL 2 hex characters Flags (TRANDET only)
MSGPRFLL - Prefix length
MSGCSW 2 hex characters Communication switches (TRANDET only)
MSGMDRRN 8 hex characters Message DRRN
MSGRDRRN 8 hex characters Record DRRN
ORID 8 characters originating system (from MSGORGID)
ORTK YYYY-MM-DD originating token (from MSGORGTK)
HH:MM:SS.uuuuuu
PRID 8 characters processing system
PRTK YYYY-MM-DD processing token
HH:MM:SS.uuuuuu
UFLG1 2 hex characters Unit of work flags
UFLG2 2 hex characters Unit of work flags
MSGRSQTY 2 hex characters Queue type for restart (TRANDET only)
MSGDOFS 4 hex characters Prior record offset within block (TRANDET
only)
MSGDRBN 8 hex characters Prior record RBN on disk log (TRANDET
only)
DATETIME YYYY-MM-DD Log record timestamp to 1/100th of a second,
HH:MM:SS.xx+hhmm in UTC with offset to local time

LOGRC_STCK YYYY-MM-DD Log record timestamp in UTC

HH:MM:SS.uuuuuu
LOGRC_SEQ decimal Log record sequence number

System Segment

MSGCFLG1 - Flags
MSGCFLG2 - Flags
MSGCFLG3 - Flags
MSGCQSF1 - CQS flags
MSGCQSF2 - CQS flags
MSGILINE decimal BTAM line number
MSGITERM decimal BTAM terminal
MSGINODE 8 characters VTAM terminal
MSGTISEQ decimal Sequence number from line / terminal (TRANDET
only)
MSGPREFI decimal Output sequence number for this transaction
MSGPREFO decimal Number of program switches so far
MSGSETS 2 hex characters SETS/ROLS level number (TRANSET only)
MSGRECCT - Count of objects in this record
MSGIDSTN 8 characters Input CNT
MSGODSTN 8 characters Destination CNT or SMB
MSGOD62I - APPC (LU6.2) destination type QAB/TIB
MSGOD62A - APPC (LU6.2) destination address QAB/TIB
MSGIHSQN 8 characters Sub pool
MSGFMTNM 8 characters MFS format name
LU 6.1 Segment

MSGRDPNS - Length of following item
MSGRDPN up to 8 characters Return Destination Procedure Name
MSGRPRNS - Length of following item
MSGRPRN up to 8 characters Return Primary Resource Name

Extended Prefix Header

MSGEPFL1 - flag byte
MSGEPFL2 - flag byte
Security Segment

MSGRACUS 8 characters userid
MSGSAFNM 8 characters group name
MSGUSIDI 1 character Indicates source of userid
Workload Manager Segment

This segment is formatted only for TRANDET

MSGEWLMD - flag
MSGWLMSC 8 hex characters WLM service classification token
MSGMGATM YYYY-MM-DD Message arrival timestamp
HH:MM:SS.uuuuuu
MSGWLMTT 16 hex characters WLM transaction trace token
MSGEWTKN 24 hex characters WLM C2 Correlator
System Extension Segment

This segment is formatted only for TRANDET

MSGUTC YYYY-MM-DD Timestamp of original message with offset from
HH:MM:SS.uuuuuu UTC
+hhmm
MSGCFLG4 2 hex characters Flags

Multi-system Segment

MSGMSFL5 2 hex characters Flags (TRANDET only)
MSGESINM 8 characters source
MSGESONM 8 characters destination
MSGDSSID 2 hex characters destination system (SID)
MSGSRSID 2 hex characters originating system (SID)
MSGMORID 8 characters originating IMS
MSGMMOTK YYYY-MM-DD originating token
HH:MM:SS.uuuuuu
MSGCPRID 8 characters Processing IMS (when segment built) TRANDET
only
MSGCPRTK YYYY-MM-DD Processing token (when segment built) TRANDET
HH:MM:SS.uuuuuu only
Conversation Extension Segment

MSGSPALN decimal Current SPA length (TRANDET only)
MSGSPABL decimal Current SPA buffer length (high water mark)
TRANDET only
MSGSCCBI 4 hex characters CCB ID for this SPA (TRANDET only)
RTKN IMSID + OASN + Recovery token (from field MSGMRTKN)
commit count
MSGMRID decimal Region ID
MSGCSMBN 8 characters Transaction code
MSGCFLAG 2 hex characters Flags (TRANDET only)
MSGCOFL2 2 hex characters Flags (TRANDET only)

User Prefix Segment

This is not formatted.
Internal User Prefix Segment

This is not formatted.
Transaction Manager Routing Segment

MSGMSTRA 8 hex characters trace (TRANDET only)
MSGMVID 16 hex characters trace (TRANDET only)
MSGMSONM 8 characters Destination
MSGMSINM 8 characters Source LTERM
MSGMSOID 2 hex characters destination system (SID)
MSGMSIID 2 hex characters originating system (SID)
MSGMSUID 8 characters userid
MSGMSGID decimal Error message number if message cancelled
(TRANDET only)
MSGMSGIDU boolean True if a user message, false if a system message
(TRANDET only)
MSGMSPAD - Filler
MSGMSCTS YYYY-MM-DD Enqueue timestamp (TRANDET only)
HH:MM:SS.uuuuuu
MSGIMSR 2 hex characters IMS version (TRANDET only)
MSGIMSL 2 hex characters IMS release (TRANDET only)
MSGTODTK 32 hex characters Token for subsequent records (TRANDET only)
MSGLKTKN 16 characters CQSREAD lock token (TRANDET only)
MSGTFL1 2 hex characters routing exit flags (TRANDET only)
MSGTRFL2 2 hex characters terminal routing exit flags (TRANDET only)
MSGTRFL3 2 hex characters terminal routing exit flags (TRANDET only)
MSGLRFL2 2 hex characters link receive exit flags (TRANDET only)

MSGLRFL3 2 hex characters link receive exit flags (TRANDET only)

MSGPRFL2 2 hex characters program routing exit flags (TRANDET only)
MSGPRFL3 2 hex characters program routing exit flags (TRANDET only)
MSGERRSN 8 hex characters error message and reason (TRANDET only)
MSGHIMSR 2 hex characters high water IMS version (TRANDET only)
MSGHIMSL 2 hex characters high water IMS release (TRANDET only)
MSGTMFL1 - flag byte
MSGOMNAM 8 characters Operations Manager name (TRANDET only)
MSGLLCNT decimal Long lock message count

APPC Segment
Notice that the “APPC segment” may alternatively contain OTMA information.

Fields Common to APPC and OTMA
CONVERSATION_TYPE 1 character
SYNC_LEVEL 1 character
MSG_TYPE 2 hex characters Flags (TRANDET only)
MSG_FLAG 2 hex characters Flags (TRANDET only)
RACF_OPT 1 character RACF option from profile
APPC Fields
LUP_USER_ID_IND 1 character Indicates source of userid
LUP_INCLUDE_FLAG 2 hex characters Flags (TRANDET only)
LUP_NETWORK_ID 8 characters destination network
LUP_LUNAME 8 characters destination LU
LUP_MODENAME 8 characters mode table
LUP_SIDENAME 8 characters destination side info
LUP_FE_XCF_NAME 4 characters XCF member name
LUP_FE_TIB_PTR - Front end TIB address (not formatted)
LUP_LUMBLK_TOKEN - TIB/QAB address (not formatted)
LUP_USER_ID 8 characters userid
LUP_GROUP_NAME 8 characters group name
LUP_TP_ID 16 hex characters Transaction program instance

(TRANDET only)
LUP_TRANCODE 8 characters transaction
LUP_LTERM 8 characters LTERM
LUP_TOKEN 16 hex characters APPC prefix token (TRANDET only)
LUP_FLAGS 8 hex characters Flags (TRANDET only)
LUP_LUWID up to 25 characters LUW id
LUP_TPNAME up to 64 characters Transaction program name
LUP_UTOKEN Up to 160 hex Security user token (TRANDET only)

characters
LUP_CTOKEN 16 characters Context token


LUP_FRONTEND_SMQN 8 characters Front end SMQ name
M
LUP_ASYNC_TOKEN 16 hex characters (TRANDET only)
LUP_SYNC_TOKEN 16 hex characters (TRANDET only)
LUP_UR_TOKEN 32 hex characters Unit of recovery token (RRS)

(TRANDET only)
LUP_LOCALLU 8 characters Local LU
OTMA Fields
LUY_LTERM 8 characters transaction
LUY_TRANCODE 8 characters LTERM
LUY_TOKEN 16 hex characters

LUY_FLAGS 8 hex characters Flags (TRANDET only)
LUP_LUMBLK_TOKEN - TIB/QAB address
LUY_MEMBER_NAME 16 characters XCF member name
LUY_FRONTEND_SMQN 8 characters Front end SMQ name

M
LUY_ASYNC_TOKEN 16 hex characters Front end YQAB token (TRANDET
only)
LUY_IMSR 2 hex characters IMS version (TRANDET only)
LUY_IMSL 2 hex characters IMS release (TRANDET only)
LUY_FIXPRE_LEN - Length of fixed prefix
LUY_SYNC_TOKEN 16 hex characters Front end YTIB token (TRANDET

only)
LUY_UR_TOKEN 32 hex characters Front end unit of recovery token
(TRANDET only)
LUY_FE_TIB_PTR - Front end TIB pointer
LUY_FIRST_QAB_TOKEN 16 hex characters First QAB token (TRANDET only)
LUY_FE_XCF_NAME 4 characters Front end XCF name (TRANDET

only)
LUY_BE_ALTPCB_MN 16 characters Shared queues back end Alternate
PCB member
LUY_SUPER_MN 4 characters Super member name
LUY_MSG_ARRIVAL_TIM YYYY-MM-DD OTMA message arrival time

E HH:MM:SS.uuuuuu (TRANDET only)
LUY_SMBEXPTM decimal Front end transaction expiry time
(TRANDET only)


LUY_BE_ALTPCB_TPIPE 8 characters Shared queues back end Alternate
PCB TPIPE
LUY_MSG_FLAG3 2 hex characters flags (TRANDET only)
LUY_MSG_FLAG4 2 hex characters flags (TRANDET only)
OTMA Request Control

TMAMCALV 2 hex characters Architecture level (TRANDET only)
TMAMCMGT 2 hex characters Message type (TRANDET only)
TMAMCRSI 2 hex characters Response indicator (TRANDET only)
TMAMCCCI 2 hex characters Commit confirmation indicator

(TRANDET only)
TMAMCTYP 2 hex characters Command Type (TRANDET only)
TMAMCPFG 2 hex characters Processing flag (TRANDET only)
TMAMCTNM 8 characters Transaction pipe name
TMAMCCHN 2 hex characters Chain State Flag (TRANDET only)
TMAMCPFL 2 hex characters Prefix flag (TRANDET only)
TMAMCSSN decimal send sequence number
TMAMCSNC decimal sense code
TMAMCRSC decimal reason code
TMAMCRSQ decimal Recoverable Msg Sequence Number

(TRANDET only)
TMAMCSEQ decimal Segment Sequence Number
(TRANDET only)
TMAMCTO1 decimal Time-out for missing ACK for CM1
(TRANDET only)
TMAMCTDN decimal Number of control data segments
(TRANDET only)
OTMA Request Header
TMAMHIST 2 hex characters IMS State Flag (TRANDET only)
TMAMHSYN 2 hex characters Synchronization Flag (TRANDET

only)
TMAMHSLV decimal Synchronization level
TMAMHCFL 2 hex characters Client Flags (TRANDET only)
TMAMHMAP 8 characters Map name
TMAMHCOR 32 hex characters correlator
TMAMHLTM 8 characters Override LTERM name


TMAMRTMO decimal Time-out for IMS Connect to IMS
Connect (TRANDET only)
OTMA Request Security
TMAMSLEN - Length of security data
TMAMSFLG 1 character Security type
TMAMSFLN - Reserved field
TMAMSPRF Up to 160 hex User token (TRANDET only)

characters
TMAMSUID Up to 8 characters Userid
TMAMSGRP Up to 8 characters User group
TMAMSWID Up to 246 characters Network user id (IMS 15 and later)

TMAMSSID Up to 508 hex Network session id (IMS 15 and later)
characters
OTMA “User” Data – IMS Connect (formatted for TRANDET only)

TMAMULEX - Length of user data
TMAMDUMY - General user data
TMAMUORG 8 characters TPIPE name
TMAMPORT 8 characters Port id
TMAMLTKN 16 hex characters IMS Connect logon token
TMAMDUM2 - General user data
TMAMUFL3 2 hex characters flags
TMAMUARC 2 hex characters Architecture level
TMAMRRNM 8 characters reroute TPIPE name
TMAMUADT 8 characters XML adapter name
TMAMUDRV 8 characters driver name
TMAMLIMS 8 characters local IMSID
TMAMRIMS 8 characters remote IMSID
TMAMRICO 8 characters remote IMS Connect
TMAMRTRN 8 characters remote transaction
TMAMUSRD 8 characters USERID for transaction authorization


OTMA “User” Data – MQ Message Descriptor
MQMD_STRUCID - “MQMD”
MQMD_VERSION decimal Structure version (TRANDET only)
MQMD_REPORT 16 hex characters Options for report messages

(TRANDET only)
MQMD_MSGTYPE decimal Message type (TRANDET only)
MQMD_EXPIRY decimal Message lifetime (TRANDET only)
MQMD_FEEDBACK decimal Feedback or reason code (TRANDET

only)
MQMD_ENCODING decimal Numeric encoding of message data
(TRANDET only)
MQMD_CODEDCHARSET decimal Character set identifier of message
ID (TRANDET only)
MQMD_FORMAT 8 characters Format name of message data
MQMD_PRIORITY decimal Message priority (TRANDET only)
MQMD_PERSISTENCE decimal Message persistence (TRANDET

only)
MQMD_MSGID 48 hex characters or Message identifier
CSQ + QMGR name
+ timestamp
MQMD_CORRELID 48 hex characters or Correlation identifier
CSQ + QMGR name
+ timestamp
MQMD_BACKOUTCOUN decimal Backout counter (TRANDET only)
T
MQMD_REPLYTOQ 48 characters Reply-to queue
MQMD_REPLYTOQMGR 48 characters Reply-to queue manager
MQMD_USERIDENTIFIE 12 characters UserID

R
MQMD_ACCOUNTINGTO 64 hex characters Accounting token
KEN
MQMD_APPLIDENTITYD 32 characters Application-provided data
ATA
MQMD_PUTAPPLTYPE decimal Type of application that created this
message
MQMD_PUTAPPLNAME 28 characters Name of application that created
this message
MQMD_PUTDATE YYYY-MM-DD Date message was created


MQMD_PUTTIME HH:MM:SS.HH Time message was created
MQMD_APPLORIGINDAT 4 characters Application-provided data

A
MQMD_GROUPID 24 characters Group identifier
MQMD_MSGSEQNUMBE decimal Sequence number of logical message

R within group
MQMD_OFFSET decimal Offset of data in physical message
from start of logical message
(TRANDET only)
MQMD_MSGFLAGS 8 hex characters Message flags
MQMD_ORIGINALLENG decimal Length of original message

TH (TRANDET only)
Data Segment

SEG_COUNT decimal Number of data segments in this record
SEG_DATA Array of Content of the segments. Notice that printer control
character fields characters are converted to blanks.
MTOMSG only, if the message is for DFSMTCNT

Log Record 06 – IMS Stop/Start

MFSOURCETYPE IMS06 IMS ID
ACIMSID 4 characters IMS ID
ACIDENT 2 hex characters Reason for record creation
HH:MM:SS.uuuuuu

Log record 07 – Application End

MFSOURCETYPE IMS07
DLRNPSB 8 characters PSB
DLRTRNCD 8 characters transaction code
DLRPRTY decimal transaction priority (TRANDET only)
DLRTYPE 2 hex characters program type (TRANDET only)
DLRTIME decimal elapsed (timer units)
DLREXTIM HH:MM:SS.uuuuuu CPU time
DLRAZAAP HH:MM:SS.uuuuuu zAAP time
DLRCOMP Sxxx or Unnnn Completion code
DLRNJOB 8 characters job name
DLRNSTP 8 characters step name
DLRMCNT decimal Number of messages dequeued
DLRGU1 decimal Number of DB GU calls
DLRGN decimal Number of DB GN calls
DLRGNP decimal Number of GNP calls
DLRGHU decimal Number of GHU calls
DLRGHN decimal Number of GHN calls
DLRGHNP decimal Number of GHNP calls
DLRISRT decimal Number of DB ISRT calls
DLRDLET decimal Number of DLET calls
DLRREPL decimal Number of REPL calls
DLRCLCNT decimal total number of DB calls
DLRGUMES decimal message GU calls
DLRGNMES decimal message GN calls
DLRISMES decimal message ISRT calls
DLRPUMES decimal message PURG calls
DLRTSTNQ decimal number of test enqueues
DLRTSTWT decimal number of waits for test enqueue

DLRTSTDQ decimal number of test dequeues

DLRQCONQ decimal number of command enqueues
DLRQCOWT decimal number of waits for command enqueue
DLRQCODQ decimal number of command dequeues
DLRSUPNQ decimal number of update enqueues
DLRSUPWT decimal number of waits for update enqueue
DLRSUPDQ decimal number of update dequeues
DLREXCNQ decimal number of exclusive enqueues
DLREXCWT decimal number of waits for exclusive enqueue
DLREXCDQ decimal number of exclusive dequeues
DLRCMD decimal number of CMD calls
DLRGCMD decimal number of GCMD calls
DLRCHNG decimal number of CHNG calls
DLRAUTH decimal number of AUTH calls
DLRSETO decimal number of SETO calls
DLRAPSB decimal number of APSB calls
DLRDPSB decimal number of DPSB calls
DLRGMSG decimal number of GMSG calls
DLRICMD decimal number of ICMD calls
DLRRCMD decimal number of RCMD calls
DLRCHKP decimal number of CHKP calls
DLRXRST decimal number of XRST calls
DLRROLB decimal number of ROLB calls
DLRROLS decimal number of ROLS calls
DLRSETS decimal number of SETS calls
DLRSETU decimal number of SETU calls
DLRINIT decimal number of INIT calls
DLRINQY decimal number of INQY calls
DLRSLOG decimal number of LOG calls
DLRDEQ decimal number of DEQ calls
DLRVSAMR decimal number of VSAM reads

DLRVSAMW decimal number of VSAM writes

DLROSAMR decimal number of OSAM reads
DLROSAMW decimal number of OSAM writes
DLRTOTIO decimal total VSAM and OSAM I/O
DLRESAF decimal number of External subsystem calls
DLRFLD decimal number of FLD calls
DLRPOS decimal number of POS calls
DLRRLSE decimal number of RLSE calls
DLRXSAVE decimal number of XQUERY save
DLRXRSTR decimal number of XQUERY restore
DLRXCOPY decimal number of XQUERY copy
DLRICAL decimal number of ICAL calls
DLRDGUR decimal number of GUR calls
DLRDIR decimal number of IR calls
DLRDMR decimal number of MR calls
DLRUSID 8 characters user of last message
DLRNWID 8 characters network ID of last message
DLRFLAG2 2 hex characters Flags (TRANDET only)
PST decimal region number (from DLRPSTNR)
RTKN IMSID + OASN + Recovery token (from field DLRTOKN)
commit count
or jobname +
timestamp (for
DBCTL)
DLRNPGM 8 characters program name
DLRCPUID 16 hex characters CPU ID
DLRABRSN 8 hex characters ABEND reason code
DLRUSSN 8 hex characters Unique schedule sequence number for
DBCTL
DLRTMEIO decimal database IO elapsed time (µs)
DLRTMEPL decimal locking elapsed time (µs)

DLRIOCNT decimal Total number of DB IOs (DBCTL)

DLRSQ6TM decimal Time on sub queue 6 (wait for input) per
message
DLRACCQ6 decimal Total time on sub queue 6 (wait for input)
DLRUTC YYYY-MM-DD Timestamp with offset from UTC
HH:MM:SS.uuuuuu+h (TRANDET only)
hmm
HH:MM:SS.uuuuuu

Log record 08 – Application Start

LINTSUB 2 hex characters Record subtype (TRANDET only)
LINTSY1 8 characters PSB name or transaction code
LINTSY2 8 characters Transaction code or database name or
16 hex characters jobname
or Region classes
LINTCLAS decimal Transaction class (TRANDET only)
LINTPRTY decimal Transaction Priority (TRANDET only)
LINTSUB2 2 hex characters Additional subtype (TRANDET only)
LINTPGM 8 characters Program name
LINTPSB 8 characters PSB name
LINTTYPR 2 hex characters Region type
PST decimal Region number (from LINTPSTN)
RTKN IMSID + OASN + Recovery token (from field LINTOKN)
commit count
or jobname +
timestamp (for
DBCTL)
LINTTSKI 8 hex characters FSE task id (TRANDET only)
LINTCODE 2 hex characters Application program flags (TRANDET only)
LINTFLG1 2 hex characters Flags (TRANDET only)
LINTMINT decimal Wait time for intent (µs)
LINTMPOL decimal Wait time for pool space or command (µs)
LINTMSCH decimal Wait time for scheduling (µs)
LINTUTKN 32 hex characters User token (TRANDET only)
LINTUTC YYYY-MM-DD timestamp with offset from UTC (TRANDET
HH:MM:SS.uuuuuu+ only)
hhmm
LINTCTSK 16 hex characters CCTL task id (TRANDET only)


HH:MM:SS.uuuuuu

Log Record 0A – CPIC Application Start/End

MFSOURCETYPE IMS0A IMS ID
L0ASUB 2 hex characters Sub type: “07” for end or “08” for start
PST decimal region number (from L0APSTNR)
L0ATPI 16 hex characters Transaction program instance (TRANDET
only)
L0ACONID 8 characters conversation ID
L0ATRNCD 8 characters transaction code
RTKN IMSID + OASN + Recovery token (from field L0ATOKN)
commit count
L0AUTC YYYY-MM-DD timestamp with offset from UTC (TRANDET
hhmm
HH:MM:SS.uuuuuu
Fields for end record

L0AETIM decimal Elapsed time (timer units)
L0ACOMP Sxxx or Unnnn Completion code
L0AQCBPR decimal Transaction priority (TRANDET only)
L0AEXTIM HH:MM:SS.uuuuuu CPU time
L0AAZAAP HH:MM:SS.uuuuuu zAAP time
Fields for start record

L0ATSKID 8 hex characters FSE task ID (TRANDET only)
L0ATERM 2 hex characters Region type (TRANDET only)
L0ANWID 8 characters Network ID
L0ALUNM 8 characters source LU
L0AUSID 8 characters source user

L0AGRPNM 8 characters source user group

L0ALUWID 26 characters logical Unit-of-Work
L0ACLASS 16 hex characters CPI-C region classes
L0A62DTE YYYYDDD Local Date of arrival (TRANDET only)
L0A62TME HHMMSSTT Local Time of arrival (TRANDET only)
An APPC segment is present on the start record, this is described in “APPC Segment” on
page 20-16.

Log Record 31 – Message GU Call

QLGUFLGS 2 hex characters Flags (TRANDET only, except following)
QLGUFDLI boolean True for a program GU, false for a DC GU
QLGUFLG1 2 hex characters Flags (TRANDET only)
QLGUFLGX 2 hex characters Flags (TRANDET only)
QLGUDRRN 8 hex characters Message DRRN
QLGUDTME YYYY-MM-DD timestamp with offset from UTC (TRANDET
hhmm
QLGUAPOF - Offset to APPC data
RTKN IMSID + OASN + Recovery token (from field QLGURTKN)
commit count
PST decimal region number (from QLGUPST)
ORID 8 characters originating system (from QLGUORID)
ORTK YYYY-MM-DD originating token (from QLGUORTK)
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu
UFLG1 2 hex characters CQS flags
QLGUCQNR decimal queue number (TRANDET only)
QLGUOPDN 8 characters message destination
QLGUOPPT 8 hex characters DRRN of next message in chain (TRANDET
only)
QLGUMFS 16 characters MFS data: CNT + MOD name
QLGUTSKI 8 hex characters PST task id (TRANDET only)
QLGUISEQ decimal VTAM inbound sequence number of last RU
(TRANDET only)
QLGUOSEQ decimal VTAM outbound sequence number of last
RU (TRANDET only)

QLGUACTL 2 hex characters CTBACTL contents (TRANDET only)

QLGUVCTL 2 hex characters CTBVCTL contents (TRANDET only)
QLGUDCTL 4 hex characters CTBDCTL contents (TRANDET only)
QLGUCOMP 2 hex characters CTBCOMP contents (TRANDET only)
QLGUCCB decimal CCB-ID (TRANDET only)
QLGUCCBO 8 characters Conversation owner (TRANDET only)
QLGUSQ6T decimal Sub queue 6 (wait for input) time for
previous message
QLGUIMSG 8 hex characters prior contents PSTQIMSG (TRANDET only)
QLGUQBP 8 hex characters DRRN in QBLKS (TRANDET only)
HH:MM:SS.uuuuuu
An APPC segment may be present, this is described in “APPC Segment” on page 20-16.

Log Record 32 – Message Rejected

QLREFLGS 2 hex characters rejection flags (TRANDET only)
PST decimal region number (from field QLREJPST)
QLREDRRN 8 hex characters DRRN of message
PCBA 8 hex characters address of PCB for correlation (from field
QLREJPCB)
RTKN IMSID + OASN + Recovery token (from field QLRERTKN)
commit count
ORID 8 characters originating system (from QLREORID)
ORTK YYYY-MM-DD originating token (from QLREORTK)
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu
QLREQNR decimal Queue number (TRANDET only)
QLREOLDM 8 hex characters DRRN of next most recent message
(TRANDET only)
QLREOPDN 8 characters Destination name
HH:MM:SS.uuuuuu

Log Record 33 – Message Freed

QLFRFLGS 2 hex characters Flags (TRANDET only)
QLFRFUNC 2 hex characters Function code (TRANDET only)
QLFRNODR decimal Number of DRRNs in QLFRVNDR
QLFRPCBA)
RTKN IMSID + OASN + Recovery token (from field QLFRRTKN)
commit count
ORID 8 characters originating system (from QLFRORID)
ORTK YYYY-MM-DD originating token (from QLFRORTK)
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu
QLFRVNDR 8 hex characters Up to 6 DRRNs
Or array of
8-hex-character
elements
QLFROPNM 8 characters destination
QLFROPDN decimal Number of DRRNs associated with message
(TRANDET only)
QLFROPDF 2 hex characters Flags (TRANDET only)
QLFROP3N 8 hex characters TIB token (TRANDET only)
QLFRFLG1 2 hex characters Flags (TRANDET only)
QLFRFLG2 2 hex characters Flags (TRANDET only)
QLFRRCTK 32 hex characters Shared queue recovery token


HH:MM:SS.uuuuuu
Log Record 34 - Message Cancelled

QLCMCALL 2 hex characters caller id and function (TRANDET only)
QLCMFLG2 2 hex characters flags (TRANDET only)
QLCMPCBA)
QLCMDSTN 8 characters destination
QLCMDRRN 8 hex characters DRRN of message
RTKN IMSID + OASN + Recovery token (from field QLCMRTKN)
commit count
ORID 8 characters originating system (from QLCMORID)
ORTK YYYY-MM-DD originating token (from QLCMORTK)
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu

Log Record 35 – Message Enqueued

QLNQCALL 2 hex characters call type (TRANDET only)
QLNQFLGS 2 hex characters flags (TRANDET only)
QLNQFLG4 2 hex characters flags (TRANDET only)
QLENQQNR decimal queue number (TRANDET only)
PST decimal region number (from field
QLENQPST)
PCBA 8 hex characters address of PCB for correlation (from
field QLNQPCBA)
QLNQDSTN 8 characters destination
QLNQDTTM YYYY-MM-DD timestamp with offset from UTC
HH:MM:SS.uuuuuu+hhmm (TRANDET only)
QLNQDRRN 8 hex characters DRRN of message
RTKN IMSID + OASN + commit recovery token (from field
count QLNQRTKN)
ORID 8 characters originating system (from QLNQORID)
ORTK YYYY-MM-DD originating token (from QLNQORTK)
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu
QLNQAPOF - Offset to APPC data, if present
QLNQOPPT 8 hex characters Next or prior DRRN (TRANDET only)
QLNQTBLK 8 hex characters DRRN in QBLKS (TRANDET only)
QLNQMSGC decimal previous queue count
QLNQCCB decimal CCB-ID (TRANDET only)

QLNQCCBO 8 characters Conversation owner (TRANDET only)

QLNQOLDM 8 hex characters DRRN in suspend queue (TRANDET
only)
QLNQMFS 16 characters origin + MID name
QLNNDNAM 8 characters Node name
QLNQRLIN decimal relative line number
QLNQRTRM decimal relative terminal number
QLNQSUB 8 characters Sub pool
QLNQISEQ decimal VTAM inbound sequence number of
last RU (TRANDET only)
QLNQOSEQ decimal VTAM outbound sequence number of
QLNQACTL 2 hex characters CTBACTL contents (TRANDET only)
QLNQVCTL 2 hex characters CTBVCTL contents (TRANDET only)
QLNQDCTL 4 hex characters CTBDCTL contents (TRANDET only)
QLNQCOMP 2 hex characters CTBCOMP contents (TRANDET only)
QLNQICNT 8 characters Input CNT name for front end
switching
QLNQIDST 8 characters input destination
QLNQIISQ Decimal input sequence number
QLNQSMBN 8 characters MSC re-routing transaction code
QLNQSID Decimal MSC re-routing system ID
QLNQ2MSQ 16 characters shared queues: queue name
(TRANDET only)
The next 3 fields are for ISC over TCPIP

QLNQPCID 16 hex characters previous conversation ID
QLNQCCID 16 hex characters current conversation ID
QLNQUOWID 16 hex characters unit of work ID
The next 3 fields for moving data to another CNT

QLNQGVLN Decimal Length of data being moved
QLNQMDST 2 hex characters Flags for new destination
QLNQMCNT 8 characters CNT moving the data

QLGUISEQ Decimal VTAM inbound sequence number of

DATETIME YYYY-MM-DD Log record timestamp to 1/100th of a
HH:MM:SS.xx+hhmm second, in UTC with offset to local time
HH:MM:SS.uuuuuu

Log Record 38 – Message Re-queued after an Abend

QLRIFLGS 2 hex characters Flags (TRANDET only)
QLRIFLG2 2 hex characters Flags (TRANDET only)
QLRIPCBA)
RTKN IMSID + OASN + Recovery token (from field QLRIRTKN)
commit count
PST decimal region number (from field QLRIPST)
QLRIAPOF - Offset to APPC data
ORID 8 characters originating system (from QLRIORID)
ORTK YYYY-MM-DD originating token (from QLRIORTK)
HH:MM:SS.uuuuuu
HH:MM:SS.uuuuuu
QLRIQNR decimal queue number (TRANDET only)
QLRISMBN 8 characters destination transaction
QLRIMMSG 8 hex characters DRRN of message being moved
QLRINMSG 8 hex characters DRRN of next message (TRANDET only)
QLRIQMSG 8 hex characters DRRN of QBLKS (TRANDET only)
QLRISTAT 8 hex characters CRE status at abort (TRANDET only)
QLRILHLD decimal Locks held highwater mark
These 7 fields for when moving a message to another CNT

QLRIGVLN decimal Length of data being moved (TRANDET only)
QLRIMDST 2 hex characters Flags for new destination (TRANDET only)
QLRIMFG1 2 hex characters Flags (TRANDET only)

QLRIPMSG 8 hex characters DRRN of message being moved (TRANDET

only)
QLRIQQRN 8 hex characters DRRN of QBLKS (TRANDET only)
QLRIQMRN 8 hex characters DRRN of message to chain to (TRANDET
only)
QLRIMCNT 8 characters CNT moving the message (TRANDET only)
HH:MM:SS.xx+hhm in UTC with offset to local time
m
HH:MM:SS.uuuuuu

Log Record 45 – System Statistics

Log record 45 is formatted for SYSSTAT only. It has several subtypes, not all of which are
formatted.
Subtypes that are not formatted are:
• 45-00 – Begin Statistics
• 45-0A – Latch Statistics
• 45-0B – DFSCBT00 storage
• 45-0E – Fixed storage pools
• 45-10 – RACF multi-TCB
• 45-11 – General storage
• 45-12 – IMODULE
• 45-13 – MSC link
• 45-14 – EWLM
• 45-15 – 64-bit cache storage manager
• 45-16 – Fast Path 64-bit buffer manager
• 45-17 – User Exit Statistics
• 45-18 – TCB-specific dispatcher stats
• 45-19 – 64-bit storage manager
• 45-FF – End Statistics

Log Record 45-02 – Queue Statistics

MFSOURCETYPE IMS45
STATTYPE - subtype
STATID QP Record ID
IMSVER 4 hex characters IMS version and release
VER decimal record version
FIELDFLAGS - flags
QMOFF - offset to queue manager section
SQOFF - offset to shared queues section
HH:MM:SS.uuuuuu
Queue Manager Section

QBLKDRRN 8 hex characters DRRN of highest queue block
SMSGDRRN 8 hex characters DRRN of highest short message queue
LMSGDRRN 8 hex characters DRRN of highest long message queue
#LOCATE decimal # of locate calls from queue manager
#RELEASE decimal # rcd release calls from queue manager
#LOCALTER decimal # locate & alter calls from queue manager
#PURGE decimal # requests to purge
#TRANSLATE decimal # translate requests
CINT - Reserved for IMS performance use
#READ decimal # of read requests
#WRITE decimal # of write requests (total)
#WRITE4PRG decimal # of writes done for purge
#WAITPURGE decimal # of waits for purge complete
#WAITBUF decimal # waits for buffer


#WAITREAD decimal Waits for other DECB to read buffer
#WAITWRITE decimal Waits for other DECB to write buffer
#WAITWTQ decimal Waits for conflicting enqueue-dequeue buffer
request
AVAIL1 - Reserved field
#IOERR decimal Count of temporary I/O errors not retried
#BUFLOCK decimal Total number of buffers locked
#BUFUNLOCK decimal Total number of buffers unlocked
#PCBUNCH decimal Total number of PCBs unchained from
buffers
RRNDUMMY 8 hex characters RRN of last dummy record assigned
#QMGR decimal Number of calls to Queue Manager - total
#REPOS decimal Number of calls to reposition at last buffer
#ENQ decimal Number of calls to enqueue messages
#DEQ decimal Number of calls to dequeue messages
#CANCEL decimal Number of calls to cancel input or output
QBLKINUSF 2 hex characters QBLKS flag byte
QBLKINUSR decimal Number QBLKS records currently in use
SMSGINUSF 2 hex characters short message queue flag byte
SMSGINUSR decimal Number short message queue records
currently in use
LMSGINUSF 2 hex characters long message queue flag byte
LMSGINUSR decimal Number long message queue records
currently in use
SMSGLEN decimal Size of a short message queue record
LMSGLEN decimal Size of a long message queue record
NUMBUF decimal Number buffers in the pool
Shared Queues Section

TOTALBUF decimal Total count of buffers
HIGHTHRESH decimal High threshold for buffers
LOWTHRESH decimal Low threshold for buffers
BUFINUSECT decimal Number of buffers in use


HIGHINUSECT decimal High water mark of buffers in use since last
checkpoint
#EXPAND decimal Number of times buffer has expanded
NEXTAVLPTR - Address of first available buffer
NEXTAVLCT decimal Count of first available buffer
BUFALOCPTR - Address of last buffer allocation
EXPCOMPPCT decimal Percentage to expand/compress buffers
XFLG 4 hex characters Shared queue buffer status flags
HIGHINUSECTR decimal High water mark of buffers since restart

Log Record 45-03 – Format Pool Statistics

MFSOURCETYPE IMS45
STATTYPE - subtype
STATID FP Record ID
FBPPFRC decimal # P/F REQUESTS
FBPIFRC decimal # I/F REQUESTS
FBPIFIOC decimal # I/F I/O'S
FBPCOMPC decimal # TIMES POOL COMPRESS WOULD
succeed
FBPDIOC decimal # DIRECTORY I/O OPERATIONS
FBPFREWC decimal # TIMES BLOCK WASHED FOR FRE
FBPPFIGC decimal # TIMES P/F REQUEST IGNORED
FBPFBRC decimal # F/B REQUESTS
FBPFBIGC decimal # TIMES F/B REQUEST IGNORED
FBPIFFBC decimal # TIMES I/F ON F/B QUEUE
FBPIFIFC decimal # TIMES I/F ON I/F QUEUE
FBPFBIFC decimal # TIMES F/B ON I/F QUEUE
FBPPFIFC decimal # TIMES P/F ON I/F QUEUE
FBPPFFBC decimal # TIMES P/F ON F/B QUEUE
FBPNDIRC decimal # TIMES THERE WAS NO DIR.ENT.
FBPIOERC decimal # I/O ERRORS POINT OR READ MACRO
FBPIODCB decimal # I/O REQUESTS WAITED DUE TO
FBPINDIR decimal # REQUESTS SATISFIED BY DIRECT
FBPINDXP - ADDRESS OF DIRECTORY INDEX
FBPINDXC decimal # DIRECTORY INDEX ENTRIES
HH:MM:SS.uuuuuu

Log Record 45-04 – OSAM Buffer Pool Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID DB Record ID
STDBCNT decimal # Stat counts returned
STDBBSIZ decimal or ‘ALL ‘ Buffer size
STDBNBUF decimal # Buffers
STDBLCTR decimal # Locate calls
STDBNBLK decimal # Requests to create new blocks
STDBALTR decimal # Buffer alter calls
STDBPRGR decimal # Purge calls
STDBFIPL decimal # Locate calls-data in pool
STDBBSRC decimal # Buffers searched
STDBRREQ decimal # Read I/O requests
STDBBSTW decimal # Single block writes/buffersteal
STDBPRGW decimal # Blocks written by purge
STDBWBZI decimal # Locate calls/wait busy ID
STDBWBZW decimal # Locate calls/wait busy write
STDBWBZR decimal # Locate calls/wait busy read
STDBWRLO decimal # Buffersteal/purgequeue-wait release own
STDBWNOB decimal # Buffersteal wait/no buffers avail
STDBERRT decimal # Perm write errors in subpool
STDBERRL decimal # Buffers locked in pool/write errors
STDBPOID 4 characters Pool ID
STDBFIXO 2 hex characters Fix option
STDCFCLS 4 hex characters OSAM caching storage class
STDCFRD decimal # blocks read from CF
STDCFEXP decimal # blocks expected but not read
STDCFWRP decimal # blocks written to CF (prime)

STDCFWRC decimal # blocks written to CF (changed)

STDCFSCF decimal # blocks not written (storage class full)
STDCFXIV decimal # blocks invalidated w/XI
STDCFXIC decimal # of XI calls issued
STDSBSEQ decimal # immediate (sync) sequential reads
STDSBANT decimal # anticipatory reads
HH:MM:SS.uuuuuu

Log Record 45-05 – Variable Pool Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID SM Record ID
STSDNAME - eyecatcher ‘DLDP’
STSDSIZE decimal DMB pool (maximum) size
STSDRES decimal DMB pool currently-used
STSDHIGH decimal DMB pool highest-used
STSPNAME - eyecatcher ‘DLMP’
STSPSIZE decimal PSB pool (maximum) size
STSPRES decimal PSB pool currently-used
STSPHIGH decimal PSB pool highest-used
STSDPNM - eyecatcher ‘DPSB’
STSDPSZ decimal DPSB pool (maximum) size
STSDPRS decimal DPSB pool currently-used
STSDPHG decimal DPSB pool highest-used
STSWNAME - eyecatcher ‘PSBW’
STSWSIZE decimal PSBW pool (maximum) size
STSWRES decimal PSBW pool currently-used
STSWHIGH decimal PSBW pool highest-used
STSBNAME - Eyecatcher 'DBWP'
STSBSIZE decimal DBW pool (maximum) size
STSBRES decimal DBW pool currently-used
STSBHIGH decimal DBW pool highest-used
STSENAME - Eyecatcher ‘EPCB’
STSESIZE decimal EPCB pool (maximum) size
STSERES decimal EPCB pool currently-used
STSEHIGH decimal EPCB pool highest-used
STSMNAME - Eyecatcher 'MAIN'

STSMSIZE decimal WKAP pool (maximum) size

STSMRES decimal WKAP pool currently-used
STSMHIGH decimal WKAP pool highest-used
HH:MM:SS.uuuuuu

Log Record 45-06 – Scheduler Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID AS Record ID
NOSCHD decimal scheduling failed: PGM conflict
NSDB decimal scheduling failed: intent
NSCH decimal schedulings attempted
NSMISC decimal scheduling failed: miscellaneous reasons
BMPACT decimal active BMPs
MPPACT decimal active MPPs
SKCNT decimal current scheduling number
FLG1 - flags
HH:MM:SS.uuuuuu
PSB Pool Statistics

PSBGRQSTS decimal # get requests
PSBGNSPCCSA decimal # times CSA space not available
PSBGCOCSA decimal # times CSA PSBs cast out
PSBGFAILCSA decimal # times CSA get fails
PSBGNSPCDLI decimal # times DLI space not available
PSBGCODLI decimal # times DLI PSBs cast out
PSBGFAILDLI decimal # times DLI get fails
PSBGNSPCBOTH decimal # times space not avail in both
PSBGTIMENCO HH:MM:SS.uuuuuu time spent getting space when no cast-out
PSBGTIMECO HH:MM:SS.uuuuuu time spent getting space when cast-out
needed

PSBW Pool Statistics

PSWGRQSTS decimal get requests
PSWGFAIL decimal failed requests
PSWGTIME HH:MM:SS.uuuuuu time spent
Shared Queue Statistics

CQNOTIFYLCL decimal CQS notifies (local)
CQNOTIFYRMT decimal CQS notifies (remote)
CQLTX2IFS HH:MM:SS.uuuuuu Cumulative time between CQS structure
list transition exit dispatch and CQS
schedule of inform exit
CQIFS2IFX HH:MM:SS.uuuuuu Cumulative time between CQS schedule of
IMS inform exit and dispatch of IMS
inform exit SRB.
CQIFX2ENQ HH:MM:SS.uuuuuu Cumulative time between IMS inform exit
and enqueue of SMB onto TCT (local) or
call of router (remote)

Log Record 45-07 – Logger Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID LL Record ID
IMSVER 4 hex characters IMS version and release
VER decimal record version
LLOFF - offset to logical logger section
PLOFF - offset to physical logger section
m
HH:MM:SS.uuuuuu
Logical Logger Section

CURSEQ# - Current log record sequence number
CHKW decimal Number of “check write” requests
WTWT decimal Number of “wait write” requests
BUFWAITCKP decimal # waits for all buffers full during checkpoint
BUFWAITNCK decimal # waits for all buffers full at other times
BUFWAITTRANS decimal number of "other" buffer waits
WRTAWE decimal number of write requests with AWE
WTWT2CHKW decimal number of WTWT->CHKW conversions
PWADSIOTIME HH:MM:SS.uuuuuu Cumulative write time for primary WADS
SWADSIOTIME HH:MM:SS.uuuuuu Cumulative write time for secondary WADS
POLDSIOTIME HH:MM:SS.uuuuuu Cumulative write time for primary OLDS
SOLDSIOTIME HH:MM:SS.uuuuuu Cumulative write time for secondary OLDS
Physical Logger Section

WADSEXCPVR decimal number of WADS EXCPVRs
WADS4K decimal number of 4K writes to WADS

OLDSWRITES decimal number of OLDS writes

OLDSREADS decimal number of OLDS reads
INTCHKW decimal number of internal CHKWs
WTWTTIME decimal wait time of WTWT (times 1024 to get µS)
BLKSIZE decimal OLDS block size
BUFNO decimal number of log buffers
WADSTRACKS decimal number of tracks in WADS (IMS 14 and
below)
WADSBLKSTRK decimal WADS blocks / track (IMS 14 and below)
WADSCIS decimal number of CIs in WADS (IMS 15 and above)
FLG1 2 hex characters flags
FLG2 2 hex characters flags (IMS 15 and above)
ENC_WADS_MTX 4 hex characters WADS encryption matrix (IMS 15 and above)
PWADSMAXIOTM HH:MM:SS.uuuuuu Maximum IO time since last checkpoint for
primary WADS
SWADSMAXIOTM HH:MM:SS.uuuuuu Maximum IO time since last checkpoint for
secondary WADS
POLDSMAXIOTM HH:MM:SS.uuuuuu Maximum IO time since last checkpoint for
primary OLDS
SOLDSMAXIOTM HH:MM:SS.uuuuuu Maximum IO time since last checkpoint for
secondary OLDS
PWADSMAXIOTS YYYY-MM-DD When maximum IO time occurred for primary
HH:MM:SS.uuuuuu WADS
SWADSMAXIOTS YYYY-MM-DD When maximum IO time occurred for
HH:MM:SS.uuuuuu secondary WADS
POLDSMAXIOTS YYYY-MM-DD When maximum IO time occurred for primary
HH:MM:SS.uuuuuu OLDS
SOLDSMAXIOTS YYYY-MM-DD When maximum IO time occurred for
HH:MM:SS.uuuuuu secondary OLDS
BUFPOSTCKP decimal Number of times any task still waiting for
buffers after write during checkpoint
BUFPOSTNCK decimal Number of times any task still waiting for
buffers after write at other times

Log Record 45-08 – VSAM Buffer Pool Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID VS Record ID
STVSUBP 2 characters Sub pool ID
STVBCNT decimal # Stats returned
STVBBSIZ decimal or ‘ALL ‘ Buffer size
STVBNBUF decimal # Buffers in sub pool
STVBHSNB decimal # HS buffers for sub pool
STVBRRBA decimal # Retrieve by RBA calls
STVBRKEY decimal # Retrieve by key calls
STVBEIST decimal # Logical records ISRTS/ESDS
STVBKIST decimal # Logical records ISRTS/KSDS
STVBBALT decimal # Logical records altered in sub pool
STVBBGWR decimal # Background write requests
STVBSYNP decimal # Sync calls
STVBERRC decimal # Write errors in sub pool
STVBERRL decimal Largest # write errors in sub pool
STVBVSMG decimal # VSAM GET calls
STVBSCHB decimal # VSAM search buffers calls
STVBVSMF decimal # Times VSAM found CI in pool
STVBVSMR decimal # Times VSAM read CI from DASD
STVBUSRW decimal # Writes initiated by IMS
STVBVSMW decimal # Writes initiated by VSAM
STVBHSRS decimal # Successful VSAM reads from HS
STVBHSWS decimal # Successful VSAM writes to HS
STVBHSRF decimal # Failed VSAM reads from HS
STVBHSWF decimal # Failed VSAM writes to HS
STVBPLHW decimal # PLH waits

STVBPOID 4 characters Shared resource pool ID

STVBPTY 1 character Shared resource pool type
STVBPNUM 2 hex characters Shared resource pool number
STVBFIXO 2 hex characters Fix option
HH:MM:SS.uuuuuu
Log Record 45-09 – Program Isolation Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID PI Record ID
STPIINCR decimal PI pool increment
STPIMAX decimal PI pool maximum
STPIUSED decimal PI pool current use
STPISRCH decimal number of FINDQCB entries
STPISYNA decimal total synonyms searched
STPISYNM decimal Maximum synonyms searched in a call
DATETIME YYYY-MM-DD Log record timestamp to 1/100th of a second, in
HH:MM:SS.xx+hhm UTC with offset to local time
m
HH:MM:SS.uuuuuu

Log record 45-0D – VTAM Buffer Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID RA Record ID (Receive Any)
ST0DRUC decimal number of RECA used
ST0DRMAX decimal maximum number of RECA used
m
HH:MM:SS.uuuuuu

Log Record 45-0F – Dispatcher Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID DS Record ID
STCK - current time
DATE_TIME - current time (local with UTC offset)
CPUID 16 hex characters CPU id from STIDP
IMS_REL 4 hex characters IMS version and release
MVS_REL 4 hex characters z/OS version and release
TCB_OFFS - Offset of TCB section
TCB_ELGTH - Length of TCB sect entry
DSAP_OFFS - Offset of DSAP section
DSAP_ELGTH - Length of DSAP sect entry
#TYPES decimal # TCB types
REGIONS decimal # assigned dependent regions
CREATES decimal Total IMS ITASK creates
DISPS decimal Total IMS # dispatches
CTLTCBTM HH:MM:SS.uuuuuu Cumulative CPU time CTL TCB
CTLSRBTM HH:MM:SS.uuuuuu Cumulative CPU time CTL SRB
DLITCBTM HH:MM:SS.uuuuuu Cumulative CPU time DLI TCB
DLISRBTM HH:MM:SS.uuuuuu Cumulative CPU time DLI SRB
CTLZIIPENTM HH:MM:SS.uuuuuu Cumulative CPU time CTL zIIP enclave
CTLZIIPNETM HH:MM:SS.uuuuuu Cumulative CPU time CTL zIIP non enclave
CTLZIIPCPTM HH:MM:SS.uuuuuu Cumulative CPU time CTL zIIP time on CP
DLIZIIPENTM HH:MM:SS.uuuuuu Cumulative CPU time DLI zIIP enclave
DLIZIIPNETM HH:MM:SS.uuuuuu Cumulative CPU time DLI zIIP non enclave
DLIZIIPCPTM HH:MM:SS.uuuuuu Cumulative CPU time DLI zIIP time on CP


TCB_NUM decimal Number of TCB entries (see following)
Array of TCB entries, each comprising

TCBNAME 4 characters type of TCB
#TCBS decimal Number of TCBs of this type
TCREATES decimal ITASK creates
TDISP decimal ITASK dispatches
TSUSP decimal dispatcher suspends
REALTIME HH:MM:SS.uuuuuu real time this TCB
IMSTIME HH:MM:SS.uuuuuu IMS busy time
CPUTIME HH:MM:SS.uuuuuu CPU time this TCB
WRTCBTERM decimal wrong TCB ITASK terminations
QLENCT decimal ECBs waiting
QLENMAX decimal max ECB queue length
RESTIME HH:MM:SS.uuuuuu total resume time
MAXRESTIME decimal max of above (µs)
#DBFSLEEPS decimal tot DBF sleep suspends
(End of TCB entry)

HH:MM:SS.uuuuuu

Log Record 45-21 – IRLM User Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID RU Record ID
STATSIZE - Length of statistics which follow
STAGTLOK decimal total global lock requests
STACHLCT decimal number child locks propagated
STAGNRHR decimal RH to RH notify requests
STAACLCK decimal lock requests
STAACUNL decimal unlock requests
STAACCHG decimal change requests
STAASNOT decimal synchronous notify requests
STAAANOT decimal asynchronous notify requests
STAACVER decimal verify requests
STAACPUR decimal purge requests
STAACQRY decimal query requests
STAATAKE decimal takeover requests
STACSUSP decimal suspend exit counter
STACRSUM decimal resume exit counter
STACSTAT decimal status exit counter
STACNOTY decimal notify exit counter
STACDEAD decimal deadlock exit counter
STACTIME decimal timeout exit counter
STAACSPL decimal Synchronously Propagated Locks
STAACSPC decimal Synchronously Propagated Change
STAACSPU decimal Synchronously Propagated Unlock
STAACAPL decimal Asynchronously Propagated Locks
STALICNT decimal # local resource contentions
STAGICNT decimal # global resource contentions

STAGCONT decimal # visits to the contention exit, but IRLM

granted OK
STAFCONT decimal # false contentions
HH:MM:SS.uuuuuu

Log Record 45-22 – IRLM System Statistics

MFSOURCETYPE IMS45
STATTYPE - sub type
STATID RS Record ID
STATSIZE - Length of statistics which follow
STAACIDN decimal identify requests
STAACQUT decimal quit requests
STADLCL decimal total number of local deadlocks
STADGBL decimal total number of global deadlocks
STAPTOUT decimal timeout RLBs purged
STACSAH decimal CSA high water mark (thousands of bytes)
STACSAC decimal CSA current (thousands of bytes)
STARETRY decimal # re-triable ABENDS
STANRTRY decimal # non re-triable ABENDS
Array of storage pool statistics

STASPNM 4 or 8 characters pool name
STASPCR decimal current number of blocks in pool
STASPMX decimal maximum number of blocks in pool
STASPEX decimal number of pool expansions
STASPCM decimal number of pool compressions
(end of pool entry)

SMPOOLCT decimal number of entries in the array
HH:MM:SS.uuuuuu

Log Record 56 – Unit-of-Recovery

Log record 56 is formatted for TRANDET only. It has several subtypes.
Log Record 56-00 – External Subsystem

MFSOURCETYPE IMS56
TPCPSSTY 00 sub type
TPCPSBCD 4 hex characters sub code
TPCPOSSN 8 characters sub system name
TPCPNSS decimal number of subsystems
PST decimal region number (from field TPCPSTN)
TPCPINLT 8 characters Input LTERM
TPCPUSID 8 characters userid
TPCPGRPN 8 characters user group
RTKN IMSID + OASN + commit Recovery token (from field
count TPCPRTKN)
TPCPFLGS 2 hex characters flags
TPCPTIME YYYY-MM-DD timestamp with offset from UTC
HH:MM:SS.uuuuuu+hhmm
TPCPESS 8 characters External subsystem name
TPCPESF1 2 hex characters External subsystem flags
HH:MM:SS.uuuuuu

Log record 56-07 – Start IMS Unit-of-Recovery

MFSOURCETYPE IMS56
TPCPSBCD 0000 sub code
TPCPINLT 8 characters PSB name
RTKN IMSID + OASN + Recovery token (from field TPCPRTKN)
commit count
HH:MM:SS.uuuu
uu+hhmm
DATETIME YYYY-MM-DD Log record timestamp to 1/100th of a second, in
HH:MM:SS.xx+h UTC with offset to local time
hmm
HH:MM:SS.uuuu
uu

Log Record 56-12 – End of Phase 2 Commit

MFSOURCETYPE IMS56
commit count
TPCPCPUI 16 hex characters CPU ID
TPCPSIDD decimal destination system
TPCPSIDS decimal source system
HH:MM:SS.uuuuuu

Log Record 56-15 – Restart with RRS

MFSOURCETYPE IMS56
TPCPSSTY 15 Sub type
TPCPSBCD 0000 Sub code
TPCPOSSN 8 characters Sub system name
TPCPIMSL up to 21 characters IMS log name
TPCPRRSL up to 64 characters RRS log name
TPCPURCT decimal Number of units of recovery
TPCPUORS Array of Units of recovery themselves
32-hex-character
elements
HH:MM:SS.uuuuuu

Log Record 56-16 – Start of RRS Unit-of-Work

MFSOURCETYPE IMS56
TPCPINLT 8 characters input LTERM
commit count
HH:MM:SS.uuuuuu+
hhmm
TPCPURID 32 hex characters RRS UR identifier
TPCPFLG4 2 hex characters LCREF4 BYTE
TPCPPCST 2 hex characters protected conversation table status
TPCPTSKN decimal task number
TPCPWID Up to 280 hex workid (LUWID/EID/XID)
characters
HH:MM:SS.uuuuuu

Log record 56-FA – Transaction-level Statistics

MFSOURCETYPE IMS56
TPCPSSTY FA sub type
commit count
TPCPCPUI 16 hex characters CPU ID
TPCPSIDD decimal destination system
TPCPSIDS decimal source system
TPPFXLEN - Length of prefix
TPIMSVER 2 hex characters IMS version
TPIMSREL 2 hex characters IMS release
TPRECVER decimal record version
TPJOBN 8 characters job name
TPSTEPN 8 characters step name
TPLTERM 8 characters input LTERM
TPNWID 8 characters network ID (APPC)
TPLUNAME 8 characters LU name (APPC)
TPPGMNM 8 characters program name
TPTRAN 8 characters transaction code
TPCLASS decimal transaction class
TPPRTY 2 hex characters transaction priority


TPTYPE 2 hex characters program type
TPCMPCD Sxxx or Unnnn completion code
TPEXTIME HH:MM:SS.uuuuuu CPU time
TPEZAAP HH:MM:SS.uuuuuu zAAP time
TPSTARTS YYYY-MM-DD Unit of recovery start time (UTC)
HH:MM:SS.uuuuuu
TPSTARTU - Unit of recovery start time (local with UTC
offset)
TPENDS YYYY-MM-DD Unit of recovery end time (UTC)
HH:MM:SS.uuuuuu
TPENDU - Unit of recovery end time (local with UTC
offset)
TPINDATE - Input date of message
TPINTIME - Input time of message
TPINUTC YYYY-MM-DD Message input timestamp (local with UTC
HH:MM:SS.uuuuuu+ offset)
hhmm
TPTDBIO decimal elapsed DB IO time (µs)
TPTDBPL decimal elapsed locking time (µs)
TPDGU decimal DL/I DB GU calls
TPDGN decimal DL/I DB GN calls
TPDGNP decimal DL/I DB GNP calls
TPDGHU decimal DL/I DB GHU calls
TPDGHN decimal DL/I DB GHN calls
TPDGHNP decimal DL/I DB GHNP calls
TPDISRT decimal DL/I DB ISRT calls
TPDDLET decimal DL/I DB DLET calls
TPDREPL decimal DL/I DB REPL calls
TPCLCNT decimal TOTAL DB calls
TPMGU decimal DL/I MSG GU calls
TPMGN decimal DL/I MSG GN calls
TPMISRT decimal DL/I MSG ISRT calls
TPMPURG decimal DL/I MSG PURG calls


TPTSTNQ decimal test enqueues
TPTSTWT decimal waits on test enqueues
TPTSTDQ decimal test dequeues
TPQCONQ decimal queue command enqueues
TPQCOWT decimal waits on queue command enqueues
TPQCODQ decimal queue command dequeues
TPSUPNQ decimal update enqueues
TPSUPWT decimal waits on update enqueues
TPSUPDQ decimal update dequeues
TPEXCNQ decimal exclusive enqueues
TPEXCWT decimal waits on exclusive enqueues
TPEXCDQ decimal exclusive dequeues
TPMCMD decimal DL/I MSG CMD calls
TPMGCMD decimal DL/I MSG GCMD calls
TPMCHNG decimal DL/I MSG CHNG calls
TPMAUTH decimal DL/I MSG AUTH calls
TPMSETO decimal DL/I MSG SETO calls
TPSAPSB decimal DL/I APSB calls
TPSDPSB decimal DL/I DPSB calls
TPSGMSG decimal DL/I GMSG calls
TPSICMD decimal DL/I ICMD calls
TPSRCMD decimal DL/I RCMD calls
TPSCHKP decimal DL/I CHKP calls
TPSXRST decimal DL/I XRST calls
TPSROLB decimal DL/I ROLB calls
TPSROLS decimal DL/I ROLS calls
TPSSETS decimal DL/I SETS calls
TPSSETU decimal DL/I SETU calls
TPSINIT decimal DL/I INIT calls
TPSINQY decimal DL/I INQY calls
TPSLOG decimal DL/I LOG calls


TPDDEQ decimal DL/I DB DEQ calls
TPVSAMR decimal VSAM reads
TPVSAMW decimal VSAM writes
TPOSAMR decimal OSAM reads
TPOSAMW decimal OSAM writes
TPTOTIO decimal TOTAL DL/I IO COUNT
TPESAF decimal TOTAL ESAF calls
TPFLD decimal FP FLD calls
TPPOS decimal FP POS calls
TPRLSE decimal RLSE calls
TPXSAVE decimal SAVE calls (XQUERY)
TPXRSTR decimal RSTR calls (XQUERY)
TPXCOPY decimal COPY calls (XQUERY)
TPSICAL decimal DL/I ICAL calls
TPDGUR decimal DL/I GUR calls
TPDIR decimal DL/I IR calls
TPDMR decimal DL/I MR calls
HH:MM:SS.uuuuuu

Log Record 56-xx – All Other Types

MFSOURCETYPE IMS56
TPCPSSTY 2 hex characters sub type
TPCPSBCD 4 hex characters sub code
TPCPINLT 8 characters Input LTERM
commit count
HH:MM:SS.uuuuuu+
hhmm
TPCPSOXN 8 characters External subsystem name
HH:MM:SS.uuuuuu

Log Record F9 – User Record

Ironstream formats the BMC Mainview F9 program log record. There are three levels of
detail:
• MVF9SUMM – selected fields
• MVF9STAT – more fields
• MVF9DET – all listed fields
Field name Format Description SUMM STAT DET

MFSOURCETYPE IMSF9 Y Y Y
IMSID up to 8 characters IMS ID Y Y Y
SYSNAME 4 characters z/OS system where Y Y Y

extracted
PST decimal region number (from Y Y Y
PGMPSTNR)
PGMOPSYS 3 characters MVS level: vrr Y Y
PGMIMS 4 characters IMS level: vvrr Y Y
PGMIMF 4 characters Mainview for IMS Y Y

level: vvrr
PGMIMSID 4 characters IMSID Y Y Y
PGMSMFID 4 characters SMF ID Y Y
PGMSYSID 1 character Mainview system ID Y Y
PGMFLAG1 1 character LSO= parameter Y Y
PGMSAD12 2 hex characters flags Y
PGMJOBNM 8 characters Job name Y Y Y
PGMASID 4 hex characters address space ID Y
PGMPG 4 hex characters SRM performance Y

group
PGMCAVAL decimal storage available Y
after scheduling
(units of 2kb)
PGMAGN 8 characters AGN name Y Y
PGMPSBNM 8 characters PSB name Y Y Y
PGMTRNCD 8 characters transaction code Y Y Y
PGMESSID 4 characters external subsystem Y Y
PGMCLAS decimal transaction class Y Y Y


PGMPTYPE 1 character program type Y Y Y
PGMPTYP2 1 character Additional program Y Y

type
PGMXFLAG 2 hex characters transaction type Y Y
PGMCUSED decimal program size (in 2k Y Y Y

units)
PGMWLMSC 8 characters WLM service class Y
PGMSTRDT YYYY-MM-DD program start, Y Y Y

HH:MM:SS.uuuuuu includes PGMSTRTT
[+hhmm] [with offset to local
time if in UTC]
PGMSTOPD YYYY-MM-DD transaction end, Y Y Y
HH:MM:SS.uuuuuu PGMSTOPT [with
[+hhmm] offset to local time if
in UTC]
PGMNBA decimal normal FP buffer Y Y
allocation
PGMOBA decimal overflow FP buffer Y Y
allocation
PGMBUHWM decimal FP buffer highwater Y Y
mark this schedule
PGMCOMP Sxxx or Unnnn Completion code Y Y Y
PGMPSBSZ decimal PSB pool space Y Y

needed, units of 8
bytes
PGMDMBSZ decimal DMB pool space Y Y
needed (bytes)
PGMLOGID 4 characters ID of module that Y
logged this record
PGMPSBSA decimal CSA pool space Y Y
needed (bytes)
PGMPSBDL decimal DLISAS pool space Y Y
needed (bytes)
PGMSHCPU HH:MM:SS.uuuuuu Control region Y Y
scheduling CPU time
PGMCOCPU HH:MM:SS.uuuuuu Control region Y Y
overhead CPU time


PGMDOCPU HH:MM:SS.uuuuuu Dependent region Y Y
overhead CPU time
PGMDLCPU HH:MM:SS.uuuuuu Dependent region Y Y
program load CPU
time
PGMSSCPU HH:MM:SS.uuuuuu DLISAS scheduling Y Y
CPU time
PGMSOCPU HH:MM:SS.uuuuuu DLISAS overhead Y Y
CPU time
PGMCPTWK HH:MM:SS.uuuuuu CPU timer working Y
storage
PGMMGU decimal message GU calls Y Y
PGMMGN decimal message GN calls Y Y
PGMMISRT decimal message ISRT calls Y Y
PGMMPURG decimal message PURG calls Y Y
PGMMOTHR decimal Other message calls Y Y
PGMDONCP HH:MM:SS.uuuuuu Standard CP CP CPU Y Y

time
PGMDZPCP HH:MM:SS.uuuuuu zIIP or zAAP CPU Y Y
time
PGMUSER 32 hex characters user area Y
DATETIME YYYY-MM-DD Log record timestamp Y Y Y

HH:MM:SS.xx+hhmm to 1/100th of a second,
in UTC with offset to
local time
LOGRC_STCK YYYY-MM-DD Log record timestamp Y Y Y
HH:MM:SS.uuuuuu in UTC
LOGRC_SEQ decimal Log record sequence Y Y Y
number

Log Record FA – User Record

Ironstream formats the BMC Mainview FA transaction log record. There are three levels of
detail:
• MVFASUMM – selected fields
• MVFASTAT – more fields
• MVFADET – all listed fields

MFSOURCETYPE IMSFA Y Y Y
SYSNAME 4 characters z/OS system where Y Y Y

extracted
TRNRCTYP 2 hex characters record type Y Y Y
PST decimal region number (from Y Y Y

TRNPSTNR)
TRNOPSYS 3 characters MVS level vrr Y Y
TRNSMQFL 2 hex characters flags Y Y
TRNIMS 4 characters IMS level: vvrr Y Y
TRNIMF 4 characters Mainview for IMS level: Y Y

vvrr
TRNIMSID 4 characters IMSID Y Y Y
TRNSMFID 4 characters SMF ID Y Y
TRNSYSID 1 character Mainview system ID Y Y
TRNFLAG1 1 character LSO= parameter Y Y
TRNTMERR 2 hex characters indicates an error with Y Y Y

CPU timing
TRNTMEDT 2 hex characters IMS dispatcher type code Y
when the timing error
occurred
TRNJOBNM 8 characters Job name Y Y Y
TRNASID 4 hex characters address space ID Y
TRNPG 4 hex characters SRM performance group Y
TRNCAVAL decimal storage available after Y

scheduling (units of 2kb)
TRNAGN 8 characters AGN name Y Y
TRNPSBNM 8 characters PSB name Y Y Y
TRNTRNCD 8 characters transaction code Y Y Y


TRNESSID 4 characters external subsystem Y Y
TRNOTMCL 1 character OTMA client type Y Y
TRNCLAS decimal Transaction class Y Y Y
TRNPTYPE 1 character program type Y Y Y
TRNFLAG0 1 character additional program type Y Y
TRNXFLAG 2 hex characters transaction type Y Y
TRNCUSED decimal program size (in 2k units) Y Y Y
TRNCOMP Sxxx or Unnnn Completion code Y Y Y
TRNSTRDT YYYY-MM-DD transaction start, includes Y Y Y

HH:MM:SS.uuuuuu TRNSTRTT, TRNSTRTU
[+hhmm] and TRNSTRTA [with
offset to local time if in
UTC]
TRNSTOPD YYYY-MM-DD transaction end, includes Y Y Y
HH:MM:SS.uuuuuu TRNSTOPT, TRNSTOPU
[+hhmm] and TRNSTOPA [with
offset to local time if in
UTC]
TRNARIVD YYYY-MM-DD transaction arrival, Y Y Y
HH:MM:SS.uuuuuu includes TRNARVTH,
[+hhmm] TRNARVTJ and
TRNXUTCA [with offset
to local time if in UTC]
TRNARIVT decimal EMH input queue time Y Y Y
(ms)
TRNLTERM 8 characters LTERM Y Y Y
TRNUSID 8 characters user Y Y Y
TRNVNODE 8 characters VTAM node Y Y
TRNPLINE decimal BTAM line Y Y
TRNPTERM decimal BTAM terminal Y Y
TRNPGMNM 8 characters program name Y Y Y
TRNRCODE 8 characters routing code Y Y
TRNFLAG2 1 character Fast path flag Y Y
TRNFLAG3 2 hex characters OTMA flag Y Y
TRNBUSED decimal FP buffers used Y Y


TRNNBA decimal normal FP buffer Y Y
allocation
TRNOBA decimal overflow FP buffer Y Y
allocation
TRNNCIC decimal FP CI contentions Y Y
TRNNWFB decimal waits for FP buffers Y Y
TRNSPRC decimal sync point return code Y Y
TRNBGQCT decimal balancing group queue Y Y

count
TRNMDRRN 8 hex characters input message DRRN Y Y
TRNMST 4 hex characters MSC trace Y Y
TRNCSW 2 hex characters MSC source Y Y
TRNUINID 2 hex characters MSC input SID Y Y
TRNUOTID 2 hex characters MSC destination SID - Y Y

IOPCB
TRNUSWID 2 hex characters MSC destination SID - Y Y
message switch
TRNUALID 2 hex characters MSC destination SID - Y Y
alternate PCB
TRNUMSWT 8 characters or alternate PCB LTERM or Y Y
12 hex characters CICS Unit-of-Work ID
TRNUALTN 8 characters alternate PCB destination Y Y
TRNMSCAD YYYY-MM-DD MSC arrival, includes Y Y Y

HH:MM:SS.uuuuuu TRNMSCTH,
[+hhmm] TRNMSCTJ and
TRNXUTCA [with offset
to local time if in UTC]
TRNLOGID 4 characters ID of module that logged Y
this record
TRNCDCPU HH:MM:SS.uuuuuu Control region CPU time - Y Y
DLI
TRNCBCPU HH:MM:SS.uuuuuu Control region CPU time Y Y
– buffer handler
TRNOCCPU HH:MM:SS.uuuuuu Control region CPU time Y Y
– open and close


TRNDDCPU HH:MM:SS.uuuuuu dependent region CPU Y Y
time - DLI
TRNDBCPU HH:MM:SS.uuuuuu dependent region CPU Y Y
time – buffer handler
TRNDOCPU HH:MM:SS.uuuuuu dependent region CPU Y Y
time – open and close
TRNPGCPU HH:MM:SS.uuuuuu dependent region CPU Y Y
time - application
TRNSDCPU HH:MM:SS.uuuuuu DLISAS region CPU time Y Y
- DLI
TRNSBCPU HH:MM:SS.uuuuuu DLISAS region CPU time Y Y
– buffer handler
TRNSOCPU HH:MM:SS.uuuuuu DLISAS region CPU time Y Y
– open and close
TRNESCPU HH:MM:SS.uuuuuu dependent region CPU Y Y
time – DB2
TRNMGU decimal message GU calls Y Y
TRNMGN decimal message GN calls Y Y
TRNMISRT decimal message ISRT calls Y Y
TRNMPURG decimal message PURG calls Y Y
TRNMOTHR decimal other message calls Y Y
TRNIMCHR decimal input character count Y Y
TRNISPAC decimal SPA input character count Y Y
TRNOMCHR decimal output character count Y Y
TRNOSPAC decimal SPA output character Y Y

count
TRNATCHR decimal message switch output Y Y
character count
TRNALCHR decimal alternate LTERM output Y Y
character count
TRNSKW decimal SYNC BUFFER FLUSH Y Y
KEY WRITE
TRNSNKW decimal SYNC BUFFER FLUSH Y Y
NONKEY WRITE
TRNUSER 32 hex characters user area Y


TRNSCODE 8 characters IMS transaction code for Y Y
SAP
TRNSTCK YYYY-MM-DD transaction start time Y
HH:MM:SS.uuuuuu UTC
TRNETFLG 2 hex characters timings collected Y
TRNW1OTH decimal unclassified IWAIT time Y Y

(µs)
during sync point (µs)
TRNW2LCH decimal latch IWAIT time during Y Y
sync point (µs)
TRNW2IOV decimal VSAM IWAIT time during Y Y
sync point (µs)
TRNW2IOO decimal OSAM IWAIT time during Y Y
sync point (µs)
during TM calls (µs)
TM calls (µs)
during DB open / close
(µs)
TRNW4DBR decimal DBRC during IWAIT time Y Y
DB open / close (µs)
TRNW4IO decimal IO during IWAIT time DB Y Y
open / close (µs)
during DB calls (µs)
DB calls (µs)
TRNW5LCK decimal IRLM / PI IWAIT time Y Y
during DB calls (µs)
TRNW5IOV decimal VSAM IWAIT time during Y Y
DB calls (µs)
TRNW5IOO decimal OSAM IWAIT time during Y Y
DB calls (µs)
TRNW5IOD decimal DEDB IWAIT time during Y Y
DB calls (µs)


TRNEAPPL decimal application elapsed time Y Y
(µs)
TRNEDLTM decimal TM calls elapsed time (µs) Y Y
TRNEDLDB decimal DB calls elapsed time (µs) Y Y
TRNEDB2 decimal DB2 calls elapsed time Y Y

(µs)
TRNEMQS decimal MQ calls elapsed time (µs) Y Y
TRNEOESS decimal other ESS calls elapsed Y Y

time (µs)
TRNEOPCL decimal DB open/ close elapsed Y Y
time (µs)
TRNESYNC decimal sync point elapsed time Y Y
(µs)
TRNE1STD decimal schedule to 1st DLI call Y Y
elapsed time (µs)
TRNELDLI decimal last DLI call elapsed time Y Y
(µs)
TRNTCPU HH:MM:SS.uuuuuu total CPU time Y Y Y
TRNSTCKE YYYY-MM-DD transaction end time UTC Y

HH:MM:SS.uuuuuu
TRNOTMAM 16 characters OTMA member name Y Y
TRNFALSC decimal number of false schedules Y Y
TRNRSENM 8 characters RSE name Y Y
TRNOTMAP 8 characters OTMA map name Y Y
TRNNUOWP 40 hex characters Network Unit-of-Work ID Y Y
TRNWLMSC 8 characters WLM service class Y
TRNSMQGN 8 characters shared-Q group name Y
TRNUOW IMSID + timestamp, transaction unit of work Y Y Y

IMSID + timestamp,
flags
TRNDLCMX decimal maximum time for a TM Y Y
call
TRNDLDMX decimal maximum time for a DB Y Y
call


TRNESSMX decimal maximum time for an ESS Y Y
call
TRNDLWMX decimal maximum time for a (non Y Y
IO) wait
TRNDLDTH decimal number of DB or ESS over Y Y
threshold
TRNDLCTH decimal number of TM calls over Y Y
threshold
TRNDLDER decimal number of DLI calls with Y Y
"bad" stat or RC
TRNESSER decimal number of ESS calls with Y Y
"bad" stat or RC
TRN1STCP decimal elapsed time from Y Y
schedule to first DLI call
(µs)
TRNCAPPL 8 characters CICS appl id Y Y
TRNFALST decimal false schedule elapsed (µs) Y Y
TRNXCKPC decimal number of sync points Y Y
TRNXCKPM decimal maximum locks held at Y Y

any one time
TRNXCKPT decimal total locks held Y Y
TRNEWLMC 128 hex characters WLM correlator Y
TRNOTCON YYYY-MM-DD IMS Connect start time Y Y

HH:MM:SS.uuuuuu UTC
TRNCSYS 8 characters z/OS system name for Y Y
CICS transaction
TRNOTSTC 8 characters IMS Connect job name Y Y
TRNOTIPT decimal input port number Y Y
TRNOTPRT decimal OTMA port number Y Y
TRNOTIP 8 hex characters client IP address Y Y
TRNOTCLN 8 characters OTMA client name Y Y
TRNOTUSR 8 characters OTMA user id Y Y
TRNOTSTF 2 hex characters OTMA state Y

(OMHDRIST)
TRNOTSYF 2 hex characters OTMA sync flag Y
(OMHDRSYN)


TRNOTSLF 2 hex characters OTMA sync level Y
(OMHDRSLV)
TRNOTCLF 2 hex characters OTMA client flag Y
(OMHDRCFL)
TRNOTSCF 2 hex characters OTMA security flag Y
(OMSECFLN)
TRNOTCOR 32 hex characters OTMA correlator Y
(OMSECFLN
TRNOTCLP 8 hex characters IMS Connect client port Y Y
TRN_MQMID 48 hex characters MQ correlation identifier Y Y

or
CSQ + QMGR name
+ timestamp
TRNOTEIP 8 hex characters Energizer for IMS Y Y
Connect IP address
TRNOVHD HH:MM:SS.uuuuuu region overhead CPU Y Y
TRN5GSP decimal HD get space IWAIT time Y Y

(microseconds)
DBD Segments, each comprising

DBTDBNAM 8 characters DBD name Y Y
DBTDBTYP 2 hex characters DBD type Y Y
DBTFLAG1 2 hex characters flags Y Y
DBTDMBSZ decimal total DMB space for this Y Y

DB
DBTGU decimal total GU calls to this Y Y

database
DBTGN decimal total GN calls to this Y Y
database
DBTISRT decimal total ISRT calls to this Y Y
database
DBTDLET decimal total DLET calls to this Y Y
database
DBTRIOTM decimal total read I/O time for the Y Y
transaction


DBTWIOTM decimal total write I/O time for the Y Y
transaction
DBTREPL decimal total REPL calls to this Y Y
database
DBTOTHER decimal total other calls to this Y Y
database
DBTKEYR decimal total key reads Y Y
DBTKEYW decimal total key writes Y Y
DBTNKEYR decimal total non key reads Y Y
DBTNKEYW decimal total non key writes Y Y
DBTNOI decimal # buffer hits Y Y
DBTBFSTK decimal # of non-key buffer steal Y Y

writes
DBTNOO decimal # of alters to an already Y Y
altered buffer
DBTBFSTN decimal # of key buffer steal writes Y Y
DBTCTLIO decimal I/Os in CTL or DLISAS Y Y
DBTDBVER decimal IMS database version Y Y

number
DB2 Segment, if present

DBTPLAN 8 characters plan name Y Y
DB2SEL decimal number of SELECT / Y Y

FETCH calls
DB2OPEN decimal number of OPEN calls Y Y
DB2ISRT decimal number of INSERT calls Y Y
DB2DEL decimal number of DELETE calls Y Y
DB2UPD decimal number of UPDATE calls Y Y
DB2DDL decimal number of CREATE / Y Y

DROP / ALTER /
COMMENT etc calls
DB2DYN decimal number of DYNAMIC Y Y
SQL calls
DB2CTRL decimal number of GRANT / Y Y
REVOKE calls


DB2OTHER decimal number of EXPLAIN / Y Y
LOCK / LABEL / CLOSE
calls
DB2SSID 4 characters subsystem name Y Y
MQ Segment, if present
MQGET decimal number of MQGET calls Y Y
MQPUT decimal number of MQPUT calls Y Y
MQPUT1 decimal number of MQPUT1 calls Y Y
MQSET decimal number of MQSET calls Y Y
MQOPEN decimal number of MQOPEN calls Y Y
MQCLOSE decimal number of MQCLOSE Y Y

calls
MQBACK decimal number of MQBACK calls Y Y
MQCMT decimal number of MQCMT calls Y Y
MQCONN decimal number of MQCONN calls Y Y
MQDISC decimal number of MQDISC calls Y Y
MQSSID 4 characters subsystem name Y Y
MQINQ decimal number of MQINQ Y Y
MQUNKN decimal number of unknown MQ Y Y

calls
(End of MQ Segment)
DATETIME YYYY-MM-DD Log record timestamp to Y Y Y
HH:MM:SS.xx+hhm 1/100th of a second, in
m UTC with offset to local
time
LOGRC_STCK YYYY-MM-DD Log record timestamp in Y Y Y
HH:MM:SS.uuuuuu UTC
LOGRC_SEQ decimal Log record sequence Y Y Y
number
Note that Ironstream does not currently format the FA record extension.

Messages Issued by IMS Log Records

Ironstream IMS Log-related messages are mainly in the SDF1200 range and are fully
described in “Ironstream Messages,” on page 27-1.


SECTION V Setting Up the Data Collection
Extension Data Types
This section provides instructions for setting up the Data Collection Extension (DCE)
parameters and its associated data types.
• “Configuring the DCE Parameters”
• “Setting Up USS File Collection”
• “Setting Up the RMF Data Forwarder”
Chapter 21 Configuring the DCE
Parameters
This chapter covers the global parameters required to activate the basic operation of
Ironstream’s Data Collection Extension (DCE), and the cluster parameters that define a
group of Ironstream systems to forward data to the same destination.
Topics:
• “Overview of DCE” on page 21-1
• “DCE Configuration Files” on page 21-2
• “Syntax for DCE Configuration Parameters” on page 21-5
• “Ironstream Forwarder Configuration Files” on page 21-5
Overview of DCE
The DCE is a component of Ironstream that provides extensions for collection of data from a
variety of sources. It currently provides support for offloading UNIX Systems Services (USS)
files and collecting Resource Measurement Facility (RMF) III metrics.
Each DCE instance has its own configuration file. These configuration files largely contain
system-level parameters; the detailed specification of RMF III metrics to be collected and
USS files and directories to be monitored are defined using IDT.
This chapter identifies the system level parameters that are common to both RMF III and
USS. You should read this chapter first.
• For details about configuring USS, see “Setting Up USS File Collection,” on page 22-1.
• For details about configuring RMF III, see “Setting Up the RMF Data Forwarder,” on
page 23-1.
DCE requires the availability of a Monoplex or Sysplex Cross System Coupling Facility
(XCF) service. For more information, see the MVS Programming: Sysplex Services Guide or
contact your system programmer.

Configuring the DCE Parameters
DCE Configuration Files

The DCE configuration file for each data source is divided into multiple sections. The first
section defines global DCE parameters and the second section defines XCF parameters. The
remainder of the configuration file is specific to the data source and is covered in subsequent
chapters. The best way to understand the first two sections is by looking at examples.
Figure 21-1 is for USS and Figure 21-2 is for RMF III.
Figure 21-1. Sample DCE Configuration for USS
*---------------------------------------------------------*
* Data Collection Extension for USS *
*---------------------------------------------------------*
Define Globals
InstanceName USS1
Maxthreads 64
*---------------------------------------------------------*
* Define Ironstream Clusters *
*---------------------------------------------------------*
Define IronstreamCluster ClusterU
*---------------------------------------------------------*
Figure 21-2. Sample DCE Configuration for RMF III
*---------------------------------------------------------*
* Data Collection Extension *
*---------------------------------------------------------*
Define Globals
InstanceName RMF1
Maxthreads 4
*---------------------------------------------------------*
* Define Ironstream Clusters *
*---------------------------------------------------------*
Define IronstreamCluster ClusterR
XCFGroup RMFXCFG1 XCFMember RMFXCFM1
*---------------------------------------------------------*
As you can see, the same parameters are specified in both examples, but there are some
differences in the parameter values.
The following sections describe the DCE parameters.
• “Global Parameters” on page 21-3
• “Ironstream Cluster Parameters” on page 21-3
• “Include Parameter Group” on page 21-4

Global Parameters
Global parameters follow the mandatory “Define Globals” statement that marks the start of
the global parameter group.
Define Globals
This statement marks the start of the Globals group of parameters; any
parameters that follow it up to the next Define statement or the end of the
configuration file are assumed to be Globals parameters. Parameters in this
group are:
InstanceName instance_name
The InstanceName parameter, which can be up to eight characters long, assigns a
unique name, instance_name, to each instance of DCE on an LPAR. This enables
you to run multiple DCEs in an LPAR should you wish to do so (although this is
not required even with multiple data sources going to multiple Ironstream
systems).
When you run multiple instances of DCE, the drop-down Ironstream menu
available from the Ironstream Desktop enables you to choose the instance for
which you want to access the various display panels.
MaxThreads nn
This parameter defines the maximum number of threads, nn, that can be active
at any one time and thereby determines the maximum number of concurrent
offloads. Any value from 1 to 64 may be specified and the default when this
parameter is omitted is 16.
You may have noticed in the sample configurations in Figure 21-1 and Figure 21-2 that USS
has a value of 64 for MaxThreads; whereas, it is 4 for RMF III. There are many reasons why
USS requires many more threads, largely related to the numbers and characteristics of the
files you are monitoring and parameters associated with tailing. This is explained in detail
in “Setting Up USS File Collection,” on page 22-1.
Ironstream Cluster Parameters

The “Define IronstreamCluster” statement marks the beginning of the group of parameters
that constitute a cluster. A cluster is a named group of Ironstream systems that are
forwarding data to the same destination.
Define IronstreamCluster cluster_name

This statement marks the start of the IronstreamCluster group of parameters;
any parameters that follow it up to the next Define statement or the end of the
configuration file are assumed to be IronstreamCluster parameters. Each cluster
definition can have one or several Ironstream systems defined within it.
The defined cluster name, which may be up to 8 characters long, is used as the
target for offloaded data rather than a specific Ironstream system. This enables
DCE to use any alternative systems as backup should the primary target
Ironstream system become unavailable.

XCFGroup XCF_groupname XCFMember XCF_membername

This parameter defines the XCF group and member name(s) of a target
Ironstream system to which you want to offload data. A maximum of 16 target
Ironstream systems may be specified for a single cluster.
It follows that the names defined here will have matching XCFGROUP and
XCFMEMBER parameters defined for a data source of XCF in the defined target
Ironstream system(s). When a second or subsequent XCF group and member
definition is provided, DCE uses them in sequence only when the preceding
system defined in the list becomes unavailable.
XCF_groupname must be a maximum eight characters long; valid characters are
A-Z, 0-9, $, # and @. To avoid using the names IBM uses for its XCF groups, do not
begin group names with the letters A through I or the character string SYS. Also,
do not use the name UNDESIG, which is reserved.
XCF_membername must be a maximum eight characters long; valid characters
are A-Z, 0-9, $, # and @.
The fact that USS has multiple XCF forwarders is no coincidence either and again is related
to your USS file characteristics and data volumes. A single forwarder should be adequate for
RMF III.
Include Parameter Group

Although it is possible to specify all of your DCE parameters in a single configuration file, it
may help to split them up into logical groups for ease of maintenance.
During initialization, DCE processes the member referred to on the CONFIG parameter in
the DCE procedure first; this will be in the data set defined by the DCEPARM DD
statement. The default name for this member is DCEPARM.
By using Include parameters in the member specified by the DCEPARM DD statement, you
can process other parameter groups. Any such included members are processed in the
sequence in which they are encountered in DCEPARM.
The Include parameter group comprises one or more Include parameters:
Include member_name
This optional parameter enables you to combine sets of DCE parameters from
other configuration members in the same data set as the primary configuration
member. You can specify as many Include parameters as required.
For example, if you create member DCEUSS with just the USS global and XCF
parameters and specify this as the member name in the DCE USS started task.
In the same input library, you could create member USSDFLTS with the USS
default parameters and add the statement INCLUDE USSDFLTS in member
DCEUSS.

Syntax for DCE Configuration Parameters

The records in the DCE configuration file must conform to the following rules:
• Only one parameter is allowed on each line and can start in any position on that line.
• Parameters and any keywords must be specified in full and are not case sensitive.
• A line with an asterisk * in the first position is treated as a comment.
• DCE parameters support standard z/OS ampersand-prefixed (&) variables; examples:
&SYSNAME, &SYSCLONE.
• A parameter marked in the text as mandatory must be supplied; an error message will
be issued if it is omitted.
• Optional parameters can be omitted and a default is normally assumed when they are.
The default value for optional parameters are described in the text.
Ironstream Forwarder Configuration Files

The USS and RMF data types must have their own Ironstream forwarder task(s).
Figure 21-3 is the USS configuration file that corresponds to the first forwarder defined in
the USS DCE configuration file shown in Figure 21-1.
Figure 21-3. Sample USS Data Type Configuration File
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"USS1"
"SOURCE"
"DESTINATION"
"INDEX":"your_USS_index"
"TYPE":"TCP"
"IPADDRESS":"xxx.xxx.xxx.xxx"
"PORT":"nnnnn"
"SSL":"NO"
"SOURCE"
"DATATYPE":"XCF"
"XCFGROUP":"USSXCFG1"
"XCFMEMBER":"USSXCFM1"
There needs to be a separate forwarder started task for each XCF member defined in
Figure 21-1. The only differences in the configuration file for the other two forwarder tasks
are in the NAME and XCFMEMBER parameters. Note that there is no relationship between
the SYSTEM NAME defined in the forwarder and the InstanceName defined in DCE, but
each forwarder NAME must be unique within an LPAR

Figure 21-4. Sample RMF Data Type Configuration File
"KEYS"
"KEY":"0123456789ABCDEF"
"SYSTEM"
"NAME":"RMF1"
"SOURCE"
"DESTINATION"
"INDEX":"your_RMF_index"
"TYPE":"TCP"
"IPADDRESS":"xxx.xxx.xxx.xxx"
"PORT":"nnnnn"
"SSL":"NO"
"SOURCE"
"DATATYPE":"XCF"

Chapter 22 Setting Up USS File Collection
This chapter describes how to configure DCE to monitor and offload Unix System Services
(USS) files to Ironstream.
Topics:
• “Overview of USS File Collection” on page 22-1
• “Summary of DCE’s USS Offload Functions” on page 22-4
• “Configuring DCE for USS File Offload” on page 22-4
• “Duplicate USS File Detection” on page 22-12
• “USS File Tailing Process” on page 22-13
• “Dynamically Modifying USS Processing” on page 22-14
Overview of USS File Collection

USS files can be offloaded to Ironstream using the USS File Collection component of DCE.
Because of the disparate nature of the data they collect, you must have separate DCE
instances for the USS and RMF data types, each with its own configuration file. For
instructions on running a USS-only DCE instance, see “Controlling the Data Collection
Extension (DCE)” on page 8-4.
Adjust File Monitoring and Offloading

You use a simple configuration file to define USS directories to be scanned at a specified
interval; this interval may be different for each directory. A directory may be scanned at the
top level only, or you can configure DCE to process all subdirectories defined in the specified
head directory.
The configuration file enables you to override the Splunk metadata “source” and
“sourcetype” fields for offloaded USS data. You can also override the Splunk index specified
in the Ironstream configuration file and offload USS files to another Splunk index at the

Setting Up USS File Collection
Defaults group level. The offloaded data can be split further by specifying other Splunk
indexes at the Directory group level.
During the scanning process DCE looks for files that are eligible for offloading to Ironstream
according to filters that you define. A filter may select a specific file or it can be generic and
so select multiple files. Once a file has been selected it is offloaded to a defined Ironstream
system. Provision is made for defining one or more backup Ironstream systems so if the
primary target Ironstream is unavailable, then files can be offloaded to a backup.
Scan for Duplicate Files

DCE has a duplicate USS file detection process so if a file is copied to a new name, DCE
prevents the new file being unnecessarily offloaded. For more information, see “Duplicate
USS File Detection” on page 22-12.
Tail Volatile Files

DCE also provides a facility whereby volatile files can be more frequently monitored for new
data than at the normal directory scanning interval. This is done by a process called ‘tailing’
and provides a more efficient way of processing a selected file and offloading the data to
Ironstream. For more information, see “USS File Tailing Process” on page 22-13.
Dynamic Administration of USS Processing Using IDT

The Ironstream Desktop (IDT) component provides GUI panels for dynamically modifying
USS processing. The IDT panels provide administrative options to make changes to the USS
defaults, filters, and directories. There is also a USS Files Status panel that enables you to
monitor the status of USS file offloads in real-time. For more information, see “Dynamically
Modifying USS Processing” on page 22-14.
Flexible Start Types

The provision of three different start types provides flexibility in both configuration and USS
file offload processing. The default start type is a ‘Hot’ start. This processes the complete
configuration that is saved to HFS each time changes are applied from the DCE panels
displayed in the IDT and also continues offload processing exactly where it was left.
A ‘Warm’ start differs from a Hot start only in that it ignores changes made from the DCE
panels in the IDT. This means that the configuration settings only reflect the parameters
defined in the z/OS configuration member.
Finally, a ‘Cold’ start processes the configuration from the z/OS member but disregards all
previous offload activity so every eligible file is offloaded for Ironstream for forwarding to
Splunk even if it has previously been offloaded.
For more information, see “Starting DCE” on page 8-4.

USS File Offload Operational Diagram

Figure 22-1 gives an overall view of the way in which DCE handles USS file offloading:
Figure 22-1. Ironstream USS File Offload Operational Diagram

Summary of DCE’s USS Offload Functions

In summary, the primary functions of the USS offload feature of DCE is to:
• Offload selected USS files to Ironstream.
• Define Splunk “Source” and “Sourcetype” metadata.
• Offload files to separate Splunk index(es) at the Defaults group and Directory group
level.
• Offload (only) new data added to a file that has already been offloaded.
• Offload (only) new data added to the end of a volatile file without closing/opening the file
(‘tailing’).
• Offload a ‘replaced’ file.
• Prevent copied files from being offloaded (again).
• Provide online panels via the Ironstream Desktop for dynamic parameter updates.
Once a USS file has been offloaded to Ironstream it will be forwarded to Splunk in the usual
way.
Configuring DCE for USS File Offload

Overview
This section covers the parameters that are required in the DCE configuration to set up USS
file offloading. Parameters are required to define the overall defaults for USS file offload (the
USSDefaults group), the filters to be applied to the scanned USS directories (the USSFilters
group) and the directories that are to be scanned for eligible files to offload (the
USSDirectory group).
The syntax of the USS-related parameters is identical to that of the Global parameters; see
the section “Syntax for DCE Configuration Parameters” on page 21-5.

USS Defaults Parameters

The parameters in the USS Defaults group define default values used for offloading files. All
of the defaults specified in this group can be overridden at the USS directory level.
Define USSDefaults
This statement marks the start of the USS Defaults group of parameters; any
configuration file are assumed to be USS Defaults parameters. Parameters in this
group are:
Source syncsort | source_name

The optional Source parameter sets the Splunk “source” metadata field to the
specified path or filename of the USS files. This is applied to all defined USS
directories when no other Source name is specified at the directory level. When
this parameter is omitted the default is “syncsort”.
The name can have “FILENAME” or “PATHNAME” values, and it can also be
abbreviated using “f”, “file”, or “filename”. This indicates that the Source
metadata should identify the file by either just its filename or by its full
path/filename.
Sourcetype syncsortMF | sourcetype_name

The optional Sourcetype parameter sets the Splunk “sourcetype” metadata field
for the USS files. This is applied to all defined USS directories when no other
Sourcetype name is specified at the directory level. This value overrides the
Sourcetype value set in the Ironstream configuration file (e.g., “log4j”).
The name can be any character string value up to 60 characters (no blanks).
When this parameter is omitted the default is “syncsortMF”.
Index index_name
The required Index parameter specifies the name of the Splunk index where you
want to offload data from USS directories. In order for DCE USS to start, you
must specify the Splunk index specified in the Ironstream XCF data type
configuration that is paired with the Ironstream forwarder for USS, or you must
specify a different Splunk index that will override the Ironstream XCF
configuration. The index specified here can also be overridden if another Splunk
index is specified at the directory level.
Tip! Since you can specify the same directory more than once, and apply different
filters so that different files are selected, it’s possible to have different files in the
same directory that are given different Splunk Source and Sourcetype metadata
and which are also sent to different Splunk indexes.

Filter filter_name
The Filter parameter specifies the name, filter_name, that is applied to all defined
USS directories when no other filter name is specified at the directory level (see
“Define USSFilter filter_name” on page 22-8). The name can be a maximum of 23
bytes long. A filter name of AllFiles can be specified, which is a default filter
provided in DCE USS and which uses a mask of *.
Important! There is no default when this parameter is omitted, which means
that a filter name must be specified at the USS directory level, otherwise no files
will be selected for offload.
ScanFrequency 300 | nnn

The ScanFrequency parameter specifies the interval in seconds from 1 to 3600 at
which DCE scans all defined USS directories applying the specified or defaulted
filter criteria and selecting files for offload when the criteria match. The default
when this parameter is omitted is 300 seconds.
Tailing No | Yes
The Tailing parameter specifies whether to use file tailing. The default is No,
which means no tailing is performed, in which case the values in TailingDelay
and TailingWait are ignored.
The Tailing, TailingDelay, and TailingWait parameters together define DCE’s
Tailing feature, as described in “USS File Tailing Process” on page 22-13.
TailingDelay 60 | nn
The TailingDelay parameter specifies the total number of seconds between 1 and
600 that DCE waits once a USS file offload is complete (end-of-file has been
detected) to check whether more data has been appended to the file. The default
when this parameter is omitted is 60 seconds.
The number of times the check is made during this period is determined by the
TailingWait parameter described next. The TailingDelay value would normally be
a multiple of the TailingWait value.
If additional records are added to a file within the TailingDelay period these are
offloaded to Ironstream without a file close/open being performed. This process is
repeated until the TailingDelay period expires without further records being
added to the file, at which point the file is closed and will be rescanned as usual
when the ScanFrequency interval next expires.
TailingWait 15 | nn
Once the tailing process starts for an offloaded file, the check for additional
records being added is made at the expiry of each TailingWait interval. The
TailingWait value is a number of seconds between 1 and 600 and should be less
than the TailingDelay value. Normally the TailingDelay value would be a
multiple of the value specified for this parameter.

ChecksumLength 1024 | nnnnn

DCE uses an encryption algorithm to detect duplicate files and the
ChecksumLength parameter specifies the number of bytes from 128–4096 used by
this algorithm. When this parameter is omitted, the default is 1024 bytes which
provides a reasonable balance between CPU usage and percentage of duplicate
files detected. DCE will detect close to 100% of duplicate files using the default
value.
You would only need to increase this value above the default if you noticed that
duplicates were occasionally being offloaded to Ironstream and forwarded on to
Splunk. See the section “Duplicate USS File Detection” on page 22-12 for further
information on duplicate file detection.
If you are primarily using DCE to offload, say, log files where there is a unique
date and time stamp at the start of each record, you could usefully save a little
CPU by reducing the value of this parameter since a duplicate file would be
detected within a few tens of bytes.
StatusHistory 30 | nnn
This parameter specifies the default number of days between 1 and 365 for which
DCE retains status information for offloaded files. When this parameter is
omitted the default is 30 days.
This parameter is relevant to the Duplicate File Detection feature of DCE since it
means that a duplicate can still be detected if the original file from which the copy
was made is deleted from the directory. Once the period of days specified here is
passed the status information is lost and the duplicate can no longer be detected.
See the section “Duplicate USS File Detection” on page 22-12 for further
information.
Encoding AUTO | ASCII | EBCDIC

The Encoding parameter specifies the default data encoding of USS files that are
selected for offload. The default is AUTO which means that DCE will check the
initial sample of 256 chars (or the complete file if smaller) for valid ASCII codes,
and if they are not all ASCII codes, then DCE will set them to EBCDIC.
Alternatively you can specify the default as either ASCII or EBCDIC. You can
always override the value specified here at the individual USS directory level if
required.
Recursive No | Yes
The Recursive parameter specifies whether DCE searches all subdirectories of a
defined USS directory (see “USS Directory Parameters” on page 22-10) when
scanning for matching files. Files are selected for offload when they match the
criteria specified in the defined or default filter name.
The default when this parameter is omitted is ‘No’ so only the single specified
directory is scanned by default. To scan all subdirectories, specify ‘Yes’ for this
parameter.

TargetCluster cluster_name
The TargetCluster parameter specifies the name of the Ironstream cluster to
which USS file data will be offloaded. See the section “Ironstream Cluster
Parameters” on page 21-3 for a description of the Cluster parameter group.
There is no default assumed when this parameter is omitted; in this event you
must specify the TargetCluster parameter for each USSDirectory parameter
group, see “USS Directory Parameters” on page 22-10.
Here is a sample USS Defaults group definition:
Define USSDefaults
Source PATHNAME
Sourcetype USSFile
Index usslogs
Filter AllFiles
ScanFrequency 120
Tailing Yes
TailingDelay 30
TailingWait 1
ChecksumLength 1024
StatusHistory 60
Encoding AUTO
Recursive Yes
TargetCluster Cluster1
USS Filter Parameters

The USS Filter parameter group enables you to define a named set of USS filename filters
which can be applied to a directory by DCE’s File Scanner. Filters can both include and
exclude files so you can easily include all files in a directory while excluding just a few. Only
when a file in a defined directory, or subdirectory when the recursive option is being used,
matches the specified filters will it be selected for offload.
Using named filter groups enables you to use the same set of filters on multiple directories
without having to redefine the same set of filters each time. For additional information on
filtering, see the section “Notes on USS File Filtering” on page 22-9.
Define USSFilter filter_name

This statement marks the start of the USS Filter group of parameters; any
configuration file are assumed to be USS Filter parameters. The specified
filter_name can be used on the Filter parameter in the USS Defaults group
(page 5), and on any of the directories defined by the USSDirectory group

(page 10). The name can be a maximum of 23 bytes long. A filter name of AllFiles
should not be specified because this is a default filter provided in DCE USS,
which uses a mask of *.
IncludeFile file_name | file_mask

The IncludeFile parameter specifies the name of a file to include for offload. You
can define a specific file_name, or use the wildcard character ‘*’ to mean ‘any
number of any character’ or ‘?’ to mean any one of any character, to define a
file_mask that will include any files matching the mask. When using masking,
the mask character(s) can be specified in both the filename and file extension if
required.
ExcludeFile file_name | file_mask

The ExcludeFile parameter specifies the name of a file to exclude from the offload
process. In the same way as for the IncludeFile parameter, you can define a
specific file_name, or use the wildcard character ‘*’ to mean ‘any number of any
character’ or ‘?’ to mean any one of any character, to define a file_mask that will
exclude any files matching the mask. When using masking, the mask character(s)
can be specified in both the filename and file extension if required.
Notes on USS File Filtering

Filters are processed in the sequence in which they are specified in the configuration file and
filter processing for a file stops when the first matching ExcludeFile specification is detected.
For example, if you were to include all files using the mask ‘*.log’ you could then use
ExcludeFile parameters afterwards to exclude log files for users/applications whose logs you
did not want forwarding to Splunk.
By default, DCE’s filtering excludes files in a directory that is processed because it matches a
USSDirectory parameter. It is therefore your responsibility to specify appropriate
IncludeFile statements to ensure that any required files are offloaded to Ironstream for
forwarding to Splunk.
Here are some sample USS Filter group definitions:
Define USSFilter Selected_Files
IncludeFile *.log
IncludeFile *.error*
IncludeFile *.xml
ExcludeFile IBMUSER*
ExcludeFile TEST*
Define USSFilter SyslogD
IncludeFile plx1.syslog.log
IncludeFile plx2.syslog.log

USS Directory Parameters

The USS Directory group of parameters defines a directory that DCE will scan for files that
are eligible for offload. Any filtering applied to the directory by a Filter parameter, either at
the default or USSDirectory level is taken into account when selecting files for offload.
The only mandatory parameter is the Define itself which provides the name of a directory to
be scanned. The remaining available parameters are listed in Figure 22-5.
Define USSDirectory directory_name

This statement marks the start of the USS Directory group of parameters; any
configuration file are assumed to be USS Directory parameters.
• Specify the full directory_name ensuring no trailing oblique is added.
• The directory_name accommodates long directory path names, with a maximum
length of 255 characters. You can use a free-format syntax to split long path
names over multiple lines, as shown in Figure 22-4.
• The directory_name can accommodate spaces and most special characters in the
directory name. Note that the left-right angle bracket characters < > cannot be
used in a directory name. This is achieved by using both a single and double
quote as a delimiter when specifying the path name, as shown in Figure 22-5.
• Parameters in this group are exactly the same as those specified in the
USSDefaults group. Parameters set at the directory level override any default
value either set or assumed.
Figure 22-2. Available USS Directory Parameters
The available parameters are shown here for completeness only. For a full description, see
the section “USS Defaults Parameters” on page 22-5.
Filter filter_name
Source File | Path | Default
Sourcetype sourcetype_name | syncsortMF
Index index_name
ScanFrequency 300 | nnn
Tailing No | Yes
TailingDelay 60 | nn
TailingWait 60 | nn
ChecksumLength 1024 | nnnnn
StatusHistory 30 | nnn
Encoding AUTO | ASCII | EBCDIC

Recursive No | Yes
Figure 22-3. Examples of Typical USS Directory Group Parameters
Here are some typical USS Directory group examples:
Define USSDirectory /sync1/syslogd
Filter SyslogDFilter
Define USSDirectory /sync1/samples/log4j
Filter Log4jFilter
Define USSDirectory /etc
Recursive Yes
TailingDelay 5
ScanFrequency 1800
Define USSDirectory /sync1/support/syslog.log
Source PATHNAME
Sourcetype USSFile
Index usslogsdir1
Figure 22-4. Example of USS Directory Name Using a Long Path
This “Define USS Directory” statement example uses a long path name based on this long
directory path name:
/sync1/support/plx3/zen/user/zenplx3/ZENV21/registry/ZenUserSettings
Define USSDirectory /sync1
/support/plx3/zen/user
/zenplx3/ZENV21
/registry/ZenUserSettings
Filter SyslogDFilter
The path syntax is free-format but it must be broken between directory boundaries and each
line must be restarted with a forward slash character. The path must start on the
USSDirectory line and has a maximum length of 255 characters.

Figure 22-5. Example of USS Directory Name Using Special Characters
This directory path example uses a period as a special character, using both single and
double quotes as delimiters.
Define USSDirectory '/syncsort/dev'
'/my documents'
‘/myuser”’
“’/.help”
This directory path name would be interpreted as:

/syncsort/dev/my documents/myuser"'/.help
Duplicate USS File Detection

Overview
DCE automatically caters for duplicate USS files, ensuring that data is not needlessly
offloaded and forwarded to Splunk. For example, suppose USS file ‘mylog.log’ had already
been forwarded to Splunk and was then copied to ‘mylog.saved.log’ either in the same or a
different (but still eligible for scanning) directory. In this situation, provided the new file
passed any specified filtering it would also be eligible for offload. You would not want this to
occur, however, since the data would then be duplicated in Splunk.
DCE caters for this by automatically handling the scenario where, although the filenames
may be different, the content of the files is the same. Two parameters are relevant to this
process, ChecksumLength and StatusHistory which are available in both the USSDefaults
and USSDirectory parameter group.
How Duplicate USS File Detection Works

The duplicate USS file detection process works by reading a segment of a file once it has
been selected for offload and using an encryption algorithm on the data. The number of bytes
it reads from the file is specified on the ChecksumLength parameter which defaults to 1024
bytes when it is omitted. The outcome of the algorithm along with several other fields are
saved into DCE’s registry (in zFS/HFS) where they will persist for the number of days
specified by the StatusHistory parameter. During this period, even if the original file from
which the copy was made is deleted, DCE will be able to detect any copy as a duplicate and
refrain from offloading it again.
Modifying the Duplicate File Detection Behavior

The number of bytes specified by the ChecksumLength parameter can be adjusted according
to the types of file in the directory being processed. For example, it would not be efficient to
process 1024 bytes of data from each file selected in a directory if you know that the first 50

bytes of every file will always be enough to uniquely identify it. In this case it would be
advantageous to reduce the ChecksumLength parameter to 50 since there would be a (small)
reduction in CPU usage. On the other hand, if you notice that one or two files pass the
duplicate file check and are forwarded to Splunk when they ought not to have been, then you
could usefully increase the value specified for ChecksumLength. Be aware that this will
cause an (again small) increase in CPU used by the algorithm but will help to prevent
duplicate files being forwarded.
USS File Tailing Process

Tailing is a process that forwards new records that are added to monitored files, based on
the parameters TailingDelay and TailingWait, and can make the offload process for volatile
USS files more efficient. File tailing can be configured in both the USSDefaults and
USSDirectory parameter group.
How It Works
When a USS file is selected for offload, DCE reads the data from the file and offloads it to
Ironstream for forwarding to Splunk. If tailing is enabled, when end-of-file (EOF) is
detected, rather than closing the file and waiting for the scanning interval to pass and then
re-opening the file and checking for additional data, DCE waits for the interval defined by
the TailingDelay parameter (this parameter defaults to 60 seconds if it is omitted and may
be specified in both the USSDefaults and USSDirectory parameter group).
During this wait period, DCE will perform a number of checks to see whether more data has
been appended to the file according to the value specified for the TailingWait parameter. For
example, if the default values are used there will be four such checks since the TailingDelay
default is 60 (seconds) and the TailingWait value is 15 (seconds). At each check, if DCE finds
that there has been more data appended it is offloaded immediately after which DCE again
waits for the specified tailing wait period. This process repeats until the tailing delay expires
without any additional data being offloaded.
Only if the time specified by the TailingDelay parameter expires without any new data being
appended to the file will it be closed and DCE will then wait until the expiry of the defined
directory scanning interval (which would normally be longer than the tailing delay period)
before opening and checking the file again.
Tailing Volatile Files

For a volatile file to which data is being frequently appended, this can mean that the file is
being continually offloaded at the tailing wait interval rather than at the scanning interval.
This in turn means that the processing thread associated with the file offload will also be
continually active.
This effect should be taken into consideration when defining the MaxThreads parameter
value in the Global parameter group. By default, the value assigned for MaxThreads is 16,
which means that sixteen file offloads can take place simultaneously. However, if DCE is
managing many highly-volatile files that are in a continual state of offload, it could mean

that most of those threads would be in continuous use, thereby leaving few threads for other
file offloads. In this situation it may be advisable to increase the value of MaxThreads.
Dynamically Modifying USS Processing

Overview
To modify USS processing dynamically, you can use the online panels available from the
Ironstream Desktop (IDT(). As well as providing Administrative options to make changes to
the USS defaults, filters and directories, there is also a USS Files Status panel that enables
you to monitor the status of USS file offloads in real-time.
Accessing the Ironstream Desktop USS panels

After signing on to IDT using your usual RACF user ID and password you will see an
Ironstream item in the menu bar. The full list of items that appears in the menu bar
depend on the components you are running.
Panel 22-1 illustrates a system that is running just Ironstream:
Panel 22-1: Ironstream Desktop Menu Bar
Displaying the USS Files Status Panel

To access the Ironstream ‘Managed Files Status’ panel, click the Ironstream menu. This
will show each of your Ironstream clusters; Panel 22-2 shows just one target cluster:
Panel 22-2: Accessing the USS File Status

Clicking the USS File Status item invokes the USS File Status panel. This provides an
overall view of the USS files that have been selected for offload to the selected Ironstream
cluster according to your filtering definitions. Panel 22-3 is a (partial) example:
Panel 22-3: USS File Status

As with all desktop panels, detailed online help is available that describes the purpose of the
panel and all the fields, icons and buttons it displays. To access the help, click the icon in
the top left corner of the panel.
Dynamically Modifying USS Settings

Panels are available via the Admin drop-down menu to modify current settings and add new
Directory and Filter definitions. The Admin submenu options are:
• USS Defaults
• USS Directories
• USS Filters

Selecting USS Defaults enables you to view the current default settings and adjust the
maximum number of threads for concurrent USS file offloads.:
Panel 22-4: USS Defaults

Selecting USS Directories displays the currently defined USS directories:
Panel 22-5: USS Directories

From this panel you can access and modify the filter settings for each directory.

Clicking the Edit Directory icon opens the Directory Scan Attributes panel for the
selected directory. This panel displays the directory scan values for offloading files that are
set at the USSDefault level for all directories:
Panel 22-6: Directory Scan Attributes

From this panel you can modify the file offload settings for the selected directory.
For descriptions of these attributes, see “USS Defaults Parameters” on page 22-5.

Selecting USS Filters displays the currently defined filters and enables you to modify and
delete them. Panel 22-7 shows a (partial) example:
Panel 22-7: USS Filters

All of the Admin panels have additional functions available, some of which invoke other
Admin panels. This section is only an introduction to the panels and some of the facilities
available. We recommend that you spend a little time trying out the USS panels since they
provide a more dynamic and elegant method of updating the current configuration than
editing the z/OS configuration and restarting DCE.

Chapter 23 Setting Up the RMF Data
Forwarder
This chapter describes how to configure the RMF Data Forwarder to collect Resource
Measurement Facility III system performance and utilization data.
Topics:
• “Overview of the RMF Data Forwarder” on page 23-1
• “Configuring the RMF Data Forwarder” on page 23-2
• “Configuring DCE RMF Parameters” on page 23-2
• “Defining Security Settings” on page 23-5
• “Setting the RMF Filters in IDT” on page 23-6
• “Sample Scenario for Setting RMF Filters” on page 23-10
Overview of the RMF Data Forwarder

Ironstream can collect RMF III system performance and utilization data in real time to help
prevent potential bottlenecks and performance delays.
Using the RMF Data Forwarder component of DCE, Ironstream calls the RMF Distributed
Data Server (DDS) function to gather sysplex-wide performance data from a single data
server on one system in the sysplex. A simple configuration file defines the DDS HTTP
socket and the Ironstream cluster, and controls the frequency that data retrieved is from
DDS.
The Ironstream Desktop component can be used to configure and monitor the RMF Data
Forwarder, and to control the filtering of RMF fields, as described in “Setting the RMF
Filters in IDT” on page 23-6.

Setting Up the RMF Data Forwarder
Configuring the RMF Data Forwarder

Due to the disparate nature of the data they collect, you must have separate DCE instances
for the USS and RMF data types, each with its own configuration file. For instructions on
running an RMF-only DCE instance, see “Controlling the Data Collection Extension (DCE)”
on page 8-4.
Member CFGRMF is created by the Configurator Tool. This contains a definition for RMF
Data Forwarder parameters, as illustrated in Figure 23-1.
Figure 23-1. Sample Configuration for RMF Data Type
"KEYS¨
"KEY":"0123456789ABCDEF"
"SYSTEM¨
"NAME":"RMF1"
"DESTINATION¨
"INDEX":"xhrmf"
"TYPE":"TCP"
"IPADDRESS":"nnn.nnn.nnn.nnn"
"PORT":"nnnnn"
"SSL":"NO"
"SOURCE¨
"DATATYPE":"XCF"
The Configurator Tool creates RMF forwarder JCL in the member you specified as the RMF
forwarder STC name.
Configuring DCE RMF Parameters

Member DCERMF created by the Configuration Tool has a combination of the DCE RMF
default parameters and the values you specified during configuration. These values are used
to control the filtering of RMF fields.
There are three sets of DCE RMF parameters:
• Global parameters
• Ironstream Cluster parameters
• RMF parameters
The values for the first two sets are based on values you specified during configuration and
should not need to be changed. The values in the third set determine require some
consideration and are explained next.

Define RMFSettings
The parameters in the RMFSettings group define values used to configure and monitor the
RMF Data Forwarder, and to control the filtering of RMF fields.
Define RMFSettings
This statement marks the start of the RMFSettings group of parameters; any
parameters that follow it up to the next Define statement, or the end of the
configuration file, are assumed to be RMFSettings parameters. Parameters in
this group are:
IPAddress ipaddress
This mandatory parameter specifies the IPv4 address (up to 15 characters) of the
RMF Distributed Data Server (DDS).
Port port
This mandatory parameter specifies the HTTP_PORT used by the RMF
Distributed Data Server (DDS).
Userid userid
This is an SAF user ID that has the required access to RMF DDS performance
data.
ScanFrequency frequency
This optional parameter specifies how often, in seconds, the RMF server is to be
contacted for retrieval of data.
A value between 5–3600 can be specified. The default is 60.
DefaultSelection Off | On
This parameter specifies whether on a COLD start all resources are selected (On)
for collection or none are selected (Off). The default is Off.
MetricSelection Off | On
This parameter specifies whether on a COLD start all metrics are selected (On)
for collection or none are selected (Off). The default is Off.
MaxNumMetrics max_value
This parameter specifies the maximum number of entries when requesting metric
data results from the RMF DDS. This is also known as the number of list
elements. Where there are multiple entries in a resource list, then only the first
max_value metrics with the highest values will be forwarded. Some metrics are
single items, while some metrics have multiple items.
A value between 1–1000 can be specified. The default is 20.
For example, MaxNumMetrics=250 means that if metric_id has multiple items,
then only the first (largest-valued) 250 are to be sent: metric_id_R0001 to

metric_id_R0250. If there are more entries in the list with lower values, then they
will be ignored.
Note: When the maximum XCF record size is exceeded, message SDF0507S will
be issued. Reducing the MaxNumMetrics value is a simple mechanism to
potentially eliminate SDF0507S messages.
The TargetCluster parameter specifies the name of the Ironstream cluster to
which RMF file data is offloaded.
DataFormat format
This optional parameter specifies the format of the data transmitted to
Ironstream, and hence, to a destination. The format can be JSON or XML. The
default is JSON.
Here is a sample RMF Data Forwarder settings definition member:
Define RMFSettings
IPAddress 192.168.61.25
Port 8803
UserID rmfuser
ScanFrequency 120
DefaultSelection Off
MetricSelection Off
MaxNumMetrics 30
TargetCluster SDFRMF
DataFormat JSON
Setting the ScanFrequency

Consider the collection interval carefully. The IBM default collection interval for type 70
SMF records is 15 minutes and if you are filtering a small subset of fields, then a shorter
interval may be more appropriate. The combination of the number of filtered fields and
collection interval affects the cost of forwarding and the volume of data forwarded to a
destination.

Defining Security Settings

The first time you start the Ironstream DCE task, the following message is issued every
minute:
DCE0150I RMF Collection suspended due to incomplete security settings
This means that no RACF userid and password has been provided for the DCE RMF
collector. To define RACF credentials for the RMF collector, follow these steps:
1. Activate the Ironstream Desktop browser. (See “Controlling the Ironstream Desktop
(IDT)” on page 8-3.)
2. On the Admin menu, select your Ironstream-instance, and then click RMF Security
on the submenu.
The Update RMF Collection Settings window is displayed:
Panel 23-1: Update RMF Collection Settings

3. Enter the following RMF settings:
▪ IP Address and Port – The IP address and port number of your RMF DDS.
▪ UserID – A valid RACF user ID.
Tip: Syncsort recommends that the RMF user ID should be a generic user ID that is
defined to RACF (or other security system) rather than the ID of a specific Iron-
stream user who is typically subjected to mandatory password expirations that
require a change. If possible, the generic ID used for RMF access should not have a
frequent password expiration.
4. Click the Generate New Passcode button to generate a password for the user ID. This
displays a Password field in place of the button.
5. Specify the password in the Password field and click Save.
The password is stored in encrypted format. DCE starts collecting RMF data
immediately after you save the security settings, subject to the filtering that you define.
The following messages in the DCE started task SYSPRINT indicate that RMF data is
being collected:
DCE0152I RMF Discovery started

DCE0154I Connected to RMF Server IP ipaddr Port nnnn Socket 0

Changing the RMF User ID or Password

In the event that it is necessary to change the userid and/or password combination specified,
you need to log into IDT and modify the Update RMF Collection Settings. For example, if
the userid/password is not valid or has expired, then DCE RMF will issue message
“DCE0150I - RMF Collection suspended due to incomplete settings”, and wait for a password
to be created in IDT or a request to shut down.
Note that any change to user ID or password will require a DCE RMF restart for these
changes to take effect.
1. Open the Update RMF Collection Settings window as described in steps 1-2 of
“Defining Security Settings” on page 23-5.
2. Click the Generate New Passcode button. This displays a Password field in place of
the button.
3. If necessary, update the RMF user in the UserID field.
4. Specify the new password in the Password field.
5. Click Save. The password is stored in encrypted format.
6. Restart DCE RMF with a WARM start, as described in “Starting DCE” on page 8-4.
For example: S sdfDCE,RMF=WARM
Note: For instructions on fine-tuning authorization to access to specific IDT-controlled
operations, see “Controlling Authority Levels within IDT” on page 6-17. For example, you
might want some users to generate SMF record filters, but you may not want them to be able
to change RMF III or USS definitions.
Setting the RMF Filters in IDT

Use the Ironstream Desktop (IDT) to set RMF filters for resource selection and metric
selection for each resource.
1. Activate the Ironstream Desktop browser.
2. On the Admin menu, select your Ironstream-instance, and then click RMF Filters
on the submenu.
The RMF Filters panel is displayed. DCE automatically builds this panel using data
provided by the RMF DDS so it displays resource elements that are specific to your
environment.
For more information about RMF, refer to IBM’s Resource Management Facility
Programmer’s Guide for your version of z/OS, “Chapter 3 Accessing performance data using
the RMF Distributed Data Server”.
About the RMF Filters Panel

The panel is organized in the form of a resource tree that reflects the RMF resource model
with the Sysplex as the top-level element and all other elements being children or
grandchildren of the Sysplex.

There are four main categories of metrics available:

• Sysplex Metrics – All LPARs in a cluster.
• MVS Image Metrics – The operating system of each LPAR.
• MVS Image Attributes – Enclaves of each LPAR.
• CPC and CF Metrics – The Central Processing Complex and the Coupling Facility.
Panel 23-2 illustrates the RMF Filters display panel with Processor metrics selected:
Panel 23-2: RMF Filters Panel

Table 23-1 describes the controls available on the RMF Filter panel:
Table 23-1: RMF Filters Panel Controls

The Update action buttons are used to access the RMF
Elements and RMF Metrics panels. Each button enables
you to display the associated list of resource elements or
metrics and selectively activate/deactivate data collection as
required.
The Refresh action button activates changes. Changes take
effect immediately
Switch icons allow you to selectively activate/deactivate
collection for elements at each level. For example, you can
deactivate collection for All Volumes even if data is being
collected for other elements in the I/O Subsystem group.
You can also deactivate collection for All Volumes even if
metrics are being collected at the individual volume level.
The switch icons in the panel’s heading line allow you to
deactivate or deactivate collection for all selected resources
with a single click
Caution: The panel heading line switch icons can be
regarded as a “reset” toggle and so should be used with
caution.
The Metrics Selected button (bottom right) automatically
calculates the number of selected metrics, and clicking it
invokes the Selected RMF Metrics panel, which displays
the metrics that are being collected and forwarded to
Ironstream.
The right-most column provides a visual indication of
whether metrics are being collected for that element. When
the icon is green, metrics are selected; when the icon is red,
metrics are not selected.
It may take some to understand precisely how to set the element and metric switch icons in
conjunction with the RMF Elements and RMF Metrics panels to gather the metrics you
require, so here are some guidelines:
• The Metrics Selected button is particularly useful in this regard because it invokes
the Selected RMF Metrics panel, which displays all the metrics that can be collected
and forwarded to Ironstream.
• The Metrics column provides a count of the number of metrics selected for collection.
When metrics are selected for a parent element, which itself has more than one item
selected for collection (examples are SSIDs, LCUs and Volumes), multiply the count of

the parent resource by the metric count displayed to arrive at the total number of
metrics selected.
• The number shown in the Metrics Selected button provides this automatically so that
the count shown is accurate.

Sample Scenario for Setting RMF Filters

This scenario describes how to activate filters to capture a subset of RMF metrics for three
disk volumes on one LPAR.
Step 1: Open the RMF Filters Panel

If necessary, activate the Ironstream Desktop browser and open the RMF Filters panel, as
described in “Setting the RMF Filters in IDT” on page 23-6.
Panel 23-3 shows the initial filter settings with no metrics selected:
Panel 23-3: RMF Filters - No Metrics Selected

Note that the zero to the right of Volumes indicates that no disk volumes are selected, and
that the Metrics Selected button indicates that “No Metrics Selected”.

Step 2: Activate Filtering for Volumes

Click the Update button to the right of Volumes.
This dynamically builds the RMF Elements for VOL panel that contains a list of all the
disk volumes:
Panel 23-4: RMF Elements for VOL

The red switch icons indicate that no filter is set. Clicking a switch icon turns it green and
means that a volume is selected. Alternatively, all volumes can be selected by clicking the
icon next to the Volume heading
Panel 23-4 shows that we have selected three volumes: D11201, D11301 and D11302.
Click Close to return to the main filter panel.
Panel 23-5: RMF Filters Panel - With 3 Volumes Selected

As you can see in Panel 23-5, there are now three volumes selected for filtering.

Step 3: Specify the Metrics Collected for Selected Volumes

Having activated filtering, we can specify which specific metrics we want to capture for the
three selected volumes.
Click the Update button on the right side of the Filters panel under the Metrics heading.
Panel 23-6: RMF Filters Panel - With 3 Volumes Selected

This opens the RMF Metrics for VOL panel.
Panel 23-7: RMF Metrics for Volume Panel - With 3 Volumes Selected
Individual metrics can be activated by clicking the red switch icons. Alternatively, all
metrics can be selected by clicking the icon next to the Description column heading.
Click Close to return to the main filter panel.

Panel 23-8 shows that 25 metrics are selected, which was the result of activating all
metrics.
Panel 23-8: RMF Metrics for Volume Panel - With 25 Metrics Selected

Step 4: Specify the Metrics Collected per LPAR

The final step in this scenario is to specify that we want to capture metrics for one LPAR, in
this case ZOS2, by clicking the switch icon for the three selected volumes.
Panel 23-9: RMF Metrics for Volume Panel - With 75 Metrics Selected
Panel 23-9 shows that 25 metrics for the three volumes that have been selected for ZOS2,
and so the Metrics Selected button confirms “75 Metrics Selected”.
Note: Changes apply immediately, as soon as an icon changes from red to green or vice
versa, and take effect on the next DCE RMF collection cycle.

Clicking opens the Selected RMF Metric panel, which lists all seventy-five
selected metrics for ZOS2.
Panel 23-10: Selected RMF Metrics Panel

For detailed information about the available RMF metrics, refer to IBM’s Resource
Management Facility Programmer's Guide, in “Chapter 3 Accessing performance data using
the RMF Distributed Data Server”, for your version of z/OS.
Accessing RMF Enclave Attributes

The RMF Filter panel can collect RMF Enclave metrics from the RMF DDS. Panel 23-9
shows that Enclave Attributes can be enabled/disabled per LPAR within a Sysplex. When
activated, the Enclave Attributes collect the Enclave metrics that are logged by DCE and
forwarded to a data repository.
Clicking the adjacent View button opens the RMF Attributes for ENCLAVE pop-up,
which lists the Enclave names for that LPAR, which in this case is ZOS2.
Panel 23-11: RMF Attributes for ENCLAVE

The Enclave data format defaults to JSON but it can also be formatted as XML by modifying
the DataFormat configuration parameter in the RMFSettings group.


SECTION VI Integration with Splunk Premium
Applications
This section explains how Ironstream can be integrated with Splunk premium
applications.
• “Splunk Enterprise Security and Ironstream”
Chapter 24 Splunk Enterprise Security and
Ironstream
This chapter describes how Ironstream can be configured to work with Splunk Enterprise
Security.
Topics:
• “About Splunk Enterprise Security and Ironstream” on page 24-1
• “Intrusion Detection” on page 24-2
• “TSO Log-on Activity” on page 24-3
• “TSO Account Activity” on page 24-3
• “FTP Sessions” on page 24-4
• “FTP Change Analysis” on page 24-5
• “IP Traffic Analysis” on page 24-5
• “Network Management/User-Defined Notification” on page 24-6
About Splunk Enterprise Security and Ironstream

Splunk offers a premium application called “Enterprise Security” (ES). a large, multi-faceted
application that provides comprehensive security surveillance of an organization’s
computing infrastructure.
Ironstream Enterprise Security Technology Add-on (TA)

To leverage the Splunk ES application in Ironstream, Syncsort has created an “Ironstream®
Technical Add-on for Splunk Enterprise Security” (or Ironstream TA-ES), which collects,
formats, and manages the data from several z/OS mainframe sources powered by
Ironstream.

Splunk Enterprise Security and Ironstream
The Ironstream TA-ES application is downloaded and installed the same way as any other
Splunk application. However, the Ironstream TA-ES application does not contain any
dashboards, unlike a standard application.
Data is supplied by the Ironstream TA-ES and surfaced on the dashboards provided within
the Splunk ES application. The Splunk dashboards display mainframe information provided
by Ironstream TA-ES alongside data from other sources giving an organization a more
complete picture of security across their computing infrastructure.
Ironstream integration with Splunk ES currently supports the following activities within
z/OS:
• “Intrusion Detection”, including:
▪ Port scans – fast and slow
▪ Flood attacks – interface floods, SYN attacks, denial-of-service (DoS)
▪ Malformed packet detection
• “TSO Log-on Activity”
• “TSO Account Activity” – creation, update, deletion, and lockout
• “FTP Sessions” (authentications) – z/OS acting as server or client
• “FTP Change Analysis” (file activity) – file modification, download, creation, deletion
• “IP Traffic Analysis” – IP component usage (TCP, UDP, Stack, tn3270, etc.)
• “Network Management/User-Defined Notification”
Intrusion Detection
z/OS implements Intrusion Detection Services (IDS) via the Traffic Regulation Management
Daemon (TRMD), which is part of the z/OS Communications Server.
TRMD is required to detect and collect intrusion events. The daemon must be configured to
collect the following message types:
• EZZ8643I — TRMD SCAN threshold exceeded.
• EZZ8650I — TRMD ATTACK SYN flood.
• EZZ8654I — TRMD ATTACK Interface flood start: date
• EZZ8648I — TRMD ATTACK packet was discarded.
• EZZ8649I — TRMD ATTACK packet would have been discarded (packet kept).
These TRMD messages are written to SyslogD.
Ironstream collects the SyslogD messages via the Ironstream Network Monitoring
Component (NMC), breaks the message text into key/value pairs, and forwards the data to
Splunk. The key/value pairs make working with values easier in Splunk.
For instructions on configuring the Ironstream NMC, see “Alerts and SyslogD Forwarding,”
on page 14-1.

Splunk ES Visibility
TRMD data primarily appears within the Splunk ES Intrusion Center dashboard, which
provides an overview of all network intrusion events from Intrusion Detection Systems (IDS)
and Intrusion Prevention Systems (IPS) device data.
TSO Log-on Activity

Log-on activity for TSO users is captured via SMF 30 records for subtype 1 (job start), which
are collected and forwarded by Ironstream.
For instructions on configuring Ironstream to capture SMF data, see “SMF Record
TSO log-on activity primarily appears within these Splunk ES dashboards:
• Access Center — provides a summary of all authentication events.
• Access Anomalies — displays concurrent authentication attempts from different IP
addresses and improbable travel anomalies using internal user credentials and
location-relevant data.
• Access Search — finds specific authentication events.
• Access Tracker — gives an overview of account statuses to track newly active or inactive
accounts, as well as those that have been inactive for a period of time but recently
became active.
• Default Account Activity — shows activity on “default accounts”, or accounts enabled by
default on various systems, such as network infrastructure devices, databases, and
applications.
• User Activity – Remote Access — displays remote access authentication by user. A user
performing risky web or email activity while using remote access services can be an
indicator of data exfiltration, or exploited credentials.
TSO Account Activity

Creation, update, deletion, and lockout activity for TSO accounts are captured via SMF 80
records that are collected and forwarded by Ironstream.
The following RACF commands are tracked:
• ADDUSER — creating a new TSO user account.
• ALTUSER — changing an existing TSO user account.
• DELUSER — deletion of an existing TSO user account.

The SMF80 Event Code Qualifier (7) is used for LOCKOUT detection:
• SMF80EVQ = 7 — TSO user account lockout due to excessive password attempts.
TSO account activity primarily appears within these Splunk dashboards:
• Account Management — shows changes to user accounts, such as account lockouts,
newly created accounts, disabled accounts, and password resets.
applications.
• Endpoint Changes — uses the Splunk change monitoring system, which detects
file-system and registry changes, to illustrate changes and highlight trends in the
endpoints in your environment.
FTP Sessions
Authentication of FTP sessions are detected via SyslogD activity with the following
messages:
• EZYFS51I — CONN fails
• EZYFS52I — CONN ends
• EZYFS56I — ACCESS OK
• EZYFS57I — ACCESS fails
For instructions on configuring Ironstream to capture SyslogD data, see “Alerts and SyslogD
FTP log-on activity primarily appears within these Splunk ES dashboards:
• Access Center — provides a summary of all authentication events.
• Access Anomalies — displays concurrent authentication attempts from different IP
addresses and improbable travel anomalies using internal user credentials and
location-relevant data.
• Access Search — finds specific authentication events.
• Access Tracker — gives an overview of account statuses to track newly active or inactive
accounts, as well as those that have been inactive for a period of time but recently
became active.
applications.

• User Activity – Remote Access — displays remote access authentication by user. A user
performing risky web or email activity while using remote access services can be an
indicator of data exfiltration, or exploited credentials.
FTP Change Analysis

Analysis of FTP file modification, download, creation, and deletion activity is captured via
SMF 119 record activity for subtypes 3 and 70:
• Subtype 3 records z/OS acting as an FTP client (data potentially leaving the
mainframe).
• Subtype 70 records z/OS acting as an FTP server (data potentially arriving on the
mainframe).
FTP change activity appears within these Splunk ES dashboards:
• Endpoint Changes — uses the Splunk change monitoring system, which detects
file-system and registry changes, to illustrate changes and highlight trends in the
endpoints in your environment.
• Network Changes — tracks configuration changes to firewalls and other network
devices in your environment.
IP Traffic Analysis
Various IP traffic types (IP, UDP, FTP, Stack activity, etc.) are tracked via SMF 119 records
in subtype 2:
• Subtype 2 — Connection termination.
IP activity appears within these Splunk ES dashboards:
• Traffic Center — profiles overall network traffic, helps detect trends in type and
changes in volume of traffic, and helps to isolate the cause (for example, a particular
device or source) of those changes.
• Traffic Search — assists in searching network protocol data, refined by the search
filters.
• Network Changes — tracks configuration changes to firewalls and other network
devices in your environment.

Network Management/User-Defined Notification

Alerts and notifications detected by Ironstream’s Network Management Components (NMC)
are forwarded to Splunk by Ironstream. These can include events such as broken
connections, threshold breaches, or low activity anomalies. Plus, user-defined alerts can be
created for specific condition tracking.
For instructions on configuring the Ironstream NMC, see “Alerts and SyslogD Forwarding,”
on page 14-1.
Alerts appears as Notable Events in these Splunk ES dashboards:
• Security Posture — provides high-level insight into the notable events across all
domains of your deployment, suitable for display in a Security Operations Center (SOC).
• Incident Review — displays notable events and their current status to gain insight into
the severity of events occurring in your system or network.
• Identity Investigator — displays information about known or unknown user identities
across a pre-defined set of event categories, such as change analysis or malware.

SECTION VI Troubleshooting Ironstream
This section provides information about troubleshooting Ironstream and contacting

Syncsort Product Support.
• “Ironstream Commands”
• “Operational Considerations”
• “Ironstream Messages”
• “Diagnostics and Contacting Syncsort Product Support”
Chapter 25 Ironstream Commands
This chapter describes how to use Ironstream commands.
Topics:
• “Management Commands” on page 25-2
• “MODIFY Commands” on page 25-2
• “SMF Real-time INMEM Commands” on page 25-5
Overview
The commands in chapter are supported in Ironstream Version 2.1.
Note: Sample commands are written as if they were issued from an active console. When
issuing commands from within an SDSF environment, you need to prefix each command
with a slash (/).

Ironstream Commands
Management Commands
The following commands are supported in Ironstream Version 2.1.
Note: Sample commands are written as if they were issued from an active console. When
issuing commands from within an SDSF environment, you need to prefix each command
with a slash (/).
STOP
The “P” command causes Ironstream to stop collecting data, process any data in the data
store or coupling facility, and then terminate.
P jobname
MODIFY Commands
The MODIFY “F” commands are used to communicate to a running Ironstream instance.
BLOCKPRINT
Prints each translated block just before it is transferred to the transmission code. The
options are YES to turn on printing and NO to turn it off. (In a change from V1.4, DEBUG
does not have to be on to set BLOCKPRINT=YES.)
F jobname,BLOCKPRINT=YES
Caution: This command can generate a lot of output very quickly and should not be used
except when directed by Syncsort Technical Support.
DEBUG
Turns debug messages on or off. The options are YES to turn on debugging messages and
NO to turn them off.
F jobname,DEBUG=YES
DUMP
Causes an ABEND and take a dump of memory. It is a fatal command.
F jobname,DUMP
Warning! This command could cause Ironstream to crash and should only be used at the
direction of Syncsort Technical Support.

Ironstream Commands
LIST
The LIST command has four options. It is used to print a variety of informational messages,
mostly for the use of Syncsort Technical Support.
CAPTURE
The CAPTURE option will list the SMF record types being captured, or the syslog prefixes
being captured.
F jobname,LIST=CAPTURE
CBS
All the Ironstream control blocks are printed.
F jobname,LIST=CBS
MODULES
Issues message SDF0831I, which lists the metadata of modules in SYSPRINT.
F jobname,LIST=MODULES
SDF0831I name entry_point compile_date compile_time release PTF_level IN SERVICE
Here is a partial example of the SYSPRINT output.
Figure 25-1. Example LIST-MODULES Output
11:22:04 SDF0050S SDF INITIALIZATION COMPLETE

11:23:44 SDF5001I MODULES ARE LISTED IN SYSPRINT ONLY
11:23:44 SDF0831I SSDFCKDS SSDFCKDS 11/15/17 11.31 R1.4 EW01107 IN SERVICE
11:23:44 SDF0831I SSDFF250 SSDFF250 11/15/17 11.44 R1.4 EW01107 IN SERVICE
11:23:44 SDF0831I SSDFN250 SSDFN250 11/15/17 11.57 R1.4 EW01107 IN SERVICE
11:23:44 SDF0831I SSDFF241 SSDFF241 11/15/17 11.43 R1.4 EW01107 IN SERVICE
For more information about Ironstream versioning-related messages, SDF0831I-SDF0835I,
refer to “Ironstream Messages”.
QUEUES
The QUEUES option will print out the Data Store queue configuration and usage.
F jobname,LIST=QUEUES
TRACE
The Ironstream internal trace table is printed.
F jobname,LIST=TRACE

Ironstream Commands
RECONFIGURE
The RECONFIGURE commands allow you to dynamically reconfigure a running Ironstream
instance that is collecting SMF data. There are two commands: VALIDATE and EXECUTE.
VALIDATE
This command validates the reconfiguration:
EXECUTE
This command both validates and executes the reconfiguration:
Command Notes:
• When a valid RECONFIGURE command is issued for either VALIDATE or EXECUTE,
the configuration is printed in the SYSPRINT file.
• When invalid configuration change is encountered, the RECONFIGURE command will
not change the current configuration.
RECORDPRINT
Prints each record just before it is translated to ASCII. The options are YES to turn on
printing and NO to turn it off.
Note: In a change from V1.4, DEBUG does not have to be on to set RECORDPRINT=YES.
F jobname,RECORDPRINT=YES
RESTART
Restarts a suspended task. The task name should be the same as specified in system
message SDF0655S or SDF0656S. A task is suspended if two failures occur less than ten
seconds apart.
F jobname,RESTART=taskname
STATUS
Instructs Ironstream to print interim statistics to the SYSPRINT file (SDF0400I through
SDF0408I messages), and to the console where the command was issued. To run the
STATUS command from a system or SDSF console:
F jobname,STATUS
The SDF0601I message in Figure 25-2 that precedes the remaining responses to the
STATUS command is not written to the requesting console.

Ironstream Commands
Figure 25-2. Example STATUS Output
SDF0601I OPERATOR REQUESTED STATISTICS AT TIME - 18:13:10.76 DATE - 2/02/2017

SDF0401I TASK NAME TCB TIME MESSAGES IN MESSAGES OUT MAX RECORD LENGTH
SDF0402I MASTER 0.009693 N/A N/A N/A
SDF0402I GATH0001 0.002197 1036 159 N/A
SDF0402I EXTR0001 0.007816 159 159 32902
SDF0402I USAG0001 0.000201 N/A 1
SDF0404I SMF014 0.001219
SDF0406I --------------- ----- ------------ --------------- ----------------
SDF0407I 172.30.40.126 10010 CONNECTED 42 149340
SDF0407I 172.30.40.126 10009 CONNECTED 49 167298
SDF0407I 172.30.40.126 10008 CONNECTED 46 158638
SDF0407I 172.30.40.126 10007 CONNECTED 22 101338
SDF0406I --------------- ----- ------------ --------------- -----------------
SDF0408I TOTALS 159 576614
SMF Real-time INMEM Commands

The SMF real-time INMEM commands are only valid when "SMF_SOURCE":"INMEM" has
been specified. For more information, see “SMF Subparameters” on page 7-21.
REFRESH
Dynamically adds log streams to the capture queue, unless a log stream was disconnected
using the DISCONNECT command.
F jobname,INMEM,REFRESH
DISCONNECT
Use this command if a particular log stream is no longer required to be connected to
Ironstream, or needs Ironstream to disconnect from it for maintenance.
F jobname,INMEM,DISCONNECT,<logstream>
Once a log stream is disconnect by this command, it must be reconnected by a CONNECT
command.
CONNECT
Reconnects a disconnected log stream.
F jobname,INMEM,CONNECT,<logstream>
STATUS
Displays the status of all log stream connections, including the metadata surrounding each
log stream and the SMF real-time interface as a whole.
F jobname,INMEM,STATUS

Ironstream Commands

Chapter 26 Operational Considerations
This chapter describes some operational considerations when using Ironstream, such as
message flood automation, network contention, and data store conditions.
Topics:
• “Message Flood Automation and Syslog Message Collection” on page 26-1
• “Network Contention” on page 26-1
• “Data Store Filling or Full Condition” on page 26-2
Message Flood Automation and Syslog Message Collection

If you have implemented Message Flood Automation, messages may be suppressed at the
source and not reach Ironstream for forwarding to a destination. To ensure that messages do
reach Ironstream, specify AUTO or DISPLAY as an action statement when defining policies
for controlling message flooding situations. If you do not want such messages to reach
Ironstream, then you should specify NOAUTO or NODISPLAY.
Network Contention
Ironstream is designed to transmit data from the mainframe to chosen destinations at a
high speed. However, this could cause an impact on other network traffic if a lot of data is
being moved by Ironstream and the network is very busy. To address this issue, Ironstream
provides an option to set a cap for its transmission rate.
The THROTTLING_RATE parameter in the DESTINATION section of the configuration file
can limit the amount of data transferred per second by Ironstream. When this parameter is
set, the amount of data transferred per second through the network by Ironstream will not
exceed the capped amount for each TCP connection. For more information about the
THROTTLING_RATE parameter, refer to the “DESTINATION Section” on page 7-11).

Operational Considerations
Data Store Filling or Full Condition

A “Data Store Full” condition can occur when the arrival rate of the data exceeds the
transmission capabilities of the TCP connections, or when the TCP connection or destination
endpoint fails.
• A TCP or a destination connection failure is indicated by messages SDF0127S or
SDF0128S:
▪ Message SDF0127S is issued on a per TCP connection basis and indicates a change in
the connection status.
▪ Message SDF0128S is issued when Ironstream detects that all connections have
failed.
• As the amount of collected data held in the data store grows beyond 1000 elements,
message SDF0126S is issued every minute and displays the number of messages held in
the data store.
Note that message SDF0126S indicates a condition where the arrival rate is exceeding
the transmission rate, but without receiving a preceding SDF0127S or SDF0128S
message.
• Once the data store can no longer hold any more data, message SDF0145S is issued and
data collection is stopped. Data collection will not resume until all the data in the data
store has been transmitted. At that point message SDF0146S is issued and data
collection will resume.
For information on how to recover data using the IMPORT parameter, see the description on
“"IMPORT":"ON"” on page 7-8. Examples are also provided in the “Configuration File
Examples” on page 7-29.
Recommended Data Store Configuration Guidelines

When message SDF0126S is issued multiple times, it is an indication that the data being
collected by Ironstream cannot be processed fast enough. This could also indicate a
configuration issue that should be addressed.
The following list of recommended steps can help to ensure that Ironstream is properly
configured to explain, reduce, or eliminate these conditions.
• Ensure that the job priority of the Ironstream task is at least as high as the application
producing the logs that are being collected. If Ironstream does not get CPU cycles to
process the records, messages will be issued indicating that the data store has an
excessive number of messages in its queue or that data collection has stopped.
• Ensure that connectivity is established and that there is enough network bandwidth to
handle the volume of data that is being produced by Ironstream.
• Ensure that the chosen destination – indexer(s)/forwarder(s) – have enough capacity to
handle the load of the messages being forwarded to them. If necessary, multiple
indexers or forwarders can be added. Up to 255 different target IP/PORT addresses can
be added to the configuration files to assist in load balancing.
• If all of the above conditions are appropriate for the amount of data being processed, it is
possible to specify a larger size for the data store that is being used by Ironstream by

adding a DATASTORESIZE parameter to your configuration file. Valid values are

100-2000. The field follows the DESTINATION keyword specification and precedes the
INDEX keyword.
The default value for the DATASTORESIZE is 400K times the MAXUSER value in the
IEASYSnn member of PARMLIB (limited to 2000 MB). Here is an example snippet of
where it should be placed in the configuration file:
DESTINATION
"DATASTORESIZE":"nnnn"
"INDEX":"index_name"
• In extreme cases of very large volume of records where the data store size is just not
large enough to process the influx of records, it is recommended to break up the records
collected by their maximum peak volumes and create multiple instances of Ironstream
in the same LPAR to process the different records.
For more information about setting the DESTINATION parameters in the configuration file,
see “DESTINATION Section” on page 7-11.


Chapter 27 Ironstream Messages
This chapter contains the system messages generated by core Ironstream and the Data
Collection Extension (DCE).
Topics:
• “Overview of Ironstream Messages” on page 27-1
• “Ironstream Messages” on page 27-2
• “Data Collection Extension Messages” on page 27-76
Overview of Ironstream Messages

Messages issued by core Ironstream have the form: hh:mm:ss SDFnnnnx message_text
where hh:mm:ss is the local time of day, nnnn is the message number, and x may be A, I, or
S. The interpretation of the suffix letter is:
• A (Action) messages indicate a critical error condition. They are issued to the
SYSPRINT file. Ironstream terminates so that the error can be corrected and
Ironstream restarted.
• I (Information) messages provide operational information about Ironstream as it is
running. They are issued to the SYSPRINT file.
• S (Severe) messages are critical messages that are issued to the console () and to the
SYSPRINT file. These may require you to contact Syncsort Product Support (see
“Diagnostics and Contacting Syncsort Product Support,” on page 28-1).
Messages issued from Ironstream’s Data Collection Extension are prefixed with ‘DCE’
rather than ‘SDF’ but otherwise have the same basic format. DCE messages are listed in the
“Data Collection Extension Messages” on page 27-76 section, after the core Ironstream
messages.
The next section lists the core Ironstream messages in numeric sequence.

Ironstream Messages
Ironstream Messages
Table 27-1: Ironstream Messages
Message No. Message Text and Description

SDF0001I SDF START TIME - hh:mm:ss.th DATE - mm/dd/yyyy
Explanation: This message reports the time and date that this instance of
Ironstream was started.
SDF0002I SDF END TIME - hh:mm:ss.th DATE - mm/dd/yyyy
Explanation: This message reports the time and date that this instance of
Ironstream terminated.
SDF0003S ddname FILE NOT PRESENT
Explanation: No file with the ddname could be located in the TIOT
Action: Add a DD statement to the JCL for the appropriate file.
SDF0004S ddname FILE DID NOT OPEN
Explanation: The DCB for ddname was not marked as opened.
Action: Verify the ddname file is a valid sequential file. If the problem
continues, contact Syncsort Product Support (see “Diagnostics and
Contacting Syncsort Product Support,” on page 28-1).
SDF0005S ddname FILE OPEN FAILURE
Explanation: The OPEN for ddname returned a non-zero return code.
Action: Verify the ddname file is a valid sequential file. If the problem
continues, contact Syncsort Product Support (see “Diagnostics and
SDF0006A SDF MASTER TASK FAILED
Explanation: The master task has abnormally ended.
Action: Contact Syncsort Product Support (see “Diagnostics and
SDF0007A ddname FILE RECFM IS NOT SUPPORTED
Explanation: The record format of the file defined by ddname is not
RECFM=F/FB/FBS/V/VB.
Action: Convert the file to a supported record format.
SDF0008A ddname FILE LRECL EXCEEDS 32756 BYTES
Explanation: The LRECL of the file defined by ddname exceeds the
maximum allowed length.
Action: Convert the file to have a supported record length.

Ironstream Messages
Table 27-1: Ironstream Messages (continued)

SDF0009I OPENING FILE ddname
Explanation: The FILELOAD process is opening the ddname file.
SDF0010I READ n RECORDS FROM FILE ddname
Explanation: The FILELOAD process has read n records from the
ddname file.
SDF0011I CLOSING FILE ddname
Explanation: The FILELOAD process is closing the ddname file.
SDF0012S PROCESSING OF FILE ddname TERMINATED BEFORE EOF
Explanation: A failure or termination of the process has caused the
FILELOAD process to terminate before reaching the End Of File mark for
file ddname.
SDF0013S SYSPRINT OPEN FAILURE
Explanation: Ironstream has been unable to open SYSPRINT. This
message indicates that an unexpected error has occurred during
Ironstream initialization.
Action: If there are no other console messages that can help you
determine why this situation has occurred, contact your local Syncsort
office for technical support using the information provided in “Diagnostics
and Contacting Syncsort Product Support,” on page 28-1.
SDF0014I IRONSTREAM INSTANCE instance_name STARTING
Explanation: The Ironstream instance named in the message text has
begun its initialization process.
SDF0015S IRONSTREAM INSTANCE instance_name ABENDING BY
COMMAND
Explanation: This message confirms that the Ironstream instance named
in the message text has been terminated by operator command.
SDF0016I IRONSTREAM INSTANCE instance_name STOPPING
Explanation: This message confirms that the Ironstream instance named
in the message text has been stopped by operator command and has
started its normal shutdown procedure.
SDF0017A THE dataset_name DATASET IS NOT LRECL=80, RECFM=F/FB
Explanation: The named data set does not have an LRECL=80 and/or the
record format is not of a fixed length.
Action: Change the characteristics of the named data set or use a data set
with conforming characteristics.

Ironstream Messages

SDF0018I STARTING SYNTAX ONLY RUN
Explanation: This informational message is issued at the start of a syntax
checking-only run.
SDF0019I ENDING SYNTAX ONLY RUN
Explanation: This informational message is issued at the end of a syntax
checking-only run.
SDF0020A NOT VALID TO SPAN LOGICAL RECORDS ACROSS SOURCES
Explanation: A continued record was not logically completed within the
scope of the current source. Typically, this happens when an attempt has
been made to continue a record between the SSDFCONF file and a READ
file, or across multiple READ files.
Action: Put all the continuation records for a command in the same
SSDFCONF or READ file.
SDF0021A NOT VALID COMMENT RECORD IN CONTINUATION SEQUENCE
Explanation: A comment record was detected in the middle of a series of
concatenated control records.
Action: Reposition or remove the comment record.
SDF0022A CONTINUATION RESULTS IN MORE THAN 1280 CHARACTERS
Explanation: A series of continued records resulted in a logical record
exceeding the maximum allowed of 1280 bytes.
Action: Shorten the "keyword":"value" definition to fit in 1280 bytes.
SDF023A A COMMAND LINE DOES NOT BEGIN WITH A '[' OR A '"'
Explanation: Command lines must begin with a square bracket [ or a
quotation mark ".
Action: Correct the invalid specification.
SDF0050S SDF INITIALIZATION COMPLETE
Explanation: This message reports that Ironstream has completed
initialization and is ready to process data.
SDF0051I SDF TERMINATING
Explanation: This message reports that Ironstream has started to
terminate.
SDF0052I SDF PRINT OUT OF CONTROL BLOCKS AT START-UP
Explanation: As a result of specifying "DEBUG":"YES", this message is a
heading for the printing of control blocks generated by Ironstream after
initialization and before processing has commenced for use by Syncsort
Product Support.

Ironstream Messages

SDF0053I SDF PRINT OUT OF CONTROL BLOCKS AT SHUTDOWN
heading for the printing of control blocks generated by Ironstream after
processing has completed for use by Syncsort Product Support.
SSDF0054I SDF PRINT OUT OF INTERNAL TRACE TABLE

heading for the printing of an internal trace table for use by Syncsort
Product Support.
SDF0055I A SUB-TASK TERMINATED WITH AN ABEND
Explanation: A task has abended or terminated out of sequence. See
previous messages for task failures.
Action: If unable to determine the cause of the failure, contact Syncsort
Product Support.
SDF0056A THE [INIT|GET|TERM] OF A NAME/TOKEN WITH TOKENNAME =
token FAILED WITH RETURN CODE = rc
Explanation: An [INIT/GET/FREE] of a name/token pair failed with
return code rc.
Action: If unable to determine the cause of the failure, contact Syncsort
Product Support.
SDF0057A THE field_type FORMAT IS INCORRECT FOR THE IMPORT OF
data_type DATA
Explanation: The format of the TIME or DATE field in the "START
TIME" / "END TIME" or "START DATE" / "END DATE" is incorrect for
the type of data being processed by the IMPORT function.
Action: Correct the format of the field in question.
SDF0058A INCOMPATIBLE field_type FORMATS BETWEEN START AND END
COMMAND STATEMENTS
Explanation: An inconsistency in the format of the named fields was
found between the START and END commands.
Action: Correct the format of the field in question.

Ironstream Messages

SDF0090S LICENSE KEYS VALIDATED FOR CPU SERIAL NUMBER serial, MSU
nnn, and EXPIRATION DATE: date
Explanation: A valid license key for CPU number serial and MSU level
nnn was processed that has an expiration date of date. If you have
multiple keys in the configuration file, the expiration date may not be the
latest date if more than one is outside of the warning period.
For example: two keys are in the file and the number of warning days is
set to 45 days. The first key in the file is to expire in 46 days and the
second is to expire in a year and 45 days. The expiration date will show
the 46 day date. In a second case of the first key being set to expire in 44
days and the second key set to expire in a year and 45 days, then the date
will be for the year and 45 days.
SDF0091S **WARNING** LICENSE EXPIRING, MUST INSTALL VALID KEY
WITHIN number DAYS
Explanation: This is a warning message that the current key will expire
in the specified number of days. If a new key is not installed, SDF will
terminate.
Action: Contact Syncsort Product Support to obtain a new license key.
SDF0092S INSUFFICIENT LICENSE CAPACITY FOR CPU SERIAL NUMBER
xxxxx MSU nnnnn.
Explanation: This is a warning message that the running machine has
exceeded the licensed MSU limit.
Action: Contact Syncsort Product Support to upgrade your license.
SDF0093S NO VALID LICENSE KEY FOUND FOR CPU SERIAL NUMBER xxxxx
Explanation: This is a warning message that the running disaster
recovery machine is currently not licensed for Ironstream.
Action: Contact Syncsort Product Support to obtain a temporary license
key.
SDF0101I configuration input records
Explanation: Each record in the configuration file is echoed to SYSPRINT.
SDF0102A THE PREVIOUS RECORD CONTAINS AN ERROR
Explanation: The previous record contains a syntax or value error.
Action: Correct the invalid data.

Ironstream Messages

SDF0105A section name SECTION NOT order IN CONFIGURATION FILE
Explanation: section name is either KEYS or SYSTEM. order is either
FIRST or SECOND. The first non-comment or blank record in the
configuration file was not a [KEYS] record, or the second section did not
begin with [SYSTEM].
Action: Correct your configuration file, ensuring that the [KEYS] record is
the first non-comment or blank record in the SSDFCONF file, and that
the second section header is [SYSTEM].
SDF0107A THE ABOVE RECORD IS OUT OF SEQUENCE
Explanation: The previous record is not in the prescribed sequence.
Action: Correct the order of the records in the SSDFCONF file. Control
sections must occur in [SYSTEM], then [DESTINATION] and [SOURCE]
sequence. See the instructions for the sequence of "keyword" records in
each section.
SDF0108A UNEXPECTED EOF ON SSDFCONF FILE
Explanation: End-of-file was reached when additional control records
were expected.
Action: Add the missing records to the SSDFCONF file. See the
instructions for the sequence of required "keyword" records in each
section.
SDF0109A ERROR, TOKEN token_name ERROR
Explanation: The listed token was not found or the token specification
format was invalid.
Action: For an unfound token check the sequence of tokens in the
configuration file. If it is a token specification error, check the acceptable
format for the token and correct.
SDF0110A ERROR, VALUE ERROR IN ABOVE RECORD
Explanation: The value portion of the "keyword":"value" in the previous
record is not acceptable.
Action: Verify the "value" specified is valid for the associated "keyword"
and correct.
SDF0112A BLDL FAILURE FOR MODULE mod_name. RETURN CODE rc,
REASON CODE rsn
Explanation: A BLDL was done for mod_name and it returned a return
code and reason code.
Action: Consult the BLDL section of the DFSMS Macro Instructions for
Data Sets manual for an explanation of the codes. If unable to correct,
contact Syncsort Product Support.

Ironstream Messages

SDF0113A BLDL FAILURE FOR MODULE mod_name. INVALID LIBRARY TYPE
OF type RETURNED
Explanation: A BLDL was done for mod_name and it returned a type code
other than 1 or 2.
Action: Consult the BLDL section of the DFSMS Macro Instructions for
Data Sets manual for an explanation of the codes. If unable to correct,
SDF0114A FAILURE TO FIND MODULE mod_name IN LINKLIST. RETURN
CODE rc, REASON CODE rsn
Explanation: A CSVDYNL macro was issued for mod_name and it
returned a return code and reason code.
Action: Consult the CSVDYNL section of the MVS Programming:
Authorized Assembler Services Reference, Volume 1 (ALE-DYN) manual
REQUEST=TEST for an explanation of the codes. If unable to correct,
SDF0115A SWAREQ FAILURE FOR DDNAME ddname. RETURN CODE rc
Explanation: A SWAREQ macro was issued for ddname and it returned a
return code.
Action: Consult the SWAREQ section of the MVS Programming:
Authorized Assembler Services Reference, Volume 4 (SET-WTO) manual
FCODE=RL for an explanation of the codes. If unable to correct, contact
SDF0116A SEARCH OF TIOT RESULTED IN ZERO LENGTH ENTRY
Explanation: The TIOT was being scanned for required DDNAMEs. An
invalid entry with length zero was found.
Action: If unable to correct, contact Syncsort Product Support.
SDF0117S NO VALID KEY PARAMETER FOUND
Explanation: No valid KEY value was found. Ironstream terminating.
Action: Contact Syncsort Product Support to obtain a valid KEY.
SDF0119A [SUBTYPE|INCLUDE] CAN ONLY BE SPECIFIED WITH A SINGLE
SMF RECORD TYPE
Explanation: The SUBTYPE and INCLUDE parameters can only be used
following a SELECT parameter that specifies a single SMF record type.
Action: Modify the configuration file so that a distinct SELECT parameter
is used when SUBTYPE or INCLUDE parameters are specified.

Ironstream Messages

SDF0120A ANOTHER INSTANCE OF SDF WAS DETECTED USING THE
[SYSTEM] NAME OF system_name. CREATE TOKEN RC=rc
Explanation: Another instance of SDF was detected using the same
system_name. This is detected by creating a name/token using the
system_name and getting a non-zero return code rc back from the create
function.
Action: Check that another instance of SDF is not using the same
system_name and correct.
SDF0124I STARTING TASK taskname USING PROGRAM pgmname
Explanation: The specified task name is being started and is attaching the
specified program as the initial program.
SDF0125S AN OUTPUT RECORD LONGER THAN 393216 BYTES WAS
DETECTED. THE RECORD WILL NOT BE TRANSMITTED.
Explanation: When processing a record to send to the destination
repository SDF detected the length exceeded the maximum length that
can be processed. This message is printed in the SYSPRINT file and in the
syslog. The failing record is printed in the SYSPRINT file following this
message. The record is discarded and processing continues.
SDF0126S AT time ON date THE NUMBER OF MESSAGES QUEUED FOR
EXTRACTION IS n. RECORDS IN = input RECORDS
OUT = output
Explanation: At the time and date specified, an excessive number of
records (n) were detected being queued up for processing by the extraction
routine. The total number of records put into the Data Store, or Coupling
Facility when using the DLP feature, is input and the total number
extracted from it is given in the message text. Ironstream checks the
number of records queued once a minute and each time the number of
records in the Data Store exceeds the internal threshold value, this
message is generated.
Action: This message tends to indicate that there is either a transient or
permanent problem. If it only occurs periodically, that is, not every
minute, it indicates there was a temporary increase of records that
exceeded the capacity of the TCP connection. If it is repeated every
minute, and the number of RECORDS OUT continues to increase, it
indicates the TCP connection is undersized or that throughput has been
impaired in some fashion. If the RECORDS OUT value does not increase,
then either there is a TCP failure or an Ironstream process failure. If you
believe it is an Ironstream process failure, contact Syncsort Product
Support for additional assistance.

Ironstream Messages

SDF0127S AT time ON date THE STATUS OF TCP CONNECTION ipaddress:port
CHANGED TO [DISCONNECTED/CONNECTED]
Explanation: At the time and date specified, the TCP connection status
specified by ipaddress:port became either disconnected or connected.
Processing continues with other connections, if possible.
Action: If the connection became disconnected, you should determine what
caused the connection failure.
SDF0128S AT time ON date ALL THE TCP CONNECTIONS ARE DOWN
Explanation: This message shows the time (HH:MM:SS.TH) and date
(MM/DD/YYYY) that Ironstream detected all TCP connections are down.
Action: You should determine what conditions are causing the connections
to fail.
SDF0129A THE ENCLAVE CREATE FUNCTION HAS FAILED WITH RETURN
CODE rc AND REASON CODE rsn
Explanation: A failure occurred when creating an enclave to support z/IIP
offload processing. Processing continues without z/IIP offload.
Action: Contact Syncsort Product Support with the return code and
reason code values.
SDF0130A THE ENCLAVE OFFLOAD CONTROL TABLE CREATE FUNCTION
HAS FAILED WITH RETURN CODE rc AND REASON CODE rsn
Explanation: A failure occurred when creating an enclave to support z/IIP
offload processing. Processing continues without z/IIP offload.
reason code values.
SDF0131A THE ENCLAVE DELETE FUNCTION HAS FAILED WITH RETURN
Explanation: A failure occurred when deleting the enclave to support z/IIP
offload processing. Processing continues.
reason code values.
SDF0132A DUPLICATE CLASS/TYPE/SUB-TYPE DEFINTION DETECTED.
CLASS = c, TYPE = t, SUB-TYPE = s
Explanation: When processing IRONSTREAM_API control images, a
duplicate definition was detected for the CLASS, TYPE and SUBTYPE
given in the message.
Action: Remove the duplicate definition.

Ironstream Messages

SDF0133A ILLEGAL RECURSIVE USE OF A "READ" COMMAND DETECTED
Explanation: A second instance of a "READ" command for the same data
set (member) was detected while the first occurrence was still being
processed.
Action: Modify the configuration file to remove the circular reference.
Note that READ files can contain additional READ commands, but
circular references are not permitted.
SDF0134A "INCLUDE" FIELD NAME name IS A DUPLICATED NAME
Explanation: The field name specified has already been selected in the
INCLUDE parameter for an SMF record type.
Action: Modify the configuration file to remove the additional references
to the field name.
SDF0135A EXISTING ENTRY IN ISV ADDRESS TABLE IS NOT A SYNCSORT
ENTRY
Explanation: In a work area assigned by IBM for the use of Syncsort,
non-Syncsort data was discovered.
Action: Contact Syncsort Product Support for assistance.
SDF0136A GETMAIN FAILED FOR NEW ISV ADDRESS TABLE
Explanation: The GETMAIN to acquire CSA storage for the Syncsort ISV
address table failed.
SDF0137A NO DB2TOKEN SPECIFIED WHEN USING DB2TRIGGER
Explanation: The "DATATYPE":"DB2TRIGGER" option was used, but no
associated "DB2TOKEN" parameter was specified.
Action: Provide one or more "DB2TOKEN" parameters in the
configuration file.
SDF0138A GETMAIN FAILED FOR NEW DB2TOKEN BLOCK
Explanation: When processing the DB2TOKEN parameters in the
configuration file, an insufficient storage condition was detected.
Action: Increase the REGION parameter.
SDF0139A DB2TOKEN ''token'' IS THE SAME AS AN EXISTING TOKEN
Explanation: A duplicate token value was detected.
Action: Remove duplicate in the configuration file for this instance of
Ironstream, or see if one exists in another instance of Ironstream.

Ironstream Messages

SDF0140A THE VALUE n IS NOT IN THE VALID RANGE OF 1 TO 128
Explanation: When processing the ROUTCDE parameter an invalid value
was detected.
Action: Correct the invalid value.
SDF0141A THE SECOND RANGE VALUE OF n IS NOT GE THE FIRST VALUE
OF m
Explanation: When specifying a value range, the value n must be equal to
or greater than the value m.
Action: Reverse the values.
SDF0142A WHEN PROCESSING ROUTCDE PARAMETERS, A NON-NUMERIC
CHARACTER WAS FOUND
Explanation: The values in the ROUTCDE parameter must be numeric.
Action: Replace the non-numeric value with a numeric value.
SDF0143A SMF RECORD TYPE nnn IS NOT SUPPORTED
Explanation: The SMF record type number specified in the SELECT
parameter is not supported by Ironstream at this time.
Action: Modify the configuration file to remove the unsupported record
type number.
SDF0145S AT hh:mm:ss.th ON mm/dd/yyyy A DATA STORE FULL CONDITION
WAS DETECTED AND DATA COLLECTION HAS STOPPED
Explanation: At the time and date specified, the DATA STORE could not
accept any more data. Data collection will be suspended until the records
in the DATA STORE can be transmitted to the destination repository.
Action: Determine the reason why the DATA STORE became full and
correct the problem. The most common causes are:
• The destination repository has stopped
• TCP connections have failed
• The data gathering rate is greater than the TCP transmission rate
SDF0146S AT hh:mm:ss.th ON mm/dd/yyyy DATA COLLECTION HAS RESUMED
Explanation: At the time and date specified, Ironstream has resumed
collecting data.
Action: If you need to import data that has been missed, you can use the
IMPORT parameter with date and time specifications appropriate for the
data being collected. See the description of the IMPORT parameter on
page 8.

Ironstream Messages

SDF0148A "TYPE":"HTTPS" SPECIFIED AND "SSL":"YES" IS NOT SPECIFIED
FOR THIS CONNECTION
Explanation: "SSL":"YES" must be specified when using
"TYPE":"HTTPS".
Action: Modify the configuration file to add the SSL parameters, or
change to "TYPE":"HTTP".
SDF0149A THE INCLUDE NAME OF name WAS NOT FOUND IN THE NAME
LIST FOR SMF RECORD TYPE n
Explanation: The INCLUDE list of field names included a name that is
not a field that can be forwarded from the specified record type.
Action: Change the configuration file to remove the field name.
SDF0150I INITIAL CONNECTION FAILED, RETRYING IN nnn SECONDS
Explanation: "RETRY_ON_START":"YES" has been specified and a new
connection attempt will be made in the specified number of seconds.
SDF0151S SDF IS TERMINATING BECAUSE NO VALID KEY WAS FOUND
Explanation: At initialization this message is issued and SDF terminates
if no valid key is found. This message will be issued while SDF is running
if no valid key is found for two days. SDF will check for a valid key at
10:00AM local time each day.
Action: SDF terminates immediately. Contact Syncsort Product Support
administration to obtain a new license key and restart SDF.
SDF0152I REVALIDATION OF PROCESSING KEYS STARTED AT hh:mm:ss.th
ON mm/dd/yyyy
Explanation: Each day at approximately 10:00 local time the SSDFCONF
file is read and examined for valid license keys.
SDF0153I [KEYS] SECTION OF CONFIGURATION FILE LISTING
Explanation: This is the header record for the listing of the configuration
file through the [KEYS] section.
SDF0154S FAILURE IN PROCESSING OF KEYS. SECOND FAILURE WILL
RESULT IN SDF TERMINATION
Explanation: During revalidation of license keys, either an error caused
early termination of the key checking, or no valid key was found. If the
problem is not corrected, a second check in 24 hours will result in the
termination of SDF.
Action: Correct the problem or contact Syncsort Product Support and
obtain a new license key.

Ironstream Messages

SDF0155S SECOND FAILURE IN PROCESSING OF KEYS. SDF TERMINATING
Explanation: For a second day in a row the revalidation routine did not
find a valid key. SDF is terminating.
Action: SDF terminates immediately. Contact Syncsort Product Support
to obtain a new license key and restart SDF.
SDF0156I END OF KEY SEARCH PROCESSING
Explanation: This message is issued at the end of the revalidation
process.
SDF0158A ANOTHER IRONSTREAM INSTANCE IS ALREADY RUNNING USING
THE LOG STREAM NAME OF stream_name
Explanation: This Ironstream instance has detected another instance
using the specified stream name.
Action: Use a unique log stream name for this instance of Ironstream.
SDF0160A ERROR IN TOKEN PARAMETER STATEMENT: supplied_parameter
Explanation: The token parameter statement defined by the DB2 trigger
is incorrect. Correct format is
"SSDFDB2TOKEN":"nnnnnnnnnnnnnnnn".
Action: Correct the parameter statement and retry.
SDF0160I THE FOLLOWING MESSAGE EXCEEDS THE MAXIMUM SIZE OF
65,532 BYTES THAT CAN BE WRITTEN TO A COUPLING FACILITY
LOG STREAM
Explanation: This message is issued when a message is attempted to be
logged by the Data Loss Prevention (DLP) feature in the coupling facility
log stream exceeds the maximum size of 65,532 bytes that can be written
to a log stream. The message is issued to the SYSPRINT file and no
attempt is made to process the data. Processing continues with the next
record.
Action: No action required.
SDF0161A TOKEN NOT FOUND: nnnnnnnnnnnnnnnn
Explanation: The token parameter statement defined by the DB2 trigger
does not have an active Ironstream instance processing DB2 data for this
token.
Action: Ensure an Ironstream instance to process this DB2 data is active
and retry.

Ironstream Messages

SDF0162A ERROR IN PUT ROUTINE RETURN rc REASON rsn
Explanation: An error has occurred writing the DB2 data to the
Ironstream data store.
Action: Determine cause of error and retry. If unable to correct, contact
SDF0170A VALUE field_name NOT AN SMF FIELD NAME DEFINED IN SMF
RECORD TYPE nnn
Explanation: The specified value in a WHERE statement is not a
recognized name of a field in the specified SMF record type.
Action: Correct the field name in the WHERE statement.
SDF0171A WHERE TEXT: text
Explanation: The WHERE statement is output as a single text string. See
message SDF0172A.
Action: None.
SDF0172A SYNTAX ERROR AT OFFSET location IN THE ABOVE WHERE TEXT
Explanation: There is a syntax error at the specified offset in the
statement printed in SDF0171A.
Action: Correct the syntax error.
SDF0173A SYNTAX ERROR - UNBALANCED PARENTHESES IN THIS
STATEMENT
Explanation: Unbalanced parentheses were detected in the WHERE
statement.
Action: Correct the error.
SDF0174A INSUFFICIENT STORAGE AVAILABLE PROCESSING WHERE
CLAUSE. REDUCE THE NUMBER OF WHERE CONDITIONS OR
INCREASE THE REGION SIZE.
Explanation: Storage was not available to allocate a control block.
Action: Reduce the number of WHERE conditions or increase the
REGION size.
SDF0175A NUMERIC VALUE value EXCEEDS 64-BIT VALUE
Explanation: The specified numeric operand value in the WHERE
statement exceeds the largest value that can be stored in 64 bits.
Action: Validate that the numeric operand value is correct.

Ironstream Messages

SDF0176A ERROR CONVERTING operand_type VALUE value
Explanation: The value specified for the operand_type (NUMERIC, HEX,
DATE, or TIME) in the WHERE statement was incorrect.
Action: Correct the format of the value specified for the operand_type.
SDF0177A type DATA TYPE IS NOT SUPPORTED AT THIS TIME
Explanation: An unsupported data type was specified for use in a WHERE
statement.
Action: Remove or replace the specified data type.
SDF0178A TOKEN token IS INVALID AT THIS LOCATION
Explanation: The specified token is invalid in this position.
Action: Put the specified token in the correct sequence.
SDF0179A SYNTAX ERROR – ONLY A SINGLE WHERE CLAUSE IS PERMITTED
PER SMF RECORD TYPE
Explanation: More than one WHERE clause was specified for a single
SMF record type.
Action: Delete the extraneous WHERE clause(s) for the SMF record type.
SDF0180I WHERE PROCESSING ERROR TYPE type. MESSAGE ACCEPTED BY
DEFAULT
Explanation: An internal error has occurred. The message is
automatically accepted.
SDF0181A TOKEN token CAN ONLY FOLLOW THE EQ AND NE OPERATORS
Explanation: The specified token is only valid when it follows an EQ or
NE operator.
Action: Correct the syntax and resubmit.
SDF0182A VALUE token NOT A MONITOR FIELD NAME DEFINED IN module
Explanation: The specified token is not defined in the named CICS
monitor token definition module.
Action: Validate that the specified token is correct. You may need to
create a custom CICS monitor name table. For more information, see
“Implementing a Custom CICS Monitor Dictionary in Ironstream” on
page 12-23.

Ironstream Messages

SDF0183I DUPLICATE NAME name FOUND. THE DUPLICATED NAME HAS
BEEN IGNORED
Explanation: When processing an IN or NOTIN list of names, the value
name appeared more than once.
Action: The duplicated name values have been ignored. Processing
continues.
Note: This message will appear once for each duplicated value.
SDF0190A PARAMETER parm_1 IS INVALID WITH PARAMETER parm_2
Explanation: The two specified parameters are incompatible.
Action: Decide which parameter is more important to the process and
either remove or modify the other parameter.
SDF0191A SUBTYPE nn IS INVALID
Explanation: The specified subtype value is either invalid or not
supported for the SMF record type.
Action: Delete this subtype number from the configuration file.
SDF0192A SUBTYPES NOT SUPPORTED FOR SMF RECORD TYPE nn
Explanation: The SMF record type specified does not support subtypes.
Action: Delete the "SUBTYPE" statement for this SMF record.
SDF0193A SMF RECORD TYPE nn CAN ONLY BE SPECIFIED ONCE
Explanation: A SMF record type can only be selected once in a
configuration file. A second SELECT statement occurrence for the
specified SMF record number has been detected.
Action: Remove the second SELECT statement for the same SMF record
and resubmit.
SDF0194I pppppppp PARAMETER NOT REQUIRED. PARAMETER IGNORED
Explanation: Parameter pppppppp is recognized but is no longer
supported. The parameter and any related subparameters are ignored.
Action: The ignored parameter should be removed from the configuration
file.
SDF0201I DATA SPACE ACQUIRED FOR data store name
Explanation: Information gathered by Ironstream is stored briefly in a
data space. This message indicates the success of acquiring the requested
data space.

Ironstream Messages

SDF0202I DATA SPACE EXTENDED FOR data store name
data space. This message indicates the success of extending (enlarging) a
previously acquired data space.
SDF0203A DATA SPACE ACQUIRE FOR data store name FAILED WITH RETURN
data space. This message indicates an attempt to acquire the data space
failed. The return code and reason code are from the DSPSERV macro
found in the MVS Programming: Authorized Assembler Services
Reference, Volume 1(ALE-DYN); CREATE, SCOPE=COMMON. The
Ironstream task terminates.
SDF0204A DATA SPACE EXTEND FOR data store name FAILED WITH RETURN
data space. This message indicates an attempt to enlarge the size of an
existing data space failed. The return code and reason code are from the
DSPSERV macro found in the MVS Programming: Authorized Assembler
Services Reference, Volume 1(ALE-DYN); EXTEND. The Ironstream task
terminates.
SDF0205A DATA SPACE ALET ACQUIRE REQUEST FOR data store name
FAILED WITH RETURN CODE rc AND REASON CODE rsn
data space. Accessing information stored in a data space requires an
ALET. This message indicates an attempt to acquire access to the data
space by way of the ALET failed. The return code and reason code are
from the ALESERV macro found in the MVS Programming: Authorized
Assembler Services Reference, Volume 1(ALE-DYN). The Ironstream task
terminates.
SDF0206I DATA SPACE DELETED FOR data store name
data space. This message indicates the successful deletion of a previously
acquired data space.

Ironstream Messages

SDF0207A DATA SPACE DELETE FOR data store name FAILED WITH RETURN
data space. This message indicates an attempt to delete an existing data
space failed. The return code and reason code are from the DSPSERV
macro found in the MVS Programming: Authorized Assembler Services
Reference, Volume 1(ALE-DYN); DELETE. The Ironstream task
terminates.
SDF0208I DATA SPACE ALET DELETED FOR data store name
data space and was accessed via a PASN-AL entry. This message
indicates the successful deletion of a PASN-AL entry for the ALET.
SDF0209A DATA SPACE ALET DELETE FOR data store name FAILED WITH
RETURN CODE rc AND REASON CODE rsn.
data space and was accessed via a PASN-AL entry. This message
indicates an attempt to delete an existing PASN-AL entry failed. The
return code and reason code are from the ALESERV macro found in the
MVS Programming: Authorized Assembler Services Reference, Volume
1(ALE-DYN); DELETE. The Ironstream task terminates.
SDF0301A GETBUFFER FAILURE FOR EXTRACTOR task_name
data space. The extractor removes information from the data store,
creates named-paired destination repository entries, and stores the
information in a TCP/IP buffer. This message indicates an attempt to
acquire a TCP/IP buffer failed.
Action: Ironstream stops. If unable to resolve, contact Syncsort Product
Support.
SDF0302A INITIALIZATION OF C ENVIRONMENT FAILED FOR EXTRACTOR
task_name
creates name-paired destination repository entries, and stores the
information in a TCP/IP buffer. The TCP/IP environment is LE and C.
This message indicates an attempt to create the proper TCP/IP
environment failed.
Support.

Ironstream Messages

SDF0303A LOAD OF C HLL INTERFACE FAILED FOR EXTRACTOR task_name
This message indicates an attempt to create the proper TCP/IP
environment failed.
Support.
SDF0304A LOAD OF MODULE mod_name FAILED WITH ABEND CODE ab,
REASON CODE rsn FOR EXTRACTOR task_name
information in a TCP/IP buffer. The module used to create this
environment is loaded into storage with the LOAD macro. This message
indicates an attempt to load a required module failed.
Action: Ironstream stops. Using the listed abend code and reason code,
refer to the System Message manual for required corrective measures. If
unable to resolve, contact Syncsort Product Support.
SDF0305A ADD OF mod_name MODULE TO C ENVIRONMENT FAILED FOR
EXTRACTOR task_name
This message indicates an attempt to load TCP/IP module failed.
Support.
SDF0306A TCP/IP [INIT|SEND|DELETE] ROUTINE RETURNED RETURN
CODE=rc, REASON CODE=rsn AND FEEDBACK CODE fd FOR
EXTRACTOR task_name
information in a TCP/IP buffer. A call to the indicated TCP/IP routine
returned a non-zero return code indicating a failure in TCP/IP.
Support.

Ironstream Messages

SDF0307I TCP THROTTLING IS ENFORCED, THROTTLING RATE IS nnnn KB/s
Explanation: This message is displayed when a THROTTLING_RATE
parameter has been specified in the DESTINATION section of the
configuration file.
SDF0309A EXTRACTOR task_name ERROR RETURNED FROM CALL TO
NAME/TOKEN PAIR
Explanation: A call to the system routine IEANTRT failed. Refer to the
manual "MVS Programming: Assembler Servers Reference, Volume 2
(IAR-XCT)" for an explanation of the return code.
Support.
SDF0310A EXTRACTOR task_name ERROR RETURNED WHEN READING FROM
DATA STORE data store name
Explanation: An extractor task_name attempted to retrieve data from the
data store data store name. The return code was greater than 4 indicating
an error in information retrieval.
Support.
SDF0311A EXTRACTOR task_name HAD A DYNALLOC ERROR. R15= rc WITH
REASON CODE=rsn
Explanation: An extractor task_name attempted to allocate a file for
writing the retrieved data from the data store. The return code and reason
code are from dynamic allocation and are located in the Interpreting
DYNALLOC return codes section of the MVS Programming: Authorized
Assembler Services Guide.
Support.
SDF0312A EXTRACTOR task_name HAD AN OPEN ERROR FOR ddname
Explanation: An extractor task_name attempted to open the file ddname
but failed. Examine messages in the JESMSGLG of the Ironstream job to
understand the cause of the error.
Support.
SDF0313A EXTRACTOR task_name HAD A CLOSE ERROR FOR ddname
Explanation: An extractor task_name attempted to close the file ddname
but failed. Examine messages in the JESMSGLG of the Ironstream job to
understand the cause of the error.
Support.

Ironstream Messages

SDF0314I SOFTWARE COMPRESSION FEATURE IS AVAILABLE
Explanation: SMF 110 records for CICS may be compressed. While
creating the environment to process CICS 110 SMF records, an
assessment of the required compression capability of the software and
hardware is made. This message indicates software compression is
available in this environment.
SDF0315I SOFTWARE COMPRESSION FEATURE IS NOT AVAILABLE
hardware is made. This message indicates software compression is not
SDF0316I HARDWARE COMPRESSION FEATURE IS AVAILABLE
hardware is made. This message indicates hardware compression is
SDF0317I HARDWARE COMPRESSION FEATURE IS NOT AVAILABLE

hardware is made. This message indicates hardware compression is not
SDF0318A CSRCESRV SERVICE=QUERY, RETURN CODE rc
hardware is made. Using the compression / decompression feature
requires a SERVICE=QUERY call via the CSRCESRV macro. This
message indicates the call failed with return code rc. Refer to the manual
MVS Programming: Assembler Services Reference, Volume 1
(ABEND-HSPSERV) section CSRCESRV for an understanding of the
return code.
Action: Ironstream stops. If unable to resolve the error condition using the
above reference, contact Syncsort Product Support.

Ironstream Messages

SDF0319A CSRCESRV SERVICE=EXPAND, RETURN CODE rc
hardware is made. Using the decompression feature requires a
SERVICE=EXPAND call via the CSRCESRV macro. This message
indicates the call failed with return code rc. Refer to the manual MVS
Programming: Assembler Services Reference, Volume 1
(ABEND-HSPSERV) section CSRCESRV for an understanding of the
return code.
Action: Ironstream stops. If unable to resolve the error condition using the
above reference, contact Syncsort Product Support.
SDF0320A UNSUPPORTED CICS RELEASE
Explanation: The detected level of CICS is not supported.
SDF0323I STOPPING taskname TASK AT SHUTDOWN
Explanation: During SHUTDOWN processing, the named task is notified
to shut down.
SDF0324A [GATHERER|EXTRACTOR] TASK BEING CANCELLED DUE TO
TIMEOUT AT SHUTDOWN
Explanation: During SHUTDOWN processing, a task did not terminate
within 30 seconds of the order being sent to stop it, so it is being
automatically cancelled.
SDF0325I EXTRACTOR task_name ENDING. LAST MESSAGE PROCESSED
DATE AND TIME: date time
Explanation: The named extractor task is ending and is reporting the date
and time of the last message that it processed.
SDF0338A TASK task_name ENDED WITH SYSTEM ABEND CODE = ab,
REASON CODE = rsn
Explanation: The named task abnormally terminated with the abend code
and reason code given.
Action: If unable to correct the indicated problem, contact Syncsort
Product Support for assistance.

Ironstream Messages

SDF0339A TASK task_name ENDED WITH USER ABEND CODE = ab, REASON
CODE = rsn
Explanation: The named task abnormally terminated with the abend code
and reason code given.
Action: If unable to correct the indicated problem, contact Syncsort
Product Support for assistance.
SDF0340A TASK task_name ENDED WITH USER RETURN CODE = rc
Explanation: The named task terminated with a non-zero return code.
Action: Examine previous messages for the cause and if unable to correct
the indicated problem, contact Syncsort Product Support for assistance.
SDF0350A SYSLOG DATA COLLECTOR task_name DETECTED ERROR code
WHEN ACTIVATING A CONSOLE
Explanation: Activation of a console for Ironstream syslog message
collection has failed. One or more SYSLOG messages may not be
forwarded.
Action: Consult the MCSOPER section of the Authorized Assembler
Service Reference manual for an explanation of the codes. If unable to
correct, contact Syncsort Product Support.
SDF0351A SYSLOG DATA COLLECTOR task_name DETECTED ERROR code
WHEN GETTING A MESSAGE
Explanation: Retrieval of a syslog message has failed. One or more
SYSLOG messages may not be forwarded.
Action: Consult the MCSOPMSG section of the Authorized Assembler
SDF0352A SYSLOG DATA COLLECTOR task_name DETECTED AN ALREADY
ACTIVE CONSOLE
collection has failed because an Ironstream console is already active. One
or more SYSLOG messages may not be forwarded.
SDF0353I SYSLOG DATA COLLECTOR task_name CONSOLE HAS BEEN
ACTIVATED
collection was successful.
DEACTIVATED
Explanation: Deactivation of a console for Ironstream syslog message
collection was successful.

Ironstream Messages

SDF0355A SYSLOG DATA COLLECTOR task_name DETECTED ERROR CODE rc
WITH REASON CODE rsn WHEN DEACTIVATING A CONSOLE
Explanation: Deactivation of an Ironstream syslog console has failed. One
or more SYSLOG messages may not be forwarded.
Action: Consult the MCSOPER section of the Authorized Assembler
SDF0356A SYSLOG DATA COLLECTOR task_name DETECTED AN ALERT -
DEACTIVATING THE CONSOLE
Explanation: An unspecified alert was issued from the Ironstream
console. The console will be deactivated. One or more SYSLOG messages
may not be forwarded.
SDF0357A SYSLOG DATA COLLECTOR task_name DETECTED CONSOLE
QUEUEING STOPPED DUE TO MEMORY LIMITS
Explanation: An alert was issued from the Ironstream console. The
message data space is full. The console will be deactivated. One or more
SYSLOG messages may not be forwarded.
SDF0358A SYSLOG DATA COLLECTOR task_name DETECTED CONSOLE
QUEUEING STOPPED DUE TO QUEUE DEPTH LIMITS
maximum number of messages in the queue has been reached. The
console will be deactivated. One or more SYSLOG messages may not be
forwarded.
SDF0359A SYSLOG DATA COLLECTOR task_name DETECTED AN INTERNAL
SYSTEM ERROR ON CONSOLE
Explanation: An alert was issued from the Ironstream console. An
internal error was encountered. The console will be deactivated. One or
more SYSLOG messages may not be forwarded.
SDF0360A SYSLOG DATA COLLECTOR task_name RECEIVED A QUEUE DEPTH
ALERT
message queue alert percentage has been reached. The console will be
deactivated. One or more SYSLOG messages may not be forwarded.
SDF0361A SYSLOG DATA COLLECTOR task_name RECEIVED RETURN
CODE=rc, REASON CODE=rsn WRITING TO THE DATA STORE
Explanation: An error occurred while writing console message to the

Ironstream Messages

SDF0362A SYSLOG DATA COLLECTOR task_name RECEIVED AN ERROR
WHEN CALLING NAME/TOKEN SERVICES
Explanation: An error occurred while calling NAME/TOKEN services.
Action: Ironstream stops. If a restart of Ironstream fails to resolve this
issue contact your local Syncsort office; see “Diagnostics and Contacting
Syncsort Product Support,” on page 28-1.
SDF0363A DATA COLLECTOR task_name ENDED - LAST CAPTURED MESSAGE
AT time_date
Explanation: Ironstream syslog message collection has ended. The time of
the last successful message written to Ironstream data store is indicated.
SDF0364A SYSLOG DATA COLLECTOR task_name ERROR LOADING filter_name
ABEND CODE=ab, REASON CODE=rsn
Explanation: An error occurred while loading the Ironstream syslog
message filter table.
Action: Ensure module filter_name is in the Ironstream STEPLIB
concatenation.
DELETED
Explanation: The console for the Ironstream syslog message collection
was successfully deleted.
WITH REASON CODE rsn WHEN DELETING A CONSOLE
Explanation: Deletion of an Ironstream syslog console has failed.
Action: Consult the z/OS MVS Planning: Operations manual for an
explanation of the codes for CNZM1ERF. If unable to correct, contact
WITH REASON CODE rsn WHEN ESTABLISHING AN ESTAE
Explanation: The request to establish an ESTAE environment has failed.
Action: Consult the MVS Programming: Assembler Services Reference,
Volume 1 for an explanation of the codes for the ESTAE error. If you are
unable to correct this fault, contact your local Syncsort office, see
“Diagnostics and Contacting Syncsort Product Support,” on page 28-1.

Ironstream Messages

SDF0368A SYSLOG DATA COLLECTOR name: MESSAGE PROCESSING HAS
BEEN TEMPORARILY HALTED BY THE OPERATING SYSTEM DUE
TO TOO MANY MESSAGES IN THE QUEUE. SOME MESSAGES MAY
BE OMITTED
Explanation: The operating system’s internal queue of messages for
Ironstream to process has reached its maximum capacity. Ironstream will
re-enable message gathering, but this may cause the loss of some
messages.
Action: Consult the “MCSOPMSG - Retrieve MCS operator messages”
chapter in the MVS Programming: Authorized Assembler Services
Reference, Volume 3 (LLA-SDU) for Version 2, Release 2. If you are unable
to correct this fault, contact your local Syncsort office, see “Diagnostics
and Contacting Syncsort Product Support,” on page 28-1.
SDF0380A TCP CONNECTION ERROR MESSAGE: text
Explanation: An error was detected in TCP processing code as described
in the text.
Action: If the text is “httpack HTTPack send to HTTP endpoint”, review
the destination repository’s HTTP Event Collector definition and select
the Enable indexer acknowledgement check box. If you are unable to
correct the indicated problem, contact Syncsort Product Support.
SDF0381A SYSOUT FORWARDER ERROR MESSAGE: JOBNAME SELECTION
CANNOT BEGIN WITH A PERCENT SIGN
Explanation: When using SYSOUT Data Forwarding to query jobs, the
use of a percent sign wildcard ‘%’ is not allowed in the first position of the
jobname.
Action: The percent ‘%’ wildcard is allowed in positions 2-8. For optimum
performance, move the wildcard as far down a jobname as possible, such
as “MYJOBS%%”.

Ironstream Messages

SDF0381I SDF0381I SYSOUT FORWARDER: DATASET ALLOCATION
FAILED,R15=nn,S99EERR=ee, S99EINFO=ii,S99ERSN=rr,DSN=dsn
Explanation: Refer to the “Requesting dynamic allocation functions”
chapter (26) in the z/OS MVS Authorized Assembler User Guide. Then,
refer to the “Interpreting DYNALLOC return codes” section for a more
complete description of each code listed.
nn – This is the return code returned in register 15 by the DYNALLOC
function
ee – This is the error code returned by the DYNALLOC function
ii – This is the informational code returned by the DYNALLOC function
rr – This is the reason code returned by the DYNALLOC function
dsn – This is the data set name the DYNALLOC function was called for
Action: If the error is correctable by the user, make the correction. For
additional help interpreting the codes, contact Syncsort Product.
SDF0382I SYSOUT FORWARDER: <message>
Possible messages are:
ACQUIRE KEYLEN FAILED DDNAME=<ddname>,nnnn,nnnn
ACQUIRE RKP FAILED DDNAME=<ddname>,nnnn,nnnn
CLOSE FAILED DDNAME=<ddname>,nnnn,nnnn
GENCB BLK=EXLST,nnnn,nnnn
GENCB BLK=ACB,nnnn,nnnn
GENCB BLK=RPL,nnnn,nnnn
GET DATA FAILED,nnnn,nnnn
MODCB ERROR DDNAME=<ddname>,nnnn,nnnn
MODCB ERROR ARGADD DDNAME=<ddname>,nnnn,nnnn
MODCB ERROR AREAADD DDNAME=<ddname>,nnnn,nnnn
MODCB BLK=RPL
OPEN FAILED DDNAME=<ddname>,nnnn,nnnn
SET EODAD FAILED DDNAME=<ddname>,nnnn,nnnn
SHOW LEN FAILED,nnnn,nnnn
Explanation: During internal processing preparing Ironstream to read the
SYSOUT dataset, error conditions were raised as indicated. Returned
codes, and if applicable, reason codes are listed. These codes are from
VSAM data macros as noted, and are documented in the IBM manuals.
Refer to the accompanying messages for more information
Action: Contact Syncsort Product Support for further explanation.

Ironstream Messages

SDF0383I SYSOUT FORWARDER: DATASET FREE FAILED,
RC=nnnn,nnnn,nnnn
Explanation: During deallocation of the SYSOUT dataset, deallocation
returned error code, information code, and reason code as indicated. These
codes are from SVC 99, and as such are documented in the IBM manuals.
Refer to the accompanying messages for more information.
SDF0384I SYSOUT FORWARDER: SECURITY CHECK FAILED,
RC=nnnn,nnnn,nnnn
Explanation: Before allocation of the SYSOUT dataset, access to the
SYSOUT dataset is verified via a security request. The security product
return code, SAF return code, and SAF reason code are listed.
Action: The security request if made to the JESSPOOL security class,
with a profile of <jes node>.<data set name>, as per standard JESSPOOL
resource profile definitions. If necessary, contact Syncsort Product
Support for further explanation.
DETAIL DATA INCLUDES: JOBNAME=<jobname>,JOBID=<job id>
…JES FILE DETAILS,
DDNAME=<ddname>,STEPNAME=<stepname>,PROCSTEP=<procstep>
…JES FILE NAME=<JES file name>
…REQUESTED BY
JOBNAME=<jobname>,DDNAME=<ddname>,STEPNAME=<stepname>,
PROCSTEP=<procstep>
Explanation: This message accompanies other messages and contains
diagnostic information related to the previous message. Refer to the
previous message for an indication of the error.
SDF0386I SYSOUT FORWARDER: POINT FAILED,
RETURNCD=nnnn,REASONCD=nnnn
Explanation: An attempt was made to position the reading of the
SYSOUT file and failed.

Ironstream Messages

ADD FIFO FAILED
GET FIFO FAILED
RTN FIFO FAILED
Explanation: During internal processing required to preparing the
Ironstream JSON event for forwarding, an internal FIFO queue had an
error. Refer to the accompanying messages for more information.
SDF0389I SYSOUT FORWARDER:
AQE=nnnn,RETURNCD=nnnn,REASONCD=nnnn
Explanation: During internal processing, an error occurred and DEBUG
was active. The internal active queue is listed. This message and
SDF0385I will be listed for each queue element. Refer to the
accompanying messages for more information.
SDF0390I SYSOUT FORWARDER: JOBNAME SELECTION CANNOT BEGIN
WITH A PERCENT SIGN
Explanation: Jobname wildcard specification for selection cannot begin
with a percent sign.
Action: Correct the JOBNAME selection criteria and try again.
Explanation: Header message issued at start of a set of statistics
messages.
SDF0401I TASK NAME TCB TIME MESSAGES IN MESSAGES OUT
Explanation: Column heading message for SDF0402I messages that
follow.
SDF0402I task_name ssss.thtthm messages_in messages_out
Explanation: task_name is the internal name given to each subtask,
ssss.thtthm is the TCB time for the task in seconds and microseconds,
messages_in is the count of the input messages the task has processed,
regardless of whether or not any data was processed, messages_out is the
count of output messages that have been processed.
Explanation: Header message issued for each Splunk destination.

Ironstream Messages

SDF0404I splunk_index_name ssss.thtthm
Explanation: splunk_index_name is the first 20 bytes of the Splunk
indexer name to which the data is being sent.
ssss.thtthm is the elapsed time for TCP in seconds and microseconds.
Explanation: This is a header message for statistics for each TCP
connection defined to SDF. Each SDF0406I message that follows reports
the IP address, the PORT address, its current status, the number of
records processed and the number of bytes sent over that TCP connection.
SDF0406I ------------ ------ -------- --------- ------- -------
Explanation: Header messages issued for each TCP connection for a
SDF0407I nnn.nnn.nnn.nnn ppppp cccccccccccc rrrrrrrrrrrrrrr bbbbbbbbbbbbbbb
Explanation: nnn.nnn.nnn.nnn is the numerical IPv4 address the data is
being sent to.
ppppp is the port number on which the destination repository or Heavy
Forwarder is listening for data.
cccccccccccc is the status of the connection, either CONNECTED or
DISCONNECTED.
rrrrrrrrrrrrrrr is the number of TCP records sent using this connection.
bbbbbbbbbbbbbbb is the number of bytes of data sent using this
connection.
SDF0408I TOTALS rrrrrrrrrrrrrrr bbbbbbbbbbbbbbb
Explanation: This message reports the totals for all connections
associated with a destination repository.
rrrrrrrrrrrrrrr is the total number of TCP records sent to the destination
repository.
bbbbbbbbbbbbbbb is the TOTAL number of bytes of data sent to the
SDF0410I ZIIP ACTIVE TIME ssssssss.thtthm
Explanation: This message reports the zIIP processor time in seconds and
microseconds.
SDF0411I ZIIP ON CP TIME ssssssss.thtthm
Explanation: This message reports the general processor time in seconds
and microseconds for work that could have been dispatched on a zIIP
processor.

Ironstream Messages

SDF0414I NO FILTERS ACTIVE FOR GATHERER TASK name
Explanation: This message is issued when the type of data being gathered
does not support filtering.
SDF0415I LIST OF [SMF|SYSLOG] RECORDS BEING CAPTURED BY
GATHERER TASK name
Explanation: This is a header message for the type of messages being
captured.
SDF0416I SMF RECORD nnn <SUBTYPE nn>|SYSLOG PREFIX xxx
Explanation: One such message is issued for each record type that is
being captured. For SMF records, ‘SUBTYPE nn’ is only appended to the
message when subtype filtering is active for the given SMF record.
SDF0420I task MESSAGES DELETED BY function PROCESSING: nnn
Explanation: This informational message lists the number (nnn) of
messages that were deleted as a result of the specified task performing
either the JSON formatting of SMF 110 records or the SMF WHERE
search clause function.
Messages are generally deleted by the JSON formatting process when
processing certain SMF 110 records with unsupported subtypes.
Messages are deleted by the SMF WHERE process when the result of the
WHERE search clause results in a FALSE condition.
SDF0421I QUIESCE ENTERED - OUTSTANDING ACKS: nnn
Explanation: The quiesce process for an Ironstream shutdown has
started. nnn represents the number of outstanding DLP
acknowledgements.
SDF0422I QUIESCE OUTSTANDING ACKS: nnn
Explanation: The quiesce process is proceeding. nnn represents the
outstanding DLP acknowledgements reported. This message is issued
once per second until nnn reaches zero.
SDF0423I TIMEOUT FOR ACKID nnn BLOCK LOW X'hhhh HIGH X'hhhh
Explanation: A DLP acknowledgement has exceeded its retry time and
has been marked as timed-out. nnn is the acknowledgement ID. The first
X'hhhh is the low CF block number for the acknowledgement, the second
X'hhhh is the high CF block number for the acknowledgement.

Ironstream Messages

SDF0424I UNEXPECTED HTTP CODE: %%
Explanation: An unhandled HTTP code has been returned by the
destination, where %% details the code. This message is followed by a
dump of the headers and content.
Action: Review your Ironstream and network configuration. If the reason
for this error is unexplained by either configuration, then contact
SDF0425I SPLUNK SEND REPLY ERROR: %%
Explanation: An unhandled status code has been returned by Splunk,
where %% describes the error. This message is followed by a dump of the
reply.
Action: Review your Ironstream and network configuration. If the reason
for this error is unexplained by either configuration, then contact
SDF0450I LOG STREAM stream_name HAS BEEN CONNECTED TO
Explanation: A connection has been successfully made to the coupling
facility using stream_name.
SDF0451I LOG STREAM stream_name HAS BEEN SET TO READ OLDEST
MESSAGES FIRST
Explanation: The log stream stream_name will be read in oldest to newest
message sequence.
SDF0452I A COLD START OF LOG STREAM stream_name HAS BEEN
PERFORMED
Explanation: All data in the log stream stream_name has been deleted.
SDF0453A ASCRE FAILED WITH RETURN CODE = rc AND REASON CODE = rsn
Explanation: While attempting to start the auxiliary address space, the
ASCRE system function returned with the given return and reason codes.
The Ironstream task terminates.
Action: If a failure is indicated and it is user-correctable, correct the
problem. In all other cases, contact Syncsort Product Support.
SDF0454I ADDRESS SPACE space_name ALREADY STARTED
Explanation: When performing a DLP warm start, the named address
space was already running.
SDF0455I STARTING ADDRESS SPACE space_name
Explanation: The named address space is being started.

Ironstream Messages

SDF0456A COUPLING FACILITY function FUNCTION FAILED WITH A RETURN
CODE = rc AND REASON CODE = rsn WITH THE FOLLOWING
MESSAGE: text
Explanation: A call to the coupling facility for the specified function failed
with the given return and reason codes. A message is also reported.
Action: If the message indicates an automatic retry is being done, no
action is needed. If a failure is indicated and it is user-correctable, correct
the problem. In all other cases, contact Syncsort Product Support.
SDF0457A COUPLING FACILITY function FUNCTION FAILED WITH A RETURN
CODE = rc AND REASON CODE = rsn
Explanation: If the message indicates an automatic retry is being done, no
action is needed. If a failure is indicated and it is user-correctable, correct
the problem.
Action: In all other cases, Contact Syncsort Product Support.
SDF0458A ADDRESS SPACE space_name FAILED TO START
Explanation: The named address space did not POST back to the main
Ironstream instance that it was initialized in. The Ironstream task
terminates.
Action: Examine the console logs and job outputs to determine the cause.
If you are unable to determine and/or correct the issue, contact Syncsort
Product Support.
SDF0459A ADDRESS SPACE space_name FAILED TO STOP
Explanation: The named address space did not terminate in the expected
time interval.
Action: Examine the console logs and job outputs to determine the cause.
If you are unable to determine and/or correct the issue, contact Syncsort
Product Support.
SDF0460A STOPPING ADDRESS SPACE space_name
Explanation: The named address space is being stopped.
SDF0469A "TARGET":"KAFKA" AND "DATA_LOSS_PREVENTION":"YES" ARE
MUTUALLY EXCLUSIVE OPTIONS IN THIS RELEASE.
Explanation: KAFKA and Data Loss Prevention (DLP) are mutually
exclusive.
Action: Run Kafka without the DLP feature by removing
"DATA_LOSS_PREVENTION":"YES" and associated parameters from
the configuration file.

Ironstream Messages

SDF0470A "DATA_LOSS_PREVENTION":"YES" AND "TYPE":"TCP" ARE
MUTUALLY EXCLUSIVE OPTIONS IN THIS RELEASE
Explanation: DATA_LOSS_PREVENTION requires a HTTP or HTTPS
type of connection.
Action: Remove "DATA_LOSS_PREVENTION":"YES" and associated
parameters from the configuration file or add "TYPE":"HTTP/HTTPS"
and "TOKEN":"token_value" parameters.
SDF0471I REALLOCATING RESEND BUFFER FAILED USING SIZE OF nnnnn
Explanation: During Data Loss Prevention resend processing, the
reallocation of a larger buffer to process messages failed. The record being
processed is printed in hex format following this message and then
bypassed.
Action: To prevent this from happening, you should increase the REGION
size specified, or preferably specify REGION=0M. If you have already
specified REGION=0M, then contact Syncsort Product Services.
SDF0472I REALLOCATING RESEND BUFFER USING PREVIOUS SIZE OF
nnnnn
Explanation: Following the failed attempt at buffer reallocation, as
described in message SDF0471I, the buffer size that was in use is
allocated.
SDF0473I REALLOCATED RESEND BUFFER. PREVIOUS SIZE = nnnnn NEW
SIZE = nnnnn
Explanation: During Data Loss Prevention resend processing, the need
for reallocation of a larger buffer to process messages was detected.
SDF0501A XCF INTERFACE task_name DETECTED ERROR CODE rc WITH
REASON CODE rsn WHEN ESTABLISHING AN ESTAE
Explanation: Ironstream’s XCF support encountered an error when
attempting to establish an ESTAE recovery environment. The return and
reason codes are given in the message text by rc and rsn respectively.
Action: Refer to the section ‘ESTAE and ESTAEX - Specify Task
Abnormal Exit Extended’, in the MVS Programming: Authorized
Assembler Services Reference, Volume 2 (EDT-IXG) for information on
the cause of the failure. If you are unable to resolve the error and
restarting the product continues to fail, contact your local Syncsort Office.
See “Diagnostics and Contacting Syncsort Product Support,” on page 28-1.

Ironstream Messages

SDF0502A XCF INTERFACE task_name RECEIVED AN ERROR WHEN CALLING
NAME/TOKEN SERVICES
Explanation: The XCF interface could not be established by the
name/token used by Ironstream and the initialization will fail as a
consequence.
Action: If you are unable to resolve the error by restarting the product,
contact your local Syncsort Office. See “Diagnostics and Contacting
SDF0503A XCF GATHERER task_name IS new_status AT time ON date
DUE TO reason
Explanation: This message is issued to confirm a change of status in
Ironstream’s XCF gatherer task at the time and on the date given in the
message text.
new_status can be either ACTIVE or INACTIVE and the reason for the
status change is given by reason and can be set to one of:
INITIAL CONNECTION when the gatherer is first started
TASK TERMINATION when the gatherer task is
shut down
DATA STORE FULL when the task has been deactivated
because the Data Store has filled
DATA STORE AVAILABLE when the task is reactivated
because the Data Store full
condition has been relieved
SDF0504A XCF PARTNER XCF_member ACTIVE AT time ON date
Explanation: This message is issued as confirmation that Ironstream’s
XCF interface has detected the named XCF member joining its XCF
group. Data can now flow between Ironstream and the named partner.
SDF0506I XCF FUNCTION IXCJOIN|IXCLEAVE|IXCQUERY FAILED WITH
RETURN CODE nnnn AND REASON CODE nnnn
Explanation: A JOIN, LEAVE, or MEMBER QUERY request failed with
the noted return and reason codes.
Action: Refer to the z/OS MVS Programming: Sysplex Services Reference
for the appropriate return and reason codes. If you cannot resolve the
issue, then contact Syncsort using the information in “Diagnostics and
Contacting Syncsort Product Support,” on page 28-1.

Ironstream Messages

SDF0507S AN XCF RECORD OF nnnn BYTES EXCEEDS THE MAXIMUM
SUPPORTED LENGTH OF mmmm BYTES. THE FIRST 256 BYTES OF
THE RECORD WILL BE PRINTED AND THE RECORD WILL BE
DELETED.
Explanation: When processing a record presented to Ironstream via the
XCF interface, the record nnnn exceeded the maximum supported length
mmmm that can be stored in the data store. The first 256 bytes of the
record are printed and the record is deleted.
Action: Try reducing the MaxNumMetrics value set in the RMFSettings
group, which may help to manage XCF maximum record size limitation.
For more information, see “Define RMFSettings” on page 23-3.
SDF0550A MODULE modname CANNOT FIND SSDFINST STRUCTURE AT
address IN SSDFSTAT_INSTANCE_PTR LIST
Action: Contact Syncsort using the information in “Diagnostics and
SDF0505A XCF PARTNER XCF_member INACTIVE AT time ON date
Explanation: Ironstream’s XCF interface has detected the named XCF
member leaving its XCF group. Data can no longer flow between
Ironstream and the named partner.
SDF0551A STORAGE [obtain/release] OF n BYTES FAILED IN MODULE modname
SDF0552A SSDFDELC FAILURE WITH RC = rc WHEN CALLED BY MODULE
modname
SDF0553A MODULE modname CANNOT FIND SSANCHOR IN CUSTOMER
ANCHOR TABLE
SDF0554A MODULE modname CANNOT FIND SSDFSTAT IN SSANCHOR
STRUCTURE
SDF0555A MODULE modname CANNOT FIND VALID SSDFCVEC POINTER FOR
CLASS nnn

Ironstream Messages

SDF0556A MODULE modname CANNOT FIND SSDFINST STRUCTURE AT
address IN SSDFS TAT_CLASS_PTR LIST'
SDF0557A MODULE modname CANNOT VALIDATE THE structure_name
STRUCTURE AT LOCATION address
SDF0560A MODULE modname DETERMINED THE SS NUMBER TO BE
INVALID
SDF0561A MODULE modname FAILED TO OBTAIN ENQ ON
IRONSTRM/STATABLE'
SDF0562A MODULE modname DETRMINED SSNUMBER IS NON ZERO AND
HAS ALREADY BEEN USED
SDF0563A MODULE modname FAILED FINDING THE LENGTH OF THE
MODULE
SDF0564A DEFINE ENTRY TABLE FAILED IN MODULE modname
SDF0565A AUTHORIZE PC FOR ALL ADDRESS SPACES FAILED IN MODULE
modname
SDF0566A MODULE modname FAILED TO GET THE SYSTEM LX FOR THE PC
ROUTINE

Ironstream Messages

SDF0567A DEFINE ENTRY TABLE DESCRIPTOR FAILED IN MODULE
modname
SDF0568A MODULE modname FAILED TO CONNECT ENTRY TABLE AND
SYSTEM LX
SDF0569A MODULE modname FAILED TO FREE THE SYSTEM LX
SDF0591A FAILURE RESETTING LOG STREAM TO REREAD THE RECORD
WITH THE BLOCKID OF nn. THE FIRST RECORD RETURNED HAS A
BLOCKID OF mm.
Explanation: During resend processing using the DLP feature, there was
a failed request to re-read the block with an ID of nn from the coupling
facility. The lowest block available has an ID of mm.
Action: The record with the BLOCKID of nn is lost. Contact Syncsort
using the information in “Diagnostics and Contacting Syncsort Product
Support,” on page 28-1.
SDF0592A THE DATA TO RECOVER WILL OVERFLOW THE SIZE OF THE
RECOVERY BUFFER. THE BLOCKID OF THE LAST RECORD TO
RECOVER IS nn.
Explanation: During resend processing using the DLP feature, a request
to re-read the block with an ID of nn from the coupling facility will result
in an overflow of the resend buffer.
SDF0593A ERROR READING RECOVERY DATA FROM THE LOG STREAM. ONE
OR MORE RECORDS MAY BE MISSING. THE BLOCKID OF THE
LAST RECORD WAS nn. THE BLOCKID OF THE RETURNED
RECORD IS %%
a failed request to re-read the block with an ID of nn from the coupling
facility because the block was not found. The next BLOCKID found was
mm.

Ironstream Messages

SDF0594A FAILURE RESETTING THE LOG STREAM TO THE LAST
PROCESSED RECORD. THE BLOCKID REQUESTED WAS nn. THE
BLOCKID OF THE RECORD RETURNED WAS mm.
a failed request to reset the next record to read from the coupling facility
to nn. The next BLOCKID found was mm.
SDF0600S SDF - UNRECOGNIZED COMMAND. REQUEST IGNORED
Explanation: An unrecognized MODIFY command was issued.
Action: The only valid MODIFY command for Ironstream is STATUS.
Reissue the command correctly.
SDF0601I SDF OPERATOR REQUESTED STATISTICS AT time ON date
Explanation: At the indicated time and date, an operator entered a
MODIFY,STATUS command. Messages SDF0400 through SDF0408
follow.
SDF0602I SDF TERMINATION STATISTICS AT time ON date
Explanation: As part of termination processing at the indicated time and
date, statistics are generated. Messages SDF0400 through SDF0408
follow.
SDF0605I SDF INITIALIZATION COMPLETE
Explanation: Ironstream has completed initialization processing and is
ready to process data.
SDF0607I SDF TERMINATION IN PROGRESS
Explanation: Ironstream has received a STOP command and is in the
process of terminating the processing of data.
SDF0610S SDF TERMINATED DUE TO CRITICAL ERROR
Explanation: A critical error has occurred and Ironstream is shutting
down.
Action: Examine the SYSPRINT file and syslog for additional messages
detailing the critical error.
SDF0612A SDF LOAD FAILURE FOR MODULE modname, ABEND CODE = ab,
REASON CODE = rsn
Explanation: While issuing a LOAD for the module named, an ABEND
occurred.
Action: Look in the MVS Systems Codes manual for an explanation of the
ABEND code and REASON code.

Ironstream Messages

SDF0613A SDF CANCELING MODULE modname
Explanation: The task with modname as the called program is being
canceled due to an error in another task.
Action: Examine the SYSPRINT file and syslog for additional messages
detailing the previous error.
SDF0614S SDF ALREADY ACTIVE. REQUEST IGNORED
Explanation: An attempt was made to start another instance using the
same [SYSTEM] name. The start-up is terminated.
Action: Assign a different "NAME":"instance_name" and restart.
SDF0615A SDF LOAD LIBRARY MUST BE APF AUTHORIZED. TERMINATING
Explanation: All load libraries in the JOBLIB or STEPLIB concatenation
used to run Ironstream must be APF authorized. The start-up is
terminated.
Action: Authorize the required libraries and restart.
SDF0616A SDF - UNSUPPORTED OPERATING SYSTEM. TERMINATING
Explanation: Ironstream is compatible with levels of z/OS that are fully
supported by IBM and has detected an unsupported z/OS level.
Action: Run Ironstream on an LPAR with a supported z/OS level.
SDF0617A SDF - UNSUPPORTED HARDWARE LEVEL. TERMINATING
Explanation: Ironstream is compatible with z/Architecture hardware that
is fully supported by IBM and has detected unsupported hardware.
Action: Run Ironstream on an LPAR with supported z/Architecture
hardware.
SDF0618A LOG4J DATA COLLECTOR task_name RECEIVED AN ERROR WHEN
CALLING NAME/TOKEN SERVICES
Explanation: An error occurred while calling NAME/TOKEN services.
Action: Restart Ironstream. If the problem persists, contact Syncsort
Product Support.
SDF0619A LOG4J DATA COLLECTOR task_name RECEIVED RETURN CODE=rc,
REASON CODE=rsn WRITING TO THE DATA STORE
Explanation: An error occurred while writing Log4j messages to the
Ironstream data store. The Ironstream task terminates.
Action: Restart Ironstream. If unable to resolve, contact Syncsort Product
Support.

Ironstream Messages

SDF0620A INITIALIZATION OF C ENVIRONMENT FAILED FOR LOG4J
GATHERER task_name
Explanation: The SDFAppender on OMVS will collect Log4j log data and
send the data to z/OS Ironstream through a namedpipe; Ironstream uses
the C language to get records from the namedpipe. This message indicates
that an error occurred during the initialization of the Language
Environment for C.
Support.
SDF0621A AN ERROR OCCURRED WHILE ATTEMPTING TO OPEN AND GET
DATA FROM A NAMEDPIPE. CHECK THE VALIDITY OF THE
NAMEDPIPE.
Explanation: The call to open the named pipe failed.
Action: Ensure that the named pipe has a valid UNIX file name.
SDF0622A CANNOT CREATE THE CONNECTION FROM OMVS TO DATA
STORE FOR LOG4J
Explanation: An error occurred while creating a named pipe - mkfifo()
failed for the named pipe.
Action: Ensure that the user has the authority to create a named pipe.
SDF0623I SDFAPPENDER IS UP AT: date_time
Explanation: This information message is issued on the OMVS console
and indicates the date/time that the SDFAPPENDER was up for Log4j.
SDF0624I LOG4J DATA COLLECTOR task_name IS READY TO COLLECT DATA
Explanation: This z/OS console message indicates that the Log4j data
collector is ready.
SDF0625I SDFAPPENDER STARTED TO SEND RECORDS AT: date_time
Explanation: This OMVS console message indicates the date/time that the
SDFAPPENDER sent the first record.
SDF0626I SDFAPPENDER NAMEDPIPE IS: pipe_name
Explanation: This OMVS console message which indicates the named pipe
that the SDFAPPENDER is using.
SDF0627A THE CONNECTION BETWEEN SDFAPPENDER AND DATA STORE
IS BROKEN AT: date_time
Explanation: The SDFAPPENDER issues this message when the
Ironstream server on z/OS is down.

Ironstream Messages

SDF0628A EXCEPTION OCCURRED IN SDFAPPENDER
Explanation: An internal Java exception occurred in the SDFAPPENDER
for Log4j.
SDF0629I THE CONNECTION BETWEEN SDFAPPENDER AND DATA STORE
IS BUILT FROM date_time
Explanation: This OMVS console message indicates the date/time that the
SDFAPPENDER connected to the Ironstream z/OS server.
SDF0630I SDFAPPENDER TIMEZONE IS: timezone
Explanation: This OMVS console message indicates the time zone that
the SDFAPPENDER is using.
SDF0631A LOG4J DATA COLLECTOR task_name DETECTED ERROR CODE rc
WITH REASON CODE rsn WHEN ESTABLISHING AN ESTAE
Explanation: The attempt to create an ESTAE failed with a return code of
rc and a reason code of rsn. Refer to the section ESTAE and ESTAEX -
Specify task abnormal exit extended, in the manual MVS Programming:
Authorized Assembler Services Reference, Volume 2 (EDT-IXG) to
understand the cause of the failure.
Action: If unable to resolve the error using the above reference, contact
SDF0632I SDFAppender encoding is: codepage
Explanation: This OMVS console message indicates the system code page.
SDF0633A The connection between SDFAppender and data store doesn’t exist or
broken
Explanation: This message is issued when the SDFAppender attempts to
send log4j data to Ironstream, but the Ironstream log4j forwarder is not
active.
Action: Start the Ironstream log4j forwarder on your z/OS system.
SDF0634I SDFAppender date format is: default_z/OS_date_format
Explanation: If the optional “dateformat” parameter is set to “zos”, then
this OMVS console message indicates that log4j will use default z/OS date
format.
SDF0635I SDFAppender data is in original log4j format
Explanation: If the optional “datatype” parameter is set to “original”, then
this OMVS console message indicates that original log4j data is sent to
the destination repository. Otherwise, Ironstream JSON format is sent to
the destination repository.

Ironstream Messages

SDF0650A TASKNAME taskname IS NOT A VALID TASK NAME
Explanation: The specified task name was not of the correct format. Task
names must be eight characters long and begin with either GATH or
EXTR.
Action: Use the name specified in messages SDF0124I, SDF0655Sm or
SDF0656S.
SDF0651A TASKNAME taskname IS NOT A RECOGNIZED TASK
Explanation: The specified task name was not found.
Action: Use the name specified in messages SDF0124I, SDF0655S, or
SDF0656S.
SDF0652A TASKNAME taskname IS STILL AN ACTIVE TASK
Explanation: The specified task name was determined to be still active.
Action: Use the name specified in messages SDF0124I, SDF0655S, or
SDF0656S.
SDF0653A TASKNAME taskname IS RESTARTED
Explanation: The specified task name has been restarted.
SDF0654S TASKNAME taskname HAS FAILED ON RESTART

Explanation: The specified task failed to initialize on restart.
Action: Attempt to determine and correct the cause. If your are unable to
determine the cause, contact Syncsort Product Support.
SDF0655S TASKNAME taskname HAS BEEN SUSPENDED DUE TO REPEATED
FAILURES
Explanation: The specified task name failed twice within 10 seconds and
no additional restarts will be attempted.
Action: Attempt to determine and correct the cause. If the cause can be
determined, use a RESTART console command to force a restart of the
task. If you are unable to determine the cause, contact Syncsort Product
Support.
SDF0656S TASKNAME taskname HAS TERMINATED
Explanation: The specified task name has terminated.
Action: No action is needed. If "AUTO_RESTART":"YES" is active,
Ironstream will restart the task.

Ironstream Messages

SDF0657A ATTACH FAILURE RC = return_code FOR TASKNAME taskname AND
MODNAME pgmname
Explanation: The ATTACH of program pgmname for the specified
taskname failed with a return code of return_code.
Action: Attempt to determine and correct the cause. If the cause can be
determined, use a RESTART console command to force a restart of the
task. If unable to determine the cause, contact Syncsort Product Support.
SDF0658I TASKNAME taskname IS BEING RESTARTED
Explanation: The specified task name is being restarted.
SDF0659I TASKNAME taskname HAS BEEN SUSPENDED DUE TO OPTION
"AUTO_RESTART":"NO"
Explanation: The specified task name failed and no restarts will be
attempted due to the option being selected.
Action: Attempt to determine and correct the cause of the failure. If the
cause can be determined, use a RESTART console command to force the
restart of the task. If you are unable to determine the cause, contact
SDF0702A SDF - SMF EXIT module system_exit_name FAILED - RETURN CODE =
rc, REASON CODE = rsn
Explanation: When the capture of SMF records is requested, Ironstream
will dynamically install the exits into the operating system. This message
indicates for exit system_exit_name and load module module, the dynamic
installation failed with a return code rc and a reason code rsn. Refer to the
section CSVDYNEX-Provide dynamic exits service, in the manual MVS
Programming: Authorized Assembler Services Reference, Volume 1
(ALE-DYN) to understand the cause of the failure. The Ironstream task
terminates.
SDF0703A SDF - SMF CAPTURE SHUTTING DOWN - REVIEW PREVIOUS
ERROR
Explanation: Errors have been detected while establishing the
environment to capture SMF records.
Action: Ironstream Stops. Review previous messages for resolution to the
cause.

Ironstream Messages

SDF0704I SDF LOAD FOR MODULE mod_name SUCCESSFUL
will dynamically establish the appropriate environment. To do so,
required modules are loaded into memory. This message notes the
successful load of module mod_name.
SDF0705I SDF - SMF EXIT system_exit_name - SUCCESSFULLY message
will dynamically establish the appropriate environment. message will be
replaced with the following text to indicate the current phase of the
environment establishment:
ADDED AS A SYSTEM SMF EXIT - STATE=INACTIVE
ACTIVATED AS A SYSTEM SMF EXIT
SDF0706A SDF - SMF EXIT UNSUCCESSFULLY message
will dynamically establish the appropriate environment. message will be
replaced with the following text to indicate the current phase of the
environment establishment:
LISTED - rc rsn
ACTIVATED - module - system_exit_name - rc - rsn
DELETED - module - system_exit_name - rc - rsn
ADDED - module - system_exit_name - rc - rsn
INACTIVATED - module - system_exit_name - rc - rsn
This message indicates for exit system_exit_name and load module
module, the dynamic installation failed with a return code rc and a reason
code rsn. Refer to the section CSVDYNEX-Provide dynamic exits service,
in the manual MVS Programming: Authorized Assembler Services
Reference, Volume 1 (ALE-DYN) to understand the cause of the failure.

Ironstream Messages

SDF0707I TASK taskname - ESTAE INIT FAILED. RETURN CODE = rc, REASON
CODE = rsn
will dynamically establish the appropriate recovery environment. An
ESTAE is requested to protect the SMF support environment running in
the Ironstream address space. The attempt to create with protection
failed with a return code of rc and a reason code of rsn. Refer to the section
ESTAE and ESTAEX - Specify task abnormal exit extended, in the
manual MVS Programming: Authorized Assembler Services Reference,
Volume 2 (EDT-IXG) to understand the cause of the failure.
SDF0708I REQUESTED GATHERING OF SMF TYPE=XX, BUT SMF NOT
RECORDING RECORD TYPE VIA YYYYYYYY, EXIT=ZZZZZZ
Explanation: Ironstream recognized the request to forward an SMF record
type to the destination repository. A test of SMF revealed this record type
was not being recorded.
TYPE XX is the SMF record type requested for gathering.
YYYYYYY is either:
SYSTEM for requests defaulting to the SYS option for SMF recording, or
SUBSYS=wwww, where wwww is a four-character SUBSYS as defined in
SMF parameters using one of the exits IEFU83, IEFU84, or IEFU85.
EXIT ZZZZZZ is the name of the SMF exit that is required to be activated
to ensure proper gathering of SMF records. It will be IEFU83, IEFU84, or
IEFU85.
Action: This message is informational. It should be carefully examined to
make sure there is not an SMF PARMLIB oversight, or a spurious
addition required for gathering. Remove the SMF type from gathering, or
add it to the SMF PARMLIB recording options.
Ignore this message if you are using the offline SMF ingestion facility.

Ironstream Messages

SDF0709I REQUESTED GATHERING OF SMF SUBTYPE=XX FOR TYPE=XX,
BUT SMF NOT RECORDING RECORD TYPE VIA YYYYYYYY,
EXIT=ZZZZZZ
Explanation: Ironstream recognized the request to forward a SMF record
subtype to the destination repository. A test of SMF revealed this record
subtype was not being recorded.
SUBTYPE XX is the SMF record type and SMF record subtype (as
denoted in the message) requested for gathering.
YYYYYYY is either:
SYSTEM for requests defaulting to the SYS option for SMF recording, or
SUBSYS=wwww where wwww is a four-character SUBSYS as defined in
SMF parameters using one of the exits IEFU83, IEFU84, or IEFU85.
EXIT ZZZZZZ is the name of the SMF exit that is required to be activated
to ensure proper gathering of SMF records. It will be IEFU83, IEFU84, or
IEFU85.
addition required for gathering. Remove the SMF subtype from gathering,
or add it to the SMF PARMLIB recording options.
Ignore this message if you are using the offline SMF ingestion facility.
SDF0710I SMF COLLECTION DONE AT SYSTEM LEVEL DOES NOT INCLUDE
THE REQUIRED EXIT ZZZZZZ
Meaning: Ironstream tests the SYS option against the three SMF exits
Ironstream uses. If the noted level doesn't use all required exits, this
message is produced.
ZZZZZZ is the name of the SMF exit that is required to be activated to
ensure proper gathering of SMF records. It will be IEFU83, IEFU84, or
IEFU85.
make sure all SMF SUBSYS options include all SMF types requested, or
the global SYS option is specified to be used when a SUBSYS parameter is
not selectable. This may be an SMF PARMLIB oversight, or a spurious
addition required for gathering. One option is to add the use of the
denoted exit to the SYS option of the SMF PARMLIB recording options.

Ironstream Messages

SDF0711I SMF COLLECTION DONE FOR SUBSYSTEM WWWW INCLUDED
EXIT ZZZZZZ, BUT NOT REQUIRED EXIT ZZZZZZ
Meaning: Ironstream recognized the designation of a specific SUBSYS
parameter in an SMF exit statement. Ironstream tested this SUBSYS
parameter against the three SMF exits Ironstream uses. If the noted
SUBSYS does not use all required exits, this message is produced.
WWWW is a four-character SUBSYS as defined in SMF parameters using
one of the exits IEFU83, IEFU84, or IEFU85.
ZZZZZZ is the name of the SMF exit that is required to be activated to
ensure proper gathering of SMF records. It will be IEFU83, IEFU84, or
IEFU85.
addition required for gathering. One option is to add the use of the
denoted exit to the specified SUBSYS option of the SMF PARMLIB
recording options.
SDF0712I SMF NUMBER nn IS BEING USED TO COLLECT IRONSTREAM
MONITORING STATISTICS
Explanation: This informational message enumerates the SMF record
type (nn) that Ironstream will write to record Ironstream activity.
SDF0713I SMF NUMBER nn IS NOT ACTIVELY BEING RECORDED BY SMF
Explanation: This informational message is issued when Ironstream
determines that the operating system has not been configured to collect
the Ironstream monitoring SMF record.
Action: Modify the SMFPRMxx member in SYS1.PARMLIB to collect
SMF record type nn. At a future date, recording this SMF record will be
required for Ironstream to run.
SDF0714I SMF NUMBER nn WRITE FAILED, RC=rc
Explanation: This message is issued when a write of an Ironstream
monitoring SMF record fails.
Action: If this message is issued frequently, please contact Syncsort
Product Support.
SDF0801I SDF OFFLINE SMF READER FACILITY STARTING
Explanation: An offline SMF ingestion process has started.
SDF0802I SDF OFFLINE SMF READER COMPLETED
Explanation: An offline SMF ingestion process has completed normally.

Ironstream Messages

SDF0803A OFFLINE SMF READER taskname RECEIVED RETURN CODE= rc,
REASON CODE = rsn WRITING TO THE DATA STORE
Explanation: An error occurred while writing offline SMF data to the
SDF0811I SDF OFFLINE SYSLOG READER FACILITY STARTING
Explanation: An offline syslog ingestion process has started.
SDF0812I SDF OFFLINE SYSLOG READER COMPLETED
Explanation: An offline syslog ingestion process has completed normally.
SDF0813A OFFLINE SYSLOG READER taskname RECEIVED RETURN CODE=
rc, REASON CODE = rsn WRITING TO THE DATA STORE
Explanation: An error occurred while writing offline syslog data to the
SDF0821I SDF OFFLINE LOG4J READER FACILITY STARTING
Explanation: An offline Log4j ingestion process has started.
SDF0822I SDF OFFLINE LOG4J READER COMPLETED
Explanation: An offline Log4j ingestion process has completed normally.
SDF0823A OFFLINE LOG4J READER taskname RECEIVED RETURN CODE= rc,
REASON CODE = rsn WRITING TO THE DATA STORE
Explanation: An error occurred while writing offline Log4j data to the
SDF0824A OFFLINE LOG4J READER SDFRecover.java DETECTED ERROR
WITH REASON CODE rsn
Explanation: An offline Log4j ingestion process encountered an internal
error.
SDF0825A OFFLINE LOG4J READER - error
Explanation: An offline Log4j ingestion process encountered an error.
Normally this is a user error, see the error description for the reason.
SDF0826I THE CONNECTION BETWEEN SDFRECOVER AND DATA STORE IS
BUILT FROM date_time
Explanation: This OMVS java code message indicates the date/time that
the Log4j READER on OMVS connected to the Ironstream z/OS server.
SDF0827I OFFLINE LOG4J READER SUCCESSFULLY FINISHED, n RECORDS
WERE SENT
Explanation: This OMVS java code message indicates that the Log4j
READER java modules on OMVS successfully finished. n indicates the
number of records that were read and sent.

Ironstream Messages

SDF0828I UNSUPPORTED SECURITY PRODUCT
repository, Ironstream detected an unsupported security product being
used. The SMF record will be ignored.
SDF0829I UNSUPPORTED TOP SECRET DATA TYPE datatype, RECORD DATE:
yyyy-mm-dd AND TIME : hh:mm:ss.th
repository, Ironstream detected an unsupported data source. Only the
header part will be sent to the destination repository.
SDF0830I TOP SECRET RECORD HAS WRONG TRIPLET COUNT, RECORD
DATE: yyyy-mm-dd AND TIME : hh:mm:ss.th
repository, Ironstream detected an incorrect triplet count in the record;
according to the RDW of the record, only one occurrence of the variable
section was found.
SDF0831I module name module CSECT module compile date module compile time
module release module PTF level IN SERVICE
Explanation: This message is in response to the command:
F <Ironstream jobname>,LIST=MODULES
This message will list the metadata of modules in SYSPRINT.
SDF0832I VERSION vv.rr.mm OF Z/OS IS CURRENTLY UNSUPPORTED, USING
ALTERNATE LEVELS
Explanation: This message indicates Ironstream versioning is in effect
and has recognized it is operating on a z/OS vv.rr.mm system. The highest
available level of Ironstream versioning will be used to format JSON
pairs.
SDF0833I IRONSTREAM IS EXECUTING ON A Z/OS SYSTEM, VERSION
vv.rr.mm WHICH WILL BE USED TO FORMAT JSON PAIRS
and has recognized the operating system on a z/OS vv.rr.mm system.
SDF0834I VERSION vv.rr.mm OF Z/OS WILL BE USED BY IRONSTREAM TO
CREATE JSON PAIRS
and a statement in the configuration file has requested versioning to occur
at level vv.rr.mm, which may or may not be the level of the resident
operating system. This message indicates the active level of versioning for
z/OS, which may or may not be different from the level indicated in
message SDF0833I.

Ironstream Messages

SDF0835I VERSION vv.rr.mm OF subsystem HAS BEEN RECOGNIZED BY
IRONSTREAM AND VERSIONING FOR THE SUBSYSTEM LEVEL IS
ACTIVE
and an SMF record created by the subsystem indicated in the message
has been forwarded to Ironstream for processing. Ironstream has
activated processing for this level of the subsystem.
SDF0880I *************************************************************
SDF0881I THIS IS A FREE VERSION OF THE IRONSTREAM PRODUCT FROM
SYNCSORT, INC.
SDF0882I IT IS PROVIDED "AS IS" WITH NO WARRANTIES EXPRESSED OR
IMPLIED.
SDF0883I THE USER ASSUMES ALL LIABILITIES AND RISKS.
SDF0884I ONLY THE "DATATYPE":"SYSLOG" AND SMF RECORD TYPE 205
ARE SUPPORTED.
SDF0885I THERE IS NO TECHNICAL SUPPORT AVAILABLE FOR THIS FREE
VERSION.
Explanation: The set of messages from SDF0880I through to SDF0885I
are issued when running the unlicensed Starter Edition of Ironstream.
This version only supports a data source of syslog for forwarding to
Splunk.
Action: If you want to forward data sources other than syslog contact
Syncsort Sales at info@syncsort.com.
SDF0886A AN ATTEMPT WAS MADE TO USE A DATATYPE OTHER THAN
SYSLOG OR SMF TO SELECT A RECORD TYPE OTHER THAN TYPE
205. PROCESSING IS TERMINATED.
Explanation: While running an unlicensed version of Ironstream, an
attempt was made to process data other than syslog data or SMF to select
a record type other than type 205. Without a valid license key this is not
permitted.
Action: Replace the configuration statements that refer to the non-syslog
with "DATATYPE":"SYSLOG" or the SMF data source for type 205 with
"DATATYPE":"SMF205". If you wish to run the full function version of
Ironstream contact Syncsort Sales at info@syncsort.com.
SDF0885I TO RUN THE FULL FUNCTION VERSION OF IRONSTREAM,
PLEASE CONTACT SYNCSORT PRODUCT SALES AT
+1-877-700-0970.

Ironstream Messages

SDF0899A jobname,stepname,procstepname - module-id TASK ABENDED nnn t
Explanation: An SSDF Offline Reader subtask has abended. module-id is
either OFSR (Offline SMF Reader) or OFLR (Offline Log Reader). nnn t is
the hexadecimal system (t=S) or internal (t=W) Abend reason code. Note
that this message only appears in the syslog for the job. It does not appear
in the SYSPRINT data set.
SDF0900A CONFIGURATION DATA EXCEEDS 72 BYTES AFTER
SUBSTITUTION
Explanation: After replacing system symbols a configuration record has
exceeded the maximum length allowed. The record on which this occurred
is given in message SDF0901A.
Action: Adjust the substitution text for the symbol so that the maximum
length is no longer exceeded and restart Ironstream
SDF0901I configuration_record_after_substitution
Explanation: Each configuration record that has symbol substitution in it
is printed after substitution has occurred.
SDF0902A SYMBOL FIELD DOES NOT START WITH AN '&'
Explanation: Symbol fields must start with an ampersand character and
Ironstream has detected one that does not.
Action: Add an ampersand & at the start of the symbol definition. See the
section “SYMBOLS Section” on page 7-6 for full details.
SDF0903A SYMBOL FIELD DOES NOT END WITH A '.'
Explanation: Symbol fields must end with a period character and
Ironstream has detected one that does not.
Action: Add a period . at the end of the symbol definition. See the section
“SYMBOLS Section” on page 7-6 for full details.
SDF0904A SYMBOL FIELD NOT AS LONG AS SUBSTITUTION TEXT
Explanation: Substitution text for a symbol cannot be longer than the
symbol field plus one.
Action: Shorten the substitution text, or make the symbol name longer.
See the section “SYMBOLS Section” on page 7-6 for full details.

Ironstream Messages

SDF0905A TOO MANY SYMBOL AND SUBSTITUTION TEXT ELEMENTS
Explanation: The symbols and associated substitution text strings exceed
the memory allocated to hold them.
Action: Shorten the symbol names and substitution text strings, and/or
remove and symbols that are not required. If all the symbols you have
defined are required, contact Syncsort Customer Support (see
“Diagnostics and Contacting Syncsort Product Support” on page 28-1).
SDF0906I SDF KAFKA PRODUCER COMPLETED
Explanation: KAFKA producer successfully completed sending all
requested data (sources). This message appears when an Ironstream
Kafka job is manually terminated.
SDF0907A SDF KAFKA PRODUCER DETECTED ERROR WITH RETURN CODE
%%
Explanation: KAFKA producer detected a severe error and cannot
transmit until the problem is resolved.
Action: Resolve the problem at the Kafka broker side. The transmission
will restart automatically.
SDF0908I SDF KAFKA PRODUCER STARTING
Explanation: KAFKA producer has started to send the data.
SDF0909S Kafka native code library failed to load
Explanation: Ironstream failed to locate the JNI modules (*.SO files) in
the KAFKA library.
Action: Make sure the JNI modules (*.SO) in the Kafka directory are
APF-authorized, then restart Ironstream. For more information, see
Chapter 5, “Setting Up Kafka for Ironstream”.
SDF0910S Kafka producer started sending messages at: date time
Explanation: This message shows the date (YYYY/MM/DD) and time
(HH:MM:SS) that the Kafka producer started sending data.
SDF0911S Kafka producer resumed sending messages at: date time
(HH:MM:SS) that the Kafka producer resumed sending data.
SDF0912S Kafka producer failed to send messages at: date time
(HH:MM:SS) that the Kafka producer failed to send data.
Action: See the error in STDERR for the failure reason. Correct the
problem so that Ironstream can resume data transmission.

Ironstream Messages

SDF0913I Kafka custom properties file not found. The default Kafka producer
settings will be applied.
Explanation: KAFKA properties file was not found so the default Kafka
settings will be applied.
Action: The internal producer uses Kafka’s default producer settings.
However, Ironstream also supports all Kafka producer key-value pairs in
the producer.properties file format. Make sure the file is located under
the directory pointed to by the SSDFHOME parameter in the
configuration file.
For more information, see Chapter 5, “Setting Up Kafka for Ironstream”.
SDF0914I Kafka destination specified in properties file is ignored. Specify TCP
destination values in the Ironstream configuration file.
Explanation: Cannot find the IPADDRESS and PORT for the Kafka
broker provided in the Ironstream configuration file.
Action: Make sure the IPADDRESS and PORT values are correctly
entered for the Kafka broker in the configuration file. For more
information, see Chapter 5, “Setting Up Kafka for Ironstream”.
SDF0915A KAFKA TARGET IS NOT SUPPORTED FOR THE OFFLINE LOG4J
READER FACILITY
Explanation: KAFKA target is not supported for offline log4j reader.
Action: Use the log4j offline reader with a different target.
SDF0950I SSDF SMF REPORTER V1.100 STARTING
Explanation: Explanation: This information is issued at initiation time as
confirmation that the SMF Reporter has started.
SDF0951I COULD NOT OPEN FILE ddname, reason
Explanation: The SMF Data Usage Reporter could not open the file with
the ddname in the message text for the reason given.
Action: Verify the file named ddname is a valid file. If the problem
continues, contact Syncsort Product Support.
SDF0952I SMF RECORDS READ=nnn, TOTAL DATA OFFLOADED=volume
Explanation: This message reports the number of SMF records that have
been read and the total volume of data that has been offloaded in nnn
units (TB, GB, MB, or KB).
SDF0953I SMF REPORT TRACING ACTIVATED
Explanation: The SMF Reporter Tracing has been activated to assist in
any issues that require debugging.

Ironstream Messages

SDF0954I SMF RECORDS READ=nnn, IRONSTREAM=nnn, TYPE0=nnn,
TYPE1=nnn, TYPE2=nnn, TYPE3=nnn, REJECTED=nnn,
IGNORED=nnn, HEADERS=nnn
Explanation: This message reports the number of SMF records that have
been read, their subtypes (if any), and the number of SMF records that
have been rejected or ignored.
SDF0956I COULD NOT OPEN SYSIN. DEFAULTS TAKEN. PROCESSING
ENTIRE SMF FILE
Explanation: The SMF Reporter could not open the SYSIN DD. The
SELECT parameters were ignored and defaults were used to process the
entire SMF file.
SDF0957I VALIDATING SYSIN PARAMETERS
Explanation: The SMF Reporter is validating the specified SYSIN
SELECT parameters.
SDF0958I SELECT parameter SET TO value
Explanation: This message reports the specified SYSIN SELECT
parameter settings. For example, SELECT LPAR is set to ZOS2.
SDF0959I INVALID SELECT PARAMETER parameter. IGNORED
Explanation: A specified SYSIN SELECT parameter cannot be recognized
and has been ignored.
Action: Verify that the SELECT parameter is valid for your system.
SDF0960I NO RECORDS SELECTED
Explanation: The SMF Reporter could not match any records due to
invalid SELECT filtering parameters
Action: Review your SELECT parameter settings.
SDF0961I FIRST TIMESTAMP IN INPUT: timestamp
Explanation: This message reports the initial timestamp for the input
data sets. The timestamp uses this format: Mon Nov 28 15:49:45.45.
SDF09612 LAST TIMESTAMP IN INPUT: timestamp
Explanation: This message reports the final timestamp for the input data
sets. The timestamp uses this format: Mon Nov 28 15:49:45.45.

Ironstream Messages

SDF0964I PATH: LPAR:name, JOBNAME:name AS SOURCETYPE:source_type TO
INDEX:index_name AT IP ADDRESS:IP_address. TOTAL BYTES
OFFLOADED: volume
Explanation: The SMF Reporter reports the values of the path used when
data is offloaded to a specified target, as well as the total volume of bytes
that were offloaded. For example, when sending data of a particular type
on an LPAR via an IP address to a the destination repository.
SDF0965I PROCESSING SMF DATASET: 'dataset_name'
Explanation: The SMF Reporter reports the data set being processed. If
there are multiple SMF files, it will just say “Concatenated”.Action:
SDF0966I SMF DATA COVERS nnn DAYS, nn HOURS, nn MINUTES, nn

SECONDS
Explanation: The amount of time the SMF Report covers in days, hours,
minutes, and seconds.
SDF0967I SSDF SMF REPORTER V1.100 ENDING
Explanation: This information is issued at initiation time as confirmation
that the SMF Reporter has ended.Action:
SDF0968 REPORT parameter SET TO value
Explanation: The SMF Reporter indicates the specified REPORT
parameter settings. For example, REPORT Break is set to LPAR.
SDF0969I INVALID REPORT PARAMETER parameter. IGNORED
Explanation: A specified SMF REPORT parameter cannot be recognized.
Action: Verify that the REPORT parameter is valid for your system. Valid
parameters are TYPE, FORMAT, BREAK, NUMBERS, and TITLE.
SDF0975I nnn CSV records written to CSV_filename
Explanation: This message reports the number of CSV records that are
written to the CSV file.
SDF0977I nnn pages written to SSDRRPT
Explanation: This message reports the number of report pages that have
been written to the SSDRRPT job.
SDF0978I Producing filename report
Explanation: The SMF Reporter is generating a report to either a
SYSPRINT or a CSV file.

Ironstream Messages

SDF1200I IRONSTREAM SYNCHRONOUS LOG GATHERER INITIALIZED
Explanation: This message appears in the IMS Control Region JES
message log to confirm that the Ironstream IMS Log Write exit has
initialized.
SDF1201I LOG GATHERER taskname PROCESSED LOG RECORD RANGE
ssssssss TO eeeeeeee
Explanation: The IMS Asynchronous Log Gatherer has processed IMS log
records with hexadecimal sequence numbers ssssssss to eeeeeeee inclusive.
Note that because Ironstream does not forward every IMS log record, you
might not find log sequence numbers ssssssss or eeeeeeee in a destination.
SDF1202I LOG GATHERER taskname ENDING EARLY AFTER READING nnnnn
SLDS BLOCKS
Explanation: The IMS Asynchronous Log Gatherer has ended before
reaching the end of the SLDS. This might be because an operator has
stopped the Ironstream process or because of a failure. Other messages
will indicate the reason why this occurred.
SDF1203I LOG GATHERING STARTED AT RECORD ssssssss
Explanation: The IMS Synchronous Log Gatherer has started processing
IMS log records at hexadecimal sequence number ssssssss.
might not find log sequence number ssssssss in the destination repository.
SDF1204I LOG GATHERING ENDED AT RECORD <NONE PROCESSED> |
eeeeeeee
Explanation: The IMS Synchronous Log Gatherer has stopped processing
IMS log records at hexadecimal sequence number eeeeeeee or before any
records could be processed. There will be another message to explain the
reason why this occurred.
might not find log sequence number eeeeeeee in a destination.
SDF1205A LOG EXTRACTOR FOR name IS NOT ACTIVE
Explanation: The IMS Synchronous Log Gatherer did not detect its Log
Extractor. Name is composed of imsid + ‘GIMG’ + ‘DSTR0000’.
Action: Check that an IMS Extractor is running with [SOURCE]
“IMS_SYSTEM_ID":imsid
SDF1206A DATA STORE FULL
Explanation: The IMS Log Gatherer could not pass the current block of
IMS log data to the Log Extractor because the intermediate data store
was full. The Log Gatherer will retry with the next block.

Ironstream Messages

SDF1207I LOG EXTRACTION STARTED AT RECORD ssssssss
Explanation: The IMS Log Extractor has started processing IMS log
records at hexadecimal sequence number ssssssss.
might not find log sequence number ssssssss in the destination repository.
SDF1208I LOG EXTRACTION ENDED AT RECORD <NONE PROCESSED> |
eeeeeeee
Explanation: The IMS Log Extractor has stopped processing IMS log
records, either at hexadecimal sequence number eeeeeeee or before any
records could be processed. There will be another message to explain the
reason why this occurred.
might not find log sequence number eeeeeeee in a destination.
SDF1209I IRONSTREAM SYNCHRONOUS LOG GATHERER REFRESH
COMPLETE
Explanation: This message appears in the IMS Control Region to JES
message log when the Ironstream IMS Log Write exit has reinitialized
following an IMS UPDATE USEREXIT command.
SDF1210I IMS LOG RECORD STATISTICS
Explanation: This message indicates the start of an IMS log record
statistics report.
SDF1211I RECORD DESCRIPTION PROCESSED SUPPRESSED TOTAL
Explanation: Column headings for the IMS log record statistics report.
SDF1212I Description records processed records suppressed total number of records
Explanation: A detail line from the IMS log record statistics report. A log
record is suppressed if it is not contained in the IMS log records categories
you have requested.
SDF1213I ------------------------ -------------------- -------------------- --------------------
Explanation: A spacer line between the details and totals in the IMS log
record statistics report.
SDF2001A DYNAMIC RECONFIGURATION IS NOT SUPPORTED FOR THIS
DATA TYPE
Explanation: An attempt to do dynamic reconfiguration was made using a
DATATYPE other than "DATATYPE":"SMF".
Action: The request is rejected.

Ironstream Messages

SDF2002I DYNAMIC RECONFIGURATION PROCESS IS STARTING
Explanation: This message is issued at the start of the reconfiguration
listing.
SDF2003S DYNAMIC RECONFIGURATION process FAILED. SEE PRIOR
MESSAGES
Explanation: Process denotes a VALIDATION or EXECUTE failure.
Action: Review prior error messages and correct as appropriate.
SDF2004I DYNAMIC RECONFIGURATION VALIDATION PROCESS
COMPLETED SUCCESSFULLY
Explanation: The validation of the configuration file has been successfully
completed.
SDF2005A DYNAMIC RECONFIGURATION DOES NOT PERMIT PARAMETER
parm TO BE CHANGED
Explanation: The specified parameter cannot be changed as part of
dynamic reconfiguration.
Action: Change the parameter back to the value in the original
configuration file.
SDF2006I DYNAMIC RECONFIGURATION IMPLEMENTATION PROCESS
COMPLETED SUCCESSFULLY
Explanation: The implementation of the configuration file has been
successfully completed.
SDF2007A DYNAMIC RECONFIGURATION DOES NOT SUPPORT THE option
OPTION
Explanation: The specified option is not supported as part of dynamic
reconfiguration.
Action: Remove the option from the configuration.
SDF2008I DYNAMIC RECONFIGURATION [IS PAUSING | HAS RESUMED]
THE EXTRACTION OF DATA FROM THE DATA STORE
Explanation: This status message is issued to inform the user when data
is not being sent to the destination. Data continues to be collected in the
data store and no data is lost.
SDF2009I DYNAMIC RECONFIGURATION function FAILED
Explanation: During dynamic reconfiguration, a function or process has
failed.
Action: Retry the action that caused the problem. If it reoccurs, contact

Ironstream Messages

SDF500nI Diagnostic information
Explanation: Messages in the 5000 range display diagnostic information
for use by members of the Syncsort Product Support group.
SDF7000I START TIME - HH:MM:SS.TH DATE - MM/DD/YYYY CURRENT
MAINTENANCE - PTF1234
Explanation: Issued at the start time for the SSDFGDIC process.
Informational only.
SDF7002A IRONSTREAM CUSTOM DICTIONARY CREATE TASK
INITIALIZATION FAILURE
Explanation: Issued when SSDFGDIC initialization has an error. Review
previous messages for the error.
Action: Correct the error and resubmit the Ironstream job.
SDF7003A DICTIONARY GENERATION FAILURE DURING procedure
Explanation: procedure will be one of four values:
ESTAE INITIALIZATION PROCESSING
DATASET INITIALIZATION
Review previous messages for the data set.
Action: Correct the error and resubmit Ironstream job.
If DDNAME SMFIN failed to open, Ironstream will issue message
SDF7004A, followed by SDF7003A.
If DDNAME SSDFGDIC failed to open, Ironstream will issue message
SDF7005A (was not RECFM=FB) or message SDF7006A (was not
LRECL=80), followed by SDF7003A.
FAILURE PROCESSING NEW ENTRIES
FAILURE CLOSING DATASETS
Data sets failed to close. Review previous system messages to understand
the failure.
SDF7004A FAILURE OPENING DATASET WITH DDNAME OF ddname
Explanation: ddname is the DDNAME of the data set failing to open.
Action: Review previous system messages or the following Ironstream
messages to understand the failure. See related messages SDF7003A,
SDF7005A, and SDF7006A.

Ironstream Messages

SDF7005A THE RECORD FORMAT OF THE DATASET WITH THE DDNAME OF
ddname IS NOT FIXED-LENGTH
Explanation: ddname is required to be RECFM=F or FB. See related
messages SDF7003A, SDF7004A, AND SDF7006A.
SDF7006A THE LRECL OF THE DATASET WITH THE DDNAME OF ddname IS
NOT LRECL=80
Explanation: ddname is required to be LRECL=80. See related messages
SDF7003A, SDF7004A, and SDF7005A.
SDF7007I END TIME - HH:MM:SS.TH DATE - MM/DD/YYYY
Explanation: Indicates the time and date the SSDFGDIC process ended.
SDF7008A DICTIONARY GENERATION FAILURE DURING CSRCESRV
SERVICE=QUERY FAILED, RETURN CODE=12345678
Explanation: CICS SMF records can be compressed. The CSRCESRV
service is required to decompress the record. Review the return codes for
the system CSRCESRV SERVICE=QUERY macro to understand the
reason for the failure.
Action: After examining the CSRCESRV return code, if an understanding
of how to resolve the issue is not reached, contact Syncsort Product
Support.
SDF7009A THE FOLLOWING SMF RECORD IS NOT A TYPE 110 RECORD WITH
SUBTYPE 1 AND CLASS 1
Explanation: This message is the heading for the following SMF 110
record printout, indicating the message was ignored by selection
processing because it was the wrong type, subtype, and /or class.
Action: If instructed by Syncsort Product Support, debugging options may
be turned on.
SDF7010I BUILDING CICS ENTRIES BASED ON DICTIONARY FOR JOBNAME
jobname, APPLID applid, AND CICS VERSION cicsversion AS TABLE
index
Explanation: The SDF7010I message will occur for each region found in
the SMFIN DDNAME. The list of regions represents all regions for which
Ironstream will be able to properly format the modified SMF 110 monitor
records. This list should be examined to ensure that it contains every
region that will forward data by Ironstream.

Ironstream Messages

SDF7011I GROUP groupname, TYPE fieldtype, LENGTH fieldlength,
CONNECTION connectionid, OFFSET fieldlocation, NICKNAME
nickname, TABLE index
Explanation: This message will occur for each field recognized to be a part
of the dictionary table for a given region. Group name, field type, field
length, connection ID, location, and field name are part of the field
description from the dictionary record. Table index is the link back to the
SDF7010I message identifying the CICS region in which this information
will be used.
SDF7012I nnn SMF RECORDS READ
Explanation: This end-of-job message is provided to compare the records
read by Ironstream to the number of records written by IFASMFDP.
These numbers should match to insure all SMF records have been read.
SDF7013I nnn SMF RECORDS SKIPPED
Explanation: This end-of-job message is provided as a count of
non-dictionary SMF records read by SSDFGDIC. This is informational
only.
SDF7014I nnn DICTIONARY CARDS CREATED
Explanation: This end-of-job message is provided as a count of assembler
statements created by SSDFGDIC. This is informational only.
SDF7015I NICKNAME nickname RENAMED AS uniquenickname TO ALLOW
UNIQUE JSON PAIR NAME VALUES
Explanation: When duplicate field names (referenced in CICS manuals as
nicknames) are found in the dictionary record, a SDF7015I message will
be written. Duplicate nicknames in the dictionary record will cause
Ironstream to create two JSON pairs with the same name and possibly
different values associated with that nickname. This duplication in the
JSON event causes confusion in follow-on processing as to which value to
associate with the field name.
Ironstream resolves this dilemma by creating unique field names when
duplicate nicknames are recognized. Message SDF7015I indicates that a
duplicate nickname was found in the dictionary record and a new
nickname has been created to take its place.
The new nickname will be used by Ironstream to create a JSON pair to
reference the data originally represented by the duplicate nickname.
Follow-on processing will be required to use the new unique name and not
the duplicate name.

Ironstream Messages

SDF7016I LOAD OF LOCAL CICS DICTIONARY TABLES FAILED ON INSERT
Explanation: During Ironstream initialization, the internal table of a
customized monitor dictionary failed because of invalid internal entries
found in the customizing module SSDFCICD. Contact Syncsort Product
Support with the message.
SDF7017I SYNTAX ERROR, EXPECTING <dataname1>, FOUND <dataname2>
Explanation: During the processing of statements for Ironstream
SSDFGDIC, the syntax processor expected to find <dataname1>, when
<dataname2> was found.
Action: Correct the syntax of the desired command and resubmit
SSDFGDIC.
SDF7018I SKIPPING TO THE START OF NEXT SENTENCE
Explanation: A syntax error was recognized. The syntax process will skip
forward until the CREATE or FORMAT verb is found.
SSDFGDIC.
SDF7019I SYNTAX ERROR, DUPLICATE FIELD NAME FOUND: <fieldname>
Explanation: During the processing of statements for Ironstream
SSDFGDIC, duplicate FORMAT statements were found for the same
<fieldname>. FORMAT <fieldnames> must be unique.
SSDFGDIC.
SDF7020I USAGE STATISTICS FOR FIELD NAME FORMATTING
Explanation: At the end of SSDFGDIC processing, this message is the
header statement indicating the beginning of the reporting of FORMAT
verb usage.
SDF7021I <fieldname> TYPE: <formatting_type> COUNT: <count>
Explanation: This statement reports the number of times <fieldname>
formatting was changed to <formatting_type> by SSDFGDIC. This count
should be examined to make sure the expected number of occurrences
were changed.
SDF7022I USAGE STATISTICS FOR COPING BY APPLID
Explanation: At the end of SSDFGDIC processing, this message is the
header statement indicating the beginning of the reporting of CREATE
verb usage.

Ironstream Messages

SDF7023I COPY APPLID: <source_APPLID> TO APPLID: <target_APPLID> for
VERSION: <CICS_version> COUNT: <count>
Explanation: This statement reports the number of times
<source_APPLID> was used to create <target_APPLID> at CICS version
<CICS_version>. This count should be examined to make sure the
expected number of copies were created.
SDF7024I CREATE APPLID <target_APPLID> FROM <source_APPLID>
VERSION <CICS_version> UNSUCCESSFUL. FAILED VERSION
MATCH TO <current__processing_MCT_APPLID>
Explanation: During the processing of CREATE statements for
Ironstream SSDFGDIC, an attempt was made to CREATE, but the
version of the <current_processing_MCT_APPLID> and the requested
version <CICS_version> did not match. MCTs are unique by CICS version
and cannot be used to create a different version of the information. This
message is only available if DEBUG is active.
Action: Ensure this message was expected. If not, correct the information
and resubmit SSDFGDIC.
VERSION <CICS_version> UNSUCCESSFUL. FAILED APPLID
MATCH TO <current_processing_MCT_APPLID>
APPLID of the <current_processing_MCT_APPLID> and the
<source_APPLID> did not match. This message is only available if
DEBUG is active.
VERSION <CICS_version> SUCCESSFULLY MATCHED TO
<current_processing_MCT_APPLID>
Ironstream SSDFGDIC, a successful match was made and
<target_APPLID> information will added to Ironstream.
VERSION <CICS_version> UNSUCCESSFUL. FAILED ATTEMPT
MATCHED THE PREVIOUS APPLID VERSION
resulting MCT information for this APPLID and version are already being
created.
Action: Correct the CREATE request and resubmit SSDFGDIC.

Ironstream Messages

SDF7100I SMF INMEM RESOURCE <rname> FUNCTION <interface function>,
RETURN CODE=<return code>, REASON CODE=<reason code>
Explanation: Ironstream requested <interface function> of the operating
system on behalf of the SMF real-time INMEM resource <rname>.
The request completed with a return code of <return code> and a reason
code of <reason code>. Refer to messages SDF7101I, SDF7102I,
SDF7103I, and SDF7104I for a complete description of the return code
and any possible required action.
Action: Refer to messages SDF7102I for complete description and
SDF7103I for required action.
SDF7101I SMF INMEM RESOURCE RETURN CODE=<return code>, REASON
CODE=<reason code>
Explanation: <return code> and <reason code> are descriptive values of
the codes in message SDF7100I.
Action: Refer to message SDF7102I for a complete description and
SDF7103I for the required action.
SDF7102I SMF INMEM RESOURCE <rname> <message>
Explanation: This message contains the description of the codes contained
in SDF7100I.
Action: Refer to message SDF7103I for required action.
SDF7103I SMF INMEM RESOURCE <rname> <action>
Explanation: This message contains the possible actions to the codes
contained in SDF7100I.
Action: Review this text for action. If you are unable to resolve the issue,
SDF7104I SMF INMEM RESOURCE FUNCTION <interface function call>,
RETURN CODE=<return code>, REASON CODE=<reason code>
Explanation: Ironstream requested an unrecognized function of the
operating system on behalf of the SMF real-time INMEM resource
<rname>. The request completed with a return code of <return code> and
a reason code of <reason code>. Refer to messages SDF7101I, SDF7102I,
SDF7103I, and SDF7104I for a complete description of the return codes
Action: Refer to message SDF7102I for a complete description and
SDF7103I for the required action.

Ironstream Messages

SDF7105I UNRECOGNIZED RETURN CODE AND REASON CODE FOR
FUNCTION <interface function>, RETURN CODE=<return code>,
REASON CODE=<reason code>
Explanation: Ironstream requested <interface function> of the operating
system on behalf of the SMF real-time INMEM resource <rname>.
The request completed with a return code of <return code> and a reason
code of <reason code>. Refer to messages SDF7101I, SDF7102I,
SDF7103I, and SDF7104I for a complete description of the return codes
Action: The return code was unknown to Ironstream. Contact Syncsort
Product Support with the complete job log.
SDF7106A SMF INMEM COLLECTOR <gatherer> DETECTED ERROR CODE
<return code> WITH REASON CODE <reason code> WHEN
ESTABLISHING AN ESTAE
Explanation: Ironstream unsuccessfully established an ESTAE
environment.
Action: Contact Syncsort Product Support with the complete job log.
SDF7107A SMF INMEM COLLECTOR <gatherer> DETECTED ERROR CODE
<return code> WHEN CALLING NAME/TOKEN SERVICES
Explanation: Ironstream unsuccessfully called NAME/TOKEN services.
SDF7108A SMF INMEM COLLECTOR FAILED TO LOAD MODULE <module
name> RETURN CODE=<return code> REASON CODE=<reason code>
Explanation: Ironstream unsuccessfully attempted to load <module
name>.
SDF7109A SMF INMEM COLLECTOR GETMAIN FAILED FOR SIZE <size>
RETURN CODE=<return code> REASON CODE=<reason code>
Explanation: Ironstream unsuccessfully attempted to allocate storage for
internal use of size <size>.
SDF7110A SMF INMEM COLLECTOR FREEMAIN FAILED FOR SIZE <size>
RETURN CODE=<return code> REASON CODE=<reason code>
Explanation: Ironstream unsuccessfully attempted to release storage for
internal use of size <size>.

Ironstream Messages

SDF7111I SMF INMEM COLLECTOR CAPTURING SMF TYPE <type> AS
INDICATED BY CONFIGURATION
Explanation: Ironstream is reporting that SMF TYPE <type> was
recognized in the configuration file.
Action: This message should be reviewed to ensure accuracy.
SDF7112I SMF INMEM RESOURCES ARE CAPTURING SMF TYPE <type> AND
IRONSTREAM IS REQUIRING THIS SMF TYPE
Explanation: Ironstream is reporting that SMF TYPE <type> is available
for retrieval from SMF real-time resources known to Ironstream and
Ironstream will forward this SMF type.
SDF7113I SMF INMEM RESOURCES ARE CAPTURING SMF TYPE <type> BUT
IRONSTREAM IS NOT REQUIRING THIS SMF TYPE
for retrieval from SMF real-time resources known to Ironstream, but
Ironstream will NOT forward this SMF type because the configuration file
does not contain a "SELECT":"SMF<type>" statement for this SMF type.
SDF7114A SMF INMEM RESOURCES ARE NOT CAPTURING SMF TYPE <type>
BUT IRONSTREAM IS REQUIRING THIS SMF TYPE
Explanation: Ironstream is reporting that SMF TYPE <type> is NOT
available for retrieval from SMF real-time resources known to
Ironstream. Ironstream has been requested to capture this SMF type
because the configuration file contains a "SELECT":"SMF<type>"
statement for this SMF type.
Action: This message should be reviewed to ensure accuracy. This is
probably an error and SMFPRMxx needs to be upgraded to request SMF
<type>.
SDF7115I SMF INMEM RESOURCE <rname> IS CAPTURING SMF TYPE <type>
AND IRONSTREAM IS REQUIRING THIS SMF TYPE
Ironstream is forwarding this SMF type off-platform.

Ironstream Messages

SDF7116I SMF INMEM RESOURCE <rname> IS CAPTURING SMF TYPE <type>
BUT IRONSTREAM IS NOT REQUIRING THIS SMF TYPE
Ironstream is forwarding this SMF type off-platform.
SDF7117A SMF INMEM RESOURCE <rname> IS NOT CAPTURING SMF TYPE
<type> BUT IRONSTREAM IS REQUIRING THIS SMF TYPE
Explanation: Ironstream is reporting that SMF TYPE <type> is NOT
available for retrieval from SMF real-time resources known to
Ironstream. Ironstream has been requested to capture this SMF type
because the configuration file contains a "SELECT":"SMF<type>"
statement for this SMF type.
Action: This message should be reviewed to ensure accuracy. This is
<type>.
SDF7118A SMF INMEM RESOURCE <rname> IS CAPTURING SMF TYPE <type>
BUT THE RESOURCE IS DISCONNECT FROM IRONSTREAM
Explanation: Ironstream is reporting that SMF RESOUCE <rname> is
disconnected from the SMF real-time resources known to Ironstream.
Ironstream has been requested to capture this SMF type because the
configuration file contains a "SELECT":"SMF<type>" statement for this
SMF type.
Action: This message should be reviewed to ensure accuracy. This
<type>.
SDF7112A SMF INMEM RESOURCE <rname> ENDED - LAST CAPTURED
MESSAGE FROM LOGSTREAM <rname> WAS AT <last message date
and time>
Explanation: Ironstream was retrieving records from <rname> when the
return code indicated the <rname> buffer wrapped.
Action: Data was possibly lost. The <last message date and time> can be
the corresponding <first message date and time> from SDF7121A and can
be used to bracket a recovery of the SMF message if required.

Ironstream Messages

SDF7121A SMF INMEM RESOURCE <rname> RESUMED - FIRST CAPTURED
MESSAGE FROM LOGSTREAM <rname> WAS AT <first message date
and time>
Explanation: Ironstream was retrieving records from <rname> when the
return code indicated the <rname> buffer wrapped.
Action: Data was possibly lost. The <last message date and time> from
SDF7120A and the corresponding <first message date and time> can be
used to bracket a recovery of the SMF message if required.
SDF7122I SMF INMEM RESOURCE <gatherer> ENDED - LOGSTREAM <rname>
HAS NOT SELECTED A MESSAGE
Explanation: Ironstream has disconnected <rname> from the SMF
real-time interface. No SMF records were retrieved by this <rname>.
SDF7130I SMF INMEM RESOURCE <rname> IS CONNECTED
Explanation: Ironstream has successfully CONNECTED <rname> to the
SMF real-time interface.
Action: This message is informational as the result of a request for status
via the "f <jobname>,INMEM,STATUS" command.
SDF7131I SMF INMEM RESOURCE <rname> IS PENDING CONNECT
Explanation: Ironstream will attempt to CONNECT <rname> to the SMF
real-time interface.
SDF7132I SMF INMEM RESOURCE <rname> IS DISCONNECTED
Explanation: Ironstream has successfully DISCONNECTED <rname>
from the SMF real-time interface.
SDF7133I SMF INMEM RESOURCE <rname> IS PENDING DISCONNECT
Explanation: Ironstream will attempt to DISCONNECT <rname> from
the SMF real-time interface.

Ironstream Messages

SDF7134I IRONSTREAM IS GRANTED PERMISSION TO SMF INMEM
RESOURCE <rname>
Explanation: Ironstream is reporting the result of a security request for
READ access to FACILITY class, PROFILE IFA.<rname>.
SDF7135I IRONSTREAM IS NOT PERMITTED ACCESS TO SMF INMEM
RESOURCE <rname>
Explanation: Ironstream is reporting the result of a security request for
READ access to FACILITY class, PROFILE IFA.<rname>.
SDF7136I SMF INMEM RESOURCE <rname> IS DISCONNECTED BY
COMMAND
Explanation: Ironstream is reporting the resource <rname> was
disconnected by command. This is important because Ironstream will
attempt to keep all valid resources active. If a valid resource is required to
be disconnected (for SMF environmental maintenance for example), this
message indicates an explicit CONNECT is required to re-establish the
resource as an SMF real-time source.
SDF7137I SMF INMEM RESOURCE <rname> IS NO LONGER DEFINED TO SMF
REAL-TIME RESOUCES OR SECURITY PREVENTING ACCESS
Explanation: A resource <rname> previously known to Ironstream has
been removed from the list of SMF real-time resources, or the resources
listed in response to the query executed by Ironstream no longer has the
resource because security has prevented Ironstream access.
via the "f <jobname>,INMEM,STATUS" command. If the resource is
defined to SMF real-time resources, and Ironstream doesn’t list the
resource, then the security system must grant READ access to the
resource by Ironstream: CLASS FACILITY, PROFILE IFA.<rname>.
SDF7138I SMF INMEM RESOURCE COMMAND NOT EXECUTED, <rname>
NOT FOUND
Explanation: A connect or disconnect command was issued to change the
status of <rname>, but <rname> is not defined to Ironstream.
Action: Check the spelling of <rname> and reissue the command.

Ironstream Messages

SDF7139I SMF INMEM COMMAND <command> IS RECOGNIZED
Explanation: Ironstream acknowledges the <command>.
SDF7140I INMEM DEBUGGING IS (TURNED OFF | ACTIVE)
Explanation: Ironstream acknowledges the INMEM,DEBUG command.
SDF7150I SMF INMEM RESOURCE <rname> RETRIEVED COUNT = <count>
Explanation: The Ironstream connection to <rname> has retrieved
<count> messages.
SDF7151I SMF INMEM RESOURCE <rname> SELECTED COUNT = <message
count>
Explanation: The Ironstream connection to <rname> has selected <count>
messages for the available messages indicated in SDF7510I.
SDF7152I SMF INMEM RESOURCE LOGSTREAM <rname> LAST CAPTURE A
MESSAGE AT <last message date and time>
Explanation: The date and time of last retrieved message by the
Ironstream connection to <rname>.
SDF7153I SMF INMEM RESOURCE LOGSTREAM <rname> HAS NOT
SELECTED A MESSAGE FOR LAST MESSAGE DATE AND TIME
Explanation: The resource <rname> has not retrieved a message.
via the "f <jobname>,INMEM,STATUS" command
SDF7154A SMF INMEM RESOURCE <rname> PAUSING, RETURN
CODE=<return code>
Explanation: Ironstream received a return code indicating the SMF
real-time interface buffer has wrapped.
used to bracket a recovery of SMF message if required.

Ironstream Messages

SDF7155A SMF INMEM RESOURCE <rname> RESUMED
Explanation: Ironstream successfully retrieve a message from SMF
real-time interface after being aware of a buffer.
used to bracket a recovery of SMF message if required.
SDF7160A IRONSTREAM SMF INMEM: <security system return codes>
Explanation: Ironstream access to <rname> is not allowed. <security
system return codes> were return by the security system.
Action: If access to <rname> is required by Ironstream, grant Ironstream
access to FACILITY class, profile IFA.<rname>.
SDF7195I INMEM STATUS IS LISTED IN SYSPRINT ONLY
Explanation: Ironstream will respond to the console command in the
SYSPRINT data set as the amount of output may be large.
Action: Informational.
SDF7196I NO IRONSTREAM SMF INMEM RESOURCE DEFINED
Explanation: Ironstream has not be assigned a resource name to utilize.
Action: Create "INMEM_RESOUCE":"<rname>" statements in the
configuration file of required resources to access.
SDF7197A IRONSTREAM SMF INMEM ENVIRONMENT MUST FIRST BE
ESTABLISHED
Explanation: A command was attempted to be executed on an instance of
Ironstream without a defined INMEM resource.
Action: Create "INMEM_RESOUCE":"<rname>" statements in the
configuration file of required resources to access.
SDF7198A IRONSTREAM SMF INMEM LOGIC ERROR: <internal code>
Explanation: A command was attempted to be executed on an instance of
Ironstream and an internal error was encountered.
Action: Contact Syncsort Product Support with the complete job log and
syntax of the entered command.
SDF7199A REVIEW PREVIOUS MESSAGES AND RESTART
Explanation: Previous messages indicate action may be required.
Action: Review previous message for possible action.

Ironstream Messages

SDF8005A ASEXT FAILURE, RETURN CODE rc, REASON CODE rsn
Explanation: A failure occurred when the auxiliary task attempted to get
start-up parameters. The SMF Auxiliary task and the Ironstream task
both terminate.
SDF8006A COUPLING FACILITY CONNECT ERROR, RETURN CODE rc,
REASON CODE rsn
Explanation: A failure occurred when the auxiliary task attempted to
connect to the coupling facility. The SMF Auxiliary task and the
Ironstream task both terminate.
Action: See the IXGCONN return code section of the Assembler Services
Reference manual for an explanation of the return code/reason code. If you
need additional help, contact Syncsort Product Support.
SDF8007A INVALID PARAMETER STRING PASSED, LENGTH = length, DATA =
data
Explanation: The parameter string passed from the main Ironstream
instance was invalid. The SMF Auxiliary task and the Ironstream task
both terminate.
SDF8008A FAILURE BUILDING DATA STORE
Explanation: The auxiliary task could not build a temporary data store.
The SMF Auxiliary task and the Ironstream task both terminate.
SDF8009A CROSS MEMORY POST ERROR, RETURN CODE rc
Explanation: The auxiliary task had a failure issuing a cross memory
POST. The SMF Auxiliary task and the Ironstream task both terminate.
SDF8010A FAILURE GETTING NAME/TOKEN
Explanation: The auxiliary task could not retrieve a name/token pair. The
SMF Auxiliary task and the Ironstream task both terminate.

Ironstream Messages

SDF8012S WRITE TO COUPLING FACILITY FOR TIMING MESSAGE FAILURE,
RETURN CODE rc, REASON CODE rsn
Explanation: The auxiliary task had a failure writing to the coupling
facility.
Action: See the IXGWRITE return code section of the Assembler Services
Reference manual for an explanation of the return code/reason code. If you
need additional help, contact Syncsort Product Support.
SDF8013S WRITE TO COUPLING FACILITY FOR DATA RECORD FAILURE,
RETURN CODE rc, REASON CODE rsn
Explanation: The auxiliary task had a failure writing to the coupling
facility.
Action: If the RETURN CODE is 00000008 and the REASON CODE is
00000809, the likeliest explanation is that the MAXBUFSIZE in the
coupling facility’s log stream is too small. For Ironstream, the minimum
value should be 32868. Otherwise, refer to the IXGWRITE return code
section of the Assembler Services Reference manual for an explanation of
the return code/reason code. If you need additional help, contact Syncsort
Product Support.
SDF8014S MESSAGE GET FAILURE, RETURN CODE rc
Explanation: A failure occurred getting data from the temporary data
store.
SDF8015S COUPLING FACILITY STRUCTURE USAGE IS AT nn PERCENT
Explanation: The Coupling Facility is at the stated percentage of
utilization.
Action: Determine what is causing the high utilization. This may be due
to high activity or because the main Ironstream task has failed or is not
able to extract data fast enough from the Coupling Facility.
SDF8016S COUPLING FACILITY USAGE IS ABOVE HIGH OFFLOAD WRITE
PERCENTAGE
Explanation: The Coupling Facility has reached the utilization level at
which it starts writing data from internal data structures to external
DASD.
Action: See the action for message SDF8015S.
SDF8017S COUPLING FACILITY USAGE IS AT WRITE ELEVATED CAPACITY
Explanation: The Coupling Facility has utilized an internally specified
percentage of the available DASD.

Ironstream Messages

SDF8018S COUPLING FACILITY USAGE IS AT WRITE IMMINENT CAPACITY
Explanation: The Coupling Facility is near the limits for storing messages
on DASD. The continued writing of data to the facility will cause it to
reject messages.
SDF8019I AUXILIARY TASK INITIALIZATION FAILED WITH REASON CODE
nn
Explanation: The auxiliary task failed to start properly.
Action: See messages in the auxiliary task JOBLOG. If unable to correct
the failure, contact Syncsort Product Support.
SDF8020A THE BASE IRONSTREAM RELEASE LEVEL OF vv.rr.mm DOES NOT
MATCH THE AUXILIARY ADDRESS SPACE RELEASE LEVEL OF
vv.rr.mm
Explanation: The release levels of the two processes are not the same.
Action: Verify that both the base instance of Ironstream and the auxiliary
address space are using the same execution library.
SDF8021A A FAILURE OCCURRED ACQUIRING THE BASE IRONSTREAM
NAME/TOKEN
Explanation: The NAME/TOKEN of the base Ironstream instance was not
found.
Action: If the base Ironstream instance terminated, determine why and
correct that error. If it did not, contact Syncsort Product Support.
Data Collection Extension Messages
Table 27-2: Data Collection Extension Messages
Number Message Text and Description

DCE0000I Ironstream data collection extension started
This information is issued at initiation time as confirmation that the Data
Collection Extension has started.
DCE0009I Ironstream Data Collection Extension ended
This message is issued as confirmation that DCE has been cleanly closed
down. No more data can be offloaded once this message has been issued.

Ironstream Messages
Table 27-2: Data Collection Extension Messages (continued)

DCE0010I ----------------- Processing Configuration -----------------
DCE0010I -------------------- End Configuration ---------------------
These information messages are issued when DCE initialization has
started and mark the boundaries of the configuration file processing.
Informative messages are issued as each configuration parameter is
processed and these are contained within the two DCE0010I messages.
DCE0012I Unable to open configuration member member_name
DCE has been unable to open the configuration file member defined in the
DCE start-up procedure. Ensure that the correct name has been specified
and that it is not locked by another user.
DCE0013I Keyword keyword invalid
DCE has detected an unrecognized keyword while processing the
configuration file. This is most likely to be a typing error which will need to
be corrected. Use the information in “Configuring the DCE Parameters,”
on page 21-1 to verify that you have used the correct parameter
specifications.
DCE0014I Keyword keyword missing value
DCE has detected a keyword while processing the configuration file that
has no associated value specified. Correct the omission before restarting
DCE.
DCE0015I Keyword keyword invalid value value
has an invalid value specified. Both the keyword and the value are given in
the message text. Correct the invalid value before restarting DCE.
DCE0016I Keyword keyword value out of range
has a value specified which is not in the permitted range for that keyword.
Correct the invalid value before restarting DCE.
DCE0017I Keyword keyword value too long
has a value specified which is longer than the permitted number of
characters/digits for that keyword. Ensure that the given value does not
exceed the permitted length before restarting DCE.
DCE0018I Parsing member member_name
This message indicates that DCE has successfully opened the
configuration file and is now processing the parameters that are defined in
it. Informative messages are issued as processing takes place so that all
specified values are recorded.

Ironstream Messages

DCE0019I File Filters filter_name
This form of the DCE0019I message issued during configuration file
processing gives the name of the filter being applied to the USS directory
given in the preceding DCE0021I message.
DCE0019I Target Cluster cluster_name
processing gives the name of the DCE target cluster to which any filtered
files from the USS directory given in the preceding DCE0021I message are
offloaded.
DCE0020I Scan frequency nnn seconds
processing gives the interval in seconds at which DCE processes the USS
directory given in the preceding DCE0021I message.
DCE0020I Tailing Delay nnn seconds
processing gives the total delay after EOF is detected during an offload
after which DCE will check for data having been appended to the file. The
number of times the check is made during this period is determined by the
TailingWait value. The TailingDelay value would normally be a multiple of
the TailingWait value. See the description of the TailingDelay parameter
on page 6 and the TailingWait parameter on page 6 for further
information.
If additional records are added to a file within the TailingDelay period
these are offloaded to Ironstream without a file close/open being
performed. This process is repeated until the TailingDelay period expires
without further records being added to the file, at which point the file is
closed and will be rescanned as usual when the ScanFrequency interval
next expires.
DCE0020I Tailing Wait nnn seconds
Once the tailing process starts for an offloaded file, the check for additional
records being added is made at the expiry of each TailingWait interval
which is given by this form of the DCE0020I message. See the description
of the TailingDelay parameter on page 6 and the TailingWait parameter
on page 6 for further information.
DCE0020I Buffer Size nnnnn bytes
processing gives the size of the data buffer used for the transfer of data to
Ironstream. The value is specified using the BufferSize parameter and it
must be greater than the longest record in the file(s) being transferred.

Ironstream Messages

DCE0020I Checksum Length nnnn bytes
processing gives the size of the checksum length area used by the duplicate
file detection algorithm. The value is specified using the ChecksumLength
parameter.
DCE0020I Status History nn days
processing gives the number of days for which file status information is
stored. The value is specified using the StatusHistory parameter. This
means that for this number of days DCE will remain able to detect a
duplicate file even if the original file is deleted.
DCE0021I USS Directory Scan defined for path
The message precedes a set of DCE0020I directory scanning
characteristics messages and gives the name of the directory path that
those DCE0020I messages apply to.
DCE0022I Maximum threads nnn
The number of global maximum threads specified by the MaxThreads
parameter is nnn. This value indicates the maximum number of files that
can be offloaded to Ironstream simultaneously.
DCE0023I Global Settings
This information message indicates the start of the Global parameter
group in the DCE configuration file.
DCE0023I Ironstream cluster_name
One of these information messages is issued for each Ironstream cluster
defined in your DCE configuration file. It is followed by one or more
DCE0023I messages that provide the target XCF group and member
names of the Ironstream systems defined in the named cluster.
DCE0023I XCFGroup XCF_groupname XCFMember XCF_membername
One of these information messages is issued for each target Ironstream
that belongs to an DCE cluster. It follows that there is an associated
definition of the same XCF group and member name in the target
Ironstream instance’s SOURCE section.
DCE0030I Invalid syntax Ironstream Cluster cluster_name
The configuration file contains an Ironstream cluster definition that does
not have the correct syntax. Use the information in “Configuring the DCE
Parameters,” on page 21-1 to make suitable corrections.

Ironstream Messages

DCE0031I Maximum targets defined for Ironstream Cluster cluster_name
There is an arbitrary limit of 16 on the number of target Ironstream
systems that can be specified for a single DCE cluster and this has been
exceeded for the cluster named in the message text. You can circumvent
this problem by reducing the number of targets in the named cluster and
define an additional cluster in which the residue target Ironstream
systems can be defined.
Please contact Syncsort Product Support who will determine whether a
PTF can be raised to increase the limit. See “Diagnostics and Contacting
DCE0032I No Ironstream clusters defined
No valid IronstreamCluster group parameters have been found so DCE
has no target Ironstream for offloading data. Ensure that at least one valid
target Ironstream system has been defined in the DCE configuration file
and then restart DCE.
DCE0040I Thread started for task
One of these messages is issued for each thread activated for an DCE task.
The task name is given by task in the message text, for example ‘USS File
Scanner’.
DCE0041I Thread start failed for task : reason
A processing thread initiation has failed for the task named in the message
text. This error should not occur since if all the available tasks are
currently busy DCE will wait until one becomes free and then schedule the
task as usual. Other messages may have been issued to DCE’s SYSPRINT
or ZENTRACE output files which will help you to determine the cause.
If you are unable to resolve this issue, contact Syncsort using the
information in “Diagnostics and Contacting Syncsort Product Support,” on
page 28-1, and ensure all relevant output remains available.
DCE0042I Thread ended for task
One or more of these messages will be issued at DCE close-down as the
various tasks are cleanly terminated.
DCE0043I No entry point for thread task
An error has occurred in the thread for the task named in the message
text.
Please report this to Syncsort using the information in “Diagnostics and

Ironstream Messages

DCE0044I User user-id has marked file filename new_status
The user given by user-id in the message text has altered the status of the
USS file filename using the Ironstream USS Defaults panel from the
Ironstream Desktop. The new status is given in the message text and can
be one of:
• to be re-sent
• to stop
• as ineligible
• as eligible
When the directory is next scanned by DCE the file will be handled
according to its new status, or if the file is currently being offloaded the
process will stop.
DCE0045I Configuration written to file_system by user user_id
This information message is written when the DCE configuration has been
written to the file system given in the message text by file_system. The
user who caused the configuration to be written is given in the message
text by user_id.
DCE0047I No Default Index supplied
This information message is written when DCE cannot start because a
default Splunk index name has not been specified in the USSDefaults
group configuration for USS directories. Ensure that a default Splunk
index has been defined in the USSDefaults group and then restart DCE.
DCE0050I data_description start type: start_type
Issued at DCE startup time, this message provides information about the
start type of the task related to a particular type of data collection.
data_description gives a description of the type of data being collected, for
example ‘USS data collection’ and start_type is the type of startup, for
example ‘Warm’.
DCE0100I File details loaded from registry USS File filename
Issued during a WARM start of DCE, this message confirms that the
details of the file named in the message have been loaded from the
registry. Offloading for these files will begin from the point at which the
offload was previously terminated and thus all file data will be offloaded to
Ironstream without repetition.
DCE0101I Scan started for USS directory path
This message is issued as confirmation that DCE has started its scan of the
directory path named in the message text. This marks the beginning of the
process of applying all defined filters for that directory and offloading any
files to Ironstream that match the defined filter criteria.

Ironstream Messages

DCE0102I Unable to open file USS File filename (reason)
DCE has been unable to open the file named in the message text for the
reason given. This message is unlikely to occur under normal
circumstances so it is likely that some external interference has happened
to cause the fault. Ensure that the file name in the message has not, for
example, been deleted by another user after DCE has already determined
that the file should be offloaded.
If you are unable to resolve this issue, contact Syncsort using the
information in “Diagnostics and Contacting Syncsort Product Support,” on
page 28-1.
DCE0103I Unable to extract file statistics USS File filename
DCE has been unable to extract the named file’s statistics and therefore
the tailing process will not work for this file. Under normal circumstances
this error should not occur.
Contact Syncsort using the information in “Diagnostics and Contacting
DCE0104I Detected new file USS File filename
A new file filename has been detected since the last time the Scanning
Scheduler ran. A further message should follow indicating that file has
been queued for processing.
DCE0105I Unable to read file USS File filename (reason)
DCE has been unable to read the file whose name is given in the message
text.
Contact Syncsort using the information in “Diagnostics and Contacting
Syncsort Product Support,” on page 28-1 and provide the message given by
reason.
DCE0106I USS directory path has been added to scheduler
This message is issued to confirm that DCE has processed the
USSDirectory configuration parameter for the path named in the message
text and the Scanning Scheduler has been updated accordingly.
DCE0107I File updated since last scan USS File filename
DCE has detected that the file named in the message text has been
updated since the last scan. New data in the file will be offloaded to
Ironstream.
DCE0108I File queued for offload processing USS File filename
The file named in the message text has been queued for offloading since it
matched one of your filter definitions. A task will be scheduled to perform
the offload to Ironstream.

Ironstream Messages

DCE0109I Duplicate file detected USS File filename1 and filename2
DCE has detected that the two files named in the message are duplicates
of one another so no offload will take place (since the data has already been
offloaded). filename1 is the file that has been selected for offload and
filename2 is the duplicate file that has already been offloaded. For
additional information, see the description of the StatusHistory and
ChecksumLength configuration parameters in “Configuring the DCE
Parameters,” on page 21-1.
DCE0110I Offload processing started USS File filename (type)
Offloading has started for the file named in the message text. type
indicates the type of encoding used for the offload, and is set to AUTO,
EBCDIC or ASCII. For additional information, see the description of the
‘Encoding’ parameter on page 7.
DCE0111I Offload processing ended USS File filename Sent nnnnnnn bytes
Total bytes sent nnnnnnn
This message is issued as confirmation that the file named in the message
text has been successfully offloaded.
DCE0112I nnn USS Files pending offload due to nnn active threads
The Scanning Scheduler has files ready to offload but is unable to do so
because there are no available threads. The files will be offloaded when
existing file offloads complete and threads are released. If you notice this
message appearing frequently it indicates that the configuration value you
have specified for MaxThreads may usefully be increased.
Threads can be tied up for long periods when you are offloading volatile
files since this can lead to permanent tailing. See the description of the
TailingDelay parameter on page 6 and the TailingWait parameter on
page 6.
DCE0113I Offload aborted due to no target cluster USS File filename
This message is issued when the Scanning Scheduler has detected a file
that is eligible for offload but there is no Ironstream cluster defined to
which it can be transferred. This is likely to be because of a fault in the
DCE configuration. Ensure that you have specified at least one
IronstreamCluster parameter in your DCE configuration and that no
configuration-related error messages were issued at DCE initiation time.
If you are unable to resolve this problem, contact your local Syncsort office
for technical support. See “Diagnostics and Contacting Syncsort Product

Ironstream Messages

DCE0114I Offload delayed due to inactive Ironstream USS File filename
DCE’s Scanning Scheduler has detected the file named in the message text
is eligible for offload but it cannot initiate it because the target Ironstream
is not active.
DCE0115I Offload aborted due to Ironstream outage USS File filename Sent
nnnnnnn bytes
The target Ironstream to which data is being sent has been terminated
while DCE was sending data to it. The file affected and the number of
bytes sent so far are given in the message text. When Ironstream is
restarted, DCE will pick up the data transfer for the named file
immediately after the termination point, however, it is not generally
recommended that Ironstream be terminated while DCE is active.
DCE0116I Offload aborted due to no EOL markers found in file USS File filename
Sent nnnnnnn bytes
The offload of the file filename has been terminated after nnnnnn bytes
because of a bad record length. This message is issued when a read buffer
(32k) for an HFS file contains no end-of-line (EOL) character.
If after examining the file you are unable to determine why this message
has been issued, contact Syncsort Product Support using the information
given in “Diagnostics and Contacting Syncsort Product Support,” on
page 28-1.
DCE0117I Offload aborted due to invalid registry USS File filename
The offload for the file named in the message text has been terminated
because the file statistics that DCE has saved in its registry are no longer
valid. The implication is that the registry entry has been corrupted since
the offload started.
If you are unable to determine why this message has been issued, contact
Syncsort Product Support using the information given in “Diagnostics and
Contacting Syncsort Product Support,” on page 28-1. A COLD start of DCE
will resolve this error since the registry will be rebuilt, however, Syncsort
Product Support will probably require a dump of the registry before you do
this.

Ironstream Messages

DCE0118I Offload tailing started USS File filename Sent nnnnnnn bytes.
When this message is issued without the second part it means that DCE
has completed offloading the USS file filename and the number of bytes
offloaded to Ironstream for forwarding to the destination repository is
given. No tailing has taken place in this case.
When the second part of the message is included it means that the tailing
process is underway for the USS file filename and the number of bytes
given in the message text has just been offloaded to Ironstream for
forwarding; the second part of the message provides the total number of
bytes that has been sent so far.
Tailing enables DCE to process and offload only the data added to the end
of the file since it originally detected the EOF condition. For further
information see the section “USS File Tailing Process” on page 22-13.
DCE0119I Offload aborted due to user request USS File filename
This self-explanatory message is issued as confirmation that DCE has
successfully carried out a user request to terminate the offload of the USS
file named in the message text.
DCE0124I Unable to action user root images directory object
An error was encountered processing an HFS object. The possible values of
action are create, open, and write. For a create error, object is a directory.
For open and write errors, object is a filename. Possible reasons for this
error are insufficient access privileges or the HFS is full for open and write
conditions.
DCE0130I File history set for expiry USS File filename
During normal shutdown DCE has detected that the named file has been
deleted. The associated file’s statistics have therefore been set to expire in
the number of days specified by the StatusHistory configuration parameter
(default 30 days). During this period DCE will not re-offload any duplicate
copies of the file that might have been made.
DCE0131I File history deleted USS File filename
The statistics for the named file have been deleted at DCE shutdown time
because the number of days specified by the StatusHistory parameter have
now passed. Once this message has been issued any copies of the named
file that have been made will again be eligible for offload provided that
they pass any filtering criteria specified for files in the directory in which
they exist.

Ironstream Messages

DCE0132I File history restored USS File filename
DCE has rediscovered a file that had been deleted and so was in the
countdown period to having its history statistics removed. This situation is
detected during normal shutdown processing and causes DCE to restore
the statistics for the named file and stop the deletion countdown. This
effectively restores the situation to the same state as when the file was
discovered for the first time.
DCE0133I Checking for deleted files
This message is issued when the expiry/delete scan starts (every four
hours).
DCE0134I Check completed. nnn histories deleted.
This message is issued when the expiry/delete scan completes, where nnn
is the number of history entries that have been deleted.
DCE0135I File has been reset. Restarting offload of USS File filename.
This message is issued when a file reset has been identified, which restarts
an offload with the new data and file size. This can occur when logs are
cleared and restarted (for example, when archiving old logs). If tailing is
active when the reset is detected, then tailing will be ended before the
restart.
DCE0137I Offloading latest log data from Archive USS File filename
DCE has identified that a file has been reset and has found a matching
archive filename (file.1). DCE is now offloading the residual data that was
added before the reset and log rotation from archive filename.
DCE0138I Continuing to offload from start of USS File filename
DCE has identified that filename has been reset and archive processing
has been completed. DCE is now offloading data from the start of filename.
DCE0139I No archive file found for USS File filename
DCE has identified that filename has been reset but filename.1 either
does not exist or the calculated CHECKSUM (SHA-1) value does not match
the value stored for filename. No archive processing will take place.
DCE0140I Offload processing ended Archive USS File filename Sent nnn bytes. Total
bytes sent nnnn.
DCE has completed the offload of data from the first archive filename. This
message shows the number of bytes of “residual” data after a log rotation
and the total number of bytes sent for the original file, including the
residual data.

Ironstream Messages

DCE0150I RMF Collection suspended due to incomplete settings
DCE has been unable to start RMF data collection or to continue collecting
RMF data because the security credentials for accessing the RMF server
have not been completed, are incorrect, or the password provided expired
while the collection process was running.
Use the ‘Update RMF Collection Settings’ panel accessed from the
Ironstream desktop’s Admin menu for the appropriate system to provide
valid credentials to access the RMF server. RMF data collection will
resume once the configuration is corrected.
DCE0151I RMF Collection resumed
This information message is issued when DCE has resumed the collection
of RMF data after a temporary suspension due to an issue with the
security credentials.
DCE0152I RMF Discovery started
Issued at initialization time when DCE has successfully connected to the
RMF DDS Server and has started its resource discovery process.
DCE0153I RMF Discovery completed
Issued at initialization time when the RMF resource discovery process has
completed.
DCE0154I Connected to RMF Server IP IP_address Port port_number Socket
socket_number
This message is issued as confirmation that DCE has successfully
connected to the RMF DDS Server port port_number at IP_address using a
socket connection on socket_number.
DCE0155I Unable to connect to RMF Server IP IP_address Port port_number
DCE has been unable to establish a connection with the RMF DDS Server
at the IP address and port given in the message text. Make sure that the
IP address and port number specified in the RMF configuration member
are correct and the RMF DDS server is active.
If you are unable to resolve this problem, contact Syncsort Product Support
using the information given in “Diagnostics and Contacting Syncsort
Product Support,” on page 28-1.

Ironstream Messages

DCE0156I Socket error trying to connect to RMF Server: error_code
DCE has encountered a problem while attempting to establish a socket
connection to the RMF DDS Server. The error code given in the message
text may help you to establish what the problem is; see the IBM
publication CS IP and SNA Codes, in the chapter “Sockets and sockets
extended return codes (ERRNOs)”.
DCE0157I RMF Server request rejected: error_code
DCE has issued a request for data from the RMF server but the request
has been rejected.
Contact contact Syncsort Product Support using the information given in
“Diagnostics and Contacting Syncsort Product Support,” on page 28-1, and
provide the error code given in the message text.
DCE0158I Disconnected from RMF Server Socket socket_number
This message is issued when DCE ends its connection to the RMF server’s
socket whose number is provided in the message text.
DCE0159I RMF Discovery failed
A fault has occurred during DCE’s RMF discover processing; there may be
other messages that will help to pinpoint the cause.
Contact Syncsort Product Support using the information given in
“Diagnostics and Contacting Syncsort Product Support,” on page 28-1.
DCE0160I Reading RMF resource settings from checkpoint dataset
This message is issued during a Warm or Hot start when DCE loads the
various settings for RMF data collection from its checkpoint data set.
DCE0161I RMF Resources built nnnnnn
This information message is issued at Cold start time when DCE has
successfully contacted the RMF server and has built the number of RMF
Resources given in the message text.
DCE0162I RMF Keys built nnnnnn
Keys given in the message text.
DCE0163I RMF Elements built nnnnnn
Elements given in the message text.

Ironstream Messages

DCE0164I RMF Metrics built nnnnnn
Metrics given in the message text.
DCE0165I RMF Metrics available nnnnnn
successfully contacted the RMF server and gives the total number of RMF
metrics available for collection.
DCE0166I RMF Metrics selected nnnnnn
successfully contacted the RMF server and gives the total number of RMF
metrics selected for collection.
DCE0170I RMF checkpoint in progress
This message is issued when DCE starts its checkpointing processing.
DCE0171I RMF checkpoint completed
This message is issued when DCE has successfully completed its
checkpointing processing. The RMF metrics collection settings are read
from the checkpoint data set during a Warm or Hot start.
DCE0172I RMF checkpoint aborted due to insufficient space
DCE has determined that there is insufficient space in its checkpoint file to
accommodate all the RMF resources, keys, elements and metrics requested
for collection and forwarding to Ironstream. You will need to re-allocate the
checkpoint file and perform a Cold start of DCE to remedy this situation.
Use the information provided in the associated message DCE0173I to
define a new checkpoint dataset of an appropriate size.
DCE0173I Checkpoint blocks required nnnnnn allocated nnnnnn
This information message provides the number of checkpoint file blocks
required to checkpoint all of the RMF resources, keys, elements and
metrics requested for collection and forwarding to Ironstream. Since the
message also provides the total number of blocks it enables you to
determine whether you will need to increase the size of the checkpoint file
in the near future.
DCE0174I RMF extraction interval nnnnn of nnnnnn metrics selected:
Format format
This message is issued at the end of an RMF statistics extraction interval
and provides the number of metrics selected for forwarding from those
available. The format of the statistics is given by format and will be JSON
or XML depending on the setting of the configuration’s DataFormat
parameter.

Ironstream Messages

DCE0175I RMF extraction aborted due to inactive Ironstream
DCE has terminated its RMF extraction processing as the Ironstream
instance to which it is connected is not active. If you want to continue to
have RMF data forwarded to the destination repository, you must activate
the Ironstream instance referred to by DCE’s IronstreamCluster
parameter.
DCE0176I RMF extraction aborted due to Ironstream failure
DCE has terminated its RMF extraction processing as there is a fault in
the Ironstream instance to which it is connected. Check the console and the
Ironstream log for error messages which may help to pinpoint the cause of
the failure.
DCE0185I RMF extraction of metrics: DDS request time taken was nnnnn seconds
This is a warning that the extraction of metrics from the DDS has taken
longer than would normally be expected. This may be related to CPU usage
by other tasks or network problems.
DCE0186I RMF extraction nnnnn deadlines missed
Each time an extraction time (deadline) is missed for any reason, it is
counted and when normal service is resumed, this message is issued to
show how many deadlines were missed. Check for DCE0185I messages
prior to this message.
DCE0187I RMF extraction deadline missed by nnnnns
This message is an internal debugging message and should not occur
during normal processing.
DCE0188I RMF extraction Date day_of_week date (day dayno week weekno)
This is a date stamp message to break up the data on the SYSPRINT data
set. It will be issued before the first extraction time after initialization and
before the first extraction time after midnight.

Chapter 28 Diagnostics and Contacting
Syncsort Product Support
This chapter contains contact information for Syncsort Product Support for Ironstream
technical support.
Topics:
• “Before Calling Syncsort Product Support” on page 28-1
• “Contacting Syncsort Product Support” on page 28-2
Before Calling Syncsort Product Support

All pertinent information (listings, dumps, maintenance level, etc.) should be available for
easy reference when calling Syncsort Product Support.
If no ABEND has occurred, please issue an F jobname,LIST=MODULES command to provide a
list of modules being used and the maintenance level of each module.
If you are opening a problem through CRM, please attach a .TXT or .ZIP file with the
JESMSGLG, JESJCL, JESYSMSG, and SYSPRINT output listings.
Providing this information when initially reporting a problem allows the support team to
more quickly determine the nature of the problem. If there is a configuration problem, they
can quickly reproduce it in the lab, or if it is an ABEND, Ironstream prints enough
information to solve 90% of the problems without additional documentation.
Searching the Syncsort Knowledge Base

Ironstream is continually enhanced to add more functionality. Enhancements are
documented in Syncsort Knowledge Base articles. The Syncsort Knowledge Base contains
information about enhancements, topics of interest and product defects. The Knowledge
Base is available to licensed users and is accessible through the ‘MySupport’ section of the
Syncsort website. Search on the Ironstream product by release to find all relevant
information about Ironstream.

Diagnostics and Contacting Syncsort Product Support
Contacting Syncsort Product Support

This section contains Syncsort’s Ironstream technical support information based on your
location.
North America
Customers in North America can contact Syncsort Product Support directly for expert advice
at the numbers listed below. Email can be used for any question that does not need an
immediate reply.
Contact information:
Syncsort Product Support
Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
USA
Phone: +1-877-700-8260 – Toll Free for the United States and Canada
+1-201-930-8260 – For outside the United States and Canada
FAX: 201-930-8284
E-mail: zos_tech@syncsort.com
Europe, Middle East, and Africa

Customers in Europe, the Middle East, and Africa can contact Syncsort Product Support
directly for expert advice. Email can be used for any question that does not need an
immediate reply.
Contact information:
Syncsort - Dutch Branch
Stroombaan 4
1181 VX Amstelveen
The Netherlands
Phone: +31-20-219 9912
E-mail: SupportEMEA@syncsort.com
Other Regions
Customers in other regions should contact their local Syncsort representative.

SECTION VII Ironstream Audit Reporting
This section provides information about how to use Ironstream auditing reports.
• “Using the Ironstream Data Usage Reporter”
Chapter 29 Using the Ironstream Data
Usage Reporter
This chapter describes how to configure the Ironstream Data Usage Reporter.
Topics:
• “Configuring the Report Parameters” on page 29-2
• “Using the Report TRACE Facility” on page 29-5
• “CSV File Report Format” on page 29-5
• “Overriding the Default SMF Record Number” on page 29-6
• “System Messages for the Data Usage Reporter” on page 29-7
Overview
The Ironstream Data Usage Reporter produces reports of Ironstream output data usage
from SMF records. The report reflects the data volumes that are sent from your system to a
destination. The report defaults to SYSPRINT, but it can also be output as a CSV file, which
can then be FTP’d to a workstation and imported into a spreadsheet. You can also get a
SYSPRINT and a CSV file in one run.
Ironstream records data usage by creating SMF records, using 207 as the default SMF
number for this purpose. The report program can input any number of SMF files
concatenated together. They can be from a mix of LPARs. They do not have to be in
sequence; in fact, some time frames may overlap.
Note: If you need to override the default SMF number, refer to “Overriding the Default SMF
Record Number” on page 29-6.

Using the Ironstream Data Usage Reporter
Configuring the Report Parameters

This section describes the JCL required by the Data Usage Reporter and also explains how
to configure the report filtering and output parameters.
Basic JCL to Produce a Printed Report

The Reporter JCL will produce a summary and a daily report on all the SMF data read. It
first shows a combined LPAR report and then an individual report on each LPAR.
//SSDRREP JOB (),CLASS=A,MSGCLASS=X,REGION=0M,NOTIFY=DSS
//SSREPORT EXEC PGM=SSDFREP
//SSDRSMF DD DISP=SHR,DSN=yourSMF_dataset
//SSDRRPT DD SYSOUT=*
The report is generated on JES DD SSDRRPT. Here are some sample summary usage and
daily usage pages that were sent to PRINTSYS.
Figure 29-1. Sample Usage Summary Report
Ironstream Usage Summary Ironstream Data Usage - Acme Tools Company Page 1
Syncsort Data Reporter...........V2.01

Report run at....................Thu Dec 13 2018 09:27AM
Report run on....................System ZOS3 in Sysplex PRODPLEX
Jobname..........................SDFUR007
SMF Input file...................Concatenated SMF Datasets
SMF Input device, org............Disk, Sequential
Report Type......................Hourly
Report Breakdown.................LPARs
Date Selection
Start Date.......................Mon Mar 12 2018 02:00:00PM
End Date.........................Sun Mar 18 2018 06:00:00AM
No Active Selection Filters
LPARs encountered................ZOS3
SMF Data covers 3 days, 13 hours, 44 minutes, 50 seconds
Earliest Time Latest Time Byte Count

-------------------------- -------------------------- ----------
Mon Mar 12 2018 07:58:04PM Fri Mar 16 2018 09:00:00AM 53.87GB
Total bytes offloaded 53.87GB

Figure 29-2. Sample Daily Usage Report
Ironstream Hourly Usage Report Ironstream Data Usage - Acme Tools Company Page 2
All offloads combined
Time Range Bytes Percent of day

------------------------------ ---------- ------- -------------------------------------------------
Mon Mar 12 2018 07PM-08PM 2.43MB 0.09%
Mon Mar 12 2018 08PM-09PM 809.95MB 30.62% ***************
Mon Mar 12 2018 09PM-10PM 901.75MB 34.10% *****************
Mon Mar 12 2018 10PM-11PM 552.76MB 20.90% **********
Mon Mar 12 2018 11PM-12AM 377.88MB 14.29% *******
Monday total 2.58GB
...
Fri Mar 16 2018 12AM-01AM 328.36MB 10.29% *****

Fri Mar 16 2018 01AM-02AM 354.21MB 11.10% *****
Fri Mar 16 2018 02AM-03AM 322.28MB 10.10% *****
Fri Mar 16 2018 03AM-04AM 330.44MB 10.35% *****
Fri Mar 16 2018 04AM-05AM 332.85MB 10.43% *****
Fri Mar 16 2018 05AM-06AM 352.67MB 11.05% *****
Fri Mar 16 2018 06AM-07AM 354.30MB 11.10% *****
Fri Mar 16 2018 07AM-08AM 341.43MB 10.70% *****
Fri Mar 16 2018 08AM-09AM 360.25MB 11.29% *****
Fri Mar 16 2018 09AM-10AM 114.87MB 3.60% *
Friday total 3.12GB
March total 53.87GB
LPARs Total 53.87GB
Grand Total 53.87GB

End of Report
SYSIN Parameters
Additionally, a SYSIN DD can be added if parameters are required. There are two types of
SYSIN parameters:
• SELECT parameters for filtering the scope of the reported data.
• REPORT parameters to specify preferences for the report.
SYSIN Syntax
• Each has keyword=value operands, one per line, including the first line, which can be
formatted as:
SELECT LPAR=SYSD
JOBNAME=PRODIRON
-or-
SELECT
LPAR=SYSD
JOBNAME=PRODIRON
• All keywords are not case sensitive, and with the exception of the REPORT TITLE,
SOURCETYPE, and INDEX values, all values are not case sensitive.
• Asterisks can be used in column one before statements to create comments.
• Trailing commas are not needed but are accepted.

SELECT Parameters
The SELECT parameters can be used to restrict the scope of the report.
SELECT
SMFNO=207
STARTDATE=09/14/16
ENDDATE=12/14/2016
STARTTIME=11:33.30pm
ENDTIME=05:33PM
INDEX=ProdLogs
LPAR=SYSA
JOBNAME=IRONSMF
IPADDRESS=172.30.40.126
PORT=1007
SOURCETYPE=LOG4J
The input date format must be mm/dd[/yy[yy]].
Start/end time formats can be 12 or 24 hour. For example, 5:00PM or 17.00.
REPORT Parameters
The REPORT parameters are used to organize the report by choosing the type (hourly or
daily), format, totals, and units.
REPORT
Title='This is our company name'
Type=Daily
Format=PRINT
Break=LPARS
Numbers=MB
The default title is currently: Ironstream Usage Report
Type=Hourly|Daily
Accumulate totals into Daily or Hourly slots. The default is Daily.
A Daily report type accumulates values into whole day slots; whereas, Hourly accumulates
values into one-hour slots. An Hourly report also shows daily totals.
Format=PRINT|CSV
Physical format of report. The default is SYSPRINT. The same report can be output as a
CSV file.
Report Format can be specified multiple times by specifying PRINT and CSV once only for
each report. You can also get a PRINT and a CSV in one run by specifying both types for a
report, as shown here:
REPORT
Title='ACME Tools Inc.'
Format=PRINT
Format=CSV
Break=Path|LPAR|LPARS
Accumulate totals by Path or by LPAR, or by all LPARS combined.
Numbers=AUTO|Bytes|KB|MB|GB|TB

Auto formats numbers in TB/GB/MB/KB, according to their magnitude. KB, MB, GB, and
TB will use those units throughout. Bytes shows the exact numbers in bytes. This option can
be useful for testing and checking results. MB is the default.
Using the Report TRACE Facility

In addition to the SYSIN parameters an EXEC PARM of TRACE=YES or TRACE=ALL or
TRACE=SMF can be used by support staff to get full trace information to assist in any
issues that require debugging.
• TRACE=YES gives a trace of all the events occurring.
• TRACE=ALL additionally includes a full dump of each incoming record.
• TRACE=SMF only dumps the incoming SMF records with expansion of timestamps.
For example:
//SDRTEST EXEC PGM=SSDFREP,PARM='TRACE=ALL'
This Reporter JCL requires an additional DD statement to receive TRACE output:
//SDRTRACE DD SYSOUT=*
CSV File Report Format

Creating a CSV file requires the following extra JCL statement:
//SSDRCSV DD DISP=SHR,DSN=DSS.SMF.V110.CSVLIB(CSVREP) << CSV will go here
This creates a file shown in Figure 29-3.
Figure 29-3. Sample Data Usage Report in CSV Format
LPAR,Jobname,Sourcetype,Index,IPAddress,Timestamp,Byte count
PLX1,SDFDSSMF,syncsortMF,zsmf,172.30.40.126:8010,Wed Nov 23 10:25:31.01,9244
PLX1,SDFDSSMF,syncsortMF,zsmf,172.30.40.126:8010,Wed Nov 23 11:00:00.00,17018
PLX1,SDFDSSMF,syncsortMF,zsmf,172.30.40.126:8010,Thu Nov 24 12:00:00.00,16925
PLX1,SDFDSSMF,syncsortMF,zsmf,172.30.40.126:8010,Thu Nov 24 16:34:00.17,18488
PLX1,SDFDSSMF,syncsortMF,zsmf,172.30.40.126:8010,Mon Nov 28 11:00:00.00,31707
This can be FTP'd back to a workstation where it can be imported into a spreadsheet, as
shown in Figure 29-4:

Figure 29-4. Sample Data Usage Report in a Spreadsheet
This enables you to generate graphs that suit your needs.

It can also be extremely useful in testing and support because it represents the raw data, as
extracted from the SMF records.
Overriding the Default SMF Record Number

This section explains how to override the default SMF Report number by updating the
Ironstream configuration file and also describes how to copy and rename the SMF 207
modules in the Ironstream load library.
Ironstream Configuration File

Ironstream SMF records are normally collected using SMF record number 207. If you have
chosen to use a different SMF record number, you can supply a configuration parameter
designating the desired SMF number. For example, to specify 201, the configuration
statement would be:
"USAGE_SMF_NUMBER":"201"
This statement must occur immediately after the NAME statement in the [SYSTEM] section
in the Ironstream configuration file.
Copying and Renaming the Default SMF Modules

You must follow these directions if you have chosen to use a different SMF record number
for Ironstream reporting and are forwarding that data to a destination.
For SMF processing, the last three digits of a module name is the SMF number that is
formatted by Ironstream to forward data. If a non-default SMF number is used, then the
module that formats that SMF number must be copied and renamed to contain the new SMF
number. There are two modules for each SMF type in the Ironstream load library that are
used in the formatting: SSDFNnnn and SSDFFnnn.
Continuing the SMF 207 example, the two modules in the Ironstream load library are
SSDFN207 and SSDFF207. Therefore, if the default number has been changed from 207 to

201 in the Ironstream configuration file, then these two members must be copied and
renamed to SSDFN201 and SSDFF201.
System Messages for the Data Usage Reporter

System messages generated when using the Ironstream Data Usage Reporter are in the
SSDF0950–SSDF0978 range and are described in “Ironstream Messages,” on page 27-1.


SECTION VIII Appendices
This section contains appendices for certain Ironstream features.

• Appendix A, ”Forwarded Data Formats”
• Appendix B, ”The SSDFCPR Utility”
Appendix A Forwarded Data Formats
This chapter contains the data formats that are forwarded to a destination.
Topics:
• “Syslog Format” on page A-2
• “FILELOAD Format” on page A-3
• “SYSOUT Format” on page A-3
• “Log4j Format” on page A-4
• “Alert Format” on page A-4
• “SyslogD Format” on page A-5
Ironstream Configuration and User’s Guide A–1

Forwarded Data Formats
Syslog Format
The fields forwarded to a destination from syslog data are as follows:
MFSOURCETYPE:SYSLOG Source type value for a destination

DATETIME:yyyy-mm-dd hh:mm:ss.th Date and time data forwarded in the
format shown
SYSLOGSYSTEMNAME:system_id The system identifier
JOBID:job_id The job identifier (job number) both for
messages and WTO commands
MSGNUM:message_number The message number
MSGTXT:message_text The text of the message
The following fields will be available when a command/response is being forwarded:
ACTION:message_type The type of message and can be set as

follows:
INFORMATIONAL
BROADCAST
EVENTUAL_ACTION
IMMEDIATE_ACTION
CRITICAL_EVENTUAL_ACTION
WTOR
COMMAND:command_text Command entered
CONSOLE:console Command source
CONSOLEID:MCS_console Command source
JOBNAME:jobname Jobname for internal commands
RESPONSE:response Command response(s)
All syslog messages appear in their entirety under the keyword of MSGTXT. Multiple lines
of syslog text are merged together with an ASCII NL character sequence between them so
that when listed in a destination they appear as they did on syslog or on the console. The
RESPONSE and MSGTXT fields also contain the MSGID of a WTO and/or a COMMAND
response.
A–2 Ironstream Configuration and User’s Guide

FILELOAD Format
The fields forwarded to a destination from sequential files are as follows:
MFSOURCETYPE:FILE Source type value for a destination

format shown
JOBNAME:jobname The job name
STEPNAME:stepname The EXEC step name
DDN:ddname The DD name
JOBID:job_id The job identifier (job number)
DSN:dsname The data set name
DATA:file record The record from the selected file
SYSOUT Format
The keyed fields forwarded to a destination from SYSOUT files are:

format shown
DDNAME:ddname The DD name
JOBID:jobid The job identifier (job number)
JOBNAME:jobname The job name
MFSOURCETYPE:SYSOUT Source type value for a destination
PROCSTEP:procstep The PROC’s step name
SMFID:smfid The SMF record number
STEPNAME:stepname The EXEC step name
SYSNAME:system_id The system identifier
TEXT:block format spool data Spool file data

Log4j Format
The keyed fields forwarded to a destination from log4j files are:
MFSOURCETYPE:LOG4J Source type value for a destination

DATETIME:yyyy-mm-dd hh:mm:ss,sss Time data forwarded in the format shown
JOBID:job_id The job identifier (job number)
MSGTXT:message_text The text of the message
Alert Format
The keyed fields forwarded to a destination for alerts generated by the NMC components:
DATETIME:yyyy-mm-dd hh:mm:ss.ss Date and time data forwarded in the

format shown
DATETIMEUTC:yyyy-mm-dd hh:mm:ss UTC time data forwarded
MFSOURCETYPE:ZENALERT Fixed type field always set to
‘ZENALERT’
ZENALERTAPP:NMC_identifier Identifier of the ZEN Network
Monitoring Component that issued the
alert
ZENALERTCATEGORY:category Alert category
ZENALERTCLASS:class Alert class
ZENALERTID:identifier Alert identifier
ZENALERTMSG:message_text Alert console message issued
ZENALERTSEVERITY:severity Alert severity
ZENALERTSRC:alert_text Alert text recorded in ZEN
ZENALERTSYSPLEXNAME:sysplex Sysplex from which the alert was issued
ZENALERTSYSTEMNAME:system System (LPAR) from which the alert was
issued
ZENALERTTYPE:alert_type Type of alert
ZENVERSION:PTF_level The PTF level of the ZEN system that
issued the alert

SyslogD Format
The keyed fields forwarded to a destination for SyslogD data are:
DATETIME:yyyy-mm-dd hh:mm:ss.ss Time data forwarded in the format shown

DATETIMEUTC:yyyy-mm-dd hh:mm:ss UTC time data forwarded
MFSOURCETYPE: SYSLOGD Fixed type field always set to ‘SYSLOGD’
SYSLOGDCLASS:class The class of the SyslogD message
SYSLOGDDEMON:daemon_id The name of the daemon that generated
the SyslogD message
SYSLOGDFACILITY:facility The facility controlling SyslogD
SYSLOGDID:message_id The message identifier
SYSLOGDMSG:message_text Full text of the SyslogD message
SYSLOGDPRIORITY:priority The message priority
SYSLOGDSEVERITY:severity The message severity level
SYSLOGDSYSPLEXNAME:sysplex Sysplex from which the alert was issued
SYSLOGDSYSTEMNAME:system System (LPAR) from which the alert was
issued
SYSLOGD_ID:identifier Identifier from the message text
SYSLOGD_REPLY:value Value associated with the identifier above
ZENVERSION:PTF_level The PTF level of the ZEN system that
issued the alert
Anything detected in the message text that starts with the characters ‘SYSLOGD_’ is parsed
out of the message text so it can be more easily processed by a destination. Some messages
can have up to twenty additional fields that have been parsed out of the original message.
The fields SYSLOGD_ID and SYSLOGD_REPLY above are used to hold those additional fields.
Additional keywords are also generated from repeated fields in the message. This applies
primarily when fields occur for both input and for output. For example, here is a typical
SyslogD message:
SYSLOGDMSG: EZD0836I Packet permitted: 09/11/2007 15:23:06.95 sipaddr=
10.11.2.4,dipaddr = 10.81.2.2,proto =icmp(1) type= 3,code=1 Interface= 10.11.2.4 (O)
secclass= 255 dest= local len= 56 tunnelID= Y4 ifcname= MPC4124L embsipaddr= 10.81.2.2
embdipaddr= 10.81.8.8 embproto= udp(17) sport= 1050 dport= 10173 -= Interface=
10.5.1.90 (I) secclass= 255 dest= local len= 64 vpnaction= N/A tunnelID= N/A ifcname=
LNKOSA48 fragment= N
Note the emboldened input and output interface IP addresses in this message that are
formed into keywords such as these:
"SYSLOGD_INTERFACE_I":"10.11.2.4"
"SYSLOGD_INTERFACE_O":"10.5.1.90"


Appendix B The SSDFCPR Utility
This chapter describes how to use the SSDFCPR utility.
Topics:
• “Overview of SSDFCPR” on page B-1
• “Executing SSDFCPR” on page B-1
Overview of SSDFCPR
SSDFCPR is a utility program that produces a report containing information about the
machine on which it is run. Syncsort Inc. may need this information in order to provide
appropriate license keys for Ironstream.
Executing SSDFCPR
Syncsort may request that you run the SSDFCPR utility on each LPAR where Ironstream is
licensed. Here is sample JCL:
//jobcard
//PRINT EXEC PGM=SSDFCPR
//STEPLIB DD DISP=SHR,DSN=hlq.SSDFAUTH
E-mail the output from each LPAR to zos_tech@syncsort.com. Syncsort will generate license
keys for your systems based on the information in these reports.
Ironstream Configuration and User’s Guide B–1

The SSDFCPR Utility
B–2 Ironstream Configuration and User’s Guide

Index
A
Alert Forwarding EE MONITOR 14-10

Configuring ZEN for 14-2 FTP CONTROL 14-8
Fields forwarded to Splunk A-4, A-5 IP MONITOR 14-13
From FTP CONTROL 14-9 LINUX MONITOR 14-7
From the EE MONITOR 14-12 OSA MONITOR 14-3
From the IP MONITOR 14-19 Alerts issued
From the LINUX MONITOR 14-8 By FTP CONTROL 14-8
From the OSA MONITOR 14-7 By the EE MONITOR 14-10
Overview 14-2 By the IP MONITOR 14-13
Alert generation By the LINUX MONITOR 14-7
Defaults 14-3 By the OSA MONITOR 14-3
Out-of-the-Box 14-3 API, Ironstream 18-2
Overview 14-3 ASMFILTR 11-1
Alert Monitoring
Capturing sequential data 16-1 Typical non-SSL parameters 7-27

JCL example 16-2 Configuration examples
Configuration Log4j data 7-30
Data filtering 11-1 Log4j data ingestion 7-31
DCE 21-2 Log4j from z/OS data set 7-32
DESTINATION Section 7-11 Log4j from z/OS data set with PATTERN 7-32
Examples 7-29 SMF data 7-29
General Syntax Rules 7-3 SMF offline ingestion 7-31
Ironstream API 18-2 Syslog data 7-30
KEYS Section 7-6 Syslog data with SSL and Translate 7-33
Parameter definitions 7-6 Contact details 28-2
SDFSAMP data set 7-2 Custom CICS SMF records
SOURCE Section 7-16 Flow of implementation steps 12-23
SSDFCONF DD statement 7-2 Implement custom monitor dictionary 12-23
SYMBOLS Section 7-6 SSDFGDIC report 12-28
SYSTEM Section 7-7 SSDFGDIC utility 12-25
Daemon Sequential data offline ingestion 16-1

z/OS Syslog 14-19 Data Store
z/OS SyslogD 14-19 Data arrival/transmission rates 26-2
Data filtering 11-1 Full condition
Syslog 11-2 Data collection termination 26-2
Data formats Ironstream API reason codes 18-20
Syslog data A-2 Messages issued when full 26-2
Data Loss Prevention Recovering data 26-2
Best practices 10-4
Splunk connection failure 26-2
Overview 10-1
TCP failure 26-2
Parameters 10-3 Data Type
Requirements 10-2 DB2Trigger 7-20
Splunk parameters 10-4 IMS 7-27
Data sets
Ironstream Configuration and User’s Guide Index–i

IRONSTREAM_API 7-26 DATA LOSS PREVENTION 7-13
LOG4J 7-24 ACK RETRY LIMIT 7-14
RACF 7-19 ACK TIMEOUT LIMIT 7-14
SMF 7-21 AUX SPACE NAME 7-14
SYSLOG 7-20 DLP COLD START 7-14
SYSOUT 7-25 DLP STREAM NAME 7-13
SYSTEMSTATE 7-20 TOKEN 7-16
XCF 7-25
Data Usage Reporter TYPE = HTTP or HTTPS 7-15
Configuration 29-2 DATASTORESIZE 7-12
CSV file report format 29-5 DATASTORESIZEQUEUE 7-12
Override default SMF report number 29-6 INDEX 7-15
Overview 29-1 IPADDRESS 7-15
Using the TRACE facility 29-5 KEEP ALIVE 7-15
DB2 KEYRING 7-16
Data definitions 15-2 PASSWORD 7-16
Insert trigger 15-1 PORT 7-15
Sample DDL 15-1 RETRY ON START 7-12, 7-13
Table data RETRY ON START INTERVAL 7-13
SDFSAMP 15-1 RETRY ON START LIMIT 7-13
SSDFPROC 15-1 SOURCE 7-12
SSDFTRIG 15-1 SOURCETYPE 7-13
Trigger rules 15-2 SSL 7-16
DCE STASH FILE 7-16
Configuring 21-2 THROTTLING RATE 7-13
Global parameters 21-3 TYPE 7-15
Parameter Syntax 21-5 Dynamic Reconfiguration
RMF data forwarder 23-1 Commands 9-3
USS file collection 22-1 Limitations 9-2
DESTINATION parameter Overview 9-1
CERTIFICATE 7-16 Procedure 9-3
EE MONITOR Lo4j data ingestion 7-31

Alerts forwarded 14-12 Log4j data 7-30
Elastic Log4j from z/OS data set 7-32
Displaying data in Kibana 4-4 Log4j from z/OS data set with PATTERN 7-32
Field mappings and defaults 4-4 SMF data 7-29
Forward data to Logstash 4-2 SMF offline ingestion 7-31
Overview 4-1 Syslog data 7-30
Receiving data in Elasticsearch 4-4 Syslog data with SSL and Translate 7-33
Enterprise Security TA-ES for Splunk 24-1
Examples
FTP CONTROL
Alerts forwarded 14-9
Importing Data 26-2 Extraction process 20-5

IMS log record forwarding Log record field reference 20-8
Asynchronous log gathering 20-4 Overview 20-2
Index–ii Ironstream Configuration and User’s Guide

Processing log records 20-7 Ironstream API
Synchronous log gathering 20-3 CICS 18-11
Include parameters 21-4 Code Examples 18-21, 18-36
IP MONITOR Configuring data type
Alerts forwarded 14-19 Class parameters 18-3
Ironstream XCF parameters 18-3
Cluster parameters 21-3 Overview 18-2
Configuration overview 7-2 SSDFAPI routine 18-5
Configuring SyslogD for 14-20 SSDFCAPI routine 18-11
Forwarding SyslogD messages to 14-19 Troubleshooting 18-17
Messages 27-1 Ironstream Multi-send API
Printing statistics 12-22, 17-2, 25-2 SSDFPAPI routine 18-12
Utilities
SSDFCPR B-1
SSDFDB2F 15-2
ZEN parameter 14-3
JESJCL 13-2 JESMSGLG 13-2

JESJCLIN 13-2 JESYSMSG 13-2
Kafka Overview 5-2

Activity Status 5-8 KEYS parameter 7-6
APF Authorization 5-5 KEY 7-6
Apply Function 5-4 KEY_WARN_DAYS 7-6
Configuring for Ironstream 5-6 Keyword syntax 7-3
Installing 5-3
LINUX MONITOR log4j.configurationFile 19-1

Alerts forwarded 14-8 log4j.properties 19-1
Log4j Forwarding log4j.xml 19-1
Fields forwarded to Splunk A-4
Message Flood Automation 26-1 Messages 27-1
Network Contention
Avoiding 26-1
Offline ingestion OSA MONITOR

Sequential data 16-1 Alerts forwarded 14-7
Offline ingestion data sets
Sequential data example 16-2
OMVS 19-1
Ironstream Configuration and User’s Guide Index–iii

P
Parameter syntax 7-3, 21-5 USS Directory group 22-10

Parameters 7-6 USS Filter group 22-8
DCE global 21-3 PATTERN
Include 21-4 Using in offline Log4j processing 19-4
Ironstream Cluster 21-3 Printing Ironstream statistics 12-22, 17-2, 25-2
USS Defaults group 22-5
Reporter Overview 23-1

Data Usage 29-1 Scenario for setting filters 23-10
RMF data forwarder Security settings 23-5
Configuring 23-2 Setting filters with Ironstream Desktop 23-6
Filters panel overview 23-6
Sample SSDFPROC 15-2

SDF2Appender 19-1
SDFAppender 19-1
SDFSAMP 11-1, 15-1
SDFSAMP data set 7-2
Sequential file format A-3
Setup
Elastic Stack 4-1
Kafka 5-2, i-i
Splunk 3-1
SMF record filtering
Custom CICS monitor dictionary 12-23
Manually defining SMF filters 12-7
Overview 12-2
Sample SMF filter configurations 12-31
SMF Filter Configuration Builder GUI 12-13
Supported SMF record types 12-4
User exits vs. Real-time INMEM 12-3
Using the READ command 12-22
WHERE search conditions 12-7
SOURCE parameter 7-17
Index–iv Ironstream Configuration and User’s Guide

DB2TRIGGER XCF
DB2TOKEN 7-20 XCFGROUP 7-26
IMS XCFMEMBER 7-26
CATEGORY 7-27 Splunk
IMS_SYSTEM_ID 7-27 Data formats A-2
IRONSTREAM_API 18-3 Enterprise Security TA-ES 24-1
CLASS 7-26, 18-3 Overview 3-1
SUBTYPE 7-26, 18-4 Setup Index 3-3
TYPE 7-26, 18-3 Setup non-SSL port 3-2
XCFGROUP 7-26, 18-3 Setup SSL port 3-2
XCFMEMBER 7-26, 18-3 Splunk connection failure
Impact on Data Store 26-2
LOG4J SSDA0037 7-17
FILENAME 7-24
SSDA0500 7-17
JAVA64BIT 7-24 SSDA1047 7-17
JAVAHOME 7-24 SSDA1141 7-17
NAMEDPIPE 7-24 SSDF0037 7-17
PATTERN 7-25 SSDF0500 7-17
SDFHOME 7-24 SSDF1047 7-17
TIMESTAMP 7-25 SSDF1141 7-17
SMF SSDFAPI routine 18-5
INCLUDE 7-23 SSDFCONF DD statement 7-2
INMEM_RESOURCE 7-22 SSDFCPR Utility B-1
SECURITY_PRODUCT 7-21 SSDFDB2F Utility 15-2
SELECT 7-23 SSDFFLOG macro 11-2
SMF_SOURCE 7-22 SSDFPAPI routine 18-12
SSDFPROC 15-1
SUBTYPE 7-23
SSDFTRIG 15-1
VERSION 7-22 SSDU0037 7-17
WHERE 7-24 SSDU0500 7-17
SYSLOG SSDU1047 7-17
FILTER 7-21 SSDU1141 7-17
HARDCOPY 7-21 Syncsort
LINE BREAK 7-21 Contacting for support 28-2
ROUTCDE 7-21 Syslog
SCOPE 7-20 data format A-2
SYSOUT data type 7-20
EXCLUDE_JOB_IF_JOBNAME 7-25 Syslog filtering types
EXCLUDE_JOB_WHEN_OUTCLASS 7- ACF2 11-2
ALL 11-2
25
CICS 11-2
FILTER_JOB_ON_filter_keyword 7-25 DB2 11-2
PRINT_MODE 7-25 DB2L 11-2
PRINT_SEND 7-25 IEF 11-2
PRINT_WRAP 7-25 IMS 11-2
SELECT_DATA_SET_IN_JOB_WITH_dat RACF 11-2
a_set_keyword 7-25 TOPS 11-2
SELECT_JOB_IF_job_keyword 7-25 USS 11-2
SYSOUT_NEW_JOB_SCAN_WAIT_TIME WAS 11-2
7-25 WEBS 11-2
SYSOUT_NEW_OUTPUT_SCAN_WAIT_ Syslog message filtering 11-2
Selection processing sequence 11-3
TIME 7-25
SSDFFLOG macro 11-2
TRANSLATE_TABLE 7-17 Typical macro definition 11-2
Types of DATATYPE 7-19 SyslogD messages
Daemon 14-19
Display in ZEN System Log 14-19
Ironstream Configuration and User’s Guide Index–v

Driving ZEN automation from 14-20 Selection and Forwarding process 13-2
Filtering 14-19 Selection keywords and rules 13-6
Forwarding to Ironstream® 14-19 SELECT_JOB_IF keywords 13-6
Forwarding to ZEN Network Log 14-20 SPIN data set 13-1
Messages available by default 14-20 SYSOUT Forwarding Examples
SYSOUT Forwarding JESMSGLG from IMS 13-16
Configuration 13-2 JESYSMSG from two jobs 13-16
Fields forwarded to Splunk A-3 Output from a DD name 13-15
Filter keywords and rules 13-6 Output from two jobs 13-16
FILTER_JOB_ON keywords 13-8 Specific data set from all CICS jobs 13-16
Format of forwarded data 13-2 Submitted JCL from all STC 13-16
FREE=CLOSE 13-1 SYSTEM parameter 7-7
Increasing granularity 13-2 AUTO_RESTART 7-9
JESJCL 13-2 DATE_OFFSET 7-9
JESJCLIN 13-2 FILELOAD 7-7
JESMSGLG 13-2 IMPORT 7-8
JESYSMSG 13-2 KEEP_ALIVE 7-9
Job and data set selection 13-4 LOADLIB 7-7
Job exclusion criteria 13-5 NAME 7-7
Job filtering criteria 13-5 RACFLOAD 7-8
Overview 13-1 TERMINATE_ON_FAILURE 7-10
Parameter examples 13-15 TIMEZONE_OFFSET 7-8
SELECT_DATA_SET IN_JOB_WITH USAGE_SMF_NUMBER 7-7
keywords 13-7
TCP failure SSDA1047 7-17

Impact on Data Store 26-2 SSDA1141 7-17
Technical support SSDF0037 7-17
Contacting Syncsort 28-2 SSDF0500 7-17
Translate tables SSDF1047 7-17
Creating your own 7-17 SSDF1141 7-17
EBCDIC 037 7-17 SSDU0037 7-17
EBCDIC 1047 7-17 SSDU0500 7-17
EBCDIC 273/1141 7-17 SSDU1047 7-17
EBCDIC 500/1148 7-17 SSDU1141 7-17
SSDA0037 7-17 Typical non-SSL configuration parameters 7-27
SSDA0500 7-17
USS file collection Filter group parameters 22-8

Defaults group parameters 22-5 Modifying processing with Ironstream
Directory group parameters 22-10 Desktop 22-14
Duplicate file detection 22-12 Overview 22-1
File filtering 22-9 Tailing process 22-13
WHERE SMF search conditions Validate with PARM option 12-12

Null processing 12-11 WLM environment 15-2
Operators and operands 12-9
Overview 12-7
Syntax 12-8
Index–vi Ironstream Configuration and User’s Guide

Z
z/OS Syslog Daemon 14-19

ZEN
EE MONITOR
Forwarding Alerts & SyslogD messages 14-2
FTP CONTROL
IP MONITOR
Ironstream Parameter 14-3
LINUX MONITOR
OSA MONITOR
Ironstream Configuration and User’s Guide Index–vii

Index–viii Ironstream Configuration and User’s Guide

Ironstream Configuration and Users Guide v2.1 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ironstream Configuration and Users Guide v2.1 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Ironstream™

Configuration and User’s Guide

Version 2.1 - PTF SDF2179

Version 2.1 - PTF SDF2179

List of Panels ............................................................................................................... xv

List of Tables .............................................................................................................. xvii

SECTION I, About Ironstream

Chapter 2: Understanding Ironstream ................................................................. 2-1

Ironstream Configuration and User’s Guide i

Chapter 4: Setting Up Elastic for Ironstream ..................................................... 4-1

Chapter 5: Setting Up Kafka for Ironstream ....................................................... 5-1

ii Ironstream Configuration and User’s Guide

Chapter 7: Manually Setting Ironstream Parameters ...................................... 7-1

Ironstream Configuration and User’s Guide iii

Chapter 8: Controlling Ironstream Components ............................................... 8-1

Chapter 9: Dynamically Modifying a Running Ironstream Configuration ... 9-1

Chapter 10: Configuring Data Loss Prevention ................................................ 10-1

iv Ironstream Configuration and User’s Guide

Chapter 12: SMF Record Filtering ....................................................................... 12-1

Chapter 13: SYSOUT Forwarding ......................................................................... 13-1

Ironstream Configuration and User’s Guide v

Chapter 14: Alerts and SyslogD Forwarding ..................................................... 14-1

Chapter 15: DB2 Data Forwarding ...................................................................... 15-1

vi Ironstream Configuration and User’s Guide

Chapter 17: System State Forwarding ................................................................ 17-1

Ironstream Configuration and User’s Guide vii

Chapter 20: IMS Log Record Forwarding ........................................................... 20-1

viii Ironstream Configuration and User’s Guide

Chapter 22: Setting Up USS File Collection ....................................................... 22-1

Chapter 23: Setting Up the RMF Data Forwarder ........................................... 23-1

Ironstream Configuration and User’s Guide ix

SECTION VI, Integration with Splunk Premium Applications

SECTION VI, Troubleshooting Ironstream

x Ironstream Configuration and User’s Guide

Chapter 26: Operational Considerations ........................................................... 26-1

Chapter 27: Ironstream Messages ...................................................................... 27-1

SECTION VII, Ironstream Audit Reporting

Ironstream Configuration and User’s Guide xi

Appendix B: The SSDFCPR Utility ......................................................................... B-1

xii Ironstream Configuration and User’s Guide

Ironstream Configuration and User’s Guide xiii

Ironstream Configuration and User’s Guide xv

Ironstream Configuration and User’s Guide xvii

Ironstream Configuration and User’s Guide 1–1

What’s in this Guide

1–2 Ironstream Configuration and User’s Guide

Table 1-1: Sections and Chapters in this Guide

Ironstream Configuration and User’s Guide 1–3

Table 1-1: Sections and Chapters in this Guide

Syncsort Knowledge Base

1–4 Ironstream Configuration and User’s Guide

Ironstream Configuration and User’s Guide 1–5

1–6 Ironstream Configuration and User’s Guide

This chapter provides an overview of Ironstream and its components.

What Data Does Ironstream Collect from z/OS?

Ironstream Configuration and User’s Guide 2–1

What Happens to z/OS Data in a Destination?

What Happens If Ironstream Is Unable to Deliver Data to a

Fast and Efficient Performance

2–2 Ironstream Configuration and User’s Guide

Data Collection Extension (DCE)

The Ironstream Desktop (IDT)

Network Monitoring Components Alerts