<ConstraintDef> element


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.


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.


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

    <ConstraintDef id="bosboot">
    <NLSCatalog catalog="artexcat.cat" setNum="51" msgNum="3"> 
  2. 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">
      <NLSCatalog catalog="artexcat.cat" setNum="48" msgNum="3">
         Check that the clic.rte kernel extension is installed. 
      <Pre>Oplslpp -l "clic*"</PreOp>
  3. 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">
    <NLSCatalog catalog="artexcat.cat" setNum="5" msgNum="3">
    Send the authorizations database to the KST (Kernel Security Tables)
      <PostOp>/usr/sbin/setkst -t auth &gt;/dev/null</PostOp>