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
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?