gwlmreport man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

gwlmreport(1M)							gwlmreport(1M)

NAME
       gwlmreport  -  produce  advanced	 textual  summary reports for workload
       resource utilization

SYNOPSIS
       gwlmreport command [options]

AVAILABILITY
       This command is available only on gWLM Central Management Servers (sys‐
       tems   where   you   run	  gwlmcmsd).   On  HP-UX  systems,  it	is  in
       /opt/gwlm/bin/.	On  Microsoft  Windows	systems,  it  is  in   C:\Pro‐
       gram Files\HP\Virtual  Server  Environment\bin\	by default. However, a
       different path may have been selected at installation.

       To run the command, you must be logged in as root on HP-UX or  into  an
       account that is a member of the Administrators group on Windows.

DESCRIPTION
       Use  gwlmreport	to  extract  data  for a given set of workloads over a
       given date range, and either create summary reports or write that  data
       to  comma-separated  value  (CSV) output.  gwlmreport can get data from
       one of two sources: By default, it pulls data from the  gWLM  database.
       It  can also use CSV input, which you point it to using the --inputpath
       option.

       NOTE: To ensure data from the current day is included  in  any  reports
       you create, run the following command on your CMS:

	      HP-UX  # /opt/gwlm/bin/gwlm history --flush

	      Windows
		     C:\Program Files\HP\Virtual  Server  Environment\bin\gwlm
		     history --flush

		     (This is the default path for Windows. However, a differ‐
		     ent path may have been selected at installation.)

       Valid values for command are:

	      extract	     Extract data from the gWLM database into CSV for‐
			     mat

	      resourceaudit  Generate a resource audit report
			     (Provides an overview of resource usage)

	      topborrowers   Generate a top borrowers report
			     (Helps identify workloads that may require	 addi‐
			     tional resources)

	      abnormalutil   Generate an abnormal utilization report
			     (Shows  CPU utilization over various time periods
			     so	 you  have  a  "normal"	 utilization   pattern
			     against which to compare abnormal utilization)

	      ovpafeed	     Extract  data  to	use  with OpenView Performance
			     Agent (OVPA) via data source integration (DSI)

	      config	     Generate a report showing configuration history

COMMANDS
       This section describes the syntax of each  command.  Note  that	option
       arguments are introduced by two dash characters (--), not a single dash
       character (-).

       The options are described in the next section. They  are	 the  same  on
       both HP-UX and Microsoft Windows.

	      extract [--workload=workload] [...]
		      [--help]
		      [--policy=policy]
		      [--startdate=YYYY/mm/dd]
		      [--enddate=YYYY/mm/dd]
		      [--duration=n{ days | weeks | months }]
		      [--inputpath=path]
		      [--outputpath=path]
		      [--dataversion=version]
		      [--columnhelp]
		      [--datestamps]
		      [--columns=colname1[,colname2,...]]

	      resourceaudit [--workload=workload] [...]
			    [--help]
			    [--policy=policy]
			    [--startdate=YYYY/mm/dd]
			    [--enddate=YYYY/mm/dd]
			    [--duration=n{ days | weeks | months }]
			    [--inputpath=path]
			    [--outputpath=path]

	      topborrowers [--workload=workload] [...]
			   [--help]
			   [--policy=policy]
			   [--startdate=YYYY/mm/dd]
			   [--enddate=YYYY/mm/dd]
			   [--duration=n{ days | weeks | months }]
			   [--inputpath=path]
			   [--outputpath=path]

	      abnormalutil [--workload=workload] [...]
			   [--help]
			   [--policy=policy]
			   [--startdate=YYYY/mm/dd]
			   [--enddate=YYYY/mm/dd]
			   [--duration=n{ days | weeks | months }]
			   [--inputpath=path]
			   [--outputpath=path]
			   [--targetdate=YYYY/mm/dd[:hh]]

	      ovpafeed [--workload=workload] [...]
		       [--help]
		       [--policy=policy]
		       [--startdate=YYYY/mm/dd]
		       [--enddate=YYYY/mm/dd]
		       [--duration=n{ days | weeks | months }]
		       [--inputpath=path]
		       [--outputpath=path]
		       [--dataversion=version]
		       [--setup]

	      config [--help]
		     [--dates]
		     [--targetdate=YYYY/mm/dd[:hh:mm:ss[.SSS]]]
		     [[--diff] --startdate=YYYY/mm/dd[:hh:mm:ss[.SSS]]
			       --enddate=YYYY/mm/dd[:hh:mm:ss[.SSS]]]
		     [--outputpath=path]

