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 these records CPU is not an issue.
Regards, Berry.
Op 09-06-11 21:38, Scott Rohling schreef:
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 show as a different OSA <shrug>)
- Could a different ports be being used on the same OSA?
You've likely thought of this stuff already - just thinking of stuff I
would check. Can't think of any reason offhand. Well - maybe one:
does TCPIP on this LPAR have 2 virtual CPU's defined? Seems like
the number of CPU's can influence, but I'm probably thinking of
accounting records..
Scott Rohling
On Thu, Jun 9, 2011 at 11:56 AM, Berry van Sleeuwen
<berry.vansleeu...@xs4all.nl <mailto:berry.vansleeu...@xs4all.nl>> wrote:
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 truly identical. That leads me to believe
that these are seperatly created records.
The record produced by the TCPIP stack contains data from the OSA
device, we are interested in the number of bytes in and out for
the device during the minute interval.
As I understand it there is a buffer for each device. So the OSA
devices each have a record and the CTC devices also have a record.
And indeed that is what we get on other LPARs. Only on this
particular LPAR we have more than one record. And only for the
OSA's, not for the CTC's.
Regards, Berry.
Op 09-06-11 16:51, Scott Rohling schreef:
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
buffer at the time of this sample interval. A
separate record is generated for each buffer
declared by the virtual machine(s) via the Diagnose
'DC' START operation.
Seems to imply a separate record is generated for each buffer
declared.. I'm not sure what the application data sample is
in this case. Are the records truly duplicates? (the whole
record is absolutely identical, displayable chars or not)
Perhaps the application data needs to be appended to come up
with the entire field?
Scott Rohling
On Thu, Jun 9, 2011 at 8:04 AM, Berry van Sleeuwen
<berry.vansleeu...@xs4all.nl
<mailto:berry.vansleeu...@xs4all.nl>
<mailto:berry.vansleeu...@xs4all.nl
<mailto:berry.vansleeu...@xs4all.nl>>> wrote:
Hi listers,
I am looking at processing the userrecords in the CP
MONITOR for
the TCPIP
stacks. These are in CP MONITOR domain 0A record 02. The
data is
collected
though a STARMON stage, basically "PIPE STARMON | locate
<selection> | >
fielid".
Most LPARs have records like I'd expect them but I have
found that
in one
LPAR we have duplicate records for subrecordtype 05 for each of
the the OSA
devices.
The CTC's for VSE systems have one record per minute for
each VSE
system.
The OSA links have 2 identical records (apart from a slight
difference in
timestamp, a few miliseconds apart). A second IP stack even
writes
3 records
for every minute.
So basically we see:
00:01 VSE1
00:01 VSE2
00:01 OSA1
00:01 OSA2
00:01 OSA1
00:01 OSA2
00:02 ...
What can cause the CP monitor to have these duplicate records?
TIA, Berry.
