semi合集-English.pdf - 第1798页

SEMI E42-0704 © SEMI 1995, 2004 67 Table 10.3 Typical Chan ge Request Scenario Manager Segment Receives request for attribu te change from local operator . Requests change from manager. <- RMDChangeRequest.req Manager…

100%1 / 7923
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>".
SEMI E42-0704 © SEMI 1995, 2004 68
10.2.1.1 Attribute Read/Write — The DRNS distributed
recipe namespace recorder shall support the get
attributes operation for its attributes. It shall deny
attempts to set its attributes through the set attributes
service.
10.2.1.2 Object Create and Delete Operations — The
recorder may support both the create object and delete
object pair of operations. The authorized user who
invokes the create object operation shall assign a name
to be used as its name ObjID
. The name "Default" is
prohibited.
Once created, the recorder shall be attached to a
specific manager before it is ready to accept data. Once
created, the recorder shall set its attributes other than
ObjID
to null or empty values.
The create and delete operations are not required if the
owner agent that provides the distributed recipe
namespace recorder capabilities provides an installed
distributed recipe namespace recorder that cannot be
deleted. In this case, a means of recreating the recorder
shall be provided in the event the recorder becomes
damaged. If either of these two operations is supported,
both are required.
10.2.1.3 Object Attachment Operations — The
recorder shall support the operations to attach and
reattach to a DRNS manager, and the detach and attach
set attributes when invoked by the DRNS manager to
which it is attached.
The recorder attributes Namespace
and Namespace-
Manager are set by the attach and reattach operations.
The detach operation breaks the logical connection of
the recorder to the namespace and managers by setting
the recorder attributes Namespace
and Namespace-
Manager to null values.
NOTE: In the event that a distributed recipe namespace
becomes damaged, its recorder should be left attached
so that it may later be reattached to a new manager.
The reattach operation is used in rebuilding a
distributed recipe namespace.
10.2.2 Add Segment Record — The add segment
record operation adds a given segment (its object
specifier) to the DRNS recorder's internal list of DRNS
segments. A request to add a DRNS segment that is
already in the list shall be denied.
The add segment record operation is invoked by the
service RMDRAddSegRecord.
10.2.3 Delete Segment Record — The delete segment
record operation deletes a given segment specifier from
the DRNS recorder's internal list of DRNS segments. A
request to delete a segment not in the current list shall
be denied.
The delete segment record operation is invoked by the
service RMDRDelSegRecord.
10.2.4 Add Change Request Record — The add
change request record operation adds a change
request record to the DRNS recorder. The DRNS
recorder keeps, at most, one change request record per
recipe at any time. This is intended to represent a
change currently approved and active for that recipe. If
the DRNS recorder already has a change request record
for the specified recipe, the information in the new
change request replaces the previous information.
The contents of the change request record are defined
in Section 10.3.7.4.
The add change request record operation is invoked by
the service RMDRAddChgRecord.
10.2.5 Delete Change Request Record — The delete
change request record operation removes a change
request record for a specified recipe.
The delete change request record operation is invoked
by the service RMDRDelChgRecord.
10.2.6 Get Change Request Record — The get change
request record operation returns the current change
request record for a specified recipe or assigned
segment.
The get change request record operation is invoked by
the service RMDRGetChgRecord and is available to
any service user.
10.3 Distributed Recipe Namespace Management
Operations — Operations defined in Sections 8 and 9
shall be supported by the DRNS manager. This section
defines the additional operations provided by the DRNS
manager. Operations defined in Sections 8 and 9.4 are
delegated by the DRNS manager to an attached DRNS
segment.
10.3.1 Object Services — The DRNS manager is
considered to own the DRNS segments and any DRNS
recorder currently attached to the distributed recipe
namespace. In addition to the object services required
in Section 9, the DRNS manager shall support the get
type and get attribute name operations for its attached
objects. The DRNS manager shall support object
services directed to any of its attached objects and to
recipes stored by specific DRNS segments.
The DRNS manager is considered to own the recipes
that are owned through delegation by any of its attached
DRNS segments. The Get Attributes and Set Attributes
operations for a recipe may be directed to the
distributed recipe namespace.