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
On Monday, 06/13/2011 at 07:46 EDT, Berry van Sleeuwen
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 more than once is to
declar
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
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
wrote:
The IP stack ha
On Fri, 10 Jun 2011 09:43:52 -0500, Berry van Sleeuwen
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 reported in all buffers
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 devic
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 co
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 (EF00-EF0
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 th
On Thursday, 06/09/2011 at 10:06 EDT, Berry van Sleeuwen
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 Altmark
z/VM and Linux on
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
would
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 tru
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
13 matches
Mail list logo