semi合集-English.pdf - 第1802页

SEMI E42-0704 © SEMI 1995, 2004 71 Figure 10.3 Change Request Recor d State Model 10.3.4.5 Change Request Lifecycle — This section describes the states of a change request . A change requ est is received and examined. It…

100%1 / 7923
SEMI E42-0704 © SEMI 1995, 2004 70
management services, to change a recipe, or to change
the namespace (for example, to store a new recipe or
delete an existing one), from an entity other than an
attached DRNS segment. If the change involves a
specified agent (for example, verify or upload requests),
then the DRNS manager shall delegate the operation to
the DRNS segment provided by that agent. Otherwise,
operations are preferably delegated to a DRNS master
segment.
10.3.4.2 Internal Change Requests — A change
request may be initiated by a specific attached segment.
For example, a local operator may want to change the
generic attribute EditedBy
(illustrated in Figure 10.3) or
to rename a recipe. The DRNS segment then requests its
DRNS manager for approval to make the specific type
of change desired. The DRNS manager, upon receipt of
the request, shall create a change request record
(Section 10.3.4.4) for the recipe(s), specifying the
DRNS segment that initiated the request, the type of
change requested, and noting that the change was
segment-initiated.
10.3.4.3 Allowable Change Requests — A change
request may not be allowable. For example, a change to
a write-protected recipe or a change to introduce a
recipe identifier already in use may be denied
immediately. If the change is allowed, then a change
request record shall be created in non-volatile memory
for each allowed change request.
Any operation that creates or changes a recipe body, a
recipe attribute, or a recipe identifier, requires explicit
manager approval. This includes the following
operations: create, delete, modify (body), copy (new
identifier), rename (new identifier), protect, verify, link,
unlink, certify, de-certify, change read-write generic
attribute, and change read-write agent-specific
attribute.
The following requirements shall apply:
— A request to create a new recipe, or copy an existing
recipe, with a specified identifier shall be granted
only if that identifier is not in use for a write-
protected recipe within the namespace as a whole
(that is, no attached DRNS segment has a write-
protected recipe using that identifier).
— A request from a DRNS segment to rename a recipe
shall be granted only if no other segment has that
recipe and the new identifier is not otherwise in use.
— A request from a dedicated segment to delete a
recipe shall be denied only if the recipe is write-
protected.
10.3.4.4 Change Request Record Definition — A
change request record, as shown in Figure 5.7,
consists of the following information:
— The recipe identifier (RecipeID
),
— a destination recipe identifier (DestRecipeID
) (used
for copy and rename only, and otherwise null),
— the segment specifier, (Segment
), of the DRNS
segment that has requested a change or to which the
change operation is or will be delegated,
— the specific type of change requested (ChangeType),
— a timestamp of when the request was received
(Timestamp
),
— an operation identifier (OperationID
), an integer
delegated by the DRNS manager that uniquely
identifies a given change request within the
distributed recipe namespace at large,
— a boolean (SegmentRequest
) used to differentiate
requests by attached segments from other requests
(the manager responds differently in the two cases).
All of the above information, with the exception of the
segment specifier, shall be determined at the time the
change request record is created. In the case of
externally initiated requests, delegation of a segment
specifier may be postponed until the change request is
selected.
The operation identifier is used to identify a specific
change request by both the namespace and the
delegated DRNS segment. It is passed to the DRNS
segment when granting permission to make the
requested change (Section 10.3.5) and when sending
segment change approval to a DRNS segment (Section
10.1.2.2) for a previous change request made while the
recipe was locked. It shall also be used for recipe
management services defined in Section 12 that use an
operation identifier (parameter RMOpID).
For change requests initiated by an attached segment,
the boolean SegmentRequest
is set to TRUE.
Otherwise, it is FALSE.
The change request record shall be deleted when the
requested change operation has been completed,
whether successfully or unsuccessfully.
SEMI E42-0704 © SEMI 1995, 2004 71
Figure 10.3
Change Request Record State Model
10.3.4.5 Change Request Lifecycle — This section
describes the states of a change request.
A change request is received and examined. It is
determined either to be allowed or not allowed.
If the requested change is allowed, then a change
request record is created for the specified recipe by
saving the information required. The change request is
now INACTIVE and ON HOLD (see Figure 10.1). The
operations identifier is set to a unique unsigned integer.
If the change was initiated externally, a segment may or
may not be designated until the change request is
selected for approval. The remaining information is
filled at this time. The change request record is placed
in a queue for that recipe in non-volatile memory.
The change request remains on hold until the DRNS
manager selects it as the next change and it becomes
selected. If a segment has not already been designated,
then one is determined at this time. The selected recipe
may be discarded after evaluation due to changes in
circumstances since it was originally put on hold.
Otherwise, the change request becomes active, and the
change request record is added to any attached DRNS
recorder. The manager is ready to begin its
negotiations with the designated segment or to approve
a segment-initiated change request already in progress,
at this point.
These stages may occur in rapid succession if the
request is initiated by a segment and the recipe was not
locked.
Selection occurs in one of two ways: either a change
request is received when the specified recipe is
unlocked (Section 10.3.4.5), or else a currently active
change request completes, and a new change request is
selected from the queue of change request records on
hold for that recipe. Rules for selection may vary and
are beyond the scope of RMS. For example, rules could
be sequence-oriented (first-in, first-out), or they might
consider the types of operations specified. For example,
requests for verification might be given precedence
over requests to link.
When a selected change request becomes active, the
manager adds the change request record to any
attached recorder and begins negotiations with the
delegated segment.
If the change request was segment-initiated (Section
10.3.5), the segment change request is approved. The
DRNS manager shall initiate a segment change
approval to the DRNS segment (Section 10.1.2.2).
There are three possible scenarios for the negotiations
with the segment: an externally initiated request, an
internally initiated request from a segment when the
recipe specified was unlocked, and an internally
initiated request from a segment when the recipe
specified was locked. These three types of scenarios are
illustrated in Table 10.5. NOTE: In both of the first two
cases, the segment sends a request to make a change
with RMDChangeRequest.req. However, in the first
case, the initiation of that change request was external,
and the segment's request is its required response to any
change request that it receives.
SEMI E42-0704 © SEMI 1995, 2004 72
Table 10.5 Active Change Request Negotiations
Manager Segment
Externally Initiated Change Request
An externally initiated change request becomes active. The
manager requests the delegated segment to make the change:
RMNAction.req ->
The segment responds that it will make the change and notify
the requestor when done.
<- RMNAction.rsp
The segment requests approval to make the change:
<- RMDChangeRequest.req
The manager approves the request immediately:
RMDChangeRequest.rsp ->
The segment completes the change and notifies its manager:
<- RMDComplete.nfy
The segment notifies the requestor of the change (in this case,
its manager) that the change is complete.
<- RMNComplete.nfy
Segment-Initiated Change Request for Unlocked Recipe
The segment requests approval to make the change:
<- RMDChangeRequest.req
The manager approves the request immediately:
RMDChangeRequest.rsp ->
The segment completes the change and notifies its manager:
<- RMDComplete.nfy
The segment notifies the requestor of the change (in this case,
its manager) that the change is complete.
<- RMNComplete.nfy
The segment notifies the initial requestor of the change that the
change is complete:
RMNComplete.nfy ->
Segment-Initiated Change Request for Locked Recipe
The segment requests approval to make a change:
<- RMDChangeRequest.req
The manager puts the change request on hold:
RMDChangeRequest.rsp ->
The change request later becomes active. The manager now
approves the segment’s earlier request to change generic
attributes:
RMDSApproveAction.req ->
The segment responds that it intends to make the change:
<- RMDSApproveAction.rsp
The segment completes the change and notifies its manager:
<- RMDComplete.nfy
The segment notifies the initial requestor of the change that the
change is complete:
RMNComplete.nfy ->