<ConstraintDef> element

Syntax

Parent element: <Catalog>, <ParameterDef>

The following attributes are supported:

Table 1. Attributes
Attribute	Required	Type	Description
id	no*	string	Specifies the name of the parameter constraint.

*This attribute must be specified for <Constraint> elements defined at the catalog level.

The following child elements are supported:

Table 2. Child Elements
Child Elements	Required	Description
<Description>	no	Textual description of the disruptive command.
<PreOp>	no	Disruptive operations to run before setting the parameter value.
<PostOp>	no	Disruptive operations to run after setting the parameter value.
<BuiltIn>	no	Built-in disruptive operation This element may occur multiple times.

Usage

Some tuning and configuration parameters may require disruptive operations for value changes to take effect. A disruptive operation is any operation that may temporarily interrupt access to a service or a device. Typical disruptive operations are restarting a daemon, unmounting or mounting a filesystem, bringing a network adapter card offline or online. The AIX® Runtime Expert program uses constraints to show that a parameter requires a disruptive operations for changes to take effect. A <ConstraintDef> element is used to define such a constraint.

The constraint can be defined either:

Inside a <ParameterDef> element, if the constraint only applies to the single parameter.
At the catalog level, the <ConstraintDef> element must have an id attribute to allow the constraint to be referenced later in <ParameterDef> elements.

Built-In constraint

The <BuiltIn> element does not contain any attribute or child element.

The built-in constraint defines operations that are hard coded in the core engine. There is currently only one built-in constraint defined: bosboot. The difference of built-in constraints with other disruptive operations is that the bosboot command is never run by AIX Runtime Expert. The core engine will only warn that a bosboot is required for changes to take effect.

0590-206 A manual post-operation is required for the changes to take effect
Please perform a bosboot

PreOp and PostOp constraint

The <PreOp> element defines mandatory commands (shell expressions) to be run before the parameter value is set by the set configuration method. The <PostOp> element defines mandatory commands to be run after the execution of the set configuration method.

An <ConstraintDef> element must contain 0 or one <PreOp> child element, and 0 or one <PostOp> child element.

Examples

Example of a built-in constraint (at catalog level)

<ConstraintDef id="bosboot">
  <Description>
<NLSCatalog catalog="artexcat.cat" setNum="51" msgNum="3"> 
    bosboot
</NLSCatalog>
  </Description>
  <Built>Inbosboot</BuiltIn>
</ConstraintDef>

Example of <PreOp> constraint: The clic constraint in the trustchkParam.xml catalog. Note that in this example, the preop command does not run anything, but only checks the presence of a kernel extension required by the set command. If the kernel extension is not installed, then the constraint defined in the <PreOp> element will fail and the set command will not be run:
```
<ConstraintDef id="clic">
  <Description>
  <NLSCatalog catalog="artexcat.cat" setNum="48" msgNum="3">
     Check that the clic.rte kernel extension is installed. 
  </NLSCatalog>
  </Description>
  <Pre>Oplslpp -l "clic*"</PreOp>
 </ConstraintDef>
```

Example of <PostOp> constraint: The set Kernel Security Tables constraint in the authParam.xml catalog. The modified databases need to be loaded only once in the kernel after all modifications have been made.

<ConstraintDef id="setkst">
  <Description>
<NLSCatalog catalog="artexcat.cat" setNum="5" msgNum="3">
Send the authorizations database to the KST (Kernel Security Tables)
    </NLSCatalog></Description>
  <PostOp>/usr/sbin/setkst -t auth &gt;/dev/null</PostOp>
  </ConstraintDef>