Physical Output Mappings 

Introduction 
The creation of the Physical Output Mapping (POM) is the fourth and fifth of seven steps in program design.

Step Four (if necessary): Create a Warnier/Orr diagram depicting the structure of the format of the physical output. Then Step Five: Create a diagram depicting the process necessary to turn the logical output into the physical output. Invert the diagram if processing as a subroutine, and build the interfaces to the Logical Output Mapping.

These steps are explained in the following section of the tutorial.

Create the Physical Output Data Structure 
The structure of the physical organization of the output is as amenable to data structured design as is the logical organization. A data structure chart analogous to the Logical Output Structure can be built depicting the format of the physical output. It is sometimes called a Physical Output Data Structure, and can be built in the same fashion as the LOS: by listing the physical output data elements, their physical output frequencies, their calculation rules, and so on.

Consider a typical printed report. Assume for the purposes of this discussion that we wish to have a banner page at the beginning and at the end of the report, a heading and footing on each page, and 50 lines of data shown per page. One may construct a physical Output Definition Form (if necessary) which looks something like the following..

The Physical Output Data Structure looks similar to a Logical Output Structure, but shows physical sets and data rather than logical sets and data.

Notice that Line is shown as appearing "1,l" times within Page, rather than "50". This avoids "hard coding" a constant into the design that is likely to change.

Create the Physical Output Mapping (Uninverted) 
A Physical Output Mapping can be created in a manner analogous to that for creating a Logical Output Mapping: we use the structure of the output data (the PODS, in this case) and add to it the actions necessary to produce the output. It appears below...

As with the LOM, the augmenting the Physical Output Mapping with tests and control fields generates the following...

Notice that this augmented POM will only work under certain conditions: the physical lines that it expects as input must be a file of "logical output lines" created by the Logical Output Mapping. This is certainly possible if we wish to have our program process the data in two passes (ignoring the Physical Input Mapping pass for the moment). First, the Logical Output Mapping would run, but each logical "print" statement on the LOM wouldn't actually print to the report, but instead create a logical "line" as a record on a temporary file. Then as a second pass, the Physical Output Mapping just designed would read in that temporary file as input, and produce the packaged output.

This "two-pass" solution is fine, if there is time to go through all the data basically twice (and before you scream "that's inefficient" notice that a "print spooler" does exactly that...except that most print spoolers aren't as intelligent as this Physical Output Mapping). However if you want to just take one pass at the data, the Physical Output Mapping we've just designed will not work. A related solution must be used...

Invert the Physical Output Mapping (if necessary) 
Imagine for a moment that we would like to produce the printed report as before, but that we do not want to pass the entire data set through two separate stages of processing: we'd like to produce the report on a single pass through the data. This is very doable, but will require some changes to our Physical Output Mapping.

Here is the strategy: instead of having the Logical Output Mapping create a temporary file of logical "lines" to print, let's build the program so that the Logical Output Mapping calls a subroutine (or subprogram, it doesn't matter which) each time it has a "line" to print. The subroutine's job would be to keep track of the state of the printed report, print headings and footings when necessary, and print the "line" given to it by the Logical Output Mapping. Thus, the Physical Output Mapping will be implemented as a subroutine instead of a second program pass.

Notice that the Physical Output Mapping we have already designed WILL NOT WORK as a subroutine. If we call the "native" Physical Output Mapping but give it only one line to print, the POM we have will print an entire report (with only one line on it). It would create such a report each time a single line was given to it!

If, however, we know about inverted hierarchies, we can invert the native Physical Output Mapping with respect to the Line level, and have a routine that knows how to "print one line at a time." The pattern for inverting the POM is exactly the same as before, and the inverted mapping appears below...

Notice that since this mapping is to be invoked as a subroutine, there is no need for it to "get" data as input: at the time it is invoked the data that it should process has either a) been passed to the subroutine as a parameter or b) has been placed in some working storage area.

The mapping can be augmented as before...

Before the subroutine is invoked for each line, the contents of the data line to be printed have to be built and placed in some working storage buffer: the subroutine then prints the line from the buffer. Before it prints the line, it determines if a page heading is necessary on the page where the line will be printed; after the line is printed it determines if the page was filled by printing the line, and if so prints a footing.

Note that there are two boolean switches which must also be set before invoking the subroutine: "First-Line" is a switch informing the subroutine that the line in the buffer is the very first logical line for the report (and thus triggers the report heading); "Last-Line" is a switch informing the subroutine that the line in the buffer is the very last logical line (which triggers the printing of the footing on the final page as well as the report footing.)

To make this subroutine work, each logical line to be printed must be formatted before the line is sent to the subroutine (since the subroutine just prints the logical lines, it doesn't build them) and the switches must be correctly set. This is done in a portion of the output mapping called the "interface," and it is explained in the following section.

Develop Interface Routines 
The last step in developing the Physical Output Mapping is to interface it with the Logical Output Mapping so that the content and format of logical lines can be correctly created. To illustrate this process, we will begin by returning to the Augmented Logical Output Mapping created earlier.

To begin, notice that the inverted POM subroutine must be invoked each time there is a logical line to print (in most of the logical "print" statements seen on the ALOM). This is done in Brackets by using the "Dup" feature to create a duplicate of the subroutine in each place is is to be invoked.

Before each invocation of the subroutine, we must move the data to the line to be printed, and then move the image of the line into a working storage area (called "logical-line") so the subroutine knows where to look for it. These details are added to the diagram.

Observe that the "print" subroutine is not called for the attorney heading (since the attorney data is physically on the first client line for the attorney). Since the attorney name and number are not to be printed for each client, those fields are blanked out after printing the client line.

The only thing remaining is to add the setting of the switches for "First-Line" and "Last-Line." They are both initialized in "Print Firm Heading," and "Last-Line" is set true before the company total line is printed.

The routines "Print Firm Heading," "Print Attorney Heading," "Print Client Data," "Print Attorney Footing," and "Print Firm Footing" are called "interface routines" and they are technically part of the Physical Output Mapping portion of the program.

Adding similar details to the "Print" statements suggested inside the inverted POM subroutine will complete the design of the Physical Output Mapping portion of the program.