none
HIS 2009 IPDLC stop/start & PU recovery issues RRS feed

  • Question

  • Steve
     
    Sorry for the delay. I first had to get some idea how this new facility that has been foisted on us works.
     
    -
     
    Because the HIS support people in their wisdom have *not* reproduced the ongoing threads in this new environment, I am obliged to insert the thread hitherto - as I record it for analysis - here:
     
    <pre-existing thread>
     
    HIS 2009 IPDLC stop/start & PU recovery issues
    ----------------------------------------------
     
    stevek
     
    Testing HIS 2009 IPDLC link in the lab. Ran into situation if you stop then start IPDLC link, peer and host type PU connections stay INACTIVE/FAILED under SNA Manager from previous STOP of HIS link. They show CONCT in VTAM. 
    Have to START each PU connection to get back ACTIVE.
     
    This is different than SNA/SDLC. When you stop then start SNADLC link, the PU connections automatically recover and go ACITVE by themselves.
     
    PU connections are setup with pretty much same values on the VTAM side. If there is a IPDLC link failure in HIS, how do you get PU connections to recover automatically if the IPDLC link recovers? Anyone experience similar
    problem?
     
    ---
    >>>>>
     
    Steve
     
    > Ran into situation if you stop then start IPDLC link, peer and host type PU connections stay INACTIVE/FAILED under SNA Manager from previous STOP of HIS link. They show CONCT in VTAM. Have to START each PU connection to get back ACTIVE.
     
    It would appear you have decided that, of the two adjacent link stations, the VTAM one should be the passive one and HIS should be the active one in terms of which one accepts connections and which one initiates connections respectively. This is a normal arrangement where VTAM and a so-called "distributed" platform are concerned.
     
    However, if it is not possible to have the HIS side recover after a failure, you could so configure the switched PU statement which represents the VTAM side of the Enterprise Extender logical link that it takes responsibility to recover from a failure.
     
    Presumably you are reporting on additional tests with the same configuration which is the subject of the parallel thread "HIS 2009 SNA Manager not updating resource status - VTAM Inact For". If you had provided us with your definitions I could add the necessary statements and operands to your definitions. As it is I can provide you with a template, "before" and "after".
     
    "Before"
     
             VBUILD TYPE=MODEL
    EEMODEL  PU    DYNTYPE=EE,    Enterprise Extender dynamic link station *
                   DISCNT=NO,                   no automatic disconnection *
                   TGP=name             transmission group characteristics
     
             VBUILD TYPE=XCA
    name     PORT  MEDIUM=HPRIP,                       enterprise extender *
                   HPREELIV=YES,             HPR liveness reduction for EE *
                   IPRESOLV=0,                         no resolver timeout *
                   IPTOS=(20,40,80,C0,C0),             EE types of service *
                   LIVTIME=(20,60),                 LDLC inoperative timer *
                   SRQRETRY=4,             short request timer retry count *
                   SRQTIME=3                  short request timer interval
    grpname  GROUP IPADDR=home_address,       VIPA for enterprise extender *
                   AUTOGEN=(n,name,name),              maximum connections *
                   ANSWER=ON,                   allow incoming connections *
                   CALL=IN,                   use for incoming connections *
                   DIAL=YES,                  switched procedures required *
                   DYNPU=YES,          dynamic link station control blocks *
                   KEEPACT=YES      reactivate automatically after failure
     
    "After"
     
             VBUILD TYPE=SWNET
    name     PU    CPNAME=name,                        name of adjacent CP *
                   DISCNT=NO,                   no automatic disconnection *
                   DWACT=YES,                        connect on activation *
                   DWINOP=YES,                        reconnect after INOP *
                   LIMRES=NO,          no automatic deactivation of LU 6.2 *
                   TGP=name             transmission group characteristics
             PATH  IPADDR=away_address,        IP address of adjacent node *
                   GRPNM=grpname,    name of Enterprise Extender XCA GROUP *
                   CALL=INOUT,   use for outgoing and incoming connections *
                   REDDELAY=60,         interval between reconnect retries *
                   REDIAL=FOREVER             retry automatic reconnection
     
             VBUILD TYPE=XCA
    name     PORT  MEDIUM=HPRIP,                       enterprise extender *
                   HPREELIV=YES,             HPR liveness reduction for EE *
                   IPRESOLV=0,                         no resolver timeout *
                   IPTOS=(20,40,80,C0,C0),             EE types of service *
                   LIVTIME=(20,60),                 LDLC inoperative timer *
                   SRQRETRY=4,             short request timer retry count *
                   SRQTIME=3                  short request timer interval
    grpname  GROUP IPADDR=home_address,       VIPA for enterprise extender *
                   AUTOGEN=(n,name,name),              maximum connections *
                   ANSWER=ON,                   allow incoming connections *
                   CALL=INOUT,   use for outgoing and incoming connections *
                   DIAL=YES,                  switched procedures required *
                   DYNPU=YES,          dynamic link station control blocks *
                   KEEPACT=YES      reactivate automatically after failure
     
    where n is equal to or more than the expected number of connections
     
    I have copied the performance-related parameters from a recent project. They are not always the defaults.
     
    >  If there is a IPDLC link failure in HIS, how do you get PU connections to recover automatically if the IPDLC link recovers?
     
    One solution is shown above.
     
    This could solve the "reconnection" problem with the Enterprise Extender logical link. Once that problem is resolved, you can then check what happens in the case of the DLUS-DLUR logical link. If this does not recover automatically, similar changes could be tried out in the definitions for this logical link. Let us know if that is necessary.
     
    > This is different than SNA/SDLC. When you stop then start SNADLC link, the PU connections automatically recover and go ACITVE by themselves.
     
    As I'm sure the Microsoft HIS specialists will tell you, there is so much difference between the "IP-DLC Link Service" and earlier types of "Link Service" that it is not really logical to expect essentially identical behaviour especially since two different types of logical connection are involved.
     
    > PU connections are setup with pretty much same values on the VTAM side.
     
    Which of the two PU definitions used with the "IP-DLC Link Service" is "pretty much the same" as with the "DLC Link Service"[1] case? The Enterprise Extender PU statement - the one I show above - relates to a vastly different technology. The DLUR PU statement also cannot logically be compared.
     
    As I have said before, it will help in commenting on your problems when you show us the definitions you use, possibly indicating any variations you have tried.
     
    Chris Mason
     
    ---
     
    Stephen Jackson
     
    Steve,
     
    I just tried this and my connections stayed in a Pending/Failed state for over an hour. I then came back and started the link service again and the connections went Active.
     
    Did you change any of the default IP-DLC link service parameters in the link service properties? Did the connections drop to Inactive/Failed immediately?
     
    Also, as far as I can recall we have never recommended stopping a link service (DLC or IP-DLC) manually. The link services are setup to start and stop as the SNA Server service is started and stopped. I'm pretty sure that we don't do any testing with this type of scenario.
     
    ---
     
    stevek
     
    Steve,
     
    We have done similar testing in the past to mimic what would happen on failures at the HIS end, including the link. When I tested HIS 2006 SNA DLC links under the services area, the PU connections always recovered to ACTIVE
    status within a couple seconds. I thought I could do similar testing with the HIS 2009 IPDLC link service and PU connections.
     
    The IPDLC link "PU connections" don't come back until you manually start them within HIS Manager. The PU connections we use for SNA DLC and IPDLC are very similar except of course where we have a keyword and value for something IPDLC.
     
    I remember you pointing out about keeping the default timer values before. We are using the default IP-DLC link service parameters in the link service properties: Advanced Tab - IP-DLC timeouts, maximum BTU size, HPR/IP
    activation retries. 
     
    When the stop the IPDLC link under services, it stops immediately. When I start it, it starts immediately. SNA Service 1 is not affected by the stops and starts. IPDLC link service is left as manual as well as manual when we
    stop/start SNA DLC link services.
     
    STOP TEST
    02:02:20 PM SNA IP-DLC Link Service (event 590) - service terminated by administrator
    02:02:20 PM SNA Server (event 23) - three of these for PU connections (host or peer). For example: Connection Failure, Connection =PN0BEET0, Link Service=SNAIP1.
     
    START TEST
    02:03:04 PM  SNA IP-DLC Link Service (event 626) - service started.
    Then there we sit with each of the PU connections under SNA Service 1 showing [Inactive] (Failed @ 14:02:20)
     
    On the host, in LANEET0B we have the main EE PU connection setup.  That responds correctly immediately to me stopping and starting the IPDLC link on the HIS service. It is the other PU connections in LANEETSK switched major node that do not come back active. I think I saw something on the web that says you should keep the IPDLC PU connection separate from the other PU connections but you can comment on this if it is wrong. 
     
    Can you make sure that Microsoft HIS has never had an adverse situation with the link service failing at the server end. Maybe, we do overkill testing, but we have always documented this in our HIS test procedures before going live.
     
    Also, at this point with HIS 2010 beta, it might be worthwhile to switch to HIS 2010 beta code if we can get it from Microsoft. I will talk to Manager and the project lead to see if we can switch. Approximately when would HIS 2010 go GA?
     
    It is now 3:12 PM and the PU connections under SNA Manager have not changed. Will entertain any suggestions you have.
     
    ---
     
    Stephen Jackson
     
    My first test was on a HIS 2006 SP1 (x64) system. I just tried on a HIS 2009 (x86) system. In this case, the "Host" connection dropped to Inactive/Failed and the Peer connection to Incoming/Failed and then it went to
    Pending/Failed.
     
    Once I started the SNAIP1 link service (net start snaip1), both connections activated automatically within a few seconds.
     
    I'm not sure why you are seeing different behaviour.
     
    It might take some tracing to see what it happening in your case.
     
    ---
     
    Steve,
     
    You just provided something that changes the circumstances by mentioning the Net commands. Instead of stopping/starting SNAIP1 under the Windows 2008 64 bit services area, I am using NET STOP SNAIP1 and NET START SNAIP1 under command prompt. There are differences.
     
    With all PU connections ACTIVE under SNA Manager, I issue a NET STOP SNAIP1. SNAIP1 stops and all PU connections go inactive, failed state. When I issue a NET START SNAIP1, the PU connections that are REMOTE END "HOST" come ACTIVE now within a few short seconds. You must refresh SNA Manager to get current state.
     
    However, the one PN0BEET0 PU that is REMOTE PEER based stays inactive, failed and does not come ACTIVE. There are 3 remote APPC CICS definitions in HIS server tied to PN0BEET0 but we are not using them for sessions at this time. 
    On HIS server, PN0BEET0 is setup as:
     
    Name - PN0BEET0
    Link Service - SNAIP1
    Comment - anything, doesn't matter
    Remote end - Peer system
    Allowed directions - Both directions (greyed out)
    Activation - On server startup (greyed out)
    Affiliate application - None
    Support dynamic remote APPC LU definition - we are not using this right now
     
    We usually don't use NET commands to control link service failure testing but this has changed everything. I now get consistent recovery on the "host" PU connections that are connected with SNAIP1 link service.
     
    Should everything be in one switched major node or two like currently defined in VTAM? Either way, PN0BEET0 does not come back Incoming or Active.
     
    When your use to SNA SDLC links and HOST PU connections, this is very interesting
     
    ---
    >>>>>
     
    Steve
     
    The only possible use for partitioning switched PU statements (and associated PATH and LU statements) between switched major node members is to be able to (try to) inactivate the resources at the level of the major node. In the dim and distant past, I seem vaguely to remember needing to do something like this in order to "force" deactivation. If my memory serves me correctly, enhancements in the V INACT command long ago removed the need for this subterfuge.
     
    Thus the recommendation from a long-time VTAM specialist is that this use of one or two switched major nodes is irrelevant and has no *technical* significance whatsoever.
     
    Chris Mason
     
    ---
     
    Stephen Jackson
     
    I get the same behaviour on the when using "Net Stop/Net Start" or when stopping/starting the service in the Services MMC Snap-in. This was one three different systems. In each case, the host and peer connections start
    automatically once the service is started.
     
    W2K8 (x64)/HIS 2009
    W2K8 (x86)/HIS 2009
    W2K3 (x64)/HIS 2006 SP1
     
    Strange.
     
    What do you see in the Application Event Log when you stop and start the service?
     
    ---
     
    stevek
     
    Chris,
     
    I work on several products so sorry for delays in getting back on some things. Also, I will be switching to forums/blogs as newsgroups are being shut down including this HIS one.
     
    In response to your comment about using two separate switched major nodes, thanks. I'll stick with just one for now.
     
    Have to look at VTAM startup member yet but here are the key values we have set for APPN EE testing with Microsoft HIS 2009 server.
     
    Host Networking Group has following definitions in place for VTAM
     
    1234567890
    XCACMC1  VBUILD TYPE=XCA
    PCMC1    PORT  MEDIUM=HPRIP
                   SAPADDR=04
                   SRQTIME=15
                   LIVTIME=15
                   SRQRETRY=9
     
    Within VTAM Member LANEET0B are the following definitions:
     
    LANEET0B VBUILD TYPE=SWNET
    EE0BILAB PU    IDBLK=017,IDNUM=EE00A
                   DYNLU=YES
                   ADDR=C1
                   CONNTYPE=APPN
                   CPCP=YES
                   ANS=CONT
                   DLOGMOD=S3278M2
                   MAXDATA=1033
                   MODETAB=VTMBIND
                   SSCPFM=USSSCS
                   USSTAB=VTAMUSST
                   PACING=7
                   MAXOUT=7
                   PUTYPE=2
     
    TB00ILAB PU    IDBLK=017,IDNUM=EE00B
                   DYNLU=NO
                   ADDR=C1
                   ANS=CONT
                   DLOGMOD=S3278M2
                   MAXDATA=1033
                   MODETAB=VTMBIND
                   SSCPFM=USSSCS
                   USSTAB=VTAMUSST
                   PACING=7
                   MAXOUT=7
                   PUTYPE=2
     
    Followed by some test LU2, LU6.2 independent, and LU6.2 dependent definitions.
     
    Per a posting by Steve Jackson with Microsoft, I don't know why I get differences in PU host/peer recovery when stopping/starting IPDLC link service under server services area as opposed to using NET START/NET STOP of
    the IPDLC link. Will start looking at HIS tracing.   
     
    Will share what you presented with our Host Network Group that takes care of VTAM. Don't know what all the non-defined defaults are yet in the book but KEEPACT=YES is one that looks interesting.
     
    </pre-existing thread>
     
    > In response to your comment about using two separate switched major nodes, thanks. I'll stick with just one for now.
     
    I think you have misunderstood me. The point I was making here was that whether or not your "switched" PU statements were in one or two major nodes was effectively irrelevant.[1]
     
    Regarding whether or not there should be any changes to your VTAM definitions:
     
    a) You didn't show a VBUILD TYPE=XCA GROUP statement but I expect that will be essentially the same as I posted before - but perhaps with DYNPU=NO, a change I should have made.
     
    b) I assume you intend to stay with the structure which has the HIS side initiating the connection and the VTAM side accepting the connection both for the Enterprise Extender (EE) connection and the DLUR-DLUS connection.
     
    c) I am going to list some changes you should make but these are "cosmetic" and do not affect whether your definitions work or how they work.
     
    Thus you need to have the Microsoft specialists follow up on why the HIS side does not work as you expect.
     
    The one caveat I would suggest is that my understanding - to be corrected by the Microsoft specialists if incorrect - is that the LAN DLC Service belongs to a set of software which supports the Low Entry Networking (LEN) implementation of an SNA node and the IP-DLC Service belongs to an additional set of software which is itself an APPN implementation of an SNA node run alongside, as it were, the LEN SNA node software. It is not at all surprising that, given that the two sets of software are from different "stables", they behave from a little to a lot differently.
     
    It will actually be very interesting to hear the opinion of the Microsoft specialists on this matter.
     
    -
     
    As I mentioned, your VBUILD=XCA major node is incomplete. It should have at least one - and probably only one - GROUP statement. However, it will probably look very much like the following:
     
    name     GROUP IPADDR=aaa.aaa.aaa.aaa,    VIPA for enterprise extender *
                   AUTOGEN=(nn,prel,prep),             maximum connections *
                   ANSWER=ON,                   allow incoming connections *
                   CALL=INOUT,   use for outgoing and incoming connections *
                   DIAL=YES,                  switched procedures required *
                   DYNPU=NO,        no dynamic link station control blocks *
                   KEEPACT=YES      reactivate automatically after failure
     
    Note that the KEEPACT=YES which you find interesting is to deal with the Communications Server (CS) IP component becoming inactive and then activating again. The "line resources" defined using the VBUILD=XCA major node will take on INACT status and KEEPACT=YES, which is the default value by the way, causes the "line resources" to become active again automatically when the CS IP component becomes active again.
     
    Assuming that you intend always to define your switched PU statement which represents the EE adjacent link station rather than have it defined dynamically for you, I have specified DYNPU=NO.
     
    -
     
    Since the PU statement named EE0BILAB is *not* followed by any SSCP-dependent LU definitions I assume it must be the PU statement used to define the EE adjacent link station. As such it needs only to be specified as follows:
     
             VBUILD TYPE=SWNET
    EE0BILAB PU    IDBLK=017,IDNUM=EE00A,                   identification *
                   CONNTYPE=APPN,                  APPN is to be supported *
                   CPCP=YES                         request CP-CP sessions *
                   DYNLU=YES                    dynamic creation of CDRSCs *
                   DISCNT=NO,                   no automatic disconnection *
                   LIMRES=NO,          no automatic deactivation of LU 6.2 *
                   TGP=name             transmission group characteristics
     
    Actually I am surprised that you are using the IDBLK and IDNUM operands rather than the CPNAME operand as a means of identification. If you are using them and they work, fine. I haven't used those operands for connections of any sort between APPN (or Low Entry Networking (LEN) before it) nodes ever - although I was aware they worked as a migration aid from what were previously subarea peripheral nodes - back in the 1980s.
     
    It's normal to rely upon the CONNTYPE and CPCP start options rather than specifying those parameters as PU statement operands - but there's no other reason not to specify them as operands.
     
    It's also normal to rely upon the DYNLU=YES start option rather than specifying those parameters as PU statement operands but this is a little bit more complicated that in the case of CONNTYPE and CPCP. Strictly the DYNLU parameter belongs on an ADJCP statement in a VBUILD=ADJCP major node. However, if you specify the DYNADJCP=YES start option, your ADJCP control blocks are created dynamically and the DYNLU operand value has to be obtained from somewhere. Thus, if an ADJCP control block is created dynamically, the rule is to obtain the value of the DYNLU parameter from the PU statement which represents the *first* connection to the adjacent APPN node. Clearly, if the PU statement does *not* specify the DYNLU operand, the value of the DYNLU start option is used.
     
    So, although you have specified all of the ADDR, ANS, DLOGMOD, MAXDATA, MODETAB, SSCPFM, USSTAB, PACING, MAXOUT and PUTYPE operands, these do not add anything to your definition and generally just get in the way of seeing what is important should anyone want to review them in order to solve a problem or examine any opportunity to improve performance.
     
    Let's look at them all.
     
    PUTYPE=2 is valid but is default and will never be changed. In that sense it is a bit like ISTATUS=ACTIVE which is the default and is most unlikely ever to be considered for change. You haven't specified ISTATUS=ACTIVE but that is the one operand I usually list with PUTYPE=2 as valid but almost certainly or definitely pointless to specify.
     
    ADDR is mistakenly specified in the manual as required. It is not and has not been so for very many releases of VTAM.
     
    ANS is relevant only in the context of a resource supported by NCP and, in fact, DLUR.
     
    MAXDATA and MAXOUT apply only to media other than EE. MAXDATA never applies to a connection between APPN nodes and MAXOUT only when NCP is supporting media such as token ring.
     
    I'm happy you do *not* include IRETRY and PASSLIM which I so often see in samples such as this but which apply only to nodes connected through SDLC nonswitched multipoint media - a very far cry from EE!
     
    DLOGMOD, MODETAB, SSCPFM, USSTAB and PACING relate only to following LU statements and you don't have any of these.
     
    Now, let us examine the operands you have *not* specified but are really relevant:
     
    You ***always*** should specify transmission group characteristics for an APPN connection - within the definitions which apply to both partners since one set of characteristics applies in one direction and another set in the other direction  - and both ought to be the same for the same connection.
     
    Thus you need to specify the name of a "profile", a "transmission group (TG) profile" (TGP), for those characteristics which most characterise the connection. These are the CAPACITY (in effect "speed"), PDELAY (propagation delay) and SECURITY characteristics. The cost characteristics, COSTBYTE and COSTTIME, default to "0" and may possibly apply. The "<whatever you think additionally might be relevant according to some private understanding within your APPN network>" so-called "user" characteristics, USER1, USER2 and USER3 are rarely if ever used for the obvious reason that to coordinate their use throughout an APPN network would be very cumbersome.
     
    The TG characteristics are used in conjunction with the COS name in order to select a path through the APPN network. The choice can be there are no suitable paths which might apply if a SECURITY characteristic other than "UNSECURE" (should have been "INSECURE" but there was some failure in the education of the responsible SNA architect!) were present in the COS - or - if there are many paths, the path which scores the least weight out of many will be selected. Of course, if there is only one path and it manages to avoid the "security" trap, that will be selected - and this, I expect, is what happens nearly always - except where a connection network has been defined ...
     
    DISCNT=NO is default but, if you specify it, it can be used to disconnect the EE logical link when no RTP pipes are using it. You *may* find a use for that function.
     
    LIMRES=NO is also default. LIMRES=YES is used to cause LU type 6.2 sessions to be terminated when they are no longer servicing "conversations". It is a prerequisite for being able to use DISCNT=YES or DISCNT=DELAY with success when SSCP-independent LU 6.2 sessions could be being supported.
     
    -
     
    Since the PU statement named TB00ILAB *is* followed by SSCP-dependent LU definitions - as I assume you mean to indicate by your comments - I assume it must be the PU statement used to define the DLUR adjacent link station. As such it needs only to be specified as follows:
     
             VBUILD TYPE=SWNET
    TB00ILAB PU    IDBLK=017,IDNUM=EE00B,                   identification *
                   ANS=CONT,              continue sessions when DLUS lost *
                   DISCNT=NO,                   no automatic disconnection *
                   DLOGMOD=S3278M2,               default mode table entry *
                   MODETAB=VTMBIND,                     private mode table *
                   SSCPFM=USSSCS,            SCS USS commands and messages *
                   USSTAB=VTAMUSST,              USS commands and messages *
                   PACING=7                       secondary receive pacing
     
    Since this PU statement will never be associated with the first contact to an adjacent node's CP, the DYNLU operand has no meaning.
     
    The ADDR, MAXDATA and MAXOUT operands have no function for the logical connection from the DLUR function in the HIS node to the DLUS function in the VTAM node.
     
    The same comments as given for the other PU statement apply also to the PUTYPE (and ISTATUS) operands of the PU statement.
     
    > Followed by some test LU2, ..., and LU6.2 dependent definitions.
     
    The remaining operands provide defaults for following LU statements, generally more for your SSCP-dependent LU type 2 statements than for your SSCP-dependent LU type 6.2 statements. The latter will be understood to use SSCPFM=FSS if not actually specified and no doubt a mode table entry other than S3278M2 will be specified.
     
    > Followed by some test ..., LU6.2 independent, ... definitions.
     
    I expect you have defined the SSCP-independent LU type 6.2 statements with LOCADDR=0. Thus you oblige VTAM to convert it into a CDRSC control block. If you display the name of your SSCP-independent LU type 6.2 statements you will note that VTAM considers them to be CDRSCs defined in major node ISTPDILU.
     
    From the z/OS Communications Server SNA Network Implementation Guide:
     
    <quote>
     
    Note: The ISTPDILU major node contains CDRSC definitions for independent LUs that are converted from LU definition statements by VTAM. The ISTPDILU major node is automatically activated by VTAM on initialization and cannot be activated or deactivated by operator commands.
     
    </quote>
     
    If you want properly to represent what you have defined using LOCADDR=0 in your VTAM definitions, you need to convert the LU statement as follows:
     
    puname   PU    ...
    luname   LU    LOCADDR=0,...
     
    to the CDRSC statement as follows:
     
    luname   CDRSC ALSLIST=puname,...
     
    and define it in a CDRSC major node.
     
    You should be able to specify all relevant LU (with LOCADDR=0) operands as operands of the CDRSC statement. The exception is, of course, LOCADDR=0 and you will need to specify the name of the superior PU statement in the ALSLIST operand.
     
    However, it may just be easier simply not to have any definition statement at all for the SSCP-independent LU since it is the intention of APPN that SSCP-independent LUs should be defined dynamically. Such dynamic definition is why the DYNLU=YES start option or operand exists. In order to make sure that your private mode table is available for such dynamically defined CDRSC control blocks, you should specify the name in the DYNMODTB start option, for example DYNMODTB=VTMBIND. Note that it is intended that pacing should be fully dynamic using the adaptive pacing mechanism.
     
    One other point that needs to be covered in order to have CDRSC control blocks created dynamically is to make sure that you have *not* specified ALSREQ=YES in your start options or you have explicitly specified ALSREQ=NO.
     
    Chris Mason
     
    [1] I have dim memories - probably getting on for 30 years ago - when such separation might have been useful as a means selectively to force VTAM to forget about some resources which had got stuck in a status which prevented VTAM from disposing of them - or something like that.
    Saturday, June 12, 2010 2:45 AM

