Create autonomic computing policies using Simplified Policy Language

Streamline policy creation with Policy Management for Autonomic Computing

Simplified Policy Language (SPL) is a syntax for developing autonomic computing policies that can be understood by humans. Policy authoring without proper tools can be difficult because it requires a thorough knowledge of Extensible Markup Language (XML). SPL comes to the rescue by providing an easy syntax for creating policies. Streamline and simplify your policy creation with the Policy Management tool PMAC, which is downloadable from alphaWorks, so that you can experiment with creating policies. Administrators responsible for creating and maintaining the policies for an organization will benefit the most from this tutorial.

Sampath Chilukuri (sampath.kumar@in.ibm.com), Staff Software Engineer, IBM

Sampath ChilukuriSampath K Chilukuri is a Staff Software Engineer at IBM focusing on the Log and Trace Analyzer for Autonomic Computing. He has more than three years of experience in the development of applications that gather information from the log files generated by various products. He holds a bachelor's degree in Electronics and Communication Engineering from JNTU, Hyderabad, India. He can be reached at sampath.kumar@in.ibm.com



14 February 2006

Before you start

About this tutorial

Policies help administrators simplify the management of IT systems. This tutorial is for developers and administrators who are responsible for creating, customizing, implementing, and monitoring policies for their business units. You'll learn how to use Simplified Policy Language (SPL), an easy syntax for creating policies.

Previously, you needed a thorough understanding of the policy XML schema to author error-free policies. As an alternative, a user-friendly, human-understandable syntax is available with the Policy Management tool PMAC, which is a system for authoring policies in a policy language. The SPL syntax contains specific constructs, keywords, special characters, and symbols to represent various sections of the policy. PMAC (and the accompanying SPL syntax) are downloadable tools from alphaWorks, provided as trial code for you to experiment with.

For this tutorial, you should have an understanding of policies.

Prerequisites

  • You must download and install PMAC.
  • A basic knowledge of Java™ programming is required to understand the examples of working with policy templates.
  • All the commands and explanations in this tutorial assume you are using the Windows™ operating system environment.

Overview

Introduction to Simplified Policy Language

Policies for autonomic computing can be created in many ways. You can develop policies using XML, but a thorough knowledge of XML and the policy schema are required. Without that, manually authoring policies can become very difficult and error prone. PMAC understands a more human readable syntax for developing policies, called SPL, which greatly simplifies the creation, modification, and deployment of policies. You can also develop policies using policy editors or the ACPolicy API described in the tutorial "Using the ACPolicy API" (see Resources).

The Autonomic Computing Policy Language (ACPL) defines an XML grammar for policies, which contains the various sections and attributes of a policy. SPL syntax contains constructs and keywords to describe these sections in a simplified way. You can create a policy template file, in SPL syntax, by using any of your favorite editors. PMAC converts this manually-created SPL file into policy XML syntax when it is saved. The command line interface of Policy Editor Storage (PES), the storage component of PMAC, is used to save and deploy the policy after it is converted to XML syntax.

Retrieving the ACPL

During the conversion of SPL syntax to ACPL syntax, the syntax is verified and then added to storage. You can also retrieve the ACPL equivalent of the policy written in SPL from storage using the command-line interface of PES.

Before running any of the commands mentioned in this tutorial, make sure the PMAC environment is set by executing the acpmenv.bat file on Windows or acpmrc on Linux®, which is in the PMAC installation folder. This will add the necessary settings to PATH and sets CLASSPATH. More information on installing and setting up the environment is in the QuickStart section of the PMAC readme document, or section 3 of the tutorial "Using the ACPolicy API."

The command to retrieve the policy and store to a file is:

java -DPMAC_USE_JLOG=true -cp %PMAC_CLASSPATH% com.ibm.autonomic.policy.pss.pmac_policy
-get file=<policy-file> -filter scope=<policy-scope>

You convert a given SPL file to an ACPL file without adding it to PMAC storage using the following command.

java -DPMAC_USE_JLOG=true -cp %PMAC_CLASSPATH% com.ibm.autonomic.policy.pss.pmac_template
-put file=<spl-filename> toacplfile=<acpl-filename>

SPL syntax

SPL sections

