pmgetchildren(3) [centos man page]

PMGETCHILDREN(3)					     Library Functions Manual						  PMGETCHILDREN(3)

NAME

       pmGetChildren - return the descendent nodes of a PMNS node

C SYNOPSIS

       #include <pcp/pmapi.h>

       int pmGetChildren(const char *name, char ***offspring);

       cc ... -lpcp

DESCRIPTION

       Given  a  fully	qualified  pathname  to  a node in the current Performance Metrics Name Space (PMNS), as identified by name, pmGetChildren
       returns via offspring a list of the relative names of all of the immediate descendent nodes of name in the current PMNS.

       As a special case, if name is an empty string (i.e.""), the immediate descendants of the root node in the PMNS will be returned.

       Normally, pmGetChildren will return the number of descendent names discovered, else a value less than zero for an error.   The  value  zero
       indicates that name is a valid metric name, i.e. is associated with a leaf node in the PMNS.

       The  resulting  list  of  pointers  offspring  and  the values (the relative names) that the pointers reference will have been allocated by
       pmGetChildren with a single call to malloc(3C), and it is the responsibility of the pmGetChildren caller to free(offspring) to release  the
       space when it is no longer required.

       When  an  error	occurs,  or name is a leaf node (i.e. the result of pmGetChildren is less than one), offspring is undefined (no space will
       have been allocated, and so calling free(3C) is a singularly bad idea).

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).	Values for these variables may be obtained programmatically using the pmGetConfig(3) function.

SEE ALSO

       PMAPI(3), pmGetChildrenStatus(3), pmGetConfig(3), pmLoadASCIINameSpace(3), pmLoadNameSpace(3), pmLookupName(3),	pmNameID(3),  pcp.conf(5),
       pcp.env(5) and pmns(5).

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 pmGetChildren must be made inside a current context.

       PM_ERR_NAME
	      The 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							  PMGETCHILDREN(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)