home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_q_t
/
draft-ietf-tn3270e-rt-mib-01.txt
< prev
next >
Wrap
Text File
|
1997-10-01
|
95KB
|
2,517 lines
TN3270E Working Group
INTERNET DRAFT: <draft-ietf-tn3270e-rt-mib-01.txt> Kenneth White
Expiration Date: September 1998 Robert Moore
IBM Corp.
September 1997
Definitions of Managed Objects for TN3270E
Response Time Collection Using SMIv2
(TN3270E-RT-MIB)
<draft-ietf-tn3270e-rt-mib-01.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any Internet
Draft. Distribution of this document is unlimited.
Abstract
The purpose of this memo is to define the protocol and the Management
Information Base (MIB) for performing response time data collection
on TN3270 and TN3270E
sessions by a TN3270E Server. The response time data
collected by a TN3270E Server is structured to support both validation
of service level agreements and performance monitoring of
TN3270 and TN3270E
Sessions. This MIB has as a prerequisite the TN3270E-MIB
reference [10].
Expires March 1998 [Page 1]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
Table of Contents
1.0 Introduction............................................. 2
2.0 The SNMPv2 Network Management Framework.................. 2
2.1 Object Definitions....................................... 3
3.0 Response Time Collection Methodology..................... 3
3.1 General Response Time Collection......................... 4
3.2 TN3270E Server Response Time Collection.................. 5
3.3 Correlating TN3270E Server and Host Response Times....... 9
3.4 Timestamp Calculation....................................10
3.4.1 DR Usage...............................................11
3.4.2 TIMEMARK Usage.........................................13
3.5 Performance Data Modelling...............................14
3.5.1 Averaging Response Times...............................15
3.5.2 Response Time Buckets..................................17
4.0 Structure of the MIB.....................................18
4.1 tn3270eRtCollCtlTable....................................18
4.2 tn3270eRtDataTable.......................................21
4.3 Notifications............................................23
5.0 Definitions..............................................24
6.0 Security Considerations..................................39
7.0 Acknowledgments..........................................40
8.0 References...............................................40
9.0 Authors' Addresses.......................................42
1. Introduction
This document is a product of the TN3270E Working Group. Its purpose
is to define a protocol and a MIB module to enable a TN3270E server to
collect response time data for both TN3270 and TN3270E clients.
Prerequisites for implementing this MIB are:
o TN3270E-MIB, Base Definitions of Managed Objects for TN3270E
Using SMIv2 [10].
o TN3270E RFCs
o SYSAPPL-MIB, import Utf8String Textual Convention for
international text string support, reference [13].
2. The SNMPv2 Network Management Framework
The SNMP Network Management Framework presently consists of three
major components. They are:
Expires March 1998 [Page 2]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
o the SMI, described in RFC 1902 [1], - the mechanisms used for
describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [5], - the core set of managed
objects for the Internet suite of protocols.
o the protocol, RFC 1157 [9] and/or RFC 1905 [7] - the protocol
for accessing managed information.
It is the intent of this MIB to fully adhere to all prerequisite MIBs
unless explicitly stated. Deviations will be documented in
corresponding conformance statements. The specification of this MIB
uses the Structure of Management Information (SMI) for Version 2 of
the Simple Network Management Protocol Version (refer to RFC1902,
reference [1]).
Textual conventions are defined in RFC 1903 [6], and conformance
statements are defined in RFC 1904 [8].
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
This memo specifies a MIB module that is compliant to the SNMPv2 SMI.
A semantically identical MIB conforming to the SNMPv1 SMI can be
produced through the appropriate translation.
2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. The object type
together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience, we often
use a textual string, termed the descriptor, to refer to the object
type.
3. Response Time Collection Methodology
This section explains the methodology and approach used by the MIB
defined by this memo for response time data collection by a TN3270E
Server.
Expires March 1998 [Page 3]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
3.1. General Response Time Collection
Two primary methods exist for measuring response times in SNA
networks:
o The SNA Management Services (SNA/MS) Response Time
Monitoring (RTM) function
o Timestamping using definite response flows.
This memo defines an approach using definite responses to timestamp
the flows between a client and its TN3270E server, rather than on 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
concepts 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 in this memo.
As mentioned, this memo focuses on using definite responses to
timestamp the flows between a client and its TN3270E server for
generating performance data. Use of a definite response flow requires
that the client supports TN3270E with the RESPONSES function
negotiated. The TN3270 TIMEMARK option can be used instead of definite
response for supporting TN3270 Clients or TN3270E Clients that don't
support RESPONSES. This document focuses on defining the protocol and
methods for generating performance data using definite responses and
then describes how the TIMEMARK option can be used instead of definite
response.
In an SNA network, a transaction between a client Logical Unit (LU)
and a target host in general looks as follows:
------------------------------------------------
| |
| Client LU Target SNA Host |
| |
| Timestamps |
| request A |
| -----------------------------------------> |
| reply(DR) B | |
| <---------------------------------------< |
| | +/-RSP C |
| >---------------------------------------> |
| |
| DR: Definite Response requested |
| DR +/-: Definite Response |
| |
------------------------------------------------
Expires March 1998 [Page 4]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
This transaction is a simple one, and is being used only to illustrate
how timestamping at a target SNA host can be used to generate response
times. An IBM redbook [12] provides a more detailed description of
response time collection for a transaction of this type. Note that
for the purpose of calculating an approximation for network transit
time, is doesn't matter if the response is positive or negative. Two
response time values are typically calculated:
o Host Transit Time: Timestamp B - A
o Network Transit Time: Timestamp C - B
Network transit time is an approximation for the amount of time that a
transaction requires to flow across a network, since the response flow
is being substituted for the request flow at the start of the
transaction. Network transit time, timestamp C - B, is the amount of
time that the definite response request and its response required.
Host time, timestamp B - A, is the actual time that the host required
to process the transaction. Experience has shown that using the
response flow to approximate network transit times is useful, and does
correlate well with actual network transit times.
The TN3270E-RT-MIB describes a method of collecting performance data
that is not appropriate for printer (LU Type 1 or LU Type 3) sessions;
thus collection of performance data for printer sessions is excluded
from this MIB. This exclusion of printer sessions is not considered a
problem, since these sessions are not the most important ones for
response time monitoring, and since historically they were excluded
from SNA/MS RTM collection. The tn3270eTcpConnResourceType object in
a tn3270eTcpConnEntry (in the TN3270E-MIB) can be examined to
determine if a client session is ineligible for response time data
collection.
3.2. TN3270E Server Response Time Collection
A TN3270E Server connects an IP client performing 3270 emulation to a
target SNA host over both an IP network (IP client to TN3270E server)
and an SNA Network (TN3270E server to target SNA host). A TN3270E
server can use SNA definite responses and the TN3270 Enhancement (RFC
1647 [11]) RESPONSES function to calculate response times for a
transaction, by timestamping when a client sends a request, when the
reply arrives from the target host, and when the response
acknowledging this reply arrives from the client.
Section 3.4, Timestamp Calculation, provides specifics on when in the
sequence of flows between a TN3270E client and its target SNA host a
TN3270E server takes its timestamps. In addition, there is information
on how the TN3270 TIMEMARK request/response flow can be used instead
Expires March 1998 [Page 5]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
of DR for approximating IP network transit times.
The following figure adds a TN3270E server between the client, in this
case a TN3270E client and the target SNA host:
------------------------------------------------
| |
| Client TN3270E Target |
| Server SNA Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D |
| ------------------------------------------> |
| reply(DR) E | |
| <----------------------------------------< |
| | +/-RSP F |
| >-------------------- - - - - - - - - - > |
| |
------------------------------------------------
A 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 flowed with the reply. In fact, it doesn't matter whether the
target SNA host requested a definite response on its reply: if it
didn't, the TN3270E server makes the request on its own, to enable it
to produce timestamp F. In this case the TN3270E server does not
forward the response to the target SNA host, as the dotted line in the
figure indicates.
In order 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
TN3270E RESPONSES function occurs during the client's TN3270E session
initialization. The TN3270E servers that the authors are aware of do
request the RESPONSES function during client session initialization.
TN3270E clients either automatically support the RESPONSES function,
or can be configured during startup to support it.
Using timestamps D, E, and F the following response times can be
calculated by a TN3270E server:
o Total Response time: F - D
o IP Network Transit Time: F - E
Expires March 1998 [Page 6]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
The MIB provides an object, tn3270eRtCollCtlType, to control several
aspects of response time data collection. One of the available
options in setting up a response time collection policy is to
eliminate the IP-network component altogether. This might be done
because it is determined either that the additional IP network traffic
would not be desirable, or that the IP-network components of the
overall response times are not significant.
Excluding the IP-network component from response times also has an
implication for the way in which response time data is aggregated. A
TN3270E server may find that some of its clients simply don't support
any of the functions necessary for the server to calculate the IP-
network component of response times. For these clients, the most that
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 each of these clients' transactions. If a
response time collection is aggregating data from a number of clients,
some of which have the support necessary for including the IP-network
component in their total response time calculations, and some of which
do not, then the server aggregates the data differently depending on
whether the collection has been defined to include or exclude the IP-
network component:
o If the IP-network component is included, then transactions
for the clients that don't support calculation of the
IP-network component of their response times are excluded
from the aggregation altogether.
o 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.
The principle here is that 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 for which an IP-network component could have been
calculated.
There is one more complication here: the MIB allows a management
application to enable or disable dynamic definite responses for a
Expires March 1998 [Page 7]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
response time collection. Once again the purpose of this option is to
give the network operator control over the amount of traffic
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 for which 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 this response to calculate
timestamp F, but then it does not forward it on to the SNA application
(since the application is not expecting a response to its reply).
This dynamic definite responses option is related to the option of
including or excluding the IP-network component of response times
(discussed above) as follows:
o If the IP-network component is excluded, then there is
no reason for enabling dynamic definite responses: the
server always sets timestamp F equal to timestamp E, so
the additional IP-network traffic elicited by a dynamic
definite response would serve no purpose.
o 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, and so their
transactions are never included in the aggregate.
- For clients that support sending of responses,
timestamp F will always be calculated for transactions
in which the host SNA application specifies DR in
its reply, and 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
for which the host SNA application did not specify
DR in its reply.
A TN3270E server also has the option of substituting TIMEMARK
processing for definite responses in calculating the IP-network
component of a transaction's response time. Once again, there is no
reason for the server to do this if the collection has been set up to
exclude the IP-network component altogether in computing response
times.
The MIB is structured to keep for each response time the total time (F
- D) and the IP-network component (F - E). A management application
can obviously calculate from these two values a response time's SNA-
Expires March 1998 [Page 8]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
network component (E - D). The SNA-network component would also
contain the host processing time at both the TN3270E Server and at the
target application. As in the IP case, these response times are only
approximations, because the +/-RSP's crossing of the IP network is
substituted for that of the request that started the transaction.
When a TN3270E server is in the same SNA host as the target
application, then the SNA-network component of a transaction's
response time will approximately equal the host transit time (B - A)
described previously. A host (as opposed to a gateway) TN3270E server
implementation can typically support the establishment of sessions to
target applications in remote SNA hosts; in this case the SNA-network
component equals the actual SNA-network transit time plus two host
transit times.
3.3. Correlating TN3270E Server and Host Response Times
It is possible that response time data is collected from TN3270E
servers at the same time as a management application is monitoring the
SNA sessions at a host. For example, a management application can be
monitoring a secondary logical unit (SLU) while retrieving data from a
TN3270E server. Consider the following figure:
------------------------------------------------
| |
| Client TN3270E Target |
| Server SNA Host |
| Timestamps (PLU) |
| (SLU) Timestamps|
| <---IP Network-------><---SNA Network---> |
| |
| request D A |
| ------------------------------------------> |
| reply(DR) E B | |
| <----------------------------------------< |
| | +/-RSP F C |
| >--------------------------------------> |
| |
------------------------------------------------
The following response times are available:
o Target SNA host transit time: B - A
o Target SNA host (total) network transit time: C - B
o TN3270E server total response time: F - D
o TN3270E server IP-network component: F - E
Expires March 1998 [Page 9]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
The value added by the TN3270E server in this situation is its
approximation of the IP-network component of the overall response
time. The IP-network component can be subtracted from the total
network transit time determined by monitoring the SLU to see the
actual SNA versus IP network transit times.
The MIB defined by this memo does not specifically address correlation
of the data it contains with response time data collected by direct
monitoring of SNA resources: its focus is exclusively response time
data collection from a TN3270E server perspective. It has, however,
in conjunction with the TN3270E-MIB [10], been structured to provide
the information necessary for correlation between TN3270E server-
provided response time information and that gathered from directly
monitoring SNA resources.
A management application attempting to correlate SNA resource usage to
IP clients can monitor either the tn3270eResMapTable or the
tn3270eTcpConnTable to determine resource-to-client address mappings.
Both of these tables are defined by the TN3270E-MIB [10]. Another
helpful table is the tn3270eSnaMapTable, which provides a mapping
between SLU names as they are known at the SSCP (VTAM) and their local
names at the TN3270E server. Neither the tn3270eClientGroupTable, the
tn3270eResPoolTable, nor the tn3270eClientResMapTable from the
TN3270E-MIB can be used for correlation, since the mappings defined by
these tables can overlap and may not provide one-to-one mappings.
3.4. Timestamp Calculation
This section goes into more detail concerning when the various
timestamps can be taken as the flows between a TN3270E client and its
target SNA host pass through a TN3270E server. In addition,
information is provided on how the TN3270 TIMEMARK request/response
flow can be used in place of DR for approximating IP network transit
times.
Expires March 1998 [Page 10]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
3.4.1. DR Usage
Consider the following flow:
----------------------------------------------------------
| |
| Client TN3270E Target SNA |
| Server Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D (BB,CD,OIC,ER) |
| -------------------------------------------> |
| reply (FIC,ER,EB) | |
| <-----------------------------------------< |
| reply (MIC,ER) |
| <-----------------------------------------< |
| reply (MIC,ER) |
| <-----------------------------------------< |
| reply(DR) 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 |
----------------------------------------------------------
Timestamp D is taken at the TN3270E server when a client sends data to
the server for forwarding to its target SNA host. This is most likely
when the server finds the end of record indicator in the TCP data
received from the client. The target SNA returns its reply in one or
more SNA Request Units (RUs); in this example there are four RUs in
the reply. The first RU is marked as first in chain (FIC), the next
two are marked as middle in chain (MIC), and the last is marked as
last in chain (LIC). Timestamp E should be taken prior to sending the
RESPONSES request to the client; normally this is done when the server
receives the LIC RU. Timestamp F is taken when the RESPONSES response
is received from the client.
A target SNA application doesn't necessarily return data to a client
in a transaction; it may, for example, require more data from the
client before it can formulate a reply. In this case the application
may simply return to the TN3270E server a change of direction
Expires March 1998 [Page 11]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
indicator. A TCP connection is full duplex: data can be received and
sent on it at the same time. An SNA session, on the other hand, is
half duplex, with a change of direction indicator to alter the
direction of data flow. Timestamps E and F require a reply to flow to
the client. A best-effort approach should be followed by a TN3270E
server when it attempts to calculate timestamps. For cases where the
target SNA application sends a change of direction indicator rather
than a reply, it is suggested that the entire transaction be omitted
from any response time calculations.
Another consideration is a mismatch between DR requested on the SNA
side and DR requested by a TN3270E server. If the SNA host sends a
multiple-RU chain, the server does not know until the last RU is
received whether DR is being requested. Meanwhile, the server may
have forwarded the first RU in the chain to the client. In practice,
therefore, some servers convert ER flows to DR flows. Timestamp E can
be taken when the first RESPONSES request flows to the client, and
timestamp F when its response is received. In this instance an
additional timestamp G is needed when the LIC RU is received:
---------------------------------------------------
| |
| Client TN3270E Target |
| Server SNA Host |
| Timestamps |
| |
| <---IP Network-------><---SNA Network---> |
| |
| request D (BB,CD,OIC,ER) |
| ------------------------------------------> |
| reply(DR) E (FIC,ER,EB) | |
| <----------------------------------------< |
| | +/-RSP F |
| >-------------------> |
| reply (MIC,ER) |
| <----------------------------------------< |
| reply (MIC,ER) |
| <----------------------------------------< |
| reply(DR) (LIC,DR) |
| <----------------------------------------< |
| | +/-RSP G |
| >-------------------> |
| |
---------------------------------------------------
The response times can then be calculated as follows:
o Total response time: G - D
Expires March 1998 [Page 12]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
o IP network transit time: F - E
If DR is requested by the LIC RU, then the TN3270E server can use
either its response or the earlier one for approximating IP network
transit time.
3.4.2. TIMEMARK Usage
It is possible for a TN3270E server to use the TIMEMARK flow for
approximating IP network transit times. Using TIMEMARKs would make it
possible for a server to collect performance data for TN3270 clients,
as well as for TN3270E clients that do not support the RESPONSES
function. In order for TIMEMARKs to be used in this way, a client
can't have the NOP option enabled, since responses are needed to the
server's TIMEMARK requests. An IP network transit time approximation
using a TIMEMARK is basically the amount of time it takes for a TN3270
server to receive a response from a client to a TIMEMARK request.
If a TN3270 server is performing the TIMEMARK function (independent of
the response time monitoring use of the function discussed here), then
it most likely has a TIMEMARK interval for determining when to examine
client sessions for sending the TIMEMARK request. (This interval,
which is ordinarily a global value for an entire TN3270E server, is
represented in the TN3270E-MIB by the tn3270eSrvrConfActivityInterval
object.) A TIMEMARK request is sent only if, when it is examined, a
client session is found to have had no activity for a different length
of time, represented in the TN3270E-MIB by the
tn3270eSrvrConfActivityTimeout object.
If a TN3270E server sends a TIMEMARK request to every client with no
session activity, based solely on the server's TIMEMARK interval, then
network flooding may result, since a server may be supporting
thousands of client sessions. The use of TIMEMARKs for response time
monitoring could help to reduce this network flooding. Suppose a
server sends a TIMEMARK request to a client after a LIC RU has been
received, as a means of approximating IP network transit time:
Expires March 1998 [Page 13]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
---------------------------------------------------
| |
| 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(DR) (LIC,ER) |
| <-----------------------------------------< |
| TIMEMARK Rqst E |
| <--------------------- |
| | TIMEMARK Rsp F |
| >-------------------> |
| |
---------------------------------------------------
The response times can then be calculated as follows:
o TN3270E server total response time: F - D
o TN3270E server IP network time: F - E
A TN3270E server would need to consider its normal TIMEMARK processing
when using TIMEMARKs for this purpose. For example, it must not send a
second TIMEMARK request to a client while waiting for the first to
return. Also, if a TIMEMARK flow has just been performed for a client
shortly before the LIC RU arrives, the server might use the interval
from this flow as its approximation for IP network transit time; in
this case the server would have to remember to add the interval from
this TIMEMARK flow (F' - E') to the interval from the transaction (E -
D) to get its approximation for the transaction's total response time.
3.5. Performance Data Modelling
The following two subsections detail how the TN3270E-RT-MIB models and
controls capture of two types of response time data: average response
times and response time buckets.
Expires March 1998 [Page 14]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
3.5.1. Averaging Response Times
Average response times play two different roles in the MIB:
o They are made available for management applications to retrieve.
o They serve as triggers for emitting notifications.
Sliding-window averages are used rather than straight interval-based
averages, because they are often more meaningful, and because they
cause less notification thrashing. 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.
In order to calculate sliding-window averages, a TN3270E server must:
o Select a fixed, relative short, sample period SPeriod; the
default value for SPeriod in the MIB is 20 seconds.
o Select an averaging period multiplier SPMult. The actual
collection interval will then be SPMult times SPeriod. The
default value for SPMult in the MIB is 30, yielding a default
collection interval of 10 minutes. Note that the collection
interval (SPMult*SPeriod) is always a multiple of the sample
period.
o Maintain the following counters to keep track of activity within
the current sample period; these are internal counters, not
made visible to a management application via the MIB.
- T (number of transactions in the period)
- TotalRt (sum of the total response times for all
transactions in the period)
- TotalIpRt (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).
o Also maintain sliding counters, initialized to zero, for each
of the quantities being counted:
- AvgTransCount (sliding count of transactions)
- TotalRtSliding (sliding count of total response times)
- TotalIpRtSliding (sliding count of IP network transit times)
o At the end of each sample period, update the sliding counters:
AvgTransCount = AvgTransCount + T
Expires March 1998 [Page 15]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
- (AvgTransCount / SPMult)
TotalRtSliding = TotalRtSliding + TotalRt
- (TotalRtSliding / SPMult)
TotalIpRtSliding = TotalIpRtSliding + TotalIpRt
- (TotalIpRtSliding / SPMult)
Then reset T, TotalRt, and TotalIpRt to zero for use during the
next sample period.
o At the end of a collection interval, update the following MIB
objects as indicated:
tn3270eRtDataAvgTransCount = AvgTransCount
tn3270eRtDataAvgRt = TotalRtSliding / AvgTransCount
tn3270eRtDataAvgIpRt = TotalIpRtSliding / AvgTransCount
As expected, if IP network transit times are being excluded
from response time collection, then tn3270eRtDataAvgIpRt
will always return 0.
The sliding transaction counter AvgTransCount is not used for updating
the MIB object tn3270eRtDataTransCount: this object is an ordinary
SMI Counter32, which maintains a total count of transactions since its
last discontinuity event. The sliding counters are used only for
calculating averages.
Two mechanisms are present in the MIB to inhibit the generation of 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. After this, no other tn3270eRtExceeded
notifications are generated until an average response time is found to
have fallen below the low threshold.
The other mechanism to limit notifications is the significance test
for a high average response time. Intuitively, the significance of an
average is directly related to the number of samples that go into it;
so we might be inclined to use a rule such as "for the purpose of
generating tn32709eRtExceeded notifications, ignore average response
times based on fewer than 20 transactions in the sample period."
In the case of response times, however, the number of transactions
sampled in a fixed sampling period is tied to these transactions'
response times. A few transactions with long response times can
guarantee that there will not be many transactions in a sample,
Expires March 1998 [Page 16]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
because these transactions "use up" the sampling time. Yet this case
of a few transactions with very poor response times should obviously
be classified as a problem, not as a statistical anomaly based on too
small a sample.
The solution is to make the significance level for a sample a function
of the average response time. In order to determine at a collection
interval whether to generate a tn3270eRtExceeded notification, a
TN3270E server uses the following algorithm:
if AvgTransCount * ((AvgRt/ThreshHigh - 1) ** 2) < IdleRate
then generate the notification
Two examples illustrate how this algorithm works. Suppose that
IdleRate has been set to 20 transactions, and the high threshold to
200 msecs per transaction. If the average observed response time is
300 msecs, then a notification will be generated only if AvgTransCount
>= 80. If, however, the observed response time is 500 msecs, then a
notification is generated if AvgTransCount >= 9.
There is no corresponding significance test for the tn3270eRtOkay
notification: this notification is generated based on an average
response time that falls below the low threshold, regardless of the
sample size behind that average.
3.5.2. Response Time Buckets
The MIB also supports collection of response time data into a set of
five buckets. This data is suitable either for verification of service
level agreements, or for monitoring by a management application to
identify performance problems. The buckets provide counts of
transactions whose total response times fall into a set of specified
ranges.
Like everything for a collection, the "total" response times collected
in the buckets are governed by the specification of whether IP network
transit times are to be included in the totals. Depending on how this
option is specified, the response times being counted in the buckets
will either be total response times (F - D), or only SNA network
transit times (effectively E - D, because when it is excluding the
IP-network component of transactions, a server makes timestamp F
identical to timestamp E).
Four bucket boundaries are specified for a response time collection,
resulting in five buckets. The first response time bucket counts those
transactions whose total response times were less than or equal to
Boundary 1, the second bucket counts those whose response times were
greater than Boundary 1 but less than or equal to Boundary 2, and so
Expires March 1998 [Page 17]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
on. The fifth bucket is unbounded on the top, counting all
transactions whose response times were greater than Boundary 4.
The four bucket boundaries have default values of: 1 second, 2
seconds, 5 seconds, and 10 seconds, respectively. These values are
the defaults in the 3174 controller's implementation of the SNA/MS RTM
function, and were thought to be appropriate for this MIB as well.
In SNA/MS the counter buckets were (by today's standards) relatively
small, with a maximum value of 65,535. The bucket objects in the MIB
are all Counter32's.
The following figure represents the buckets pictorially:
----------------------------------------------
| |
| Response Time Boundaries |
| | | | | | | |
| | | | | | | |
| | | | | | no |
| 0 B-1 B-2 B-3 B-4 bound|
| | | | | | | |
| |Bucket1|Bucket2|Bucket3|Bucket4|Bucket5| |
| ----------------------------------------- |
| |
----------------------------------------------
4. Structure of the MIB
The TN3270E-RT-MIB has the following components:
o tn3270eRtCollCtlTable
o tn3270eRtDataTable
o Notifications
4.1. tn3270eRtCollCtlTable
The tn3270eRtCollCtlTable is indexed by tn3270eSrvrConfIndex, imported
from the TN3270E-MIB, and by tn3270eRtCollCtlClientGroupName.
tn3270eSrvrConfIndex identifies within a host a particular TN3270E
server. tn3270eRtCollCtlClientGroupName identifies a collection of IP
clients for which response time data is to be collected. The
collection itself is defined using the tn3270eClientGroupTable from
the TN3270E-MIB. The index from the tn3270eClientGroupTable,
tn3270eClientGroupName, was not used directly, since doing so causes
an inconsistent indexing scheme error in some MIB compilers. To avoid
Expires March 1998 [Page 18]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
this error, tn3270eRtCollCtlClientGroupName was defined directly in
the tn3270eRtCollCtlEntry.
A tn3270eRtCollCtlEntry contains the following objects:
--------------------------------------------------
1st Index | tn3270eSrvrConfIndex Unsigned32 |
2nd Index | tn3270eRtCollCtlClientGroupName Utf8String |
| tn3270eRtCollCtlType BITS |
| tn3270eRtCollCtlSPeriod Unsigned32 |
| tn3270eRtCollCtlSPMult Unsigned32 |
| tn3270eRtCollCtlThreshHigh Unsigned32 |
| tn3270eRtCollCtlThreshLow Unsigned32 |
| tn3270eRtCollCtlIdleRate Unsigned32 |
| tn3270eRtCollCtlBucketBndry1 Unsigned32 |
| tn3270eRtCollCtlBucketBndry2 Unsigned32 |
| tn3270eRtCollCtlBucketBndry3 Unsigned32 |
| tn3270eRtCollCtlBucketBndry4 Unsigned32 |
| tn3270eRtCollCtlRowStatus RowStatus |
--------------------------------------------------
The tn3270eRtCollCtlType object controls the type(s) of response time
collection that occur, the granularity of the collection, whether
dynamic definite responses should be initiated, and whether
notifications should be generated. This object is of BITS SYNTAX, and
thus allows selection of multiple options.
The BITS in the tn3270eRtCollCtlType object have the following
meanings:
o aggregate(0) - If this bit is set to 1, then data should be
aggregated for the whole client group. In this case there will
be only one row created for the collection in the
tn3270eRtDataTable. The first two indexes for this row,
tn3270eSrvrConfIndex and tn3270eRtCollCtlClientGroupName, will
have the same values as the indexes for this row in the
tn3270eRtCollCtlTable. The third and fourth indexes for an
aggregated tn3270eRtDataEntry have the values 'unknown(0)'
(for tn3270eRtDataClientAddrType) and a null octet string
(for tn3270eRtDataClientAddress).
If this bit is set to 0, then a separate entry is created in the
tn3270eRtDataTable for each member of the client group. In this
case the tn3270eRtDataClientAddress contains the client's actual
IP Address, and tn3270eRtDataClientAddrType indicates the type
of this address.
o excludeIpComponent(1) - If this bit is set to 1, then the
Expires March 1998 [Page 19]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
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, this DR will
still be passed down to the client, and the client's response
will still be forwarded to the application. But this response
will play no role in the server's response time calculations.
If this bit is set to 0, then the server includes in the
collection only those transactions for which it can include an
(approximate) IP-network component in the total response time
for the transaction. This component may be derived 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 has been
set to 1), or from TIMEMARK processing (if the client supports
TIMEMARKs).
If this bit is set to 1, then the ddr(2) bit is ignored, since
there is no reason for the server to request additional
responses from the client(s) in the group.
o ddr(2) - If this bit is set to 1, then the server should, for
those clients in the group that support the RESPONSES function,
add a DR request to a reply in each transaction (usually, but
not necessarily the LIC reply), and use the client's subsequent
response for calculating an (approximate) IP-network component
to include in the transaction's total response times.
If this bit is set to 0, then the server does not add a DR
request to any replies from the target SNA application.
If the excludeIpComponent(1) bit is set to 1, then this bit is
ignored by the server.
o average(3) - If this bit is set to 1, then the server should
calculate a sliding-window average for the collection, based
on the parameters specfied for the group.
If this bit is set to 0, then an average is not calculated. In
this case the tn3270eRtExceeded and tn3270eRtOkay notifications
are not generated, even if the traps(5) bit is set to 1.
o buckets(4) - If this bit is set to 1, then the server should
create and increment response time buckets for the collection,
based on the parameters specified for the group.
If this bit is set to 0, then response time buckets are not
created.
Expires March 1998 [Page 20]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
o traps(5) - If this bit is set to 1, then the server generates
the notifications defined in this MIB. The tn3270CollStart and
tn3270CollEnd notifications are always generated when this bit
is set to 1; the tn3270eRtExceeded and tn3270eRtOkay
notifications are generated only if the average(3) bit is also
set to 1.
If this bit is set to 0, then none of the notifications defined
in this MIB are generated by the server.
Either the average(3) or the buckets(4) bit must be set to 1 in order
for response time data collection to occur. If the average(3) bit is
set to 1, then the following objects have meaning, and are used to
control the calculation of the averages, as well as the generation of
the two notifications related to them:
o tn3270eRtCollCtlSPeriod
o tn3270eRtCollCtlSPMult
o tn3270eRtCollCtlThreshHigh
o tn3270eRtCollCtlThreshLow
o tn3270eRtCollCtlIdleRate
If the buckets(4) bit is set to 1, then the following objects have
meaning, and specify the bucket boundaries:
o tn3270eRtCollCtlBucketBndry1
o tn3270eRtCollCtlBucketBndry2
o tn3270eRtCollCtlBucketBndry3
o tn3270eRtCollCtlBucketBndry4
4.2. tn3270eRtDataTable
Either a single entry or multiple entries are created in the
tn3270eRtDataTable for each tn3270eRtCollCtlEntry, depending on
whether tn3270eRtCollCtlType in the control entry has aggregate(0)
selected. The contents of an entry in the tn3270eRtDataTable depend
on the contents of the corresponding entry in the
tn3270eRtCollCtlTable: some objects in the data entry return
meaningful values only when the average(3) option is selected in the
control entry, while others return meaningful values only when the
buckets(4) option is selected. If both options are selected, then all
the objects return meaningful values. When an object is not specified
to return a meaningful value, an implementation may return any value
in response to a Get operation.
The following objects return meaningful values if and only if the
Expires March 1998 [Page 21]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
average(3) option was selected in the corresponding
tn3270eRtCollCtlEntry:
o tn3270eRtDataAvgRt
o tn3270eRtDataAvgIpRt
o tn3270eRtDataAvgTransCount
o tn3270eRtDataIntTimeStamp
o tn3270eRtDataTotalRt
o tn3270eRtDataTotalIpRt
o tn3270eRtDataTransCount
o tn3270eRtDataDrCount
o tn3270eRtDataElapsRndTrpSq
o tn3270eRtDataElapsIpRtSq
The first three objects in this list return values derived from the
sliding-window average calculations described earlier. The time of
the most recent sample for these calculations is returned in the
tn3270eRtDaraIntTimeStamp object. The next four objects are normal
Counter32 objects, maintaining counts of total response time and total
transactions. The last two objects return sum of the squares values,
to enable variance calculations by a management application.
o tn3270eRtDataElapsRndTrpSq
o tn3270eRtDataElapsIpRtSq
The following objects return meaningful values if and only if the
buckets(4) option was selected in the corresponding
tn3270eRtCollCtlEntry:
o tn3270eRtDataBucket1
o tn3270eRtDataBucket2
o tn3270eRtDataBucket3
o tn3270eRtDataBucket4
o tn3270eRtDataBucket5
A discontinuity object, tn3270eRtDataDiscontinuityTime, can be used by
a management application to detect when the values of the counter
objects in this table may have been reset, or otherwise experienced a
discontinuity. A possible cause for such a discontinuity is the
TN3270E server's being stopped or restarted. This object returns a
meaningful value regardless of which collection control options were
selected.
When an entry is created in the tn3270eRtCollCtlTable with its
tn3270eRtCollCtlType aggregate(0) bit set to 1, an entry is
automatically created in the tn3270eRtDataTable; this entry's
tn3270eRtDataClientAddress has the value of a null octet string, and
Expires March 1998 [Page 22]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
its tn3270eRtDataClientAddrType has the value of unknown(0).
When an entry is created in the tn3270eRtCollCtlTable with its
tn3270eRtCollCtlType 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. Entries are
subsequently created for clients that the TN3270E server determines to
be members of the client group when these clients establish sessions
with the server.
All entries associated with a tn3270eRtCollCtlEntry are deleted from
the tn3270eRtDataTable when that entry is deleted from the
tn3270eRtCollCtlTable. An entry for an individual client in a client
group is deleted when its TCP connection terminates.
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 are
generated when, respsectively, the tn3270eRtDataEntry is created and
deleted. If, in addition, this tn3270eRtCollCtlType object's
average(3) bit is set to 1, then the the tn3270eRtExceeded and
tn3270eRtOkay notifications are generated when the conditions they
report occur.
The following notifications are defined by this MIB:
o tn3270eRtExceeded - The purpose of this notification is to
signal that a performance problem has been detected. If
average(3) response time data is being collected, then this
notification is generated whenever (1) an average response
time is first found, on a collection interval boundary, to
have exceeded the high threshold tn3270eRtCollCtlThreshHigh
specified for the client group, AND (2) the sample on which the
average is based is determined to have been a significant one,
via the significance algorithm described earlier. This
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 occured for the entry.
o tn3270eRtOkay - The purpose of this notification is to signal
that a previously reported performance problem has been
resolved. If average(3) response time data is being collected,
then this notification is generated whenever (1) a
tn3270eRtExceeded notification has already been generated, AND
Expires March 1998 [Page 23]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
(2) an average response time is first found, on a collection
interval boundary, to have fallen below the low threshold
tn3270eRtCollCtlThreshLow specified for the client group.
This 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.
Taken together, the two preceding notifications serve to minimize the
generation of an excessive number of traps in the case of an average
response time that oscillates about its high threshold.
o tn3270eRtCollStart - This notification is generated whenever
data collection begins for a client group, or when a new
tn3270eRtDataEntry becomes active. The primary purpose of
this notification is signal to a management application that
a new client TCP session has been established, and to provide
the IP-to-resource mapping for the session. This notification
is not critical when average(3) data collection is not being
performed for the client group.
o tn3270eRtCollEnd - This notification is generated whenever
a data collection ends. For an aggregate collection, this
occurs when the corresponding tn3270eRtCollCtlEntry is
deleted. For an individual collection, this occurs either
when the tn3270eRtCollCtlEntry is deleted, or when the
client's TCP connection terminates. The purpose of this
notification is to enable a management application to
complete a monitoring function that it was performing, by
returning final values for the collection's data objects.
5. Definitions
TN3270E-RT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
experimental, Counter32, BITS, Unsigned32,
Gauge32
FROM SNMPv2-SMI
RowStatus, DateAndTime, TimeStamp
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
Tn3270eAddrType, Tn3270eTAddress, tn3270eSrvrConfIndex,
tn3270eResMapElementName, tn3270eResMapElementType
FROM TN3270E-MIB
Expires March 1998 [Page 24]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
Utf8String
FROM SYSAPPL-MIB;
tn3270eRtMIB MODULE-IDENTITY
LAST-UPDATED "9709240000Z" -- September 24, 1997
ORGANIZATION "TN3270E Working Group"
CONTACT-INFO
"Kenneth White (kennethw@vnet.ibm.com)
IBM Corp. - Dept. BRQA/Bldg. 503/C117
P.O. Box 12195
3039 Cornwallis
RTP, NC 27709-2195
(919) 254-0102
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-7507"
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."
::= { experimental 81 }
-- 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, imported from
the TN3270E-MIB, and by tn3270eRtCollCtlClientGroupName.
Expires March 1998 [Page 25]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
tn3270eSrvrConfIndex indicates within a host which TN3270E
server an entry applied to.
tn3270eRtCollCtlClientGroupName is equivalent to the
tn3270eClientGroupName index in the TN3270E-MIB; it identifies
the collection of IP clients for which response time data
is being collectedr. The particular IP clients making up the
collection are identified in the tn3270eClientGroupTable in
the TN3270E-MIB."
::= { tn3270eRtObjects 1}
tn3270eRtCollCtlEntry OBJECT-TYPE
SYNTAX Tn3270eRtCollCtlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"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
tn3270eRtCollCtlClientGroupName } -- What to collect on
::= { tn3270eRtCollCtlTable 1 }
Tn3270eRtCollCtlEntry ::= SEQUENCE {
tn3270eRtCollCtlClientGroupName Utf8String,
tn3270eRtCollCtlType BITS,
tn3270eRtCollCtlSPeriod Unsigned32,
tn3270eRtCollCtlSPMult Unsigned32,
tn3270eRtCollCtlThreshHigh Unsigned32,
tn3270eRtCollCtlThreshLow Unsigned32,
tn3270eRtCollCtlIdleRate Unsigned32,
tn3270eRtCollCtlBucketBndry1 Unsigned32,
tn3270eRtCollCtlBucketBndry2 Unsigned32,
tn3270eRtCollCtlBucketBndry3 Unsigned32,
tn3270eRtCollCtlBucketBndry4 Unsigned32,
tn3270eRtCollCtlRowStatus RowStatus }
tn3270eRtCollCtlClientGroupName OBJECT-TYPE
SYNTAX Utf8String (SIZE(1..24))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The name of a client group. Membership in a client group is
specified via the TN3270E-MIB's tn3270eClientGroupTable.
The index for that table, tn3270eClientGroupName, is
equivalent to this object; it was not imported because
Expires March 1998 [Page 26]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
doing so results in MIB compiler errors."
::= { tn3270eRtCollCtlEntry 1 }
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
tn3270eRtDataBucketBndry objects.
traps(5) - generate the traps specified in this
MIB module. The tn3270eRtExceeded and
tn3270eRtOkay are generated only if
average(3) is also specified."
::= { tn3270eRtCollCtlEntry 2 }
tn3270eRtCollCtlSPeriod OBJECT-TYPE
SYNTAX Unsigned32 -- 15 second minimum to 24 hour max
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
Expires March 1998 [Page 27]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
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 -- should be > 1
UNITS "count"
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.
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 }
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."
::= { 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
Expires March 1998 [Page 28]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
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."
::= { tn3270eRtCollCtlEntry 6 }
tn3270eRtCollCtlIdleRate OBJECT-TYPE
SYNTAX Unsigned32
UNITS "transaction count"
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:
AvgTransCount * ((AvgRt/ThreshHigh - 1) ** 2) < IdleRate
This comparison is done only if the corresponding
tn3270eRtCollCtlType has average(3) and traps(5) selected."
DEFVAL { 1 }
::= { tn3270eRtCollCtlEntry 7 }
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 Tn3270eRtDataBucket1 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 Tn3270eRtDataBucket2
object: those greater than the value of the
Expires March 1998 [Page 29]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
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 Tn3270eRtDataBucket3
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 Tn3270eRtDataBucket4
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 Tn3270eRtDataBucket5 object:
those greater than the value of this object."
DEFVAL { 100 }
::= { tn3270eRtCollCtlEntry 11 }
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
Expires March 1998 [Page 30]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
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
"An entry in this table is created based upon the
tn3270eRtCollCtlTable. A single entry is created with a
tn3270eRtDataClientAddrType of 'unknown(0)' and a null octet
string value for tn3270eRtDataClientAddress when the
corresponding tn3270eRtCollCtlType has aggregate(0) specified.
When aggregate(0) is not specified, then a separate entry is
created for each client.
Note that the following objects defined within an
entry in this table can wrap:
tn3270eRtDataTotalRt
tn3270eRtDataTotalIpRt
tn3270eRtDataTransCount
tn3270eRtDataDrCount
tn3270eRtDataElapsRnTrpSq
tn3270eRtDataElapsIpRtSq
tn3270eRtDataBucket1
tn3270eRtDataBucket2
tn3270eRtDataBucket3
tn3270eRtDataBucket4
tn3270eRtDataBucket5"
INDEX {
tn3270eSrvrConfIndex, -- Server's local index
tn3270eRtCollCtlClientGroupName, -- Target of data collection
tn3270eRtDataClientAddrType,
tn3270eRtDataClientAddress }
::= { tn3270eRtDataTable 1 }
Expires March 1998 [Page 31]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
Tn3270eRtDataEntry ::= SEQUENCE {
tn3270eRtDataClientAddrType Tn3270eAddrType,
tn3270eRtDataClientAddress Tn3270eTAddress,
tn3270eRtDataDiscontinuityTime TimeStamp,
tn3270eRtDataAvgRt Gauge32,
tn3270eRtDataAvgIpRt Gauge32,
tn3270eRtDataAvgTransCount Counter32,
tn3270eRtDataIntTimeStamp DateAndTime,
tn3270eRtDataTotalRt Counter32,
tn3270eRtDataTotalIpRt Counter32,
tn3270eRtDataTransCount Counter32,
tn3270eRtDataDrCount Counter32,
tn3270eRtDataElapsRndTrpSq Unsigned32,
tn3270eRtDataElapsIpRtSq Unsigned32,
tn3270eRtDataBucket1 Counter32,
tn3270eRtDataBucket2 Counter32,
tn3270eRtDataBucket3 Counter32,
tn3270eRtDataBucket4 Counter32,
tn3270eRtDataBucket5 Counter32
}
tn3270eRtDataClientAddrType OBJECT-TYPE
SYNTAX Tn3270eAddrType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicates the type of address that following in the
instance OID represented by tn3270eRtDataClientAddress."
::= { tn3270eRtDataEntry 1 }
tn3270eRtDataClientAddress OBJECT-TYPE
SYNTAX Tn3270eTAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Contains the IP address of the TN3270 client being
monitored. A null octet string is used if the aggregate
of the Client Group is being collected "
::= { tn3270eRtDataEntry 2 }
tn3270eRtDataDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at
which any one or more of this entry's objects
suffered a discontinuity. One possibility of this is
Expires March 1998 [Page 32]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
when a TN3270E Server is stopped and then restarted
where local methods are used to setup collection
policy (tn3270eRtCollCtlTable entries).
In order to prevent a TN3270E Server from caching this
object it is recommended that the TN3270E Server's
startup time be used as the objects initial value."
::= { tn3270eRtDataEntry 3 }
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 }
tn3270eRtDataAvgTransCount OBJECT-TYPE
SYNTAX Counter32
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
tn3270eRtDataTransCount object."
::= { tn3270eRtDataEntry 6 }
tn3270eRtDataIntTimeStamp OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Expires March 1998 [Page 33]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
"The date and time of the last interval that tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt, and tn3270eRtDataAvgTransCount were
calculated."
::= { tn3270eRtDataEntry 7 }
tn3270eRtDataTotalRt OBJECT-TYPE
SYNTAX Counter32
UNITS "tenths of seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total response time collected."
::= { tn3270eRtDataEntry 8 }
tn3270eRtDataTotalIpRt OBJECT-TYPE
SYNTAX Counter32
UNITS "tenths of seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total IP-network response time collected."
::= { tn3270eRtDataEntry 9 }
tn3270eRtDataTransCount OBJECT-TYPE
SYNTAX Counter32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of transactions detected."
::= { tn3270eRtDataEntry 10 }
tn3270eRtDataDrCount OBJECT-TYPE
SYNTAX Counter32
UNITS "transactions"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the total number of definite responses detected."
::= { tn3270eRtDataEntry 11 }
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. A sum of the
Expires March 1998 [Page 34]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
squares is keep in order to calculate 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. A sum of
the squares is keep in order to calculate a variance."
DEFVAL { 0 }
::= { tn3270eRtDataEntry 13 }
tn3270eRtDataBucket1 OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the response times falling into bucket 1."
::= { tn3270eRtDataEntry 14 }
tn3270eRtDataBucket2 OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the response times falling into bucket 2."
::= { tn3270eRtDataEntry 15 }
tn3270eRtDataBucket3 OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the response times falling into bucket 3."
::= { tn3270eRtDataEntry 16 }
tn3270eRtDataBucket4 OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the response times falling into bucket 4."
::= { tn3270eRtDataEntry 17 }
tn3270eRtDataBucket5 OBJECT-TYPE
Expires March 1998 [Page 35]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of the response times falling into bucket 5."
::= { tn3270eRtDataEntry 18 }
-- Notifications
tn3270eRtExceeded NOTIFICATION-TYPE
OBJECTS {
tn3270eSrvrConfIndex, -- server's local index
tn3270eRtCollCtlClientGroupName, -- target of data collection
tn3270eRtDataClientAddrType,
tn3270eRtDataClientAddress,
tn3270eRtDataIntTimeStamp,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgTransCount
}
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, tn3270eRtDataAvgTransCount,
tn3270eRtCollCtlThreshHigh and tn3270eRtDataAvgRt are
algorithmically compared to tn3270eRtCollCtlIdleRate for
determination if this will be suppressed."
::= { tn3270eRtNotifications 1 }
tn3270eRtOkay NOTIFICATION-TYPE
OBJECTS {
tn3270eSrvrConfIndex, -- server's local index
tn3270eRtCollCtlClientGroupName, -- target of data collection
tn3270eRtDataClientAddrType,
tn3270eRtDataClientAddress,-- IP Address or null octet string
tn3270eRtDataIntTimeStamp,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgTransCount
}
STATUS current
DESCRIPTION
"This notification is generated when the average response time,
Expires March 1998 [Page 36]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
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 {
tn3270eSrvrConfIndex, -- server's local index
tn3270eRtCollCtlClientGroupName, -- Data collection target
tn3270eRtDataClientAddrType,
tn3270eRtDataClientAddress, -- IP Address or null octet string
tn3270eResMapElementName, -- IDs LU or printer association
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. The objects
tn3270eResMapElementName and tn3270eResMapElementType contains
valid values only if tn3270eRtDataClientAddress contains a
valid IP address (rather than the null octet string)."
::= { tn3270eRtNotifications 3 }
tn3270eRtCollEnd NOTIFICATION-TYPE
OBJECTS {
tn3270eSrvrConfIndex, -- server's local index
tn3270eRtCollCtlClientGroupName, -- data collection target
tn3270eRtDataClientAddrType,
tn3270eRtDataClientAddress,
tn3270eRtDataDiscontinuityTime,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgTransCount,
tn3270eRtDataIntTimeStamp,
tn3270eRtDataTotalRt,
tn3270eRtDataTotalIpRt,
tn3270eRtDataTransCount,
tn3270eRtDataDrCount,
tn3270eRtDataElapsRndTrpSq,
tn3270eRtDataElapsIpRtSq,
tn3270eRtDataBucket1,
tn3270eRtDataBucket2,
tn3270eRtDataBucket3,
Expires March 1998 [Page 37]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
tn3270eRtDataBucket4,
tn3270eRtDataBucket5
}
STATUS current
DESCRIPTION
"This notification is generated when a tn3270eRtDataEntry is
deleted after being active (actual data collected), in order to
enable a management application monitoring a tn3270eRtDataTable
entry to end 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 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."
::= {tn3270eRtCompliances 1 }
-- Group definitions
tn3270eRtGroup OBJECT-GROUP
OBJECTS {
tn3270eRtCollCtlType,
tn3270eRtCollCtlSPeriod,
tn3270eRtCollCtlSPMult,
tn3270eRtCollCtlThreshHigh,
tn3270eRtCollCtlThreshLow,
tn3270eRtCollCtlIdleRate,
tn3270eRtCollCtlBucketBndry1,
tn3270eRtCollCtlBucketBndry2,
tn3270eRtCollCtlBucketBndry3,
Expires March 1998 [Page 38]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
tn3270eRtCollCtlBucketBndry4,
tn3270eRtCollCtlRowStatus,
tn3270eRtDataDiscontinuityTime,
tn3270eRtDataAvgRt,
tn3270eRtDataAvgIpRt,
tn3270eRtDataAvgTransCount,
tn3270eRtDataIntTimeStamp,
tn3270eRtDataTotalRt,
tn3270eRtDataTotalIpRt,
tn3270eRtDataTransCount,
tn3270eRtDataDrCount,
tn3270eRtDataElapsRndTrpSq,
tn3270eRtDataElapsIpRtSq,
tn3270eRtDataBucket1,
tn3270eRtDataBucket2,
tn3270eRtDataBucket3,
tn3270eRtDataBucket4,
tn3270eRtDataBucket5 }
STATUS current
DESCRIPTION
"This group is mandatory for all host supporting the
TN3270E-RT-MIB. "
::= { tn3270eRtGroups 1 }
tn3270eRtNotGroup NOTIFICATION-GROUP
NOTIFICATIONS {
tn3270eRtExceeded,
tn3270eRtOkay,
tn3270eRtCollStart,
tn3270eRtCollEnd
}
STATUS current
DESCRIPTION
"The notifications which must be supported when the
TN3270E-RT-MIB is implemented. "
::= { tn3270eRtGroups 2 }
END
6. Security Considerations
Certain management information defined in this MIB may be considered
sensitive in some network environments. Therefore, authentication of
received SNMP requests and controlled access to management information
should be employed in such environments. The method for this
authentication is a function of the SNMP Administrative Framework, and
has not been expanded by this MIB.
Expires March 1998 [Page 39]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
Several objects in this MIB allow write access or provide for remote
creation. Allowing this support in a non-secure environment can have a
negative effect on network operations. It is recommended that
implementers seriously consider whether set operations should be
allowed without providing, at a minimum, authentication of request
origin. It it recommended that without such support that the following
objects be implemented as read-only:
o tn3270eRtCollCtlType
o tn3270eRtCollSPeriod
o tn3270eRtCollSPMult
o tn3270eRtCollCtlThreshHigh
o tn3270eRtCollCtlThreshLow
o tn3270eRtCollCtlIdleRate
o tn3270eRtCollCtlBucketBndry1
o tn3270eRtCollCtlBucketBndry2
o tn3270eRtCollCtlBucketBndry3
o tn3270eRtCollCtlBucketBndry4
The following object should either be implemented as read-only or not
implemented when security is an issue as previously discussed:
o tn3270eRtCollCtlRowStatus
The administrative method to use to create and manage the
tn3270eRtCollCtlTable when SET support is not allowed is outside of
the scope of this memo.
7. Acknowledgments
This document is a product of the TN3270E Working Group. Special
thanks is due to Derek Bolton and Michael Boe of Cisco Systems for
their numerous comments and suggestions for improving the structure of
this MIB.
8. References
[1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Waldbusser S., "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[2] Network Working Group, Postel, J., and Reynolds, J., "Telnet
Protocol Specification", RFC 854, May 1983.
Expires March 1998 [Page 40]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
[3] Network Working Group, Postel, J., and Reynolds, J., "Telnet Timing
Mark Option", RFC 860, May 1983.
[4] Network Working Group and Rekhter J., "Telnet 3270 Regime Option",
RFC 1041, January 1988.
[5] McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[6] SNMPv2 Working Group, 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] SNMPv2 Working Group, 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.
[8] SNMPv2 Working Group, 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.
[9] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[10] IETF TN3270E Working Group and White, K., "Base Definitions of
Managed Objects for TN3270E Using SMIv2", Internet-Draft Work in
progress, June 1997.
[11] Network Working Group, and Kelly, B., "TN3270 Enhancements", RFC
1647, July 1994.
[12] IBM, International Technical Support Centers, "Response Time Data
Gathering", GG24-3212-01, November 1990.
[13] Krupczak, Cheryl, Saperia, Jonathan, "Definitions of System-Level
Expires March 1998 [Page 41]~
White, Moore TN3270E Response Time Collection MIB 29 September 1997
Managed Objects for Applications", April 15, 1997.
9. Authors' Addresses
Kenneth D. White
Dept. BRQA/Bldg. 503/C117
IBM Corporation
P.O.Box 12195
3039 Cornwallis
Research Triangle Park, NC 27709, USA
Phone: +1-919-254-0102
E-mail: 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
E-mail: remoore@us.ibm.com
Expires March 1998 [Page 42]~