OPTIONS
       The gwlmreport commands recognize the following options:

       --workload=workload
	    Generate a report for workload.  To create reports for:

	    + Multiple (but not all) workloads:

	      Repeat --workload=workload with different values for workload

	    + All workloads: Do not specify --workload

	      The  absence  of the option indicates gwlmreport should get data
	      for all workloads. (Be aware that collecting data for  a	single
	      workload can take up to two minutes. So, collecting data for all
	      the workloads can take a significant amount of  time  for	 large
	      configurations.)

	      You cannot omit --workload and use --inputpath.

       --help
	    Print usage and exit.

       --policy=policy
	    Filter data to show only those periods when policy was in effect.

	    If you do not specify --policy, there is no filtering.

       --startdate=date
	    Base  the  report  on  data	 starting  from date.  Specify date in
	    YYYY/mm/dd format, such as 2004/06/09 for June 9th,	 2004.	 (With
	    the	 config	 command,  you	can also specify the ":hh:mm:ss[.SSS]"
	    component. SSS represents milliseconds.)

	    If you do not specify --startdate, gWLM sets date to one  calendar
	    month  before  today. (However, if you specify --enddate, you must
	    explicitly set --startdate.)

	    When you specify --startdate but not --enddate, you get  data  for
	    the one month period following date.

	    When  running  gwlmreport  config  --diff,	you  must specify both
	    --startdate and --enddate.

	    When running gwlmreport ovpafeed multiple times, be	 sure  not  to
	    use overlapping --startdate and --enddate arguments.

       --enddate=date
	    Base  the  report on data ending date.  Specify date in YYYY/mm/dd
	    format, such as 2004/06/09 for June 9th, 2004.  (With  the	config
	    command, you can also specify the ":hh:mm:ss[.SSS]" component. SSS
	    represents milliseconds.)

	    You cannot specify --enddate with --duration.

	    The default end date is the current date. (However, if you specify
	    --startdate,  the  default	end  date  is one month after the date
	    given with --startdate.)

	    When running gwlmreport  config  --diff,  you  must	 specify  both
	    --startdate and --enddate.

	    When  running  gwlmreport  ovpafeed multiple times, be sure not to
	    use overlapping --startdate and --enddate arguments.

       --duration=n{ days | weeks | months }
	    Run the report with data from

	    date
	    to
	    date + n{ days | weeks | months }

	    where date is the value you specified in --startdate=date.

	    If you specify --duration, you must also specify --startdate.  You
	    cannot specify --duration with --enddate.

	    The input format is n{ days | weeks | months }.  Examples of valid
	    choices are: 5weeks, 2months.

	    If you do not specify --duration, gWLM  uses  a  duration  of  one
	    month.

       --inputpath=path
	    Specify  the  path	for  the  CSV  data being used to generate the
	    report.

	    You must specify --workload when you specify --inputpath.

	    There are three valid choices for path:

	    + A single dash "-" to read all CSV data from stdin

	    + An absolute path to a single file containing CSV	data  for  all
	      workloads specified with the --workload option

	    + A directory containing a group of CSV files, one per workload

	      For  example, if the workloads specified are wl1 and wl2 and the
	      input path is /tmp, gwlmreport will attempt to read the CSV info
	      for  workload  wl1  from	file /tmp/wl1.csv and the CSV info for
	      workload wl2 from file /tmp/wl2.csv.

       --outputpath=path
	    Specify the path for the report output.  The default  path	is  to
	    send report output to stdout.

	    There are three valid choices for path:

	    + A single dash "-" to write all report output to stdout

	    + An absolute path to a single file to which all report data is to
	      be written

	      If a single file is specified and that file already exists,  the
	      file is overwritten.

	    + A directory

	      If  a  directory	is  specified, each report is placed in a file
	      named after its workload (unless you are using the  topborrowers
	      command).	 The  filenames	 change	 based on the report type. For
	      example, the following commands result in the indicated files:

	      gwlmreport resourceaudit \
		  --workload wkldA \
		  --workload wkldB \
		  --outputpath=/tmp/
	      Files: /tmp/wkldA.resaud, /tmp/wkldB.resaud

	      gwlmreport extract \
		  --workload wkldA \
		  --workload wkldB \
		  --outputpath=/tmp/
	      Files: /tmp/wkldA.csv, /tmp/wkldB.csv

	      gwlmreport abnormalutil \
		  --workload wkldA \
		  --workload wkldB \
		  --outputpath=/tmp/
	      Files: /tmp/wkldA.abutil, /tmp/wkldB.abutil

	      gwlmreport topborrowers \
		  --workload wkldA \
		  --workload wkldB \
		  --outputpath=/tmp/
	      File: /tmp/allworkloads.topbor

	      gwlmreport config --outputpath=/tmp/
	      File: /tmp/config.YYYY-mm-dd:hh:mm:ss

	    NOTE: Using --outputpath with ovpafeed directs data to  the	 given
	    path instead of to the logfileset.

	    --dataversion=version
		   Specify  the	 version  of  data to use for the intermediate
		   file. Valid choices are: 1.0, 2.0, 3.0, and 4.0. (This ver‐
		   sion is independent of the version of the gWLM product.)

		   If  you  do not specify --dataversion, gWLM sets version to
		   4.0.

		   You can convert from one data version to another by reading
		   a  database or CVS source that is one version, say 2.0, and
		   specifying the --dataversion option with the other  version
		   (for example, 4.0). New fields (when going from 3.0 to 4.0)
		   are filled as best as possible, while missing fields (going
		   from 4.0 to 3.0) are dropped.

		   When	 using ovpafeed, you can change the version as desired
		   because each version's data goes into a  separate  logfile‐
		   set,	 maintaining  different	 sets  of OpenView Performance
		   Agent metrics as provided by the given version.

	    --columnhelp
		   List the names for the all  the  columns  of	 data  in  the
		   extract output. Use the names shown when you use the --col‐
		   umns option to limit the number of columns displayed.

		   The list of column names changes based on the --dataversion
		   value.

	    --datestamps
		   Convert timestamps to human-readable datestamps.

		   NOTE: If you use --datestamps and save the output to a file
		   (using --outputpath), that file cannot  be  used  later  as
		   input with the --inputpath option.

	    --columns=colname1[,colname2,...]]
		   Extract data only for the specified columns. (Separate col‐
		   umn names using only commas; do not use spaces.) To display
		   a  list  of column names, use the --columnhelp option. (The
		   columns available change based on the --dataversion value.)

		   NOTE: If you use --columns and save the output  to  a  file
		   (using  --outputpath),  that	 file  cannot be used later as
		   input with the --inputpath option.

	    --targetdate=YYYY/mm/dd[:hh:mm:ss[.SSS]]
		   Focus the report on the specified date.

		   The ":mm:ss[.SSS]" component is allowed only with the  con‐
		   fig command. (SSS represents milliseconds.)

	    --setup
		   Sets up the DSI logfileset needed for feeding data to Open‐
		   View Performance Agent. Data is placed  in  logfilesets  in
		   /var/opt/dsi/version/gwlm*.

		   NOTE:  The ovpafeed command is available only on HP-UX sys‐
		   tems with the HPUX11i-OE-Ent.MeasureWare.PERFDSI fileset or
		   its	 equivalent   installed.    (One   equivalent  is  the
		   B3701AA.MeasureWare.PERFDSI	fileset,  which	 is  installed
		   when	 you  install HP GlancePlus/UX Pak, version C.03.85.00
		   or later.) You must be root to use the command.

		   NOTE: Running gwlmreport  ovpafeed  --setup	modifies  your
		   /var/opt/perf/perflbd.rc  file.  Restart perflbd to see new
		   feed in the OpenView tools. For  more  information,	search
		   for "mwa restart server" in the mwa(1) manpage.

		   You	must  run gwlmreport ovpafeed --setup before using any
		   other gwlmreport ovpafeed commands.

	    --dates
		   Display the dates when there were configurations saved.

	    --diff --startdate=date --enddate=date
		   Display  any	 changes  in  configurations   saved   between
		   --startdate=date and --enddate=date.

