semi合集-English.pdf - 第1790页

SEMI E42-0704 © SEMI 1995, 2004 59 of “Default ” is prohibit ed. Once created , the namespace s h all be ready to accept reci pes. This is an optional cap ability that is not required if the owner age nt that provi des t…

SEMI E42-0704 © SEMI 1995, 2004 58

9 Namespace Management Operations

Namespace management operations include

operations that affect the namespace itself in some way

and those operations that provide information about the

namespace or its manager, or that require knowledge

about more than one recipe.

Namespace operations defined in RMS are presented in

groups of similar functionality:

• operations on the namespace (create, delete, and

rename namespace),

• operations that provide information about the

namespace or its recipes (get available storage,

check recipe status, and get best version), and

• operations on recipes that affect the set of recipe

identifiers within the namespace and/or moving a

recipe as a whole (create, delete, store, retrieve,

copy, and rename recipe),

• operations that always require interactions with a

recipe executor (verify, download, and upload

recipe).

Namespace management operations may be invoked

through namespace services defined in Section 12. In

most cases, service scenarios consist of a single

message request from the service user and a

corresponding response from the namespace manager.

This case is illustrated in Section 12.1.

Scenarios are shown only for operations that require

additional messages. These operations are one of two

types: operations that may be performed on more than

one recipe (such as delete recipe) and operations that

require interactions with a recipe executor to complete.

Operations such as these may require more time to

complete. The initial response to the message service

request only indicates the intent to perform the

operation. The namespace manager informs the service

user of the completion of each individual operation by

sending the notification message RMNComplete. (See

Section 12.1 for more detail.)

9.1 Applications of Object Services — A manager shall

comply with SEMI E39 (Object Services Standard

(OSS): Concepts, Behavior, and Services)

specifications for fundamental requirements and with

the requirements for Filters and Owner Objects.

9.1.1 Object Specifiers — The “owns/owned by”

relationship is used by OSS to define the object

specifier used for scope. Recipes within a namespace

are owned by the namespace in which they reside. The

namespace in turn is owned by its manager. The agent

that provides the storage and services for a centralized

namespace owns both the manager and the namespace.

An object specifier has the form of:

“type

: id

>…type

: id

>”

where “type

” and “id

” represent the object type and

object identifier, respectively, of the ith object instance

in the sequence, and where each object is owned by the

preceding object in the sequence and is the owner of the

succeeding object.

A namespace specifier is an object specifier applied to

namespaces. A recipe specifier is an object specifier

applied to recipes.

Object types in the object specifier may be omitted

where they may be otherwise determined. For the

recipe specifier, when omitted, they are determined by

their relative positions, with the recipe identifier in the

final position, preceded by a namespace identifier.

Additional identifiers preceding that of the namespace

are those of agents.

An example of a namespace specifier for a namespace

“NS-MOM” owned by an agent “Etch01” would be

“Agent:Etch01>RNS:NS-MOM>” or (where object

types can be otherwise determined) “Etch01>NS-

MOM”. A recipe specifier for recipe “/PROCESS/

ABC;5” stored in NS-MOM would be “Agent:

Etch01>RNS:NS-MOM>/PROCESS/ABC;

5>”.

Where the manager is to be used instead of the

namespace, the object type of the manager must be

included.

A recipe in a namespace also owns its components. An

agent-specific attribute is accessed through the recipe

owner.

9.1.2 Required Object Services — A manager shall

support operations for Get Attributes and Set Attributes

for the attributes of the namespace, the recipes within

the namespace, and the manager itself. For a shared

namespace, access to different agent-specific datasets

shall be supported.

When a recipe’s attributes are changed through the Set

Attributes operation, the appropriate attribute timestamp

and length attributes shall be updated as well.

A manager shall support the Get Type and Get

Attribute Name operations for the object types of

namespace, recipe, recipe components, and manager.

9.2 Namespace Operations — This section describes

operations that are performed on a namespace.

9.2.1 Create Namespace — The create namespace

operation is used to define a namespace and assign a

name to be used as its identifier ObjID

. The name is

assigned only by an authorized user, except that a name

SEMI E42-0704 © SEMI 1995, 2004 59

of “Default” is prohibited. Once created, the

namespace shall be ready to accept recipes.

This is an optional capability that is not required if the

owner agent that provides the namespace capabilities

also provides an installed default namespace (see

Section 6) that cannot be deleted. In this case, a means

of recreating the namespace shall be provided in the

event the namespace becomes damaged.

The create namespace operation is invoked with the

message service RMNCreateNS.

9.2.2 Delete Namespace — The delete namespace

operation is the inverse of the create namespace

operation. A namespace that is not empty may not be

deleted. It is recommended that the default namespace

of a recipe executor should not be deleted. This is an

optional capability required only if the create

namespace operation is supported.

The delete namespace operation is invoked by the

message service RMNDeleteNS.

9.2.3 Rename Namespace — The rename namespace

operation allows an authorized user to change the

identifier of the namespace. It is recommended that the

