semi合集-English.pdf - 第1794页

SEMI E42-0704 © SEMI 1995, 2004 63 attribute of the agent-specifi c dataset for the recipe executor’s agent . Note that a ttributes of a recipe m ay change without affecting the v ersion number . Synchronization may f ai…

SEMI E42-0704 © SEMI 1995, 2004 62

The download recipe operation is invoked by the

message service RMNAction.

9.4.9 Upload Recipe — The upload recipe operation

causes the manager to upload a recipe from the recipe

executor of a specified agent (see Section 11.2.3). This

operation is the equivalent of a namespace-initiated

recipe create (if the specified recipe identifier does not

already exist in the namespace) or a recipe update.

The upload operation allows recipes that have been

created or modified by the recipe executor to be placed

under management in a namespace. Such recipes are

always unlinked.

In addition, it is possible to upload previously

downloaded recipes. However, due to the differences in

the attributes, certain intermediate information available

in a managed recipe, such as ExtRef

and Parameters,

must be re-created for the uploaded recipe by

requesting the recipe executor to verify the recipe and

send the results.

In the case of the derived object form recipe, where the

original source recipe identified in the SrcRcpID

attribute (common to both recipe types) exists within

the namespace, most of the attributes of the derived

object form recipe are identified to those of the original.

The exceptions are the attributes AttrLength

AttrChgTime

, BodyLength, BodyFormat, and

EditTime

, which are all set by the recipe executor at the

time the derived object form recipe is derived.

The namespace manager is responsible for converting

the uploaded execution recipe to a managed recipe for

storage in the namespace. This is accomplished through

the following steps:

1. If the recipe is not verified, then no conversion is

performed. The attributes ExecAttrLength

and

ExecAttrChgTime, if uploaded, are discarded.

2. The generic attributes ExtRef

and Parameters of the

verified recipe are not sent with the uploaded recipe.

They must be obtained separately through the verify.

3. If an agent-specific dataset exists that corresponds to

the destination recipe executor, then if the execution

recipe attributes AgentSpec Comments

and Certified

are non-empty, they are placed in the corresponding

attributes of an agent-specific dataset for that recipe

executor. If necessary, an agent-specific dataset is

created.

4. Any variable parameter initial values and

restrictions in the execution recipe attribute AgentSpec-

LinkParam

replace their corresponding elements in the

corresponding agent-specific attribute (if the dataset for

that agent exists) in the uploaded recipe. If it can be

determined that the contents of AgentSpec LinkParam

are not different from those of the generic attribute

LinkParam

(as in the case of a derived object form

recipe), then AgentSpec LinkParam

should be

discarded. If necessary, an agent-specific dataset is

created for the appropriate agent.

The upload recipe operation is invoked by the message

service RMNAction.

9.5 Synchronization — In addition to the explicit

operations that are invoked through specific message

services, the recipe namespace manager may provide

the optional capability of sychronization of the

managed recipes with execution recipes stored by the

recipe executors of its member agents. This section

describes the synchronization capability.

The ExecChgCtrl

attribute of a recipe is used to specify

types of permitted changes in execution recipes. The

recipe executor is permitted to change the recipe body

or to save the last settings used for variable parameters

in the ExecLinkParam

attribute of the execution recipe

only when expressly granted permission in

ExecChgCtrl

may also require the recipe executor to

send a change notification message to the recipe’s

originating namespace. The originating namespace is

either the namespace from which the recipe was

downloaded or to which a new recipe will be uploaded.

Change notification applies to both the explicitly

permitted changes (modification and saving the last

value) and to a derived object form recipe built from a

source form recipe. Change notification informs the

namespace that a change of interest to the namespace

has occurred.

Namespaces with synchronization capability provide

two additional attributes, SynchOn

and SynchFail. The

first allows the user to disable synchronization or to

select the types of synchronization desired, and the

second records execution recipe specifiers of recipes for

which synchronization failed.

Synchronization for a new or changed recipe, or a new

recipe form, consists of uploading the execution recipe

for which a change notification has been received and,

when necessary to protect a read-only recipe, assigning

it a new version number and requesting the recipe

executor to rename the corresponding execution recipe.

Note that the recipe executor is required to deny

attempts to rename a currently selected execution

recipe.

The recipe executor saves the last value of a variable

parameter in the execution recipe attribute Exec-

LinkParam. Synchronization for a new last value

consists of getting the value of this attribute from the

recipe executor and updating the AgentSpec LinkParam

SEMI E42-0704 © SEMI 1995, 2004 63

attribute of the agent-specific dataset for the recipe

executor’s agent. Note that attributes of a recipe may

change without affecting the version number.

Synchronization may fail either through failure to

properly upload an execution recipe, through failure to

properly retrieve the value of the execution recipe’s

ExecLinkParam

attribute, or through failure to

successfully rename the recipe stored by the recipe

executor. The attribute SynchFail

contains a list of

recipe specifiers of the execution recipes for which

synchronization was attempted but failed to be

successfully completed. A recipe specifier shall be

deleted from SynchFail

if a later attempt at the failed

operation for that recipe is successful. The authorized

user may also remove one or all recipe specifiers from

this attribute.

The attribute SynchOn

is set by the user to indicate the

types of changes for which synchronization shall be

performed. SynchOn

may be set to specify synchroniz-

ation for changes to the body, changes to the last value,

creation of a new recipe, building a new derived object

form recipe from a source form, or any combination of

these settings. A value of zero disables synchronization.

SynchOn

is an unsigned integer. Possible values are

either 0 (disabled) or any combination (sum) of one or

more of the following decimal values:

0 = synchronization disabled

1 = changes in body

2 = new execution recipes

8 = changes in the last value of one or more

