pmtraversepmns(3) [centos man page]

PMTRAVERSEPMNS(3)					     Library Functions Manual						 PMTRAVERSEPMNS(3)

NAME

       pmTraversePMNS, pmTraversePMNS_r - traverse the performance metrics name space

C SYNOPSIS

       #include <pcp/pmapi.h>

       int pmTraversePMNS(const char *name, void (*dometric)(const char *));
       int pmTraversePMNS_r(const char *name, void (*dometric_r)(const char *, void *), void *closure);

       cc ... -lpcp

DESCRIPTION

       The routine pmTraversePMNS may be used to perform a depth-first traversal of the Performance Metrics Name Space (PMNS).

       The  traversal  starts at the node identified by name - if name is an empty string (i.e. ""), the traversal starts at the root of the PMNS.
       Usually name would be the pathname of a non-leaf node in the PMNS.

       For each leaf node (i.e. performance metric) found in the traversal, the user-supplied routine dometric is called with the full pathname of
       that  metric  in  the PMNS as the single argument.  This argument is null-byte terminated, and is constructed from a buffer that is managed
       internally to pmTraversePMNS.  Consequently the value is only valid during the call to dometric - if the pathname needs to be retained,	it
       should be copied using strdup(3C) before returning from dometric.

       The pmTraversePMNS_r routine performs the same function, except the callback method func_r has an additional parameter that will be closure
       from the initial call to pmTraversePMNS_r.  The additional parameter to pmTraversePMNS_r and the callback method allows the caller to  pass
       context	through pmTraversePMNS_r and into the callback method func_r, making the service more useful for multi-threaded applications where
       thread-private data can be accessed in the callback method via the closure argument.

       On success pmTraversePMNS returns the number of children of name, which may be zero.

SEE ALSO

       PMAPI(3) and pmGetChildren(3).

DIAGNOSTICS

       PM_ERR_NOPMNS
	      Failed to access a PMNS for operation.  Note that if the application hasn't a priori called pmLoadNameSpace(3) and wants to use  the
	      distributed PMNS, then a call to pmTraversePMNS must be made inside a current context.

       PM_ERR_NAME
	      The initial pathname name is not valid in the current PMNS.

       PM_ERR_*
	      Other diagnostics are for protocol failures when accessing the distributed PMNS.

Performance Co-Pilot							PCP							 PMTRAVERSEPMNS(3)

PMNSADD(1)						      General Commands Manual							PMNSADD(1)

NAME

       pmnsadd - add new names to the Performance Co-Pilot PMNS

SYNOPSIS

       $PCP_BINADM_DIR/pmnsadd [-d] [-n namespace] file

DESCRIPTION

       pmnsmerge(1)  performs  the  same  function as pmnsadd and is faster, more robust and more flexible. It is therefore recommended that pmns-
       merge(1) be used instead.

       pmnsadd adds subtree(s) of new names into a Performance Metrics Name Space (PMNS), as used by the components of	the  Performance  Co-Pilot
       (PCP).

       Normally  pmnsadd operates on the default Performance Metrics Namespace (PMNS), however if the -n option is specified an alternative names-
       pace is used from the file namespace.

       The default PMNS is found in the file $PCP_VAR_DIR/pmns/root unless the environment variable PMNS_DEFAULT is set, in which case	the  value
       is assumed to be the pathname to the file containing the default PMNS.

       The  new names are specified in the file, arguments and conform to the syntax for PMNS specifications, see pmns(5).  There is one PMNS sub-
       tree in each file, and the base PMNS pathname to the inserted subtree is identified by the first group named in	each  file,  e.g.  if  the
       specifications begin

		 myagent.foo.stuff {
		     mumble	123:45:1
		     fumble	123:45:2
		 }

       then the new names will be added into the PMNS at the non-leaf position identified by myagent.foo.stuff, and following all other names with
       the prefix myagent.foo.

       The new names must be contained within a single subtree of the namespace.  If disjoint subtrees need to be added, these	must  be  packaged
       into separate files and pmnsadd used on each, one at a time.

       All  of	the  files  defining  the  PMNS  must  be located within the directory that contains the root of the PMNS, this would typically be
       $PCP_VAR_DIR/pmns for the default PMNS, and this would typically imply running pmnsadd as root.

       As a special case, if file contains a line that begins root { then it is assumed to be a complete PMNS that needs to be merged, so none	of
       the subtree extraction and rewriting is performed and file is handed directly to pmnsmerge(1).

       Provided  some  initial integrity checks are satisfied, pmnsadd will update the PMNS using pmnsmerge(1) - if this fails for any reason, the
       original namespace remains unchanged.

       The -d option allows the resultant PMNS to optionally contain duplicate PMIDs with different names in the PMNS.	By default this  condition
       is considered an error.

CAVEAT

       Once  the  writing  of the new namespace file has begun, the signals SIGINT, SIGHUP and SIGTERM will be ignored to protect the integrity of
       the new files.

FILES

       $PCP_VAR_DIR/pmns/root	the default PMNS, when then environment variable PMNS_DEFAULT is unset

PCP ENVIRONMENT

       Environment variables with the prefix PCP_ are used to parameterize the file and directory names used by PCP.  On  each	installation,  the
       file  /etc/pcp.conf contains the local values for these variables.  The $PCP_CONF variable may be used to specify an alternative configura-
       tion file, as described in pcp.conf(5).

SEE ALSO

       pmnsdel(1), pmnsmerge(1), pcp.conf(5), pcp.env(5) and pmns(5).

Performance Co-Pilot							PCP								PMNSADD(1)