Asher

I made the point about your changing from using XID 3 to XID 3 because
this is definitely a step backward in general. There was only a slight
possibility that this change related to your problem.

It is clear you do not have a good grasp of the difference between and
the significance of XID 0 and XID 3. To remedy this situation, take a
look at Chapter 3 of SNA Formats:

http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL
=GA27-3136-20

I make this claim based on your comment "(No more CPNAME and so on)".
When you use connections to VTAM over a LAN, you use "switched" as
opposed to "nonswitched" definitions in VTAM. When you use "switched"
definitions, you use PU statements in a Switched Major Node. There has
to be some matching between such a PU statement and an incoming
connection attempt - I'm leaving aside the possibility to use the
ISTEXCCS exit or the DYNPU=YES function[1]. With XID 0, you are
obliged to match on the basis of the "node identification" field of
the XID - which is common to all XID formats. This breaks down into
two parts which are represented in operands of the PU statement as the
IDBLK and IDNUM operands. If you are using XID 0, you must be using
these operands on your PU statement - or if you are not, please let us
all know what you are doing!

When you were using XID 3, you appear to have been using the PU
statement CPNAME operand. Perhaps you were not aware that, having
specified the CPNAME operand, you no longer needed the IDBLK and IDNUM
operands and, indeed, specifying all of them probably led you to
assume that VTAM was imposing excessive definition activity on you, a
reputation VTAM has spent most of its working life - since the bad old
days of the late seventies! - trying to shake off!

As for the "so on", if you examine the fields in the XID 3, you could
see - if you had the necessary education - that a number of the
operands of the PU statement were no longer needed. A number of
seemingly needed parameter matches - matching additional to that
required for identification - evident in the operands of the PU
statement is *removed* by use of the XID 3. Thus there is no "so on".
In changing from XID 3 to XID 0, you may find that some of the 802.2
parameters which were passed automatically in XID 3 now need
explicitly to be specified with XID 0. Clearly in going from XID 3 to
XID 0 you lay yourself open to getting such matches wrong. SNA
designers went to a lot of trouble in creating XID 3 as an enhancement
to XID 0.

I expect that the significance may not be clear from the information
provided by the HIS product and that the HIS documentation is not
clear enough. I participate in this newsgroup in order to "catch" the
VTAM and SNA issues rather than solve problems deep within HIS - about
which I know very little. This XID 0/XID 3 "thing" is very definitely
an SNA issue - and also maybe a VTAM issue - that needs addressing!

However, you seem to have got some sort of wrong impression that XID 3
applies only when using APPC/LU 6.2 in the context of SSCP-independent
LU (ILU) definitions. This is quite wrong. It was with considerable
relief that those who were obliged to create definitions for the very
popular 3174 using only SSCP-dependent LU types 2 and 3 greeted the
advent of the XID 3 and threw out definition activity associated with
XID 0 with glee.

I can't really help you with your basic problem. It seems rather
unlikely that the XID format has anything to do with it. Either you
should stick with XID 0 and make sure you do all the necessary desk
checking with your VTAM counterpart to make sure that all the
necessary parameter matches are there - or you just use XID 3 and use
either the CPNAME operand - preferred - or the IDBLK and IDNUM
operands - but there's no need whatsoever to use both.

Your problem is at the level of the 802.2 protocols. I could guess
that if there is a buffer constraint which somehow extends to the
adapter where the protocol is observed, it could lead to the sort of
problem you describe. I would expect your Microsoft helpers to be of
more use here.

If a buffer problem in the adapter is really to blame, you might like
to relieve the stress - as it were - by operating with a smaller
receive window for the adapter. When I taught this topic I used to
encourage the use of an NCP tool which indicated what the required
window size was for the sort of traffic I was generating in my test
systems over the local centre's LAN. It was interesting that the
required window size was never more than 11 or 12 and so I set my
window size maxima to 20 so that, under normal operating conditions,
the window size was never a constraint on the traffic.

Incidentally, you may decide to specify a receive window for the
adapter of, say, 20. If you use XID 0, you now need to make sure that
the value of the MAXOUT operand of the matching PU statement is 20. If
you use XID 3, you can leave out the MAXOUT operand since the value
you specified for the adapter is conveyed to VTAM in the XID 3 data.
All so, so much easier!

The reason I'm making all this fuss is that I don't want anything in
the archives of the newsgroup which begins to imply that changing from
XID 3 to XID 0 is any way to try to solve problems - of any sort!

Chris Mason

[1] Since you point out you are not using ILU, you cannot be using
DYNPU=YES.

Asher,

Since you mentioned that your NICs are teamed, I'd like to mention that DLC
does not support NIC teaming. We have seen various issues when using NIC
teaming with DLC connections. In some cases, customers never have a problem.
However, we have found that random network related issues have been resolved
when NIC teaming was disabled.

Thanks...

Hi Asher - let us know the outcome.

As you say it shouldn't be a network throughput/congestion issue with
1Gbit/sec nics - as long as the nic's/switch ports aren't misconfigured or
erroring that is.  Hopefully your network dept know what they're doing - my
experience is that, unfortunately, they often don't...

Neil Pike.  Protech Computing Ltd
Microsoft SNA/HIS MVP
https://mvp.support.microsoft.com/profile=BE66F0D8-9D78-47EF-840A-08E6D8522A2D
http://www.linkedin.com/in/neilpike

Hello Neil & Stephen,

I disabled one of the team network in all my HIS servers and since then I
didn’t suffer from the 227 event.

I didn’t decide yet to drop entirely the team definition

In case of dropping the users will suffer from downtime.

Further more in case of NIC problem we can enable the other NIC immediately

In case of suffering from more network problem I will drop the team
definition entirely

Thank you for yours helps in this issue.