EXAMPLES
   Example 1
       Produce	a resource audit report for myworkloadA for the calendar month
       prior to the current date (time at which gwlmreport is run). The	 work‐
       load data is read from the gWLM database.

	       gwlmreport resourceaudit \
		   --workload=myworkloadA

   Example 2
       Produce a resource audit report for workloads myworkloadA, myworkloadB,
       and myworkloadC for the three calendar months starting  Sep  01,	 2004.
       The workload data is read from the gWLM database.

	       gwlmreport resourceaudit \
		   --workload=myworkloadA \
		   --workload=myworkloadB \
		   --workload=myworkloadC \
		   --startdate=2004/09/01 \
		   --duration=3months

   Example 3
       Produce	a  topborrowers	 report for workloads myworkloadA, myworkloadB
       and myworkloadC for the calendar month starting Sep 01, 2004. The work‐
       load data is read from the gWLM database.

	       gwlmreport topborrowers \
		   --workload=myworkloadA \
		   --workload=myworkloadB \
		   --workload=myworkloadC \
		   --startdate=2004/09/01 \
		   --duration=1month

   Example 4
       Walk  through  the CSV file /tmp/previously_extracted_data.csv and pro‐
       duce a resource audit report for workload myworkloadA under the	policy
       myOwnBorrowPol  for  the	 three	calendar months starting Sep 01, 2004.
       Print it to stdout.

	       gwlmreport resourceaudit \
		   --workload=myworkloadA \
		   --policy=myOwnBorrowPol \
		   --startdate=2004/09/01 \
		   --duration=3months \
		   --inputpath=/tmp/previously_extracted_data.csv

   Example 5
       Extract the data for myworkloadA, for the three calendar months	start‐
       ing  Sep	 01,  2004. Print it to stdout. The workload data is read from
       the gWLM database.

	       gwlmreport extract \
		   --workload=myworkloadA \
		   --startdate=2004/09/01 \
		   --duration=3months

   Example 6
       Extract the data for myworkloadA (formatting it as CSV data),  for  the
       three  calendar months starting Sep 01, 2004. The CSV data is stored in
       a file called /tmp/mydata.csv. The workload data is read from the  gWLM
       database.

	       gwlmreport extract \
		   --workload=myworkloadA \
		   --startdate=2004/09/01 \
		   --duration=3months \
		   --outputpath=/tmp/mydata.csv

   Example 7
       Extract	the data for myworkloadA and myworkloadB (formatting it as CSV
       data), for the three calendar months starting Sep 01, 2004. Because the
       --outputpath option points to a directory, the CSV data for myworkloadA
       is stored in a file called /tmp/myworkloadA.csv, and the CSV  data  for
       myworkloadB  is	stored	in  /tmp/myworkloadB.csv. The workload data is
       read from the gWLM database.

	       gwlmreport extract \
		   --workload=myworkloadA \
		   --workload=myworkloadB \
		   --startdate=2004/09/01 \
		   --duration=3months \
		   --outputpath=/tmp/

   Example 8
       Read the data for myworkloadA and myworkloadB from /tmp/myworkloadA.csv
       and /tmp/myworkloadB.csv for the three calendar months starting Sep 01,
       2004, and use it to produce an audit report for each workload.

	       gwlmreport resourceaudit \
		   --workload=myworkloadA \
		   --workload=myworkloadB \
		   --startdate=2004/09/01 \
		   --duration=3months \
		   --inputpath=/tmp/

   Example 9
       Compare recent CPU utilization of a poorly performing workload  against
       its utilization when it was performing as desired. Say the poor perfor‐
       mance is noticed on 2005/10/21 around 10am. To compare that utilization
       to  the	utilization  in	 periods related to that time, run a report as
       follows:

	    gwlmreport abnormalutil \
		--workload=myworkloadA \
		--startdate=2005/10/01 \
		--enddate=2005/10/30 \
		--targetdate=2005/10/21:10

       The resulting report would show all the historical samples for workload
       utilization for several time periods:

	      + The whole period (10/01 through 10/30)

	      + All the Friday 10-10:59 am time periods (10/21 is a Friday)

	      + The week (7 calendar days) prior to 10/21

	      + The hour prior to 10:21:10

	      + The sample immediately before 10:21:10

       Comparing  the  data during the target period with these other periods,
       you can see if the allocation and utilization are normal for  a	Friday
       10am slot, and for a given week or month.  If the allocation seems nor‐
       mal but the utilization is high, perhaps there is extra	demand	or  an
       application  problem.  If  the allocation seems too low compared to the
       other time periods of interest, perhaps the  workload  is  not  getting
       enough resources and a policy adjustment is needed.

       You  might then rerun the report with the same start and end dates, but
       different targetdates, say 2005/10/21:11 and 2005/10/21:12, to  compare
       the  original  10am  report with an 11am and a noon-based report. These
       variations quickly give a feel for the behavior of the application.

   Example 10
       Show the configuration changes made in September of 2006:

	    gwlmreport config --diff --startdate=2006/09/01 --enddate=2006/09/30

   Example 11
       Extract data for viewing with OpenView by running  the  following  com‐
       mands:

       1. Set up the DSI logfileset:

	       gwlmreport ovpafeed --setup --dataversion=3.0

	  NOTE: This command fails if the DSI-related OV tools are not present
	  or you are not running on HP-UX.

	  This step adds a line to the /var/opt/perf/perflbd.rc file.

       2. Restart the mwa servers

	  You must restart the mwa servers so that perflbd and other OV	 tools
	  can see the new data stream. The restart command is:

	       mwa restart server

       3. Extract the data:

	       gwlmreport ovpafeed \
		   --workload=myworkloadA \
		   --startdate=2005/10/01 \
		   --enddate=2005/10/30 \
		   --dataversion=3.0

	  This	step shows the data being used from the gWLM database. You can
	  use --inputpath to use CSV files as input instead.

	  Data is placed in a logfileset in /var/opt/dsi/version/gwlm* on  the
	  CMS  by  default.  These  files  grow	 with  each  run of gwlmreport
	  ovpafeed.  Starting with gWLM A.02.00.00.07, the logfileset  is  set
	  up  to hold enough historical samples to accommodate 90 days of data
	  for 20 workloads with 5-minute historical samples  before  the  log‐
	  fileset 'rolls' and starts overwriting older data. This rolling lim‐
	  its  the   maximum   disk   space   that   will   be	 consumed   by
	  /var/opt/gwlm/dsi.

	  You  can see the raw data that is being reported to OVPA by specify‐
	  ing a --outputpath to stdout or a file and  then  viewing  the  con‐
	  tents.  However, when you use --outputpath, data is sent to the file
	  or stdout instead of being sent via DSI to OVPA.

       4. Access the data using OpenView tools:

	  Available tools include:
	  + /opt/perf/bin/extract
	  + OpenView Performance Manager (OVPM) and other  OpenView  reporting
	  tools

	  For  example,	 to  see the data just added via the command line, run
	  the command:

		 /opt/perf/bin/extract -xp -C workloads DETAIL \
		     -l /var/opt/gwlm/dsi/version/gwlm \
		     -b 10/01/05 -e 10/30/05

	  Alternatively, you can view the data graphically using OVPM  on  the
	  CMS. When creating a new report in OVPM, the Metric Selection screen
	  will have an entry named GWLM_3_0:WORKLOADS. Select  that  entry  to
	  see  the possible gWLM metrics (including compCpuAlloc, compCpuUtil,
	  and polCpuRequest). Select the metrics of interest. Add a filter for
	  wlName == myworkloadA. Name and save the new report. Then display it
	  for the time period 2005/10/01 to 2005/10/30.

       5. Repeat step 3 and step 4 for other workloads and/or time periods  of
	  interest.

       To automate use of gwlmreport ovpafeed, you can feed gWLM workload data
       to OVPA regularly. For example, you could use a snippet similar to  the
       one below executed by cron to feed data to OVPA daily:

       YESTERDAY=`TZ=GMT+24 date +%Y/%m/%d`
       /opt/gwlm/bin/gwlmreport ovpafeed \
	       --startdate $YESTERDAY \
	       --enddate $YESTERDAY

       Using  yesterday	 for  both the start and end dates gives all data from
       yesterday.

   Example 12
       Set up an automatic report using a cron entry to run a  resource	 audit
       report  on  the first of each month for workload myworkloadB's resource
       use during the previous month:

	      0	 00  * 1 *  /opt/gwlm/bin/gwlmreport resourceaudit \
	      --workload=myworkloadB | /usr/bin/mail the_admin@mycompany.com 2>&1

