Large volume of SMF 255 records written by Sysview
Article ID: 192844
Updated On:
Products
Issue/Introduction
A large volume of SMF type 255 records was being written by Sysview. We then took dump of Sysview and restart it, but the issue did not stop. We then suspect a CICS region that kept writing CICSLOGR in loop state, and the issue stopped after we canceled the CICS region. We want to know if there is any command in Sysview that we can use to identify who are writing large volume of SMF type 255 records when the problem occurs.
Environment
Release : 16.0
Component : SYSVIEW
Resolution
I think the terminology that is being used is very misleading. The "flood" of SMF records being created by SYSVIEW appear to be the CICS transaction detail records. SMF 255 subtype 27. A transaction detail record is created each time a CICS transaction ends. SYSVIEW does not create additional transaction records. The number of records is driven by the number of transactions executed.
When a transaction is created, there are multiple destinations for the record including SYSVIEW log streams and SMF.
SYSVIEW configuration options are currently set to write transaction records to SMF. I am assuming that this is the desired outcome. It is not the default. There is nothing wrong with writing SYSVIEW transaction records to SMF as along as they will be used and are expected.
The email showing several transactions XXXX running in CICS jobname CICSJOB were ALL started from a single transaction XSMQ task number 247 in region CICS_region.
From the information provided, I cannot fully understand the program logic, but transaction YYYY 247 in region CICS_region is making requests that start the XXXX transaction in region CICSJOB. If this a form of MQ function shipping?
In any case, it appears that the XXXX transaction in CICSJOB is abending. Whether transaction XXXX abends or not, it is a transaction that will end and SYSVIEW will create a transaction detail record for each.
As a note, if CICS SMF 110,1 records are active, CICS will be creating the same number of SMF records as SYSVIEW.
They will match.
Some additional things could be happening that could produce more SMF records.
If transaction end threshold processing is active and threshold exception definitions exist, then additional exception record could be getting created. Multiple exception records could be created for each transaction. Since the transaction abends, an ABEND exception record could be created.
AN ABENDS threshold definition exists out of the box. If more thresholds exist, additional records could and would get created if matching occurs. The writting of SMF records can be controlled in the threshold definition itself. Each threshold has a SMF| NOSMF attribute. This can be seen on the CTHRESH command display.
Each CICS region connects to the SYSVIEW logger. The logger ultimately controls whether the records get written to SMF. The options are specified in the parmlib member CICSLOGR.
LOG-EXCEPTIONS-SMF NO
LOG-SYSTEM-DATA-SMF NO
LOG-TRANSACTION-SUMMARY-SMF NO
LOG-TRANSACTIONS-SMF NO
The command CICSLOGR can be used to see current settings for the logger as well as the number of records processed. These are all items and reasons that SYSVIEW will create and write an SMF record for the transactions that are executed. CICS is generating the work. SYSVIEW is responding accordingly as it should. The CICS transactions may be behaving poorly causing additional transactions to be executed and therefore additional SMF records including additional exceptions records. You as a user are in full control of the amount data that SYSVIEW generates and the destination where the data is logged or written. The current settings should be examined to determine if they are set as desired. If not, make changes. I believe the reasons for the abending transactions should also be examined. They are causing addition work on the system.
Feedback
