semi合集-English.pdf - 第1805页

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 r ecipe. Local operator certifies recipe fo r this agent. …

100%1 / 7923
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
SEMI E42-0704 © SEMI 1995, 2004 75
10.4.2 Recorder Operations Table — Table 10.2 lists all the operations defined for distributed recipe namespace
recorder.
Table 10.2 Distributed Recipe Namespace Recorder Operations
Operation Invoked by Description Reqd
add segment record the recorder’s manager A segment specifier is added to the
current list.
Y
delete segment record the recorder’s manager A segment specifier is removed from the
current list.
Y
add change request record the recorder’s manager A currently active change request
record is added for a specified recipe.
Y
delete change request record the recorder’s manager An existing change request record is
removed for a specified recipe.
Y
get change request records any The change request records for one or
more recipes are requested.
Y
10.4.3 Manager Operations Table — Table 10.3 lists all the operations defined for distributed recipe namespace
manager.
Table 10.3 Distributed Recipe Namespace Manager Operations
Operation Invoked by Description Reqd
segment change request an attached segment A segment requests approval for a
specified type of change on a specified
recipe.
Y
segment change complete an attached segment A segment’s notification that an
approved change has been completed,
either normally or abnormally.
Y
segment notification an attached dedicated segment A dedicated segment’s notification that
an agent-specific dataset has been
changed.
Y
get change requests any A request for the list of existing change
requests for a specified recipe.
Y
rebuild distributed namespace an authorized user A manager is requested to rebuild a
distributed recipe namespace using a
specified recorder.
Y
11 Recipe Executor Operations
The operations of the recipe executor defined by RMS are: download and verify, verify, upload, rename, get
available storage, delete, select, deselect, and change notification. In addition, the recipe executor shall provide
object services as described in Section 11.1.
Recipe executor operations may be invoked by an operator or through recipe executor services defined in Section
14. In most cases, service scenarios consist of a single message request from the service user and a corresponding
response from the recipe executor. This case is illustrated in Section 14.1.
Scenarios are shown only for operations that differ from this typical case. For example, some operations may require
more time to complete, such as recipe verification and the select operation that may be performed on more than one
recipe and may require interactions with a recipe namespace to complete. In this case, the initial response to the
message service request may only indicate the intent to perform the operation. The recipe executor informs the
service user of the completion of each individual operation by sending the notification message RMEComplete.
In addition, in restricted circumstances, the recipe executor is required to inform a namespace that a recipe body
originally downloaded from that namespace has been changed.