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

From: Robert Moore <[email-masked]>
Date: Thu, 8 Jan 1998 10:24:06 -0500

Barry,

You've raised a couple of points that I'd like to respond to:

1. Consistency of indexing with other SNA MIBs:

The current indexing is consistent with all the "modern-era" MIBs
that have come out of the SNA NAU MIB WG.  RFC 1666, from August
1994, represents an earlier approach to indexing tables of SNA
resources.  All the subsequent MIBs produced by the WG index
tables of SNA resources by SNA name.  These MIBs include:

   - the APPC MIB (RFC 2051)
   - the APPN MIB (RFC 2155)
   - the DLUR MIB (RFC 2232)
   - the HPR MIB (RFC 2238)
   - the EBN MIB (still an Internet-Draft)

The motivation for the change in approach is that SNA resources
are invariably known by their 3-to-17 character SNA names in the
SNA network.  Thus the only way for a management application to
gain immediate access to information about a SNA resource it's
concerned with is to index the associated MIB table with the SNA
name.

The strong consensus for this change in the SNA NAU MIB WG included
several people from Cisco.

2. What to do if the VTAM LU name is not available:

First, it is possible to set things up so that a SLU name from VTAM
is always available.  I had written the following text earlier, for
inclusion in a companion informational RFC we're planning to write
on how to use the TN3270E MIBs.  Based on your comment, however, I'm
now inclined to go ahead and include this text in section 3.3.1 of
the tn32703-mib RFC.

*********************************************************************
A TN3270E server provides a client with access to an SNA application
by associating a TCP connection from the client with an SNA secondary
LU (SLU) at the server.  This SLU in turn has an SNA session with a
primary LU (PLU) running on an SNA host.  This PLU represents the
application with which the client is communicating.  The TN3270E-MIB
includes two tables for mapping back and forth between the SNA name
identifying the PLU, the SNA name identifying the SLU, and the TCP
connection with the client.

In order to understand how these name mappings work, it is necessary
to understand a subtlety involving the names of the SLUs at the
TN3270E server:  these names are often different from the names by
which the SLUs are known in the rest of the SNA network.  In the MIB
these two types of SLU names are termed "local names" and
"SSCP-supplied names"; the latter term indicates that the name by
which the SLU is known in the SNA network comes to the TN3270E
server from the SNA System Services Control Point, i.e., from VTAM.

VTAM doesn't always send SLU names down to the secondary LUs -- this
capability must be turned on.  In the case of SLUs served by a
Dependent LU Requester (DLUR), the capability is always turned on.
For those associated with an SNA type 2.0 node (or with a boundary
function-attached type 2.1 node), however, inclusion of SLU names on
ACTLU must be enabled explicitly at VTAM, by including the keyword
"INCLUDE0E" on the PU definition for the type 2.0 node
*********************************************************************

This said, there's still the question of what an agent should do if
the customer fails to turn this option on in VTAM.  It needs to be
stated explicitly, but I think the only reasonable behavior for an
agent is not to create an entry in the table at all if there's no
SSCP-supplied name available on ACTLU.  The alternatives would be
to "pretend" that the local LU name is the SSCP-supplied name, or
to use the zero-length string as the index.  Note that the last of
these choices would yield a single-row table, where the values for
the local name and possibly the PluName objects kept changing.

Thanks again for your review and comments.

Regards,
Bob Moore (chair, SNA NAU MIB WG)
IBM Networking Software
+1-919-254-4436

---

From: Michael Boe <[email-masked]>
Date: Fri, 9 Jan 1998 11:23:55 +1100 (EST)

[snip]

Bob,

> "INCLUDE0E" on the PU definition for the type 2.0 node

I've not seen this documented anywhere....what's the story? Is it currently
documented somewhere?  If not, when (if ever) will it appear in documentation?
Can you make a guess as which versions of VTAM (MVS & VM) it first appeared?

We're trying to figure out how we server vendors can lean on this feature.

thanks,
/msb