none
Significance of LU name RRS feed

  • Question

  • Hi All,

           I need clarifications on the LU Naming convention. I know that the PU name should be different for different connections and I hope that they are identified in the network routers and the mainframes using the same name.

          But I am not sure if this is the same case for LU Names. As an LU is part of a PU, I am wondering if it will cause any issue if I use the same LU Names under different PU names. I hope in that way they will be unique.

          For ex. PU Name = ABCD001 LU Name = LUABC001

                     PU Name = EFGH001 LU Name = LUABC001

          Kindly let me know if this will result in any conflict in the configuration. Also Is the LU Naming used in any of the Network routers or the Mainframe?

          These may be basic questions but I am new to HIS and would like to be sure about things before I finalise them.

          Thank you in advance.

    Regards,

    Kumaran R

    Friday, July 16, 2010 1:32 AM

Answers

  •  Kumaran,
     
     An LU name needs to be, I think, unique within an SNA subdomain.  But the actual LU name isn't used, for LU2 anyway, when connecting to the mainframe.
     
     Every LU(2) name is really an alias for the LU number on the PU.  So the LU's may be numbers 1-254 say (something like that) on the PU.
     
     >        I need clarifications on the LU Naming convention. I know that the PU name should be different for different connections and I hope that they are identified in the network routers and the mainframes using the same
    name.
    >
    >       But I am not sure if this is the same case for LU Names. As an LU is part of a PU, I am wondering if it will cause any issue if I use the same LU Names under different PU names. I hope in that way they will be unique.
    >
    >       For ex. PU Name = ABCD001 LU Name = LUABC001
    >
    >                  PU Name = EFGH001 LU Name = LUABC001
    >
    >       Kindly let me know if this will result in any conflict in the configuration. Also Is the LU Naming used in any of the Network routers or the Mainframe?
    >
    >       These may be basic questions but I am new to HIS and would like to be sure about things before I finalise them.
    >
    >       Thank you in advance.
    >
    > Regards,
    >
    > Kumaran R
     
     
     
     

    Neil Pike
    Sunday, July 25, 2010 12:32 PM

