Please include the variables for SMCD and SMCR for SMF 119 type 2, and SMF 119 type 38-45

Kekahu AluliI of the CDP/ZLDA team was able to meet with the BoA team in RTP a few weeks back for a tech council and when they explained the Idea, it was just for CDP/ZLDA to support the SMF119 subtypes that are missing, not actually any data curation or dashboards on Splunk. This idea will be transferred back to CDP/ZLDA for them to disposition.

Comment from Randy Kunkel:
Hi Jim,
My tester collected an SMF 119 Subtype 02 record for me. Here is a link to our publications which show the breakdown of this record:

https://www.ibm.com/docs/en/zos/3.1.0?topic=records-tcp-connection-termination-record-subtype-2


We have a local application that breaks down the SMF 119 records. In this case,
we were using an application called DMP1030 which was using SMC-Rv1. The application name, DMP1030 in this
case, is located at offset 0 in the TCP connection termination section, field SMF119AP_TTRName. Could you
please double check your SMF119 Subtype 02 records on your end to see if this gets the information that you
need.
-------------------------------------------------------------------------------
26 VIC207 TCP 00770002 15:19:11.200000 Tcp Term
SMF 119 Header: Length.. 468 Flags... 5E
Type.... 119 Date.... 125.143 Time.... 15:19:11.20 Sy
SubType. 2 Tcp Term TRN..... 6
*************************************************
Identification:
SysName. VIC207 SysplexN LOCAL Stack... TCPCS5 Release. 030100 Co
ASName.. TCPCS5 UserId.. ***N/A** Asid.... 37 Reason.. Event comple
Tcp Termination:
LIP..... xxx.xxx.xxx.xxx-1030 RIP..... xxx.xxx.xxx.xxx-1037
RName... DMP1030 ConnId.. 00000026 TlsCs... UnSecure TlsPs... TTLS Off Te
SmcStatu Active SmcdStat Inactive
Tcpip SMF Record Report
IPSecFlg ()
SubTask. 006F9040 SDate... 125.143 STime... 19:18:25.89
EDate... 125.143 ETime... 19:19:11.20
InBytes. 45000 OutBytes 45000
SWS..... 128000 MSWS.... 128000 CWS..... 44740 SMS..... 8948 RT
Status.. 0 TOS..... 0 XRT..... 0
Profile. Policy..
InSeg... 51 OutSeg.. 51
SSTCK... 2025/05/23 19:18:25.898398 ESTCK... 2025/05/23 19:19:11.200369
DupAcksR 0
LclSmcId A31C0101 RmtSmcId 90BC0101 SmcRsn.. 00000000 (OK)
SmcFlags
LclSmcBf 128 RmtSmcBf 64
XRT32... 0 SmcdRsn. 0000530F (NORMTSUPP)
SMC protocol. V1
Smcrv2Rsn. 00000000 (OK)
Smcdv2Rsn. 00005325 (OK)
Application Data:
TTAppl.. SENDING:0000001000......................


000000 01D40000 5E770054 27700125 143FF3F0 F9F0E2E3 C3400002 00060000

Self Defining Offset.. 001c Length.. 48 Number.. 6
000000 0000004C 00400001 0000008C 01200001 000001AC 00000000 000001AC 00000000
000020 000001AC 00280001 000001D4 00000000

Section. 0 Offset.. 004c Length.. 64 Number.. 1
000000 E5C9C3F2 F0F74040 D3D6C3C1 D3404040 E3C3D7C3 E2F54040 F0F3F0F1 F0F04040
000020 E3C3D740 40404040 E3C3D7C3 E2F54040 5C5C5CD5 61C15C5C 00000037 08000000

Section. 1 Offset.. 008c Length.. 288 Number.. 1
000000 C4D4D7F1 F0F3F040 00000026 01015201 006F9040 006A0EBD 0125143F 006A2070
000020 0125143F 00000000 00000000 0000FFFF xxxxxxxx 00000000 00000000 0000FFFF
000040 xxxxxxxx 040D0406 00000000 0000AFC8 00000000 0000AFC8 0001F400 0001F400
000060 0000AEC4 000022F4 0000002C 0000002C 00000000 40404040 40404040 40404040
000080 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040
0000A0 40404040 40404040 40404040 40404040 40404040 00000000 00000033 00000000
0000C0 00000033 E0EE2BF2 0179E24C E0EE2C1D 358711C3 00000000 A31C0101 90BC0101
0000E0 00000000 00001000 00000080 00000040 00000000 0000530F 00000000 00000000
000100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00005325

