NAME
mxtask - Systems Insight Manager task XML file format
SYNOPSIS
mxtask
DESCRIPTION
The mxtask command supports reading and writing task information in
the eXtensible Markup Language (XML) format. You may use this
capability to create new scheduled tasks in the Systems Insight
Manager environment. Each task XML file may contain definition blocks
for one or more tasks.
The task specific XML format may be generated by the following "list"
type mxtask command option (-lf). This option will list the specified
task data in the task specific XML format (as described in this man
page), to stdout. The output could be redirected to an external file
as shown in the 2nd example. The output file could then be used as
input for the (-cf) command to create a similar task.
mxtask -lf taskname
mxtask -lf taskname > outfilename
The task specific XML format is utilized by the following "create"
type mxtask command option. This option will create a new task based
off the task specifc XML contents (as described in this man page) of
the specified file.
mxtask -cf filename
Document Type Definition
The Document Type Definition (DTD) file defines the constraints for an
XML file. These constraints include the valid element tags,
attributes, and the cardinality of elements in an XML file. The Task
DTD file is named tasklist.dtd and is included in the following
paragraph. Note that due to man page formatting, the following text
may not look the same as the contents of the actual DTD file.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- The task-list is the root element defined for the task
XML DTD and will contain at least one or more task elements,
with each element block containing all required data for
creating a new scheduled task.
-->
<!ELEMENT task-list ( task+ )>
<!-- The task element consists of the following required data
elements: toolname, queryname, scheduleinfo, toolparams.
Note that for some Tasks, 'scheduleinfo' and/or 'toolparams'
may not contains any content, however, the element must
still exist (although empty). Doing this so users will
always be able to see all available elements for the Task
XML format. If required, This DTD design could be changed
so that the existance of the 'scheduleinfo' and 'toolparams'
elements within the XML are optional (implied).
-->
<!ELEMENT task (toolname,queryname,scheduleinfo,timefilter,toolparams)>
<!-- The task element itself has the following attributes:
-name required attribute specifies the task name.
-type required attribute specifies the task type.
(valid values: add, remove, manual, schedule)
-owner optional attribute specifies the task owner.
(if omitted, owner is current user)
-runmode optional attribute specifies the task run mode.
(valid values are: runnow or runatstartup)
-state optional attribute specifies whether task is enabled or disabled.
(valid values are: enabled or disabled)
(if attribute is omitted, default is disabled)
-guid attribute specifies the task GUID and is optional.
(guid attribute not recongnized at this time)
-->
<!ATTLIST task name CDATA #REQUIRED
owner CDATA #IMPLIED
runmode CDATA #IMPLIED
state CDATA #IMPLIED
guid NMTOKEN #IMPLIED >
<!-- As said above, the task element requires an attribute
called 'type' that only allows the following valid values.
(add, remove, manual, schedule)
-->
<!ATTLIST task type (add | remove | manual | schedule) #REQUIRED >
<!-- The toolname element specifies the tool name associated with
specified task and is required.
-->
<!ELEMENT toolname (#PCDATA)>
<!-- The queryname element specifies the query name associated with
specified task and is required.
-->
<!ELEMENT queryname (#PCDATA)>
<!-- The scheduleinfo element specifies the schedule information
associated with the specified task and is required.
-->
<!ELEMENT scheduleinfo (#PCDATA)>
<!-- 4 possible attributes may accompany the scheduleinfo element.
Attribute Req/Opt Valid Values
========= ======= ============
1. interval (optional: required if task type = schedule)
minutes,hours,days,weeks,months,daily,runonce,ranonce
2. periodic (optional: depends on interval type)
some numeric value
3. time (optional: depends on interval type)
HH:MM (24hr clock)
4. day (optional: depends on interval type)
interval=weeks: sunday,monday,etc
interval=months: numeric value= 1 thru 31
5. date (optional: depends on interval type)
date=mm/dd/yy
-->
<!-- The interval attribute is used to specify the schedule interval type.
Only 7 string values are allowed as defined below.
The 'interval' attribute is required when Task type is 'schedule'.
-->
<!ATTLIST scheduleinfo interval (minutes | hours | days | weeks | months | daily | runonce | ranonce) #IMPLIED >
<!-- The 'periodic' attribute is used to specify the schedule interval value
which is a string value representing some numeric value.
The 'periodic' attribute is NOT required when 'interval' type is
'daily', 'runonce' or 'ranonce'.
-->
<!ATTLIST scheduleinfo periodic CDATA #IMPLIED >
<!-- The 'time' attribute is used to specify a schedule time indicating
when the Task is to run. The string format for time is in 24hr
format - HH:MM
The 'time' attribute is NOT required when 'interval' type is
'minutes', 'hours', 'runonce' or 'ranonce'.
-->
<!ATTLIST scheduleinfo time CDATA #IMPLIED >
<!-- The 'day' attribute is used to specify the day a scheduled task
is set to run. If the 'interval' attribute is 'weeks', then
this attribute must be in the form of 'sunday', 'monday', etc.
If the 'interval' attribute is 'months', then this attribute
must be in the form of '1' to '31'.
The 'day' attribute is NOT required when 'interval' type is
'minutes', 'hours', 'days', 'daily', 'runonce' or 'ranonce'.
-->
<!ATTLIST scheduleinfo day CDATA #IMPLIED >
<!-- The 'date' attribute is used to specify the date a scheduled task
is set to run. If the 'interval' attribute is 'runonce' or 'ranonce',
then this attribute must be in the form of 'mm/dd/yy'.
The 'date' attribute is NOT required when 'interval' type is
'minutes', 'hours', 'weeks', 'months', 'days' or 'daily'.
The 'date' attribute IS required when the 'interval' type
is 'runonce' or 'ranonce'.
The 'periodic', 'day' and 'time' attributes are NOT required
when the 'interval' type is 'runonce' or 'ranonce',
-->
<!ATTLIST scheduleinfo date CDATA #IMPLIED >
<!-- The 'timefilter' element is used to specify two major actions for a task.
(1) To simply associate a particular time filter with the task to be
created. Only the time filter name need be provided within the
timefilter element - no additional time filter data required. Note the
time filter specified must already exist in the current Systems
Insight Manager repository.
(2) To create a new time filter and associate that time filter with the
task to be created. Additional time filter data must be provide
within the timefilter element.
Time filters provide a means for the user to define certain times of the
day when a task can run. Several standard time filters are provided for
in Systems Insight Manager, but user's can define their own time filters.
A time filter is basically a 7 x 24 (7-days x 24-hr) array whereby one or
more hours (1-24) are selected as valid task runtime windows, and for each
desired day (1-7) of the week.
The timefilter element must be present witin the XML, regardless if a time
filter is or is not specified for particular task.
If no time filter is to be associated with a particular task, then the
time filter element must still be present within the XML, but must be
empty. That is, must ensure the 'name' attribute is not present within
the timefilter element.
If an aleady-existing time filter is to be associated with a task, then
the 'name="xxx"' attribute must be present within the timefilter element.
If a new time filter need be created for a particular task, then (1) the
name of the new time filter need be provided, and (2) additional time
filter schedule data sub-element (one or more) must be provided. The
'day' sub-elements are based off the 7-day week. For each 'day' element,
valid task run times are specified on a 1-hr resolution for a 24-hr clock.
Time filter schedule data elements are defined as follows with their
corresponding day of the week values:
<mon> - Monday
<tue> - Tuesday
<wed> - Wednesday
<thu> - Thursday
<fri> - Friday
<sat> - Satuday
<sun> - Sunday
Examples:
'n' place holders in the following examples represent numbers in the
range of 0-23 and represent whole hours in a 24 hr day. For example,
if you wanted to specify time filter that's active for the first 3 hour
period of the day Monday (12:00 AM to 3:00 AM), then the <mon> element
would look as follows. Single value comma-delimited numbers are
interpreted as inclusive times of a 24-hr day, starting with time zero.
The following could also be interpreted as 0=12:00AM-12:59AM,
1=1:00AM-1:59AM, 2=2:00AM-2:59AM.
<mon>0,1,2</mon>
If you wanted to specify a time filter only be active in the last 3
hour period of the day Monday (9:00PM to midnight), then the <mon>
element would look as follows. It will be interpreted as
21=9:00AM-9:59AM, 22=10:00AM-10:59AM, 23=11:00AM-midnight
<mon>21,22,23</mon>
A short-hand 'range' syntax is allowed when defining time filter
data. Note that when the ranging syntax is used, the upper time
value interpreted as a non-inclusive time value. The following
would be interpreted as "0,1,2", or 12:00AM up to 3:00AM or
12:00AM to 2:59AM.
<mon>0-3</mon>
The following are two ways to represent a non-defined time filter.
Even if a task has no associated time filter name or name plus
data, one of the following must reside in the task XML block.
<timefilter />
<timefilter></timefilter>
The following two examples show how to specify an already existant
time filter with a new task definition. The MxTask CLI will not
attempt to create a new time filter.
<timefilter name="xxx" />
<timefilter name="xxx"></timefilter>
The following two examples show how to specify that a new time
filter be created and associated with a new task. The MxTask CLI
will create a new time filter based off the specified time filter
data.
<timefilter name="xxx">
<mon>n,n,n</mon>
</timefilter>
<timefilter name="xxx">
<mon>n,n,n</mon>
<tue></tue>
<wed />
<sat>22,23</sat>
</timefilter>
When manually creating time filter data, remember that the 0 through
12 values represent the AM times, and the PM times are represented by
the 13 to 23 values (24hr clock). To determine a PM time value, simply
add the value 12 to the desired PM time - that will then be the value
to insert into the time filter data string. For example, you want to
create a Monday time data string for the hours 8:00AM up to 5:00PM. To
determine the value that represents 5:00PM, simply add 12+5 - the value
to use in the data string will then be 17. The string would look as
follows using the range syntax:
<mon>8-17</mon>
The string would look as follows using the single value syntax. Note
that when using single value syntax, we must omit the 17 value as the
values here are interpreted as being inclusive. In this example, we
do not want to include the 5:00PM-5:59PM hour.
<mon>8,9,10,11,12,13,14,15,16</mon>
-->
<!ELEMENT timefilter (mon?,tue?,wed?,thu?,fri?,sat?,sun?) >
<!ATTLIST timefilter name CDATA #IMPLIED>
<!ELEMENT mon (#PCDATA)>
<!ELEMENT tue (#PCDATA)>
<!ELEMENT wed (#PCDATA)>
<!ELEMENT thu (#PCDATA)>
<!ELEMENT fri (#PCDATA)>
<!ELEMENT sat (#PCDATA)>
<!ELEMENT sun (#PCDATA)>
<!-- The toolparams element specifies the Tool parameters that may be
required for the associated Tool. Some Tools require parameters,
some don't. This element is required to exist within the XML,
although at times, the element may not contain any content.
NOTE: The content stored within this element may be XML data. If
so, then the special XML chars 'less-than' and 'greater-than'
can NOT exist in their literal format - they must be expressed
as their 'character reference' or 'predefined entity reference'.
For example, a 'less-than' char must be expressed as either
"<" or "<". A 'greater-than' char as: ">" or ">".
-->
<!ELEMENT toolparams (#PCDATA) >
Elements
As defined in the DTD, the Task XML file must adhere to the following
general format:
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task name" type="schedule" owner="machine/user">
<toolname>tool name</toolname>
<queryname>query name</queryname>
<scheduleinfo interval="x" periodic="x" time="x" day="x" date="x"/>
<timefilter />
<toolparams />
</task>
</task-list>
As defined in the DTD, the Task XML file must contain the following
elements.
<?xml version="1.0" encoding="UTF-8" ?>
The first line of a Task XML file should be in the following format:
<?xml version="1.0" encoding="encoding-value" ?>
where the user substitutes a recognized encoding value for the
encoding-value parameter. The recognized encoding values may be found
at the following web site:
http://www.iana.org/assignments/character-sets
If no XML header line is specified, the system defaults encoding to
"UTF-8".
The "task-list" element must appear once in a user XML file and wraps
the list of Task information. The "task-list" element must contain one
or more "task" elements. Note if the "task-list" element contains no
"task" elements, the associated mxtask command will fail.
The "task" element must appear one or more times in a user XML file
and has the following format.
<task name="taskname" type="tasktype" owner="taskowner"
state="enabled">
The "task" element has two required attributes - "name" and "type".
The "name" attribute is mandatory and specifies the task name. The
name specified must be unique and must not already exist in the
Systems Insight Manager repository.
The "type" attribute is mandatory and specifies the type of task.
Valid values for the task type are "add", "remove", "manual" and
"schedule" and are described below.
add -task runs when systems or events meet the list criteria.
remove -task runs when systems or events no longer meet the list
criteria.
manual -task runs only when manually invoked.
schedule -task runs based off a defined schedule. When this task type
is specified, then the scheduleinfo element must contain the required
attributes that actually define the schedule.
The "task" element has several optional attributes - "owner",
"runmode" and "state".
The "owner" attribute specifies the owner of the task. If no owner is
specified, the current logged in user will be assigned as the task
owner.
The "runmode" attribute takes one of the following two values, either
"runnow" or "runatstartup".
runmode="runnow" - the task will be run as soon as it is created.
Note that the task will be forced to run by the MxTask CLI.
runmode="runatstartup" - the task will run the next time the CMS is
started.
The "state" attribute specifies whether the task should be created in
an "enabled" or "disabled" state. If no state attribute is specified,
the task will be created in the disabled state. If disabled, the task
must then be manually enabled from within the UI.
The "task" element must also contain several additional elements. Each
of these elements must appear once in each "task" element. Each
element must appear in the order they are defined in the DTD.
<toolname>tool name here</toolname>
<queryname>query name here</toolname>
<scheduleinfo interval="x" periodic="x" time="x" day="x" date="x"/>
<timefilter></timefilter>
The "toolname" element specifies an existing tool (by name) to
associate with the task and an assigned value is required. The tool
name specified must already exist in the Systems Insight Manager
repository.
<toolname>tool name here</toolname>
The "queryname" element specifies an existing query (by name) to
associate with the task and an assigned value is required. The query
name specified must already exist in the Systems Insight Manager
repository.
<queryname>query name here</toolname>
The "sheduleinfo" element defines schedule information (when the task
will run) for the task. Attributes for this element are only required
if the task "type" attribute is defined as "schedule" (task types
"add", "remove" and "manual" do not require schedule information).
The "scheduleinfo" element can contain five various attributes that
define the schedule. They are: "interval", "periodic", "time", "day"
and "date".
The "scheduleinfo" element has the following format by which a
complete run schedule can be defined for any task.
<scheduleinfo interval="x" periodic="x" time="x" day="x" date="x"/>
The "interval" attribute specifies the type of interval for the new
task. Valid values for the 'interval' attribute are as follows.
minutes - task will run every X minutes.
hours - task will run every X hours.
days - task will run every X days at specified time.
weeks - task will run every X weeks on specified day/time.
months - task will run every X months on specified day/time.
daily - task will run every day at specified time.
runonce - task will run once on specified date/time.
ranonce - task had already run on specified date/time.
The "perodic" attribute is a numeric value and specifies how often the
task will run. Valid values for the the "periodic attribute include
any numeric value greater than zero.
The "day" attribute specifies a day value and is required only when
the "interval" attribute is either "weeks" or "months". Valid "day"
attribute values are dependant on the "interval" attribute value
specified. If "interval" attribute value defined as "weeks", then the
valid "day" attribute values are "sunday", "monday", etc. If the
"interval" attribute value is defined as "months", then the valid
"day" attribute value is a numeric value in the range of 1-31.
The "date" attribute specifies a date value and is required only when
the "interval" attribute is "runonce" or "ranonce". Valid "date"
attribute values are in the form of mm/dd/yy.
The "time" attribute specifies a time value and is required for all
"interval" attribute types, excluding "minutes" and "hours". This
attribute defines the time at which the task will run and must be
specified in 24hr format - time="HH:MM"
The "timefilter" element is used to specify two major actions for a
task.
(1) To simply associate a particular time filter with the task to be
created. Only the time filter name need be provided within the
timefilter element. No additional time filter data required. Note the
time filter specified must already exist in the current Systems
Insight Manager database.
(2) To create a new time filter and associate that time filter with
the task to be created. Additional time filter data must be provided
within the timefilter element.
Time filters provide a means for the user to define certain times of
the day when a task can run. Several standard time filters are
provided for in Systems Insight Manager, but user's can define their
own time filters if need be. A time filter is basically a 7 x 24 (7-
days x 24-hr) array whereby one or more hours (0-23) are selected as
valid task runtimes, including each desired day (1-7) of the week.
The timefilter element must be present within the XML, regardless if a
time filter is or is not specified for particular task.
If no time filter is to be associated with a particular task, then the
time filter element must still be present within the XML, excluding
any data. That is, must ensure the 'name' attribute is not present
within the timefilter element.
If an aleady-existing time filter is to be associated with a task,
then the name="xxx" attribute must be present within the timefilter
element.
If a new time filter need be created for a particular task, then (1)
the name of the new time filter need be provided, and (2) additional
time filter schedule data sub-element (one or more) must be provided.
The 'day' sub-elements are based off the 7-day week. For each 'day'
element, valid task run times are specified on a 1-hr resolution for a
24-hr clock.
Time filter schedule data elements are defined as follows with their
corresponding day of the week values:
<mon> - Monday
<tue> - Tuesday
<wed> - Wednesday
<thu> - Thursday
<fri> - Friday
<sat> - Satuday
<sun> - Sunday
Examples:
0-23 and represent whole hours in a 24 hr day. For example, if you
wanted to specify time filter that's active for the first 3 hour
period of the day Monday (12:00 AM to 3:00 AM), then the <mon> element
would look as follows. Single value comma-delimited numbers are
interpreted as inclusive times of a 24-hr day, starting with time
zero. The following could also be interpreted as 0=12:00AM-12:59AM,
1=1:00AM-1:59AM, 2=2:00AM-2:59AM.
<mon>0,1,2</mon>
If you wanted to specify a time filter only be active in the last 3
hour period of the day Monday (9:00PM to midnight), then the <mon>
element would look as follows. It will be interpreted as 21=9:00PM-
9:59PM, 22=10:00PM-10:59PM, 23=11:00PM-midnight
<mon>21,22,23</mon>
A short-hand 'range' syntax is allowed when defining time filter data.
Note that when the ranging syntax is used, the lower time value is
interpreted as an inclusive time value, while the upper time value is
interpreted as a non-inclusive time value. The following would be
interpreted as "0,1,2", or 12:00AM up to 3:00AM or 12:00AM to 2:59AM.
<mon>0-3</mon>
The following are two ways to represent a non-defined time filter.
Even if a task has no associated time filter name or name plus data,
one of the following element tags must reside in the task XML block
and must be located between the 'schedule' element and the 'toolparms'
element.
<timefilter />
<timefilter></timefilter>
The following two examples show how to specify an already existant
time filter with a new task definition. The MxTask CLI will not
attempt to create a new time filter as there is no additional sub-
element time filter data present .
<timefilter name="xxx" />
<timefilter name="xxx"></timefilter>
The following two examples show how to specify that a new time filter
be created and associated with a new task. The MxTask CLI will create
a new time filter based off the specified time filter data.
<timefilter name="xxx">
<mon>n,n,n</mon>
</timefilter>
<timefilter name="xxx">
<mon>n,n,n</mon>
<tue></tue>
<wed />
<sat>22,23</sat>
</timefilter>
When manually creating time filter data, remember that the 0 through
12 values represent the AM times, and the PM times are represented by
the 13 to 23 values (24hr clock). To determine a PM time value,
simply add the value 12 to the desired PM time - that will then be the
value to insert into the time filter data string. For example, you
want to create a Monday time data string for the hours 8:00AM up to
5:00PM. To determine the value that represents 5:00PM, simply add
12+5 - the value to use in the data string will then be 17. The
string would look as follows using the range syntax:
<mon>8-17</mon>
The string would look as follows using the single value syntax. Note
that when using single value syntax, we must omit the 17 value as the
values here are interpreted as being inclusive. In this example, we
do not want to include the 5:00PM-5:59PM hour.
<mon>8,9,10,11,12,13,14,15,16</mon>
The "toolparams" element specifies the parameters for specified
Systems Insight Manager tool. Not all Systems Insight Manager tools
require parameters. Contents for this element are only required if the
tool specified in the "toolname" element does indeed require
additional parameters to run properly.
<toolparams />
Note1: If the content for the 'toolparams' element is stored as XML
data, then the tool parameter data must not contain the literal less-
than (<) or greater-than (>) characters. Instead, all less-than
characters must be replaced by the corresponding entity reference
"<", and all greater-than characters must be represented by the
corresponding entity reference ">".
Note2: The output generated from the "mxtask -lf taskname" command
will display any possible XML type tool parameter data in the proper
format (as described above) whereby any less-than and greater-than
characters are replaced by their corresponding entity references. The
output from the '-lf' command can therefore be used as input for
creating new tasks.
Below is a sample content for the "toolparams" element for the actual
Systems Insight Manager tool called "Hardware Status Polling".
<toolparams><?xml version="1.0"?> <XeObject
className="com.hp.mx.core.tools.polling.HardwareStatusPollingTaskModel"
classVersion="2.0"> <Property name="pollingTimeout">
<Simple>4</Simple> </Property> <Property
name="pollingRetries"> <Simple>1</Simple>
</Property> <Property name="pollingProtocols"> <Vector
size="0"> </Vector> </Property> </XeObject>
</toolparams>
Commenting
Comments may be included in XML files. The comment must begin with
the characters "<!--" and end with the characters "-->". Comments may
span multiple lines within the beginning and ending character tags.
Examples
This section contains some examples of "task" specific XML format.
This example defines a new task named task1 of type "add" (task runs
when systems or events meet the list criteria) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is not of type "schedule", the scheduleinfo element is empty.
Also, we're assuming the specified tool (tool1) does not require any
additional parameters, thus the toolparams element is empty. The task
state is also set to enabled.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="add" state="enabled">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo />
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "add" (task runs
when systems or events meet the list criteria) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is not of type "schedule", the scheduleinfo element is empty.
Also, we're assuming the specified tool (tool1) does not require any
additional parameters, thus the toolparams element is empty. A task
owner is also being specified.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="add" owner="machineName/userName">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo />
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "remove" (task
runs when systems or events no longer meet the list criteria) that is
associated with an existing Systems Insight Manager query called
"query1" and an existing Systems Insight Manager tool called "tool1".
Since the task type is not of type "schedule", the scheduleinfo
element is empty. Also, we're assuming the specified tool (tool1)
does not require any additional parameters, thus the toolparams
element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="remove">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo />
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "manual" (task
runs only when manually invoked) that is associated with an existing
Systems Insight Manager query called "query1" and an existing Systems
Insight Manager tool called "tool1". Since the task type is not of
type "schedule", the scheduleinfo element is empty. Also, we're
assuming the specified tool (tool1) does not require any additional
parameters, thus the toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="manual">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo />
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "schedule" (task
runs based off a periodic/day/time schedule) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is of type "schedule", the scheduleinfo element must contain the
schedule information. In this case, the task schedule specifies the
task will run every 30 minutes. We're also specifying the specified
tool (tool1) does not require any additional parameters, thus the
toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="schedule">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo interval="minutes" periodic="30" />
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "schedule" (task
runs based off a periodic/day/time schedule) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is of type "schedule", the scheduleinfo element must contain the
schedule information. In this case, the task schedule specifies the
task will run every 7 days at 1:00 AM. We're also specifying the
specified tool (tool1) does not require any additional parameters,
thus the toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="schedule">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo interval="days" periodic="7" time="1:00"/>
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "schedule" (task
runs based off a periodic/day/time schedule) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is of type "schedule", the scheduleinfo element must contain the
schedule information. In this case, the task schedule specifies the
task will run every 2 weeks on Friday at 6:00 PM. We're also
specifying the specified tool (tool1) does not require any additional
parameters, thus the toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="schedule">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo interval="weeks" periodic="2" day="friday" time="18:00"/>
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "schedule" (task
runs based off a periodic/day/time schedule) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is of type "schedule", the scheduleinfo element must contain the
schedule information. In this case, the task schedule specifies the
task will run every month on the 15th at 2:00 AM. We're also
specifying the specified tool (tool1) does not require any additional
parameters, thus the toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="schedule">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo interval="months" periodic="1" day="15" time="2:00"/>
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "schedule" (task
runs based off a periodic/day/time schedule) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is of type "schedule", the scheduleinfo element must contain the
schedule information. In this case, the task schedule specifies the
task will run every day at 5:00 AM. We're also specifying the
specified tool (tool1) does not require any additional parameters,
thus the toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="schedule">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo interval="daily" time="5:00"/>
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "schedule" (task
runs based off a periodic/day/time schedule) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is of type "schedule", the scheduleinfo element must contain the
schedule information. In this case, the task schedule specifies the
task will run once at 5:00 AM on January 1, 2004. We're also
specifying the specified tool (tool1) does not require any additional
parameters, thus the toolparams element is empty.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="schedule">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo interval="runonce" time="5:00" date="01/01/04"/>
<timefilter />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "add" (task runs
when systems or events meet the list criteria) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is not of type "schedule", the scheduleinfo element is empty.
Also, we're assuming the specified tool (tool1) does not require any
additional parameters, thus the toolparams element is empty. The task
is to be associated with an existing standard time filter call
"Weekend Plus".
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="add">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo />
<timefilter name="Weekend Plus" />
<toolparams />
</task>
</task-list>
This example defines a new task named task1 of type "add" (task runs
when systems or events meet the list criteria) that is associated with
an existing Systems Insight Manager query called "query1" and an
existing Systems Insight Manager tool called "tool1". Since the task
type is not of type "schedule", the scheduleinfo element is empty.
Also, we're assuming the specified tool (tool1) does not require any
additional parameters, thus the toolparams element is empty. The task
is to be associated with a new user-defined time filter that is active
only the first 3 hours of every day of the week. The time filter is
to be called "First 3 Hours Every Day".
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="task1" type="add">
<toolname>tool1</toolname>
<queryname>query1</queryname>
<scheduleinfo />
<timefilter name="First 3 Hours Every Day" >
<mon>0,1,2</mon>
<tue>0,1,2</tue>
<wed>0,1,2</wed>
<thu>0,1,2</thu>
<fri>0,1,2</fri>
<sat>0,1,2</sat>
<sun>0,1,2</sun>
</timefilter>
<toolparams />
</task>
w</task-list>
This example defines a new task named "Hardware Status Polling 2" of
type "schedule" (task runs based off a periodic/day/time schedule)
that is associated with an existing Systems Insight Manager query
called "All Servers" and an existing Systems Insight Manager tool
called "Hardware Status Polling". Since the task type is of type
"schedule", the scheduleinfo element must contain the schedule
information. In this case, the task schedule specifies the task will
run every week on Sunday at 1:00 AM. We must also specify the tool
parameters for the specified tool. Note that the parameters for the
"Hardware Status Polling" tool may be obtained via the mxtask -lf
"Hardware Status Polling" command.
<?xml version="1.0" encoding="UTF-8"?>
<task-list>
<task name="Hardware Status Polling 2" type="schedule">
<toolname>Hardware Status Polling</toolname>
<queryname>All Servers</queryname>
<scheduleinfo interval="weeks" periodic="1" day="sunday" time="1:00"/>
<timefilter />
<toolparams><?xml version="1.0"?>
<XeObject
className="com.hp.mx.core.tools.polling.HardwareStatusPollingTaskModel"
classVersion="2.0">
<Property name="pollingTimeout">
<Simple>4</Simple>
</Property>
<Property name="pollingRetries">
<Simple>1</Simple>
</Property>
<Property name="pollingProtocols">
<Vector size="0">
</Vector>
</Property>
</XeObject>
</toolparams>
</task>
</task-list>
Note that the above parameters for the "Hardware Status Polling" tool
may be viewed on the screen via the following mxtask command option:
mxtask -lf "Task Name"
Use redirection to save the screen output to an external Task XML
file. The file could be modifed and then used to create a similar
task via the -cf command option.
mxtask -lf "Task Name" > "Task Name.xml"
LIMITATIONS
This command may only be run on the CMS.
AUTHOR
mxtask was developed by the Hewlett-Packard Company.
SEE ALSO for HP-UX
mxtask(1M)
SEE ALSO for Linux
mxtask(8)
* Note: Care must be taken when specifying passwords on the command-
line. This makes them available in the command history, in the process
list while executing, and in the audit log if executed as part of a
task. Be sure to clear your command history, or use alternate methods
for specifying passwords, e.g. prompt, input file.