Subject: comments on tn3270e-mib-02, implementation issue

From: Barry Chan <[email-masked]>
Date: Tue, 30 Dec 1997 14:38:03 +1100 (EST)

Ken,
   For a server with more than a few thousand lu, to access the lu
using getnext with lu name as index will be very inefficient if the
luName has to be in lexicographically order. I cannot see it will
work unless the lu somehow is sorted in order by name. Similarly
the client address used to index the connection had to be sorted
in order. This is a too much burden to the server to support this
mib.

Barry

---

From: [email-masked]
Date: Tue, 6 Jan 98 14:11:50 EST

Barry,

>in order. This is a too much burden to the server to support this

You raise an interesting issue with respect to the structure of
(I think) the tn3270eSnaMapTable and the tn3270eTcpConnTable in
the TN3270E-MIB.  Please let me know if I've misinterpreted your
note.  The tn3270eTcpConnTable has the following index elements:

    tn3270eTcpConnRemAddrType
    tn3270eTcpConnRemAddress
    tn3270eTcpConnRemPort
    tn3270eTcpConnLocalAddrType
    tn3270eTcpConnLocalAddress
    tn3270eTcpConnLocalPort

The AddrType objects I would expect to be ipv4(1) usually. So a
GET-NEXT, for example, on tn3270eTcpConnBytesIn.1.4.171.69.176.7
should return the number of bytes received for the 1st TN3270(E)
session for 171.69.176.7 or the first entry after .1.4.171.69.176.7.
I still think that structuring the table's indexes to start with the
remote client address is very useful. Specifically for a help desk
where someone calls in and complains about their TN3270(E) session
performance.

I would expect that no matter what the order of the indexes are or
actually what they are that the table would have to be kept in
order with respect to its indexes in order for GET-NEXT to work right
at all. Doesn't the same issue arise with a GET request as well?
I don't agree that requiring lexicographical order necessarily
introduces a large burden when the number of entries exceed a
specific number or are you raising issue with the practicality of
implementing the table at all when large number of entries are expected?

Your issue is in my opinion an implementation issue not a MIB structure
one. Actual implementation of the tn3270eTcpConnTable would of
course depend on the number of entries expected. For example,
if a large number of entries is expected implement a hash table
could be created that uses the remote client address as its primary
key as oppose to using a linear search to find an entry. How any of
this is actually implemented really depends on the structure of the
server in how it keeps track of its clients.

The tn3270eSnaMapTable has the following indexes:

    tn3270eSrvrConfIndex
    tn3270eSnaMapSscpSuppliedName

tn3270eSnaMapSscpSuppliedName is a LU name. This table would have
to be kept in lexicographical order. The key here would be not to
implement the table in a manner where each GET or GET-NEXT required
the table to be built and sorted on every request. As with the
tn3270eTcpConnTable when the number of entries is expected to
exceed a specific amount then a non-linear search method would
be advised.

I have started working on your other comments along with those that
others have submitted as I revise the MIBs. Thanks for your comments
and suggestions.

Regards,

Ken

---

From: Barry Chan <[email-masked]>
Date: Wed, 7 Jan 1998 15:20:40 +1100 (EST)

Kenneth,

> to be kept in lexicographical order.

   Yes, the table has to be kept in lexicographical order using lu
name as an index. The number of search is about log2 N which is not too
bad. To support this mib, the lu needed to be sorted in order by lu name
and by ip address. I guessed most servers can cope with this overhead.
It is just two AVL trees and about extra 200K of memory.(10000 sessions).

   But one of my main concern is the lu name is VTAM lu name, the server
may not know the lu name. Another concern is that other mibs, eg
SNA-NAU-MIB (rfc1666) and IBM-APPN-DLUR mib use pu-index and locaddr.
How is this mib's lu correlate the rfc1666 lu.

   From the implementation point and easier access to other mib. I would
prefer the lu is indexed the same way rfc1666.

Barry

The key here would be not to

---

From: Robert Moore <[email-masked]>
Date: Mon, 19 Jan 1998 09:16:38 -0500

I've gotten some more information on the VTAM feature I mentioned
previously.  First, as Derek suspected, the keyword is INCLUD0E,
not INCLUDE0E as I stated earlier.  (You'd think that by now I'd
understand the fundamental law of the universe, that anything worth
saying at all can be said in 8 EBCDIC characters:-).)  With this
one-character fix, I think the text I appended earlier is correct.

The feature itself is in APAR OW25501, which went out in VTAM V4R4.
The text to describe it may not be in the VTAM manuals yet, but it
will get there eventually.  Any customer who actually installs the
support will get a pointer to enough documentation to let them make
use of it.  Really, though, there's very little to document:

  - The keyword is INCLUD0E.
  - It goes on a PU statement.
  - The values are YES and NO.
  - If it's not coded on a PU statement, it defaults to NO.

Bob Moore
IBM Networking Software
+1-919-254-4436