default namespace of a recipe executor should not be

renamed. This is an optional capability required only if

the create namespace operation is supported.

The rename namespace is invoked by the message

service RMNRenameNS.

9.3 Namespace Informational Operations

9.3.1 Get Available Storage — The get available

storage operation is used to determine the size of the

remaining recipe storage capacity, in bytes. The value

returned shall exclude any overhead requirements for

storage of one generic recipe. That is, it shall be

assumed that sufficient storage exists for a single recipe

with a combined generic attribute length and body

length less than or equal to the returned value, and

ignoring possible space requirements for additional

agent-specific datasets. This is a required operation.

The get available storage operation is invoked by the

message service RMNSpaceInquire.

9.3.2 Check Recipe Status — The check recipe status

operation checks a recipe identifier and returns the

status for existence and read-only (PROTECTED or

UNPROTECTED state). It also returns the next

available numeric version. This is a required operation.

This operation may be used to determine if a given

recipe identifier will be accepted prior to sending it to

the namespace and to obtain an available version if the

original identifier is used for a read-only recipe.

The check recipe status operation is invoked by the

message service RMNRecStatInquire.

9.3.3 Get Best Version — The get best version

operation checks for the best default version of a recipe

with a specified class and name and for an optional

specific member agent. If a member agent is specified,

then in addition to the rules for selection of a default

version defined in Section 3.2.3.4.1, the version with

the highest certification level for that agent is selected.

This is a required operation.

The get best version operation is invoked by the

message service RMNVersionInquire.

9.4 Namespace Recipe Operations — This section

describes the recipe operations that affect the set of

recipe identifiers within the namespace and/or involve

moving an entire recipe.

9.4.1 Create Recipe — A recipe is created through the

create recipe operation when a namespace is sent a

recipe with an identifier, body, body descriptor, and the

attributes BodyFormat

and EditedBy only. This

operation sets the attributes AttrLength

and

AttrChgTime

and clears the remaining generic

attributes.

This capability allows a recipe body that has been

created off-line to be stored in a namespace. It is

required of any namespace intended for use other than

as a default namespace for hardware-specific recipes

only

The create recipe operation is invoked by the message

service RMNCreate.

9.4.2 Delete Recipe — The delete recipe operation has

the effect of deleting a recipe from the namespace.

Complete physical erasure of the recipe is not required,

but the recipe is no longer considered to be stored in the

namespace, is no longer accessible, and the storage

space that it used is freed.

A read-only recipe may not be deleted.

The delete recipe operation is invoked by the message

service RMNAction. More than one recipe may be

specified by the service user. Figure 9.1 illustrates the

flow of messages in this case. The namespace manager

responds to the initial request with an intent to comply

before performing any deletions. As each deletion is

completed, the manager notifies the service user of the

results using RMNComplete.

10 In the case of the default namespace dedicated to hardware-

specific recipes, the recipes may always be created initially by the

recipe executor and uploaded to namespace.

Figure 9.1

Delete Recipe Scenario

9.4.3 Store Recipe — The store recipe operation is

used to store a complete recipe, including its body,

generic attributes, and one or more agent-specific

datasets, in a namespace. Note: methods of storing

recipes are not specified by RMS.

Storage shall be denied if the specified recipe identifier

is already used by an existing read-only recipe or if

there is insufficient storage available for the recipe.

Otherwise, the recipe shall be accepted into the

namespace.

The store recipe operation is invoked by the message

service RMNStore.

9.4.4 Retrieve Recipe — The retrieve recipe request

specifies the identifier of a recipe. If the recipe exists

within the namespace, the namespace manager returns

the requested recipe. Otherwise, it shall deny the

request. This is a required operation.

It is also possible to retrieve a recipe's generic

attributes set to a non-default value and/or one or more

of its agent-specific datasets without retrieving its

body.

The retrieve recipe operation is invoked by the message

service RMNRetrieve.

9.4.5 Copy Recipe — The copy recipe operation causes

a new copy of a recipe, with a different identifier from

the original recipe, to be created within the namespace.

If the identifier for the new copy is already in use by a

pre-existing read-only recipe, the namespace shall deny

the request.

The copy recipe operation is invoked by the message

service RMNCopy.

9.4.6 Rename Recipe — The rename recipe operation

causes a recipe to be assigned a new identifier within

the namespace. If the new identifier is already in use by

a pre-existing read-only recipe, the namespace shall

deny the request. In this case, it may suggest a new

version according to the rules in Section 3.2.3.3.

The rename recipe operation is invoked by the message

service RMNRename.

9.4.7 Verify Recipe — A manager is not required to

understand the syntax or semantics of the recipe

language of a source recipe or to understand the

internal format of an object form recipe. To verify a

recipe, the manager may require the services of a recipe

executor, described in Section 6. In this case, the

manager shall request verification from the recipe

executor of one of the agents listed in its Members

attribute and shall return the resulting status and error

information to the initial requestor. (See Section 11 for

more detail.) This is a required operation.