none
HIS and APPN Transmission group (TG) characteristics RRS feed

  • Question

  • Hi, I'm relaying a question from my APPN/VTAM colleagues... is there a way in HIS to tweak the APPN Transmission group (TG) characteristics as described here http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.znetwork/znetwork_215.htm and http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.znetwork/znetwork_216.htm

    mainly these two parameters

    CAPACITY seems to be defaulted to 100 Mega
    SECURITY seems to be defaulted to UNSECURE

    Thanks

     


    Laurent THALER
    Friday, October 1, 2010 8:39 AM

Answers

  • Laurent,

    The CAPACITY setting that you reference is the Effective Capacity setting in the IP-DLC link service as Chris mentioned. This value is hard coded in the IP-DLC link service. It was hard-coded at 94Mbit/s in HIS 2006. In HIS 2009 and HIS 2010, this was changed to be 150Mbit/s. I checked with one of the IP-DLC developers and he explained that the capacity (effective capacity) value does not have to be set to the exact maximum throughput of the link since the HPR algorithm calculates this dynamically, however it does need to be of the correct order of magnitude (within a factor of 2 or so).

    If this is something that you and your VTAM colleagues feel need to be configurable, you could open a support case with the HIS support team requesting that this be made a configurable option. The HIS Product Team would then look at the issue and decide if they would do this as a Critical Design Change Request (CDCR) to provide an update quickly based on the business justification for your situation.

    The other thing I can do is to file a regular DCR asking that this be made configurable in a future release of HIS.

    The other TG parameters like SECURITY are not relevant to HIS since the MODEs inside the LEN node component of HIS (which is the SNA Server service, snaservr.exe) do not have the capability of using these COS parameters. As Chris mentioned in his reply, HIS makes use of two nodes. The first of the SNA Server service (snaservr.exe) that provides the LEN fucntionality and the other is the APPN node that the IP-DLC link service is. This has never been a secret. <g>

    The IP-DLC white paper (one of Chris's favorites <g>) mentions this as shown here:

    LEN Node

    A LEN Node is a type 2.1 node that uses independent LU 6.2 protocols, but does not support CP-CP sessions.  It can be connected to a Network Node or End Node but does not support APPN functions.  Host Integration Server’s existing SNA node is a LEN node.

    Thanks...

     


    Stephen Jackson - MSFT
    • Marked as answer by Laurent THALER Thursday, October 7, 2010 10:17 PM
    Thursday, October 7, 2010 6:26 PM

All replies

  • Laurent
     
    I await the answer of the Microsoft gurus with great anticipation!
     
    It is well-known I have a number of difficulties principally with the way that the IP-DLC Link Service of HIS is presented in documentation. These difficulties are so extensive that some other infelicities have received less exposure- but your post highlights one of them.
     
    Your APPN/VTAM colleagues are absolutely correct in their concern to be able to specify APPN transmission group (TG) characteristics for any "transmission groups", more generally called "links". Such TG characteristics need to be specified in the definition statements covering the "adjacent link station" wherever they can be found. This means that for each TG/"link" there are two sets of TG characteristics, one set for each direction. In the case of VTAM, purely for historical reasons since there may be no actual SNA PU entity involved, this is the PU statement specified either in a Switched Major Node or a Model Major Node or created dynamically by VTAM in response to an *arriving* request to establish a "link".
     
    The document references you give are very much at an introductory level. I would prefer that you direct attention to the following "redbook":
     
    Inside APPN and HPR - The Essential Guide to New SNA[1]
     
     
    Getting back to HIS and TG characteristics, you can see that the folk who actually created the IP-DLC Link Service - which is the one to which you refer here I guess - have done a comprehensive job in terms of implementing APPN. This is evident in the "APPENDIX D - Qryipdlc (Full Log), Detailed Diagnostics for IP-DLC Link Service SNAIP1 on HISERVER" from the "Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper" document[2] and the following is what must be assumed - since there is no opportunity actually to specify them of which I am able to be aware from the document - to be the "hard-wired" TG characteristics:
     
    <quote>
     
    TG characteristics:
      Effective capacity                                    94 Mbits/s
      Connection cost                                       0
      Byte cost                                             0
      Security                                              No security
      Propagation delay                                     384 microseconds
      Modem class                                           0
      User-defined parameter 1                              128
      User-defined parameter 2                              128
      User-defined parameter 3                              128
     
    </quote>
     
    No doubt it is the fact that these TG characteristics are "hard-wired" that so appals and disturbs your APPN/VTAM colleagues.
     
    What happens when there is a choice of route, one HIS End Node (EN)[3] to Network Node (NN) (typically the one acting at the time as the Network Node Server (NNS)) to typically VTAM EN over, say, an XCF "link" - and - one HIS directly to the VTAM EN running the server application over logically a virtual node (VN)? In order to be sure that the desired route, namely the direct one, is chosen, the APPN network designer needs to be able to define TG characteristics for each direction over each TG/"link". The sad fact appears to be that the Microsoft folk responsible for what is "exposed" in the HIS GUI are unaware of this fundamental aspect of APPN network design.
     
    Since I would doubt what you require, namely the possibility actually to do what any respectable implementation of APPN would offer, the specification of TG characteristics, is going to become available tomorrow for you properly to design your APPN network, what you probably need is for the HIS gurus to let you in on the secret of what are the TG characteristics which have been assumed for the logical link between the HIS EN and any VN. A fair guess - and guesses are not a proper feature of a well-documented product - is that the same characteristics are applied as have been imposed on the TG/"link" in the direction HIS to adjacent APPN node (usually and inappropriately always described as an NNS in the HIS documentation) for the IP-DLC Link Service "links".
     
    With this assumption and with full flexibility to specify TG characteristics for all the other TG/"links" in your network - unless they involve Cisco SNASw but that's another disgraceful story and in any case probably doesn't involve the HIS nodes, you will be able to ensure that APPN route selection works as you would expect.
     
    I probably don't have to remind your perspicacious APPN/VTAM colleagues that, while they simply need to add up the weights of the TG from the HIS EN to the NN, the NN itself and the TG from the NN to the EN, in order to calculate the weight of the route over the VN, they need to add up the weight of the TG from the HIS EN to the VN, assume 0 for the weight of the VN itself and the weight of the TG from the VN to the EN, and then divide by two. The least weighted route then becomes the winner!
     
    Your colleagues may also know very well that, if any of the sets of TG characteristics remains unchanged from the defaults, the "wrong" route can easily be selected - to universal consternation!
     
    It's just possible that this consideration with its little calculation is a bit of a revelation to at least some of the Microsoft gurus!
     
    -
     
    Regarding the general point of "tweaking" TG characteristics. On the principle that, as well as non-default specifications, all relevant defaults should also explicitly be specified as a documentation aid, I used to recommend that students created TG characteristics set profile wherever necessary and associated a profile with each and every TG/"link" while, at the same time, making sure that the Class-of-Service (COS) calculation worked as expected with these definitions. Typically simply being honest about the characteristics was sufficient although, if there really were "costs", some attention needs to be given on a network-wide basis to how to scale costs in comparison with other characteristics.
     
    More recently I have taken the view that, because it is extremely unlikely that the "user" characteristics need ever be considered and actually unlikely that the "cost" characteristics need to be considered, we come down to just three characteristics - of which you mention two - to which some attention need be given, namely, "Effective capacity" ("speed"), "Security" and "Propagation delay". These may as well be specified as operands on the relevant PU statement itself as CAPACITY, SECURITY and PDELAY rather than specifying the TGP operand and possibly going to the trouble of creating a TG profile different from those supplied by VTAM. In addition, the need actually to look up the specified TG profile when reviewing TG characteristics is avoided.
     
    I expect your APPN/VTAM colleagues are specifically concerned that they cannot specify the "Effective capacity" characteristic because they are aware of the fact that this characteristic is "borrowed" by the Rapid Transport Protocol (RTP) logic in order to "seed" the algorithms governing the behaviour of the RTP logical connection. Thus it is *doubly* frustrating not actually to be in a position properly to control the performance of the APPN network because of an inexcusable oversight on the part of Microsoft!
     
    Chris Mason
     
    [1] Of course, it was some idiot "suit" who insisted on the change of title from "APPN Tutorial" with the presence of the word "new" in the title which, now 13 years on from the publishing date, reveals how stupid it was in the first place. General point: never use the word "new" in anything which you have every right to expect to last a while!
     
    [2]
     
     
    [3] Some pedants may feel inspired to point out that HIS isn't an EN but a BNN as indicated in the "APPENDIX D - Qryipdlc (Full Log), Detailed Diagnostics for IP-DLC Link Service SNAIP1 on HISERVER".
     
    <quote>
     
    Node type                                             Branch Network Node
     
    </quote>
     
    The reason that the log shows "Branch Network Node" (BNN) is because the IP-DLC Link Service was developed from BNN base software by the software house which implemented the IP-DLC Link Service for Microsoft. It is a feature which the Microsoft gurus seem hesitant ever to admit that HIS consists of two SNA node implementations, an old LEN node and a new APPN node. The IP-DLC Link Service is really the APPN node and is a BNN where the "Uplink" is the "Enterprise Extender" "link" and the "Downlink" is the internal "link" to the LEN node logic. Just take a closer look at the "Topology Information" at the end of the log.
     
    If you encounter any Microsoft documents which claim that HIS implements a Branch Network Node, such as "Deploying Microsoft Host Integration Server 2004 in a TCP/IP Wide Area Network, Microsoft Host Integration Server 2004 Technical Article, Published: August 2004", you need to treat the suggestion with the contempt it deserves. Technically it is true but mentioning the BNN supposed capability is to ascribe to HIS far more SNA capability that it actually possesses.
    Friday, October 1, 2010 12:42 PM
  • Chris,

    Thanks for your detailed answer, I need to read a few pages to go further...


    Laurent THALER
    Friday, October 1, 2010 3:18 PM
  • Laurent,

    The CAPACITY setting that you reference is the Effective Capacity setting in the IP-DLC link service as Chris mentioned. This value is hard coded in the IP-DLC link service. It was hard-coded at 94Mbit/s in HIS 2006. In HIS 2009 and HIS 2010, this was changed to be 150Mbit/s. I checked with one of the IP-DLC developers and he explained that the capacity (effective capacity) value does not have to be set to the exact maximum throughput of the link since the HPR algorithm calculates this dynamically, however it does need to be of the correct order of magnitude (within a factor of 2 or so).

    If this is something that you and your VTAM colleagues feel need to be configurable, you could open a support case with the HIS support team requesting that this be made a configurable option. The HIS Product Team would then look at the issue and decide if they would do this as a Critical Design Change Request (CDCR) to provide an update quickly based on the business justification for your situation.

    The other thing I can do is to file a regular DCR asking that this be made configurable in a future release of HIS.

    The other TG parameters like SECURITY are not relevant to HIS since the MODEs inside the LEN node component of HIS (which is the SNA Server service, snaservr.exe) do not have the capability of using these COS parameters. As Chris mentioned in his reply, HIS makes use of two nodes. The first of the SNA Server service (snaservr.exe) that provides the LEN fucntionality and the other is the APPN node that the IP-DLC link service is. This has never been a secret. <g>

    The IP-DLC white paper (one of Chris's favorites <g>) mentions this as shown here:

    LEN Node

    A LEN Node is a type 2.1 node that uses independent LU 6.2 protocols, but does not support CP-CP sessions.  It can be connected to a Network Node or End Node but does not support APPN functions.  Host Integration Server’s existing SNA node is a LEN node.

    Thanks...

     


    Stephen Jackson - MSFT
    • Marked as answer by Laurent THALER Thursday, October 7, 2010 10:17 PM
    Thursday, October 7, 2010 6:26 PM
  • Thanks, we will follow your advice.
    Laurent THALER
    Thursday, October 7, 2010 10:19 PM
  • Andrew
     
    > The other TG parameters like SECURITY are not relevant to HIS since the MODEs inside the LEN node component of
    HIS (which is the SNA Server service, snaservr.exe) do not have the capability of using these COS parameters.
     
    I am in the process of preparing a full response to what I took to be general ignorance over APPN as demonstrated in your post as a whole - but I missed this key point which I think allows you to assume that HIS in general and the "IP-DLC Link Service" in particular are absolved from needing to be bothered with all the complicated aspects of APPN regarding route selection, class of service and transmission group (TG) characteristics.
     
    I fear it won't work - your trying to dodge the issue, that is, and possibly also "IP-DLC developer" is also trying to dodge the issue. He is to some extent quite correct about the conscripted use of the "effective capacity" TG characteristic in "seeding" the HPR/RTP/ANR flow control algorithm. The order of the order of magnitude can be debated - I tend to suggest 10 rather than 2 with no particular input other than 1000 is definitely bad - but is really of no enormous concern since the algorithm is self-correcting in time. This means the "tweaking" you gave to the "hardcoded" value is quite unimportant and I'm surprised anyone bothered.
     
    If the inspiration that "TG characteristics don't matter with HIS and the IP-DLC Link Service" came from your "IP-DLC developer" then he is equally culpable with you.
     
    The quick explanation of why you are so wrong is that, assuming the network node server (NNS) is VTAM, VTAM will provide the missing COS name based on the mode name. The NNS will then apply the architected APPN route selection logic in order to create a route selection control vector (RSCV) describing the route to pass back to the HIS end node. This architected route selection logic requires that the HIS end node supplies end-node TG vectors containing the TG characteristics of the links emanating from the HIS end node from its perspective.
     
    If I knew how to hunt around inside the AS/400 documentation I'm pretty sure I would find that the AS/400 behaves in the same way as VTAM.
     
    The more extensive reply I was in the process of creating explains why it may be necessary to change the "hardcoded" TG characteristics values to which Laurent referred and, until now, I'd missed how and why you were trying to pretend they didn't matter at all - apart from the incidental use of "effective capacity" in "seeding" the HPR/RTP/ANR flow control algorithm.
     
    However until you and "IP-DLC developers" you have to hand understand and accept that the NNS actually needs and uses the TG characteristics, I will be talking to a blank wall.
     
    And, having understood and accepted, I trust the requirement that the means to specify the TG characteristics is valid becomes part of HIS/"IP-DLC Link Service" product plans without any need for any of your users to make quite inappropriate requests.
     
    How the TG characteristics are used, and why not being able to set them could cause inappropriate routes to be selected, I will be putting in a future detailed post - if I'm spared!
     
    Here's a couple of sections from the APPN Tutorial redbook - which some "suit" insisted should be renamed "Inside APPN - The Essential Guide to the Next-Generation SNA"[1] - in order to help you understand what I have been talking about:
     
    <quote>
     
    5.5 Class-of-Service Database
     
    The COS database and the class-of-service manager (COSM) exist in all APPN network nodes, and in those APPN end nodes that support the COS/TPF function. A node having the COS/TPF function is capable of translating a mode name to a COS name and an associated transmission priority.
     
    </quote>
     
    <quote>
     
    C.3.1.1 Class-of-Service Functions
     
    The COS database is an optional database as defined in the APPN end node architecture. If an EN does not support the COS/TPF (class of service / transmission priority field), then it relies on its NN server to provide a COS mapping. This mapping is done when the EN sends a request to set up a session with a resource using a certain mode name.
     
    </quote>
     
    Ideally, you should be familiar with the whole of this redbook. Even more ideally, you should have had the benefit of attending the classes I gave on APPN 15 or so years ago!
     
    > The other TG parameters like SECURITY are not relevant to HIS since the MODEs inside the LEN node component of HIS (which is the SNA Server service, snaservr.exe) do not have the capability of using these COS parameters.
     
    In the discussion until now, I sort-of interpreted this as the following:
     
    - (The other) TG parameters like SECURITY are not relevant to HIS since a MODE inside the LEN node component of HIS (...) does not have the capability of specifying a COS parameter and, consequently, COS, with its reliance on TG characteristics, also is not relevance to HIS.
     
    Actually, this doesn't make complete sense either. Let us say I interpreted it more as the following:
     
    - The LEN component of HIS specifies a MODE name but the MODE does not specify a COS name. It's the COS function which uses the TG characteristics such as SECURITY and so TG characteristics are not relevant to HIS.
     
    Ostensibly this makes sense but it falls down when, even when the end node doesn't support the COS/TPF function, its NNS will and it's the NNS which uses the TG characteristics provided by the end node in order, as the last step in the session setup flows, to provide the end node with the RSCV which needs to be packaged with the BIND request and which starts to be used when the RSCV informs the end node which link to use initially over which the BIND request is to be sent.
     
    Chris Mason
     
    Wednesday, October 20, 2010 6:07 PM
  • HIS and TGs - CAPACITY
    ======================

    What is the significance of TG characteristics to HIS?

    1. Route selection - covered in a separate post

    2. Effective capacity also used in order to “seed” the RTP flow control algorithm

    -

    2. Effective capacity also used in order to “seed” the RTP flow control algorithm
    ---------------------------------------------------------------------------------

    This is the only aspect of the request to be able to specify TG characteristics which has received any sort of acknowledgement as legitimate, even if HIS developers have decided that just one “effective capacity” value happens to match the implementation of the “IP-DLC Link Service” by every HIS customer - patently absurd!

    In the APPN tutorial redbook which goes by the unfortunate title, “Inside APPN - The Essential Guide to the Next-Generation SNA”,[1] Chapter 9, “Adaptive Rate-Based Flow/Congestion Control”, 9.3.1, “ARB Initialization”, we find the following:

    <quote>

    Maximum send rate

    This is the maximum rate at which the sender is (initially) allowed to send data. It is set to the capacity (link speed) of the slowest link on the path of the connection. This is not the maximum rate at which the sender ever is allowed to send because the system definitions for the link speeds might not reflect the actual link speed, or the accumulated bandwidth of an MLTG can change as its links are activated and deactivated.

    </quote>

    The “capacity (link speed)” is, as it were, “stolen” from a parameter which was originally intended purely as a characteristic of the transmission group (TG) for the purposes of route selection. “But, hey, it's there and it might prove useful as a starting point for the flow control algorithm.” was the thinking of the SNA/APPN/HPR architects.

    Incidentally, the MLTG, multiple-link transmission group, has never been implemented to my knowledge.

    In the redbook “VTAM V4R4 for MVS/ESA Implementation Guide”,[2] Chapter 2, “High-Performance Routing Overview”, we find the following:

    <quote>

    2.5 ARB Flow Control

    The Route Setup and its reply are used to determine the lowest capacity link on the connection; each node on the path checks the APPN CAPACITY value of the next link on the RSCV, and substitutes it into the Route Setup if it is lower than the value it finds there. It is important to get the CAPACITY values correct; if ARB is initialized with too low a value (for example, 8K instead of 32M), it can take a very long time to reach capacity and the performance gains from HPR may not be realized.

    </quote>

    This is a more precise description of what happens and contains the warning about getting the “effective capacity”, the CAPACITY operand, value wildly wrong.

    I believe there are also disadvantages, probably with unnecessarily lost traffic, associated with initialising the algorithm with too high a value. Clearly if this were not the case, there would be no need to try to find a suitable value but merely to start the algorithm with a very high value.

    What is evident from this use of the “effective capacity” TG characteristic is that it need only be in the right order of magnitude in order to initialise the flow control algorithm with a usable rate which can quickly discover the correct rate for the moment which, in any case, will fluctuate as traffic patterns change.

    Chris Mason

    [1] http://www.redbooks.ibm.com/abstracts/sg243669.html

    [2] http://www.redbooks.ibm.com/abstracts/sg242100.html
    Thursday, October 28, 2010 8:16 PM
  • HIS and NNS
    ===========

    What do the definition of two links to supposedly Network Node Servers really mean?

    -

    On the “IP-DLC Link Services Properties” page, “General” tab, there are two fields available for the purposes of identifying both the “Primary NNS” and the “Backup NNS”. What must be specified is the IP address of an IP node which is, just like HIS, supporting the end-point of an Enterprise Extender link. Thus the nodes are, in addition to being IP nodes, APPN nodes.

    At this point it is important to appreciate that, while the responsibility for the GUI very probably lies with Microsoft, the actual executing code of the “IP-DLC Link Service” is provided by a software house as a version of their APPN Branch Network Node product. This is a very reliable organisation and their product can be just about guaranteed to implement the APPN Branch Network Node architecture in full.

    Thus, quite irrespective of what may be said in the GUI prompts, unless Microsoft have imposed the introduction of some quite pointless additional programming upon the software house - massively unlikely - the behaviour observed will correspond to APPN architecture, specifically APPN Branch Network Node architecture.

    It seems that, not considering the use of “connection networks” for now, HIS limits itself to just two defined links. From the GUI prompts you may imagine - and I am about to suggest that it might be otherwise - that the partner APPN node needs to be defined as a network node (NN) and needs to be able to offer APPN network services as a network node, in other words, a network node server (NNS) services. I suspect that there are no such limitations. I suspect that the contacted node can be either an NN or an end node (EN) and that, if an NN, it need not necessarily offer APPN network services.

    Of course, it is a rule of APPN that an EN such as HIS requires to establish a link to an adjacent NN which does indeed offer APPN network services but, while, in order for the EN to initiate sessions within the APPN network, at any one time this must apply to one of the links corresponding to the GUI definition, there is absolutely no need whatsoever for it to apply to the other, which can be an EN or an NN which does not offer APPN network services.

    It's useful now to be sure exactly what is going on. It's all about a couple of bits in a message which is exchanged between SNA nodes when they make contact, the “exchange identification” (XID) “information field” message which actually is defined to belong to the “data link control” (DLC) OSI layer and so can be described as contained within a “frame”.

    Let us assume that the EN, HIS, node takes the initiative. Necessarily it states that of the two APPN capabilities, NN or EN, that it is an EN. Furthermore, another bit is set which means, madly anthropomorphising, “If I am talking to an NN, please sir, would you be so kind as to supply me with APPN network services?” We can confidently assume that the HIS EN will be making this request, rather than so setting the bit that the request is not made, or the description of the field as Primary or Backup NNS would make no sense whatsoever!

    In reply, the NN can either “say”, “If I am talking to an EN,” - of course it knows already so I am giving the general case - “I am prepared to offer you APPN network services.”[1]

    Once both sides have discovered their mutual capabilities, the link then becomes fully established and the EN can check whether or not it is already in contact with an NN which is providing APPN network services.

    If the EN is not already in contact with an NN which is providing APPN network services, the EN reviews the capabilities of the node contacted over the newly established link in order to see whether or not it is an NN and, if so, whether or not it is prepared to provide APPN network services. If the node is an NN prepared to provide APPN network services, the EN initiates the establishment of a first CP LU to CP LU session and expects a second CP LU to CP LU session to be established by the NN.

    If the EN is already in contact with an NN which is providing APPN network services, but the node just contacted is also willing to supply APPN network node services and is additionally designated as a “preferred NNS”, the EN terminates its CP LU to CP LU session, expects the NN to terminate the CP LU to CP LU session it initiated and the EN then initiates the establishment of CP LU to CP LU sessions with the newly contacted NN.[2]

    If the link between the EN and the NN over which the CP LU to CP LU sessions have been established is broken, the EN treats this event in the same way as when any link is established so that it can acquire APPN network node services from another NN.

    The NN, between which and the EN a link has been established and which happens to be providing APPN network services to the EN, is called the NNS for the period of time over which the NN is providing APPN network node services to the EN.

    Since all this is based on the dynamic detection of capabilities and the dynamic detection of the need for an EN to be supplied with APPN network services by an NN, it is rather misleading for the prompts to imply that the adjacent node indicated by the IP identification, address or name, is necessarily some sort of static NNS, there being no such thing.

    Furthermore this artificial labelling could imply that some configurations which might suit an installation are forbidden. For example, suppose an installation is quite happy to have just one NN acting as NNS but needs just one more link to run from the HIS node to some server node which could be either VTAM or an iSeries (AS/400) and, as a server node with the main purpose of running applications, this node may as well be defined as an EN. If the HIS systems programmer slavishly follows what the prompts suggest, it may not occur to him or her to set up the second link, say, to the server EN. He or she may feel that it is absolutely required that the node be defined as an NN and necessarily be capable of supplying APPN network services which just may not correspond to the design the customer had in mind initially, particularly if the server node happened to be an iSeries (AS/400).

    Because there is every likelihood that the same functions will exist in the “IP-DLC Link Service” logic as exist with other APPN node implementations from the same software house, I examined the define_ip_ls statement from the Administration Command Reference manual for the IBM Communications Server for AIX product. Specifically I was looking for any specification which might allow a parameter to be hardcoded that would require that, for a defined connection from an EN to an NN, the NN must offer to support APPN network services. There is no such parameter. While this is obviously not conclusive, it is a strong indication that (a) implying that the contacted node must be a NN could be correct since this can be required - but would, in the context of the “IP-DLC Link Service”, be a pointless restriction - but that (b) the NN must offer APPN network services would be incorrect.

    -

    Chris Mason

    -

    [1] In terms of VTAM definitions, when the CPCP parameter applying to the adjacent link station is set, actually or implicitly, to YES, APPN network services will be declared as available - if an NN, or desired, if an EN. The CPCP parameter can be specified on a static or dynamic PU statement representing the adjacent link station or, if not specified at the level of the PU statement, the value is derived from the CPCP start option.

    [2] It must be assumed that what has just been described corresponds to the behaviour performed by the “IP-DLC Link Service” logic when the “No preferred NNS” box is not “ticked”. Correspondingly, if the box is “ticked”, it is presumed to block a “switch” of NNS from “backup” to “primary”.
    Thursday, October 28, 2010 8:17 PM
  • HIS and Dynamic PUs
    ===================

    What does “Use Dynamic PU Definition” really mean?

    -

    On the “IP-DLC Link Service Properties” page, “General” tab, the set of parameters identified as the “Local APPN node” consists of the following

    - a field Network name:
    - a field Control point name:
    - a “tick-box” Use Dynamic PU Definition
    - a field Node ID:

    If the “tick-box” “Use Dynamic PU Definition” is checked, the “Node ID:” field becomes grey or ghosted.

    The first problem to get out of the way is that the “Network name” field ought to be described as the “Network identifier” in order properly to correspond with SNA terminology.

    The description of and explanation for the “tick-box” doesn't make sense.

    First of all this dialog indicates that whoever designed it understood that the three components, “network identifier”, “control  point name” and “node identifier” were required by the underlying “IP-DLC Link Service” logic in order to be able to construct an “exchange identification” (XID) “information field” message.

    It is also acceptable when particularly the “control point name” is available, as it always is in the case of the format of XID message used by APPN, format 3, that the “node identification” field need not be unique and hence need not be specified. This has nothing whatsoever in this world to do with “dynamic PU definitions”. Whether a PU statement definition is dynamic or not is unrelated to whether the “node identification” field is or is not unique. If the “node identification” field present in an arriving connection request is not unique, the VTAM systems programmer must ensure that some means, other than causing a match with a defined PU statement using the IDBLK and IDNUM operands, is used in order to select the parameters to be used by such a connection. This happens to include the use of a dynamically defined PU statement but this is by no means whatsoever required! However there is also nothing whatsoever at all to stop the VTAM systems programmer setting up the use of a dynamically defined PU statement even if the poor HIS systems programmer has gone to all the toil and trouble of dreaming up a value to use for the "Node ID" field.

    In the “Microsoft Host Integration server Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper” in the chapter “Host Integration Server Configuration”, “IP-DLC Link Service Setup”, “IP-DLC Link Service Configuration, Configuration Steps”, “Step 5c: Dynamic PU Definitions”, there is a supposed explanation of the “tick-box” as follows:

    <quote>

    New setting in HIS 2006

    The Use Dynamic PU Definition is a new configuration option in Host Integration Server 2006. This setting enables the link service to use dynamically defined PU definitions if enabled on the host.

    Regarding HIS 2004

    Note: This check box setting is not included in HIS 2004. However, you can manually enter 05D FFFFF for the Node ID, which causes the IP-DLC Link service to attempt a Dynamically created PU Definitions connection at the Host (as the “Use Dynamic PU Definition” check box in HIS 2006).

    </quote>

    The descriptions of the “Use Dynamic PU Definition” “tick-box” and “Node ID” field  under “APPENDIX C – Link and Connection References”, “USE Dynamic PU Definition / Node ID:” are as follows:

    <quote>

    Use Dynamic PU Definition

    Selecting this option allows the IP-DLC link service to attempt to use the dynamically defined PU definitions on the host.

    NODE ID:

    Typically is it recommended that the Node ID: be left as default and enabled Dynamic PU generation on the host (DynPU=Yes). However, Host Integration Server 2006 can be configured with a static PU ID. Please note: the PU definition should not have any LUs defined. IDBLK= & IDNUM= parameters in the PU Definition defined in VTAM.

    </quote>

    Comparing the images on pages 36 and 37 shows that the effect of selecting the “tick-box” is to cause the “Node ID:” field to be greyed or ghosted.

    It can be seen that the tenor of the statements quoted above is close to absolute nonsense and where not absolute nonsense, very confused regarding VTAM definitions.

    -

    The following explains how VTAM handles the arrival of a request to make a connection and, thus, what really determines “Use Dynamic PU Definition”:

    When an XID encapsulated in an SNA REQCONT request is presented to VTAM, an operand, SWNORDER, of the GROUP statement associated with the logic responsible for receiving the XID as specified, for example, in a TYPE=XCA major node, determines how a PU statement in a TYPE=SWNET major node provides parameters for the adjacent link station - and possibly a parameter - a fairly insignificant suboperand - for any associated SSCP-dependent PU entity.

    Notes:

    - SWNORDER can be specified as an operand of a GROUP statement or can be “inherited” from the start option.

    - For an XID using any format, there is always a “node identification” field with which the values of the IDBLK and IDNUM operands can be compared.

    - For a format 3 XID which is always used with nodes capable of APPN, there is always a control vector containing the fully qualified (fq) control point name with which the values of the NETID and CPNAME operands can be compared.

    1. If SWNORDER=(STATNID,...) is specified, VTAM compares the node identifier with the IDBLK and IDNUM operands

    - If found - go to 5
    - If not found
    -- If SWNORDER=(STATNID,FIRST*) - go to 3
    -- If SWNORDER=(STATNID,ONLY) - go to 6

    2. If SWNORDER=(CPNAME*,...) is specified, VTAM compares the fq control point name with the NETID and CPNAME operands**

    - If found - go to 5
    - If not found
    -- If SWNORDER=(CPNAME*,FIRST*) - go to 4
    -- If SWNORDER=(CPNAME*,ONLY) - go to 6

    3. SWNORDER=(STATNID,FIRST*) is specified, VTAM compares the fq control point name with the NETID and CPNAME operands**

    - If found - go to 5
    - If not found go to 6

    4. SWNORDER=(CPNAME*,FIRST*) is specified, VTAM compares the node identifier with the IDBLK and IDNUM operands

    - If found - go to 5
    - If not found go to 6

    5. Status of the ISTEXCCS exit:

    - Active: the result is determined completely by the exit
    - Inactive: the connection is successful

    6. Status of the ISTEXCCS exit:

    - Active: the result is determined completely by the exit
    - Inactive: go to 7

    7. DYNPU value specified on the GROUP statement associated with the logic responsible for receiving the XID:

    - DYNPU=YES (always for VN): VTAM creates a representation of a PU statement using operands as follows:

    -- If the PU statement is for Enterprise Extender link, VTAM uses operands from a DYNTYPE=EE model
    -- If the PU statement is for connection network link, VTAM uses operands from a DYNTYPE=VN model
    -- If the PU statement is for rapid transport protocol link, VTAM uses operands from a DYNTYPE=RTP model
    -- Otherwise, the default “DYNPU=YES” operands are used

    - DYNPU=NO*: the connection attempt fails

    * Default
    ** The NETID value can be inherited from the start option.

    Note that very similar logic applies for the arrival of a REQACTPU (DLUR/DLUS). The relevant start option is DLRORDER and the default value for the first suboperand is STATNID rather than CPNAME. In addition there is another possibility that, if a PU name is carried in the (simulated) XID, it may be used in order to select a PU statement rather than the IDBLK, IDNUM, NETID and CPNAME operands.

    -

    Chris Mason
    Thursday, October 28, 2010 8:19 PM
  • To all following this thread - typically any using the “IP-DLC Link Service”

    I have created 4 supplementary posts as follows:

    1. HIS and TGs - COS
    2. HIS and TGs - CAPACITY
    3. HIS and NNS
    4. HIS and Dynamic PUs

    The two posts “HIS and TGs” relate directly to the nonsense that TGs are not relevant to HIS.

    “HIS and NNS” is to suggest that the defined links need not connect to network nodes which are required to be capable of being network node servers and this relates to one of the configurations explored in the “HIS and TGs - COS” post.

    “HIS and Dynamic PUs” is just added for convenience but does indicate the ignorance of VTAM matters which seems to pervade HIS documentation and which seems to extend to ignorance of SNA/APPN as exposed in the “HIS and TGs” posts.

    I just hope there is not some sort of “catch” in this “forum” system which gets in the way of making all these posts.

    Ideally, I expect these posts will be reviewed by somebody among the HIS support people who has actually had adequate APPN education who will appreciate what is being said and who is qualified to challenge the posts if and where necessary.

    Assuming these posts are found all to be in perfect order - or perhaps have one or two frayed edges about which, of course, I would be delighted to hear, what I would like to see next from one of the Microsoft gurus, Stephen Jackson for example, whom, as can be seen in the suggested text, I have assumed is replying , is something along the lines of the following:

    <response>

    Laurent

    Let me first apologise profusely for the enormous mistakes I made in my previous post. Now that I have read these posts from Chris Mason, I can see the error of my - and many of my colleagues - ways.

    In summary, the corrections to what I said before are as follows:

    1. There is actually no external manifestation of LEN behaviour anywhere in HIS now that we have discontinued “Link Services” other than the one we refer to as the “IP-DLC Link Service”. Thus, although there is a LEN link internal to HIS connecting the functional LEN node to the network node side of the Branch Network Node implementation of APPN in the “IP-DLC Link Service”, LEN functions have no particular significance for users of HIS. All that emphasis on LEN as a way of excusing lack of support for TG characteristics was just so much “hogwash”.[1]

    2. There is obviously a need in the “IP-DLC Link Service” dialog to allow both the TG characteristics of the two defined links and the TG characteristics relating to each specified virtual routing node to be “exposed” in the GUI just as the TG characteristics can be specified in all other implementations of APPN.[2] That will now be implemented as an internal request and made available as soon as possible.

    (In case any money is associated with (a) “opening a support case with the HIS support team” (b) “a Critical Design Change Request (CDCR)” or (c) “filing a regular DCR”, the following should be added: And of course, my most profound apologies for suggesting that you should be making any payments for what is required to be a feature of any product which tries to lay claim to be an APPN product.)

    3. It is true that the configuration possibilities for the two defined links are as Chris Mason described and the contacted node need neither be a network node nor, if a network node, offer to be a network node server. Being a primary and backup network node server is only a suggested use for the two defined links. The GUI prompts and other documentation will be changed to reflect this. Consequently, some configurations which customers find more suits their needs become clearer possibilities although those possibilities have always been available.

    (This is an optional statement obviously since it may not be true if HIS insists - for no good purpose - that the adjacent node over a defined link is a network node which offers APPN services.)

    4. Chris Mason described a very misleading prompt “Use Dynamic PU Definition” with some equally misleading explanations in the HIS “Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper”. I promise to at least have the prompt changed - or, since it really serves no purpose, to have it removed. It is, in  any case a matter to be discussed between the HIS systems programmer and the VTAM systems programmer how these “recognition” fields should be completed and needs no special manipulation in the HIS GUI.

    <Microsoft HIS guru>

    [1] Just to avoid getting into yet another contentious discussion with Chris Mason, let me say that not providing a “class of service” (COS) with a session setup request, originating in the LEN node implementation, could possibly be described as a “manifestation” of LEN behaviour but it is also a normal APPN end node option, lack of implementation of function 036 to be precise, so I'll not insist that this is LEN behaviour!

    [2] With the disgraceful exception of Cisco's SNASw product where at least - the last time I checked - one of three pre-packaged sets can be selected which is guiltily contemptible rather than innocently ignorant.

    </response>

    Stephen Jackson, while attempting to excuse the lack of GUI prompts for the TG characteristics by claiming that the “IP-DLC Link Service” operated an external LEN appearance, quoted what was put in the HIS “Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper” as a terminology item for “LEN”. This is a very flawed description of “LEN” so here is an attempt at a better one:

    <LEN>

    It is a feature of all other architectural types of SNA node that, within their architectural capabilities, each is prepared to present the appearance of a LEN node. Such types of SNA node then operate additional protocols so that sessions where the origin or destination logical unit (LU) resides in a LEN node can participate in the session flows native to the architecture.

    Thus a subarea VTAM node or a consolidated node consisting of VTAM and one or more links supported by NCP can present the appearance of a LEN node over a link and sessions involving the adjacent LEN node can participate in traditional subarea networking.

    An APPN network node can present the appearance of a LEN node over a link and sessions involving the adjacent LEN node can participate in APPN networking.

    Even an APPN end node can present the appearance of a LEN node over a link and partner LUs residing in the adjacent LEN node can be in session with partner LUs residing in that APPN end node just as if the APPN end node were a LEN node.

    You will node how this rather more comprehensive description subsumes the description extracted from the HIS Configuring IP-DLC Link Service for IBM Enterprise Extender White Paper which, in turn, came from the APPN tutorial redbook and so had the IBM seal of approval. Just because something comes from IBM doesn’t mean there is no possible chance that there can be an improvement!

    Incidentally, session types other than LU 6.2 can be passed over a link, the nodes either side of which present the appearance of a LEN node to each other. This flexibility is not always properly reflected in descriptions of LEN nodes but it opens up the opportunity to connect independent subarea or APPN networks to each other in a manner, referred to in the case of subarea networks as “casual connect”, which supports a variety of session types. The major limiting factor when connecting nodes with LEN protocols is that there are no preliminary session setup request flows so that the session must be initiated by sending the BIND request thereby requiring that the session is initiated by the primary LU.

    </LEN>

    Chris Mason
    Thursday, October 28, 2010 8:21 PM
  • Because the forum system has made such a mess of this I am trying again. If the mess persists, I'll have to try posting it by splitting it up - what a royal pain!!!

    HIS and TGs - COS
    =================

    What is the significance of TG characteristics to HIS?

    1. Route selection

    2. Effective capacity also used in order to “seed” the RTP flow control algorithm - covered in a separate post

    1. Route selection
    ------------------

    APPN has two vital steps in the process of setting up a session. The first is to gather information on all the possible links between the two nodes involved in the session. The second is, having gathered the information, to work out which is the quaintly named “optimal” route and to pass this to the resource which initiated the session setup request.

    As far as links between network nodes (NNs) are concerned, this is an ongoing process independent of individual session setup requests, so that all NNs are kept aware of all links between NNs within the borders of the APPN network.

    As far as links between end nodes (ENs) and NNs and ENs and ENs are concerned, this information is made available with the session setup flows[1].

    When the NN acting as the network node server (NNS) has collected all the necessary information, it passes over to a component which works out the “optimal” route. In order to do this the transmission group (TG) characteristics of each link on a potential route from the node where the primary logical unit (LU) resides, to the node where the secondary LU resides are compared against the template defined by the class of service (COS) name defined for the session, a name which is the same as the mode name whenever it needs to be “invented”.

    If, despite there actually being a route from the PLU to the SLU, no route is found to be acceptable, the session setup request is denied. One reason for this could be that the COS imposed a requirement that at least one of the needed links could not satisfy. The most usual such requirement is some level of security.

    In practical terms, no sensible designer of a system would require a level of security which could never be available so this situation would apply where such a level of security were feasible but the alternative route with that capability just happened not to be available at the time of the session request.

    A frequent situation is that there is only one link and will only ever be one link between, say, an EN where the PLU resides, and an adjacent NN which necessarily acts as the NNS, either in which the SLU resides or which leads through the APPN network to the node where the SLU resides. As far as the link between the EN and the NNS is concerned, there is no purpose served by comparing the TG characteristics with the COS template as long as there is no restriction placed on the session by means of the COS name. Such a restriction could be that there must be a certain level of security present in all links and this link does not have the required level of security.

    It may be argued that use of the mechanism associated with the COS selection should be “switched off” when there is only a single link but this ignores the possibility, for example, that there may be a requirement on some sessions to impose a certain level of security and the link which provides that level of security just happens not to be available temporarily.

    Some persistent souls may then go on to argue that it should be possible to designate that single link as the only link that will ever be established as a way of bypassing the need for the mechanism associated with the COS selection. Well, I fear they are whistling in the wind - unless they persuade the group responsible for APPN architecture to add the function to APPN.

    Actually, in a sense, the function is there already in the architecture. It is, in effect, a feature of LEN architecture.[2] The only problem about using this with HIS is that, since other “Link Services” were withdrawn, HIS communicates “upstream” now only with the “IP-DLC Link Service” using Enterprise Extender (EE) and an EE link insists on the connected nodes having an APPN appearance to each other rather than a LEN appearance.

    Now that we know that it is impossible to avoid using TG characteristics for the process of route selection, it's important to be clear which of two possible sets of TG characteristics are used. Each link is associated with two sets of TG characteristics, one for each adjacent link station. Which of the two is used for any one link is determined by the type of nodes in contact and the direction of the BIND request flow which initiates the session.

    First we need to be clear about the node in which the TG characteristics are defined. The definition of an adjacent link station (ALS) applies to the node to which the link is established but the definition is made in the contacting node.

    - The set of TG characteristics defined in the NN which the BIND leaves is used in the case of a link between an NN and another NN which is an initial, intermediate or final link in the route for the session.

    - The set of TG characteristics defined in the EN which the BIND leaves is used in the case of the link between an EN and an NN which is the initial link in the route for the session.

    - The set of TG characteristics defined in the EN which receives the BIND is used in the case of a link between an NN and an EN which is the final link in the route for the session.

    - The set of TG characteristics defined in the EN which receives the BIND is used in the case of a link between an EN and an EN which is the sole link in the route for the session.

    Note that the set of TG characteristics defined in an NN connected to an EN is never used - except when the EN is not actually an APPN EN, as assumed for the EN as described earlier in this paragraph, but a LEN EN - using formal APPN terminology - or simply a LEN node.

    There is an exception to the rules for the use of TG characteristics as given above when a virtual NN (VNN), also known as a virtual routing node (VRN) or simply a virtual node (VN), is used in order to implement a “connection network”. This affects only the case of the link between an NN and another NN where the VNN would be expected to provide the definitions for the set of TG characteristics. Since the VNN obviously cannot, the set of TG characteristics defined in the NN which receives the BIND is used.

    Now that we know which sets of TG characteristics are relevant to the business of selecting a route, we can cover a little more how the sets of TG characteristics are used.

    When compared against the COS templates, each link is given a weight which is a determined by where the set of TG characteristics “fits” the template starting with the template having the lowest weight and progressing to higher weights. If there is no “fit”, an infinite weight is assigned and that link cannot be part of the route for the session.

    Note that the same process applies also to the nodes which are intermediate on any potential route for a session. This, for example, allows a node which is “congested” to affect the weight which is assigned to the node.

    Over all possible routes for the session, the weights are added up and, if any routes remain which have not been given infinite weight, the route with the least weight will be selected.

    The case of the VNN is exceptional again in that (a) the weights of the two links involving the VNN are divided by two before being used in the overall addition and (b) the weight of the VNN itself as a node is always zero.

    -

    In the case of an HIS EN, we have up to four complete or partial route structures in which the relevance of sets of TG characteristics can be examined - although one depends on a possible but undocumented configuration option.

    The four structures are the following:

    1. A single link between the HIS EN and an NN which is necessarily an NNS.

    In general, there are no complications introduced by considering TG characteristics. The only possible undesirable result is when the mode table name used maps in VTAM to a COS table in which the templates cause the link to have infinite weight in the route selection process.

    While this result is outside the control of HIS it is an unreasonable situation if it is planned that there should only ever be the single link. It is a reasonable assumption that a single link will allow any set of TG characteristics to be acceptable. Because of this, in this case, it is impossible to object to the fact that HIS imposes an unchangeable set of TG characteristics.

    2. Two links between the HIS EN, an NN, NN1, and another NN, NN2, in which the application resides or which is the route to the node in which the application resides

    Considering a session initiated in the EN, there are now two possible routes, a direct route, EN-NN2, and an indirect route, EN-NN1-NN2, with the route possibly extending from NN2.

    Now some may say that it is ridiculous that there are two routes since the direct route is obviously best. Well, it may not be. It may be that route EN-NN2 is not a secure route, while EN-NN1-NN2 is a secure route. It may be that route EN-NN2 is over very slow media while route EN-NN1-NN2 is over very fast media. But surely NN1, the NNS, “knows” that route EN-NN1 is best. Well, only if the necessary information is available to make that discovery - and that's where TG characteristics come in.

    Now if, as is the case of links defined within HIS EN to adjacent nodes, the TG characteristics assigned by the EN are identical for the two links, the weight assigned to the two links will necessarily have the same value. Since the value of the weight contributed by NN1 will be positive and the value of the weight contributed by the link NN1-NN2 will be positive, obviously the consolidated weight for the route EN-NN2 will be less than the consolidated weight for the route EN-NN1-NN2. Thus the direct route, EN-NN2, will be selected.

    Also in this case, the fact that HIS imposes an unchangeable set of TG characteristics escapes censure.

    The comment which many will consider is here appropriate may well be related to denying this has much to do with the science of propelling vehicles into outer space.

    Before looking into the next case, it's useful to remind ourselves that, if we are dealing with LU 6.2 sessions, while looking into the establishment of sessions in one direction, given the multiple session nature of LU 6.2 sessions, it's important to consider what might happen in the case of sessions established in the reverse direction, in essence, in this case, NN2 to EN. It so happens that the rules mean that, for this configuration, the rules are the same and the result is the same.

    3. Two links between the HIS EN, EN1, an NN and an EN, EN2, in which the application resides

    Note: This case depends on a configuration possibility which is not encouraged by the “IP-DLC Link Service” GUI and may actually be - for no particularly good reason - forbidden.

    Again considering a session initiated in the EN, there are two possible routes, a direct route, EN1-EN2, and an indirect route, EN1-NN-EN2.

    Once more, the analysis of which sets of TG characteristics apply is needed. However, unlike in the previous case, the direct route is a single link between ENs. This means that, for this link, rather than the set of TG characteristics defined in the HIS EN, EN1, determining the weight, it is the set of TG characteristics defined in the other EN, EN2, which will determine the weight. It is now possible that the consolidated weight for the route EN1-EN2, as determined by definitions in EN2, possibly a VTAM node, is greater than the consolidated weight for the route EN1-NN-EN2. Thgus the weight comparison could result in route EN1-NN-EN2 being selected - not at all what the customer of the HIS product will expect.

    This summary of possible configurations is followed by a worked example of how this easily can come about.

    As indicated for the previous case, when there are LU 6.2 sessions, a session established in the reverse direction needs also to be considered. It becomes clear that, as far as the selection of sets of TG characteristics is concerned, this is, in effect, identical to the case of the EN and two NNs, and so it is inevitable that the direct route, EN2-EN1, is chosen. It would, of course, be an interesting situation that, between the same two LUs, some sessions use one route and some sessions use a different route - to the further confusion of the customer of the HIS product.

    4. At least one link between the HIS EN and an NN, necessarily an NNS, and a link over a connection network, represented by a VNN, to an EN or an NN, to be identified as N (for node), in which the application resides or, in the case of the NN, which is the route to the node in which the application resides

    Considering a session initiated in the EN, this configuration again yields two possible routes, a direct route somewhat disguised by the presence of a VNN, EN-VNN-N, and an indirect route, EN-NNS-N.

    Now that we are used to the determination of weights derived from TG characteristics, we can present the calculation using symbols.

    The consolidated weight for the “direct” route can be represented as follows:

    (W(EN->VNN) + W(N->VNN))/2 + W(VNN = 0)

    The consolidated weight for the indirect route is as follows:

    If N is an EN

    W(EN->NNS) + W(NNS) + W(EN->NNS)

    If N is an NN

    W(EN->NNS) + W(NNS) + W(NNS->NN)

    Notes:

    - The set of characteristics, TG or node, are represented by the symbols within the brackets.
    - The direction of the “arrow” indicates the node where the set of TG characteristics is defined.

    As in the previous case, the arithmetic cannot guarantee that the, in this case, somewhat disguised “direct” route will be less that the weight for the indirect route with all the potential for unwelcome surprises this offers.

    Again the worked example can be consulted to see how this undesirable situation can come about.

    The specification of the TG and node characteristics which affects the determination of routes in this configuration is unaffected by the direction of session initiation as far as the HIS EN is concerned. Thus the behaviour of LU 6.2 sessions need not be considered.

    -

    Before considering the worked examples, it’s important to be clear whence the name of the COS table containing the all-important templates comes. The rule is that, if no COS name is supplied by an EN - as is allowed by APPN, the NNS will supply a COS name - with its associated transaction priority. The definition of the specified mode name, which must be available, is used in order to determine a COS name. In VTAM the default COS name is #CONNECT.

    Worked Examples:

    Case 3:

    If the VTAM systems programmer has specified that the “propagation delay” TG characteristics for the links to the HIS EN, EN2 to EN1, should have the quality of “packet”, specified using the PDELAY=PACKET operand, then the weight assigned to the link using the COS name #CONNECT - as long as the value for the “effective capacity” TG characteristic, specified using the CAPACITY operand, is greater than 19.2 Kbps - will have value 150.

    Thus

    the direct route has weight:................. 150

    and

    the indirect route has weight: 30 + 60 + 30 = 120

    Consequently the indirect route is chosen and all because the VTAM systems programmer was honest - as it is suggested all VTAM systems programmers should be regarding TG characteristics when they attend their APPN classes - and decided to characterise his or her IP network as a packet-switching network which it most surely is. In other words he or she come out of this smelling of roses and Microsoft come out of it smelling of something else!

    Note that the weight of the indirect route, using COS name #CONNECT, is made up of the following:

    30 based “effective capacity” >= 4M and “propagation delay” <= “negligible” for the EN1 to NN link
    60 based on a default “node resistance” of 128
    30 based “effective capacity” >= 4M and “propagation delay” <= “negligible” for the EN2 to NN link - using, say, XCF

    Case 4:

    Continuing to use COS name #CONNECT, we take the weight of 150 as used by VTAM for any link to the VNN and we take the weight of 30 as is assumed would be appropriate for any link from HIS to the VNN, there being no documentation, specific or incidental, over what TG characteristics are used, and feed that into the formula given before in order to discover the following weight:

    (150 + 30)/2 + 0 = 90

    Now our VTAM systems programmer may very well decide to set the “node resistance” value in the ROUTERES start option to a value other than the default 128. He or she might, on the basis of the description in the z/OS Communications Server SNA Resource Definition Reference manual - not really quite as accurate as it might be[3], decide simply to specify 0. This would result in a weight of 5 - although any value less than 95 would result in a weight less than 30 which is the “tipping point”.

    Thus the weight of the indirect route is as follows:

    30 + 5 + 30 = 65

    and we again have the tragedy of the indirect route being chosen.

    -

    I suppose an answer which might occur to anyone disturbed by these conclusions but who nevertheless considers the problem relatively trivial and easily rectified might simply be to suggest that the VTAM definition where the propagation delay characteristic is specified honestly as “packet” should be changed to the thoroughly dishonest “negligible” - just like the hardcoded characteristic inside HIS.

    Let us examine this disreputable suggestion.

    A VTAM systems programmer who has been keeping up with enhancements over the last decade or so will have defined one model PU statement with DYNTYPE=EE for the purposes of accepting all incoming connections over the Enterprise Extender definitions which are not associated with a connection over a “connection network”. He or she will regard with thoroughly deserved disdain any suggestion coming from the Microsoft specialist supposedly supporting the HIS product that individual PU statements should be created in order to specify an inappropriate code for the PDELAY operand just because the HIS product doesn't offer the possibility to specify TG characteristics as any self-respecting product describing itself as supporting APPN ought to.

    Point taken but how about the TG characteristics associated with a connection over a “connection network”, strictly the TG characteristics defined for the notional link to the VNN?

    This is, if possible, even worse! Having to specify different TG characteristics for a VNN because of the inflexibility of the HIS implementation would mean that a separate VNN representing a different “connection network” would need to be defined assuming, as is very likely, that there were other nodes participating in the original “connection network”. The VTAM systems programmer would be obliged to raise his opinion of the HIS implementation as is was evaluated when the individual PU statements needed to be split off the model PU statement just to leave room for the contempt needed to reflect the disgust felt over the disruption of having to create a separate “connection network”.

    And this ordure all because the HIS implementation of APPN as embodied in the “IP-DLC Link Service” hasn't taken the trouble to expose to customisation the TG characteristics - while claiming to be an implementation of APPN, no less![4]

    -

    But I haven't finished. Some scorn was poured on the “security” TG characteristic and, assuming it were possible to specify it, there's a potential application that Microsoft HIS customers might appreciate having if only it were available to them.

    When defining virtual routing nodes, it is possible to specify multiples. One possible application is to specify one name which maps to the use of an IP address pair that is not supported by a virtual private network and another name which does map to the use of an IP address pair that is supported by a virtual private network. The former would be defined with the TG characteristic “security” having the value “no security”, or SECURITY=UNSECURE in the improper semantic form chosen by VTAM developers, and the latter would be defined with the TG characteristic having some value other that “no security”, for example, SECURITY=ENCRYPT which would be appropriate for a virtual private network. Of course the parts of the route either side of the virtual private network would need to be certain of adequate security.

    The point is that different static virtual IP addresses could be defined to be associated with one instance of Enterprise Extender in VTAM corresponding to different virtual routing nodes so that, using one IP address, a virtual private network is not employed but with another IP address a virtual private network is employed, the partner IP address supported by HIS being the same in the two cases.

    But HIS does not support TG characteristics being associated with its virtual routing nodes so this is all again whistling in the wind!

    -

    Incidentally, I believe I may have discovered the text in the VTAM manual that has given rise to the request by the VTAM systems programmers for the ability to specify the CAPACITY and SECURITY operands on the relevant PU statements.

    Here is the text from the z/OS Communications Server SNA Network Implementation Guide, Chapter 6, “Using Enterprise Extender (EE)”, section “Configuring the EE network”, section “Steps for configuring and activating an EE network”, section “Step 3: Prepare your VTAM definitions”, section “EE XCA major node”:

    <quote>

    - Each GROUP entry is composed of a set of LINE definitions sharing the same characteristics, such as IP address or host name. For groups that define a connection network, the APPN TG characteristics such as CAPACITY and SECURITY are defined on the GROUP statement in the XCA major node.

    </quote>

    The poor VTAM systems programmers were just trying to follow the advice given in the VTAM manual and transferring this advice to the customisation of HIS when they came up against the intransigence of the HIS developers.

    -

    Chris Mason

    -

    [1] Actually, this is one option, the other being that the EN is obliged to keep its NNS constantly aware of all the links emanating from the EN. It can easily be seen that this doesn't affect the basic sequence of a session setup.

    [2] Low Entry Networking (LEN) solves the traditional networking problems as follows:

    a. How to reach - in SNA, initiate a session - the node where the named partner resource resides: provide a directory entry indicating the name of the adjacent node logically containing the named partner resource.

    b. Which route to use: since the partner resource must logically reside in an adjacent node, the problem reduces to which link to use and since there is only one link is permitted between any two adjacent nodes, the link over which the node identified in the directory entry is used.

    Setting up the LEN systems so that all sessions are between control points avoids having actually to create any definitions associated with the location of partner resources. The mode name can be used in order to identify the different applications supported by the control point resources.

    APPN relieves LEN restrictions by allowing the partner resource not necessarily to reside in an adjacent node and allows multiple links between any two adjacent nodes. This introduces the need to provide a mechanism to determine the “optimal” route to use in order to reach the node where the partner resource resides - which requires the “class of service” calculation - which, in turn, requires the specification of characteristics, both static and dynamic incidentally, for links aka transmission groups, and nodes.

    [3] ROUTERES start option

    <quote>

    ROUTERES=resistance_value

    ROUTERES is meaningful only if the NODETYPE=NN start option is also used.

    range: 0–255, default 128

    Specifies a route addition resistance value. This is a relative measure of the desirability for this node to perform intermediate session routing function. The value specified for this node is compared to the values of other network nodes during route calculation. The lower the value, the more desirable it is to have this
    node provide intermediate session routing.

    You can change the value of ROUTERES with the MODIFY VTAMOPTS command while VTAM is running.

    </quote>

    [4] The IBM Communications Server products Windows, AIX and Linux all “expose” TG characteristics in all appropriate contexts in a “flat file” or something similar. I cannot comment on today's GUIs but predecessor products always allowed the TG characteristics to be specified using the GUI - even if it appeared as an “advanced” option.

    The URLs which will allow the relevant manuals to be accessed are the following:

    Windows: Configuration File Reference

    http://www-01.ibm.com/support/docview.wss?rs=2262&uid=swg27010826

    AIX: Administration Command Reference

    http://www-01.ibm.com/support/docview.wss?rs=1006&uid=swg27006996

    Linux: Administration Command Reference

    http://www-01.ibm.com/support/docview.wss?uid=swg27005371
    Thursday, October 28, 2010 8:23 PM
  • Chris,

    Thanks for taking the time to put all of this information together. I will certainly agree that I'm not a IBM expert in these areas and have never tried to pretend that I was. I'm sure all of the information that you provided is accurate and that Host Integration Server does not fulfill or meet of the APPN functionality that IBM (or others) may offer. We continue to improve functionality and to add features to provide more functionality over time. A good deal of the changes that have been added to the IP-DLC link service since it was first introduced six years ago with HIS 2004 have been from direct customer feedback. 

    We encourage customers to install, configure and use HIS and to provide feedback to help us identify improvements that would benefit customers. You are more than welcome to do the same. You can submit product feedback via the following site without having to contact Microsoft Customer Support:

    http://connect.microsoft.com/HISERVER

    From this site, you can click Feedback to submit your feedback. Items entered through this feedback site are opened in our internal tracking system for Host Integration Server so that they can be reviewed by our development team. You can even vote for current feedback items to help indicate items that have broader impact.

    Of course, customers can also open support cases to pursue product hotfixes or design changes. These types of support cases are not billable. If you don't have a support contract, you may need to pay for the incident (support case) to get it opened, but when the case is determined to be a bug (or Critical Design Change Request), the cost will be reimbursed. This is done all the time.

    In respect to the particular question that Laurent posted at the beginning of this thread, I did provide an accurate answer to the question as it relates to HIS and the use of the TG parameters that were listed. Obviously, HIS and the IP-DLC link service could be changed to better support those particular parameters. If Laurent (and his company) or other customers find that our current level of functionality in this area does not meet their needs, they should contact us in order to pursue a change.

    The HIS Product Team is very customer focused and has made countless changes to the product over the years in order to meet customer needs.

    Cetainly, there are times when we can't make a requested change (especially as a hotfix or CDCR) because we have to consider the potential impact that such a change would have on existing customers. It is never a good story to make a change for a customer (or a few customers) that ends up negatively impacting other customers.    

    As I stated above, you should consider submitting your feedback for the various product improvements that you have identified via the Feedback mechanism above so that they are added to our internal tracking system and can be evaluated.

    Thanks...

     


    Stephen Jackson - MSFT
    Friday, October 29, 2010 6:48 PM