Duplicate CP Monitor records TCPIP
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 found that in one LPAR we have duplicate records for subrecordtype 05 for each of the the O SA 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 reco rds 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.
Question regarding zVM and CF when running in a LPAR
Am I understanding correctly that the CFUSER virtual machines that you can run when z/VM is running natively and now be run in zVM when running in an LPAR? This was added in zVM 5.4?
Re: Question regarding zVM and CF when running in a LPAR
We've been running CFUSER virtual machines (albeit with different userids) in an LPAR since at least z/VM 4.3, perhaps even earlier. Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. David Booher david.boo...@quest.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 06/09/2011 09:10 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Question regarding zVM and CF when running in a LPAR Am I understanding correctly that the CFUSER virtual machines that you can run when z/VM is running natively and now be run in zVM when running in an LPAR? This was added in zVM 5.4? The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Question regarding zVM and CF when running in a LPAR
Hmmm...then I wonder what this is all about. I'd really like to get this working: 09:40:56 XAUTOLOG CFCC4 09:40:56 COMMAND ACCEPTED 09:40:56 AUTO LOGON *** CFCC4USERS = 16BY OPERATOR CFCC4 : HCPMFT2816I LOADING MESSAGE PROCESSOR CFCC4 FROM THE PROCESSOR CONTROL LER. 09:43:32 SEND CFCC4 HELP CFCC4 : HCPPCX6531E THE OPERATING SYSTEM WILL NOT ACCEPT COMMANDS FROM THE SER VICE PROCESSOR. CFCC4 : HCPMFT2814E THE REQUEST TO LOAD CFCC4 FROM THE PROCESSOR CONTROLLER DI D NOT COMPLETE IN THE ALLOTTED TIME. CFCC4 : HCPMFT260E IPL COMMAND PROCESSING CANNOT COMPLETE DUE TO ERRORS. Dave Booher Quest Software From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Thursday, June 09, 2011 9:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Question regarding zVM and CF when running in a LPAR We've been running CFUSER virtual machines (albeit with different userids) in an LPAR since at least z/VM 4.3, perhaps even earlier. Mike Walter Aon Corporation y e-mail.
Re: Question regarding zVM and CF when running in a LPAR
On Thursday, 06/09/2011 at 10:12 EDT, David Booher david.boo...@quest.com wrote: Am I understanding correctly that the CFUSER virtual machines that you can run when z/VM is running natively and now be run in zVM when running in an LPAR? This was added in zVM 5.4? There has never been a restriction on using virtual coupling in an LPAR. The only thing that is required is that the machine be licensed for Coupling Facility, which, IIRC, is demonstrated by the presence of at least one coupling link on the box. (But that may have changed over the years) If the machine is not licensed for CF, then virtual CF cannot be used. What IS relatively new is that if you are running in a z/VM mode LPAR, then you can have real CF engines in the z/VM LPAR and virtual CFs will be dispatched on real CFs. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Duplicate CP Monitor records TCPIP
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 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.
Re: Question regarding zVM and CF when running in a LPAR
Yes, I see what you see on my zVM 4.4 system running on my z800 here in Chicago, but the z10 in the UK runs zVM in an LPAR and gives the strange messages indicated below. I saw Alan's response, but I'm unsure how to proceed. I know they are running CFs in LPARs on the z10, so I don't think it's a licensing issue... Is it just a matter of exposing the CF processors to the zVM LPAR? Is this a requirement for zVM 5.3? No, the CF inside of zVM on this z10 has never been tried before. I want to get it working so I can test my DB2 version 10 SYSPLEX there, because DB2 won't run on my z800 here in Chicago. My messages are cryptic at best. I particularly like the one I got back from trying to SEND the CF machine as message while it was supposedly loading. 09:40:56 XAUTOLOG CFCC4 09:40:56 COMMAND ACCEPTED 09:40:56 AUTO LOGON *** CFCC4USERS = 16BY OPERATOR CFCC4 : HCPMFT2816I LOADING MESSAGE PROCESSOR CFCC4 FROM THE PROCESSOR CONTROL LER. 09:43:32 SEND CFCC4 HELP CFCC4 : HCPPCX6531E THE OPERATING SYSTEM WILL NOT ACCEPT COMMANDS FROM THE SERVICE PROCESSOR. CFCC4 : HCPMFT2814E THE REQUEST TO LOAD CFCC4 FROM THE PROCESSOR CONTROLLER DID NOT COMPLETE IN THE ALLOTTED TIME. CFCC4 : HCPMFT260E IPL COMMAND PROCESSING CANNOT COMPLETE DUE TO ERRORS. Dave Booher Quest Software
Re: Question regarding zVM and CF when running in a LPAR
On Thursday, 06/09/2011 at 11:14 EDT, Mike Walter mike.wal...@aonhewitt.com wrote: I'm not sure if this will be of any help, but here are the CF-related console messages extracted from our most recent IPL of a z/VM 5.4 system running in an LPAR on a z10: You can find sample output and other information on the virtual Coupling Facility in the Running Guest Operating Systems book. The relevant error in this case is CFCC4 : HCPMFT2814E THE REQUEST TO LOAD CFCC4 FROM THE PROCESSOR CONTROLLER DID NOT COMPLETE IN THE ALLOTTED TIME. HELP HCP2814E tells you to try again, but that if it fails repeatedly to open a PMR. SEND won't work until the CF is loaded and ready. z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Duplicate CP Monitor records TCPIP
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 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.
Re: Duplicate CP Monitor records TCPIP
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 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 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.
Re: Duplicate CP Monitor records TCPIP
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 Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Duplicate CP Monitor records TCPIP
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.
Re: Duplicate CP Monitor records TCPIP
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-EF02). Within the IP stack there is one link defined for a device. Regards, Berry. Op 09-06-11 22:14, Alan Altmark schreef: 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 Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
