semi合集-English.pdf - 第1804页

SEMI E42-0704 © SEMI 1995, 2004 73 10.3.4.6 Change Request Completion — T he DRNS manager is informed of the completion o f an approved change either immed iately or through a later notification using the RMDComplete ser…

100%1 / 7923
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 ->
SEMI E42-0704 © SEMI 1995, 2004 73
10.3.4.6 Change Request Completion — The DRNS
manager is informed of the completion of an approved
change either immediately or through a later
notification using the RMDComplete service.
There are two circumstances when a DRNS segment
notifies its manager that it has completed an approved
change, illustrated by Figures 10.1 and 10.2 (b) for the
services RMDSegChange and RMDSApproveAction
respectively.
Figure 10.2 (a) illustrates the case where the manager
approves an earlier change request and the segment
makes the change before responding. In this case,
RMDComplete is not sent. However, if the segment
responds before actually making the change, then it is
required to send the notification RMDComplete when
done.
When a requested change has been completed by the
delegated segment, it notifies its manager by sending
the notification RMDComplete as shown in Figures
10.1 and 10.2 (b). The type of change and results of the
change operation dictate how the change shall be
updated to the other attached DRNS segments of the
namespace. After all affected DRNS segments have
been properly updated, then the change request record
corresponding to the completed change shall be
removed from the queue. If there are still inactive
change requests, the next request is selected and then
made active.
All other DRNS segments with the same logical recipe
shall be updated as appropriate. A change in agent-
specific datasets only shall be updated to master
segments. A change to attributes only shall cause only
the attributes of other instances of that recipe to be
updated. If the logical recipe was changed, then all
segments having a copy of that logical recipe shall be
updated.
When all necessary updates have been performed, the
DRNS manager shall discard the change request
record. It shall either request its DRNS recorder to
remove the change request for that change or to add the
next change request to be approved. Then the DRNS
manager shall select another inactive change request. If
no further change requests exist for that recipe, the
DRNS manager shall remove the last change request
from any attached DRNS recorder.
10.3.4.7 Change Management Example — As an
example of change management, if an operator at
Equipment A wants to link Recipe R;3 within the
distributed recipe namespace D, the resulting changes
to the recipe's generic header must be passed to all
other attached DRNS segments within the namespace
that contain Recipe R;3 before any other change is
approved.
In this example, if a request from segment A to link
Recipe R;3 is received by the manager, and no inactive
requests exist, and if Recipe R;3 is not already both
linked and write-protected, and if the request is to be
approved, the DRNS manager creates a change request
record for that recipe, which locks the recipe. The
DRNS manager approves the request and denies
subsequent requests until the approved change has been
made and other segments with an instance of that recipe
have been updated appropriately.
10.3.5 Segment Change Request — The segment
change request operation is a request made by an
attached DRNS segment to approve a specific type of
change. The DRNS manager shall respond by either
approving the request, denying it, or putting it on hold.
When putting the requested change on hold, the DRNS
manager shall return the operation identifier delegated
in the corresponding change request record.
The segment change request operation is invoked with
the service RMDSegChange sent by an attached DRNS
segment.
10.3.6 Segment Action Complete — A DRNS segment
that has requested and received permission to change a
recipe shall notify the DRNS manager when the action
is complete, whether normally or abnormally. Also,
when the manager approves an earlier request made by
a segment, and the segment makes the change after
responding to the approval, the segment shall also
notify its manager of the completion of the change. The
notification allows the DRNS manager to request the
updated recipe and send it to other segments as
appropriate.
The segment action complete operation is invoked with
the service RMDComplete, sent by an attached
segment.
10.3.7 Segment Notification — A dedicated segment
shall notify its manager of any change to an agent-
specific dataset. These changes are pre-approved. They
are not preceded by formal requests for change and do
not generate change request records. Upon receiving
notification of such a change, the DRNS manager shall
update all master segments with the new agent-specific
dataset values. An example of this case is illustrated in
Table 10.6.
The segment notification operation is invoked with the
service RMDNotify, sent by an attached segment.
SEMI E42-0704 © SEMI 1995, 2004 74
Table 10.6 Notification of Change to an Agent-Specific Dataset
Manager Segment
Receives request from local operator to certify recipe.
Local operator certifies recipe for this agent.
The segment stores the generic attribute sent by its manager.
<- RMDComplete.nfy
The segment notifies its manager that the change has been
made.
<- RMNComplete.nfy
The manager requests the new set of agent-specific attributes:
RMNRetrieve.req ->
The segment sends the generic attributes to any requestor:
<- RMNRetrieve.rsp
The manager updates all master segments with the new agent-
specific attributes for that agent and recipe.
10.3.8 Get Change Requests — The get change requests operation returns a list of active and inactive change
requests (in that order) for a locked recipe. If the recipe is not locked, an empty list is returned. Otherwise, where the
active change request record is returned first in the list, followed by any pending change requests.
The get change requests operation is invoked with the service RMDGetChangeRequests.
10.3.9 Rebuild Distributed Recipe Namespace — The rebuild distributed recipe namespace operation is used to
rebuild a previous namespace by reattaching all of its attachments to a different namespace.
The DRNS manager must first get a list of DRNS segments to be used. This list may be provided by either the
service user or by a DRNS recorder specified by the service user. It then reattaches the DRNS recorder (where
specified) and each of the specified DRNS segments. The reattach operation alerts the reattached object that the
communication linkages to its DRNS manager may have changed and that its inactive change requests have been
lost.
Next, the DRNS manager obtains the list of recipe identifiers stored by each DRNS segment. Finally, when a DRNS
recorder has been provided, the DRNS manager completes the rebuild operation by checking the DRNS recorder for
any change request record in progress at the time the original namespace was lost. The DRNS manager shall
determine if the change was completed (through comparisons of recipe descriptors) and, if so, shall update the other
segments as if it had just received a segment change completion notification.
Note that only the currently active change request record is retained. Other inactive change requests made while a
recipe was locked have been lost with the original DRNS manager.
Note also the potential exists for agent-specific datasets stored by dedicated segments to be more recent than the
corresponding datasets stored by master segments.
The rebuild distributed recipe namespace operation is invoked with the service RMDRebuild.
10.4 Tables of Operations — This section provides the operations defined for each object within the distributed
recipe namespace capability. An additional column for the object authorized to invoke the operation is provided for
tables in this section.
10.4.1 Segment Operations Table — Table 10.1 lists all the operations defined for DRNS segment.
Table 10.1 Distributed Recipe Namespace Segment Operations
Operation Invoked by Description Reqd
Segment change approval The manager of the attached
distributed recipe namespace segment.
A change to a recipe requested earlier by
a segment is now permitted.
Y