semi合集-English.pdf - 第1226页
SEMI E5-1104 © SEMI 1982, 2004 168 10.17.2. 1 Data Set N ame — An ASCII string (form at 20) which performs a function similar to the Message ID (Stream and Functi o n) of the SECS-I pr otocol. This is a logical na me whi…
SEMI E5-1104 © SEMI 1982, 2004 167
Figure 10
Wafer Map Received by Equipment
10.17 Stream 13 Data Set Transfers — This stream
provides protocols to transfer data sets between sys-
tems. It is not intended to provide a general file access
mechanism.
10.17.1 Data Set Characteristics — The data set may
reside on the host or the equipment.
10.17.1.1 The term data set is used in a very general
sense. A data set may represent a file, a data structure
in memory, a collection of sensor values, or high
density wafer profile data. The protocols define only
the way data is sent from one system to another and do
not define how the data set is stored by either the host
or equipment.
10.17.1.2 The sending system is defined to be the
system that has the data set. The receiving system is
defined to be the system to which the data set is being
transferred. The host or the equipment may assume
either role.
10.17.2 Unformatted Data Set Protocol — The proto-
col for transferring unformatted data sets has the fol-
lowing characteristics:
1. Information about the record structure of the data
set may be available.
2. ASCII records are transferred without the record
terminating “noise” characters used by some
operating systems.
3. Data sets do not need to be transferred in a single
message.
4. No arbitrary limits are imposed on the length of
one message. The maximum amount of data sent
in each message is determined by both the sending
and receiving systems, so there can be no data
overruns.
5. There is a method of restarting a transfer in the
event of an interruption.
SEMI E5-1104 © SEMI 1982, 2004 168
10.17.2.1 Data Set Name — An ASCII string (format
20) which performs a function similar to the Message
ID (Stream and Function) of the SECS-I protocol. This
is a logical name which has meaning to both the equip-
ment and the host. Neither the equipment nor the host
is required to use the Data Set Name for the same
information in any other context. For example, mainte-
nance data may be stored in the equipment in the file
“WIDGET.DAT” and in the host as records in a data-
base, but the Data Set Name may be “S11,F2”.
10.17.2.2 Records — The Record Type determines the
way the data set is divided into messages for transfer to
the receiving system. There are two types of records:
Discrete and Stream.
1. A data set with Discrete records has a traditional
record structure, such as ASCII text.
RecordLength is the length of the longest record.
Zero-length records are allowed. Each record from
the data set is sent as a single item in a message.
2. If Record Type is Stream, then the data set has no
internal structure which can be communicated with
this protocol.
These kind of data set might be, for example, a dump of
main memory, SECS-II structured data, or data which
has implicit record boundaries. RecordLength has no
meaning for this kind of data set. Items containing data
from the data set have no relationship to the structure of
the data set.
10.17.2.3 Transactions — The basic data transfer is
performed by the OPEN, READ, and CLOSE transac-
tions. There is no explicit write transaction. A write is
performed indirectly using the SEND transaction. A
RESET transaction is provided to allow a graceful
recovery after a crash. This protocol describes the
transactions over the communications channel only. No
assumption is made about the implementation of the
transactions. For example, the OPEN transaction on a
data set which is stored on a disk file does not
necessarily cause the sending system to open the file.
10.17.2.3.1 The OPEN, READ, and CLOSE transac-
tions are initiated by the receiving system. The SEND
transaction is initiated by the sending system. The
RESET transaction is initiated by either system. The
usual transaction timer operates between the primary
and secondary messages of each transaction. The time
between transactions, especially between READ trans-
actions, is application-specific so no additional timer is
defined.
10.17.2.3.2 Internally, the protocol uses a Handle to
keep track of multiple open data sets, and a Checkpoint
which aids in error recovery. A value called
ReadLength is used to negotiate the amount of data sent
at one time.
10.17.2.4 Handle — Between the sending and
receiving systems, more than one data set may be open
at a time, or one data set may be opened many times.
The Handle is a short name used to keep track of the
state of a particular data set and instance of OPEN
between the sending and receiving systems (see Figure
11). This Handle may be thought of as a name for a
single application level connection from the sending to
the receiving system. Its value is assigned in the
primary message of the OPEN transaction.
10.17.2.4.1 The value used for the Handle must not be
used in another OPEN by the receiving system to the
same sending system until it is used in a CLOSE to that
sending system, or the RESET transaction is sent by
either system. For example, assume a host system
opens a data set on equipment 255 using Handle 1. The
host may not issue another OPEN to equipment 255
using Handle 1 until it closes 1 on 255. However, the
host may use Handle 1 to open a data set on another
piece of equipment, and equipment 255 may use Han-
dle 1 to open a data set on the host.
10.17.2.4.2 The number of data sets which may be
open at one time and the number of times one data set
may be opened is not specified by this standard. Error
codes are defined for situations where the limits are
exceeded. It must be possible to have one outstanding
transaction (i.e., a primary message for which there has
not been a reply) for each open Handle. If the sending
system receives a primary message for a Handle which
already has an outstanding transaction, then the error
code for Pending Transaction is returned in the second-
ary message (see Figure 11).
10.17.2.5 Checkpoint — The response to each READ
transaction contains the data and a new Checkpoint
value. The Checkpoint is defined by and has meaning
only for the sending system. Its purpose is to allow a
data transfer to be restarted from the point of the last
complete message after some communication interrup-
tion. The exact nature of the Checkpoint is not speci-
fied. It could be the byte index in the data set, a record
counter (for Discrete records), or some other system-
dependent value.
NOTE 12: Checkpoint and the SECS-II transaction timer
define a performance requirement for the sending system.
The sending system must be able to get data from any
checkpoint location within a data set between the receipt of
the OPEN primary message and the time for reply to the first
READ.
10.17.2.5.1 The value of Checkpoint must conform to
several rules:
1. The Checkpoint value is exactly four bytes long.
SEMI E5-1104 © SEMI 1982, 2004 169
2. The beginning of the data set has Checkpoint value
with all bits reset.
3. A Checkpoint with all bits set is illegal.
4. A Checkpoint supplied by the sending system
which does not have all bits set is usable in an
OPEN transaction to restart a data transfer without
any lost data or duplicated data.
10.17.2.5.2 The receiving system defines the initial
Checkpoint in the primary message of the OPEN trans-
action. The sending system returns the next Checkpoint
in the response to each READ.
10.17.2.6 Read Length — The Read Length must be
supplied by the receiving system with each READ
transaction. It specifies the maximum number of data
bytes which that system is prepared to process at one
time. The sending system may supply less if it has lim-
ited resources. The sending system may supply more if
ReadLength is zero, or is smaller than RecordLength.
10.17.2.7 Reading a Data Set — The basic data
transfer is initiated with the OPEN transaction and
completed with the CLOSE transaction. Information is
sent from the sending to the receiving systems by a
series of READ transactions.
10.17.2.8 OPEN Transaction — The receiving system
sends a primary message containing the DataSet Name
of the desired data set, the Handle to be used, and the
Checkpoint of the initial READ transaction. The
response from the sending system is a secondary mes-
sage with a return code and the RecordType and
RecordLength of the data set. If the return code is one
of the error codes, then no data set was opened and the
values of RecordType and RecordLength are undefined.
If the RecordType is Stream, then the value of
RecordLength is undefined. Notice that the undefined
items will still appear in the secondary message.
10.17.2.8.1 The return code in the secondary message
is one of the following:
OK.
ERROR: Unknown Data Set ID.
ERROR: Try later (i.e., the data set is in use).
ERROR: Too many open data sets.
ERROR: Data set open too many times.
ERROR: Handle in use.
ERROR: Pending Transaction.
10.17.2.9 The READ Transaction — The receiving
system sends a primary message which contains the
Handle, and the ReadLength. The sending system
responds with a secondary message which has a return
code, the next Checkpoint, and zero or more items with
data. At least one data item must be supplied unless
there is an error. The return codes are:
OK.
ERROR: End of Data.
ERROR: No open Data Set (i.e., incorrect Handle).
ERROR: Cannot continue (i.e., a disk read error on the
sending system).
ERROR: Pending Transaction.
10.17.2.9.1 Any READ transaction which follows a
READ which returned an error, except “Pending
Transaction,” will generate the same error. The value
of Checkpoint must be illegal (i.e., all bits must be set)
when the “End of Data,” “No open Data Set,” or
“Pending Transaction” error is returned. The value of
Checkpoint error must be a value from which recovery
may be attempted without duplicating data when the
“Cannot continue” error is returned. Recovery may be
attempted by issuing a CLOSE, followed by an OPEN
with the last value of Checkpoint, and then another
READ.
10.17.2.9.2 Each secondary message for the READ
transaction must contain a whole number of Discrete
records. A record may be sent as an ASCII or a binary
item. Stream data sets are broken into pieces by the
READ transaction without regard to internal structure.
Each piece would be sent as a single binary item. The
number of items which contain data depends on the
RecordType, Record Length, and Read Length. The
algorithm is designed so that the maximum length of
the secondary message is deterministic. It gives the
receiving system the ability to control the amount of
resources (such as SECS-I buffers) which it must allo-
cate. The sending system may send less data than the
maximum if it has limited resources. The performance
(i.e., the packing of records into a message of some
maximum size) should be very good for the case where
records are all nearly the maximum length. This is
assumed to be the usual case. The efficiency in patho-
logical cases (e.g., many short records) will not be
good, but the algorithm is robust enough to accommo-
date this without exceeding the maximum message size.
NOTE 13: If the RecordType is Stream, then there is exactly
one item with a binary format whose length is not more than
ReadLength. If the RecordType is Discrete, then the
maximum number of items, MaxItems, is calculated by the
formula:
thRecordLeng
ReadLength
int,1maxMaxItems