Answers

  • As promised here are the changes that resolved the symptoms that were being described when stopping the switched major node that the HIS IP-DLC connections were using:

    Reconfigured Host connection IPDLC properties: Set "Connection retry limits" and "DLUR retry limit" from "UNLIMITED" to default settings "LIMITED" '8 times' with "Delay after retry" set for '10 seconds'.

    Note: The default setting had been changed so that the IP-DLC connection never stopped trying to reconnnect, thus the status stayed Active.

    Thanks...

     


     

    Stephen Jackson - MSFT

    Thursday, June 17, 2010 2:49 PM

All replies

  • It wasn't HIS support that made the decision about ending the newsgroup and moving to forums and we had no say if the olds threads would move. <g>

    My understanding is that this issue has been resolved per a support case that Steve opened up. I believe that the issue was related to a couple of factors.

    Maybe Steve will update this thread with the resolution. If not, I will make sure that it gets posted sometime next week.


    Stephen Jackson - MSFT
    Saturday, June 12, 2010 12:55 PM
  • Chris,
     
    If you are/were an NNTP user for the newsgroups check out the below to
    carry on using the forums via your original nntp client. Works great
    (and better than the MS provided equivalents)
     
     
     

    Neil Pike
    Sunday, June 13, 2010 10:30 AM
  • As promised here are the changes that resolved the symptoms that were being described when stopping the switched major node that the HIS IP-DLC connections were using:

    Reconfigured Host connection IPDLC properties: Set "Connection retry limits" and "DLUR retry limit" from "UNLIMITED" to default settings "LIMITED" '8 times' with "Delay after retry" set for '10 seconds'.

    Note: The default setting had been changed so that the IP-DLC connection never stopped trying to reconnnect, thus the status stayed Active.

    Thanks...

     


     

    Stephen Jackson - MSFT

    Thursday, June 17, 2010 2:49 PM
  • Stephen
     
    Thanks for resolving the mystery as it appears now to be described. What you now describe does not seem to correspond to the public exchange of information but this is very often the problem with moving a public exchange, in which your whole subscriber population are probably taking an interest, private.
     
    So "stevek" was complaining that he had an "active" status on the HIS side in spite of the fact there had been a disconnection - in this case deliberately caused by deactivating the PU statement on the VTAM side - because HIS was continuing to retry to connect following the disconnection. I guess this makes sense.
     
    There is still no explanation of how the parameters "stevek" was using with his "LAN DLC Link Service" which he attempted to map to his use of the "IP-DLC Link Service" should have been mapped in order to experience the same behaviour. I took this to be the objective of the whole exercise.
     
    > ... the symptoms that were being described when stopping the switched major node that the HIS IP-DLC connections were using
     
    Note that it is the deactivation of the resource represented by the PU statement, the adjacent link station in SNA terms, that caused the disconnection. This happens because the major node in which the PU statement is defined was deactivated - as you state - since it is a requirement that subordinate resources must be deactivated - gracefully or disgracefully! - before a superior resource is deactivated.
     
    The above may be "sense" but your so-called "VTAM configuration issue" is nonsense on several levels.
     
    > Changed the IPDLC switch major node PU from Type 2.0 to PU Type 2.1.
     
    What is this supposed to mean?
     
    As I have said until I could be accused of being some ancient druid, there is no such thing - never was, never will be - as a PU type 2.1 - it hurts my fingertips every time I have to mention this![1]
     
    There is also actually no such thing as a PU type 2.0. There is only a PU type 2.[2][3]
     
    But, whether or not this is SNA terminological nonsense, I have no idea what you could possibly mean! Note that the terminological nonsense is irrelevant and, while the red mist it induces might obscure my understanding, it probably doesn't obscure that of anyone else reading this trying to benefit from it by making sense of it!
     
    The only operand which relates to the "type of PU" is the PUTYPE operand and this takes the value 1 or 2.[3] It very clearly does not take the value "2.0" or "2.1".
     
    Now, if we are talking *node* types as opposed to *PU* types - never let it be said I do not try to make sense of what you are saying although I normally have to do so with original posters whose first language is not English rather than one of the resident gurus - it is actually not possible to cause a change of appearance of a node over a connection to an adjacent node. A node determines whether or not an adjacent node is a type 2.0 node or a type 2.1 node based on the format of the "exchange identification" (XID) received from the adjacent node over the newly established connection.
     
    Thus it is never in your gift to decide whether a node is a type 2.0 node or a type 2.1 node, the nodes themselves determine this based on the level of the implementation of the software that drives the connection logic.
     
    I am even more at sea over your referring to a *major* node. There are no definition aspects to a major node - unless you count the name which has no technical effects.
     
    > Note that this particular change alone did not change symptom though did affect how fast the PU displayed an ACTIVE status when IPDLC switch major node PU is activated.
     
    If we have a description of to what you are referring here, it might be possible to says whether or not there was likely to be any effect on anything. Again, I am totally flummoxed over how there could be any influence on the speed of anything happening!
     
    Incidentally, there is no such thing as an "IPDLC switch major node" - maybe this happens to be the way you and "stevek" think of the major node with BUILD TYPE=SWNET which happens to contain the PU statement representing the Enterprise Extender (IPDLC) adjacent link station.
     
    Chris Mason
     
    [1] VTAM development folk will tell you if pushed that the frequent appearance of this chimera in manuals and messages is a mistake - but they probably immediately remove the hair-shirt they put on as soon as you are gone! They will also admit that LOCADDR=0 is a bit of a nonsense - and a nuisance for understanding - but their grounds are a little more solid here - and actually somewhat based on architecture if you regard the "0" as meaning dynamic!
     
    Just to avoid acrimonious and fruitless arguments, if you wish to try to defend the use of this abominable term, you must try to explain what it may mean. You might try "a type 2.1 PU is an SNA PU entity contained in a Type 2.1 node and a type 2.0 PU is an SNA PU entity contained in a Type 2.0 node" but then you'd be obliged to explain how the nature of the PU entity changed because of the type of node in which it resided. At this point, you'd find yourself grasping for smoke. There is *no* difference, the PU entity is simply a type 2 PU indifferent to whether or not it resides in a type 2.0 node, where it is inevitably found, or in a type 2.1 node, where it might be found in those cases of a type 2.1 node which incorporate the function of a type 2.0 node.
     
    You could muddy the water by mentioning a type 2 PU supported by means of a DLUR function - very relevant to this thread actually. However, the DLUR function is an LU 6.2 application as far as the type 2.1 node is concerned and the purity of its type 2.1 node capabilities is unsullied by the presence of type 2 PU entities "hidden" by the DLUR layer.
     
    [2] In the mists of time there used actually to be a device which was required to be defined as a PU type 1, the fondly remembered 3767.[4] More recently, but fading away along with NCP, NCP and its accretions such as NPSI needed to define internal resources which behave in the manner of the type 1 PU as far as VTAM was concerned and so such internal resources were defined with PU statements with PUTYPE=1.
     
    [3] In the context of connections to HIS which use LEN or APPN protocols. In the context of connections using subarea, that is, VTAM to VTAM, VTAM to NCP and NCP to NCP, the PUTYPE operand can specify 4 or 5 - it actually doesn't matter which.
     
    [4] There was also a peculiar and relatively short-lived flavour of 3271, IMMSMC.
    Thursday, June 17, 2010 7:25 PM
  • I corrected my last update with the resolution to the problem. The change to the PU in VTAM did not result in any quicker recovery times after the switched major node was brought back online. The solution was simply to correct the DLUR retry timers. Thanks...
    Stephen Jackson - MSFT
    Wednesday, June 23, 2010 6:41 PM