Physical Input Mappings 

Introduction 
The creation of the Physical Input Mapping (PIM) is the sixth and seventh of seven steps in program design.

Step Six (if necessary): Create a Warnier/Orr diagram depicting the structure of the physical input files (if necessary). Finally Step Seven: Create a diagram depicting the process necessary to turn the real input into the desired logical input. Inversion may be used when necessary.

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

Developing the Physical Input Mapping is in a way simpler than developing the Physical Output Mapping. In a way it is much more difficult because of the way you have to "think" about processing the input. Notice that we have already designed a large part of our program without any knowledge or concern over what the input to the program actually is; contrast that with the point in traditional programming when you start to worry about how to process the input. Traditionally, it is one of the first things you start to think about when writing the program; in DSPD is is one of the last. This is a hard transition for many people to make, but the benefits are well worth the effort.

For the example we have been working with, you will recall the Logical Data Structure...

We assumed for the Logical Output Mapping that there were three different logical records which would be available, as indicated below...

There would be one logical record for the Firm (containing the Month End Date), one for each Attorney (containing the Attorney's Number and Name), and one for each Client (containing the Client Number, Name, and Amount Billed).

Physical Input Data Structures 
As with the design of the Logical Mapping and the Physical Output Mapping, we can begin by analyzing the data required of the input mapping. The output data (of the input mapping) are the data elements from the Logical Data Structure (remember that the input mapping must supply the logical mapping with only the necessary logical input data). We must also examine the actual input files, and see where these required data elements come from (and more importantly, how often they come in). If there are any calculations required to translate the data as it exists in the input files into the logical form, those calculations can be documented, as well as the calculation frequencies.

We will illustrate the design of the input mapping by first assuming that the actual files are very close to the logical files we envisioned (we'll look at more complicated examples later). Therefore assume we have as ACTUAL input, three different files:

1) A parameter file containing a single record, which has on it the Month End Date. It is a sequential file.

2) An attorney file containing a record for each Attorney of the Firm. Each record contains the Attorney Number and Attorney Name. This file is a direct-access file, and its key is the Attorney Number.

3) A client file containing a record for each Client billed during the month. Each record contains the Client Number, Client Name, Client Amount Billed, and the Attorney Number. Further, the client records have been edited (there is no invalid data) and has been sorted by Client Number within Attorney Number.

We can create a worksheet similar to the Output Definition Form which summarizes our understanding of the requirements of the Physical Input Mapping. It is shown below.

This analysis should tell us that we will have to "read a parameter record" once for the firm, "read an attorney record" once each Attorney, and "read a client record" once for each client, plus one (to know there are no more client records). Since this is such a simple exercise, we can just add those instructions to the Physical Input Mapping portions of our program design.

Physical Input Mappings 
Like the Physical Output Mapping, the activities which make up the Physical Input Mapping are added to our program design "inside" the "get" instructions seen on the augmented LOM.

We can add some miscellaneous instructions to the Physical Input Mapping (inside the "Get" statements) to open and close files, and to set up the No-More-Attorneys indicator.

Lower Level Input Mappings 
You may have noticed that the input mapping we have developed depends on a fairly simple (and very convenient) form of input. We have assumed that the Client File, for instance, exists in the sequence that we wish to process it, and that further it only contains good records. Also, it doesn't contain any extra client records (records which do not find their way onto the report). Further, we assumed that Attorney Records were directly accessible (we can look up the Attorney Record by either key or by looking up an entry in a table, based on data attached to each Client Record). What if these are invalid assumptions? Is the design still valid?

Well, assume for the moment that our initial assumption about the convenient nature of the input files was correct. But let's for the sake of argument say that the input files are changed, and that our program must be updated.

Let's first assume that the Client File changes such that it is no longer stored in the sequence we wish to process it. How would the design change? Well, the simplest change is to a) either add a job step which runs before this program which sorts the Client File into the proper sequence, or b) add a sort to the Physical Input Mapping. A very appropriate place for that sort would be in the "Get Firm Data" process, as shown below.

How would the design change if there were "extra" client records on the Client file (say, records for the previous month's billing in addition to records for this month's billing)? Again, our solution is to a) strip out the extra records before this program runs, or b) to "hide" the record stripping process inside the "Get Client Record" process. Since the input mapping subroutine expects only this month's client records, we can add another level of "input mapping" to the existing input mapping to scan through the client file and return only "good" records (just like the input mapping we have now returns only "good" records to the Logical Output Mapping).

Such a "selection mapping" has been added to the Get Client Record process, as below.

Notice that the "Get Client Record" process is expanded to process "1,n" Client Records. Each time it is invoked, it reads a client record, then sets a "selected-record" indicator if the record which was read passes the selection criteria (in this case, if the record read is for the correct month). If the record does not pass, another record is read, and the process is repeated until either a selected record is found, or the client file is exhausted.

Notice that this is a "partially inverted" mapping (see the section on inversion), so that when File End is encountered the input files are closed (there isn't anything interesting to do at File Begin, so that placeholder set has been removed from the diagram).

Similar "layers" of input mapping can do editing, updating, record matching, table lookups, summarization, and many other functions to transform the files coming in into the data required by the logical mapping. Many of the common types of "insulating" input mappings are presented in the "model programs" section of the tutorial later on.

One more example we will examine: what if the Client File contains a record for each Invoice for the month? The "Client Amount Billed" doesn't exist on the input file, and must be calculated. This information can be added to our data analysis worksheet as indicated below.

This indicates that our input mapping must summarize Invoice records to the Client level, as shown in the following design.

Please note that the "Get Client Record" is a partially inverted mapping, as in the last example (and that we added an indicator "First-Read" so that the File Begin placeholder set is indeed used.

Also notice the added logic to the "Get Client Data" at the end of the Client process. Since the Client File doesn't actually exist, notice that in building the "virtual" client records from multiple invoice records, the Invoice file will go to an end-of-file condition (called No-More-Invoices) at the time the last "client record" is built. This logic ensures that the last "client record" is processed correctly, and that the No-More-Attorneys indicator is turned on only when there are no more virtual client records to build.