REPORT OUTPUT DESCRIPTIONS
       gwlmreport produces the following types of reports,  depending  on  the
       command you specify:

	      resourceaudit  resource audit report

	      topborrowers   top borrowers report

	      extract	     CSV report

	      abnormalutil   abnormal utilization report

	      ovpafeed	     Data  for use with OpenView Performance Agent via
			     data source integration (DSI)

	      config	     configuration history report

       The sections below describe the contents of these reports. (Search  for
       "Report:" to find the start of each section.)

   Report: resource audit
       The resource audit report has the following sections:

	      + Report information

	      + Workload context information

	      + Samples info

	      + Utilization info

	      + Footnotes

			       Report information
       This  section  presents	configuration  data that is (usually) constant
       over the report duration. If any	 of  these  items  change  during  the
       report  duration,  a  footnote  (see  section below) is appended to the
       report and the *most recent value* is displayed in the report.

       ReportDate
	      The date and time when the report was generated.

       Workload
	      The name of the workload.

       TotalSamples
	      The total number	of  samples  received  from  the  data	source
	      (either the gWLM database or the CSV input) that fall within the
	      report date range for the given workload. This is	 identical  to
	      the  Total  value	 in the "Samples info" section. Samples during
	      times when the workload was in advisory mode  are	 not  counted.
	      TotalSamples may be less than PossibleSamples if gWLM was not on
	      for the whole period.

	      A footnote is produced if this value differs  from  PossibleSam‐
	      ples by more than 10%.

       AvgSampleDuration
	      Length of sample in minutes.

       ReportDateRange
	      Calendar dates covered by report.

       PossibleSamples
	      Calculated  maximum  number  of  samples	that  are  possible in
	      ReportDateRange.	Basically ReportDateRange divided  by  AvgSam‐
	      pleDuration.

       SeenDataRange
	      The  date	 of the first sample from the gWLM database or the CSV
	      file used as input to the date of the last sample.

			  Workload context information
       This section presents configuration data	 that  is  (usually)  constant
       over  the  report  duration.  If	 any  of these items change during the
       report duration, a footnote (see section	 below)	 is  appended  to  the
       report and the *most recent value* is displayed in the report.

       SRDName
	      Name  of	workload's shared resource domain. If the name changed
	      over the report time, the most recent shared  resource  domain's
	      info is displayed and a footnote is produced.

       SRDMode
	      Tells whether the workload's SRD was in managed mode or advisory
	      mode.

       PolicyName
	      Name of workload's policy. If this has changed over  the	report
	      time, the most recent policy's info is displayed.

       PolicyType
	      Fixed, OwnBorrow, Utilization, or Custom.

       PolicySettings

	      For Fixed policies:	 target

	      For OwnBorrow policies:	 min/owned/max

	      For Utilization policies:	 min/max

	      For Custom policies:	 min/max

       CompartmentName
	      Name  of	workload's  compartment.  If the name changed over the
	      report time, the most recent compartment's info is displayed and
	      a footnote is produced.  Some compartments have no name, so this
	      field may be empty.

       CompartmentType
	      hpvm, npar, vpar, fss, or pset.

       CompartmentHost
	      Hostname of the workload's compartment.

				  Samples info
       OwnedOnly
	      Percentage and count of samples where Owned  is  within  95%  to
	      105% of Size.

	      Custom  policies	and  Utilization policies treat their Min Size
	      values as their Owned values. Because  gWLM  always  honors  Min
	      Size  values,  these  types of policies always honor their Owned
	      values, never going below	 them  (that  is,  never  lending  CPU
	      resources). So, workloads with either of these policy types will
	      only own or borrow.

	      Workloads with Fixed policies will have all  their  samples  at‐
	      tributed to OwnedOnly.

       Borrowing
	      Percentage  and  count  of  samples  borrowing (that is, samples
	      where Size > '105% of Owned')

       Lending
	      Percentage and count of samples where the	 user  lent  resources
	      (that is, samples where Size < '95% of Owned').

       Total (same as TotalSamples)
	      The  total  number  of  samples  received	 from  the data source
	      (either the gWLM database or the CSV input) that fall within the
	      report date range for the given workload.

	      For  any	sample,	 the  workload must be in exactly one of three
	      states: OwnedOnly, Borrowing, or Lending. Total is  the  sum  of
	      the  number  of  samples	for  the workload in each of the three
	      states. Consequently, Total is equal to the TotalSamples	metric
	      described	 above. (The Total count excludes times when the work‐
	      load was in advisory mode.)

	      The following metrics are not included in Total:

	      + Able2Lend
	      + Want2Borrow
	      + CompClipped
	      + PolClipped
	      + PriClipped

	      Able2Lend and Want2Borrow can both describe a sample  where  the
	      workload	is in the OwnedOnly state. The remaining metrics indi‐
	      cate forms of clipping, most likely describing  a	 sample	 where
	      the  workload  is in the Borrowing state. To avoid double-count‐
	      ing, these metrics are not included in the Total metric.

       Able2Lend
	      Percentage and count of samples where request was less than  95%
	      of  Owned. This metric is not included the Total or TotalSamples
	      metrics.

       Want2Borrow
	      Percentage and count of samples where request was more than 105%
	      of  Owned. This metric is not included the Total or TotalSamples
	      metrics.

       CompClipped
	      Compartment Clipped - percentage and count of samples where  the
	      workload	could  not  borrow  or	acquire	 as  much as it wanted
	      because it is already allocated the compartment maximum. If this
	      condition	 persists,  there  may	be different remedies based on
	      compartment type.	 For  workloads	 based	on  virtual  machines,
	      psets,  or  fss  groups,	the remedies are: buy a bigger server,
	      move the workload to a server with more room, or move some other
	      workload off the server.	For workloads based on vpars, the same
	      remedies apply but you can also fix the problem by reducing  the
	      number  of  bound	 CPUs  (cores)	on the virtual partitions. For
	      workloads based on npars, the remedies for  workloads  based  on
	      psets or fss groups apply; additional Instant Capacity resources
	      can help as well.

       PolClipped
	      Policy Clipped - occurs when the workload is allocated the maxi‐
	      mum  CPU	resource  per its policy, but its utilization is above
	      the target, and thus cannot request any more.  If this condition
	      persists, a potential remedy is to increase the policy maximum.

       PriClipped
	      Priority	Clipped	 - occurs when all the workloads' compartments
	      at higher priority levels or at  the  same  priority  level  are
	      allocated	  their	  requested   resources,  not  leaving	enough
	      resources for the compartments remaining at the  same  or	 lower
	      priority	levels.	  The  remedy is to raise the priority, or, if
	      using OwnBorrow policies, edit the policy (or  associate	a  new
	      policy)  to  give	 associated workloads a larger owned amount of
	      CPU resources.

			       Utilization section
       AvgUtil
	      The average utilization of the  workload	during	the  reporting
	      duration.

       MaxUtil
	      The  maximum  utilization	 of  the workload during the reporting
	      duration. A date is displayed showing when the maximum occurred.

       TradeBalance
	      Compute grade based on how often (and  how  much)	 the  workload
	      lends  or	 borrows.  A  running  total is kept while samples are
	      read: For each sample that is lending, the total lent amount  is
	      subtracted  from the running total. For each sample that is bor‐
	      rowing, a total lent amount is added to the running  total.  The
	      end  TradeBalance is the running total divided by the total sam‐
	      ple count, so a net negative amount means a net lender, while  a
	      net  positive  amount means a net borrower. The magnitude is the
	      average amount lent or borrowed.

       AvgUtilWhileLending
	      The average utilization during samples  when  this  workload  is
	      lending.

       MaxUtilWhileLending
	      The  maximum  utilization	 encountered during a sample when this
	      workload is lending. If this is nonzero,	a  date	 is  displayed
	      showing  when this maximum occurred. Too large a value may indi‐
	      cate that this workload is being unfairly penalized.

       AvgReq Average CPU allocation request for the workload by its policy.

       AvgAlloc
	      Average CPU allocation gWLM gave to the workload.

       AvgCons
	      Average CPU consumption in terms of cores.

       CpuMinutesAlloc
	      CPU minutes allocated to the workload. For each  sample  in  the
	      report  period, the length of the sample in minutes is multipled
	      by the AvgAlloc (average	allocation)  value  for	 that  sample.
	      CpuMinutesAlloc is the sum of the results for all the samples.

       CpuMinutesCons
	      CPU  minutes  consumed  by  the workload. For each sample in the
	      report period, the length of the sample in minutes is  multipled
	      by  the  AvgCons	(average  consumption)	value for that sample.
	      CpuMinutesCons is the sum of the results for all the samples.

				    Footnotes
       Along with metrics in the detailed  reports,  a	set  of	 footnotes  is
       printed to show warnings or alerts for particular reports. These are to
       alert you that there was some kind  of  exceptional  event  during  the
       report durations that could affect the data.

       Note  that the data samples during the exceptional conditions are still
       included in the reports (as best the tools can manage).

       For each type of condition shown below, one  footnote  is  printed  per
       workload	 per  report showing the type, the date it first occurred, and
       the total number of times it occurred.

       Advisory mode
	      This workload's SRD was in advisory mode, not managed mode, dur‐
	      ing  one	or more samples. This can mean that the allocations do
	      not track the requests because gWLM is advising only, not making
	      changes.	The  samples  in advisory mode are not used to compute
	      state counts and other metrics.

       Time gap
	      This workload's history  does  not  extend  through  the	entire
	      reporting	 period,  or there are gaps in the sample stream of at
	      least one hour.

       Compartment change
	      There was one or more significant compartment changes during the
	      report  period.  This could be changes to name, id, type, and so
	      on.

       Policy change
	      There was one or more  significant  policy  changes  during  the
	      report  period.  This could be changes to name, id, type, and so
	      on.

       Overlapping samples
	      The timestamps for two or more  samples  show  they  overlap  in
	      time,  or	 are out of order.  gwlmreport expects non-overlapping
	      samples in order by time-of-century.

       Sample size changed
	      During the report period, the sample size changed	 by  at	 least
	      10%.  Because  all  samples  are	counted	 equally, this sort of
	      change will skew the results toward the  data  for  the  shorter
	      samples.	(This  size  is	 set  in  minutes  using  the property
	      com.hp.gwlm.node.samples in  the	file  /etc/opt/gwlm/conf/gwlm‐
	      cms.properties  on HP-UX or in the file C:\Program Files\HP\Vir‐
	      tual Server Environment\conf\gwlmcms.properties on Windows. This
	      is  the  default	path on Windows; however, a different path may
	      have been selected at installation.)

   Report: top borrowers
       The top borrowers report is a table view of workloads sorted by	Trade‐
       Balance.	 All  the  metrics and footnotes are identical to the Resource
       Audit metrics, so see the section above for the metric definitions.

   Report: extract (CSV)
       The extract report extracts raw historical data from the gWLM database,
       formats it as comma-separated values, and prints it to a specified file
       or stdout.

       To help consumers of the data, the first line of an extract report is a
       Schema  Version line, which gives the gWLM schema and extract-file for‐
       mat versions. As there can be changes in one or both of	these  in  any
       gWLM  release,  all consumers should check the version numbers and con‐
       firm they understand the data to follow.

       The second line in the extract report is a comma-separated list of col‐
       umn  headers.  These  are the names of columns. The number and order of
       the columns is fixed for a given extract version number.	 For  informa‐
       tion  on	 the  order of the columns, see the section "CSV Column Header
       Lines" below.

       The remaining lines in an extract report are lines of  metrics  in  CSV
       format.

       Consumers of the CSV data should ignore any lines:

	    + Starting with a # sign, as these are comments

	    + Consisting only of whitespace

       While  neither of these types of lines is generated in the v3.0 extract
       report, they may be added in future versions.

			CSV File and Schema Version Lines
       Here is the format of the CSV File and Schema  Version  line  from  the
       gWLM A.04.10.xx version of gwlmreport:

	      schemaVersion=gWLM4.1 extractFormatVersion=4.0

       The schemaVersion specifies the version of the gWLM schema used to pro‐
       duce the data. The extractFormatVersion specifies the  version  of  the
       extract	tool  used to extract the data.	 For example, running the fol‐
       lowing command

	       gwlmreport extract --dataversion=1.0

       against a gWLM  4.0  database  would  result  in	 a  CSV	 file  with  a
       "schemaVersion=gWLM4.0  extractFormatVersion=1.0"  header.  This header
       shows that the data is from a 4.0 source (DB or CSV file) and is in 1.0
       extract form. (Being in 1.0 extract form, the list and order of columns
       would match what a 1.0-based extract would have returned.)

       At least one version line must be read before column headers or	metric
       data  lines  are read so the tools know what names and how many metrics
       to expect. If a column header line or metric data line  is  encountered
       before a valid version line, gwlmreport exits with an error to stderr.

       If you have concatenated several CSV files, you may have duplicate ver‐
       sion lines. Only the first version line is used	(later	version	 lines
       are ignored).

			     CSV Column Header Lines
       The  format of the CSV Column header line from gwlmreport with dataver‐
       sion=4.0:

	      sampleStart, sampleEnd, srdName, srdId,  srdMode,	 srdTicapMode,
	      compName,	 compId,  compType,  compHost, compCpuMin, compCpuMax,
	      compCpuSize, compCpuAlloc, compCpuUtil, wlName,  wlId,  polName,
	      polId,  polType, polCpuMin, polCpuMax, polCpuRate, polCpuWeight,
	      polCpuTarget, polCpuRequest, polCpuReading, polCpuOwned,	polTi‐
	      capEnabled, polActiveId, polActiveType

       The 4.0 format includes all the 3.0 headers plus polActiveType.

       The  format of the CSV Column header line from gwlmreport with dataver‐
       sion=3.0:

	      sampleStart, sampleEnd, srdName, srdId,  srdMode,	 srdTicapMode,
	      compName,	 compId,  compType,  compHost, compCpuMin, compCpuMax,
	      compCpuSize, compCpuAlloc, compCpuUtil, wlName,  wlId,  polName,
	      polId,  polType, polCpuMin, polCpuMax, polCpuRate, polCpuWeight,
	      polCpuTarget, polCpuRequest, polCpuReading, polCpuOwned,	polTi‐
	      capEnabled, polActiveId

       The  3.0	 format	 includes all the 2.0 headers plus polTicapEnabled and
       polActiveId.

       The format of the CSV Column header line from gwlmreport with  dataver‐
       sion=2.0:

	      sampleStart,  sampleEnd,	srdName, srdId, srdMode, srdTicapMode,
	      compName, compId, compType,  compHost,  compCpuMin,  compCpuMax,
	      compCpuSize,  compCpuAlloc,  compCpuUtil, wlName, wlId, polName,
	      polId, polType, polCpuMin, polCpuMax, polCpuRate,	 polCpuWeight,
	      polCpuTarget, polCpuRequest, polCpuReading, polCpuOwned

       The  2.0 format includes all the 1.0 headers plus srdTicapMode and pol‐
       CpuOwned.

       Here is the format of the CSV Column header line from  gwlmreport  with
       dataversion=1.0:

	      sampleStart,  sampleEnd, srdName, srdId, srdMode, compName, com‐
	      pId, compType, compHost,	compCpuMin,  compCpuMax,  compCpuSize,
	      compCpuAlloc,   compCpuUtil,   wlName,   wlId,  polName,	polId,
	      polType, polCpuMin, polCpuMax,  polCpuRate,  polCpuWeight,  pol‐
	      CpuTarget, polCpuRequest, polCpuReading

       All the column headers are described below.

       sampleStart
	      Indicates the start time (in milliseconds since Jan 1, 1970) for
	      the sample.

       sampleEnd
	      Indicates the end time (in milliseconds since Jan 1,  1970)  for
	      the sample.

       srdName
	      Corresponds  to  SRDName, which is described above in the "Work‐
	      load context information" section.

       srdId  Is an ID for the SRD.

       srdMode
	      Corresponds to SRDMode, which is described above in  the	"Work‐
	      load context information" section.

       srdTicapMode
	      Indicates	 whether  the  SRD  was	 configured  to	 use Temporary
	      Instant Capacity (TiCAP). Possible entries in this column are:

	      none
		Default setting--or the	 system	 does  not  support  Temporary
		Instant Capacity.

	      off
		Temporary  Instant  Capacity is supported on the system but is
		not being used to satisfy policy requests.

	      all
		Temporary Instant Capacity is supported on the system and  can
		be used to satisfy policy requests.

       compName
	      Corresponds  to CompartmentName, which is described above in the
	      "Workload context information" section.

       compId Is an ID for the compartment.

       compType
	      Corresponds to CompartmentType, which is described above in  the
	      "Workload context information" section.

       compHost
	      Corresponds  to CompartmentHost, which is described above in the
	      "Workload context information" section.

       compCpuMin
	      Is the minimum amount of CPU resources that  a  compartment  can
	      have.  This value is the minimum resource allocation required by
	      the underlying compartment.

       compCpuMax
	      Is the maximum amount of CPU resources that  a  compartment  can
	      have.  This  value is the maximum resource allocation allowed by
	      the underlying compartment. However, gWLM may reduce this number
	      at  times	 because an SRD has a large number of compartments and
	      each  compartment	 must  receive	a  minimum  portion   of   the
	      resources.

       compCpuSize
	      Is  the amount of CPU resources a compartment actually has. Size
	      may differ from the allocation when gWLM is deployed in advisory
	      mode.

       compCpuAlloc
	      Is  the  amount of CPU resources that gWLM sets aside for a com‐
	      partment after arbitrating resource requests from	 the  policies
	      for all the compartments.

       compCpuUtil
	      Is  the percentage resulting from dividing a workload's CPU con‐
	      sumption by its CPU allocation.

       wlName Corresponds to Workload, which is described above in the	"Work‐
	      load context information" section.

       wlId   Is an ID for the workload.

       polName
	      Corresponds  to  PolicyName,  which  is  described  above in the
	      "Workload context information" section.

       polId  Is an ID for the policy.

       polType
	      Corresponds to PolicyType,  which	 is  described	above  in  the
	      "Workload context information" section.

       polCpuMin
	      Is  the  minimum	amount	of  CPU	 resources  that a policy will
	      request for any workload with which it is associated.

       polCpuMax
	      Is the maximum amount  of	 CPU  resources	 that  a  policy  will
	      request for any workload with which it is associated.

       polCpuRate
	      Is the convergence rate for the policy.

	      The default rate is 1.0. Larger values produce larger changes in
	      the allocation, resulting in a faster convergence	 on  the  pol‐
	      icy's  target.   Similarly, smaller values slow down convergence
	      on the target.

       polCpuWeight
	      Is the CPU weight for the policy. gWLM distributes CPU resources
	      in  proportion to weights when there are not enough resources to
	      satisfy all requests at a given priority. gWLM also  distributes
	      CPU  resources  in  proportion to weights if there are resources
	      remaining once all requests at all priorities have  been	satis‐
	      fied.

       polCpuTarget
	      Is  the  target  value  that  drives  a  policy, influencing its
	      resource requests to gWLM.

	      For example, with utilization and OwnBorrow policies,  the  pol‐
	      CpuTarget	 is target CPU utilization. With a target CPU utiliza‐
	      tion, gWLM attempts to keep a workload's CPU  utilization	 below
	      the  target  by  adding CPU resources when the workload is using
	      too much of its current CPU allocation.

	      With a custom policy, polCpuTarget can be either a value to stay
	      below  or	 to  exceed. (You provide this value to gWLM using the
	      gwlmsend command).  For example, response time would be a	 value
	      to  stay	below.	Adding	CPU resources should help the workload
	      stay below a certain response time. As an example of a value  to
	      exceed,  polCpuTarget could be x transactions per second. Adding
	      resources in this case  helps  the  workload  maintain  or  even
	      exceed the number of transactions.

       polCpuRequest
	      Is  the  amount of CPU resources that a policy asks gWLM to give
	      to the policy's workloads.

       polCpuReading

	      + Utilization policies / OwnBorrow policies:
		Is utilization.

	      + Fixed policies:
		Is the amount of CPU resources allocated to the compartment of
		any associated workload.

	      + Custom policies:
		Is  the value of the metric you update using the gwlmsend com‐
		mand.

       polCpuOwned
	      Is the number of CPUs (cores) owned by the policy.

       polTicapEnabled
	      Indicates whether the policy was	configured  to	use  Temporary
	      Instant  Capacity	 (TiCAP). If a policy is enabled to use TiCAP,
	      it can do so regardless of whether TiCAP use is enabled  on  the
	      SRD level, which is indicated in the srdTicapMode column.

	      Possible entries in this column are:

	      true
		The  policy  is enabled to use TiCAP, if available, to satisfy
		policy requests.

	      false
		Default setting--the policy is not allowed to use TiCAP.

       polActiveId
	      Is an ID for the effective policy. This value matches the	 polId
	      value  unless  a conditional policy is being used, in which case
	      the value identifies the policy in effect as a result of a  con‐
	      dition being met.

       polActiveType
	      Indicates	 the  type  (Fixed, OwnBorrow, Utilization, or Custom)
	      for the effective policy. This value matches the	polType	 value
	      unless  a	 conditional  policy  is being used, in which case the
	      value identifies the type of policy in effect as a result	 of  a
	      condition being met.

       Whitespace (tabs, spaces) within a line is ignored.

       At  least  one column header line must be read before metric data lines
       are read. If a metric data line is encountered before  a	 valid	column
       header line, gwlmreport exits with an error to stderr.

       If  you	have  concatenated  several  CSV files, you may have duplicate
       header lines. Only the first header line is used	 (later	 header	 lines
       are ignored).

				CSV Metric lines
       After  getting a version line and a column header line, the rest of the
       file should be comma-delimited metrics.	The  number  of	 metrics  must
       match the column headers and extract file version type. If they do not,
       the data is discarded and gwlmreport exits with an error.

       Here is an example line from gwlmreport with dataversion=3.0:

	      1194378195009, 1194378495019, MySystem.srd,  1,  Managed,	 none,
	      default,	1,  hpvm,  MySystem.hp.com,  0.03,  3.0,  1.02,	 1.02,
	      0.0029, MySystem.OTHER, 1, CPU_Utilization, 5, Utilization, 0.0,
	      2048.0, 1.0, 1.0, 75.0, 0.0115, 0.2888, 0.0, false, 5

       Whitespace (tabs, spaces) within a line is ignored.

   Report: abnormal utilization
       The abnormal utilization report has the following sections:

	      + Report information

	      + Workload context information

	      + Samples and Utilization by period

	      + Period daterange and timeslot info

	      + Footnotes

       Reports	are  generated for each workload specified or for all possible
       workloads if none are specified. The components	of  each  section  are
       described below.

			       Report information
       This section gives information about the report itself.

       ReportDate
	      The date and time when the report was generated.

       Workload
	      The name of the workload.

       ReportDateRange
	      Calendar dates covered by report.

       PossibleSamples
	      The  total number of samples that is possible during the Report‐
	      DateRange.  (This number is the sample length divided  into  the
	      ReportDateRange.)

       SeenDataRange
	      The  date	 of the first sample from the gWLM database or the CSV
	      file used as input to the date of the last sample.

       TargetDate
	      Date the report is focused upon. This date  was  specified  when
	      the  report was requested. (If no date was specified, this value
	      matches the enddate value.)

			  Workload context information
       Provides contextual information for the workload, such as its SRD, pol‐
       icy, and compartment.

       The workload context information generated with the abnormalutil report
       matches the information produced with the resource  audit  report.  For
       descriptions of this information, refer to the "Workload context infor‐
       mation" section in the "Report: resource audit" section.

			Samples and utilization by period
       This section shows CPU utilization over time, showing the "normal" uti‐
       lization for a workload. If a workload misbehaves for a certain period,
       you can compare its utilization during that  period  against  the  data
       shown  in  this section to help determine what has changed. The section
       provides the following metrics:

       AvgUtil
	      Average CPU utilization.

       AvgReq Average CPU allocation request for the workload by its policy.

       AvgAlloc
	      Average CPU allocation gWLM gave to the workload.

       AvgCons
	      Average CPU consumption in terms of cores.

       ActSamp
	      The actual number of samples seen in a given time period (column
	      heading in the report) from the current data source.

       PossSamp
	      The  number  of possible samples for a given time period (column
	      heading in the report).

       AvgSampDur
	      Average duration of each sample.

       PolMin The policy's minimum core value.

       PolOwn The policy's owned core value.

       PolMax The policy's maximum core value.

		       Period daterange and timeslot info
       This section indicates dates and times for the samples. It gives a more
       full  explanation of the column headings from the table in the "Samples
       and Utilization by period" section.

       Previous Sample
	      Dates/times for the sample immediately before the TargetDate.

       Previous Hour
	      The hour previous to the TargetDate.

	      DesiredDateRange
		     Shows the date/time for the previous hour.

	      ActualDateRange
		     Shows the date/time actually  used.  This	value  matches
		     DesiredDateRange  if  the workload existed for the entire
		     period. Otherwise, "null" indicates that samples were not
		     available at the beginning and/or end of the time period.

	      Samples
		     Indicates	the number of samples collected from the given
		     time period.

       Previous 24 Hours
	      The 24 hours previous to the TargetDate.

	      DesiredDateRange, ActualDateRange, and Samples are as  described
	      for "Previous Hour" above.

       Weekly Timeslot
	      The  one	hour  matching the hour used with TargetDate, but from
	      the week before the TargetDate.

	      Samples indicates the number of samples collected from the given
	      time period.

       All Samples
	      DesiredDateRange,	 ActualDateRange, and Samples are as described
	      for "Previous Hour" above.

       So if --targetdate is 2005/07/14:12, then:

       Previous Sample
	      is the sample immediately before 2005/07/14:12

       Previous Hour
	      is the period 2005/07/14:11:00:00 to 2005/07/14:11:59:59

       Previous 24 Hours
	      is 2005/07/13:12:00:00 to 2005/07/14:11:59:59

       Weekly Timeslot
	      is any Monday from 12:00:00 to 12:59:59

       All Samples
	      includes any samples that fell within ReportDateRange

				    Footnotes
       Footnotes are printed to warn or alert you that there was some kind  of
       exceptional  event  during  the	report durations that could affect the
       data.

       The footnotes generated with the abnormalutil report  match  the	 foot‐
       notes  produced with the resource audit report. For descriptions of the
       footnotes, refer to the Footnotes subsection of the  "Report:  resource
       audit" section.

   Report: ovpafeed
       The  gwlmreport	ovpafeed  command  does	 not  generate	a text report;
       rather, it produces data	 in  a	DSI  logfileset	 in  /var/opt/dsi/ver‐
       sion/gwlm* for use by the OVPA subsystem.

       The  data  is a subset of gWLM's historical data and the data presented
       in gWLM's advanced reports. Making it available to OV tools is intended
       as  a  service  for customers that already use OVPA or OpenView Service
       Reporter in their normal work. If you do not need  to  view  gWLM  data
       with OVPA or OVSR, there is no need to run gwlmreport ovpafeed.

       If  you no longer need the data from the ovpafeed reports or you simply
       want to erase all your DSI data and start  over,	 you  can  delete  the
       /var/opt/gwlm/dsi/version/*  directory.	You  must  then run gwlmreport
       ovpafeed --setup again before doing further ovpafeed reports.

       For information on using the ovpafeed command, see Example  11  in  the
       EXAMPLES section above.

   Report: config
       The config report summarizes the current configuration. With --diff, it
       summarizes configuration changes between the specified  start  and  end
       dates.

       The report contents are self-explanatory.

ERRORS, WARNINGS, and FOOTNOTES
   ERRORS
       If gwlmreport is successful, it exits with a zero.

       For any error, a message is printed to stderr and gwlmreport exits with
       a nonzero value.

       Errors include:

       The --inputpath directory does not exist or is unreadable.

       The --outputpath directory does not exist or is unwritable.

       Cannot connect to gWLM database--gWLM is not running

	      If gWLM has difficulties retrieving historical data for a	 work‐
	      load, errors are logged to the gwlmcmsd log file and possibly to
	      the gwlmagent log file. For information on these log files,  see
	      the gwlmcmsd(1M) manpage.

       Unexpected line numbers in errors

	      When  specifying	--inputpath=path and multiple --workload=work‐
	      load arguments, gwlmreport combines the CSV files	 for  all  the
	      specified	 workloads  into  a single input stream.  As a result,
	      any line numbers given in error  messages	 are  for  the	single
	      input  stream--not the individual CSV files. For example, if you
	      have 3 files each of 1000 lines, an  error  might	 mention  line
	      1711.  This  would  actually be a problem around line 711 in the
	      CSV file for the second workload specified  in  your  gwlmreport
	      command line.

   WARNINGS
       gwlmreport  produces  warnings  to  stderr of irregularities seen while
       extracting the data and building any reports.

       If no workloads match the target workload names, a warning is  reported
       that  no	 samples were found for the given workloads.  Similarly, if no
       samples are found in the database or CSV input that match the specified
       reporting  time frame, policy name, or no Managed samples were found, a
       warning is printed:

	      "No audit report possible for workload "mywkld" as it  had  zero
	      matching samples.	 There are several potential reasons for this:
	      there may be no workload by that name, no matching data for  the
	      given  dates, only samples that are Advisory or the wrong policy
	      name."

   FOOTNOTES
       For the resourceaudit, topborrowers,  and  abnormalutil	reports,  many
       input  data irregularities are detected and warnings produced via foot‐
       notes in the report.

LIMITATIONS
       You must be root on an HP-UX system or a member of  the	Administrators
       group  on a Windows system to run gwlmreport.  Also, you must run gwlm‐
       report on the gWLM central management server (the system where gwlmcmsd
       is running.)

FEEDBACK
       If  you	would  like to comment on the current HP gWLM functionality or
       make suggestions for future releases, please send email to:

	      gwlmfeedback@rsn.hp.com

								gwlmreport(1M)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net