RFC 2562
Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)
Request for Comments 2562 ✨ (TN3270E-RT-MIB)
Network Working Group 💖 Authors: K. White and R. Moore, both from IBM Corp. 🎀 Category: Standards Track 🦋 Date: April 1999 🌸
The title is Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) 👑. The header doesn't list anything this document obsoletes or updates, so there's nothing to chase there. Okay, let's get into it! 💅
Status of this Memo 📜
Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔥. And distribution of this memo is unlimited, so share away! 🌈
Copyright Notice ©
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract 🦋
This memo defines the protocol and the Management Information Base (MIB) for doing response time data collection on TN3270 and TN3270E sessions by a TN3270E server 💜. The data the server collects is structured to support both validation of service level agreements and performance monitoring of TN3270 and TN3270E sessions, which is iconic 👑. This MIB has the TN3270E-MIB, reference [20], as a prerequisite 🧚.
TN3270E, defined by RFC 2355 [19], is the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices ✨. If you want a sample of what TN3270 practices are, look at RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] 🎀.
Table of Contents 🗂️
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 The SNMP Network Management Framework . . . . . . . . . . 2
3.0 Response Time Collection Methodology . . . . . . . . . . . 3
3.1 General Response Time Collection . . . . . . . . . . . . . 3
3.2 TN3270E Server Response Time Collection . . . . . . . . . 5
3.3 Correlating TN3270E Server and Host Response Times . . . . 10
3.4 Timestamp Calculation . . . . . . . . . . . . . . . . . . 11
3.4.1 DR Usage . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2 TIMING-MARK Usage . . . . . . . . . . . . . . . . . . 13
3.5 Performance Data Modelling . . . . . . . . . . . . . . . . 15
3.5.1 Averaging Response Times . . . . . . . . . . . . . . . 15
3.5.2 Response Time Buckets . . . . . . . . . . . . . . . . 18
4.0 Structure of the MIB . . . . . . . . . . . . . . . . . . . 19
4.1 tn3270eRtCollCtlTable . . . . . . . . . . . . . . . . . . 19
4.2 tn3270eRtDataTable . . . . . . . . . . . . . . . . . . . . 23
4.3 Notifications . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Advisory Spin Lock Usage . . . . . . . . . . . . . . . . . 26
5.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . 26
6.0 Security Considerations . . . . . . . . . . . . . . . . . 45
7.0 Intellectual Property . . . . . . . . . . . . . . . . . . 45
8.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 46
9.0 References . . . . . . . . . . . . . . . . . . . . . . . . 46
10.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . 48
11.0 Full Copyright Statement . . . . . . . . . . . . . . . . 491.0 Introduction 🌸
Bestie, this document comes from the TN3270E Working Group 🫶. It defines a protocol and a MIB module so a TN3270E server can collect and keep track of response time data for both TN3270 and TN3270E clients 💅. Here's what you need to build this MIB:
- TN3270E-MIB, Base Definitions of Managed Objects for TN3270E Using SMIv2 [20]
- TN3270E RFCs
- Telnet Timing Mark Option RFC [17]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, reference [23] 🔥. Those are the rules-of-the-game words, so read them carefully, periodt 💀.
2.0 The SNMP Network Management Framework 🧚
The SNMP Management Framework has five major components 👑:
- An overall architecture, described in RFC 2271 [1].
- Mechanisms for describing and naming objects and events for management purposes. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set is described in RFC 1905 [13].
- A set of fundamental applications described in RFC 2273 [14], plus the view-based access control mechanism described in RFC 2275 [15].
Managed objects are accessed via a virtual information store, called the Management Information Base or MIB 🦋. Objects in the MIB are defined using the mechanisms defined in the SMI ✨.
This memo specifies a MIB module that is compliant to SMIv2 💖. A MIB conforming to SMIv1 can be produced through the appropriate translations. The translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64) 🙈. Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during translation. However, that loss of machine-readable information is not considered to change the semantics of the MIB 🌈.
3.0 Response Time Collection Methodology 🎀
This section explains the methodology and approach the MIB in this memo uses for response time data collection by a TN3270E server 💜.
3.1 General Response Time Collection ⏱️
Two primary methods exist for measuring response times in SNA networks 🔥:
- The Systems Network Architecture Management Services (SNA/MS) Response Time Monitoring (RTM) function.
- Timestamping using definite response flows.
This memo uses definite responses to timestamp the flows between a client and its TN3270E server, not the RTM method 🦋. Extensions to the SNA/MS RTM flow were considered, but this approach was deemed unsuitable, since not all TN3270E server implementations have access to their underlying SNA stacks 😭. The RTM ideas of keeping response time buckets for service level agreements and of interval-based response time collection for performance monitoring are preserved in the MIB module defined here ✨.
So, as mentioned, this memo focuses on using definite responses to timestamp the flows between a client and its TN3270E server to generate performance data 💅. Using a definite response flow requires that the client supports TN3270E with the RESPONSES function negotiated 🫶. The TN3270 TIMING-MARK option can be used instead of definite response for TN3270 clients, or for TN3270E clients that don't support RESPONSES 🧚. This document first defines the protocol and methods for generating performance data using definite responses, then describes how TIMING-MARK can be used instead 🌸.
In an SNA network, a transaction between a client Logical Unit (LU) and a target host usually looks like this 👑:
------------------------------------------------
| |
| Client LU Target SNA Host |
| |
| Timestamps |
| request A |
| -----------------------------------------> |
| reply(DR) B | |
| <---------------------------------------< |
| | +/-RSP C |
| >---------------------------------------> |
| |
| DR: Definite Response requested |
| +/-RSP: Definite Response |
| |
------------------------------------------------This transaction is a simple one, and it's only here to show how timestamping at a target SNA host can generate response times 🍓. An IBM redbook [12] gives a more detailed description of response time collection for this type of transaction 📚. Note that for approximating network transit time, it doesn't matter if the response is positive or negative 🙈. Typically two response time values get calculated 💖:
Host Transit Time: Timestamp B - Timestamp ANetwork Transit Time: Timestamp C - Timestamp B
Network transit time is an approximation for how long a transaction needs to flow across a network, because the response flow stands in for the request flow at the start of the transaction ✨. Network transit time, timestamp C minus timestamp B, is the amount of time the definite response request and its response took 🔥. Host time, timestamp B minus timestamp A, is the actual time the host needed to process the transaction 👑. Experience has shown that using the response flow to approximate network transit times is useful, and it correlates well with actual network transit times 🌈.
A client SHOULD respond to a definite response request when it finishes processing the transaction 🫶. This matters because it makes the total response time more accurate 💅. Clients that respond immediately to a definite response request will be attributed with lower total response times than actually occurred 😭.
The TN3270E-RT-MIB describes a collection method that is NOT appropriate for printer sessions (LU Type 1 or LU Type 3), so performance data collection for printer sessions is excluded from this MIB. This exclusion is not a problem, since printer sessions aren't the most important ones for response time monitoring, and they were historically excluded from SNA/MS RTM collection 🖨️. To check whether a client session is ineligible for response time collection for this reason, look at thetn3270eTcpConnResourceTypeobject in atn3270eTcpConnEntry(in the TN3270E-MIB) 🙈.
(More parts to come, bestie! 🦋)
3.2 TN3270E Server Response Time Collection ✨
okay bestie, now we're going into the TN3270E server side 🌸 A TN3270E server sits in the middle and connects a Telnet client doing 3270 emulation to a target SNA host 🫶. That's two networks: the client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client side is typically TCP/IP, but it doesn't have to be 💅. Since IP is by far the most common choice for these, this doc just calls the client-side network the "IP network" to keep things easy to follow 🦋
A TN3270E server can use SNA definite responses and the TN3270 Enhancement (RFC 2355 [19]) RESPONSES function to calculate response times for a transaction. It does this by timestamping when a client request arrives at the server, when the reply arrives from the target host, and when the response acknowledging that reply arrives from the client ⏱️✨
Section 3.4, Timestamp Calculation, gets into the specifics of exactly when, in the sequence of flows between a TN3270E client and its target SNA host, a TN3270E server takes the required timestamps 🧚 It also covers how a TN3270 TIMING-MARK request/response flow can be used instead of DR for approximating IP network transit times, which is a very cute workaround 🎀
Here's the figure that adds a TN3270E server between the client (a TN3270E client in this case) and the target SNA host 👑
------------------------------------------------
| |
| Client TN3270E Target |
| Server SNA Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D |
| ------------------------------------------> |
| reply(DR) E | |
| <----------------------------------------< |
| | +/-RSP F |
| >-------------------- - - - - - - - - - > |
| |
------------------------------------------------So the TN3270E server can save timestamp D when it receives a client request, save timestamp E when the target SNA host replies, and save timestamp F when the client responds to the definite response request that came along with the reply 💖 Here's the fun part: it doesn't matter whether the target SNA host asked for a definite response on its reply. If it didn't, the TN3270E server makes the request on its own, so it can still produce timestamp F 🙈 In that case, the TN3270E server does not forward the response to the target SNA host, as the dotted line in the figure shows.
Heads up: a transaction where the target SNA host returns anUNBINDin response to a client's request, and the TN3270E server forwards thatUNBINDto the client, is a special case. It is NOT included in any response time calculations 💀
Now, to generate timestamp F, a TN3270E server MUST insure that the transaction specifies DR, and that the TN3270E RESPONSES function has been negotiated between itself and the client 🔥 Negotiation of the RESPONSES function happens during the client's TN3270E session initialization. The TN3270E servers the authors know of do request the RESPONSES function during client session initialization 🌈 As for clients, TN3270E clients either automatically support the RESPONSES function, or can be configured during startup to support it ✨
Using timestamps D, E, and F, a TN3270E server can calculate these response times:
- Total Response time:
Timestamp F - Timestamp D - IP Network Transit Time:
Timestamp F - Timestamp E
Just like the SNA case we covered above, these response times are also approximations, because the final +/- RSP from the client is standing in for the request from the client that started the transaction 🦋
The MIB gives you an object, tn3270eRtCollCtlType, that controls several aspects of response time data collection 💅 One of the options when setting up a response time collection policy is to eliminate the IP-network component altogether. People might do this because they decide the additional IP network traffic isn't desirable, or because the IP-network component of the overall response times isn't significant 🙄
Excluding the IP-network component also changes how response time data gets aggregated 👀 Some clients simply won't support any of the functions the server needs to calculate the IP-network component. For those clients, the most the server can calculate is the SNA-network component of their overall response times. The server records this SNA-network component as the TOTAL response time for each of those clients' transactions.
Now, if a response time collection is aggregating data from a bunch of clients, some of which can include the IP-network component in their totals and some of which can't, the server aggregates things differently depending on whether the collection is defined to include or exclude the IP-network component:
- If the IP-network component is included, then transactions for the clients that don't support calculating the IP-network component of their response times are excluded from the aggregation altogether 🚫
- If the IP-network component is excluded, then total response times for ALL clients include only the SNA-network component, even though the server could have included an IP-network component in the overall response times for some of these clients. The server does this by setting timestamp F, which marks the end of a transaction's total response time, equal to timestamp E, the end of the transaction's SNA-network component 🧠
Here's the principle, and it's the key thing to remember: all the transactions contributing their response times to an aggregated value MUST make the same contribution 💖 If the aggregation specifies that an IP-network component MUST be included in the aggregation's response times, then transactions for which an IP-network component cannot be calculated aren't included at all. If the aggregation specifies that an IP-network component is not to be included, then only the SNA-network component is used, even for those transactions where an IP-network component could have been calculated 🌸
There's one more twist 🌀 The MIB lets a management application enable or disable dynamic definite responses for a response time collection. Again, the point of this option is to give the network operator control over how much traffic gets introduced into the IP network for response time data collection 🫶 A DYNAMIC definite response is one that the TN3270E server itself adds to a reply, in a transaction where the SNA application at the target SNA host did not specify DR in its reply. When the +/-RSP comes back from the client, the server uses it to calculate timestamp F, but then it does NOT forward the response on to the SNA application, since the application isn't expecting a response to its reply 🙈
The dynamic definite responses option relates to the option of including or excluding the IP-network component (which we just covered) like this:
- If the IP-network component is excluded, then there's no reason to enable dynamic definite responses. The server always sets timestamp F equal to timestamp E, so the additional IP-network traffic from a dynamic definite response would serve no purpose 🙅♀️
- If the IP-network component is included, then enabling dynamic definite responses causes MORE transactions to be included in the aggregated response time values:
- For clients that do not support sending of responses, timestamp F can never be calculated, so their transactions are never included in the aggregate 💀
- For clients that support sending of responses, timestamp F will always be calculated for transactions where the host SNA application specifies DR in its reply, so these transactions will always be included in the aggregate ✨
- For clients that support sending of responses, having dynamic definite responses enabled for a collection results in the inclusion of additional transactions in the aggregate: specifically, those where the host SNA application did not specify DR in its reply 🌈
A TN3270E server also has the option of substituting TIMING-MARK processing for definite responses when it calculates the IP-network component of a transaction's response time 🎀 Once again, there's no reason for the server to do this if the collection has been set up to exclude the IP-network component altogether when computing response times.
The MIB keeps counts and averages for total response times (F - D) and their IP-network components (F - E) 📊 A management application can easily calculate an average SNA-network component (E - D) from these two values. And yes, this SNA-network component includes the SNA node processing time at both the TN3270E server and at the target application 🧚
Now for the two flavours of server. A host TN3270E server is an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA) System Services Control Point (SSCP) for the dependent Secondary Logical Units (SLUs) that the server makes available to its clients for connecting into an SNA network 👑 A gateway TN3270E server, on the other hand, resides on an SNA node other than an SSCP. That could be an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR) 💅 Host and gateway TN3270E server implementations typically differ a lot in their internal implementation and System Definition (SYSDEF) requirements 🦋
If a host TN3270E server is in the same SNA host as the target application, then the SNA-network component of a transaction's response time will be approximately equal to the host transit time (B - A) described previously 🌸 A host TN3270E server implementation can, however, typically support establishing sessions to target applications in SNA hosts remote from itself 🫶 In that case, the SNA-network component of the response time equals the actual SNA-network transit time plus two host transit times 🔥
3.3. Correlating TN3270E Server and Host Response Times ✨
okay so, it's totally possible that a TN3270E server is collecting response time data while a management app is watching the SNA sessions at a host 👀 like, a management app could be monitoring a secondary logical unit (SLU) while it's pulling data from a TN3270E server. the vibe is very "two dashboards at once" 💅 here's the picture:
------------------------------------------------
| |
| Client TN3270E Target |
| Server SNA Host |
| Timestamps (PLU) |
| (SLU) Timestamps|
| <---IP Network-------><---SNA Network---> |
| |
| request D A |
| ------------------------------------------> |
| reply(DR) E B | |
| <----------------------------------------< |
| | +/-RSP F C |
| >--------------------------------------> |
| |
------------------------------------------------so these are the response times you can get out of it 🩷
- Target SNA host transit time:
Timestamp B - Timestamp A - Target SNA host network transit time:
Timestamp C - Timestamp B - TN3270E server total response time:
Timestamp F - Timestamp D - TN3270E server IP-network component:
Timestamp F - Timestamp E
the TN3270E server's main contribution here is its estimate of the IP-network part of the overall response time 🌸 and you can subtract that from the total network transit time (which you can grab at an SSCP that's monitoring SNA traffic to and from the SLU) to find out the actual SNA vs. IP network transit times. the math ate, no crumbs 🍓
now, the MIB in this memo doesn't directly handle correlating its data with response times from directly monitoring SNA resources 🙅♀️ its whole focus is response time collection from the TN3270E server's point of view. BUT, together with the TN3270E-MIB [10], it's built to give you everything you need to line up the server's numbers with the ones from watching SNA resources directly. iconic teamwork 🤝✨
if a management app wants to link SNA resource usage back to Telnet clients, it can check either the tn3270eResMapTable or the tn3270eTcpConnTable to figure out the resource-to-client address mappings. both of those are defined by the TN3270E-MIB [10]. another useful one is the tn3270eSnaMapTable, which maps SLU names as the SSCP (VTAM) knows them to their local names at the TN3270E server 🗺️ and heads up: the tn3270eClientGroupTable, the tn3270eResPoolTable, and the tn3270eClientResMapTable from the TN3270E-MIB are NOT for correlation 🚫 their mappings can overlap and might not be one-to-one, so they're not reliable for this. not me reading that and going "nope" 💀
3.4. Timestamp Calculation 🦋
this section gets into the details of when each timestamp gets taken as traffic moves between a TN3270E client and its target SNA host through a TN3270E server 🧚 it also explains how the TN3270 TIMING-MARK request/response flow can stand in for DR when you're approximating IP network transit times. main character energy for sure 👑
3.4.1. DR Usage 💜
let's look at this flow:
----------------------------------------------------------
| |
| Client TN3270E Target SNA |
| Server Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D (BB,CD,OIC,ER) |
| -------------------------------------------> |
| reply(DR) (FIC,ER,EB) | |
| <-----------------------------------------< |
| reply (MIC,ER) |
| <-----------------------------------------< |
| reply (MIC,ER) |
| <-----------------------------------------< |
| reply E (LIC,DR) |
| <-----------------------------------------< |
| | +/-RSP F |
| >----------------------------------------> |
| |
| BB : Begin Bracket ER : Response by exception |
| EB : End Bracket DR : Definite Response Requested |
| CD : Change Direction FIC : First in chain |
| OIC: Only in chain MIC: Middle in chain |
| LIC: Last in chain |
----------------------------------------------------------so timestamp D gets taken at the TN3270E server once it's received data from a client that's headed to the target SNA host, AND the SNA session's direction lets the server forward it right away (either the data is heading inbound toward the SNA host, or the session is between brackets) 💖 this is most likely when the server spots the end of record indicator in the TCP data it got from the client ✨
the target SNA app sends back its reply in one or more SNA Request Units (RUs). in this example there are four RUs in the reply 🫶 the first one is marked first in chain (FIC), the next two are middle in chain (MIC), and the last one is last in chain (LIC). if the SNA host sends a multi-RU chain, the server doesn't know whether DR was requested until it gets the last RU 😭 the server's ONLY shot at requesting DR from the client is when it forwards the FIC RU, because that's the only time the TN3270E header is included. since a server might forward the FIC RU to the client before the LIC RU even shows up from the SNA host, some servers just specify DR on every FIC RU 🔥
if the server put DR on the TN3270E request for the FIC RU in a chain, it takes timestamp E when it forwards the LIC RU to the client 🎀 timestamp E is what's used to calculate the IP-network time for the transaction, so the server SHOULD take timestamp E as close as possible to its "Telnet edge" 🌈 then it takes timestamp F when it receives the RESPONSES response from the client 💅
heads up: not every transaction ends in a reply. sometimes the target app doesn't send back data because it needs more from the client first. in that case, the app can just send a change of direction indicator back to the TN3270E server 🙈 at that point the server has to send something to the client (usually a Write operation with a WCC) to unlock the keyboard. if the server asks for DR on that request to the client, which gets triggered when it receives the change of direction indicator from the SNA app, then timestamps E and F can be taken and the usual response times can be calculated. and when the client sends in the extra data and gets a text response from the SNA app, the server counts that as a separate transaction from the change of direction one 🧚♀️🫶
3.4.2 TIMING-MARK Usage ✨
okay so this one is giving "smart shortcut" energy 💅 A TN3270E server can use the TIMING-MARK flow to estimate IP network transit times 🦋 That means it can collect performance data for plain TN3270 clients, and also for TN3270E clients that don't support the RESPONSES function 🎀 For this to work, a client can't have the NOP option enabled, because the server needs responses to its TIMING-MARK requests 🫶 So the IP network transit time approximation is basically how long the TN3270 server takes to get a response to a TIMING-MARK request back from the client 🌸
Here's the picture of how the flow goes. After a LIC RU comes in, the TN3270E server sends a TIMING-MARK request to the client to estimate IP network transit time 💖
---------------------------------------------------
| |
| Client TN3270E Target |
| Server Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D (BB,CD,OIC,ER) |
| -------------------------------------------> |
| reply (FIC,ER,EB) | |
| <-----------------------------------------< |
| reply (MIC,ER) |
| <-----------------------------------------< |
| reply (MIC,ER) |
| <-----------------------------------------< |
| reply E (LIC,ER) |
| <-----------------------------------------< |
| TIMING-MARK Rqst E' |
| <--------------------- |
| | TIMING-MARK Rsp F' |
| >-------------------> |
| |
---------------------------------------------------Then the response times get calculated like this 🧮🔥
- TN3270E server total response time: (Timestamp E - Timestamp D) + (Timestamp F' - Timestamp E')
- TN3270E server IP network time: Timestamp F' - Timestamp E'
Now, if the server is already doing TIMING-MARK stuff for its own reasons (totally separate from the response time monitoring we just talked about 🙈), it probably has a TIMING-MARK interval that decides when to check client sessions for sending a TIMING-MARK request 💜 This interval is usually one global value for the whole TN3270E server, and it shows up in the TN3270E-MIB as tn3270eSrvrConfTmNopInterval ✨ A TIMING-MARK request only goes out if, when the server checks, the client session has had no activity for a different fixed amount of time 🌈 That one is tn3270eSrvrConfTmNopInactTime in the TN3270E-MIB 🍓
Big servers with tons of client sessions should spread their TIMING-MARK requests across the activity interval 🚨 Don't send them all in one giant burst, or the network could get flooded with TIMING-MARK requests 😭 When a server uses TIMING-MARKs for these response time approximations, it kinda spreads them out naturally, since the requests get triggered by traffic arriving from the SNA host 🦋
Now the big rules 👑 A TN3270E server MUST integrate its normal TIMING-MARK processing with its use of TIMING-MARKs for computing response times. Specifically, it MUST NOT send a second TIMING-MARK request to a client while it's still waiting for the first one to come back, because the TIMING-MARK protocol itself already rules that out 🙅♀️ If a TIMING-MARK flow just happened for a client shortly before the LIC RU arrived, the server MAY reuse that interval as its IP network transit time approximation (that's the F' - E' value) when it calculates the transaction's total response time 💅 That way it doesn't have to send a second TIMING-MARK request so soon after the first one ✨
No matter when the server sends its TIMING-MARK request, how accurate its total response time calculation is depends on exactly when the client responds to that TIMING-MARK request 💀
3.5 Performance Data Modelling 🎀
okay so here's the tea: this part explains how the TN3270E-RT-MIB models and controls the capture of two types of response time data, which are average response times and response time buckets 🍓 Two subsections dig into each one 🫶
3.5.1 Averaging Response Times 💖
Average response times have two different jobs in the MIB 🔥
- They're available for management applications to retrieve 🦋
- They act as triggers for emitting notifications 🚨
Sliding-window averages get used instead of straight interval-based averages, because they're often more meaningful and cause less notification thrashing 🌸 If it's ever needed, sliding-window average calculation can be turned off by setting the sample period multiplier, tn3270eRtCollCtlSPMult, to 1, and setting the sample period, tn3270eRtCollCtlSPeriod, to the collection interval you want 💜
To calculate sliding-window averages, a TN3270E server MUST:
- Pick a fixed, relatively short sample period SPeriod ⏱️ The default SPeriod in the MIB is 20 seconds ✨
- Pick an averaging period multiplier SPMult 💅 The actual collection interval is SPMult times SPeriod. The default SPMult in the MIB is 30, which gives a default collection interval of 10 minutes 🎀 Note that the collection interval (SPMult*SPeriod) is always a multiple of the sample period 🧚
Clearly, SPMult*SPeriod should NOT be thought of as literally the averaging period 🙈 The average will include contributions older than that time, and it doesn't weight all contributions since that time equally 🌈 Honestly, it gives a smoother result than a traditional sliding average, like the ones used in finance 🦋 More subtly, the effective averaging period is best thought of as 2*SPMult*SPeriod 🔥 Here's why: think about how long one transaction's contribution to the result sticks around. With a traditional sliding average, it lasts exactly the averaging period. With the aging mechanism described here, it has a half-life of SPMult*SPeriod 💅
- Keep these counters to track activity in the current sample period 📊 These are internal counters, so a management application can't see them through the MIB 🙅♀️
- T (number of transactions in the period) 🎀
- TotalRts (sum of the total response times for all transactions in the period) 💖
- TotalIpRts (sum of the IP network transit times for all transactions in the period; note that if IP network transit times are being excluded from the response time collection, this value will always be 0) 🌸
- Also keep sliding counters, starting at zero, for each thing being counted 🧁
- AvgCountTrans (sliding count of transactions) ✨
- TotalRtsSliding (sliding count of total response times) 💜
- TotalIpRtsSliding (sliding count of IP network transit times) 🦋
- At the end of each sample period, update the sliding interval counters using these floating-point calculations 🧮
AvgCountTrans = AvgCountTrans + T
- (AvgCountTrans / SPMult)
TotalRtsSliding = TotalRtsSliding + TotalRts
- (TotalRtsSliding / SPMult)
TotalIpRtsSliding = TotalIpRtsSliding + TotalIpRts
- (TotalIpRtsSliding / SPMult)Then reset T, TotalRts, and TotalIpRts to zero for the next sample period 🔄
- At the end of a collection interval, update these MIB objects as shown below. The floating-point numbers get rounded, not truncated 🍓
tn3270eRtDataAvgCountTrans = AvgCountTrans
tn3270eRtDataAvgRt = TotalRtsSliding / AvgCountTrans
tn3270eRtDataAvgIpRt = TotalIpRtsSliding / AvgCountTransAs you'd expect, if IP network transit times are being excluded from response time collection, then tn3270eRtDataAvgIpRt will always return 0 🙃
The sliding transaction counter AvgCountTrans is NOT used for updating the MIB object tn3270eRtDataCountTrans 🙅♀️ That object is an ordinary SMI Counter32, which keeps a running total of transactions since its last discontinuity event 💅 The sliding counters are only used for calculating averages ✨
Two mechanisms in the MIB stop an excessive number of notifications related to average response times 🛑 First, there are high and low thresholds for average response times. A tn3270eRtExceeded notification is generated the first time a statistically significant average response time is found to have exceeded the high threshold 🚨 (The test for statistical significance is described below 👀) After that, no other tn3270eRtExceeded notifications get generated until an average response time falls below the low threshold 🌙
The other mechanism is the significance test for a high average response time 🧠 Intuitively, the significance of an average is directly related to how many samples go into it, so we might be tempted to use a rule like "for the purpose of generating tn3270eRtExceeded notifications, ignore average response times based on fewer than 20 transactions in the sample period." 🤔
But here's the twist 😭 With response times, the number of transactions sampled in a fixed sampling period is tied to those transactions' response times. A few transactions with long response times can guarantee there aren't many transactions in a sample, because those transactions "use up" the sampling time 💀 Yet that case of a few transactions with really poor response times should obviously be classified as a problem, not as a statistical anomaly from too small a sample 🚨
So the solution is to make the significance level for a sample depend on the average response time 🧮 A value IdleCount is specified, and it's used to qualify a sample as statistically significant ✨ To decide at a collection interval whether to generate a tn3270eRtExceeded notification, a TN3270E server uses this algorithm 💅
if AvgCountTrans * ((AvgRt/ThreshHigh - 1) ** 2) >= IdleCount
then generate the notification,Here AvgRt is the value that tn3270eRtDataAvgRt would return at the end of the interval, and the "**" notation means exponentiation 🤓
Two examples show how this works 🎀 Say IdleCount is set to 20 transactions, and the high threshold is 200 msecs per transaction. If the average observed response time is 300 msecs, then a notification only gets generated if AvgCountTrans >= 80 🙌 But if the observed response time is 500 msecs, then a notification gets generated if AvgCountTrans >= 9 🔥
There's no matching significance test for the tn3270eRtOkay notification 🌸 That one gets generated based on an average response time that falls below the low threshold, no matter how big the sample size behind that average was 🫶
3.5.2 Response Time Buckets 🪣
okay so the MIB also has these five buckets 🪣✨ for counting response times. It's giving two things: checking whether a service level agreement is being met ✅, or letting a management app spot performance problems 🔍. Each bucket just counts the transactions whose total response times land in its range.
Like everything else in a collection, the "total" response times that go into the buckets depend on whether IP network transit times are included 🌐. If they are, the buckets count total response times (F - D). If they're not, the buckets only count SNA network transit times, which is effectively E - D. That works because when a server excludes the IP-network part, it sets timestamp F equal to timestamp E 💅.
There are four bucket boundaries for each collection, which gives five buckets 🎀. The first bucket counts transactions with a total response time less than or equal to Boundary 1. The second counts those greater than Boundary 1 but less than or equal to Boundary 2, and so on. The fifth bucket has no upper limit and counts everything greater than Boundary 4 🚀.
The four boundaries default to 1 second, 2 seconds, 5 seconds, and 10 seconds, in that order 🕐. Those are the defaults in the 3174 controller's version of the SNA/MS RTM function, and they're thought to be a good fit for this MIB too 🥰.
Back in SNA/MS, the counter buckets were pretty small by today's standards, with a maximum value of 65,535 🙈. The bucket objects in this MIB are all Counter32's, so they're way roomier 💜.
Here's the bucket picture 📊:
----------------------------------------------
| |
| Response Time Boundaries |
| | | | | | | |
| | | | | | | |
| | | | | | no |
| 0 B-1 B-2 B-3 B-4 bound|
| | | | | | | |
| |Bucket1|Bucket2|Bucket3|Bucket4|Bucket5| |
| ----------------------------------------- |
| |
----------------------------------------------4.0 Structure of the MIB 🧩
okay now the structure! The TN3270E-RT-MIB has these components:
tn3270eRtCollCtlTabletn3270eRtDataTable- Notifications
- Advisory Spin Lock Usage
4.1 tn3270eRtCollCtlTable 🎀
The tn3270eRtCollCtlTable is indexed by tn3270eSrvrConfIndex and tn3270eClientGroupName, which are both imported from the TN3270E-MIB 📥. tn3270eSrvrConfIndex picks out a particular TN3270E server within a host 🖥️. tn3270eClientGroupName picks out a group of IP clients whose response time data should be collected 👯♀️. The clients in that group are defined using the tn3270eClientGroupTable from the TN3270E-MIB.
A tn3270eRtCollCtlEntry holds these objects 📋:
--------------------------------------------------
1st Index | tn3270eSrvrConfIndex Unsigned32 |
2nd Index | tn3270eClientGroupName Utf8String |
| tn3270eRtCollCtlType BITS |
| tn3270eRtCollCtlSPeriod Unsigned32 |
| tn3270eRtCollCtlSPMult Unsigned32 |
| tn3270eRtCollCtlThreshHigh Unsigned32 |
| tn3270eRtCollCtlThreshLow Unsigned32 |
| tn3270eRtCollCtlIdleCount Unsigned32 |
| tn3270eRtCollCtlBucketBndry1 Unsigned32 |
| tn3270eRtCollCtlBucketBndry2 Unsigned32 |
| tn3270eRtCollCtlBucketBndry3 Unsigned32 |
| tn3270eRtCollCtlBucketBndry4 Unsigned32 |
| tn3270eRtCollCtlRowStatus RowStatus |
--------------------------------------------------The tn3270eRtCollCtlType object is the control knob 🎛️. It decides which types of response time collection happen, how granular the collection is, whether dynamic definite responses are initiated, and whether notifications get generated. It's a BITS object, so you can pick multiple options at once 🍓.
Here's what each BIT in tn3270eRtCollCtlType means 👇:
aggregate(0): if this bit is set to 1, data is aggregated for the whole client group. You only get one row for the collection in thetn3270eRtDataTable. The first two indexes,tn3270eSrvrConfIndexandtn3270eClientGroupName, match the indexes of the correspondingtn3270eRtCollCtlEntry. The third and fourth indexes of an aggregatedtn3270eRtDataEntryareunknown(0)(tn3270eRtDataClientAddrType) and a zero-length octet string (tn3270eRtDataClientAddress). The fifth index,tn3270eRtDataClientPort, is 0.
If this bit is set to 0, you get a separate entry in the tn3270eRtDataTable for each member of the client group 👯. Then tn3270eRtDataClientAddress holds the client's actual IP Address, tn3270eRtDataClientAddrType shows the address type, and tn3270eRtDataClientPort holds the port number the client is using for its TN3270/TN3270E session 🔌.
excludeIpComponent(1): if this bit is set to 1, the server SHOULD exclude the IP-network component from all the response times for this collection 🚫. If the target SNA application specifies DR in any of its replies, that DR still gets passed down to the client, and the client's response still gets forwarded to the application. But that response plays no role in the server's response time calculations 🙅♀️.
If this bit is set to 0, the server only includes transactions in the collection where it can add an (approximate) IP-network component to the total response time 🧮. That component MAY come from a "natural" DR (if the client supports the RESPONSES function), from a dynamic DR introduced by the server (if the client supports the RESPONSES function and the ddr(2) bit is set to 1), or from TIMING-MARK processing (if the client supports TIMING-MARKs) ⏱️.
If this bit is set to 1, the ddr(2) bit gets ignored, because there's no reason for the server to request extra responses from the clients in the group 🙃.
ddr(2): if this bit is set to 1, the server SHOULD, for clients in the group that support the RESPONSES function, add a DR request to the FIC reply in each transaction 📨. It then uses the client's later response to calculate an (approximate) IP-network component to include in the transaction's total response times 🧠.
If this bit is set to 0, the server does not add a DR request that it wasn't otherwise going to add to any replies from the target SNA application 🙅.
If the excludeIpComponent(1) bit is set to 1, the server ignores this bit 💀.
average(3): if this bit is set to 1, the server SHOULD calculate a sliding-window average for the collection, based on the parameters set for the group 📈.
If this bit is set to 0, no average is calculated. In that case the tn3270eRtExceeded and tn3270eRtOkay notifications aren't generated, even if the traps(5) bit is set to 1 😤.
buckets(4): if this bit is set to 1, the server SHOULD create and increment response time buckets for the collection, based on the parameters set for the group 🪣.
If this bit is set to 0, response time buckets aren't created 🚫.
traps(5): if this bit is set to 1, a TN3270E Server is enabled to generate notifications for a tn3270eCollCtlEntry 🔔.tn3270CollStartandtn3270CollEndgeneration is enabled simply bytraps(5)being set to 1.tn3270eRtExceededandtn3270eRtOkaygeneration needsaverage(3)to also be set to 1, on top of thetraps(5)requirement 🫶.
If traps(5) is set to 0, none of the notifications defined in this MIB are generated for a particular tn3270eRtCollCtlEntry 🤐.
Either the average(3) or the buckets(4) bit MUST be set to 1 for response time data collection to happen 🚨. Both bits MAY be set to 1 too 💖. If the average(3) bit is set to 1, these objects mean something and control the average calculations, plus the generation of the two notifications tied to them ✨:
tn3270eRtCollCtlSPeriodtn3270eRtCollCtlSPMulttn3270eRtCollCtlThreshHightn3270eRtCollCtlThreshLowtn3270eRtCollCtlIdleCount
Those objects are meaningless if the average(3) bit isn't set to 1 🫠.
If the buckets(4) bit is set to 1, these objects mean something and set the bucket boundaries 🪜:
tn3270eRtCollCtlBucketBndry1tn3270eRtCollCtlBucketBndry2tn3270eRtCollCtlBucketBndry3tn3270eRtCollCtlBucketBndry4
Those objects are meaningless if the buckets(4) bit isn't set to 1 🙈.
If an entry in the tn3270RtCollCtlTable has the value active(1) for its RowStatus, then an implementation SHALL NOT allow Set operations for any objects in the entry except the ones below 🔒: -tn3270eRtCollCtlThreshHigh-tn3270eRtCollCtlThreshLow-tn3270eRtCollCtlRowStatus
4.2. tn3270eRtDataTable ✨
Okay so every tn3270eRtCollCtlEntry makes either one single entry or a whole bunch of entries in the tn3270eRtDataTable 💖. Which one you get depends on whether aggregate(0) is selected in that entry's tn3270eRtCollCtlType. The data entry's contents depend on the matching control entry too. Some objects only give you meaningful values when average(3) is picked, and others only when buckets(4) is picked. If you pick both, every object is meaningful 🫶. If an object isn't supposed to be meaningful, an implementation may return any syntactically valid value to a Get, so don't panic if you see random-looking stuff 💀.
The following objects return meaningful values if and only if average(3) was selected in the corresponding tn3270eRtCollCtlEntry:
tn3270eRtDataAvgRttn3270eRtDataAvgIpRttn3270eRtDataAvgCountTranstn3270eRtDataIntTimeStamptn3270eRtDataTotalRtstn3270eRtDataTotalIpRtstn3270eRtDataCountTranstn3270eRtDataCountDrstn3270eRtDataElapsRndTrpSqtn3270eRtDataElapsIpRtSq
The first three of these give you values from the sliding-window average calculations we went over earlier 📈. The time of the most recent sample used for those is in tn3270eRtDataIntTimeStamp. The next four are regular Counter32 objects that keep counts of total response time and total transactions 🧮. The last two are sum-of-the-squares values, which let a management app do variance calculations. Very smart, very useful 🧠.
The following objects return meaningful values if and only if buckets(4) was selected in the corresponding tn3270eRtCollCtlEntry:
tn3270eRtDataBucket1Rtstn3270eRtDataBucket2Rtstn3270eRtDataBucket3Rtstn3270eRtDataBucket4Rtstn3270eRtDataBucket5Rts
Now the discontinuity object, tn3270eRtDataDiscontinuityTime. This is what a management app uses to figure out when the counters in this table may have been reset or otherwise had a discontinuity 🔄. One likely cause is the TN3270E server being stopped or restarted. This object gives you a meaningful value no matter which collection control options were selected, so it's always there for you 🎀.
Then there's tn3270eRtDataRtMethod, which tells you whether the IP Network Time was calculated using the definite response approach or the TIMING-MARK approach ⏱️.
When an entry is created in the tn3270eRtCollCtlTable with its aggregate(0) bit set to 1, an entry is automatically created in the tn3270eRtDataTable. For that entry, tn3270eRtDataClientAddress is a zero-length octet string, tn3270eRtDataClientAddrType is unknown(0), and tn3270eRtDataClientPort is 0. Aggregate queen behavior, honestly 👑.
When an entry is created in the tn3270eRtCollCtlTable with its aggregate(0) bit set to 0, a separate entry is created in the tn3270eRtDataTable for each member of the client group that currently has a session with the TN3270E server 🦋. New entries get created later for clients the TN3270E server decides are group members when they start sessions with the server. Entries also get created when clients that already have sessions get added to the group.
When an entry in the tn3270eRtCollCtlTable is deleted, all of the entries tied to it get deleted from the tn3270eRtDataTable too 🗑️. An individual client's entry in a client group gets deleted when its TCP connection terminates. Once a client's entry exists, it stays active for as long as the collection's tn3270eRtCollCtlEntry exists, even if that client gets removed from the client group 🌸.
4.3. Notifications 🔔
This MIB defines four notifications related to a tn3270eRtDataEntry. If the associated tn3270eRtCollCtlType object's traps(5) bit is set to 1, then the tn3270RtCollStart and tn3270RtCollEnd notifications get generated when the tn3270eRtDataEntry is created and deleted, respectively. If, on top of that, the same tn3270eRtCollCtlType object's average(3) bit is set to 1, then the tn3270eRtExceeded and tn3270eRtOkay notifications get generated when the conditions they report happen 🚨.
The following notifications are defined by this MIB:
tn3270eRtExceeded- This one signals that a performance problem has been detected 😬. If average(3) response time data is being collected, this notification gets generated whenever both of these are true: (1) an average response time is first found, on a collection interval boundary, to have exceeded the high thresholdtn3270eRtCollCtlThreshHighfor the client group, AND (2) the sample the average is based on is determined to have been a significant one, using the significance algorithm described earlier. It doesn't get generated again for a tn3270eRtDataEntry until an average response time falls below the low thresholdtn3270eRtCollCtlThreshLowfor the client group, for that entry.tn3270eRtOkay- This one signals that a previously reported performance problem has been resolved 🥳. If average(3) response time data is being collected, this notification gets generated whenever both of these are true: (1) atn3270eRtExceedednotification has already been generated, AND (2) an average response time is first found, on a collection interval boundary, to have dropped below the low thresholdtn3270eRtCollCtlThreshLowfor the client group. It doesn't get generated again for a tn3270eRtDataEntry until an average response time goes above the high thresholdtn3270eRtCollCtlThreshHighfor the client group, for that entry.
Put together, those two notifications keep you from getting an excessive number of traps when an average response time bounces around its high threshold 🎢. Smart design, no notes.
tn3270eRtCollStart- This gets generated whenever data collection begins for a client group, or when a new tn3270eRtDataEntry becomes active 🌱. Its main job is to tell a management app that a new client TCP session has been established, and to give the IP-to-resource mapping for that session. This notification isn't critical when average(3) data collection isn't happening for the client group.tn3270eRtCollEnd- This gets generated whenever a data collection ends 🌙. For an aggregate collection, that's when the corresponding tn3270eRtCollCtlEntry gets deleted. For an individual collection, it happens either when the tn3270eRtCollCtlEntry gets deleted or when the client's TCP connection terminates. The point is to let a management app wrap up a monitoring function it was running, by handing back the final values for the collection's data objects 🏁.
4.4. Advisory Spin Lock Usage 🔒
Within the TN3270E-RT-MIB, tn3270eRtSpinLock is defined as an advisory lock. It lets cooperating TN3270E-RT-MIB applications coordinate how they use the tn3270eRtCollCtlTable 🤝. When creating a new entry or changing an existing one in the tn3270eRtCollCtlTable, an application SHOULD use tn3270eRtSpinLock to serialize its changes or additions. Since it's advisory, management applications' use of it SHALL NOT be enforced by agents. Agents MUST, however, implement the tn3270eRtSpinLock object 💅.
5.0. Definitions 📜
TN3270E-RT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Unsigned32, Gauge32
FROM SNMPv2-SMI
RowStatus, DateAndTime, TimeStamp, TestAndIncr
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
tn3270eSrvrConfIndex, tn3270eClientGroupName,
tn3270eResMapElementType
FROM TN3270E-MIB
IANATn3270eAddrType, IANATn3270eAddress
FROM IANATn3270eTC-MIB
snanauMIB
FROM SNA-NAU-MIB;
tn3270eRtMIB MODULE-IDENTITY
LAST-UPDATED "9807270000Z" -- July 27, 1998
ORGANIZATION "TN3270E Working Group"
CONTACT-INFO
"Kenneth White (kennethw@vnet.ibm.com)
IBM Corp. - Dept. BRQA/Bldg. 501/G114
P.O. Box 12195
3039 Cornwallis
RTP, NC 27709-2195
Robert Moore (remoore@us.ibm.com)
IBM Corp. - Dept. BRQA/Bldg. 501/G114
P.O. Box 12195
3039 Cornwallis
RTP, NC 27709-2195
(919) 254-4436"
DESCRIPTION
"This module defines a portion of the management
information base (MIB) that enables monitoring of
TN3270 and TN3270E clients' response times by a
TN3270E server."
REVISION "9807270000Z" -- July 27, 1998
DESCRIPTION
"RFC nnnn (Proposed Standard)" -- RFC Editor to fill in
::= { snanauMIB 9 }
-- snanauMIB ::= { mib-2 34 }
-- Top level structure of the MIB
tn3270eRtNotifications OBJECT IDENTIFIER ::= { tn3270eRtMIB 0 }
tn3270eRtObjects OBJECT IDENTIFIER ::= { tn3270eRtMIB 1 }
tn3270eRtConformance OBJECT IDENTIFIER ::= { tn3270eRtMIB 3 }
-- MIB Objects
-- Response Time Control Table
tn3270eRtCollCtlTable OBJECT-TYPE
SYNTAX SEQUENCE OF Tn3270eRtCollCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The response time monitoring collection control table,
which allows a management application to control the
types of response time data being collected, and the
clients for which it is being collected.
This table is indexed by tn3270eSrvrConfIndex and
tn3270eClientGroupName imported from the
TN3270E-MIB. tn3270eSrvrConfIndex indicates within
a host which TN3270E server an entry applies to.
tn3270eClientGroupName it identifies the set of IP
clients for which response time data is being collected.
The particular IP clients making up the set are identified
in the tn3270eClientGroupTable in the TN3270E-MIB."
::= { tn3270eRtObjects 1}
tn3270eRtCollCtlEntry OBJECT-TYPE
SYNTAX Tn3270eRtCollCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the TN3270E response time monitoring collection
control table. To handle the case of multiple TN3270E
servers on the same host, the first index of this table is
the tn3270eSrvrConfIndex from the TN3270E-MIB."
INDEX {
tn3270eSrvrConfIndex, -- Server's index
tn3270eClientGroupName } -- What to collect on
::= { tn3270eRtCollCtlTable 1 }Okay bestie, the whole collection control table is here and it's giving main character energy 💖 Each column is a knob you turn to decide what gets measured, how it gets summarised, and when the alarms go off 🔔
Tn3270eRtCollCtlEntry ::= SEQUENCE {
tn3270eRtCollCtlType BITS,
tn3270eRtCollCtlSPeriod Unsigned32,
tn3270eRtCollCtlSPMult Unsigned32,
tn3270eRtCollCtlThreshHigh Unsigned32,
tn3270eRtCollCtlThreshLow Unsigned32,
tn3270eRtCollCtlIdleCount Unsigned32,
tn3270eRtCollCtlBucketBndry1 Unsigned32,
tn3270eRtCollCtlBucketBndry2 Unsigned32,
tn3270eRtCollCtlBucketBndry3 Unsigned32,
tn3270eRtCollCtlBucketBndry4 Unsigned32,
tn3270eRtCollCtlRowStatus RowStatus }
-- The OID { tn3270eRtCollCtlEntry 1 } is not used
tn3270eRtCollCtlType OBJECT-TYPE
SYNTAX BITS {
aggregate(0),
excludeIpComponent(1),
ddr(2),
average(3),
buckets(4),
traps(5)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object controls what types of response time data to
collect, whether to summarize the data across the members
of a client group or keep it individually, whether to
introduce dynamic definite responses, and whether to
generate traps.
aggregate(0) - Aggregate response time data for the
client group as a whole. If this bit
is set to 0, then maintain response
time data separately for each member
of the client group.
excludeIpComponent(1) - Do not include the IP-network
component in any response times.
ddr(2) - Enable dynamic definite response.
average(3) - Produce an average response time
based on a specified collection
interval.
buckets(4) - Maintain tn3270eRtDataBucket values in
a corresponding tn3270eRtDataEntry,
based on the bucket boundaries specified
in the tn3270eRtCollCtlBucketBndry
objects .
traps(5) - generate the notifications specified
in this MIB module. The
tn3270eRtExceeded and tn3270eRtOkay
notifications are generated only if
average(3) is also specified."
::= { tn3270eRtCollCtlEntry 2 }The tn3270eRtCollCtlType bits are the big switchboard 🎛️ aggregate(0) decides whether the whole client group shares one set of numbers or everyone gets their own, average(3) turns on the averaging, buckets(4) turns on the bucket counting, and traps(5) turns on the notifications. Note that the exceeded and okay notifications only show up if average(3) is on too, so they're kind of a package deal 🥹
tn3270eRtCollCtlSPeriod OBJECT-TYPE
SYNTAX Unsigned32 (15..86400) -- 15 second min, 24 hour max
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The number of seconds that defines the sample period.
The actual interval is defined as tn3270eRtCollCtlSPeriod
times tn3270eRtCollCtlSPMult.
The value of this object is used only if the corresponding
tn3270eRtCollCtlType has the average(3) setting."
DEFVAL {20} -- 20 seconds
::= { tn3270eRtCollCtlEntry 3 }
tn3270eRtCollCtlSPMult OBJECT-TYPE
SYNTAX Unsigned32 (1..5760) -- 5760 x SPeriod of 15 is 24 hours
UNITS "period"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The sample period multiplier; this value is multiplied by
the sample period, tn3270eRtCollCtlSPeriod, to determine
the collection interval.
Sliding-window average calculation can, if necessary, be
disabled, by setting the sample period multiplier,
tn3270eRtCollCtlSPMult, to 1, and setting the sample
period, tn3270eRtCollCtlSPeriod, to the required
collection interval.
The value of this object is used only if the corresponding
tn3270eRtCollCtlType has the average(3) setting."
DEFVAL { 30 } -- yields an interval of 10 minutes when
-- used with the default SPeriod value
::= { tn3270eRtCollCtlEntry 4 }So the sample period is the little heartbeat ⏱️ and the multiplier stretches it into the real collection interval 🌸 The default combo, 20 times 30, is ten minutes, which is a very chill vibe. And if you really want a plain window with no sliding, you can set the multiplier to 1 and pick your own interval 🦋
tn3270eRtCollCtlThreshHigh OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The threshold for generating a tn3270eRtExceeded
notification, signalling that a monitored total response
time has exceeded the specified limit. A value of zero
for this object suppresses generation of this notification.
The value of this object is used only if the corresponding
tn3270eRtCollCtlType has average(3) and traps(5) selected.
A tn3270eRtExceeded notification is not generated again for a
tn3270eRtDataEntry until an average response time falling below
the low threshold tn3270eRtCollCtlThreshLow specified for the
client group has occurred for the entry."
DEFVAL { 0 } -- suppress notifications
::= { tn3270eRtCollCtlEntry 5 }
tn3270eRtCollCtlThreshLow OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The threshold for generating a tn3270eRtOkay notification,
signalling that a monitored total response time has fallen
below the specified limit. A value of zero for this object
suppresses generation of this notification. The value of
this object is used only if the corresponding
tn3270eRtCollCtlType has average(3) and traps(5) selected.
A tn3270eRtOkay notification is not generated again for a
tn3270eRtDataEntry until an average response time
exceeding the high threshold tn3270eRtCollCtlThreshHigh
specified for the client group has occurred for the entry."
DEFVAL { 0 } -- suppress notifications
::= { tn3270eRtCollCtlEntry 6 }The high and low thresholds are the bouncers at each end of the club 🚪 Set one to 0 and that notification just never shows up, which honestly is a power move 💅 The bit that's giving drama is the "not generated again" rule: once an alarm fires, it stays quiet until the average has crossed back over the other threshold. No spam, periodt ✨
tn3270eRtCollCtlIdleCount OBJECT-TYPE
SYNTAX Unsigned32
UNITS "transactions"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object is used to determine whether a
sample that yields an average response time exceeding the
value of tn3270eRtCollCtlThreshHigh was a statistically
valid one. If the following statement is true, then the
sample was statistically valid, and so a tn3270eRtExceeded
notification should be generated:
AvgCountTrans * ((AvgRt/ThreshHigh - 1) ** 2) >= IdleCount
This comparison is done only if the corresponding
tn3270eRtCollCtlType has average(3) and traps(5) selected."
DEFVAL { 1 }
::= { tn3270eRtCollCtlEntry 7 }IdleCount is the "is this sample actually legit?" check 🧐 It only matters when the average has gone over ThreshHigh, and the formula is the whole vibe check. Tiny little sample that's a bit spicy? It won't trigger. Solid evidence? Then the notification can go out 🔥
tn3270eRtCollCtlBucketBndry1 OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object defines the range of transaction
response times counted in the Tn3270eRtDataBucket1Rts
object: those less than or equal to this value."
DEFVAL { 10 }
::= { tn3270eRtCollCtlEntry 8 }
tn3270eRtCollCtlBucketBndry2 OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object, together with that of the
tn3270eRtCollCtlBucketBndry1 object, defines the range
of transaction response times counted in the
Tn3270eRtDataBucket2Rts object: those greater than the
value of the tn3270eRtCollCtlBucketBndry1 object, and
less than or equal to the value of this object."
DEFVAL { 20 }
::= { tn3270eRtCollCtlEntry 9 }
tn3270eRtCollCtlBucketBndry3 OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object, together with that of the
tn3270eRtCollCtlBucketBndry2 object, defines the range of
transaction response times counted in the
Tn3270eRtDataBucket3Rts object: those greater than the
value of the tn3270eRtCollCtlBucketBndry2 object, and less
than or equal to the value of this object."
DEFVAL { 50 }
::= { tn3270eRtCollCtlEntry 10 }
tn3270eRtCollCtlBucketBndry4 OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of this object, together with that of the
tn3270eRtCollCtlBucketBndry3 object, defines the range
of transaction response times counted in the
Tn3270eRtDataBucket4Rts object: those greater than the
value of the tn3270eRtCollCtlBucketBndry3 object, and
less than or equal to the value of this object.
The value of this object also defines the range of
transaction response times counted in the
Tn3270eRtDataBucket5Rts object: those greater than the
value of this object."
DEFVAL { 100 }
::= { tn3270eRtCollCtlEntry 11 }The four bucket boundaries are like a row of sorting hats 🎩 Every response time gets dropped into the first bucket whose ceiling it fits under, and the last boundary also opens the door for the fifth bucket. The units are tenths of a second, so the defaults of 10, 20, 50 and 100 are one, two, five and ten seconds 🍓
tn3270eRtCollCtlRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object allows entries to be created and deleted
in the tn3270eRtCollCtlTable. An entry in this table
is deleted by setting this object to destroy(6).
Deleting an entry in this table has the side-effect
of removing all entries from the tn3270eRtDataTable
that are associated with the entry being deleted."
::= { tn3270eRtCollCtlEntry 12 }
-- TN3270E Response Time Data Table
tn3270eRtDataTable OBJECT-TYPE
SYNTAX SEQUENCE OF Tn3270eRtDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The response time data table. Entries in this table are
created based on entries in the tn3270eRtCollCtlTable."
::= { tn3270eRtObjects 2 }
tn3270eRtDataEntry OBJECT-TYPE
SYNTAX Tn3270eRtDataEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries in this table are created based upon the
tn3270eRtCollCtlTable. When the corresponding
tn3270eRtCollCtlType has aggregate(0) specified, a single
entry is created in this table, with a tn3270eRtDataClientAddrType
of unknown(0), a zero-length octet string value for
tn3270eRtDataClientAddress, and a tn3270eRtDataClientPort value of
0. When aggregate(0) is not specified, a separate entry is
created for each client in the group.
Note that the following objects defined within an entry in this
table can wrap:
tn3270eRtDataTotalRts
tn3270eRtDataTotalIpRts
tn3270eRtDataCountTrans
tn3270eRtDataCountDrs
tn3270eRtDataElapsRnTrpSq
tn3270eRtDataElapsIpRtSq
tn3270eRtDataBucket1Rts
tn3270eRtDataBucket2Rts
tn3270eRtDataBucket3Rts
tn3270eRtDataBucket4Rts
tn3270eRtDataBucket5Rts"
INDEX {
tn3270eSrvrConfIndex, -- Server's local index
tn3270eClientGroupName, -- Collection target
tn3270eRtDataClientAddrType,
tn3270eRtDataClientAddress,
tn3270eRtDataClientPort }
::= { tn3270eRtDataTable 1 }RowStatus is how you make and break these rows 🧚 Set it to destroy(6) to delete a collection entry, and heads up, that also wipes every matching row in tn3270eRtDataTable 💀 And the data table is the diary that gets created from the control table: one shared entry for the whole group when aggregate(0) is set, or one entry per client when it isn't 🌈 Fair warning that a bunch of those counters are allowed to wrap around, so keep that in mind when you're reading them 🙈
okay so this is where the MIB gets really real 🎀 we're looking at the whole tn3270eRtDataEntry row, which is a SEQUENCE of 20 columns, one for each object. it's giving spreadsheet energy but make it networking 💅
Tn3270eRtDataEntry ::= SEQUENCE {
tn3270eRtDataClientAddrType IANATn3270eAddrType,
tn3270eRtDataClientAddress IANATn3270eAddress,
tn3270eRtDataClientPort Unsigned32,
tn3270eRtDataAvgRt Gauge32,
tn3270eRtDataAvgIpRt Gauge32,
tn3270eRtDataAvgCountTrans Gauge32,
tn3270eRtDataIntTimeStamp DateAndTime,
tn3270eRtDataTotalRts Counter32,
tn3270eRtDataTotalIpRts Counter32,
tn3270eRtDataCountTrans Counter32,
tn3270eRtDataCountDrs Counter32,
tn3270eRtDataElapsRndTrpSq Unsigned32,
tn3270eRtDataElapsIpRtSq Unsigned32,
tn3270eRtDataBucket1Rts Counter32,
tn3270eRtDataBucket2Rts Counter32,
tn3270eRtDataBucket3Rts Counter32,
tn3270eRtDataBucket4Rts Counter32,
tn3270eRtDataBucket5Rts Counter32,
tn3270eRtDataRtMethod INTEGER,
tn3270eRtDataDiscontinuityTime TimeStamp
}first up are the three index-ish columns that tell you who the stats belong to 👑 the client type, the client address, and the client port. they're all not-accessible, which means you can't just read them directly like the others, they're the key you use to find the row 🔑
tn3270eRtDataClientAddrType OBJECT-TYPE
SYNTAX IANATn3270eAddrType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicates the type of address represented by the value
of tn3270eRtDataClientAddress. The value unknown(0) is
used if aggregate data is being collected for the client
group."
::= { tn3270eRtDataEntry 1 }
tn3270eRtDataClientAddress OBJECT-TYPE
SYNTAX IANATn3270eAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Contains the IP address of the TN3270 client being
monitored. A zero-length octet string is used if
aggregate data is being collected for the client group."
::= { tn3270eRtDataEntry 2 }
tn3270eRtDataClientPort OBJECT-TYPE
SYNTAX Unsigned32(0..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Contains the client port number of the TN3270 client being
monitored. The value 0 is used if aggregate data is being
collected for the client group, or if the
tn3270eRtDataClientAddrType identifies an address type that
does not support ports."
::= { tn3270eRtDataEntry 3 }next up are the averages ✨ these are the "how does it feel right now" numbers, and they're all read-only and measured in tenths of seconds. the sliding transaction count is the one that's basically the backstage pass for the averages 🎟️
tn3270eRtDataAvgRt OBJECT-TYPE
SYNTAX Gauge32
UNITS "tenths of seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average total response time measured over the last
collection interval."
DEFVAL { 0 }
::= { tn3270eRtDataEntry 4 }
tn3270eRtDataAvgIpRt OBJECT-TYPE
SYNTAX Gauge32
UNITS "tenths of seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average IP response time measured over the last
collection interval."
DEFVAL { 0 }
::= { tn3270eRtDataEntry 5 }
tn3270eRtDataAvgCountTrans OBJECT-TYPE
SYNTAX Gauge32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The sliding transaction count used for calculating the
values of the tn3270eRtDataAvgRt and tn3270eRtDataAvgIpRt
objects. The actual transaction count is available in
the tn3270eRtDataCountTrans object.
The initial value of this object, before any averages have
been calculated, is 0."
::= { tn3270eRtDataEntry 6 }the timestamp is the "when did we last update the averages" clock ⏰ and it has a super specific starting value, so if you ever see all zeros in there, that's the vibe for "no averages yet, don't read anything into the other columns" 🙈
tn3270eRtDataIntTimeStamp OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The date and time of the last interval that
tn3270eRtDataAvgRt, tn3270eRtDataAvgIpRt, and
tn3270eRtDataAvgCountTrans were calculated.
Prior to the calculation of the first interval
averages, this object returns the value
0x0000000000000000000000. When this value is
returned, the remaining objects in the entry have
no significance."
::= { tn3270eRtDataEntry 7 }now the running totals 📈 these are the Counter32 columns, so they just keep climbing, and the discontinuity-time column is how a management app notices when they've been reset. the description on each one basically says "watch the discontinuity time, bestie" 👀
tn3270eRtDataTotalRts OBJECT-TYPE
SYNTAX Counter32
UNITS "tenths of seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the total response times collected.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 8 }
tn3270eRtDataTotalIpRts OBJECT-TYPE
SYNTAX Counter32
UNITS "tenths of seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the total IP-network response times
collected.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 9 }
tn3270eRtDataCountTrans OBJECT-TYPE
SYNTAX Counter32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the total number of transactions detected.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 10 }
tn3270eRtDataCountDrs OBJECT-TYPE
SYNTAX Counter32
UNITS "definite responses"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the total number of definite responses
detected.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 11 }the squared sums are giving math class but iconic 🧮 they're stored so that a variance can be worked out later, and that's about all the spec says on them 💖
tn3270eRtDataElapsRndTrpSq OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of seconds squared"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The sum of the elapsed round trip time squared. The sum
of the squares is kept in order to enable calculation of
a variance."
DEFVAL { 0 }
::= { tn3270eRtDataEntry 12 }
tn3270eRtDataElapsIpRtSq OBJECT-TYPE
SYNTAX Unsigned32
UNITS "tenths of seconds squared"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The sum of the elapsed IP round trip time squared.
The sum of the squares is kept in order to enable
calculation of a variance."
DEFVAL { 0 }
::= { tn3270eRtDataEntry 13 }then we get the five buckets 🪣 each one is a Counter32 that counts the response times that land in it. they all have the exact same discontinuity note, so it's a whole family moment 👯♀️
tn3270eRtDataBucket1Rts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the response times falling into bucket 1.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 14 }
tn3270eRtDataBucket2Rts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the response times falling into bucket 2.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 15 }
tn3270eRtDataBucket3Rts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the response times falling into bucket 3.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 16 }
tn3270eRtDataBucket4Rts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the response times falling into bucket 4.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 17 }
tn3270eRtDataBucket5Rts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The count of the response times falling into bucket 5.
A management application can detect discontinuities in this
counter by monitoring the tn3270eRtDataDiscontinuityTime
object."
::= { tn3270eRtDataEntry 18 }the method column tells you how the IP network time was worked out 🔍 there are three options, and none(0) is the "we didn't bother measuring the IP side" option 🫠
tn3270eRtDataRtMethod OBJECT-TYPE
SYNTAX INTEGER {
none(0),
responses(1),
timingMark(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of this object indicates the method that was
used in calculating the IP network time.
The value 'none(0) indicates that response times were not
calculated for the IP network."
::= { tn3270eRtDataEntry 19 }last column in the row, and it's the big reset-detector 🚨 it stores the sysUpTime from the most recent discontinuity, and the spec gives an example of how that can happen: a TN3270E server being stopped and restarted, with local methods setting up the collection policy. main character energy for the whole table honestly 👑
tn3270eRtDataDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which one or more of this entry's counter objects
suffered a discontinuity. This may happen if a TN3270E
server is stopped and then restarted, and local methods
are used to set up collection policy
(tn3270eRtCollCtlTable entries)."
::= { tn3270eRtDataEntry 20 }next is the spin lock 🔒 it's an advisory lock, so cooperating apps can use it to take turns editing the tn3270eRtCollCtlTable, but nothing actually stops an app from ignoring it. the vibes are "please wait your turn," not a bouncer 🙅♀️
tn3270eRtSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An advisory lock used to allow cooperating TN3270E-RT-MIB
applications to coordinate their use of the
tn3270eRtCollCtlTable.
When creating a new entry or altering an existing entry
in the tn3270eRtCollCtlTable, an application should make
use of tn3270eRtSpinLock to serialize application changes
or additions.
Since this is an advisory lock, the use of this lock is
not enforced."
::= { tn3270eRtObjects 3 }and finally the notification 🔔 this is the alarm that goes off when the average response time crosses the high threshold at the end of a collection interval. it only fires if the matching collection type has traps and average turned on, and the idle count gets a say too, so it's not just an instant "ding" every time 🛎️
-- Notifications
tn3270eRtExceeded NOTIFICATION-TYPE
OBJECTS {
tn3270eRtDataIntTimeStamp,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgCountTrans,
tn3270eRtDataRtMethod
}
STATUS current
DESCRIPTION
"This notification is generated when the average response
time, tn3270eRtDataAvgRt, exceeds
tn3270eRtCollCtlThresholdHigh at the end of a collection
interval specified by tn3270eCollCtlSPeriod
times tn3270eCollCtlSPMult. Note that the corresponding
tn3270eCollCtlType must have traps(5) and average(3) set
for this notification to be generated. In addition,
tn3270eRtDataAvgCountTrans, tn3270eRtCollCtlThreshHigh, and
tn3270eRtDataAvgRt are algorithmically compared to
tn3270eRtCollCtlIdleCount for determination if this
notification will be suppressed."
::= { tn3270eRtNotifications 1 }We're still inside the MIB module, bestie 🎀 Here are the last notifications and the conformance bits, and it's giving very structured energy 💅
tn3270eRtOkay NOTIFICATION-TYPE
OBJECTS {
tn3270eRtDataIntTimeStamp,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgCountTrans,
tn3270eRtDataRtMethod
}
STATUS current
DESCRIPTION
"This notification is generated when the average response
time, tn3270eRtDataAvgRt, falls below
tn3270eRtCollCtlThresholdLow at the end of a collection
interval specified by tn3270eCollCtlSPeriod times
tn3270eCollCtlSPMult, after a tn3270eRtExceeded
notification was generated. Note that the corresponding
tn3270eCollCtlType must have traps(5) and average(3)
set for this notification to be generated."
::= { tn3270eRtNotifications 2 }
tn3270eRtCollStart NOTIFICATION-TYPE
OBJECTS {
tn3270eRtDataRtMethod, -- type of collection
tn3270eResMapElementType -- type of resource
}
STATUS current
DESCRIPTION
"This notification is generated when response time data
collection is enabled for a member of a client group.
In order for this notification to occur the corresponding
tn3270eRtCollCtlType must have traps(5) selected.
tn3270eResMapElementType contains a valid value only if
tn3270eRtDataClientAddress contains a valid address
(rather than a zero-length octet string)."
::= { tn3270eRtNotifications 3 }
tn3270eRtCollEnd NOTIFICATION-TYPE
OBJECTS {
tn3270eRtDataDiscontinuityTime,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgCountTrans,
tn3270eRtDataIntTimeStamp,
tn3270eRtDataTotalRts,
tn3270eRtDataTotalIpRts,
tn3270eRtDataCountTrans,
tn3270eRtDataCountDrs,
tn3270eRtDataElapsRndTrpSq,
tn3270eRtDataElapsIpRtSq,
tn3270eRtDataBucket1Rts,
tn3270eRtDataBucket2Rts,
tn3270eRtDataBucket3Rts,
tn3270eRtDataBucket4Rts,
tn3270eRtDataBucket5Rts,
tn3270eRtDataRtMethod
}
STATUS current
DESCRIPTION
"This notification is generated when an tn3270eRtDataEntry
is deleted after being active (actual data collected), in
order to enable a management application monitoring an
tn3270eRtDataEntry to get the entry's final values. Note
that the corresponding tn3270eCollCtlType must have traps(5)
set for this notification to be generated."
::= { tn3270eRtNotifications 4 }
-- Conformance Statement
tn3270eRtGroups OBJECT IDENTIFIER ::= { tn3270eRtConformance 1 }
tn3270eRtCompliances OBJECT IDENTIFIER ::= { tn3270eRtConformance 2 }
-- Compliance statements
tn3270eRtCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for agents that support the
TN327E-RT-MIB."
MODULE -- this module
MANDATORY-GROUPS { tn3270eRtGroup, tn3270eRtNotGroup }
OBJECT tn3270eRtCollCtlType
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation to
this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlSPeriod
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to allow the user to change
the default value of this object, and is allowed to
use a different default."
OBJECT tn3270eRtCollCtlSPMult
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlThreshHigh
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlThreshLow
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlIdleCount
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlBucketBndry1
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlBucketBndry2
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlBucketBndry3
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlBucketBndry4
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a SET operation
to this object in the absence of adequate security."
OBJECT tn3270eRtCollCtlRowStatus
SYNTAX INTEGER {
active(1) -- subset of RowStatus
}
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention
need be supported, specifically: active(1)."
::= {tn3270eRtCompliances 1 }
-- Group definitions
tn3270eRtGroup OBJECT-GROUP
OBJECTS {
tn3270eRtCollCtlType,
tn3270eRtCollCtlSPeriod,
tn3270eRtCollCtlSPMult,
tn3270eRtCollCtlThreshHigh,
tn3270eRtCollCtlThreshLow,
tn3270eRtCollCtlIdleCount,
tn3270eRtCollCtlBucketBndry1,
tn3270eRtCollCtlBucketBndry2,
tn3270eRtCollCtlBucketBndry3,
tn3270eRtCollCtlBucketBndry4,
tn3270eRtCollCtlRowStatus,
tn3270eRtDataDiscontinuityTime,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgCountTrans,
tn3270eRtDataIntTimeStamp,
tn3270eRtDataTotalRts,
tn3270eRtDataTotalIpRts,
tn3270eRtDataCountTrans,
tn3270eRtDataCountDrs,
tn3270eRtDataElapsRndTrpSq,
tn3270eRtDataElapsIpRtSq,
tn3270eRtDataBucket1Rts,
tn3270eRtDataBucket2Rts,
tn3270eRtDataBucket3Rts,
tn3270eRtDataBucket4Rts,
tn3270eRtDataBucket5Rts,
tn3270eRtDataRtMethod,
tn3270eRtSpinLock }
STATUS current
DESCRIPTION
"This group is mandatory for all implementations that
support the TN3270E-RT-MIB. "
::= { tn3270eRtGroups 1 }
tn3270eRtNotGroup NOTIFICATION-GROUP
NOTIFICATIONS {
tn3270eRtExceeded,
tn3270eRtOkay,
tn3270eRtCollStart,
tn3270eRtCollEnd
}
STATUS current
DESCRIPTION
"The notifications that must be supported when the
TN3270E-RT-MIB is implemented. "
::= { tn3270eRtGroups 2 }
END6.0. Security Courtesy Check 🔐
Okay, this part is serious, so put your listening ears on 👂 Some of the management info in this MIB can be sensitive depending on the network, so authentication of incoming SNMP requests and controlled access to management information SHOULD be employed in those kinds of environments. An authentication protocol is defined in [12], and a protocol for access control is defined in [15].
Several objects in here allow write access or let you create rows. Turning that on in a non-secure environment can seriously mess with network operations 💀 It is RECOMMENDED that implementers really think hard about whether set operations or row creation SHOULD be allowed without providing, at a minimum, authentication of request origin. If that support isn't there, it is RECOMMENDED that the following objects be implemented as read-only:
tn3270eRtCollCtlTypetn3270eRtCollCtlSPeriodtn3270eRtCollCtlSPMulttn3270eRtCollCtlThreshHightn3270eRtCollCtlThreshLowtn3270eRtCollCtlIdleCounttn3270eRtCollCtlBucketBndry1tn3270eRtCollCtlBucketBndry2tn3270eRtCollCtlBucketBndry3tn3270eRtCollCtlBucketBndry4tn3270eRtCollCtlRowStatus
How the tn3270eRtCollCtlTable gets created and managed when SET support isn't allowed is outside the scope of this memo 🫶
7.0. Intellectual Property 🌈
The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights might be available. It also doesn't say it has tried to find any such rights. You can find the IETF's procedures for rights in standards-track and standards-related documents in BCP-11. Copies of claimed rights that were made available for publication, plus any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to practise this standard. Send that info to the IETF Executive Director 🦋
8.0. Acknowledgments 💜
This document is a product of the TN3270E Working Group. Huge thanks to Derek Bolton and Michael Boe of Cisco Systems for their many comments and suggestions on improving the structure of this MIB 🌸 Thanks also to Randy Presuhn of BMC Software for his valuable review comments on several versions of the document ✨
9.0. References ✨
okay bestie, the references section is where the receipts live 🧾💅 every single one of these is a doc the spec leans on, so here they all are, complete and unedited in their details 🎀
- [1] Harrington D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. 🌸
- [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. 💜
- [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. 🦋
- [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. ✨
- [5] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. 👑
- [6] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 🍓
- [7] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 🫶
- [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. 🌈
- [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 🧚
- [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. 💖
- [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, January 1998. 🔥
- [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, January 1998. 🎀
- [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 🦋
- [14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2273, January 1998. 🌸
- [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, January 1998. 💜
- [16] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. ✨
- [17] Postel, J. and J. Reynolds, "Telnet Timing Mark Option", STD 31, RFC 860, May 1983. 👑
- [18] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, January 1988. 🍓
- [19] Kelly, B., "TN3270 Enhancements", RFC 2355, June 1998. 🫶
- [20] White, K. and R. Moore, "Base Definitions of Managed Objects for TN3270E Using SMIv2", RFC 2561, April 1999. 🌈
- [21] IBM, International Technical Support Centers, "Response Time Data Gathering", GG24-3212-01, November 1990. 🧚
- [22] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. 💖
- [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔥
10.0. Authors' Addresses 🎀
these are the humans who wrote it, so here's how to reach them 🫶
Kenneth D. White Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA
EMail: kennethw@vnet.ibm.com
Robert Moore Dept. BRQA/Bldg. 501/G114 IBM Corporation P.O.Box 12195 3039 Cornwallis Research Triangle Park, NC 27709, USA
Phone: +1-919-254-7507 EMail: remoore@us.ibm.com
11.0. Full Copyright Statement 🌈
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
📦 where this page comes from
- ietf: rfc2562 1999-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms