none
IP-DLC timers etc RRS feed

  • Question

  • We have HIS 2006 running IP-DLC to an OSA and VTAM when we take down the
    PU on the HIS server and bring it back up it takes quite awhile to
    re-establish connectivity. 5 minutes, even though the OSA is pingable
    and reachable. I am seeing a NNS error in the log during restart of the
    PU. Eventually it comes up and works correctly. Normal DLC never had
    this issue. Are their some timers or some host item we could be missing?
    Because the NNS is active on the host and the host is logging attempts.
     The attempt to start the link to Network Node Server '10.11.129.60' failed.
     NNS link station: @N000001
     Secondary return code: 0x13400000
      Cause:
     An LS_FAILURE was returned from a START_LS NOF verb.  The Network Node
    Server may be inactive, or an invalid NNS address may have been
    configured for the link service.
      Effect:
     The IP-DLC link service will continue to attempt to connect to the
    Network Node Server.  If this fails, and no alternative NNS has been
    configured, no connections will be able to start successfully.
      Action:
     Check that the Network Node Server address has been configured
    correctly, that the NNS is active, and that it is reachable across the
    IP network.
     For more information, see Help and Support Center at
     
    Wednesday, August 25, 2010 2:06 PM

Answers

  • Stan

    > IST1411I INOP GENERATED FOR EELF1001
    > IST1430I REASON FOR INOP IS XID OR LDLC COMMAND TIMEOUT

    What these two messages tell us is the following as taken from the z/OS Communications Server SNA Messages manual:

    <adjusted quotes>

    Explanation: This message (IST1411I) is the first in a group of messages that VTAM issues when an error condition has been detected for external communications adapter (XCA) node resourcename.

    If the XCA resource is for ... an Enterprise Extender (HPR/IP) resource, VTAM issues the following messages:

    IST1411I INOP GENERATED FOR resourcename
    IST1430I REASON FOR INOP IS reason
    IST314I END

    resourcename (EELF1001) is the name of the XCA resource where the INOP condition occurred.

    reason is one of the following:

    ...

    XID OR LDLC COMMAND TIMEOUT

    An XID or LDLC COMMAND to establish an APPN connection across an ... Enterprise Extender (HPR\IP) network did not receive a response after transmission and multiple retries.

    System action: Error recovery will be attempted for resourcename, and subsequent VTAM messages will indicate the
    results of the error recovery. Processing continues.

    Operator response: Enter a DISPLAY ID=resourcename,SCOPE=ALL command to determine the status of the resource. Save the system log for problem determination. Also:

    - If reason is XID OR LDLC COMMAND TIMEOUT, re-attempt the activation of the APPN connection.

    ...

    System programmer response:

    ...

    XID OR LDLC COMMAND TIMEOUT

    During APPN connection establishment, either an XID or an LDLC COMMAND was sent to the remote node. No response was received. The XID or LDLC command was retransmitted multiple times without response.

    ...

    Enterprise Extender (HPR\IP): Retry the connection by reissuing the dial. If failure persists, determine if the
    failure is a result of a system definition error or a network error. If the failure is a result of a system definition error, correct the error. If the failure is a result of a network error, contact the IP network provider.

    </adjusted quotes>

    > IST1141I SOFT INOP FOR SWSRVR1 OVERRIDDEN BY SOFT INOP

    This is perhaps not all that helpful in that it is telling us that something happened, a "SOFT INOP" condition, which has overridden something that happened earlier, another "SOFT INOP" condition. A "SOFT INOP" is a failure from which recovery is possible in VTAM's judgement - I think since I can't actually find right now where this is specifically stated.

    > IST2180I DYNLU = YES FOR AMTKPHL.MSSOBS01 SET FROM SWSRVR1

    Probably because customers complained that they couldn't follow all VTAM's complicated rules in assisting them with creating definitions for them dynamically, this message is simply saying that the PU statement which first represents contact with the adjacent node provides the DYNLU value for the dynamically created ADJCP, adjacent CP, statement representing the adjacent node - a rather long-winded way of saying nothing of any great significance - assuming you've got the definitions right!

    > IST1086I APPN CONNECTION FOR AMTKPHL.MSSOBS01 IS ACTIVE - TGN = 8

    This is now saying that you have established contact - using transmission group (TG) number 8. Only that last part is a bit curious since it is unusual to bother specifying TG numbers. TG numbers in the range 1 to 20 can be specified but it is necessary to do so only for rather special reasons such as multiple connections where one is specifically to carry SSCP-dependent traffic - irrelevant for Enterprise Extender (EE) connections - or in order to use "activation on demand" which requires an independent permanent concatenation of CP LU to CP LU sessions over another path which I suspect does not apply here.

    If the TG number is determined dynamically, it is is the range 21 upwards with 21 for the first connection.

    -

    Since you have not shown any time stamps with the messages, it is not clear whether or not this has much to do with your first post. Also you need to go further back in the log to show what the condition which caused the first "SOFT INOP" is.

    Now it gets puzzling!

    First I wrote it would also help if you indicated when in the sequence of VTAM messages, you deliberately deactivated the resource correspoding what you identify as the "PU" in HIS. The trouble is that, if this is the "PU" resource which corresponds to the "PU" resource in the "normal (LAN?) DLC" case, it will, in the case of the IP-DLC service, be the *DLUR* PU and not any HIS resource corresponding to the EE connection. The actual EE connection *should* - I am not a HIS specialist so I need to use the word "should" - be quite unaffected by manipulating the status of the DLUR PU.

    Why by deactivating the DLUR PU you cause a failure of the EE connection is really rather puzzling and perhaps the real HIS specialists have a clue.

    *If* you had deactivated and reactivated the DLUR PU and there had been unexpected delays without any deactivation of the EE connection, it *should* have been possible for your VTAM specialist colleague to see either - the easy way - using Session Monitor (NLDM) traces or - the hard way - using VTAM buffer traces the progress and timing of the DLUR-DLUS sessions, when they are broken, when they are established and what flows on them in order to check where the delays are. As it is you need to solve the problem with the EE connection first.

    -

    In checking your second post, I see that you have the same effect whether your deactivation/reactivation is performed in HIS or in VTAM. In VTAM there are two PU statements, one representing the EE connection which is really an adjacent link station definition - without any actual SNA PU entity in sight! - and one is the PU statement representing a real SNA PU entity, the DLUR PU. To which one of these do you refer?

    -

    Incidentally, in case it becomes useful at some stage, you should post all the relevant VTAM definitions, as they were with the "normal DLC" and as they are with the IP-DLC service will probably be most helpful.

    Chris Mason
    Thursday, September 16, 2010 8:05 PM

All replies

  • Stan,

    Can you provide a bit more detail about how you are taking down the PU?

    In other scenarios where this particular event with this secondary return code occurred, we found the following:

    - There was an issue where the required UDP ports (12000 through 12004) were not opened in both directions

    - The Advanced IP-DLC settings were changed. The defaults are as follows:

    Receive Ack: 15000 ms
    Livetime: 10000 ms
    Maximum retransmissions: 3 times

    Maximum BTU Size

    Send: 1493 bytes
    Receive: 1493 bytes

    HPR/IP activation retries

    Limited: 10 times
                 25 seconds

    Thanks...


    Stephen Jackson - MSFT
    Wednesday, August 25, 2010 2:43 PM
  • Stephen
     
    We stop/start from the HIS console or the host, it acts the same. Same
    standard timers on the IP-DLC. We believe its not a port issue because
    it starts after 5 minutes like clock work. Anything else we can check?
     
    Stan
     On 8/25/2010 7:43 AM, Stephen_R_Jackson [MSFT] wrote:
    > Stan,
    >
    > Can you provide a bit more detail about how you are taking down the PU?
    >
    > In other scenarios where this particular event with this secondary
    > return code occurred, we found the following:
    >
    > - There was an issue where the required UDP ports (12000 through 12004)
    > were not opened in both directions
    >
    > - The Advanced IP-DLC settings were changed. The defaults are as follows:
    >
    > Receive Ack: 15000 ms
    > Livetime: 10000 ms
    > Maximum retransmissions: 3 times
    >
    > Maximum BTU Size
    >
    > Send: 1493 bytes
    > Receive: 1493 bytes
    >
    > HPR/IP activation retries
    >
    > Limited: 10 times
    > 25 seconds
    >
    > Thanks...
    >
    > ------------------------------------------------------------------------
    > Stephen Jackson - MSFT
     
     
    Wednesday, August 25, 2010 9:45 PM
  • Stan,

    Nothing else to check that I can think of offhand. It would likely be useful to troubleshoot the issue using HIS traces (SnaServer and SnaIP1) along with a network trace to see what is happening.

    If you aren't on HIS 2006 Sp1, you might consider that just to have all the latest updates to the IP-DLC link service for that version.

    None of the SP1 updates are for these symptoms, but sometimes you see different symptoms that what other customers might have seen.

    If you want to troubleshoot via tracing, you will need to open a support case so we can have a look at the traces.

    Thanks...


    Stephen Jackson - MSFT
    • Proposed as answer by Charles Ezzell Sunday, August 29, 2010 1:49 PM
    Friday, August 27, 2010 9:54 PM
  • Below is what we see on the host logs
     
    IST1411I INOP GENERATED FOR EELF1001
    IST1430I REASON FOR INOP IS XID OR LDLC COMMAND TIMEOUT
    IST314I END
    IST1141I SOFT INOP FOR SWSRVR1 OVERRIDDEN BY SOFT INOP
    IST2180I DYNLU = YES FOR AMTKPHL.MSSOBS01 SET FROM SWSRVR1
    IST1086I APPN CONNECTION FOR AMTKPHL.MSSOBS01 IS ACTIVE - TGN = 8
       On 8/27/2010 2:54 PM, Stephen_R_Jackson [MSFT] wrote:
    > Stan,
    >
    > Nothing else to check that I can think of offhand. It would likely be
    > useful to troubleshoot the issue using HIS traces (SnaServer and SnaIP1)
    > along with a network trace to see what is happening.
    >
    > If you aren't on HIS 2006 Sp1, you might consider that just to have all
    > the latest updates to the IP-DLC link service for that version.
    >
    > None of the SP1 updates are for these symptoms, but sometimes you see
    > different symptoms that what other customers might have seen.
    >
    > If you want to troubleshoot via tracing, you will need to open a support
    > case so we can have a look at the traces.
    >
    > Thanks...
    >
    > ------------------------------------------------------------------------
    > Stephen Jackson - MSFT
     
     
    Thursday, September 16, 2010 2:19 PM
  • Stan

    > IST1411I INOP GENERATED FOR EELF1001
    > IST1430I REASON FOR INOP IS XID OR LDLC COMMAND TIMEOUT

    What these two messages tell us is the following as taken from the z/OS Communications Server SNA Messages manual:

    <adjusted quotes>

    Explanation: This message (IST1411I) is the first in a group of messages that VTAM issues when an error condition has been detected for external communications adapter (XCA) node resourcename.

    If the XCA resource is for ... an Enterprise Extender (HPR/IP) resource, VTAM issues the following messages:

    IST1411I INOP GENERATED FOR resourcename
    IST1430I REASON FOR INOP IS reason
    IST314I END

    resourcename (EELF1001) is the name of the XCA resource where the INOP condition occurred.

    reason is one of the following:

    ...

    XID OR LDLC COMMAND TIMEOUT

    An XID or LDLC COMMAND to establish an APPN connection across an ... Enterprise Extender (HPR\IP) network did not receive a response after transmission and multiple retries.

    System action: Error recovery will be attempted for resourcename, and subsequent VTAM messages will indicate the
    results of the error recovery. Processing continues.

    Operator response: Enter a DISPLAY ID=resourcename,SCOPE=ALL command to determine the status of the resource. Save the system log for problem determination. Also:

    - If reason is XID OR LDLC COMMAND TIMEOUT, re-attempt the activation of the APPN connection.

    ...

    System programmer response:

    ...

    XID OR LDLC COMMAND TIMEOUT

    During APPN connection establishment, either an XID or an LDLC COMMAND was sent to the remote node. No response was received. The XID or LDLC command was retransmitted multiple times without response.

    ...

    Enterprise Extender (HPR\IP): Retry the connection by reissuing the dial. If failure persists, determine if the
    failure is a result of a system definition error or a network error. If the failure is a result of a system definition error, correct the error. If the failure is a result of a network error, contact the IP network provider.

    </adjusted quotes>

    > IST1141I SOFT INOP FOR SWSRVR1 OVERRIDDEN BY SOFT INOP

    This is perhaps not all that helpful in that it is telling us that something happened, a "SOFT INOP" condition, which has overridden something that happened earlier, another "SOFT INOP" condition. A "SOFT INOP" is a failure from which recovery is possible in VTAM's judgement - I think since I can't actually find right now where this is specifically stated.

    > IST2180I DYNLU = YES FOR AMTKPHL.MSSOBS01 SET FROM SWSRVR1

    Probably because customers complained that they couldn't follow all VTAM's complicated rules in assisting them with creating definitions for them dynamically, this message is simply saying that the PU statement which first represents contact with the adjacent node provides the DYNLU value for the dynamically created ADJCP, adjacent CP, statement representing the adjacent node - a rather long-winded way of saying nothing of any great significance - assuming you've got the definitions right!

    > IST1086I APPN CONNECTION FOR AMTKPHL.MSSOBS01 IS ACTIVE - TGN = 8

    This is now saying that you have established contact - using transmission group (TG) number 8. Only that last part is a bit curious since it is unusual to bother specifying TG numbers. TG numbers in the range 1 to 20 can be specified but it is necessary to do so only for rather special reasons such as multiple connections where one is specifically to carry SSCP-dependent traffic - irrelevant for Enterprise Extender (EE) connections - or in order to use "activation on demand" which requires an independent permanent concatenation of CP LU to CP LU sessions over another path which I suspect does not apply here.

    If the TG number is determined dynamically, it is is the range 21 upwards with 21 for the first connection.

    -

    Since you have not shown any time stamps with the messages, it is not clear whether or not this has much to do with your first post. Also you need to go further back in the log to show what the condition which caused the first "SOFT INOP" is.

    Now it gets puzzling!

    First I wrote it would also help if you indicated when in the sequence of VTAM messages, you deliberately deactivated the resource correspoding what you identify as the "PU" in HIS. The trouble is that, if this is the "PU" resource which corresponds to the "PU" resource in the "normal (LAN?) DLC" case, it will, in the case of the IP-DLC service, be the *DLUR* PU and not any HIS resource corresponding to the EE connection. The actual EE connection *should* - I am not a HIS specialist so I need to use the word "should" - be quite unaffected by manipulating the status of the DLUR PU.

    Why by deactivating the DLUR PU you cause a failure of the EE connection is really rather puzzling and perhaps the real HIS specialists have a clue.

    *If* you had deactivated and reactivated the DLUR PU and there had been unexpected delays without any deactivation of the EE connection, it *should* have been possible for your VTAM specialist colleague to see either - the easy way - using Session Monitor (NLDM) traces or - the hard way - using VTAM buffer traces the progress and timing of the DLUR-DLUS sessions, when they are broken, when they are established and what flows on them in order to check where the delays are. As it is you need to solve the problem with the EE connection first.

    -

    In checking your second post, I see that you have the same effect whether your deactivation/reactivation is performed in HIS or in VTAM. In VTAM there are two PU statements, one representing the EE connection which is really an adjacent link station definition - without any actual SNA PU entity in sight! - and one is the PU statement representing a real SNA PU entity, the DLUR PU. To which one of these do you refer?

    -

    Incidentally, in case it becomes useful at some stage, you should post all the relevant VTAM definitions, as they were with the "normal DLC" and as they are with the IP-DLC service will probably be most helpful.

    Chris Mason
    Thursday, September 16, 2010 8:05 PM
  • Chris
     
    OMG Awsome I am working with my VTAM guy tp research this more and THANK
    YOU!
     
    Stan
     On 9/16/2010 1:05 PM, Chris Mason in Belgium wrote:
    > Stan
    >
    >  > IST1411I INOP GENERATED FOR EELF1001
    >  > IST1430I REASON FOR INOP IS XID OR LDLC COMMAND TIMEOUT
    >
    > What these two messages tell us is the following as taken from the z/OS
    > Communications Server SNA Messages manual:
    >
    > <adjusted quotes>
    >
    > Explanation: This message (IST1411I) is the first in a group of messages
    > that VTAM issues when an error condition has been detected for external
    > communications adapter (XCA) node resourcename.
    >
    > If the XCA resource is for ... an Enterprise Extender (HPR/IP) resource,
    > VTAM issues the following messages:
    >
    > IST1411I INOP GENERATED FOR resourcename
    > IST1430I REASON FOR INOP IS reason
    > IST314I END
    >
    > resourcename (EELF1001) is the name of the XCA resource where the INOP
    > condition occurred.
    >
    > reason is one of the following:
    >
    > ...
    >
    > XID OR LDLC COMMAND TIMEOUT
    >
    > An XID or LDLC COMMAND to establish an APPN connection across an ...
    > Enterprise Extender (HPR\IP) network did not receive a response after
    > transmission and multiple retries.
    >
    > System action: Error recovery will be attempted for resourcename, and
    > subsequent VTAM messages will indicate the
    > results of the error recovery. Processing continues.
    >
    > Operator response: Enter a DISPLAY ID=resourcename,SCOPE=ALL command to
    > determine the status of the resource. Save the system log for problem
    > determination. Also:
    >
    > - If reason is XID OR LDLC COMMAND TIMEOUT, re-attempt the activation of
    > the APPN connection.
    >
    > ...
    >
    > System programmer response:
    >
    > ...
    >
    > XID OR LDLC COMMAND TIMEOUT
    >
    > During APPN connection establishment, either an XID or an LDLC COMMAND
    > was sent to the remote node. No response was received. The XID or LDLC
    > command was retransmitted multiple times without response.
    >
    > ...
    >
    > Enterprise Extender (HPR\IP): Retry the connection by reissuing the
    > dial. If failure persists, determine if the
    > failure is a result of a system definition error or a network error. If
    > the failure is a result of a system definition error, correct the error.
    > If the failure is a result of a network error, contact the IP network
    > provider.
    >
    > </adjusted quotes>
    >
    >  > IST1141I SOFT INOP FOR SWSRVR1 OVERRIDDEN BY SOFT INOP
    >
    > This is perhaps not all that helpful in that it is telling us that
    > something happened, a "SOFT INOP" condition, which has overridden
    > something that happened earlier, another "SOFT INOP" condition. A "SOFT
    > INOP" is a failure from which recovery is possible in VTAM's judgement -
    > I think since I can't actually find right now where this is specifically
    > stated.
    >
    >  > IST2180I DYNLU = YES FOR AMTKPHL.MSSOBS01 SET FROM SWSRVR1
    >
    > Probably because customers complained that they couldn't follow all
    > VTAM's complicated rules in assisting them with creating definitions for
    > them dynamically, this message is simply saying that the PU statement
    > which first represents contact with the adjacent node provides the DYNLU
    > value for the dynamically created ADJCP, adjacent CP, statement
    > representing the adjacent node - a rather long-winded way of saying
    > nothing of any great significance - assuming you've got the definitions
    > right!
    >
    >  > IST1086I APPN CONNECTION FOR AMTKPHL.MSSOBS01 IS ACTIVE - TGN = 8
    >
    > This is now saying that you have established contact - using
    > transmission group (TG) number 8. Only that last part is a bit curious
    > since it is unusual to bother specifying TG numbers. TG numbers in the
    > range 1 to 20 can be specified but it is necessary to do so only for
    > rather special reasons such as multiple connections where one is
    > specifically to carry SSCP-dependent traffic - irrelevant for Enterprise
    > Extender (EE) connections - or in order to use "activation on demand"
    > which requires an independent permanent concatenation of CP LU to CP LU
    > sessions over another path which I suspect does not apply here.
    >
    > If the TG number is determined dynamically, it is is the range 21
    > upwards with 21 for the first connection.
    >
    > -
    >
    > Since you have not shown any time stamps with the messages, it is not
    > clear whether or not this has much to do with your first post. Also you
    > need to go further back in the log to show what the condition which
    > caused the first "SOFT INOP" is.
    >
    > Now it gets puzzling!
    >
    > First I wrote it would also help if you indicated when in the sequence
    > of VTAM messages, you deliberately deactivated the resource correspoding
    > what you identify as the "PU" in HIS. The trouble is that, if this is
    > the "PU" resource which corresponds to the "PU" resource in the "normal
    > (LAN?) DLC" case, it will, in the case of the IP-DLC service, be the
    > *DLUR* PU and not any HIS resource corresponding to the EE connection.
    > The actual EE connection *should* - I am not a HIS specialist so I need
    > to use the word "should" - be quite unaffected by manipulating the
    > status of the DLUR PU.
    >
    > Why by deactivating the DLUR PU you cause a failure of the EE connection
    > is really rather puzzling and perhaps the real HIS specialists have a clue.
    >
    > *If* you had deactivated and reactivated the DLUR PU and there had been
    > unexpected delays without any deactivation of the EE connection, it
    > *should* have been possible for your VTAM specialist colleague to see
    > either - the easy way - using Session Monitor (NLDM) traces or - the
    > hard way - using VTAM buffer traces the progress and timing of the
    > DLUR-DLUS sessions, when they are broken, when they are established and
    > what flows on them in order to check where the delays are. As it is you
    > need to solve the problem with the EE connection first.
    >
    > -
    >
    > In checking your second post, I see that you have the same effect
    > whether your deactivation/reactivation is performed in HIS or in VTAM.
    > In VTAM there are two PU statements, one representing the EE connection
    > which is really an adjacent link station definition - without any actual
    > SNA PU entity in sight! - and one is the PU statement representing a
    > real SNA PU entity, the DLUR PU. To which one of these do you refer?
    >
    > -
    >
    > Incidentally, in case it becomes useful at some stage, you should post
    > all the relevant VTAM definitions, as they were with the "normal DLC"
    > and as they are with the IP-DLC service will probably be most helpful.
    >
    > Chris Mason
     
     
    Friday, September 17, 2010 3:04 AM
  • Chris
      Awsome, I am working with my VTAM guy to research this more and THANK YOU!
     
    Stan
     On 9/16/2010 1:05 PM, Chris Mason in Belgium wrote:
    > Stan
    >
    >  > IST1411I INOP GENERATED FOR EELF1001
    >  > IST1430I REASON FOR INOP IS XID OR LDLC COMMAND TIMEOUT
    >
    > What these two messages tell us is the following as taken from the z/OS
    > Communications Server SNA Messages manual:
    >
    > <adjusted quotes>
    >
    > Explanation: This message (IST1411I) is the first in a group of messages
    > that VTAM issues when an error condition has been detected for external
    > communications adapter (XCA) node resourcename.
    >
    > If the XCA resource is for ... an Enterprise Extender (HPR/IP) resource,
    > VTAM issues the following messages:
    >
    > IST1411I INOP GENERATED FOR resourcename
    > IST1430I REASON FOR INOP IS reason
    > IST314I END
    >
    > resourcename (EELF1001) is the name of the XCA resource where the INOP
    > condition occurred.
    >
    > reason is one of the following:
    >
    > ...
    >
    > XID OR LDLC COMMAND TIMEOUT
    >
    > An XID or LDLC COMMAND to establish an APPN connection across an ...
    > Enterprise Extender (HPR\IP) network did not receive a response after
    > transmission and multiple retries.
    >
    > System action: Error recovery will be attempted for resourcename, and
    > subsequent VTAM messages will indicate the
    > results of the error recovery. Processing continues.
    >
    > Operator response: Enter a DISPLAY ID=resourcename,SCOPE=ALL command to
    > determine the status of the resource. Save the system log for problem
    > determination. Also:
    >
    > - If reason is XID OR LDLC COMMAND TIMEOUT, re-attempt the activation of
    > the APPN connection.
    >
    > ...
    >
    > System programmer response:
    >
    > ...
    >
    > XID OR LDLC COMMAND TIMEOUT
    >
    > During APPN connection establishment, either an XID or an LDLC COMMAND
    > was sent to the remote node. No response was received. The XID or LDLC
    > command was retransmitted multiple times without response.
    >
    > ...
    >
    > Enterprise Extender (HPR\IP): Retry the connection by reissuing the
    > dial. If failure persists, determine if the
    > failure is a result of a system definition error or a network error. If
    > the failure is a result of a system definition error, correct the error.
    > If the failure is a result of a network error, contact the IP network
    > provider.
    >
    > </adjusted quotes>
    >
    >  > IST1141I SOFT INOP FOR SWSRVR1 OVERRIDDEN BY SOFT INOP
    >
    > This is perhaps not all that helpful in that it is telling us that
    > something happened, a "SOFT INOP" condition, which has overridden
    > something that happened earlier, another "SOFT INOP" condition. A "SOFT
    > INOP" is a failure from which recovery is possible in VTAM's judgement -
    > I think since I can't actually find right now where this is specifically
    > stated.
    >
    >  > IST2180I DYNLU = YES FOR AMTKPHL.MSSOBS01 SET FROM SWSRVR1
    >
    > Probably because customers complained that they couldn't follow all
    > VTAM's complicated rules in assisting them with creating definitions for
    > them dynamically, this message is simply saying that the PU statement
    > which first represents contact with the adjacent node provides the DYNLU
    > value for the dynamically created ADJCP, adjacent CP, statement
    > representing the adjacent node - a rather long-winded way of saying
    > nothing of any great significance - assuming you've got the definitions
    > right!
    >
    >  > IST1086I APPN CONNECTION FOR AMTKPHL.MSSOBS01 IS ACTIVE - TGN = 8
    >
    > This is now saying that you have established contact - using
    > transmission group (TG) number 8. Only that last part is a bit curious
    > since it is unusual to bother specifying TG numbers. TG numbers in the
    > range 1 to 20 can be specified but it is necessary to do so only for
    > rather special reasons such as multiple connections where one is
    > specifically to carry SSCP-dependent traffic - irrelevant for Enterprise
    > Extender (EE) connections - or in order to use "activation on demand"
    > which requires an independent permanent concatenation of CP LU to CP LU
    > sessions over another path which I suspect does not apply here.
    >
    > If the TG number is determined dynamically, it is is the range 21
    > upwards with 21 for the first connection.
    >
    > -
    >
    > Since you have not shown any time stamps with the messages, it is not
    > clear whether or not this has much to do with your first post. Also you
    > need to go further back in the log to show what the condition which
    > caused the first "SOFT INOP" is.
    >
    > Now it gets puzzling!
    >
    > First I wrote it would also help if you indicated when in the sequence
    > of VTAM messages, you deliberately deactivated the resource correspoding
    > what you identify as the "PU" in HIS. The trouble is that, if this is
    > the "PU" resource which corresponds to the "PU" resource in the "normal
    > (LAN?) DLC" case, it will, in the case of the IP-DLC service, be the
    > *DLUR* PU and not any HIS resource corresponding to the EE connection.
    > The actual EE connection *should* - I am not a HIS specialist so I need
    > to use the word "should" - be quite unaffected by manipulating the
    > status of the DLUR PU.
    >
    > Why by deactivating the DLUR PU you cause a failure of the EE connection
    > is really rather puzzling and perhaps the real HIS specialists have a clue.
    >
    > *If* you had deactivated and reactivated the DLUR PU and there had been
    > unexpected delays without any deactivation of the EE connection, it
    > *should* have been possible for your VTAM specialist colleague to see
    > either - the easy way - using Session Monitor (NLDM) traces or - the
    > hard way - using VTAM buffer traces the progress and timing of the
    > DLUR-DLUS sessions, when they are broken, when they are established and
    > what flows on them in order to check where the delays are. As it is you
    > need to solve the problem with the EE connection first.
    >
    > -
    >
    > In checking your second post, I see that you have the same effect
    > whether your deactivation/reactivation is performed in HIS or in VTAM.
    > In VTAM there are two PU statements, one representing the EE connection
    > which is really an adjacent link station definition - without any actual
    > SNA PU entity in sight! - and one is the PU statement representing a
    > real SNA PU entity, the DLUR PU. To which one of these do you refer?
    >
    > -
    >
    > Incidentally, in case it becomes useful at some stage, you should post
    > all the relevant VTAM definitions, as they were with the "normal DLC"
    > and as they are with the IP-DLC service will probably be most helpful.
    >
    > Chris Mason
     
     
    Friday, September 17, 2010 3:05 AM
  • Chris
      Awsome, I am working with my VTAM guy to research this more and THANK YOU!
     
    Stan
     On 9/16/2010 1:05 PM, Chris Mason in Belgium wrote:
    > Stan
    >
    >  > IST1411I INOP GENERATED FOR EELF1001
    >  > IST1430I REASON FOR INOP IS XID OR LDLC COMMAND TIMEOUT
    >
    > What these two messages tell us is the following as taken from the z/OS
    > Communications Server SNA Messages manual:
    >
    > <adjusted quotes>
    >
    > Explanation: This message (IST1411I) is the first in a group of messages
    > that VTAM issues when an error condition has been detected for external
    > communications adapter (XCA) node resourcename.
    >
    > If the XCA resource is for ... an Enterprise Extender (HPR/IP) resource,
    > VTAM issues the following messages:
    >
    > IST1411I INOP GENERATED FOR resourcename
    > IST1430I REASON FOR INOP IS reason
    > IST314I END
    >
    > resourcename (EELF1001) is the name of the XCA resource where the INOP
    > condition occurred.
    >
    > reason is one of the following:
    >
    > ...
    >
    > XID OR LDLC COMMAND TIMEOUT
    >
    > An XID or LDLC COMMAND to establish an APPN connection across an ...
    > Enterprise Extender (HPR\IP) network did not receive a response after
    > transmission and multiple retries.
    >
    > System action: Error recovery will be attempted for resourcename, and
    > subsequent VTAM messages will indicate the
    > results of the error recovery. Processing continues.
    >
    > Operator response: Enter a DISPLAY ID=resourcename,SCOPE=ALL command to
    > determine the status of the resource. Save the system log for problem
    > determination. Also:
    >
    > - If reason is XID OR LDLC COMMAND TIMEOUT, re-attempt the activation of
    > the APPN connection.
    >
    > ...
    >
    > System programmer response:
    >
    > ...
    >
    > XID OR LDLC COMMAND TIMEOUT
    >
    > During APPN connection establishment, either an XID or an LDLC COMMAND
    > was sent to the remote node. No response was received. The XID or LDLC
    > command was retransmitted multiple times without response.
    >
    > ...
    >
    > Enterprise Extender (HPR\IP): Retry the connection by reissuing the
    > dial. If failure persists, determine if the
    > failure is a result of a system definition error or a network error. If
    > the failure is a result of a system definition error, correct the error.
    > If the failure is a result of a network error, contact the IP network
    > provider.
    >
    > </adjusted quotes>
    >
    >  > IST1141I SOFT INOP FOR SWSRVR1 OVERRIDDEN BY SOFT INOP
    >
    > This is perhaps not all that helpful in that it is telling us that
    > something happened, a "SOFT INOP" condition, which has overridden
    > something that happened earlier, another "SOFT INOP" condition. A "SOFT
    > INOP" is a failure from which recovery is possible in VTAM's judgement -
    > I think since I can't actually find right now where this is specifically
    > stated.
    >
    >  > IST2180I DYNLU = YES FOR AMTKPHL.MSSOBS01 SET FROM SWSRVR1
    >
    > Probably because customers complained that they couldn't follow all
    > VTAM's complicated rules in assisting them with creating definitions for
    > them dynamically, this message is simply saying that the PU statement
    > which first represents contact with the adjacent node provides the DYNLU
    > value for the dynamically created ADJCP, adjacent CP, statement
    > representing the adjacent node - a rather long-winded way of saying
    > nothing of any great significance - assuming you've got the definitions
    > right!
    >
    >  > IST1086I APPN CONNECTION FOR AMTKPHL.MSSOBS01 IS ACTIVE - TGN = 8
    >
    > This is now saying that you have established contact - using
    > transmission group (TG) number 8. Only that last part is a bit curious
    > since it is unusual to bother specifying TG numbers. TG numbers in the
    > range 1 to 20 can be specified but it is necessary to do so only for
    > rather special reasons such as multiple connections where one is
    > specifically to carry SSCP-dependent traffic - irrelevant for Enterprise
    > Extender (EE) connections - or in order to use "activation on demand"
    > which requires an independent permanent concatenation of CP LU to CP LU
    > sessions over another path which I suspect does not apply here.
    >
    > If the TG number is determined dynamically, it is is the range 21
    > upwards with 21 for the first connection.
    >
    > -
    >
    > Since you have not shown any time stamps with the messages, it is not
    > clear whether or not this has much to do with your first post. Also you
    > need to go further back in the log to show what the condition which
    > caused the first "SOFT INOP" is.
    >
    > Now it gets puzzling!
    >
    > First I wrote it would also help if you indicated when in the sequence
    > of VTAM messages, you deliberately deactivated the resource correspoding
    > what you identify as the "PU" in HIS. The trouble is that, if this is
    > the "PU" resource which corresponds to the "PU" resource in the "normal
    > (LAN?) DLC" case, it will, in the case of the IP-DLC service, be the
    > *DLUR* PU and not any HIS resource corresponding to the EE connection.
    > The actual EE connection *should* - I am not a HIS specialist so I need
    > to use the word "should" - be quite unaffected by manipulating the
    > status of the DLUR PU.
    >
    > Why by deactivating the DLUR PU you cause a failure of the EE connection
    > is really rather puzzling and perhaps the real HIS specialists have a clue.
    >
    > *If* you had deactivated and reactivated the DLUR PU and there had been
    > unexpected delays without any deactivation of the EE connection, it
    > *should* have been possible for your VTAM specialist colleague to see
    > either - the easy way - using Session Monitor (NLDM) traces or - the
    > hard way - using VTAM buffer traces the progress and timing of the
    > DLUR-DLUS sessions, when they are broken, when they are established and
    > what flows on them in order to check where the delays are. As it is you
    > need to solve the problem with the EE connection first.
    >
    > -
    >
    > In checking your second post, I see that you have the same effect
    > whether your deactivation/reactivation is performed in HIS or in VTAM.
    > In VTAM there are two PU statements, one representing the EE connection
    > which is really an adjacent link station definition - without any actual
    > SNA PU entity in sight! - and one is the PU statement representing a
    > real SNA PU entity, the DLUR PU. To which one of these do you refer?
    >
    > -
    >
    > Incidentally, in case it becomes useful at some stage, you should post
    > all the relevant VTAM definitions, as they were with the "normal DLC"
    > and as they are with the IP-DLC service will probably be most helpful.
    >
    > Chris Mason
     
     
    Friday, September 17, 2010 3:05 AM