Browse Prior Art Database

USE OF RUNMODES IN GOAL DRIVEN AUTOMATION ENVIRONMENTS

IP.com Disclosure Number: IPCOM000215266D
Publication Date: 2012-Feb-23
Document File: 5 page(s) / 62K

Publishing Venue

The IP.com Prior Art Database

Abstract

Method and system for implementing runmodes in goal driven automation environments by means of a parameterized STOP request

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 5

USE OF RUNMODES IN GOAL DRIVEN AUTOMATION ENVIRONMENTS

Disclosed is a method and system for implementing runmodes in goal driven automation environments, in particular by using a parameterized STOP request.

Background

Automation environments manage the availability of resources (e.g. applications or

jobs) on one or more computers eventually organized in a computer cluster. Goal driven automation environments operate with a policy defining the managed resources and their relationships. The goal, which is the desired availability of resources, is controlled by START and/or STOP requests injected into the system. There can exist multiple START and/or STOP request for a single resource at the same time. The system has an algorithm to determine the "winning" request, typically by looking at request priorities.

A runmode (compare to runlevel in Unix) is a certain state a system can be in. Resources can be defined to qualify for certain runmodes or not. Bringing a system in a runmode means to make all those resources available that qualify for that runmode and to make all other resources unavailable.

Problem

In a goal driven automation environment resource availability is controlled by START/STOP requests. If runmodes were implemented by other means there could arise conflicts. For example a resource should be active because of a START request but inactive because it is not qualified for the current runmode. Implementing runmodes by means of START/STOP request would help. But on the surface it looks there must be one request per resource. This could be a mass problem because typically there are ten thousands of resources in a policy.

Detailed Description

The inventive function components which are newly added to the prior art automation environment are

a policy set up in a special way (Fig 1)


a parameterized STOP request (Fig 2)


a changed algorithm to calculate the winning request on each resource (Fig 3)

Fig 1 shows how the policy for a single system is enhanced:

1


Page 02 of 5

It contains a resource representing a single system (Sys1) that carries a list of so-called runtokens for each valid runmode (M1,M2,...). It further contains resources running on that system (ResA-ResF) each of which having a RunsOn relationship (red arrows) to Sys1. ResA-ResF have an attribute listing runtokens (the blue T1A, T1B, ...). ResA-ResF will probably have other relationships among each other (the gray arrows). In an embodiment of this example the RunsOn relationships can be generated under the cover by the automation environment.

Fig. 2 shows the STOP request against Sys1 that carries the desired runmode as a parameter:

2


Page 03 of 5

The automation environment takes care that the STOP request is propagated along the RunsOn relationships (against the...