Section. 2 Offset.. 01ac Length.. 0 Number.. 0

Section. 3 Offset.. 01ac Length.. 0 Number.. 0

Section. 4 Offset.. 01ac Length.. 40 Number.. 1
000000 E2C5D5C4 C9D5C77A F0F0F0F0 F0F0F1F0 F0F04B4B 4B4B4B4B 4B4B4B4B 4B4B4B4B
000020 4B4B4B4B 4B4B4B4B

Section. 5 Offset.. 01d4 Length.. 0 Number.. 0

I reread "This record also contains inbound/outbound bytes counts. So simply collecting and analyzing the SMC flags in these connection termination records, you can see all of the socket jobnames which are using SMC on this stack. You could also examine the other SMF 119 records to gain insights at link group and RNIC levels. Just wanted to let you know the jobnames are available today through the subtype 02 record."

Either our 119 type 2 are not complete, or We do see 119 type 38 bytes counts, but only see TCPIP as the Jobname?

Connecting the 2 records so far has not provided the any understanding of the Application use.

I will continue to look at these records.

MXGSAS may be needs an update as well.

Jim

On your question all or nothing, We do have sas skills that can interpret SMF data, therefor updating smf 119 records will provide some relief, the zLDA method would allow a more general group to see and report, but if that takes longer, then just the data for now we can work with. But long term would like Splunk to interpret complete smf 119 records for better reporting by more technicians.

Randy Kunkel, our network interface architect, passed along the following response (and question):

I believe I have an understanding of your requests. As I stated above, your request consists of two parts:
1) Updates to existing CommServer SMF 119 records
2) Requests for zLDA updates to support the CommServer SMF 119 records

Question: Is this request an "all or nothing" request? Meaning, if CommServer can update the SMF 119 records, but the zLDA product area contained within Common Data Provider (CDP) is unable to fully port the records to Splunk, does that provide any value to your task at hand?
My contacts in the CDP area stated they can certainly support it in CDP, but currently they don't see a path in which they would create anything custom in Splunk. At this point in time they are not adding any new content to their splunk dashboards. They are willing to create a request in their product area idea portal, but that would be to support raw SMF119, and nothing curated or no matching insights in Splunk.

Without any changes to our SMF records, you could draw some insights into what applications are using SMC.
SMF 119 - TCP Connection Termination section (subtype 02)
SMF119AP_TTSMCStatus - If set to 1, then this connection was using SMC-R
SMF119AP_TTSMCDStatus = If set to 1, then this connection was using SMC-D
SMF119AP_TTRName - TCP socket resource name
This record also contains inbound/outbound bytes counts. So simply collecting and analyzing the SMC flags in these connection termination records, you can see all of the socket jobnames which are using SMC on this stack. You could also examine the other SMF 119 records to gain insights at link group and RNIC levels. Just wanted to let you know the jobnames are available today through the subtype 02 record.

Is there any update to the information that Jim provide above?  Should we setup a conference call to discuss in detail?  

Thanks,

Chris

I understand that you want the ability to assess SMC performance for both SMC-Rv2 and SMC-Dv2. As you have listed, you are interested in SMF 119 type 2, and SMF 119 type 38-45 to perform this task. Currently, zOS CommServer provides these records in standardized SMF output datasets. You should be able to collect and process these SMF records today. I need some direction from you to understand what you are asking us to provide:
- I believe you are asking zOS CommServer to export these records in a format that is consumable by Splunk. If this is the case, I?m not sure if you are requesting real-time data collection or is post-processing of the collected SMF data is fine.
- Or are you request additional performance information to be added to these existing records? If this is the case, could you please let us know what information you are interested in collecting.
Please let me know if I am on the right track. Also, any information that you could provide to help assess this item would be appreciated. re you using Splunk to process other IBM Z elements SMF output in this format? Thank you.