semi合集-English.pdf - 第1797页
SEMI E42-0704 © SEMI 1995, 2004 66 Figure 10.2 Message Flow for Ma nager Approval of C hange Request 10.1.2.2 Segment Cha nge Approv al — The DRNS segment may receive a segment change approval request for an action that …
SEMI E42-0704 © SEMI 1995, 2004 65
to a null value. All recipes and recipe attributes are
considered as read-only during the time the segment is
unattached.
The reattach object operation is used in rebuilding a
distributed recipe namespace. This operation sets the
value of the attribute NamespaceManager
to the name
of the new manager. The segment returns a new token
value to the manager.
The request to reattach itself serves to inform the
segment that any of its pending change requests not
previously approved have now been forgotten. The
segment should either discard the request or resubmit it
to its new manager.
10.1.2 Segment Recipe Management Operations —
Within a distributed recipe namespace environment, all
recipe management operations (Section 8) and
namespace recipe operations (Section 9.4) are
performed by the DRNS segment. The DRNS segment
shall support all operations defined in these sections.
Operations defined in Section 9.4 that involve a recipe
executor, such as download and upload, shall be
performed only with a recipe executor that is either
owned by the agent providing the DRNS segment
capability or is owned by a component within the
internal hierarchy of that agent. For example, a DRNS
segment provided by a cluster tool may download to a
recipe executor owned by a cluster module but not to
equipment external to the cluster.
Figure 10.1
Segment-Initiated Change Request Message Flow
10.1.2.1 Requirements for Approval — Operations that
change a recipe in any way shall be denied unless the
DRNS segment is attached to a DRNS manager. All
changes to logical recipes within a DRNS segment shall
be approved by the DRNS manager before the changes
are made to the recipe stored within the DRNS segment.
Changes to agent-specific datasets stored by attached
dedicated segments are pre-approved. This is possible
since, at most, one dedicated segment has an agent-
specific dataset for a specific agent for any given
recipe. However, the segment shall notify its manager
immediately after any such change by sending the
RMDNotify notification, which shall include the
attribute AgentSpec_Agent
, to identify the agent-
specific dataset, as well as all agent-specific attributes
that changed, regardless of whether they have been
reset to their default value or set to a non-default value.
(Otherwise, the entire agent-specific dataset would be
required.)
A master segment, however, is prohibited from
changing an agent-specific dataset without explicit
permission from the manager.
Requests for changes that are made with RMS services
defined in Section 12 may be sent from any service
user, including the DRNS manager. The DRNS segment
may reject requests for invalid changes, such as a
request to modify a read-only recipe. Otherwise, the
DRNS segment shall request approval from its DRNS
manager for each change (Section 10.3.5). The
manager responds by either approving, denying, or
putting the request on hold.
NOTE: Service requests sent directly to a DRNS
segment may not, in some circumstances, be fulfilled.
If the change request is denied, then the change is
prohibited immediately. If it is put on hold, the segment
shall retain the information necessary to effect the
desired change at a later time.
If the change request is approved, the DRNS segment
shall proceed with the change and shall notify its DRNS
manager when the change is completed, either normally
or abnormally, through sending the notification
RMDComplete with the results, as illustrated in Figure
10.1.
The DRNS manager will put a change request on hold
when another change request exists for the same recipe
and the recipe is locked. In this case, the DRNS
manager responds to the segment's change request with
an operation identifier that the manager uses later when
sending a segment change approval request.
SEMI E42-0704 © SEMI 1995, 2004 66
Figure 10.2
Message Flow for Manager Approval of Change
Request
10.1.2.2 Segment Change Approval — The DRNS
segment may receive a segment change approval
request for an action that the DRNS segment had earlier
requested. This informs the DRNS segment that an
earlier change request made by the DRNS segment has
now been approved for immediate action or has been
completely denied.
The segment shall respond in one of three ways:
— It may reject the approval due to changes in
circumstances since the original request was made
(Figure 10.2(a).
— It may first fulfill the change request and then
respond that the change request has now been
completed, either successfully or unsuccessfully
(Figure 10.2(a).
— It may first respond that it accepts the change
request and then attempt to complete the change.
When change request has been completed, normally
or abnormally, the segment shall notify the manager
of the results with the RMDComplete notification
service (Figure 10.2(b).
Rejection of segment change approval shall be used
when the change is no longer desired. For example, a
DRNS segment "S" may request to link a write-
protected recipe, and the manager responds that the
request is on hold. Before the segment receives
approval for that change, the same logical recipe is
linked by a different attached DRNS segment, and the
results are updated to each DRNS segment having a
copy of the logical recipe, including segment "S". In
this case, the recipe may not be relinked.
11
The segment change approval operation is invoked by
the message service RMDSApproveAction by the
segment's DRNS manager and is otherwise invalid.
10.1.2.3 Scenario of a Segment Change Request — A
typical scenario is illustrated in Table 10.3.
In this scenario, a local operator wants to change the
generic attribute EditedBy
. The segment requests
approval for a generic attributes change. However, an
active change request exists for this recipe.
11 Both the DRNS manager and the DRNS segment are responsible
for compliance to RMS namespace requirements
SEMI E42-0704 © SEMI 1995, 2004 67
Table 10.3 Typical Change Request Scenario
Manager Segment
Receives request for attribute change from local operator.
Requests change from manager.
<- RMDChangeRequest.req
Manager already has an active change request to link that recipe
and answers that the request is on hold:
RMDChangeRequest.rsp ->
The active change request completes. The manager updates the
change to the segment:
RMNStore.req ->
The segment responds that it will make the change and notify
the requestor when done.
<- RMNStore.rsp
The segment requests approval to make the second change:
<- RMDChangeRequest.req
The manager approves the second request immediately:
RMDChangeRequest.rsp ->
The segment stores the generic attributes sent by its manager.
<- RMDComplete.nfy
The segment notifies the requestor of the second change (in
this case, its manager) that the change is complete.
<- RMNComplete.nfy
When all other segments are similarly updated, the manager
now approves the segment’s earlier request to change generic
attributes:
RMDSApproveAction.req ->
The segment makes the approved change to EditedBy
and then
responds:
<- RMDSApproveAction.rsp
The segment sends notification to the operator making request
for first change.
change:
<- RMNComplete.nfy
The manager requests the new set of generic attributes:
RMNRetrieve.req ->
The segment sends the generic attributes to any requestor:
<- RMNRetrieve.rsp
10.2 Distributed Recipe Namespace Recorder — This section defines the operations supported by the distributed
recipe namespace recorder.
10.2.1 Object Services — The recorder specifier is the object specifier of the recorder. A recorder is owned by the
agent providing the DRNS recorder capabilities. When attached to a DRNS manager, it is also owned by that
manager. An example of the object specifier for a recorder named Recorder182 provided by agent RecorderServer
is
"Agent:RecorderServer>RNSDRecorder:Recorder182>".