In this very small example, we assume only one record in each of the five files PSPZap uses:

Consider the input data and source construct records first. The source construct record describes what is in the input record. For example the section {C(IF)} says that the input record has the characters IF. This section is one of four, each describing a bit of the input record. These sections are called elements. If you look at the source construct record from left-to-right, then the four elements describe the entire contents of the input record. PSPZap is able to break down the input record using the source construct record.

Now consider the output data and target construct records. The target construct record describes what is in the output record. The target construct record has six elements. Two of these use ASCII codes rather than their character equivalents e.g. {D(040)} rather than {C(()}. These six elements, read from left-to-right, describe the entire contents of the output record.

PSPZap processes the transform record from left-to-right to derive the output record. The first specification is {T1}. This is a reference to the first target construct element. This specifies the characters if. PSPZap places if in the output record. The second specification {T2} is then processed in the same way. The third transform specification is {S1}. So PSPZap copies the input record characters identified by the first source construct element Var1 to the output record. PSPZap then continues to process the remaining transform specifications {T4}{S4}{T6} in the same manner.

This small example shows the most important principles of PSPZap processing. The construct and transform specifications in this example are very specific. In practice they tend to be much more generalised - the elements allow a lot of variability in the items they describe and manipulate. This short example does not illustrate these points.