I guess some more testing is required. At least i'm not the only one to
be supprised. Indeed, a pmr sounds about right at this point.
I guess a test would be pretty easy, restart (logoff/logon) one of the
TCPIP stacks and see if it produces one record. Next fiddle with NETSTAT
OBEY and see if
Alan,
I think so but I'm not quite sure. We use the NETSTAT OBEY sometimes,
usually for stop or start of a link. For instance NETSTAT OBEY START DEVHW1.
Regards, Berry.
Op 13-06-11 04:01, Alan Altmark schreef:
On Fri, 10 Jun 2011 09:43:52 -0500, Berry van Sleeuwen
Hi Berry, I'm out of ideas without looking at data. You
may want to open a PMR.
Bill Bitner - z/VM Customer Focus and Care - IBM Endicott - 607-429-3286
On Monday, 06/13/2011 at 07:46 EDT, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
I think so but I'm not quite sure. We use the NETSTAT OBEY sometimes,
usually for stop or start of a link. For instance NETSTAT OBEY START
DEVHW1.
The only way I could think of to get the same record
On Fri, 10 Jun 2011 09:43:52 -0500, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
The IP stack hasn't been stopped, at least as far as I know. The last ti
me
the stacks were stopped was due to a VM IPL.
If indeed multiple buffers were created, would it make sense that the sa
me
data is
If these are the result of multiple links, I would think the link
names would be different. This is a long shot, but is it possible
that this TCP/IP stopped unexpectedly at some point in time and
was restarted without an IPL or Logoff/Logon?
The Stack identifies which buffers the CP monitor will
Hi Bill,
The IP stack hasn't been stopped, at least as far as I know. The last tim
e
the stacks were stopped was due to a VM IPL.
If indeed multiple buffers were created, would it make sense that the sam
e
data is reported in all buffers? I would expect, if new buffers were crea
ted
for the
Hi listers,
I am looking at processing the userrecords in the CP MONITOR for the TCPI
P
stacks. These are in CP MONITOR domain 0A record 02. The data is collecte
d
though a STARMON stage, basically PIPE STARMON | locate selection |
fielid.
Most LPARs have records like I'd expect them but I have
Just poking around found this description of the monitor record:
DESCRIPTIVE NAME - Monitor Sample Record
Domain 10 - Appldata domain
Record 2 - Application Data Sample Record
DESCRIPTION - Application data as found in the application-defined
Hi Scott,
Yes, the records are identical. After a SORT UNIQUE the duplicate
records are discarded. The only thing that is not identical is the TOD
field. The second (and third) record are produced a few miliseconds
after the first. When I discard the miliseconds the records themselves
are
Hmmm.. some questions then:
- Are the z/VM and TCPIP levels all the same?
- Are the OSA's attached to TCPIP the same way (DEDICATE in directory, via
a DTCPARMS, or?)
- Are the OSA cards the same.. defined the same?
- Any NICDEF's defined to TCPIP on this LPAR? (though I would think it
On Thursday, 06/09/2011 at 10:06 EDT, Berry van Sleeuwen
berry.vansleeu...@xs4all.nl wrote:
What can cause the CP monitor to have these duplicate records?
A type 0x05 record is, I think, produced for each LCB (Link Control Block)
in the stack. Does the OSA device have multiple LINKs?
Alan
Hi Scott,
Yes they are the same, same VM levels, same basic setup for all VM's and
IP stacks. In one case, our local IP stack, even uses the same osa
device. In one LPAR it produces just one record per minute, in the
second LPAR it produces three records.
And only one virtual CPU. But for
Multiple links? You mean on the OSA or within the IP stack?
Yes, multiple links on an OSA. In LPAR1 we have one IP stack (EE00-EE02)
and a VSWITCH (EE04-EE06) on the OSA. In LPAR2 we have two IP stacks on
the same OSA (EE00--EE06). The customer stack also has a backup on a
second OSA
14 matches
Mail list logo
