The exchange mode provides an interface between computers of different architecture, through which data-structures can travel. This interface has two distinct components:
Normal blocking methods (e.g., IBM's VBS) use control-information associated to every physical record; for good reasons, because this provides safe and easy recovery to the next logical record in case a physical record is lost. In ZEBRA this could not be used because the intention was to provide a format which would allow data-taking computers to dump rapidly large amounts of data directly from memory to the file, without copying through a buffer and without distroying the data in the store, which implies the use of physical records without any control-information. Such physical records we call 'fast blocks'. We do however need a different kind of physical record, which does provide control information, and which can be used for recovery. Such blocks are called 'steering blocks'. Any data-structure starts on a steering block and may continue on as many fast blocks as needed, their number being recorded in the control-information of the steering block.
To permit recovery, the steering blocks carry a particular bit
pattern on the first 4 words,
i.e. a pattern of 128 bits.
This reduces the a priori chance of a fast block
simulating a steering block to 1 in 
.
This is further reduced by contraints on the contents of the control
information for the steering block.
(To keep this probability low the user must not deliberately
use elements of this pattern as signals,
such as end markers.)
Some copy utilities copy a magnetic tape with suppression of faulty blocks. If a fast block of a particular data-structure is lost in this way, FZIN would read the copy without getting an error signal for the fast block, and it would try to absorb the first block after the d/s, a steering block, using it as data. To prevent this, FZIN is programmed never to accept as fast a block which looks like a steering block. If a d/s contains a genuine fast block simulating a steering block, it will be lost. The chance of this happening is sufficiently low to be tolerable, as shown above.
A file to be read by FZIN is not necessarily the result of FZOUT, it may have been produced by a user program, and this may not yet be fully debugged. FZIN has been programmed to catch hopefully all logical errors possible in the user's output routines, and to give full diagnostics with logging level 4.
Whilst files in native mode can be written and read by identical code on all machines, specific code is provided for each type of machine to read and write files in exchange mode. Idiosyncracies of any given machine (like the ones of the VAX) must remain local to the specific code of that machine. This is an important principle, as it avoids the combinatorial problem of every machine having to know about all other machines. Also, it provides for a clean solution to the advent of a new machine, or the disappearance of an obsolete machine.