All replies

  • To all the "usual suspects"
     
    Later in this reply to Kumaran, I need to appeal to the HIS specialists.
     
    Kumaran
     
    Note that I am providing answers here as something of a specialist in SNA and VTAM and not in any aspect of HIS other than the structure of HIS when used with the "IP-DLC Link Service" - which latter aspect may or may not be of any relevance here.
     
    > I need clarifications on the LU Naming convention.
     
    Within the actual SNA network[1], the naming convention is simple and rigid: all names of network accessible (formerly addressable[2]) units (NAUs) must be unique. In subarea SNA NAUs are LUs, PUs and SSCPs.
     
    A single System Services Control Point (SSCP) is a NAU residing in a type 5 node (VTAM and, in the long distant past, TCAM). The single PU is a NAU residing in a type 5 node, a type 4 node (NCP) or a type 2.0 node (distributed business machines in the past or today but not upgraded to LEN/APPN level). One or more LUs reside in any of the node types mentioned so far (although not ever implemented directly within a type 4 node) and additionally in a type 2.1 node, the type of node used exclusively by Low Entry Networking (LEN) and APPN SNA.[3]
     
    > I know that the PU name should be different for different connections and I hope that they are identified in the network routers and the mainframes using the same name.
     
    On whatever education course you received this knowledge, you should demand a refund and demand more for wasting your time! The only bit that is vaguely and only possibly correct is that "the PU name should be different".
     
    You may like to explain to what sort of "PU name" you are referring here. The name of the SNA PU entity to which I refer above must follow the rules I explained above. That SNA PU entity is associated with a "connection" only indirectly as a feature of the PU statement within VTAM. This PU statement was originally designed in order to provide parameters for the adjacent link station when the only sort of adjacent link station which existed was the one defined for the subarea boundary function in NCP (later also VTAM) supporting an originally type 2 (later type 2.0) - aka peripheral - node. The fact that the PU statement, really describing parameters for the adjacent link station, has continued to be used by VTAM (and NCP) in many contexts, first in the case of NCP to NCP connections where the confusion was that many PU statements seemed to relate to just one PU - when I first noticed the damage this "reuse" was doing to the ability to comprehend VTAM/NCP structures[4] - and eventually to the case of type 2.1 nodes where there need be no SNA PU entity present and, if there is a PU entity present, it is only because the type 2.1 node additionally supports the functions of the type 2.0 node.
     
    Probably somewhere in the paragraph above is the source of some of the confusion shown in this post.
     
    -
     
    You appear to think that the LU name is "qualified" by the PU name. No!
     
    You are right in imagining that it might be possible to "qualify" the LU name within an SNA network. Different enterprises with different "naming authority" centres have wanted - and still want - to intercommunicate with their SNA networks. Obviously uniqueness of LU names, the names used in order to establish SNA sessions, needs to be guaranteed. Uniqueness is guaranteed by having a "network identifier" (NetId) which may be used to "qualify" LU names. Thus for the LU, you will find reference to the "fully-qualified" (FQ) name which is the NetId concatenated to a "full stop" - known as a "period" in some jurisdictions! - or "point final" where I happen to be writing - ".", concatenated to the LU name - which leads to the curious "17" as the number of places available in some entry fields where an FQ LU name may be entered, 8+1+8.
     
    With regard to the idea that the LU name could be "qualified" by the PU name, you must reflect that the LU may need to be activated by an SSCP, the SSCP-dependent LU, or it may not, the SSCP-independent LU. Only in the case of the SSCP-dependent LU will there also be a PU, necessarily an SSCP-dependent PU - as all PUs in any type of node are. Thus the idea that an LU name is "qualified" by the PU name is shown not to be a viable architectural choice.
     
    -
     
    > Also Is the LU Naming used in any of ... the Mainframe?
     
    It appears you are interested in the LU name as it appears in HIS typically in instances of HIS GUIs I expect.[See 1] All I have been describing refers to the LU name in the real SNA network which includes VTAM (your "mainframe"). For information on whether or not any LU name used within HIS is used in the real SNA network, you will need to get help from the HIS specialists.
     
    You hinge your query on the availability of a PU name which appears to suggest that you are interested in SSCP-dependent LUs. Note that this implies that HIS is behaving as a type 2.0 node (more strictly a type 2.1 node incorporating type 2.0 node function). In this case the actual SSCP-dependent LU (and SSCP-dependent PU) names used within the real SNA network need not be "visible" to the HIS implementation of the type 2.0 peripheral node - historically they never were. The identification of the SNA SSCP-dependent entities has been numbers contained with the transmission header (TH) which are unique only over the connection to the boundary function where they were converted to numbers unique with the SNA network as circumscribed by the applicable NetId.
     
    The case of the SSCP-independent LU, also supported by HIS, is different. Here the name should always be entered as an FQ LU name since the HIS node is responsible for initiating setting up any session and the partner LU name should also be defined as an FQ LU name. In other words, the LU name for an SSCP-independent LU as defined within HIS is indeed the LU name used within the real SNA network.
     
    > Also Is the LU Naming used in any of the Network routers ...?
     
    In principle, in the case of SSCP-independent LU names, yes. However, please explain what you mean by "Network routers". If the "routers" are SNA nodes, the names will be "seen" as they pass by when a session is being established as long as they are using "intermediate session routing" (ISR) or are a "rapid transport protocol" (RTP) end point. If the "router" is performing the role of "automatic network routing" (ANR), a "passing" LU name will not be "seen".
     
    But this may well all be gobbledegook to you because the "router" you have in mind is an IP protocol router. In this case, the "router" has no interest whatsoever at all in this world over any strange beings which may happen to be called "LU"!
     
    Chris Mason
     
    [1] Note that I used the initial qualifying phrase, since I am aware that the concept of an LU name may have some significance in HIS and may not necessarily match one-for-one with the LU name as used within the real SNA network of which the VTAM SNA node (your "mainframe") to which the HIS node is connected is a part.
     
    [2] The terminology was changed with the introduction of APPN SNA.
     
    [3] There is also the control point (CP) but this is merely a required LU always resident in a type 2.1 node in order to provide operational management services. This LU, possibly called the CP LU, performs these operational management services only when using specific SNA mode names and can be used as a "business" LU when using other mode names. You will find unnecessarily complicated descriptions of the CP in architecture documents[5] and even unnecessarily complicated architecture in order to deal with a single, albeit important, exception to this multiple use in the case of VTAM.
     
    [4] I remember the day I noticed this development calumny staring at an NCP manual and I reflected that it's always cheaper to reuse a statement than create another one even if the cost to users is actually enormous!
     
    [5] For example, "Inside APPN and HPR - The Essential Guide to New SNA".
     
    Friday, July 16, 2010 5:23 PM
  • Kumaran
     
    On reflection, I managed to realise that there is a "convention" regarding LU names which you might like to adopt.
     
    Assuming the LU names which concern you - as seems likely from your post - are those defined somewhere within HIS corresponding to SNA SSCP-dependent LU entities, there is a "convention" which I believe I have seen *recommended* in actually the old HIS newsgroup which you might like to apply. Note that this is a *recommendation*, rather than a technical requirement in order to make it all work.
     
    As I mentioned in my previous post, there is a number which is passed in the transmission header (TH) of all traffic applying to a particular SSCP-dependent LU following the architecture of the peripheral type 2.0 node. This number is called the "local address" being in fact the address number to which I just referred which is local" to the connection between the peripheral node and the subarea node boundary function.
     
    This number, 1 to 255, is the number specified on the LOCADDR operand of the LU statement within VTAM, I'm sure that somewhere in the definition of the SSCP-dependent LU within HIS, there will be a GUI field where this number is specified if indeed you cannot define it with some sort of "flat file".
     
    There is a name on the LU statement in VTAM - which has the LOCADDR=n operand - which provides the LU name used within the SNA network - qualified with the applicable "network identifier" (NetId) where necessary.
     
    There would appear to be a name within the definition structures within HIS which provides an LU name - associated with a "local address" = n - where the LU name is of relevance solely within HIS.
     
    It makes sense to arrange that these two LU names are the same so that, if VTAM-oriented folk want to talk about the LU by name with HIS-oriented folk, they end up using the same language, as it were!
     
    There's your "convention" for SSCP-dependent LU names within HIS.
     
    I believe I've seen a more advanced way of dealing with this matter. VTAM supports a function together with HIS, the "dynamic definition of dependent LUs", which allows HIS dynamically to specify SSCP-dependent LUs which have been defined to it and which VTAM can then also dynamically define - although there's nothing to stop the definitions being dynamic in HIS and static in VTAM.[1] In both cases, VTAM and HIS, there is a common algorithm for creating the LU name based on the "local address". If both the VTAM administrator and the HIS administrator agree on a common "seed" for the algorithm, the LU names within HIS and VTAM for the dynamically created definition entities will be the same - and a common language will be in place.
     
    -
     
    I thought additionally there might be yet another point you might like to know about regarding the "PU names" you
     
    mentioned. Possibly there could be a matching of "PU names" as well as matching of LU names as I described above. However it is a requirement here that you should actually be able to specify the various types of "PU name" in the HIS configuration. It seems, possibly depending on your "link service", that HIS picks the names of some resources "out of a hat" in order to relieve you of the bother. What this kind assistance in "definition reduction" does however, is remove the function I thought might be of interest - tant pis!
     
    I don't know where your "different" "PU names" come from. Having checked on how "PU names" are specified within HIS, as far as I can see it is going to be inevitable that the "PU names" dynamically created by HIS - although sometimes entirely correctly described as "link station" (LS) names - are going to be identical in each instance of HIS. Note that I am relying on the QRYIPDLC output in the document "Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper" for these hints over "PU names" where the first and possibly only "PU name" is "@C000001 ".
     
    -
     
    Chris Mason
     
    [1] I was going to include "static in HIS and dynamic in VTAM" but it may be a requirement that the definitions are dynamic in HIS in order to invoke the necessary additional NMVT request unit flow on the SSCP-PU session.
    Saturday, July 17, 2010 5:54 PM
  • Chris,

               Thank you for the response. I am new to SNA and HIS so I could not make out many things. The Network routers I mentioned were the DLSw routers. Yes, We are still using DLC which makes use of DLSw routers to connect to the Mainframe host via a Front End Processor.

               I am still wondering about the settings mapping between HIS and Mainframe. I am not sure if there is a One-to-One mapping between the connection settings (like PU, LU, APPC Modes) between the HIS and Mainframe hosts.

    Regards,

    Kumaran R

    Monday, July 19, 2010 3:34 AM
  • Kumaran
     
    The DLSw routers will not pay any attention to the content of the SNA frames they convert from LAN 802.2 to encapsulation in TCP and back again. Thus they will have no interest in even the numbers which indicate which session is being supported by the SNA Transmission Headers (THs) which, in turn, refer to your LUs.
     
    You need to give more details on your configuration in order to be sure what you really need to know. For example, you mention APPC modes so it might be useful to know whether the LUs you use for LU type 6.2 (APPC) sessions are SSCP-dependent or SSCP-independent.
     
    I wonder if I should have been able to guess that you were using DLSw. Strictly, the DLSw function is not "routing", it is simulating token ring segments which operate at level 2 of the OSI model rather than level 3. Thus it might have been better to have said DLSw routers in order not to cause confusion.
     
    Finally, very strictly - although I may be the only person in the list/newsgroup/whatever type of forum concerning SNA topics who worries about this misuse! - "Front End Processor" is the inappropriate terminology since, say, 3745 communication controllers are quite able to perform their function without being connected by a channel to a z Series CEC but be quite remote from it connected by some other medium.
     
    Chris Mason
    Monday, July 19, 2010 11:32 AM
  •  Kumaran,
     
     An LU name needs to be, I think, unique within an SNA subdomain.  But the actual LU name isn't used, for LU2 anyway, when connecting to the mainframe.
     
     Every LU(2) name is really an alias for the LU number on the PU.  So the LU's may be numbers 1-254 say (something like that) on the PU.
     
     >        I need clarifications on the LU Naming convention. I know that the PU name should be different for different connections and I hope that they are identified in the network routers and the mainframes using the same
    name.
    >
    >       But I am not sure if this is the same case for LU Names. As an LU is part of a PU, I am wondering if it will cause any issue if I use the same LU Names under different PU names. I hope in that way they will be unique.
    >
    >       For ex. PU Name = ABCD001 LU Name = LUABC001
    >
    >                  PU Name = EFGH001 LU Name = LUABC001
    >
    >       Kindly let me know if this will result in any conflict in the configuration. Also Is the LU Naming used in any of the Network routers or the Mainframe?
    >
    >       These may be basic questions but I am new to HIS and would like to be sure about things before I finalise them.
    >
    >       Thank you in advance.
    >
    > Regards,
    >
    > Kumaran R
     
     
     
     

    Neil Pike
    Sunday, July 25, 2010 12:32 PM
  • Neil

    Sorry for the delay. I've been taking a holiday.

    > An LU name needs to be, I think, unique within an SNA subdomain.

    Where one is obliged to assume, "SNA subdomain" includes the word "domain" as it applies to HIS. The word "domain" as it applies to SNA (and hence VTAM) refers to the resources controlled by an SSCP (subarea) or a CP LU (APPN). I'm surprised you can't be definite about the HIS requirements given that they relate directly to the question posed.

    > Every LU(2) name is really an alias for the LU number on the PU.

    This answer - I expect better expressed as "every SSCP-dependent LU" rather than the rather tentative "LU(2)" - looks to be closer to the point here. It would appear that, for convenience, the LU in the type 2(.0) peripheral node, namely HIS, is given a name which is related to the SNA name only by the - numerical - LU address carried in the transmission header.

    You just need actually to read my response to Kumaran's query in order to know that the range is 1-255, and not guess at 1-254.[1]

    What you might have picked on is perhaps to suppose that the range is 2-255. Starting at the address 2 was imposed by the initial 3274 SNA controllers.[2] It eventually became clear that LU address 1 was intended for some sort of network or configuration management role.[3]

    > But the actual LU name isn't used, for LU2 anyway, when connecting to the mainframe.

    ... in contrast to SSCP-*in*dependent LU type 6.2 where the name defined in HIS really is the name which applies throughout the SNA network, obviously including VTAM (the "mainframe"), and not just in individual domains.

    Chris Mason

    [1] Of course, you may want to challenge my assertion by mentioning that the LU address 0 can be found in the LU statement operand LOCADDR=0. This used to be a shorthand for an SSCP-independent LU before VTAM put together a better definition structure and used a CDRSC statement - with the ALSLIST operand naming one or more adjacent link stations. In order to deal with lazy system programmers, VTAM still handles LU statements with LOCADDR=0 but is obliged to convert any appearance of such an LU statement to a CDRSC with a single adjacent link station name as the value of the ALSLIST operand where the adjacent link station name is the name of the hierarchically superior PU statement. This can be verified by use of the DISPLAY NET,ID=<lu-statement-name> command.

    I even see that LOCADDR=0 is mentioned in a response to a seemingly related query. If supposed experts continue to provide LOCADDR=0 in their answers, it is no surprise that system programmers will persist in their laziness - and confusion when they discover that their LU has magically become a CDRSC!

    Note that you are probably not using APPN as it is intended to be used if you ever need to define a CDRSC statement with an ALSLIST operand and, of course, certainly not the now deprecated LU statement with the LOCADDR=0 operand. In fact, if you are using *subarea* SNA to its maximum level of flexibility, you will not even need to define a CDRSC statement with a CDRM operand. All CDRSC entities can be created dynamically.

    [2] I really can't recall whether or not the old 3271 SNA controllers imposed the address 2 as their starting address - possibly not - we're going back 30 years or so here!

    [3] LU address 1 may even have been used for a network or configuration management role at some time but the function never "caught on".
    Wednesday, August 11, 2010 12:26 AM