semi合集-English.pdf - 第1767页
SEMI E42-0704 © SEMI 1995, 2004 36 the DRNS manager , is damaged a nd its information becomes lost o r unavailabl e. The DRNS recorder is also used to store the current change request per recipe , to delete a change re q…
SEMI E42-0704 © SEMI 1995, 2004 35
distributed recipe namespace manager be capable of
supporting at least one attached master segment.
Additional master segments may be desirable for
further backup protection.
The term dedicated segment is used to refer to
segments that are not master segments. Dedicated
segments store at most one agent-specific dataset per
recipe. Because a DRNS segment provided by
equipment would not expect to keep agent-specific
datasets for other equipment, equipment normally does
not provide master segment capability.
Master and dedicated segments have the same
attributes and support the same message services, but
they respond differently to agent-specific datasets and
are used for different purposes. A master segment
requires approval prior to changing an agent-specific
dataset.
5.4.2 Change Restrictions — The DRNS segment may
provide access to recipes within its storage to the other
components of the agent providing the storage.
However, neither the generic attributes nor the body of
recipes stored by the segment shall be changed except
with the explicit approval of the distributed recipe
namespace manager.
Dedicated DRNS segments that are attached to a DRNS
manager may change the contents of an agent-specific
dataset without first asking permission. However, they
are required to notify the manager of any change as
soon as it occurs.
The attribute RecipeReadOnlyLevel
is set by the DRNS
manager to the value of the corresponding namespace
RecipeReadOnlyLevel
attribute when the segment is
first attached and whenever the namespace attribute is
changed. This attribute has the same function as the
namespace attribute and allows the segment to prohibit
changes based on a recipe's approval level as defined in
Section 8.2.5. For example, the segment shall deny
requests to modify a write-protected recipe.
The DRNS segment is prohibited from changing its
contents whenever it is unattached. However, recipes
and recipe attributes may be read at any time by other
entities, including other components of the owner
agent.
Any changes to a logical recipe stored by the DRNS
segment shall first be approved by the DRNS manager
before
the change is made. This includes any changes to
the body or to any generic attribute. This is required for
two reasons. First, two different DRNS segments may
attempt to change a recipe at the same time, and this
activity must be coordinated. Second, to protect the
integrity of the recipe identifier where multiple
instances of a recipe exist, the distributed recipe
namespace is required to ensure that all such instances
have been updated appropriately with that change
before other changes to the same recipe are allowed.
NOTE: The prohibition against unauthorized change
does not preclude the saving of such changes external
to the DRNS segment while waiting for authorization.
However, changes made by other DRNS segments,
subsequent to such changes and prior to authorization,
may invalidate these changes.
Communications between the different components of
an agent that do not require or use the formal services
defined by RMS are considered as proprietary to the
agent and are neither covered nor excluded by RMS,
subject to the above restrictions against change.
Figure 5.4
Distributed Recipe Namespace Recorder
5.5 Distributed Recipe Namespace Recorder — The
distributed recipe namespace recorder provides a
method of externally storing and retrieving information
critical to automated rebuilding of a damaged
distributed recipe namespace. It contains two types of
information: a list of the DRNS segments that are
attached to the DRNS manager and the current change
request record in process per recipe.
A DRNS recorder may be attached and detached from a
DRNS manager, and reattached to that manager.
Information that it contains is available to anyone but
may only be changed by its manager.
The DRNS recorder is able to store the DRNS segment
specifiers (the object specifiers) of the attached DRNS
segments in its Segments
attribute. This information
allows a distributed recipe namespace to be
automatically rebuilt in the event that the namespace, or
SEMI E42-0704 © SEMI 1995, 2004 36
the DRNS manager, is damaged and its information
becomes lost or unavailable.
The DRNS recorder is also used to store the current
change request per recipe, to delete a change request,
and to return the set of change requests for one or more
recipes. The attribute LockedRecipes
provides a list of
identifiers for recipes with change requests.
The DRNS manager shall use the services of a DRNS
recorder when one is attached to the namespace by a
service user. However, use (attachment) of a recorder is
optional for the user. The DRNS recorder is provided
for remote storage of critical information and is not
intended as a general source of information for the user.
It is not able to provide inactive change request
information.
Figure 5.5
Distributed Recipe Namespace
5.6 Distributed Recipe Namespace Management
Information — The DRNS management information
object is private and proprietary to the DRNS manager.
It is included in Figure 5.2 as an emphasis on the
importance of the information that a DRNS manager
requires for management. This includes, but is not
limited to, the recipe identifiers stored in each attached
segment and all existing change request records.
The DRNS manager is required to know the contents of
all of its attached segments at all times. It shall be able
to uniquely identify each instance of a recipe within the
distributed recipe namespace. It is responsible for
tracking the current status of each instance of a logical
recipe within the distributed recipe namespace when a
change to a recipe within one segment is being updated
to other segments. The DRNS management information
is important for these purposes.
5.7 Distributed Recipe Namespace — The distributed
recipe namespace has three additional attributes, as
shown in Figure 5.5, that are read-only, set by the
DRNS manager. The attribute Segments
contains a list
of the object specifiers of the DRNS segments currently
attached. The attribute Recorder
contains the object
specifier of an assigned DRNS recorder. The attribute
LockedRecipes
contains a list of recipe identifiers of
recipes with existing change request records.
5.8 Distributed Recipe Namespace Manager — The
distributed recipe namespace manager (Figure 5.6) is
responsible for ensuring that the distributed recipe
namespace and DRNS segments operate together and
for maintaining namespace integrity as a whole. It is
required to know the identities of its attached DRNS
recorder and DRNS segments and the contents (recipe
identifiers) of each attached DRNS segment at all times.
Figure 5.6
Distributed Recipe Namespace Manager
The current attachments of the DRNS manager are
maintained in the DRNS namespace attributes Recorder
and Segments
and through the services of the DRNS
recorder described in Section 5.5. Whenever a DRNS
segment is attached, the DRNS manager shall add the
segment specifier to the namespace attribute Segments
and to the current list maintained by the DRNS
recorder. Whenever a DRNS segment is detached, the
DRNS manager shall remove its specifier from the
Segments
attribute and from the DRNS recorder's list.
The DRNS manager is able to know which recipes are
stored in each DRNS segment through use of Object
Services provided for or by the individual DRNS
segments. It shall maintain the integrity of the
namespace through ensuring that an identifier of any
recipe stored within the namespace represents exactly
one logical recipe. This is achievable because the
manager must give explicit approval of any change of
logical recipes (generic attributes or body) stored by the
DRNS segments.
SEMI E42-0704 © SEMI 1995, 2004 37
Figure 5.7
Change Request Record
5.8.1 Change Management — A change request occurs
whenever a user or an attached segment requests the
distributed recipe namespace manager to make, or
permit, a specific type of change. A change request
record (Figure 5.7) contains information about who
requested what type of change. This allows later
diagnostics when necessary.
A change request record is created for a recipe
whenever an attached DRNS segment requests a change
and is deleted when the requested change has been
completed or discarded. A change request is either
inactive or active. Once a change request is made, it is
considered as inactive until the change has been
approved by the DRNS manager. Once approved, it is
considered as active.
The change request record is not a standardized object
and is not accessed directly through public services.
However, the information represented by the change
request record shall be available, upon request, from
the DRNS manager for all inactive and active change
requests. For this reason, it is convenient to model the
change request record as an object.
A recipe for which a change request exists is called
locked. Otherwise, it is unlocked.
The DRNS manager is responsible for ensuring that
only one change request per recipe is active at any
time. The results of each approved change request shall
be updated appropriately to each of the other DRNS
segments with a copy of the same logical recipe before
a subsequent change to the recipe is approved.
5.9 Building a Distributed Recipe Namespace — A
distributed recipe namespace is built up in several
stages. The distributed recipe namespace and its
associated DRNS manager are created separately in the
first stage. The individual DRNS segments are first
created and then attached to the DRNS manager. At
least one DRNS segment must be attached to the DRNS
manager before it can accept recipes, as the distributed
recipe namespace has no other means of storage. Figure
5.8 illustrates the attachment relationship.
Figure 5.8
The Attachment Relationship
The attached DRNS segments may later be detached
from the namespace and then either attached again to
the same namespace or to a different namespace
without affecting the recipes stored within the DRNS
segment.
NOTE: When a DRNS segment with existing recipes is
detached and then attached to a different namespace, its
recipe identifiers fall within the domain of the new
namespace. This may require some recipes to be
renamed before the attach process is complete.
5.10 Rebuilding a Damaged Distributed Recipe
Namespace — A distributed recipe namespace, or its
manager, may become damaged or unavailable. If a
DRNS recorder was attached to the damaged name-
space, then rebuilding the namespace can be automated.
A new distributed recipe namespace and new DRNS
manager are created, assigning the old namespace
name as the object identifier ObjID
for the new
namespace. The new DRNS manager should be
assigned a different identifier, however, as a security
measure. The user may then request the new DRNS
manager to rebuild the namespace with the old DRNS
recorder. A namespace may also be rebuilt without a
recorder if the list of segment specifiers can be
provided by the user. However, the user is not expected
to provide the information retained through change
request records.
5.11 Object Attribute Definition Tables — This section
contains the formal attribute definitions for the
distributed recipe namespace capability. Except for the
object identifier attributes, attributes are listed
alphabetically.
DRNS
Manager
DRNS
Segment
DRNS
Recorder
is attached to
is attached to