Browse Prior Art Database

Automated Build Process Using a Relational Data Base

IP.com Disclosure Number: IPCOM000088152D
Original Publication Date: 1977-Apr-01
Included in the Prior Art Database: 2005-Mar-04
Document File: 2 page(s) / 14K

Publishing Venue

IBM

Related People

Brackenberry, IF: AUTHOR [+4]

Abstract

A build process, in programming terminology, is a process which accepts programs written in some user-oriented language by program developers and constructs from them a set of executable programs which together constitute a testable system.

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

Page 1 of 2

Automated Build Process Using a Relational Data Base

A build process, in programming terminology, is a process which accepts programs written in some user-oriented language by program developers and constructs from them a set of executable programs which together constitute a testable system.

The particular features of the process described here are: 1. Automatic recognition of main programs, i.e., those source program units which must be translated to executable programs. 2. Automatic recognition of which executable programs are affected by a newly-submitted unit of source program text. 3. Maintenance of a data base which expresses dependencies among source programs, and the use of this data base for inquiry functions. The major functions of the build process are: 1. Housekeeping - retain submitted source language programs, and back them up for safety. 2. Determine which logical units - that is, recognizable subunits of function - must be translated into executable programs.
3. Report on the successes and failures of such translations. 4. Maintain, as an inquiry data base, the names and interrelationships of components.

The build process operates with a base library, containing old versions of source language programs, a base library for executable programs, and a submission library for newly-developed source programs. These source language programs may consist, wholly or in part, of macro programs; that is, macro processes first generate translatable text, and it is this generated text which must be translated to an executable form.

For a single executable module, typically many source language components are involved. A change in one component means that the whole of the containing unit must be translated, even if the unit itself is already in existence, and accepted, in the base source code library.

The build process tracks and updates such dependencies continuously, and, in addition, decides what translation to executable programs is needed. It does this without any other information than that in the submitted source programs themselves, and the information in the base library(s) for source code. This part of the build process may be called dependency analysis.

The submitted source programs and base library source programs consist of named members, of a set of data called a partitioned data set (PDS). The names of the PDS members are not provided as input to the build process; the build process extracts the names from PDS contents directories.

Dependency analysis involves the following steps:

1. Scan all members from submitted and base libraries, and r...