This discussion will be directed towards anyone who wishes an understanding of how a transaction acts once a user hits the enter key and which elements of the different NeuMICS products will be affected by the transaction. The flow of a transaction as it travels thru the network into a host processor downward into the specific applications which the unit of work is destined for and how the different applications may interact will be described.
Which NeuMICS files the measurements for transactions are found as well as the possibility of an overlap of measurements between different products will also be discussed. Situations that will be covered in this article are:
- A CICS transaction that does DB2 Processing
- A IMS transaction that does DB2 Processing
A Transaction that flows thru a system that consists of such applications as IMS or CICS has the following steps:
- A user would enter the data that needs to be processed and press the enter key to service the request.
- The request would flow thru the network from the terminal (LU) until it gets to the host via the Network Control Program (NCP).
- The Transaction would enter the host mainframe processor thru some access method such as VTAM.
- VTAM then passes the data onto the application (PLU) for processing. This is the area where the application monitors would be used in place of a network monitor (Processing thru a Session manager such as TPX would take place here if there was one installed).
- The application would then load the appropriate program that the transaction is requesting and the data would be processed thru the transaction, or the request being serviced.
- Once the processing is completed for the data, and the application has a response to the request, it sends it back to VTAM.
- VTAM then sends the data back to the LU with the completed answer.
- Since IMS requests a response back to determine if the data was correctly sent, VTAM sends a request to the LU asking that a positive/negative response be sent back to VTAM to let IMS know what the status of the transaction was.
How does the previous steps relate in NeuMICS Terms? In order to get the response data as the transaction travels thru the network (from when the enter key is hit until the access method (VTAM) gets control of the transaction when the transaction is inbound to a mainframe, and when the transaction is sent outbound from the access method to the LU (terminal)), the NeuMICS SNA Analyzer product must be installed along with at least one of the Network Monitors that the Analyzer supports.
The following is a list of the NeuMICS SNA files that contains response type information:
NetSpy Terminal File (SNTNSS)
NPM User Activity File (SNTPSU)
NCP Network Accounting (SNTNAC)
NLDM Session Accounting (NVSNSA)
NLDM Session Connectivity (NVSNSC)
NLDM Route (NVSRTE)
NLDM Response Time (NVSRTM)
These files will provide response time statistics all the way down to the terminal (LU) level. There is insufficient data to generate statistics by transaction name or user id however. To get this information requires the use of monitors that run in the PLU (application) that service the requests of the transactions. The monitors that run in the applications will report the statistics for the events for host time only. The following is a list of NeuMICS products and the files within those products that will supply response time statistics down to the userid, or transaction name level:
- NeuMICS CICS Analyzer - CICS User Activity File (CICCSU)
- NeuMICS IMS Analyzer - IMS User Activity File (IMSISU)
- NeuMICS IDMS Analyzer - IDMS User Activity File (IDMISU)
- NeuMICS TSO Analyzer - TSO User Activity File (TSOTSU)
If the application were using DB2 as the data manager, additional statistics would be available in the NeuMICS DB2 Analyzer, DB2 User Activity File (DB2DSU).
How does one combine the information from these sources together to get a complete picture of a transaction? The following is a list of items that are required:
- There has to be common identifier type elements that are kept on each of the files to identify a transaction uniquely
- The data from the DETAIL timespan for each of the files being used must be available.
- A time period where there is a low volume of traffic for the transaction being measured is preferred but not required.
For example, take a site that has IMS, DB2, and NetSpy as the network session monitor. The statistics for a IMS transaction that accessed DB2 on this configuration would be in the IMSISU, DB2DSU, and SNTNSS files. It would be difficult to do a one for one match for all three files. The Start timestamp for the files will be different since each of the monitors would recognize the transaction at different points in the life of the transaction.
The key elements for the files would be as follows:
Logical Terminal ID (LTERM or LU)
Transaction Name PSBNAME, or Userid
The Application and Terminal ID from the Network could be matched with the Terminal ID that IMS picks up. The corresponding transaction name, PSBNAME, or Userid from the IMS record would be matched with DB2 depending on what DB2 was told to record. The following would be the NeuMICS elements involved from the detail timespan:
SNTNSS - PLU, SLU, ENDTS
IMSISU - LTERM, PSBNAME, TRANSACT, RACFUSID, ENDTS
DB2DSU - DB2CONN, DB2CORR, ENDTS
When measuring CPU or Response times for IMS and DB2 it must be noted that the IMS and DB2 data sources both contain the CPU/Response times in their values due to the way DB2 uses the address space of the calling application to do its work. To get around this would require that DB2 do a Class 2 Accounting Trace. This will allow for the time spent only in DB2 to be recorded in the DB2 trace records.
To combine the measurements for a CICS transaction would be essentially the same as a IMS transaction. The problem with merging the data with a CICS transaction is that it is difficult to match a CICS transaction record with its DB2 counterpart. It is dependant upon what is specified in the Resource Control Table in CICS for what shows up in the DB2 Correlation identifier and Authorization ID's. Another difference is that the CPU time that is picked up by the CICS and DB2 monitors does not overlap. (DB2 currently cannot determine which transaction used it's resources).
The above scenarios will give a accurate picture of what is happening in the lifespan of a transaction. It should be noted however that the CPU time measured in the host processors will not equal the host transaction response time that the network monitors measure. This is due to differences in the point in time of the transactions life cycle that the host monitor recognizes it.
Is it practical to do this type of monitoring on a constant basis, probably not! This type of monitoring is good to validate the response/CPU numbers on a periodic basis so that the credibility of the summary statistics is maintained. It can also be used in special circumstances when there are performance problems or other questions regarding specific transactions.