The policy template file is a flat text file, created using any of your favorite editors, which contains sections with specific constructs, keywords, and special characters that are part of SPL syntax. The file is divided into multiple sections, each having a general syntax of a keyword followed by an opening curly brace ( { ) and closing curly brace ( } ), with the data specific to the section in between. Listing 1 shows an example.

Listing 1. Syntax of SPL section
<keyword> {
<data specific to the section>
}

The sections, data in the sections, and subsections in the file can appear in any order. The keywords are not case-sensitive; for example, Condition and condition mean the same for SPL. The spaces and blank lines in the file are ignored. The policy template file must use UTF-8 or ASCII encoding for PMAC to convert the file to ACPL successfully.

Lines starting with the pound symbol (#) are treated as comments and ignored by the SPL conversion service.

Sample policy

I'll use an example to show how to use SPL and how it works with PMAC. In a hypothetical organization with multiple business units, the number of paid leaves (vacation days) an employee is eligible for depends on their business unit. An employee working in UnitX is eligible for 20 days a year, but in UnitY it is 21 days per year.

I'll create a single policy template file in SPL that can hold substitution variables for the business unit, as well as the number of eligible leaves. The policy decision to the requesting application would be a message indicating that the employee can apply for leaves based on the available leaves as input to the policy condition. Upon deploying the policy template file to PMAC, the actual values for the business unit and the eligible leaves will be substituted. I'll assume the organization has only two business units, so two policies are deployed for PMAC to act upon, one with the condition of business unit UnitX and the other UnitY.

Policy templates

As explained in SPL sections, only a single flat file is created in SPL, but two policies will be derived from it. This is possible with the help of substitution variables, which are part of SPL syntax. Because the SPL file acts as a base for further policies, it is called a policy template file or simply a template file. The substitution variables will be business unit and eligible leaves in my example. Before looking at the complete SPL file, let's review the individual sections of the SPL and the corresponding ACPL fragments that they generate.

Template section

The top most section of the file is the template section, which holds three subsections that make up the policy template. Multiple template sections are allowed in a file, so more than one template can be written in a single file and saved to PMAC storage. Listing 2 shows the general syntax of the template section. Remember, SPL is not case sensitive.

Listing 2. Syntax of template section
Template {
     Header {
          <template information>
     }
     Policy {
          <policy information>
     }
     Variable {
          <substitution variable information>
     }
}

Header subsection

Header is a subsection of the template section. The syntax for the Header section is shown in Listing 3.

Listing 3. Syntax of Header section
Header {
     Name = <template name as string>
     Version = <template version as string>
     Description {
          <template description as string>
     }
     NlsDescription {
     BundleName = <resource bundle name that is to be translated>
     BundleKey = <key for the resource bundle>
     MessageInsert {
          Name = <message insert name as string>
          Value = <message insert value as string>
     }
}

The Header excerpt from the sample template file is in Listing 4. Only one Header section is allowed per template section. The Header section contains the Name, Version, and Description specific to the policy template.

Listing 4. Header section of sample policy template
Header {
    Name=PaidLeaves
    Version=1.2
    Description {
      This template is used to create policies for business unit where the number 
	  of eligible leaves differs based on business unit.
    }
  }

NlsDescription is an optional section used for specifying messages for translation to a local language. Multiple MessageInsert constructs are allowed for a single NlsDescription. The equivalent ACPL for the combination of header section and template section is shown in Listing 5. Various XML namespaces are added to the template tag as part of the SPL conversion.

Listing 5. ACPL for Header section
<t:Template templateName="PaidLeaves" version="1.2" 
xmlns:acpl="http://www.ibm.com/namespaces/autonomic/policy/language/1.2" 
xmlns:exp="http://www.ibm.com/namespaces/autonomic/policy/expressions/1.2" 
xmlns:nls="http://www.ibm.com/namespaces/autonomic/policy/nlscaption/1.2" 
xmlns:nodescope="http://www.ibm.com/namespaces/autonomic/policy/hierarchical/1.2" 
xmlns:t="http://www.ibm.com/namespaces/autonomic/policy/template/1.0" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">

     tags generated due to other SPL constructs

<acpl:Description>This template is used to create policies for business 
unit where the number of eligible leaves differs based on business 
   unit.</acpl:Description>
</t:Template>

Policy subsection

The Policy subsection contains more subsections that hold information specific to the policy. The general syntax for the Policy section is shown in Listing 6. The four tuple of autonomic computing policy -- scope, condition, business value, and decision -- are generated by this section. For more on the Policy and its attributes, see An Introduction to Policy for Autonomic Computing (found in Resources).

You use the Header subsection of the Policy section to specify the policy name and decision name (unlike that of the template section). BusinessValue is an optional subsection that specifies an integer value for the business value of the policy. The Scope subsection contains required Name attributes to specify the scope for the policy. Other optional attributes of Scope are Span, Precedence, Path, and SimpleGroup.

The optional TimePeriod section is to specify the time period for the policy to be active after it is deployed to PMAC. Multiple TimePeriod sections are allowed, so the final active period for the policy will be the union of the specified times. The default behavior is always active if the TimePeriod section is not specified.

For more on the condition expressions, functions that can be used in conditions, and keywords to specify time periods, see the tutorial Autonomic Computing Expression Language (found in Resources).

Listing 6. Syntax of Policy section
Policy {
     Header {
          Name = <policy name as string>
          Version = <policy version as string>
          DecisionName = <decision name for the policy as string>
     }
     BusinessValue {
          Value = <business value as integer>
     }
     Scope {
          Name = <scope as string>
          Span = <applicability of the path as string>
          Precedence = <string indicating which span is more relevant>
          Path = <base node path as string>
          SimpleGroup = <policy group to which this policy belongs to, as string>
     }
     Description {
          <description for the policy>
     }
     NlsDescription {
          <nlsdescription constructs, see nlsdescription section of header section>
     }
     Condition {
          <policy condition>
     }
     Decision {
          <policy decision>
     }
     TimePeriod {
          Keyword1=value
          Keyword2=value
               .
               .
          KeywordN=value
     }
}

The Policy section from the sample policy template is shown in Listing 7. The Scope given for the policy is remainingLeaves, and the BusinessValue Value is set to 6. The policy Name is PaidLeaves and DecisionName is CheckRemainingLeaves.

Listing 7. Policy section of sample policy template
Policy {
    Header {
      Name=PaidLeaves
      Version=1.2
      DecisionName=CheckRemainingLeaves
    }
    BusinessValue {
      Value=6
    }
    Scope {
      Name=remainingLeaves
    }
    Description {
      This policy is used to determine the number of remaining leaves an employee 
      can avail based on the business unit.
    }
    Condition {
      businessUnit == varBusinessUnit && leavesAvailed < varEligibleLeaves
    }
    Decision {
      Result = "Employee can avail leaves"
    }
  }

The policy works like the If-Then construct of any programming language. The content of the Condition section is used as the expressions for the If construct, and the content of the Decision section for the Then clause. The condition for the sample policy is:

(businessUnit == varBusinessUnit && leavesAvailed < varEligibleLeaves)

During the saving of the policy template to the PMAC storage, the varBusinessUnit and varEligibleLeaves variables are replaced with the actual values of the policy.

If the Condition section is missing from the policy template, then the policy evaluates to always true and no ACPL tags are generated in the resulting policy XML. The equivalent ACPL for the Policy section is shown in Listing 8.

The Decision section is used to return the policy results. Only result-based policies can be developed using SPL.

Like ACPL for the template section, the required namespaces for the Policy tag of the Policy section are also added during the SPL conversion to ACPL.

Listing 8. ACPL for Policy section
<acpl:Policy decisionName="CheckRemainingLeaves" policyEnabled="true" 
policyName="PaidLeaves" templateName="PaidLeaves" templateVersion="1.2" version="1.2" 
xmlns:acpl="http://www.ibm.com/namespaces/autonomic/policy/language/1.2" 
xmlns:exp="http://www.ibm.com/namespaces/autonomic/policy/expressions/1.2" 
xmlns:nls="http://www.ibm.com/namespaces/autonomic/policy/nlscaption/1.2" 
xmlns:nodescope="http://www.ibm.com/namespaces/autonomic/policy/hierarchical/1.2" 
xmlns:pmacext="http://www.ibm.com/namespaces/autonomic/policy/pmacextensions/1.2" 
xmlns:t="http://www.ibm.com/namespaces/autonomic/policy/template/1.0" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <acpl:Description> This policy is used to determine the number of remaining 
 leaves an employee can avail based on the business unit.</acpl:Description>
 <acpl:Condition>

    <exp:And>
        <exp:Equal>
            <exp:PropertySensor propertyName="businessUnit"/>
            <exp:StringConstant referenceId="varBusinessUnit">
                <Value>"UnitX"</Value>
            </exp:StringConstant>
        </exp:Equal>
        <exp:Less>
            <exp:PropertySensor propertyName="leavesAvailed"/>
            <exp:IntConstant referenceId="varEligibleLeaves">
                <Value>20</Value>
            </exp:IntConstant>
        </exp:Less>
    </exp:And>

 </acpl:Condition>
 <acpl:Decision>
 <acpl:Result>
 <acpl:Property propertyName="Result">
 <exp:StringConstant>
 <Value>Employee can avail leaves</Value> 
 </exp:StringConstant>
 </acpl:Property>
 </acpl:Result>
 </acpl:Decision>
 <acpl:BusinessValue>
 <Importance>6</Importance> 
 </acpl:BusinessValue>
 <acpl:Scope>
 <acpl:StringScope>
 <Value>remainingLeaves</Value> 
 </acpl:StringScope>
 </acpl:Scope>
 </acpl:Policy>

Variable section

The Variable section, an optional subsection of the Template section, specifies the substitution variables for the policy template. There can be as many variable sections defined as the variables used in the policy condition or decision. The SPL conversion will generate a warning message if a variable is defined but not used. Whenever a policy is generated from the policy template file containing the substitution variables, the substitution variables are replaced with the actual data for the policy to use.

If a variable is present in the condition or decision clause and not defined in the Variable section, then it is considered a property sensor. A property sensor is the value required by the policy and is considered as input to the policy during the evaluation by PMAC. The structure of the Variable section is shown in Listing 9. It includes the Name, Type, Default, Label, NlsDescription, and Constraints subsections.

Listing 9. Syntax of Variable section
Variable {
     Name = <substitution variable name as string>
     Type = <data type of the substitution variable as string>
     Default = <default value of the substitution variable as string>
     Label {
          <description of the substitution variable>
     }
    NlsDescription {
          <nlsdescription constructs, see nlsdescription section of header section>
     }
     Constraints {
          Restriction = value1, value2 ... valueN
     }
}
  • Name: specifies the name for the substitution variable that is used in the condition or decision subsections of Policy.
  • Type: specifies the data type of the variable. For example, the value for Type could be Integer, String, and so on.
  • Default: specifies the default value for the substitution variable
  • Constraints: use this to restrict the values assigned to the substitution variable. The list of values allowed are comma-separated, and are assigned to the Restriction attribute of the Constraints subsection.

The two variable sections for business unit and eligible leaves that are defined in the sample policy template are shown in Listing 10.

Listing 10. Variable sections from sample policy template
Variable
{
    Name=varBusinessUnit
    Type=string
    Default="UnitX"
    Label {
      Variable used for business unit
    }
  }
Variable
{
    Name=varEligibleLeaves
    Type=integer
    Default=20
    Label {
      Variable used for eligible paid leaves
    }
  }

You can use the varBusinessUnit substitution variable to specify the business unit name for the policy during the conversion to ACPL. Similarly, varEligibleLeaves is used to specify the integer value for the eligible leaves available for the employee working in the corresponding business unit. The resulting ACPL of the policy for business unit UnitX with eligible leaves of 20 is shown in Listing 11.

Listing 11. ACPL for template variables section
<TemplateVariables>
    <TemplateVariable name="varBusinessUnit">
        <Location>/t:Template/acpl:Policy/acpl:Condition/exp:And/exp:Equal/
           exp:StringConstant/Value</Location>
        <acpl:Description>      Variable used for business unit</acpl:Description>
    </TemplateVariable>
    <TemplateVariable name="varEligibleLeaves">
        <Location>/t:Template/acpl:Policy/acpl:Condition/exp:And/exp:Less/
           exp:IntConstant/Value</Location>
        <acpl:Description>  Variable used for eligible paid leaves</acpl:Description>
    </TemplateVariable>
</TemplateVariables>

Complete sample policy template

Listing 12 shows the complete policy template file.

Listing 12. Policy template file
Template {

Header {
     Name = PaidLeaves
     Version = 1.2
     Description {
          This template is used to create policies for business unit where the  
          number of eligible leaves differs based on business unit.
     }
}
#end of header section

Policy {
    Header {
      Name=PaidLeaves
      Version=1.2
      DecisionName=CheckRemainingLeaves
    }
    BusinessValue {
      Value=6
    }
    Scope {
      Name=remainingLeaves
    }
    Description {
          This policy is used to determine the number of remaining leaves an 
          employee can avail based on the business unit.
    }
    Condition {
	businessUnit == varBusinessUnit && leavesAvailed < varEligibleLeaves
    }
    Decision {
      Result = "Employee can avail leaves"
    }
  }
#end of policy section
  
Variable
{
    Name=varBusinessUnit
    Type=string
    Default="UnitX"
    Label {
      Variable used for business unit
    }
  }
Variable
{
    Name=varEligibleLeaves
    Type=integer
    Default=20
    Label {
      Variable used for eligible paid leaves
    }
  }
  #end of template section
}

Generating policies from the policy template

This section has step-by-step instructions for generating policies from the policy template.

  1. Add the template to PMAC.

    Before the policies can be generated using the policy template file, you need to add the policy template file to PMAC so it is checked for syntax and an equivalent ACPL is generated. Use the following command to put the policy template file.

    java -DPMAC_USE_JLOG=true -cp %PMAC_CLASSPATH% 
    com.ibm.autonomic.policy.pss.pmac_template -put 
    file=sample_policytemplate.txt
  2. Add and deploy policies based on the template.

    You need to understand the relevant parts of the Java code that are required for adding and deploying policies to PMAC, based on the sample policy template file.

  3. Get Template Manager Service.

    To retrieve the ACPL of the template file, create an object of TemplateManagerService with the following statement.

    templateManagerService = PolicyStorage.createTemplateManagerService();

    templateManagerService is an object of the class TemplateManagerService returned by the call to the static method createTemplateManagerService of PolicyStorage class.

  4. Create Template handles.

    Now you'll create the template information object that's used to create a handle for the template. The handle created is used to search and retrieve the matching templates. Because only one template is added, the code here creates the template handles array of size one. The getTemplateHandle method of TemplateInfo creates the handle object that can be used for the search and retrieve. The code to create handle is shown below.

    TemplateInfo templateInfo = new TemplateInfo("remainingLeaves", 
       "PaidLeaves", "1.2");
    templateHandles = new TemplateHandle[1];
    templateHandles[0] = templateInfo.getTemplateHandle();
  5. Get the template string.

    The template handle array is then passed to the getTemplates method of the TemplateManagerService object to get the ACPL template string. The function call is through the following code.

    templateString = tms.getTemplates(templateHandles);
  6. Create the ACTemplate object.

    To work with the template (to generate policies), create the ACTemplate object by calling:

    ACTemplate acTemplate = new ACTemplate(templateString[0]);

    I will use this acTemplate object to set the actual data for substitution variables and create policies.

  7. Get substitution variables information.

    Using the functions available in the acTemplate object, I'll now set the values for substitution variables. You can retrieve the list of substitution variables defined in a template file from the getSubstitutionVariables method of the ACTemplate object. I then have an array of strings that contain the names of substitution variables defined in the template.

    The data type of the variable can be retrieved by the getType method of ACTemplate by passing the name of the variable as a parameter. Similarly, the current value of the variable, if it is already set (and could be a default value too), can be retrieved using the getCurrentValue method. The corresponding function calls are shown below. The getType and getCurrentValue are given only to show that they exist; these are not needed for this tutorial.

    String [] svs = acTemplate.getSubstitutionVariables();
    String type = acTemplate.getType(svs[0]);
    String cval = acTemplate.getCurrentValue(svs[0]);
  8. Set data for the substitution variable.

    The actual values for the substitution variables can be set using the setItemValue method of the ACTemplate object. The setItemValue method takes the variable name and value as its parameters.

    acTemplate.setItemValue(svs[0], "UnitX");
    acTemplate.setItemValue(svs[1], 20);

    I assume here that the first variable returned is for the business unit and the second one is for eligible leaves. Alternatively, you can use the following code, hard-coding the names of the variables.

    acTemplate.setItemValue("varBusinessUnit", "UnitX");
    acTemplate.setItemValue("varEligibleLeaves", 20);
  9. Generate the policy.

    The policy string, after replacing the substitution variables with its data, is retrieved from the ACTemplate object by calling:

    String acPolicystring = acTemplate.generatePolicy();
  10. Create the ACPolicy object.

    Now, create the ACPolicy object from the policy string, passing it to the constructor as shown in the call:

    ACPolicy acPolicy = new ACPolicy(acPolicyString);
    WSPolicy wsPolicy = new WSPolicy(acPolicy);
    String wsPolicyString = wsPolicy.toString();

    I also wrap the policy in WSPolicy so that it can be used to create the policy information object.

  11. Create PolicyAndInfo.

    I need to create the object PolicyAndInfo so that it can be used to add and deploy the policy to PMAC with complete information. The code to create PolicyAndInfo is shown below. As mentioned earlier, remainingLeaves is the scope, PaidLeaves is the policy name, and 1.2 is the policy version.

    PolicyAndInfo[] policyAndInfo = new PolicyAndInfo[1];
    PolicyHandle[] deployPoliciesHandles = new PolicyHandle[1];
    
    policyAndInfo[0] = new PolicyAndInfo(wsPolicyString, new 
       PolicyInfo("remainingLeaves", "PaidLeaves", "1.2"));
    deployPoliciesHandles[0] = policyAndInfo[0].getPolicyHandle();
  12. Add and deploy policies.

    After I have the policyAndInfo object holding the policy information, and the handle to the policies as deployPoliciesHandles, I can now add them to the PMAC storage using the addPolicies method of the policy editor storage object. The object of policy editor storage is created using the following call.

    PolicyManagerService pes = PolicyStorage.createPolicyManagerService();

    Add the policies to storage without deploying using the call:

    pes.addPolicies(policyAndInfo);

    Deploy the policies using the call:

    pes.deployUndeployPolicies(deployPoliciesHandles, null);

    After executing the code once, the policy will be added and deployed for evaluation by PMAC only for the business unit UnitX. You will need to change the business unit name to UnitY in the code to add the policy with relevant details for business unit UnitY, and execute the code.

Alternatively, you can include the logic to deploy policies for UnitX and UnitY by creating different ACPolicy objects with different values for substitution variables. This way, you have multiple policies deployed that are all generated from a single template containing substitution variables. The complete application for deploying policies for both units is in the source included for download with this tutorial.


Receive policy guidance

This section explains how to get guidance from the deployed policies. Use the following command to get information for an employee working in UnitX with 10 available leaves.

java -DPMAC_USE_JLOG=true -cp 
%PMAC_CLASSPATH% com.ibm.autonomic.policy.dp.cldp 
-scope remainingLeaves -dname CheckRemainingLeaves 
-string businessUnit="UnitX" -int leavesAvailed=10

You can also get guidance from PMAC using the decision point API. For more information about using decision point API, refer to the tutorial "Use Policy Management for Autonomic Computing" (see Resources).


Summary

In conclusion

This tutorial showed how to create autonomic policies using a syntax, Simplified Policy Language (SPL), which can be understood by humans. You learned how you can streamline your process by creating policy template files in SPL and generating the policy XML files pertaining to ACPL grammar. The tutorial explained the code that retrieves the templates from PMAC storage, sets the values for the substitution variables, and generates policies for use with PMAC. You can download the complete source for the examples shown in this tutorial for more exploration.


Download

DescriptionNameSize
Sample policy template and deployment codeac-splsource.zip4KB

Resources

Learn

  • "Using the ACPolicy API" (developerWorks, June 2005): Take this tutorial to learn details on how to create and use policies programmatically.
  • "Autonomic Computing Expression Language" (developerWorks, 2005): This tutorial is for an intermediate-level software developer who wants to acquire knowledge of how to embed ACEL expressions in XML files and use them for various applications such as business rules and policy management.
  • "Use Policy Management for Autonomic Computing" (developerWorks, January 2006): Take this tutorial for more information about using decision point API.
  • "An Introduction to Policy for Autonomic Computing" (developerWorks, March 2005): This article introduces the concept of policy-based management, talks briefly about key standards, and discusses how policies can be structured.

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Tivoli (service management), Tivoli
ArticleID=103798
ArticleTitle=Create autonomic computing policies using Simplified Policy Language
publish-date=02142006