semi合集-English.pdf - 第1768页

SEMI E42-0704 © SEMI 1995, 2004 37 Figure 5.7 Change Request Recor d 5.8.1 C hange Ma nagement — A change request occurs when ever a user or an attached segment reque sts the distributed re cipe namespace man ager to mak…

100%1 / 7923
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
SEMI E42-0704 © SEMI 1995, 2004 38
Objects that are subtypes of objects introduced in Section 4 inherit the attributes of the supertype objects. These
attributes are not repeated in this section.
5.11.1 Distributed Recipe Namespace Segment Attribute Definition — Table 5.1 defines the attributes required for a
distributed recipe namespace segment, and Table 5.2 defines the attributes of the subtype master segment.
Table 5.1 Distributed Recipe Namespace Segment Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSDSegment”
ObjID The object name (identifier). RO Y Text.
Namespace The name (ObjID) of the namespace to which the
segment belongs. May be set by the manager.
RO Y Text.
NamespaceManager Identifies the distributed recipe namespace manager.
May be set by the manager.
RO Y Text.
RecipeReadOnlyLevel Used to track the corresponding attribute of the
namespace to which the segment belongs. May be set
by the manager.
RO Y Unsigned integer.
Table 5.2 Distributed Recipe Namespace Master Segment Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSDMaster”
ObjID The object name (identifier). RO Y Text.
5.11.2 Distributed Recipe Namespace Recorder Attribute Definition — Table 5.3 defines the attributes required for
a distributed recipe namespace recorder.
Table 5.3 Distributed Recipe Namespace Recorder Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSDRecorder”
ObjID Text. RO Y Text.
LockedRecipes List of identifiers of recipes with existing change
request records.
RO Y List of formatted text.
Namespace Identifies the namespace to which the recorder is
attached. May be set by the manager.
RO Y Text.
NamespaceManager Identifies the distributed recipe namespace manager.
May be set by the manager.
RO Y Text.
Segments List of specifiers of currently attached segments. RO Y List of formatted text.
5.11.3 Distributed Recipe Namespace Attribute Definition — Table 5.4 defines the attributes required for a
distributed recipe namespace.
Table 5.4 Distributed Recipe Namespace Attribute Definition
Attribute Name Description Access Rqmt Form
ObjType The object type. RO Y Text = “RNSD”
ObjID Text. RO Y Text.
LockedRecipes A list of identifiers of all recipes with existing change
request records.
RO Y List of formatted text.
Recorder The recorder specifier of the attached distributed
recipe namespace recorder.
RO Y Text.
Segments A list of specifiers of the distributed namespace
segments attached to the namespace.
RO Y List of formatted text.