Browse Prior Art Database

Structure of Programs Driven by Sorted Input

IP.com Disclosure Number: IPCOM000083904D
Original Publication Date: 1975-Aug-01
Included in the Prior Art Database: 2005-Mar-01
Document File: 6 page(s) / 21K

Publishing Venue

IBM

Related People

Lippmann, HE: AUTHOR

Abstract

Where the primary purpose of a program is to respond to a sorted input data set and when the program is to be written according to the principles of structured programming, the structure of the program is determined by the structure of the sort fields of the records of the data set. The mapping of a description of those fields into the structure of the program is presented herein. THE BASIC PROBLEM.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 28% of the total text.

Page 1 of 6

Structure of Programs Driven by Sorted Input

Where the primary purpose of a program is to respond to a sorted input data set and when the program is to be written according to the principles of structured programming, the structure of the program is determined by the structure of the sort fields of the records of the data set. The mapping of a description of those fields into the structure of the program is presented herein. THE BASIC PROBLEM.

Consider an input data set, each of whose records contains an ordered set of fields s(1), s(2),..., s(n) upon which a sort had been made, with the deciding field between two records being the first in which there is disagreement in the order.

Define a field S(i) to be a concatenation of all the fields from s(1) through s(i). S(i) is required when it is wished to observe if there has been a "change in s(i) from one record to the next.

However, the word "change" requires further definition at the first and last records of the data set. Therefore, rather than deal in the concept of a change in value for a field from one record to the next, the notion of "change" is broken into two parts: the "passing" of an old value for a field and the "advent" of a new value for that field.

Now when the first record is introduced, there is an "advent" of a new value for each field and at the end, a "passing" of an old for each field. Thus, by forgetting about "change" and thinking only of an advent" or "passing", there is no special case at the beginning or end of the data set.

The program segment that is to be executed at the advent of a new value for a field is called the prologue for that field. Similarly, the segment for the passing of a value is the epilogue. That which is to be done before or after the entire reading of the data set, will be said to be in the prologue and epilogue for the data set. Thus, with n fields, there will be (in general) n+1 prologues and as many epilogues. (Some may be null.)

Anything else that is to be done in the entire program is done for a given record. Such activity will be in the single segment which will be called the mesologue.

(If there is something that is to be done for each charge rather than for either an advent or passing, it can be done in the epilogue for the field in question but only when the end-of-data flag is off.)

Thus, a structure is provided and everything desired to be done is fit into that structure by asking when it ought to be done: at the advent or passing of the data set or a particular field, or during the mesologue (for a record).

A "get" is done for the next record at exactly two points: at the end of the prologue for the data set and at the end of the mesologue. These "get's" will not be considered as part of either segment.

1

Page 2 of 6

The language used here to show the program structure is an approximated PL/I, whose intention is to show form rather than correct syntax. For brevity, it will be assumed that the fields s(i) are contiguously p...