semi合集-English.pdf - 第1806页

SEMI E42-0704 © SEMI 1995, 2004 75 10.4.2 Recorder Operations Table — Table 10.2 lists all the operations defined for distributed reci pe namespace recorder . Table 10.2 Distributed Recipe Namespac e Recorder Operations …

100%1 / 7923
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.
SEMI E42-0704 © SEMI 1995, 2004 76
11.1 Object Services Operations — A recipe executor
shall comply with Object Services Standard
specifications for fundamental requirements and with
the requirements for Owner Objects. Support for
Filtering is optional.
A recipe executor owns the execution recipes that it
stores, and it is owned by the agent that provides recipe
executor. The owner relationships are used by Object
Services to define a recipe specifier.
The recipe executor shall support operations for Get
Attributes and Set Attributes for its own attributes. It
shall support the operation of Get Attributes for the
execution recipe. (Note that all attributes of the
execution recipe are read-only and may not be set
through the interface. It shall support the Get Type and
Get Attribute Name operations for the object types of
recipe executor and execution recipe.
11.1.1 Execution Recipe Specifier — The object
specifier for an execution recipe includes the object
type and identifier of the recipe executor, followed by
the identifier of the recipe, including its originating
namespace. For example, to specify an execution recipe
"NS-MOM>PROCESS/ABC;5>" that is stored by a
recipe executor named "RE-Etch" owned by "Agent-
:Etch01", the object specifier would be
"Agent:Etch01>RcpExec:RE-Etch>NS-MOM>PROCESS/
ABC;5>".
11.2 Description of Operations — This section
describes the operations of the recipe executor.
11.2.1 Recipe Download and Verify — A recipe is
downloaded when it is transferred (sent) to the recipe
executor. Downloaded recipes that do not have the
Verified
attribute set to TRUE shall be immediately
verified. Otherwise, it is not necessary to re-verify a
recipe. Any verification errors shall be reported to the
initiator of the download operation.
For further discussion of the verification operation, see
Section 11.2.2.
Normally, if the identifier of the recipe (namespace
name, recipe class, recipe name, and version number)
is already assigned to an execution recipe already
existing in storage, the download is refused. However,
the initiator of the download operation may optionally
request a forced overwrite of any such pre-existing
recipe. In this case, if the existing recipe is not currently
selected, the new recipe replaces the older one. A
request to delete or overwrite a currently selected recipe
shall be denied.
The body of a recipe currently being edited shall be
protected from inadvertent change or overwriting by a
recipe with the same identifier that is downloaded
during this time. If the downloaded recipe is accepted
(stored), the equipment shall require the operator either
to save the edited recipe to a new (unused) identifier or
to discard it.
The download and verify recipe operation is invoked
with the RMEDnldVer service.
11.2.2 Recipe Verify — This is a required operation
that verifies a specified execution recipe.
Verification requires reading the recipe's body. For a
source form recipe, the verification operation checks
the contents of the recipe for syntactical correctness. If
supported, the recipe executor may also include one or
more checks for semantic correctness as part of its
verification operation. For recipes in object form,
verification checks the format of the contents to achieve
the same effect.
A verified recipe merely indicates that it is technically
correct and can be executed. It does not indicate that it
can be properly executed for the current hardware
configuration. Checking to ensure a recipe will execute
properly is called validation and shall only be
performed at the time recipes are selected for execution.
A recipe that has syntactical or format errors fails the
verification process. Information concerning errors
shall be reported to the initiator of the verification
process. This information is required for the user to be
able to make appropriate corrections.
Information returned to the namespace manager at the
conclusion of the verification process includes:
• All external references, required for the ExtRef
attribute of the managed recipe,
• All variable parameter definitions, required for the
Parameters
attribute of the managed recipe,
• The estimated or nominal time of the recipe, in
seconds, used for the EstRunTime attribute of the
managed recipe (optional).
These items are not returned if the recipe fails
verification. In this case, the recipe executor shall
provide sufficient information to the user for
identification of the type of error and where within the
body it occurred, for at least the first error encountered.
The external references that are returned shall always
include the name of the recipe referenced, and any
referenced namespace, in the proper form for a recipe
identifier. If the external reference specifies a
namespace other than "Default" (Section 6.4), the
version is required to be fully specified for verification
to be successful. Otherwise, version shall be left exactly
as specified in the body. Omission of version allows