Steve
Post by stevekWe are trying to mimic a failure on the VTAM side with correct status
update by SNA Manager.
I see your tests are oriented to seeing what happens when there are failures
on the side remote from HIS. This would be one of
- the z system CEC
- the z system LPAR
- z/OS
- the Communications Server SNA component (VTAM)
- the Communications Server IP component
- the OSA feature port - not mentioned but assumed as the adapter which
connects to the IP network
- the IP network itself such as a failing router where there was no backup
within the network
As far as HIS is concerned, it doesn't matter which of these fails and the
easiest for testing purposes is to "STOP" the OSA interface - or whatever
type of interface supports the Enterprise Extender (EE) logical link, the
type of link supported by the IP-DLC Link Service. In case you have some
redundancy, you should ensure that only one port is active before you enter
the "STOP" command.
Primarily, in VTAM terms, this will affect the status of the adjacent link
station represented by the PU statement B in the set of definitions I
provided in my previous post. If you have a PU statement which is defined
statically - as opposed to a model PU statement with DYNTYPE=EE, for
example, the status will become CONCT. You should see a change in status of
some resources or other in HIS - one of the HIS specialists can help you
here. If you have broken the link and the status of the relevant entity in
the HIS definitions does not change, then you have a matter to take up with
the Microsoft HIS support.
You will be able to prove to yourself that there is no possibility for the
HIS "side" to communicate with the "VTAM" side if a PING command to the OSA
or whatever interface IP address or the static VIPA supporting EE fails.
This is the key test.
There is also the set of statements which represent the SSCP-dependent PU
and SSCP-dependent LUs and, to be very strict, the statement which
represents the SSCP-dependent PU also represents the logical adjacent link
station supported by the DLUS-DLUR pair of sessions with mode name CPSVRMGR.
When you break the EE logical link, you should see the pair of sessions
between the HIS (IP-DLC Link Service) CP (DLUR function) and the VTAM SSCP
(DLUS function) fail. Because these sessions fail, the logical link
supporting the SSCP-dependent resources fails and so the SSCP-dependent
resources take on the status CONCT in VTAM. Likewise there should be a
comparable change in
status in HIS with which the HIS specialists can guide you.
You may like to repeat the test - after using the "START" command on the OSA
or whatever interface - while sessions are active with the DLUR-supported
SSCP-dependent LUs.
Note that testing a failure only of the DLUR-supported SSCP-dependent
resources is a waste of time since there is a vanishingly small possibility
that the DLUS function within VTAM would fail independently of VTAM as a
whole.
It may help us all with the analysis if you posted the VTAM definitions you
are using.
-
Probably less important but it always pays to be very clear about
definitions.
Post by stevek... LAN switched major node ...
There is no such major node as a "LAN switched major node". There is a
*switched* major node characterised with VBUILD TYPE=SWNET and, not for z/OS
but for VM and VSE support of the "Integrated Communications Adapter" (ICA),
there is a LAN major node characterised by VBUILD TYPE=LAN. You are running
EE so you are running the SNA component of z/OS Communications Server and
thus you do *not* have a LAN major node.
-
Post by stevekUpon issuing a VTAM inact (force or immed) to Lan switched major node, ...
Why I wonder do you use the VTAM V NET,INACT command? This does ***not***
simulate a failure - as I see you persist in claiming in a later post. It
merely indicates to both VTAM and the affected resources that you want the
resource to become inactive - gracefully or perhaps disgracefully!
TYPE=IMMED (or TYPE=UNCOND)
The idea behind this type of deactivation is that any sessions are broken in
a way which indicates they should end immediately. However there will be a
delay in order to allow application programs to perform necessary activity
before a session is terminated.
If there are no sessions this is no different from deactivation without the
TYPE=IMMED qualification.
TYPE=FORCE
You should, in general, *not* use this command. It is a command which can
lead to needing to restart VTAM because it can cause VTAM's understanding of
the status of a resource to be different from the understanding the resource
has of its status. As with other deactivation operations, whatever SNA
requests would normally be sent to a resource in order to cause it to become
inactive are sent but VTAM doesn't bother about whether or not there is a
response. Normal SNA processing is for VTAM - playing the role of the SSCP -
to send a request to a resource and, when the resource receives the request,
it sends a response. At this point the resource considers itself inactive
and, when the response is received, VTAM considers the resource inactive.
Obviously VTAM not bothering about receiving the response can lead to status
mismatches.
-
What advantage do you imagine there could be in putting different switched
PU statements in different major nodes? By and large, major nodes are a way
administratively to manage VTAM resources. There are no technical
implications.
-
You still haven't explained what changes you made to EE (IP-DLC) parameters
and what effect you expected such changes to have.
-
From a later post
Post by stevekTB00ILAB PU with test dep & indep. LU6.2, ...
Is the LU identified as "LU6.2", SSCP-dependent (LOCADDR=>0) or
SSCP-independent (LOCADDR=0)? If the later and the PU to which you refer is
the DLUR PU, you need to treat it quite separately. This is another topic so
I won't go into it further now. If you issue a D NET,E,ID=name command,
where "name" is the name of the LU statement with LOCADDR=0, you will see
that the resource is a CDRSC. You will need to follow up on that fact. If
you need help so doing please post again and we'll deal with it when this
current problem is solved or goes into some form of stasis.
-
I hope one of the HIS specialists will explain the significance of events
533, 357, 115, 660 and 307.
Chris Mason
Post by stevekNeil,
We are trying to mimic a failure on the VTAM side with correct status update
by SNA Manager.
Here's another test I just ran this morning. Instead of keeping everything
in ONE LAN switched major node, I seperated the main IPDLC link PU definition
for SNA Service one in its own VTAM member and put all the other PU
connections (SNA hosts and 1 Peer) in a separate VTAM switched major node
member. HIS SNA Manager correctly reflects taking down the switched major
node with the PU connections. A little better.
However, inactivate the switched major node with the IPDLC PU link
definition in it and SNA Manager does not reflect that we had a drop on the
VTAM side. Still shows ACTIVE in SNA Manager no matter how long you wait for
a status update, refresh the screen or open/close SNA Manager.
Would Microsoft entertain looking at this further per chance this is a
problem?
Post by Neil PikeSteve - no not ever seen that myself, but don't recall ever
deliberately making the VTAM resources go INACT.
Neil Pike
Protech Computing Ltd