1PMPARSETIMEWINDOW(3) Library Functions Manual PMPARSETIMEWINDOW(3)
2
6 pmParseTimeWindow - parse time window command line arguments
7
9 #include <pcp/pmapi.h>
10 int pmParseTimeWindow(const char *swStart, const char *swEnd,
12 const char *swAlign, const char *swOffset,
13 const struct timeval *logStart, const struct timeval *logEnd,
14 struct timeval *rsltStart, struct timeval *rsltEnd,
15 struct timeval *rsltOffset, char **errMsg);
16 cc ... -lpcp
18
20 pmParseTimeWindow is designed to encapsulate the interpretation of the
21 -S, -T, -A and -O command line options used by Performance Co-Pilot
22 (PCP) applications to define a time window of interest. The time win‐
23 dow is defined by a start time and an end time that constrains the time
24 interval during which the PCP application will retrieve and display
25 performance metrics. In the absence of the -O and -A options to speci‐
26 fy an initial sample time origin and time alignment (see below), the
27 PCP application will retrieve the first sample at the start of the time
28 window.
29 The syntax and meaning of the various argument formats for these op‐
31 tions is described in PCPIntro(1).
32
34 pmParseTimeWindow expects to be called with the argument of the -S op‐
35 tion as swStart, the argument of the -T option as swEnd, the argument
36 of the -A option as swAlign, and the argument of the -O option as
37 swOffset. Any or all of these parameters may be NULL to indicate that
38 the corresponding command line option was not present.
39 If the application is using a PCP archive log as the source of perfor‐
41 mance metrics, you also need to supply the time of the first archive
42 log entry as logStart, and the time of the last archive log entry as
43 logEnd. See pmGetArchiveLabel(3) and pmGetArchiveEnd(3) for how to ob‐
44 tain values for these times.
45 If the application is manipulating multiple concurrent archive logs,
47 then the caller must resolve how the default time window is to be de‐
48 fined (the union of the time intervals in all archive logs is a likely
49 interpretation).
50 If the application is using a live feed of performance data, logStart
52 should be the current time (but could be aligned on the next second for
53 example), while logEnd should have its tv_sec component set to INT_MAX.
54 The rsltStart, rsltEnd and rsltOffset structures must be allocated be‐
56 fore calling pmParseTimeWindow.
57 You also need to set the current PCP reporting time zone to correctly
59 reflect the -z and -Z command line parameters before calling pmParse‐
60 TimeWindow. See pmUseZone(3) and friends for information on how this
61 is done.
62
64 PMAPI(3), pmGetArchiveEnd(3), pmGetArchiveLabel(3), pmNewCon‐
65 textZone(3), pmNewZone(3), pmParseInterval(3) and pmUseZone(3).
66
68 If the conversion is successful, pmParseTimeWindow returns 1 and fills
69 in rsltStart, rsltEnd and rsltOffset with the start, end, and offset
70 times for the time window defined by the input parameters. The errMsg
71 parameter is not changed when pmParseTimeWindow returns 1.
72 If the conversion is successful, but the requested alignment could not
74 be performed (e.g. the PCP archive log is too short) the alignment is
75 ignored, rsltStart, rsltEnd and rsltOffset are filled in and pmParse‐
76 TimeWindow returns 0. In this case, errMsg will point to a warning
77 message in an internal static buffer. This buffer should not be freed.
78 If the argument strings could not be parsed, pmParseTimeWindow returns
80 -1. In this case, errMsg will point to an error message in a static
81 internal buffer.
82Performance Co-Pilot PCP PMPARSETIMEWINDOW(3)