To all following the parent thread which - one would hope - includes all who use Enterprise Extender in z/OS VTAM:
Just to summarise why this matter continues to be under discussion: On IBMTCP-L I have attracted the attention of VTAM development to this matter and I hope that the remaining ends can be tidied up in that discussion. Meantime I can offer vastly - I hope - improved documentation to cover the problem as originally revealed in the parent thread. It was first suggested (20 May) that there might be a problem with compatibility between the implementation of Enterprise Extender (EE) in different levels of VTAM - which is the SNA component of Communications Server (CS) where each new level of z/OS brings a new level of CS. Thus the compatibility matter is one which relates to the level of z/OS used in the SNA partners communicating using EE. Note that z/OS VTAM is not the only platform which supports EE but that takes us into an area of mystery still not resolved. I responded that SNA is designed so that incompatibilities between levels of implementation can be resolved through protocol flow between the partners and so there should not no excuse ever to have incompatibilities which prevent interworking. Of course this assumes architects - because not just one product or products from just one vendor are involved - and developers had done their job properly. There were then two responses which - heads having been scratched - recalled that there are/may indeed be incompatibilities and that the incompatibility had been mentioned in a presentation concerning how wonderful z/OS V1R11 - which research discovered was: z/OS 1.11: Migration - And It's Good! Part 2 of 2 http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/topic/com.ibm.iea.zo s/zos/1.11/Installation_Migration/Migrating_to_R11_Part2.pdf At this point I started digging. It turns out there is text in the Migration manuals for V1R10 and V1R11: SNA Services: Ensure compatible levels of VTAM for HPR sessions http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/E0Z2M161/7.1.15 http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/e0z2m171/7.1.15 and there is a Technote covering the matter: z/OS V1R10 VTAM compatibility requirements for HPR sessions in mixed network http://www-01.ibm.com/support/docview.wss?uid=swg21367595 Of these only the section in the Migration manual for z/OS V1R10 can claim to have been competently written and then only because the nature of the problem caused by incompatibility had yet to be fixed; it was obliged to put egg on its face and leave it there! Both the text in the Migration manual for V1R11 and the Technote mention the APAR which allows a resolution of the problem without any appreciation that the availability of the APAR makes nonsense of the previous text. In the case of the section in the Migration manual the "game-changing" APAR is mentioned as an afterthought and it's probable that the addition of the last two paragraphs of the Technote is evidence of the same effect. In addition to what is said in the description of the HPRSESLM start option in the CS SNA Resource Definition reference manual which - highly disingenuously IMNSHO - touches on the "interchange node sessions" exception, there is also an extensive section in another document in the form of a presentation: z/OS V1R10 Communications Server Enterprise Extender (EE) and SNA enhancements: Part 2 http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/topic/com.ibm.iea.co mmserv_v1/commserv/1.10z/ee/neweesna2.pdf What this is particularly good for is to explain just exactly what the "RTP pipe session limit control" function is all about and why limiting the number of sessions using an RTP "pipe" can have benefits. Unfortunately, in the matter of what the ICN incompatibility is about, it promises more than it delivers. The remaining mystery is precisely that, what is the protocol flow involving "interchange node sessions" which can cause the session setup failure with the 0897000A sense code. Once this is clear, we will know: 1. Are EE platforms other that z/OS VTAM affected or not? After all it is the *partner* node which is supposed to implement support for a control vector or something like that in flow to the VTAM interchange node running in z/OS from z/OS V1R10 which isn't implemented before VTAM running in z/OS from V1R8 (or some earlier releases with maintenance). 2. Does the problem potentially affect *all* session setup flows involving changing from APPN/HPR at an Interchange Node to a subarea flow or only sessions having certain characteristics such as, for example, being initiated by the LU which is destined to become the secondary LU in the eventual[1] session? Knowing 1 is obviously a practical consideration and knowing 2 might be practical if my example applies and the only sessions affected by the possible incompatibility involved initiation from the LU destined to be the primary in the eventual[1] session. A very practical case could be that the affected VTAM nodes only run NJE sessions. However, as I said, in order to be finicky like this, one needs to know the facts. [1] For the benefit of those reading this who do not have English as their native language, I am always conscious that the word "eventual" is a multiple offender "false friend" and in the context of setting up SNA sessions I need to be clear. In English, "eventual" refers to something that is intended to happen or will happen whereas in other languages I know which originated (probably in the case of French) or borrow the word, it just means "possible". For an English-speaker living in Belgium, it can be very confusing to have folk proudly demonstrating their command of the English language but misusing "eventual" to mean "possible". When I first arrived mutual misunderstanding was rife - until I spotted the imposter! -- The following is a rewrite of the Migration manual text for section "SNA Services: Ensure compatible levels of VTAM for HPR sessions" and the Technote "z/OS V1R10 VTAM compatibility requirements for HPR sessions in mixed network". The main benefit is properly to recognise the impact of the HPRSESLM=DISABLED APAR for V1R10 and V1R11 with presumably corresponding function incorporated into V1R12 when it becomes available. - The Migration manual text: <original> 7.1.15 SNA Services: Ensure compatible levels of VTAM for HPR sessions Description: In order to run z/OS V1R10 and later Communications Server as an HPR-capable interchange node in a mixed subarea and APPN network, you must ensure that all HPR-capable VTAMs in your APPN network (and in attached APPN networks) are running z/OS V1R8 or later Communications Server, or sessions established with or through these earlier VTAMs might fail. z/OS V1R8 and later Communications Server provides additional information on APPN session establishment flows to identify when sessions cross from APPN into subarea (or vice versa) through an interchange node. This additional information is used by z/OS V1R10 and later Communications Server to separate interchange node sessions from APPN-only sessions by placing them on different RTP pipes. If any of the VTAMs in your network (or in attached APPN networks) are not running z/OS V1R8 or later, then z/OS V1R10 and later interchange nodes might incorrectly place interchange node sessions onto the wrong RTP pipe, which could result in session setup failures. (If any of the HPR-capable VTAMs in your APPN network or in attached APPN networks are running an earlier release of z/OS Communications Server, contact your IBM representative to find out what alternatives are available.) You should also be aware that this new function might result in interchange nodes creating more RTP pipes to adjacent APPN nodes than prior releases because separate RTP pipes are now used for interchange node sessions versus APPN-only sessions. Element or feature: Communications Server. When change was introduced: z/OS V1R10. Applies to migration from: z/OS V1R9. Timing: Before installing z/OS V1R11. Is the migration action required? Yes, if you plan to enable APPN and HPR support in VTAM using the NODETYPE and HPR start options. Target system hardware requirements: None. Target system software requirements: None. Other system (coexistence or fallback) requirements: All HPR-capable VTAMs in your network (and in attached APPN networks) must be running z/OS V1R8 or later Communications Server. Restrictions: None. System impacts: As a result of separating interchange node sessions from APPN-only sessions by placing them onto separate RTP pipes, there may be an increase in the number of RTP pipes created by interchange nodes to adjacent APPN nodes and a corresponding increase in the amount of storage used to represent these RTP pipes. Steps to take: Ensure that all HPR-capable VTAMs in your network (and any APPN-attached networks) are running z/OS V1R8 or later Communications Server. All HPR-capable VTAMs must be upgraded to this level before IPLing the first z/OS V1R10 or later Communications Server interchange node. Alternatively, you can configure your HPR-capable interchange nodes to avoid the incompatibility with earlier releases of VTAM by specifying the HPRSESLM=DISABLED start option value when the VTAM interchange node is started. The HPRSESLM=DISABLED start option value is provided by APAR OA28332 for z/OSV1R10 and APAR OA28727 for z/OSV1R11. </original> <improved> 7.1.15 SNA Services: Ensure compatible levels of VTAM for HPR sessions Description: In order to run VTAM (the SNA component of Communications Server) running in z/OS from V1R10 as an HPR-capable interchange node in a mixed subarea and APPN network, you must ensure compatibility between all HPR-capable VTAMs which may be connected with RTP pipes in your network and any attached APPN networks. Otherwise sessions established with or through incompatible VTAMs might fail. This compatibility can be achieved in one of two ways: 1. The preferred means is to ensure that HPR-capable VTAMs in your network and any attached networks run in z/OS from V1R8 where those VTAMs can establish RTP pipes to HPR-capable VTAM interchange nodes running in z/OS from V1R10. 2. If the above is not possible, a less preferred means is to ensure that, where HPR-capable VTAMs in your network and any attached APPN networks between which RTP pipes can be established are VTAM interchange nodes running in z/OS from V1R10, HPRSESLM=DISABLE is specified in the start options of those VTAMs. For z/OS V1R10, you must first install APAR OA28332 and, for z/OS V1R11, you must first install APAR OA28727. The reason the first option is preferred is that the "RTP pipe session limit control" function introduced with VTAM in z/OS V1R10 may be employed if the use of this function is desired in order to improve performance of VTAM supporting many sessions, 1000 or more, over any one RTP pipe. If it is necessary to specify HPRSESLM=DISABLED, the "RTP pipe session limit control" function cannot be used. VTAM running in z/OS from V1R8 provides additional information on APPN session establishment flows in order to identify when sessions cross from APPN into subarea (or vice versa) through an interchange node. Unless HPRSESLM=DISABLED has been specified, this additional information is used by VTAM running in z/OS from V1R10 in order to place interchange node sessions on one RTP pipe and APPN-only sessions on a different RTP pipe thereby separating the two types of session. If any of the VTAMs in your network or any attached networks are not running in z/OS from V1R8, then VTAM interchange nodes running in z/OS from V1R10 for which HPRSESLM=DISABLED has not been specified might incorrectly place interchange node sessions onto the wrong RTP pipe, potentially resulting in session setup failures. You should also be aware that, unless HPRSESLM=DISABLED has been specified, even when the "RTP pipe session limit control" function introduced with VTAM in z/OS V1R10 is not actually used in order to limit the number of sessions assigned to any one RTP pipe, this function might result in HPR- capable VTAM interchange nodes creating more RTP pipes to partner HPR- capable APPN nodes than with VTAM running in z/OS prior to V1R10 because of the separation of the two types of session, interchange node sessions and APPN-only sessions. Element or feature: Communications Server. When change was introduced: z/OS V1R10. Applies to migration from: z/OS V1R9. Timing: Before installing z/OS V1R11. Is the migration action required? Yes, if you plan to enable APPN and HPR support in VTAM using the NODETYPE and HPR start options and still to retain subarea capability by specifying the HOSTSA start option with a subarea number other than 1 and not specifying SACONNS=NO. Target system hardware requirements: None. Target system software requirements: None. Other system (coexistence or fallback) requirements: Unless HPRSESLM=DISABLED is specified, all HPR-capable VTAMs in your and any attached APPN networks must be running z/OS from V1R8. Restrictions: None. System impacts: Whenever HPRSESLM=DISABLED is not specified, as a result of separating interchange node sessions from APPN-only sessions by placing them onto separate RTP pipes, there may be an increase in the number of RTP pipes created by interchange nodes to adjacent APPN nodes and a corresponding increase in the amount of storage used to represent these RTP pipes. Steps to take: - Either ensure that all HPR-capable VTAMs in your APPN network and in attached APPN networks between which RTP pipes can be established are running in z/OS from V1R8 where those VTAMs can establish RTP pipes to HPR- capable VTAM interchange nodes running in z/OS from V1R10 - Or ensure that, where HPR-capable VTAMs in your network and any attached APPN networks between which RTP pipes can be established are VTAM interchange nodes running in z/OS from V1R10, HPRSESLM=DISABLE is specified in the start options of those VTAMs In order to be able to specify HPRSESLM=DISABLED for z/OS V1R10, you must first install APAR OA28332 and, for z/OS V1R11, you must first install APAR OA28727. </improved> This text should, of course, be "ported" to the "z/OS 1.11: Migration - And It's Good! Part 2 of 2" presentation notes in any future manifestations, for example, for V1R12. - The Technote text: <original> z/OS V1R10 VTAM compatibility requirements for HPR sessions in mixed network Technote (FAQ) Question What VTAM compatibility requirements must be met to run z/OS V1R10 Communications Server as an HPR-capable interchange node in a mixed subarea and APPN network? Cause z/OS V1R8 (and later) Communications Server provides additional information on existing APPN session establishment flows to identify when sessions cross from APPN into subarea (or vice versa) through an interchange node. These sessions are referred to as "interchange node sessions". The additional information is used by z/OS V1R10 Communications Server to separate interchange node sessions from APPN-only sessions by placing them on different RTP pipes. Releases of z/OS Communications Server prior to V1R8 do not provide this additional information on existing APPN session establishment flows. As such, if an HPR-capable pre-V1R8 z/OS Communications Server (VTAM) node is involved in establishing interchange node sessions through a z/OS V1R10 Communications Server interchange node, the missing information might cause the V1R10 interchange node to assign these sessions to the wrong RTP pipe. When this occurs, the interchange node fails the session with sense code x'0897000A'. Answer All native and non-native HPR-capable VTAM APPN nodes must be running z/OS V1R8 (or later) Communications Server (or have the necessary compatibility maintenance applied, see below) before you start any VTAM interchange nodes with z/OS V1R10 Communications Server. Although the compatibility issue applies only when z/OS V1R10 is running as an HPR-capable interchange node, you and your business partners should upgrade any downlevel z/OS systems to V1R8 or later (or apply the appropriate maintenance) as soon as possible. The following maintenance is available to bring older releases of z/OS Communications Server up to a level that is compatible with z/OS V1R10. Release APAR PTF z/OS V1R7 OA22854 UA38026 z/OS V1R6 OA23005 UA38066 z/OS V1R4 OA23005 UA38065 Note: The PTFs for releases V1R6 and V1R4 are available only to customers who have an Extended Service Contract in place for those releases. You will find a detailed explanation of the compatibility issue in: * z/OS V1R10.0 Migration (from z/OS V1R9) GA22-7499-14, in section 7.1.15 SNA Services: Ensure compatible levels of VTAM for HPR sessions. * z/OS V1R11.0 Migration (from z/OS V1R9) GA22-7499-15, in section 7.1.15 SNA Services: Ensure compatible levels of VTAM for HPR sessions. The V1R10 compatibility support is not available for all old releases of VTAM. If you are migrating one or more interchange nodes to z/OS Communications Server V1R10 or later, there is still a risk that you could encounter compatibility problems even if all of your HPR-capable VTAMs are running z/OS Communications Server V1R8 or later. One example would be if you have business partners that attach to your network using APPN and one or more of their HPR-capable VTAMs do not have the necessary compatibility support. To avoid all possible V1R10 (or later) HPR compatibility issues, a new function APAR is available for V1R10 (APAR OA28332) and V1R11 (APAR OA28727) that allows you to completely disable the new V1R10 function that causes the incompatibility issue by means of a new value for the HPRSESLM start option, HPRSESLM=DISABLED. You must install this new function APAR (and specify HPRSESLM=DISABLED) on all HPR-capable V1R10 (or later) interchange nodes. HPRSESLM=DISABLED is only meaningful for interchange nodes, and can only be specified when a VTAM interchange node is started. That is, you cannot use the MODIFY VTAMOPTS command to set or change the DISABLED value for the HPRSESLM start option. </original> <improved> z/OS V1R10 VTAM compatibility requirements for HPR sessions in mixed network Technote (FAQ) Question What VTAM compatibility requirements must be met to run VTAM running in z/OS from V1R10 as an HPR-capable interchange node in a mixed subarea and APPN network? Cause >From z/OS V1R8 VTAM provides additional information on existing APPN session establishment flows in order to identify when sessions cross from APPN into subarea (or vice versa) through a VTAM interchange node. These sessions are referred to as "interchange node sessions". Unless the "RTP pipe session limit control" function introduced with VTAM in z/OS V1R10 is disabled, the additional information is used by VTAM from z/OS V1R10 in order to separate interchange node sessions from APPN-only sessions by placing them on different RTP pipes. Releases of VTAM prior to z/OS V1R8 do not provide this additional information on existing APPN session establishment flows. As such, if an HPR-capable node running VTAM prior to z/OS V1R8 is involved in establishing interchange node sessions through a VTAM interchange node from z/OS V1R10 in which the "RTP pipe session limit control" function has not been disabled, the missing information might cause the VTAM interchange node from z/OS V1R10 to assign these sessions to the wrong RTP pipe. When this occurs, the VTAM interchange node fails the session with sense code x'0897000A'. Answer All native and non-native HPR-capable VTAM APPN nodes which can establish RTP pipes with an HPR-capable VTAM interchange node running in z/OS from V1R10 for which the "RTP pipe session limit control" function has not been disabled must be running VTAM running in z/OS from V1R8 (or have had the necessary compatibility maintenance applied, see below) before you start the HPR-capable VTAM interchange node running in z/OS from V1R10 in which the "RTP pipe session limit control" function has not been disabled. Although the compatibility problem applies only when the HPR-capable VTAM interchange node is running in z/OS from V1R10, you and your business partners should upgrade any downlevel z/OS systems to V1R8 or later (or apply the appropriate maintenance) as soon as possible. This is because you may have a use for the "RTP pipe session limit control" function with VTAM from z/OS V1R10 and thus it is preferable for it not to be disabled. The following maintenance is available to bring the VTAM in older releases of z/OS up to a level that is compatible with the "RTP pipe session limit control" function introduced with VTAM in z/OS V1R10. Release APAR PTF z/OS V1R7 OA22854 UA38026 z/OS V1R6 OA23005 UA38066 z/OS V1R4 OA23005 UA38065 Note: The PTFs for releases V1R6 and V1R4 are available only to customers who have an Extended Service Contract in place for those releases. The support for compatibility with the "RTP pipe session limit control" function introduced with VTAM in z/OS V1R10 is not available for all old releases of VTAM. If you are migrating one or more VTAM interchange nodes to z/OS V1R10 or later and you have not disabled the "RTP pipe session limit control" function, there is still a risk that you could encounter compatibility problems even if all of the HPR-capable VTAMs in your enterprise's network are running with z/OS from V1R8. You may have business partners connected to your network using APPN border node functions and one or more of their HPR- capable VTAMs may not have the necessary compatibility support. Where it is not possible to ensure that all potential partner VTAM nodes connected with RTP pipes and supporting interchange node sessions have the necessary support to be compatible with the "RTP pipe session limit control" function, the function can be disabled. In the case of VTAM for z/OS V1R10 and V1R11 a "new function" APAR is available, OA28332 for V1R10 and OA28727 for V1R11. The APAR allows you to disable the "RTP pipe session limit control" function which is associated with the HPRSESLM start option by means of a special value for the start option, HPRSESLM=DISABLED. Having installed the APAR if necessary (V1R10 and V1R11), you can specify HPRSESLM=DISABLED on any HPR-capable VTAM interchange nodes running in z/OS from V1R10. HPRSESLM is a valid start option for any HPR-capable VTAM but HPRSESLM=DISABLED is valid only for interchange nodes. Also, while other values of the HPRSESLM start option can be modified using the MODIFY VTAMOPTS command, HPRSESLM=DISABLED can be specified only as the start option when VTAM is started and cannot be set or changed using the MODIFY VTAMOPTS command. </improved> Note that the Migration manual text adds nothing to the above and, in the case of V1R10, is out of date. - Chris Mason On Thu, 3 Jun 2010 19:54:15 -0500, Chris Mason <chrisma...@belgacom.net> wrote: <Please refer to the original in the archive. This post is big enough already!> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