variable parameters (i.e., to the ExecParam

attribute of the execution recipe)

16 = new derived object form execution recipes

NOTE: Where possible, the values of SynchOn

and

ExecChgCtrl

address the same change issues. For this

reason, a value of 4 is not used, and a new value of 16

is added.

9.6 Table of Operations — Table 9.1 lists all the

operations defined for namespace management.

The column labeled “Rqmt” is used to indicate those

operations that are required for fundamental compliance

to RMS as a recipe namespace resource.

Table 9.1 Namespace Operations

Operation Description Rqmt

create namespace A new namespace is created and assigned an identifier. N

delete namespace A namespace is deleted. N

rename namespace The namespace identifier is re-assigned. N

get available storage Determine the amount of recipe storage available. Y

check recipe status Determine the existence and read-only status of a recipe, and obtain the next numeric version. Y

get best version Determine the default version for a given recipe class and name and for an optional agent. Y

create recipe A new recipe body is entered into the namespace. Y

delete recipe A recipe's identifier is removed from the namespace. Y

store recipe A recipe is stored in a namespace. Y

retrieve recipe A recipe is sent from the namespace. Y

copy recipe A new recipe is originated as a copy of an existing recipe. N

rename recipe A recipe is assigned a new identifier. N

verify recipe Check the syntax or format of a recipe body for correctness. Y

download recipe A recipe is downloaded to a specified agent's recipe executor. Y

upload recipe A recipe is created or updated by uploading a recipe body from a specified agent's recipe

executor.

9.7 Namespace Events — A user of recipe namespace services is potentially interested in any change that occurs to

or within a namespace that was not initiated by the user itself. Two such events are defined: Recipe Namespace

Change and Recipe Change. A Recipe Namespace Change event occurs when a namespace is created, deleted, or

renamed, or when a recipe is created, deleted, copied, or renamed. A Recipe Change event occurs whenever the

body or any of the attributes, including agent-specific attributes, of an existing recipe is changed.

SEMI E42-0704 © SEMI 1995, 2004 64

The selection of events to be reported, and the

mechanisms for reporting these events, are defined in

SEMI E53 (Event Reporting).

10 Distributed Recipe Namespace

Management Operations

This section defines the operations required for the

distributed recipe namespace capability. Operations are

defined for the DRNS segment, the DRNS recorder, and

the DRNS manager, in that order. Support for the

distributed recipe namespace capability is not required

for RMS compliance.

10.1 Distributed Recipe Namespace Segment

Operations — This section defines the operations that

shall be supported by the distributed recipe namespace

segment.

10.1.1 Object Services — The DRNS segment is

considered to own the recipes that it stores.

The segment specifier is the object specifier for a

DRNS segment and has the form

"type1:id1>...>type2:id2". An attached DRNS segment

is owned by the agent providing the DRNS segment

capabilities, by the distributed recipe namespace of

which it is a component, and by the DRNS manager to

which it is attached, and shall be accessible by any of

these three paths. An unattached DRNS segment is

owned by the providing agent.

An example of a segment specifier for a DRNS segment

named ABC_Etch_Seg, a component of a namespace

named WetEtchA provided by an agent named

WetEtch003, is

"Agent:WetEtch003>RNSD:WetEtchA>RNSDSegmen

t:ABC_Etch_Seg".

For a master segment Alpha provided by agent

RecipeServer, this becomes

"Agent:RecipeServer>RNSD:WetEtchA>RNSDMaster

:Alpha."

NOTE: The form of the specifier used for DRNS

segments and DRNS recorders will vary. For example,

to specify a segment to be attached to a DRNS manager,

the specifier must include the object type and identifier

for the agent providing the segment capability. Once

the segment is attached, it may be specified through the

namespace hierarchy, as in the example above.

10.1.1.1 Attribute Read/Write — The DRNS segment

shall support the get attributes operation for itself and

all recipes that it has stored.

It shall support the set attributes operation for its

recipes only according to the restrictions against change

defined in Section 5.4.2 and within Section 10.1.

If requested to change read/write attributes, it shall

request and receive permission to change attributes

prior to making such change.

A request to change either several generic attributes at

the same time, or several agent-specific attributes for a

specific agent-specific dataset at the same time, is

considered for approval purposes as one change.

However, changes to both generic and agent-specific

attributes shall not be included in one change request or

change.

10.1.1.2 Create and Delete Operations — The segment

may support both the create object and delete objects

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 segment shall be attached to a

specific manager before it is permitted to accept

recipes.

The create and delete operations are optional if the

owner agent that provides the distributed recipe

namespace segment capabilities provides an installed

distributed recipe namespace segment that cannot be

deleted. In this case, a means of recreating the segment

shall be provided in the event the segment becomes

damaged. If one of these two operations is supported,

both are required.

The attributes Namespace, NamespaceManager, and

RecipeReadOnlyLevel

shall be set to null values at the

time the segment is created.

A segment that is attached or that contains recipes (is

not empty) shall not be deleted.

10.1.1.3 Object Attachment Operations — The

segment shall support the operations to attach and

reattach to a DRNS manager, and also the operations

invoked by its manager to detach itself from a DRNS

namespace manager. It shall also support the attach set

attributes operation. Certain RMS operations shall be

accepted only when received from its manager, as

indicated below.

All requests for changes to recipes within the segment

shall be sent to the DRNS manager to which it is

attached.

The manager shall set the segment attributes

Namespace

, NamespaceManager, and RecipeRead-

OnlyLevel when attaching or reattaching a segment. It

may change these attributes for an attached segment at

any time.

The detach operation breaks the logical connection

between the segment and its manager. The segment

becomes unattached, and the values of Namespace

NamespaceManager

, and RecipeReadOnlyLevel are set