Note: Descriptions are shown in the official language in which they were submitted.
12~8;~5~
-l- 70840-60D
This application comprises three different but related
descriptive portions, the first being headed "Insert A" and
relating to Database Management Means, the second being "Insert
B" and relating to Retrieval of Related Records From a Relational
Database and the third from page 99 to 116 relating specifically
to the present invention.
l'here are twenty-nine figures of accompanying formal
drawings some of which are relevant to each of the three descrip-
tive portions. Specifically, Figures l - 15 are relevant to
Insert ~, Fi~ures l, 5 and 16-26 are relevant -to Insert B and
Figures 1,5and 27 to 29 are relevant to the present invention.
The full list of drawings is as follows:
Fig. l is a simplified block diagram of a data proces-
sing system in which my invention is employed;
Figs. 2 and 3 are conceptual diagrams showing the
relationship between the physlcal records comprising the data-
base, and the user of the data processing system;
Fig. 4 shows the components of a typical relation of a
relational database
Fig. 5 shows the keyboard of the data processing system
of Fig. l;
Fig. 6 is a conceptual showing of the allocation of data
storage in the data processing sys-tem;
Fig. 7 is a conceptual showing of -the allocation of
program storage in the data processing system;
Figs. 8a and b show a particular screen format employed
3Z5~
-la- 70840-60
in my invention, and the same format mexged wlth representations
of record occurrences from -the da-tabase to define a screen image;
Fig. 9 is a conceptual (black box) showing of the
relational operator means of my invention;
Figs. 10 and 11 are conceptual showings of portions of
Fig. 6 in more detail;
Fig. 12 shows simplified views of the types of sereen
format employed in my invention;
Figs. 13 and 14 show eertain screen formats in greater
detail;
Fig. 15 shows a por-tion of Fig. 6 in more detail;
Fig. 16 shows the alloeation of part of the data stor-
age portion of the storage of the data proeessing system of Fig.
1 aeeording to my invention;
Fig. 17 shows the allocation of part of the program
storage portion of the storage of the data processing system of
Fig. 1 according to my invention;
E'ig. 18 is a coneeptual showing of operations perform-
ed aecording to my invention by the data processing system of
Fig. 1, under the control of particular signals stored in the
program storage, with respect to the signals in the data storage
of the system;
Figs. 19, 20, 21 and 22 show in detail certain sereen
formats employed in operation aeeording to my invention;
Fig. 23 shows a part of Fig. 16 in more detail;
Fig. 24 is a coneeptual showing of the relationships
among certain exemplary data base reeords;
12682~59
-lb- 70840-60
Figs. 25 and 26 show in detail certain further screen
formats employed in operation according to my invention;
Fig. 27 shows the allocation o~ program s-torage;
Fig. 28 shows the alloca-tion of working storage; and
Fig. 29 shows the WZFETCII module of Fig. 27 in greater
detail.
.. :
~L~68~S~
--2--
--INSERT A--
DATABASE MANAGEMENT MEANS
My invention relates to the operation of data processing
systems, in particular to the management of relational databases
stored in the memory of such systems. The invention further
relates to means to facilitate the interactive use and updating of
such databases.
BACKGROUND OF THE INVENTION
The invention is employed in a data processing system, having
one or more terminals or consoles which provide display means and
keyboard signal input means, and providing in storage physical
records modeled as at least one relational database.
Among the individual ultimate users of the data processing
system and database records are some users, such as clerks, who are
not programmers. Such users wish to be able to use the system
terminals to view displayed representations of the records stored
in the data processing system memory, to select specific records or
parts of records to view, to delete or modify physical records in
the memory, or to add new physical records to the memory. For
these purposes the physical records must be selected, accessed in
the physical storage, and retrieved (copied), and representations
'` `
. . .
-` 126~3~59
of the retrieved records must be displayed to the user at one of
the terminals in some predetermined display format.
To permit this use of the stored database records, there must
be provided in the data processing system stored coded instructions
which when executed by the data processing system cause
representations of the physical records, as well as representations
of signals input by the user through the keyboard, to be displayed
in a particular format on the display. Further, there must be
pro~ided stored coded instructions which when executed by the data
processing system cause the interpretation of the signals input by
the user through the keyboard, and which cause the retrieval and
modification Oe the physical records of the stored database in
response to such input signals.
Such instructions, designed for a particular use of the
records of a particular database, together comprise one of a class
of programs known as "database applications programs", that is,
programs used by the ultimate user of the data processing system to
carry out the application desired by him on the stored physical
records of a particular database.
The preparation of such applications programs has typically
required weeks or months of effort by an applications programmer,
followed by additional weeks to detect and eliminate errors in the
program so that it becomes reliable and relatively error-free in
use.
~2~325~3
-4- 70840-60
It is therefore desirable to provide means for simpliEy-
ing the cons-truction and operation of such database applications
programs, and it is an object of my inven-tion to provide such
means.
As is well understood in the art, the user (or program-
mer) of a data processing:system does not deal directly wi-th the
physical records stored in~the system's memory. Rather, he deals
with a model of such records, provided when needed by means of
programming stored in the system's memory and executed by the
processor as needed.
The invention referred to above will now be described
in more de-tail wi-th reference to Figures 1 - 15 of the drawings.
Referring to Figure 2, the physical records are s-tored
on physical media, advantageously as magnetic signals stored on
magnetic disks 24 comprising secondary memory 16. The magnetic
signals are physically organized on disks 24 in a manner well
understood in the art of m~naging such memory media. The par-
ticular organization of such signals, and the particular means
of locating them and copying them into main memory 14, are highly
dependent on the hardware ~spects of the particular memory media
employed.
Several models of-the records are provided, having dif-
ferent degrees of abstraction from the underlying stored physical
records. Briefly, these are (referring to Fig. 2): the "external"
view (26 or 28), in which ~'external" or "logical" records are seen
6~2~j9
. ~5- 70~40-60
by a particular user; the "conceptual view" (30), in which
"conceptual" records are seen, each external view being a sub-
set of the concep-tual view; and the "internal" view (32) in
which "internal" or "stored" records are seen.
68~j9
--6--
It will be recognized that, when the data processing system
operates to construct and present for use the records of each view
shown in Fig. 2, these records are at that time (during such use)
represented within the data processing system by physical signals
derived from the magnetic signals stored on disks 24. When such
use is concluded, the constructed records are no longer physically
represented within system 10. In contrast, the underlying physical
records stored on disks 24 remain on the disks at all times,
whether or not they are in use, until deleted or modified.
The signals representing the records as seen in the various
views 26, 28, 30, and 32 are derived from the physical records
stored on media 24 by the data processing system, by means of the
operation of a database management system, in other words by the
execution of a suitable stored program by processor 12. As seen in
the conceptual showing of Fig. 3, the physical records on media 2~
are physically written, copied, and deleted by the data processing
system under the control of a program element known as an access
method, in a manner well understood in the art, and forming no part
of the present invention. The access method is regarded as
presenting to the database management system "stored" or "internal"
records corresponding to and derived from the physical records.
The "internal" view is not seen by the user of the database
(although it may be known to a programmer using the system).
Processor 12, operating according to other portions of the database
management system program, constructs from the stored or internal
`` 126825~
--7--
records the records of the conceptual view and its subsets, the
external views. The definitions of the conceetual records are
independent of the storage structure or the strategy employed by
the access method for efficiently locating and retrieving the
physical records.
Records in a database may be related to other records in the
database, and the relationship is of interest to the user of the
database. The relationship is itself represented as an entity in
the database.
It is well understood in the database management art that the
conceptual records of a database, and the relationships among them,
may be organized or modeled in one of three possible ways, known as
relational, hierarchical, and network models.
The present invention relates to the management of the records of a
database modeled as a relational database.
The records of a relational database are conceptually
organized as tables (also referred to as "relations"). ReEerring
to Fig. 4, a table (relation) of a relational database comprises a
plurality of rows; each row is a record (or tuple) comprising a
plurality of fields. All rows of a particular table have the same
nwnber oE fields. The fields of the records are arranged in
columnsJ a column is also referred to as an attribute. The
elements of a column are all members of a class of such elements,
referred to as a domain, and the column is named by a column
~68~S9
--8--
heading (domain name). Each record includes one or more fields
whose content i5 an index or key, to be used in uniquely
identifying the record.
A crucial feature of relational data structure is that
associations between rows (tuples) are represented solely by data
values in columns drawn from a common domain, rather than in terms
of the physical location on disk of the related records.
Relational databases have various advantages over the two
alternative models. Generally speaking, while hierarchical and
network databases are organized to make it efficient to deal with
one record at a time and to obtain a single related record at a
time, relational databases are organized to make it efficient to
deal with a set of records at a time and to obtain a set of related
records at a time.
It is an important aspect of the relational model that the
tables (relations), if they conform with certain constraints, may
be considered as mathematical elements, also called relations, as
to which a rigorous mathematical treatment already exists. Hence,
operations on the tables can be analyzed in terms of this
mathematical theory, an advantage in clearly understanding the
effects of such operations. In particular, representing the data
in the Eorm of uniformly defined sets makes possible a
corresponding uniformity in the set of operators which transform
the sets, which simplifies the task of providing program elements
--- lZ6~ 59
for controlling a data processing system to transform such sets.
It is an object o my invention to extend this advantage to aspects
of database maintenance where it has not previously been provided,
by providing an enumerated relation.
BRIEF SUMMARY OF THE INVENTION
A data processing system has: a keyboard providing input
signals; a visual display~ storage means providing s;gnals
representing a plurality of record occurrences organized as
relations within a relational database: working storage: and a
processor having means for controlling the visual display, for
reading and writing the working storage, and for responding to the
input signals. The processor further has access means for
retrieving record occurrence signals from the database and for
storing retrieved record occurrence signals in the working storage.
According to my invention, the data processing system is
characterized by having means in the working storags for providing
format signals representative of a predefined display format, and
cursor signals representative of a cursor defined against a target
comprising at least one of the relations in the database, and by
having relational operator means for providing signals
representative of a result relation, membership in which is defined
enumeratively and interactively through the keyboard.
~2682~9
-10-
The operator means comprises cursor acceptance means for
accepting the cursor signals from the working storage. The system
access means is responsive to the cursor acceptance means to
retrieve from the target record occurrence signals specified by the
cursor.
The relational operator means Eurther comprises screen image
defining means for accepting the format signals from the working
storage, and for defining and storing screen image signals
representative of a screen image, responsive to the format signals
and to the retrieved record occurrence signals. The processor is
responsive to the operator means to control the display to display
a representation of the stored screen image signals, and to modify
the stored screen image signals corresponding to enumerating
signals from the keyboard, input during such display, effecting
enumeration of certain of the retrieved record occurrences.
The operator means further comprises means for deriving from
the modified screen image signals together with the cursor signals,
output signals defining a result relation, membership in which is
defined enumeratively, and for storing the output signals in the
working storage.
According to another aspect of my invention, the data
processing system is further characterized in that the operator
screen image defining means is further responsive to the predefined
display format signals to define in the screen image
...
'`"' '
.. ' :
~' :
~13Z59
--11--
representations of a plurality of selectable operations executable
by the processor. The processor is responsive to the operator
means to accept, during such display, operation selection signals
input from the keyboard, effecting selection of one of the defined
plurality of operations; the processor stores the operation
selection signals.
The operator means further provides means responsive to the
stored operation selection signals for providing and storing an
output signal representative of the selected operation.
According to another aspect of my invention, the data
processing system has relational operator means for providing
signals representative of a result relation, membership in which is
defined in terms of record occurrence attributes explicitly defined
in the database, the result relation being defined interactively
through the keyboard.
The operator means comprises screen image defining means for
accepting the format signals from the working storage, and for
defining and storing signals representative of a screen image
providing generic elements and open elements. The processor is
responsive to the operator means to control the display to display
a representation of the screen image, and to modify the stored
screen image open elements responsive to characterizing signals
from the keyboard, input during such display, effecting
characterization of the cursor.
~L~68~59
-12-
The operator means further comprises means for deriving from
the modified screen image together with the cursor signals, output
signals defining a modified cursor which defines a result
relation, membership in which is defined characteristically, and
for storing the output signals in the working storage.
In preferred embodiments, the data processing system is
characterized in that the format signals define two alternative
mode formats, and include a mode indicator correspondinq to each
mode ormat. The relational operator means is responsive to the
mode indicator for using the indicated mode format, and for either
providing signals representative of a result relation, membership
in which is defined enumeratively and interactively through the
keyboard, or providing signals representative of a result relation,
membership in which is defined in terms of record occurrence
attributes explicitly defined in the database, the result relation
being defined interactively through the keyboard.
In preferred embodiments, a plurality of selectable operations
is defined for each mode format; for each mode format, the
selectable operations include a transition operation to display
according to the other mode format, and the operator means includes
means responsive to the output signal representative of the
transition operation to provide a mode indicator signal
corresponding to the other mode to the screen image defining means,
and if necessary to the cursor acceptance means, to effect the
transition.
, '
"
~L268ZS9
-13-
Also in preferred embodiments, the working storage provides
means for providing format signals representative of a predefined
update display format, and the plurality of selectable operations
includes a transition to display according to the update display
format signals. The data processing system provides update means
responsive to an output signal, fro-n the operator means,
representing the transition operation: the update means is further
responsive to the operator output signals defining a result
relation, for executing the update operation on the record
occurrences. The update means provides means for accessing the
update display format signals and for defining and storing screen
image signals representative o a screen image having
representations of an enumerated record occurrence and a selectable
update operation performable on the record occurrence. The
processor is responsive to the update means to display a
representation of the stored screen image, and to receive and store
an update operation selection signal input from the keyboard: the
update means is responsive to the stored update operation selection
signal to execute the update operation on the enumerated record
occurrence.
Other objects, features, and advantages will appear from the
following description of a preferred embodiment of my invention.
~ 2G~ 59
-14- '70840-60
DETAILED DESCRIPTION OF TEi~ INVENTION
Data processing system generally
Referring now to the drawing, and i.n particular to
Fig. l, the data processing system 10 has a processor 12, having
a main memory 14. Secondary memory 16 is provided in -the form of
one or more disks. Main memory 14 and secondary memory 16 together
comprise storage 17. The description of the present invention
does not concern itself with details of moving signals represent-
ing portions of programs or data between main memory and secondary
memory, as that is well understood in the art of managing data
processing systems
1~ 9
-15-
and the present invention does not pertain to it. It is assumed
that signals in all parts of storage 17 are available to processor
12.
One or more terminals or consoles, connected to processor 12,
each provides a CRT screen as a display means 18 and a keyboard as
signal input means 20. Other signal input means, such as mice,
touch screen, voice actuation, and the like, are contemplated by my
invention. If my invention is practiced in a large data processing
system, there may be additional processors within the system, such
as input~output processors, and the operations referred to herein
as performed by the "processor" may in fact be divided among such
processors. Such details do not affect the scope of the invention.
Keyboard and PF keys
Referring now to Fig. 5, keyboard 20 provides the usual keys
of a typewriter keyboard, indicated generally at 200, with space
bar 202. At the top of keyboard 20 are 16 keys 204, arranged in
groups of four: these are called PF (programmed function) keys.
Each is assigned a number from one to sixteen, and displays its
assigned number. With the use of the shift key, these keys provide
thirty-two possible programmed functions. In addition keyboard 20
provides an Enter key 206 and a pad of screen-position-marker
control keys 208. ~The screen-position-marker is more usually
called a "cursor", but that term will not be used for this element
in the present description, in order to avoid confusion with the
~2682~
-16-
"cursor" used in fetching multiple records from a relational
database.)
Storaqe 17
In the description which follows, the convention is observed
that words begining with "@" are names of pointers to data
structures or to elements within storage 17: that words beginning
with "$" are names of parameters for particular program elements:
and that words ending with "~" are names of indexes to elements
within lists or sets in data structures. Elements within a data
structure are named by words beginning with the data structure name
(or an abbreviation thereof), followed by a period: e.g.
"qry.source" is a storage element (or in some cases the signals
stored in such storage element) named "source" and located within
data structure "QUERY". Words beginning with "DO" are names of
modules within the calling programJ words beginning with "WZ" are
names of external procedures called by the calling program.
Storage 17 of data processing system 10 is regarded
conceptually as divided into program storage and data storage. The
contents of program storage (shown in Fig. 7) will first be briefly
revieweds the contents of the data storage (shown in Fig. 6) will
be described: each module of Fig. 7 will then be described in more
detail; and the ooeration of data processing system lO with respect
to the data structures and according to the modules will then be
described.
325~
-17-
Proqram storaqe
Referring now to Fig. 7, the program modules provided in
program storage are shown conceptually, with an indication of the
significant parameters input to each module and an indication of
calls from one module to another. In addition, in certain cases
parameters returned by the modules are indicated.
It will be readily understood that such modules and parameters
are represented by physical signals, and that during operation,
processor 12 copies from program storage signals representing
appropriate program elements and uses such signals to control the
physical state of hardware elements within system lO so that the
represented operation is physically carried out. It will be
likewise understood that when a module is described as "calling"
another module, in fact data processing system 10, operating
according to the first module, accesses the second module and
copies its signals in order to control further operation according
to the second module.
Brief description of Program storaqe
Operatinq system. In the program storage portion of storage
17 there are provided signals representing an operating system
program 100, which forms no part of the invention and may be of any
desired design, but which must provide an access method 102
suitable for controlling data processing system 10 to retrieve
~ ~268259
-18-
record occurrences from the database in storage 17, to modify or
delete record occurrences in the database, and to add new records
to the database. In addition, operating system 100 must include
program for the control of display 18 and keyboard 20, and
specifically, must be able to respond to an appropriate command
("Write/Read Screen") in a calling program by sending signals
representing a stored screen image to display 20, receiving
keyboard input signals, modifying the stored screen image in
accordance therewith, and in addition storing certain of the
keyboard input signals.
Callinq proqram. Program storage 17 further provides signals
representing a "calling program" which calls programming elements
for the oeeration of the data processing system. In the embodiment
described herein, the calling program is titled PACE RUN, but the
program for the relational operator means of the invention may be
called from other programs for maintaining relational databases,
and the details of such program are not pertinent to the present
invention except as described herein.
The information which must initially be passed from the user
of the terminal to the calling program comprises a designation oE
the database to be accessed, a designation of the screen file to be
accessed, and in some cases a cursor. (In other cases, a cursor is
provided in a manner to be explained). As understood in the art of
managing relational databases, a cursor is a statement (or an
implementation-dependent data structure derived from such
L2682~;9
-19-
statement) which defines a set o record occurrences to be
retrieved from the physical database, and-which identifies a
position within the set during the process of retrieving the record
occurrences.
Within the calling program (PACE RUN) are provided a DO OPEN
DATABASE module 103, a DO OPEN SCREEN FILE module 105, a DO DSC
module 107, a DO gUERY module 108, a DO PXI module 112, and a DO
UPDATE module 113.
A WZOPEN DATABASE module 104 is called by module 103; a WZOPEN
SCREEN FILE module 106 is called by module 105; and a WZOPEN CURSOR
module 110 is called by DO QUERY module 108. A WZPXI module 114 is
called by DOPXI module 112, and the WZDISP module 124 is called by
WZPXI module 114. The modules WZSCRLOD 116, WZRETRIEVE 118 and
WZSCRIO 120 are called by WZDISP module 124. WZFORMS 122 is called
by WZSCRIO 120. Further, a WZSELECT module 128 is called by module
114, and calls both WZSCRIO module 120 and OPEN CURSOR module 110.
A DO UPDATE module 126 is also called by DOPXI, under conditions to
be described, and the WZINSERT, WZMODIFY, and WZDELETE modules 115
are called by module 126. Details of the program modules shown in
Fig. 7 and of the operation of data processing system 10 under the
control of signals representing them will be described in what
follows.
-- æ6~s
-20-
Data storaqe
Referring now to Fig. 6, the data storage portion of storage
17 is conceptually divided into the database storage means
providing signals representing the record occurrences comprising
one or more relational databases 150, and working storage. The
details oE the database storage, as has been explained, are not
visible to the user of data processing system 10, and will not be
further described. The working storage is shown as providing
signals representing two kinds of data structures: the signals
representing those shown in solid lines are provided in storage 17,
according to my invention, before operation according to my
invention begins: signals representing the structures shown in
dotted lines are placed into storage, or storage space is allocated
for them, during the operation of data processing system 10
according to the program elements shown in Fig. 7, as will be
described.
Screen-file 151: PSCR, PSMP, POP, and PDEF
Signals representing a screen-file data structure 151 are
provided in storage 17, and provide predefined display format
signals. Screen-file lSl may be part of the user (calling)
program. It may provide display format signals for more than one
target relation; for purposes of this description, however, it will
be assumed that it is designed for the display of record
occurrences from a particular target relation (base table or view)
68;~
-21-
within the named database. More than one screen-file may be
provided, ;f more than one target relation is to be accessed.
Screen file 151 includes a PDEF table 153, which provides
storage for signals representing the initial screen format to be
accessed. Screen file 151 further includes Procedure Screen
Definition Table (PSCR) 152: the element @pscr is a pointer which
addresses PSCR 152. PSCR 152 provides stored signals relating to a
plurality of screen formats, the sic~nals for each screen being
located by the screen index (screen~). For each screen there are
provided in PSCR 152 signals representing the screen type (or mode
indicator), a pointer @scr which points to a screen format 166 (to
be described below in connection with Figs. 8, 12 and 13), and the
names of a Procedure Screen Map (PSMP) and a Procedure Operator
Table (POP) associated with the screen. Screen file 151 further
provides, for each screen indexed in PSCR 152, signals representing
a screen format 166, a POP table 156, a PSMP 15~, and a portion 155
of the For-Display-List.
The POP table 156 for a particular screen format 166 is shown
in more detail in Fig. 10. POP table 156 provides, for each screen
format 166, signals representing information about the operations
that may be selected from keyboard 20 while such screen is
displayed7 these include operations to be performed on the result
relation interactively defined during display of that screen format
as well as other operations such as scrolling of record occurrence
representations and transitions to certain other screen formats.
. , ~
s~
-22-
The table is indexed by the value of a storage element called
FPFkey, to be described, and for each such value, a data structure
called "oper" is provided, giving information regarding the
operation which is selectable by means of a PF key on keyboard 20
in a manner to be explained. "Oper" includes the "oper-name" (text
to be returned to the calling program), the action (or actions) to
be taken, and the screen name of the screen format to be used for
the action, when pertinent. In the POP table for the LIST screen,
there is an "oper" for each of the operations Add, Modi~y, Delete,
and Return. Other screens may have POP tables containing opers for
more or fewer operations. Other operations may also be provided
when the POP table is designed.
The Procedure Screen Map (PSMP) 154 for a particular screen
format 166 contains signals representing a list of the names of
view-fields that are to appear on the display when the screen
format is used to display record occurrences from the database.
This information is used when filling out the For-Display-List
155/174. Further, PSMP 154 for a particular screen format 166
provides a screen limit signal, deEining how many record
occurrences can be displayed at one time on such screen.
Screen formats
Referring now to Fig. 12, each screen-file may contain signals
representing up to six screen formats (shown together as formats
166 in Fig. 6) however, there are only two basic types. The
3L2~ 9
formats are shown schematically in Fig, 12 so that the differences
between the two types can be easily seen. The LIST screen format
400 is adapted to show representations of many record occurrences
from the database target relation, and therefore provides spaces
for the fields of such occurrences, arranged in columns. Fewer
than all fields may be shown. The DISPLAY screen format 402 is
adapted to show a representation of a single record occurrence from
the database target relation, and can show more of the fields of
that record occurrence. The formats of the SELECT screen (404) and
the ADD, MODIFY, and DELETE screens (406) are basically similar to
the formats of the DISPLAY screen, in that representations of the
fields of a single record, or of the names of the fields of a
single record, are shown, with differences to be described.
LIST screen format
LIST screen format 400 is shown in Figs. 8a and b in greater
detail.
Fiq. 8a shows LIST screen format 400 as initially provided in
screen-file 151. The title 300 of the screen is provided, with the
name of the target relation at 310 and fixed text at 302. Below
the fixed text are column headers and empty spaces for the display
of record occurrences. A line 304 divides the screen into upper
and lower portions 306 and 308. Below line 304, in lower portion
308, are displayed the numbers of particular PF keys among the
sixteen keys 204 of keyboard 20 (Fig. 5), together with the name of
~2~i82~
-24-
ENTER key Z06 on keyboard 20. Names of selectable operations are
represeDted in association with the key designations.
It will be observed that not all of the sixteen possible PF keys
are listed in lower portion 308 of the screen format; this is
because only a smaller number of operations are selectable while
the LIST screen is displayed. Amonq those listed is PF key
204-16:Return. Actuation of Key 204-4:Prev causes a previously
displayed screenload of record occurrences in the list to be
redisplayed, still using the present format; actuation of key 204-4
with the shift key causes the first screenload of record
occurrences in the list to be displayed. Actuation of key 204-5
similarly causes the next screenload to be displayed, and actuation
o key 205-5 with the shift key causes the last screenload of
occurrences to be displayed. ~eys 204-4 and Z04-5 thus scroll
portion 306. Actuation of key 204-7 causes SELECT screen format
(described below) to be displayed. Actuation of keys 204-8 and
204-9 cause one or more of the displayed record occurrences,
selected by the user by moving the screen-position-marker, to be
displayed in the DELETE and MODIFY screen formats, to be
described. (If more than one record occurrence has been selected,
they will be displayed sequentially on the selected screen.)
Actuation of key 204-6 causes the ADD screen format (described
below) to be displayed. Actuation of ENTER key 206 (on keyboard
20, Fig. 5) causes a transition to the DISPLAY screen format, in
which an enumerated record occurrence is represented.
259
The displayed key identifiers including PF key numbers and key
names, with corresponding operation names, provide representations
of a plurality of selectable operations, inc:Luding operations
executable with respect to the members of the result relation to be
provided by the relational operator means, as will be described.
In Fig. 8b, the retrieved record occurrences are represented
below the column headers.
Other formats
Referring now to Figs. 13 and 14, the remaining screen formats
are shown in more detail than in Fig. 12.
Fig. 13 shows DISPLAY screen format 402, with representations
o the fields of a single record occurrence. This screen format is
shown in response to actuation of ENTER key 206 (on keyboard 20,
Fig. 5) while the LIST format is displayed. The names of the
fields in the record are given to the left of the values of the
fields. Selectable operations are displayed in lower portion 308
of the format. Actuation oE PF key 204-16 (Return) causes a return
to a view of the LIST screen format. Actuation oE PF keys 204-6
(Add), 204-8 (Delete), and 204-9 (Modify) permits the user to view
the same record occurrence that is displayed in the DISPLAY screen
format, but displayed in one oE formats 406, so that the indicated
operation can be perEormed.
2~
-26-
SELECT screen format 40g, which is shown in response to
actuation of PF key 204-7 while the LIST format is displayed, is
similar in arrangement to format 402, but the values of some or all
of the fields are represented by question marks and blanks. This
screen permits the user to position the screen-position-marker at a
particular field (open element) and to enter a characterizing value
into the field, for the purpose of selecting from the target
relation tnamed at 310) in the database, record occurrences which
have that value in the selected field. More than one field may be
so characterized.
Referring now to Fig. 14, the Update screen formats 406 are
shown. ADD screen format 406-1 is similar to the SELECT screen
format, but in this case, the user must fill in all the Eields
necessary to constitute a new record occurrence to be added to the
target relation (named at 310) of the database. MODIFY screen
format 406-1 is similar to DISPLAY format 402, but the
representations of the values of the fields are shown highlighted
(or otherwise distinguished from the attribute names), to indicate
that the user can modify these values, for the purpose oE modifying
in the database the record occurrence represented on the screen.
DELETE screen format 406-3 is again similar to DISPLAY format 402,
but the selectable operations include "Delete" or "Skip record".
6~59
-27-
Cursor 158
Referring aqain to Fig. 6, signals representing a cursor are
provided in storage at 158, with a pointer @cursor. The particular
cursor represented in storage element 158 may be either provided by
the calling program or derived Erom an initial cursor in a manner
to be described, or otherwise defined. As previously stated, a
cursor is a statement (or an implementation-dependent data
structure derived from such statement) which defines a set of
records to be retrieved from a target relation in the database, and
which identiEies a position within the set during the process of
retrieving the records.
Other data structures
Still referring to Fig. 6, storage for the data structures
Task Common Area (TCOM) 160, QUERY 162, Seen-List 176, ATA8 172,
For-Display-List (part two) 174, DBUSER 173, and FOR 164 is
allocated during operation of data processing system 10, as will be
described. In addition, storage for a System 8uffer 168 is
allocated during operation, as will be described.
Description of proqram modules and interaction with storaqe
WZOPEN DATABASE 104. Data processing system 10 operates under
control of signals representing program element WZOPEN DATABASE
104, called from the calling program, with respect to a particular
~Z~i8~59
-28-
database (named by the parameter $database). The information as
to which database is to be accessed ultimately comes fro~ the user
of the data processing system terminal. Operating according to
module 104, data processing system 10 allocates space in storaqe 17
for the data structure DBUSER 173, which provides signals
representing pointers to lists of descriptors of database records,
files, relationships, and views, and other data pertinent to the
opened database. Such descriptors provide signals for defining the
conceptual records of level 30 (Fig. 2) in terms oE the stored or
internal record occurrences of level 32. Data processing system 10
then allocates in storage 17 space for signals representing the
structure Task Common Area (TCOM) 160, which contains storage for
various pointers to be used in subsequent operation, and in
particular, contains storage for the pointer @for-display-list,
which points to For-Display-List (part two) 174, and the pointer
@dbuser, which points to DBUSER data structure 173.
Apart from the above, the procedure of opening a database so that
record occurrences may be retrieved from it is well understood in
the database management art and will not be particularly described
herein.
WZOPEN SCREEN FILE 106. Data processing system 10 operates
according to signals representing program element WZOPEN SCREEN
FILE 106, called from the calling program, with respect to the
parameter $screen-file (supplied ultimately by the user). The
parameter $screen-file names the particular screen-file 151 to be
- ~L26~Xs9
-29-
accessed. If signals representing the particular screen-file
referred to are not present in main memory 14, data processing
system 10 loads signals representinq PSCR 152 from secondary memory
16 at this time under the control of WZOPEN SCREEN FILE module 106
this operation forms no part of the invention.
DO DSC 107. Operating accordi~g to signals representing the
DO DSC module 107 within the calliny program, data processing
system 10 defines an initial cursor, and places signals
representing it in the data structure CURSOR 158 within storage
17. The cursor is defined against a target comprising at least one
of the relations within the named database. The target may be
either a base table (represented in storage by a distinct stored
file) or a view 5a view is a table [relation] that does not have
any existence in its own right but is instead derived rom one or
more base tables.) DO QUERY 108. The module DO QUERY 108
within the calling program for purposes of the present description
serves only to control data processing system 10 to call WZOPEN
CURSOR module 110 and DOPXI module 112.
OPEN CURSOR. The module WZOPEN CURSOR~@cursor, $qid) 110 is
employed to control data processing system 10 to open the cursor
defined by signals in data structure 158. The procedure of opening
a cursor for the purpose of fetching multiple record occurrences
defined by the cursor is in general well understood in the art of
database management, and will not be described in detail herein.
~ .
i8X~
-30-
In the particular embodiment described herein, data processing
system 10 operating under the control of signals representing
WZOPEN CURSOR module 110 allocates space within storage 17 for the
QUERY data structure 162, corresponding to the cursor pointed to by
@cursor. A single QUERY data structure corresponds to a single
cursor. 9UERY data structure 162 is pointed to by @qry, and
contains signals representing the pointer @sysbuf, which points to
System Puffer 168, pointer @pxiser, which points to the sereen
format to be used during operation aeeording to my relational
operator or to the screen most recently used (to permit returns),
pointer @seen-list, which points to Seen-List 176 (to be
described), and others. Further, QUERY data structure 162 provides
storage for a data element called "oper", a buffer called
List-Buffer, and the data element "source", all of which will be
deseribed in what follows.
Data proeessing system 10 under eontrol of WZOPE~ CURSOR module 110
returns the identifier "qid" for the QVERY. Further operating
under eontrol of WZOPEN CURSOR module 110, data processing system
10 selects an access strategy to be used in retrieving physical
record occurrences from database 150, as defined by the cursor, the
process of selecting an access strategy is well understood in the
database management art and will not be described herein.
DO PXI 112. Operating under the control of signals
representing the module DO QUERY 108, data processing system 10
calls DOPXI(screen~) module 112, and aEter performing certain
operations not pertinent herein, calls WZPXI($screen-file, screen~,
~68~j9
-31-
$qid) module 114. "$screen-file" is a parameter which names the
screen-file to be referred to; "screen~" is an index to the
particular screen format within the screen-Eile. As stated in
connection with Screen-File 151, the name of the initial screen to
be accessed is provided by the calling program, and signals
representing the name are stored in "initial-screen" within PD~F
153 in Screen-File 151. Names of screens accessed in subsequent
operations are provided in a way to be described in what follows.
As noted above, "qid" is the identifier for the QUERY. Operation
according to WZPXI will be described below: it returns a value by
placing signals representing such value within data structure ATAB
172 (Fig. 6). This value represents one of the operations Add,
Modify, Delete, or Return~ other operations may also be provided.
In addition, WZPXI may return signals representing the characters
of "oper-name" within the storage element 170 pointed to by
$oper-name; this pointer is supplied by the calling program if
desired. Either or both of the values in ATAB 172 and the
characters comprising "oper-name" are available to the calling
program for further testing; they may be used in different
circumstances, not pertinent herein.
Upon return from WZPXI, data processing system 10 under the
control of DOPXI tests the signals representing the value returned
from WZPXI within data structure ATAB 172. For the actions Add,
Modify, or Delete, data processing system 10 under control of DOPXI
calls appropriate program modules (shown as DO UPDATE module 126
and WZINSERT, DELETE, MODIFY module 115 called by module 126) in
order to carry out the indicated operation.
L268~
-32-
WZPXI 114. Under the control of module WZPXI($screen-file,
screen~, $qid) (114) data processing system 10 tests the signals
representing the screen type (mode indicator) of the screen pointed
to by "initial screen" in PDEF 153 ~for the first iteration of
WZPXI) or the screen type of the screen pointed to by qry.@pxiscr
(for subsequent iterations).
Ignoring for the moment the possibility that the screen type
is SELECT (which will be discussed below), if the screen type is
either LIST or DISPLAY, module WZDISP 124 is called. Operation
according to WZDISP module 124 will be described below; during such
operation, representations of one or more record occurrences
defined by the cursor are displayed in either the DISPLAY (one
occurrence) or the LIST (multiple occurrences) screen formats.
When such operation is completed, signals have been placed in
qry.oper representing an operation selected by actuation of a PF
key by the terminal user.
When data processing system 10 returns from WZDISP module 124,
operating further according to WZPXI module 114, it tests the
signals stored in the storage element qry.action (within
qry.oper). Certain actions (including a transition to a SELECT
screen, discussed below) may be executed by data processing system
10 operating further according to WZPXI module 114: such operation
includes resetting qry.@pxiscr and qry.pxiscr~ to keep track of the
transition. Otherwise, data processing system 10 operating further
according to WZPXI module 114 copies signals representing
~1.2~S9
-33-
qry.oper-name (within qry.oper) from QUERY data structure 16Z to
the location 170 pointed to by $oper-name, places signals
representing the action into ATA8 172, sets qry.source to indicate
either selection through the DISPLAY screen, selection through the
LIST screen Erom the cursor, selection through the LIST screen by
the marked screen list, or selection through the SELECT screen.
The operation represented by signals in $oper-name and ATAB 172 may
be Add, Modify, Delete, or Return. (The possibility that the
operation is Select will be discussed below.)
WZDISP 124. Operating according to WZDISP module 12~ with
respect to the parameters $qid and $starting-lr# (lr~ = list
record number, stored in qry.List-Buffer~ the starting-lr~ is
provided by WZPXI based on the screen state), data processing
system 10 calls WZSCRLOD($qid, @scr) module 116 to complete the
For-Display-List, as will be described, and then calls
WZRETRIEVE(qry.source) module 11~3 to obtain a record occurrence to
be displayed. Operation according to WZRETRIEVE will be described
below. For the LIST screen, WZRETRIEVE is called repeatedly;
record occurrences are retrieved one at a time until either a full
screenload has been retrieved (as defined by the screen limit
signal in the PSMP 15~ for the screen), or there are no more record
occurrences to be retrieved, that is, all those defined ~y the
cursor have been retrieved. As each record occurrence is
retrieved, signals representing its key are placed in Seen-List 176.
-' ~6B~9
-34-
Upon return from WZRETRIEVE module 118, further operating
according to WZDISP module 124, data processing system 10 calls
WZSCRIO module 120 to cause representations of the retrieved record
occurrences to be displayed. Operation according to WZSCRIO will
be described below. Upon return from WZSCRIO module 120, data
processing system 10 operating further according to WZDISP module
124 tests the signals stored in qry.action (within qry.oper).
If the action is a transition from DISPLAY to LIST format
(selected by actuation of PF key 204-16:Return on DISPLAY format
402, Fig. 13) or from LIST to DISPLAY format (selected by actuation
of ENTER key 206 on keyboard 20, LIST format, Fig. 8), data
processing system 10 resets qry.@pxiscr and @scr to point to the
new screen; the index qry.pxiscr~ is used to keep track of
transitions between screen formats. For such a transition
operation, operating then further according to WZDISP and modules
called therefrom, responsive to the screen-type of the screen
format indicated by the reset pointers, data processing system 10
displays representations of the retrieved record occurrence or
occurrences in the appropriate screen ~ormat.
IE the action in qry.action is Next, Previous,`First, or Last,
the indicated scrolling operation is carried out by data processing
system 10 while operating according to WZDISP module 124. Next or
Previous causes the next or previous screenload of representations
oE record occurrences to be displayed, First or Last causes the
first or last screenload to be displayed. If a previous screenload
~;~6~3~59
;s to be displayed, the record occurrences are found using the keys
stored in Seen-List 176; otherwise record occurrences must be
retrieved using the QUERY data structure 162. These operations
result in scrolling the displayed list of record occurrences.
It will be evident that the user can select unlimited
successive operations of scrolling or transition between LIST and
DISPLAY screen formats without causing data processing system 10 to
return from WZDISP module 124. The PF key Return causes a return
to the previously displayed screen format, if any (as indicated by
qry.pxiscr~), or else a return to the calling program.
WZSCRLOD 116. Operating according to WZSCRLOD($qid, @scr)
module 116, data processing system 10 accesses the appropriate POP
table 156 and PSMP 154 for the particular screen format 166 pointed
to by @scr, and fills out the right hand portion of the
For-Display-List. Referring now to Fig. 15, the left hand portion
of the For-Display-List is provided by data structure 155 within
Screen-File 151: for each view field to be displayed on the screen,
the location (row and column on screen), the length, and other
appropriate information is provided. The right hand portion is
provided by data structure 174; for each view field, the memory
location, length, type, and other appropriate information about the
record occurrence is provided. Portion 174 thus provides the
addresses of record occurrences to be displayed; for a L~ST screen
format, these addresses are to the qry.List-~uffer, while for a
DISPLAY screen format the addresses are to System Puffer 168.
,
~12~8~s~
-36-
Display of representations of attribute names as headers 303, view
name as view title 310, the appropriate PF keys 204 for the
operations selectable during display of the particular screen
format 166, and other information is provided for by screen format
166.
WZRETRIEVE 118. Operating according to WZRETRIEVE(qry.source)
module 118, data processing system 10, taking into account the
signals in qry.source, calls access method 102 of operating system
100. Access method 102 is responsive to signals provided by data
processing system 10 operating according to WZRETRIEVE module 118
to cause data processing system 10 to retrieve from the target
within the named database 150 one record occurrence specified by
the cursor and to store signals representing the retrieved record
occurrence in System Buffer 168.
For the LIST screen (which displays a plurality of record
occurrences), since System Buffer 168 holds only one record
occurrence, signals representing the retrieved occurrences are
copied to qry.List-Buffer by data processing system 10 operating
according to WZDISP module 124. WZRETRIEVE is repeatedly executed
until there are no more record occurrences defined by the cursor,
or until enough record occurrences have been retrieved to fill the
screen, as defined by the screen limit indicator in PSMP 154.
WZSCRIO. Operatinq according to WZSCRIO(~qry = $qid, ~scr)
module 120, data processing system 10 calls
-" ~L2~i8~9
-37-
WZFORMS(@for-display-list) module 122 to merge the record
occurrences pointed to by the For-Display-List (Fig. 15) with the
screen format pointed to by @scr, for display to the user. The
operation of data processing system 10 according to WZFORMS will be
described below; when such operation is complete, signals have been
placed in for.fpf-key, and the stored screen image may have been
modified corresponding to user input signals. Upon return from
WZFORMS, operating further according to WZSCRIO, data processing
system 10 uses the signals stored in for.fpf-key (as will be
described) as an index to the signals within the POP table data
structure 156 for the screen that has been displayed, and copies
therefrom signals representing the element "oper", containing
"oper-name" and "action", corresponding to the PFkey number, into
the storage element qry.oper within QUERY data structure 162.
The signals stored in qry.oper are output signals of the
relational operator means, representative of the operation selected
by the user.
Further operating according to WZSCRIO module 120, data
processing system 10 modifies Seen-List 176 by marking records (by
setting a flag in the "Mark" column of the list, as seen in Fig.
11) that have been enumerated by the terminal user, as will be
described. Processing system 10 returns from WZSCRIO module 120 to
WZDISP module 124.
i8;~S~
-38-
WZFORMS 122. Under control of WZFORMS(@for-display-list,
@scr) module 122, data processing system 10 uses the signals
representing the addresses in For-Display-List 155/174 to obtain
the record occurrence signals from the addressed buffer, and to
merge them with the predefined display format signals of
Screen-File 151 in order to modify screen format 166 and thereby to
deEine a resultant stored screen image. For the LIST screen, the
record occurrence signals are taken from qry.List-Buffer: for the
DISPLAY screen a single record occurrence is taken from System
Buffer 168.
Further under control of WZFORMS 122, the data processing
system calls Operating System program 100, and operates according
to the display control signals therein to control display 18 to
display a representation of the resultant screen image stored at
166. Further, during this display, the data processing system
enables keyboard 20. The user of the console or terminal may use
keyboard 20 to provide input signals.
If on the LIST screen the screen-position-marker is positioned
by the user next to the representation of a particular record
occurrence, and a PF key 204 is actuated, by default that record
occurrence is taken to be enumerated. Alternatively, the user may
enter an "X" or other character next to one or more record
occurrences to enumerate them.
The keyboard signals provided by the user are interpreted by
the data processing system, operating according to operating system
i8;~5~
-39-
100, to modify the stored screen image. A signal corresponding to
the actuated PF key is also stored. After return from WZFORMS,
data processing system 10, under the control of WZSCRIO and WZDISP,
interprets the user's input keyboard signals as enumerating
signals, effecting enumeration of certain of the retrieved record
occurrences whose representations are displayed, and operation
selection signals, effecting selection of one of the plurality of
selectable operations. Selectable operations are defined for each
screen format, but always include Return.
Further operating according to WZFORMS module 122, the data
processing system copies the stored signals representing the PF key
number to the data storage element for.fpf-key within FOR data
structure 164.
When the PF key signals have been copied to Eor.fpf-key, the
data processing system returns from the module WZFORMS 122 to the
module WZSCRIO 120.
Operation.
In operation according to the signals representing the modules
and data structures that have been described, the user of the data
processing system terminal selects a database to be accessed and a
screen file to be used for the purpose (defined for a particular
base table or view). This may be done interactively through the
keyboard, or by a calling program. The database 150 and screen
2~8;~5~
-40-
file 151 are opened by data processing system 10, which allocates
storage space for the DBUSER data structure 173 and TCOM data
structure 160. The user formulates a query to the database,
repr~sented by a cursor. Data processing system 10 opens the
cursor and allocates storage for QUERY data structure 162,
determines the strategy for obtaining record occurrences Erom
database 150, and defines qid.
Operating according to WZPXI with a LIST screen format indexed
by screen~, data processing system 10 calls W2DISP(qid) module
124. Operating according to WZDISP, data processing system 10
calls WZRETRIEVE(qry.source) which then calls access method 102
within operating system 100, to retrieve from the target signals
representing a record occurrence defined by the cursor, and to
store them in System Buffer 168. For a LIST screen, multiple
record occurrences are retrieved and their signals are stored in
qry.List-8uffer.
Upon return from WZRETRIEVE, data processing system 10 calls
WZSCRLOD module 116 to complete For-Display-List 155/174, and then
calls WZSCRIO module 120; operating according to this module data
processing system 10 calls WZFORMS module 122. Operating according
to WZFORMS, data processing system 10 uses the address signals in
For-Display-List 155/174 to merge the predefined display format
signals from LIST screen format 400 stored at 166 within
screen-file 151 with the retrieved record occurrence signals stored
" ~Z6~9
-41-
in qry.List-Buffer, in order to modify the LIST screen format and
thereby to define a resultant stored screen image.
Operating according to operating system 100, data processing
system 10 then controls display 18 to display a representation of
the defined resultant screen image. During this display, system 10
enables keyboard 20. The user may use keyboard 20 to provide
enumerating signals, effecting enumeration of certain of the
retrieved record occurrences whose representations are displayed;
further, by actuating a PF key, the user provides operation
selection signals, effecting selection of one of the plurality of
selectable operations displayed on the LIST screen.
When a PF key has been actuated, assuming that some records
have been enumerated, the data processing system 10 operates
according to operating system 100 to modify the defined screen
image to correspond with the user's input signals. Further, data
processing system 10 causes signals representing the number of the
actuated PF key to be stored.
Further operating according to WZFORMS module 122, data
processing system 10 copies the PF key signals to the data storage
element for.Epf-key within FOR data structure 164. Upon return
from WZFORMS, operating further according to WZSCRIO module 120,
data processing system 10 uses the signals stored in for.fpf-key as
an index to the POP table data structure 156 corresponding to the
LIST screen, and copies therefrom the signals of the "oper"
. .
~2~
-42-
corresponding to the actuated PF key into the storage element
qry.oper within QUERY data structure 162. The signals in
qry.oper-action are output signals of the relational operator
means, representative of the operation selected by the user.
Further operating according to WZSCRIO module 120, data processing
system 10 sets mark flags within Seen-list 17~ to mark enumerated
records as indicated in the modified screen image.
Upon return from WZSCRIO, further operating according to
WZDISP module 124, data processing system 10 tests the signals
stored within qry.oper-action. If the action is Next, Prev, First,
Last, Return (from Display to List) or Display, system 10 can
execute the selected operation while operating according to WZDISP
module 124. These actions can be selected as frequently as the
user desires, and in any sequence, in order to allow the user to
obtain a display of desired record occurrences before enumerating a
set and performing operations such as Modify and Delete on the
selected occurrences.
If the action is not one of Next, Previous, First, Last,
Return to LIST from DISPLAY, or DISPLAY from LIST, data processing
system 10 returns to WZPXI module 114. If the action is Modify,
Delete or Add, (or other action defined in the POP table but not
described herein), WZPXI module 114 returns to the calling program
to interpret the action. The specific calling program shown in the
present embodiment calls modules 126 and 115 in order to execute
~2~8259
-~3_
the Modify, Delete and Add operations, with the appropriate screen
formats from screen-file 151.
If the user enumerates more than one record occurrence on a
LIST screen, and then actuates a PF key selecting Delete or Modify,
a representation of each enumerated record in turn will be
displayed on the indicated screen until all have been displayed.
As a result of the operation that has been described, there is
provided an enumerated relation, derived interactively from the
initial cursor provided by the calling program in accordance with
the user's enumerating signals input through keyboard 20. The
enumerated relation (of one member) can be defined by the user
through the LIST screen, as has been described, by positioning the
screen-position-marker next to the representation of a record
occurrence and actuating a PF key, alternatively, the enumerated
relation (of one or more members) can be defined by entering a
character next to one or more record occurrence representation and
actuating a PF key. Finally, the actuation of a PF key by the user
while the DISPLAY screen is displayed results in defining an
enumerated relation comprising the single record occurrence that is
displayed. Further, there is provided an output signal
representative of an operation selected by the user from the
displayed selectable operations. In all these cases, the
enumerated relation is specified by signals representing a
"modified cursor" comprising the enumerating marks in the
Seen-List. Further operation according to the calling program,
- ~26~X~3
-44-
which receives signals representing the "modified cursor" and the
selected operation, is thus independent of the manner in which the
enumeration was accomplished.
SELECT screen
In addition to the means for defining an enumerated result
relation, according to my invention there is provided means for
interactively defining a characteristically defined result
relation, that is, a relation, membership in which is defined in
terms of record occurrence attributes that are explicitly defined
and present in the database target. This is accomplished by means
of SELECT screen format 404 and WZSELECT module 128, together with
elements already described.
Referring now again to Fig. 7, signals representing a further
program module, WZSELECT 128, are provided in the program portion
of storage 17 within data processing system 10. When data
processing system 10 operates according to WZPXI module 114, as has
been described, it tests the signals representing the screen-type
(mode indicator) of the screen indexed by screen~ within
Screen-File 151 (indicated 'oy qry.@pxiscr). If the screen is a
SELECT screen, WZPXI calls WZSELECT module 128. Qry.@pxiscr is set
to indicate a SELECT screen during operation according to WZDISP
module 124, if the user actuates PF key 204-7 while the LIST screen
is displayed. WZPXI uses the value of qry.pxiscr~ to keep track of
1~i8~59
transitions between the SELECT screen and the LIST/DISPLAY
screens.
Data processing system 10 operates according to WZSELECT
module 128 with respect to the signals representing input
parameters @qry and @cursor, and calls WZSCRIO module 120 to
display SELECT screen format 404 (Fig. 13). The format includes
the names of the target relation and view-fields for the target
relation.
Operating according to WZSCRIO module 120, data processing
system 10 calls WZFORMS module 12Z, and operates in accordance
therewith in the manner that has been described, to display a
representation of the SELECT screen format 404, including the
target view name at 310 and the view-field names in portion 306.
The view name and view-field names are generic elements. Any value
of an attribute (field) that was previously made part of the
cursor, as a search criterion, is represented on the SELECT screen
next to the field name; the remaining fields are shown blank.
The fields, whether blank or displaying previously entered
search criteria, are open elements, that is, the user can enter
characteriæing elements into the open elements. The user can
position the screen-position-marker to a desired field, and can
enter a value into that field using the typewriter keys 200 oE
keyboard 20 (Fig. 5) to provide characterizing signals. ~he
display will be altered accordingly. This can be done to more than
8'~59
-46-
one of the displayed fields, if desired. The characterizing values
entered by the user into the open elements provide new search
criteria, further refining or characterizing the cursor with
respect to the attributes of the record occurrences in the target
relation of the named database.
Finally the user actuates one of the PF keys corresponding to
the displayed selectable operations. Selectable operations on the
SELECT screen include List, Delete and Modify. Signals
representing the actuated PF key are stored in for.fpf-key in the
manner previously described, and data processing system 10,
operating according to WZSCRIO module 120 in the manner previously
described, copies the POP.oper signals for the actuated key to
qry.oper.
However, operating further according to WZSELECT module 128,
data processing system 10 derives a new cursor by modifying the
signals of the CURSOR data structure 158 to reflect the
characterizing values entered by the user into the displayed view
fields. Data processing system 10 then closes the original cursor
(by calling and operating according to an appropriate module, not
shown, but conventional in design) and then calls WZOPEN CURSOR
module 110. Operating according to the signals of module 110, data
processing system 10 allocates storage for a new QUERY data
structure 162, corresponding to the new (modified old) cursor.
Data processing system 10 then returns from WZSELECT module 128 to
~2~8~59
-47-
WZPXI module 114. Data processing system 10 sets qry.source to
reflect the screen type pointed to by qry;@pxiscr.
The result of the operation according to the WZSELECT module
is that there is interactively provided a result relation, defined
characteristically, that is, in terms of attributes represented
explicitly in the record occurrences within the target relation of
the database. Further, there are provided output signals
representative of an operation selected by the user from the
displayed selectable operations, including operations performable
by data processing system 10 on the result relation.
If the actuated PF key selected the LIST operation, WZPXI,
responsive to the screen-type of the LIST screen, will call WZDISP
module 124 in the manner previously described, for the display on
the LIST screen of the record occurrences defined by the redefined
cursor. The user can now enumeratively define a relation, derived
from the redefined cursor. If the actuated PF key selected either
Delete or Modify, representations of the record occurrences
specified by the redefined cursor will be displayed sequentially on
the appropriate screen, permitting such action to be taken by the
user with respect to each record occurrence in the database.
In preferred embodiments, the relational operator means of my
invention comprises means for providing an output signal
representative of an operation selected from a plurality of
selectable operations displayed to the user, together both with
means for providing a result relation, membership in which is
- ~268~59
-48-
defined enumeratively and interactively through the keyboard, and
with means for providing a result relation, membership in which is
defined characteristically and interactively through the keyboard.
However, either means for providing a result relation may be
provided without the other, and considerable advantages in the
interactive maintenance of relational databases may be realized
thereby.
If means to define both enumeratively and characteristically
defined result relations are to be provided, then the WZPXI module
114 must provide signals representing instructions of the following
general form tthe terminology is not that of any standard
programminq language):
set pxi-handled-action = yes
loop while pxi-handled-action = yes:
test screen type of screen pointed to by
gry.@pxiscr
if type is SELECT, call WZSELECT
(that will set gry.action)
if type is DISPLAY or LIST, call WZDISP
(that will set qry.action)
test qry.action
if action is Select, List or Display,
get the appropriate screen (and loop)
else if action is other,
set pxi-handled-action = no, (exit loop)
return to DOQUERY.
~68~5~
-49-
Operating according to the calling program which has called
the modules described herein for the operation oE my relational
operator means, data processing system 10 can obtain signals
representing the selected PF key operation from $oper-name. Such
signals are also provided in ATAB data structure 172. (The signals
are provided in two forms for reasons not pertinent to the present
description.) Data processing system lO can then proceed with
further operation as controlled by the calling program.
The relational operator means has provided a result relation,
derived interactively from the initial cursor provided by the
calling program in accordance with the user's signals input through
keyboard 20. The result relation may be either an enumeratively
defined relation, specified by a "modified cursor" comprising the
enumerating signals (represented as the marks in Seen-List 176,
Fig. ll) or a characteristically defined relation, defined by the
modified cursor signals in CURSOR data structure 158.
In either case, the interactively defined result relation has
the characteristics of a relation as defined in the context of
relational databases, that is, further operations, designed and
built for use on relations, can be carried out on the result
relation. In particular, the records of the result relation can be J
retrieved under the control of modules designed for the retrieval
of records in a relation. Moreover, the result relation can be
operated on by the calling program in any desired manner without
regard to the specific way in which it was defined, making the
calling program independent of the physical structure that was used
, .
~68~5~3
so
(keyboard, touch screen, or the like), as well as independent of
whether the result relation was enumeratively or characteristically
defined. This provides great flexibility in the use of such result
relations.
Referring now to Fig. 9, my relational operator means is shown
conceptually as a "black box". The inputs to the black box are the
cursor signals, provided, as has been described, by the calling
program (or defined by WZSELECT module 128 in the particular case
when the initial screen is a SELECT screen, as has been described),
and display format signals, which have been predefined and stored
in Screen-File 151. The signals from keyboard 20 are further input
to the black box, which produces output signals representing a
result relation, together with a selected operation (selected from
among those presented to the user for selection by PF key
actuation). The signals representing the result relation are
stored in CURSOR data structure 158, and also ;n Seen-List 176 (for
the enumeratively defined result relation)~ the signals
representing the selected operation are stored in data structures
ATAB 172 and $oper-name 170.
Since the relational operator means of my invention in effect
operates to transform an input relation (defined by the cursor)
into a result relation, this operator means is closely analogous to
the well known relational operators, defined for operation on the
tables of relational databases, namely PROJECT, SELECT and JOIN.
(Other relational operators have also been defined by various
26~3X59
writers.) A necessary characteristic of a relational operator is
that it operate on a relation to produce another relation, which
can itself be operated on by a relational operator. This
characteristic is otherwise expressed (in mathematical terms) as
the statement that the set of possible relations is closed under
the operation of a relational operator. Note that the result
relation need not be a physical or base table within the database,
but it must conform with the definition of a relation.
The operator means of my invention complies with this
requirement, and thus can be regarded as a relational operator.
This feature of the operator means makes it possible to employ this
means as part of a sequence of relational operators. Further, it
makes it possible to fetch from the database the records of the
result relation, using the same operation that is used to fetch
records of any relation defined in the usual way by a cursor. This
provides economy of programming and simplicity of operation.
However, each standard operator, when applied to a relation,
implicitly defines a result or product relation, membership in
which is determined by the value of one of the attributes of the
records within the initial relation defined by the cursor. That
is, membership in the result relation is defined
"characteristically", by means of a characteristic or attribute oE
the records that is explicitly present in the database. For
example, it is possible to SELECT from a table of customers those
`` ~L21~i8Z~9
-52-
customers having green hair, only if hair color has been defined as
an attribute Eor that relation.
In contrast, my relational operator means provides for the
definition of a result relation, membership in which is defined
"enumeratively", that is, by means of enumeration by the user
through the keyboard, and such membership may therefore be
independent of the record occurrence attributes explicitly defined
and present in the stored database, but may depend on some aspect
of the entity underlying the record, perhaps known only to the
user.
Therefore, my novel operator means makes it possible to
construct interactively an arbitrary set, enumerated by the user,
and thereafter to treat the set as a member of the class of
relations, with all the advantages of data manipulation which
result from this. In prior art data management systems, a table of
enumerated members could be built, but only by explicit programming
(in the applications program) designed for such purpose, and the
constructed table could not then be treated as a member of the set
of relations. Consequently, for example, the records could not be
fetched using the same operation that is used to fetch records in
the relations: rather, an additional program module had to be
provided for this purpose.
My oeerator means further provides for the interactive
definition of a result relation, membership in which is defined
~268259
-53- 70840-60
characteris-tically in terms of a record occurrence attribute
explicitl~ defined and present in the database; sueh interactive
definition is thereby made much simpler than has been possible
using prior art means.
A particular embodiment of the present invention eom-
prises particular data structure definitions and program modules,
running on a Wang VS-100 (virtual storage) eomputer.
... . ... . . .
~L268259
--54--
--END OF INSERT A--
.
~..
68259
-55-
--INSERT B--
RETRIEVAL OF RELATED RECORDS
FROM A RELATIONAL DATABASE
My invention relates to the operation of data processing
systems, in particular to means for the management of relational
databases stored in the memory of such systems. The invention
further relates to means to facilitate the interactive use and
updating of such databases.
BACRGROUND OF THE INVENTION
My invention is employed in a data processing system having
one or more terminals or consoles which provide display means and
input signal means such as a keyboard, and providing in storage
physical records modeled as one or more relational databases.
Among the individual ultimate users of the data processing
system and database are some users, such as clerks and managers,
who are not programmers. Such users wish to be able to use the
system terminals to view representations of the records stored in
the database, to select specific records or parts of records to
view, to delete or modify physical records in th0 database, or to
add new physical records to the database. For these purposes the
physical records must be selected, accessed in the physical
storage, and retrieved (copied), and representations of the
~:6~3~59
-56-
retrieved records must be displayed to the user at one of the
terminals in some predetermined display format.
To permit this use of the stored database, there must be
provided in the data processing system stored coded instruction
signals which when used to control the data processing system cause
representations of the physical records, as well as representations
of signals input by the user through the keyboard, to be displayed
in a particular format on the display. Further, there must be
provided instruction signals which when used to control the data
processing system cause the interpretation of the signals input by
the user, and which cause the retrieval and modification of the
physical records of the stored database in response to such input
signals.
Such instructions, designed for a particular use of a
particular database, together comprise one of a class of programs
known as "database application programs", that is, programs used by
the ultimate user of the data processing system to carry out the
application desired by him on a particular stored physical database.
There may be (and typically are) many databases stored in the
data processing system, containing physical records representing
information of various kinds. For example, there may be a
personnel database containing information on employees, such as
their names, departments, salaries, skills, employment history, and
the like, with related information about the departments in which
the employees work. There may be a sales database containing
:1 2~8~
information about the company's customers and their orders to the
company, with datss, prices, and payment history; there may be a
procurement database containing information about the company's
suppliers and the items supplied by them, with quantities and
information about their use in products.
For each such database, there may be several distlnct users;
each user may be concerned with only a portion of the information
in the particular database.
Generally speaking, several distinct application programs must
be provided to enable such users to access and use each database.
Each additional database generally requires a further plurality of
distinct application programs. Creation of an application program
typically requires weeks or months of effort by a professional
applications programmer, followed by additional weeks to detect and
eliminate errors in the program so that it becomes reliable and
relatively error-free in use.
It will be evident that the provision of the applications
programs is a significant element in the cost of maintaining a
database. It would therefore be desirable to provide means for
creating such programs in a simple, rapid and inexpensive manner.
Furthermore, when such programs are created by professional
programmers who will not themselves be the ultimate users of the
program and the database, frequently the programmers have an
imperfect understanding of the purposes of the ultimate users, and
~6~5~
-59-
the resultant application program is not as well suited to the
users' needs as could be wished. It would be desirable to permit
the users themselves to create the application program, which could
then be closely fitted to their purposes. Since most such users
are not programmers, this has not hitherto been easy to accomplish.
A particularly burdensome and time-consuming aspect of the
creation of such application programs has been the provision of
means permitting the user of the database to make a transition from
viewing members of a particular set of record occurrences to
v;ewing members of a related set of record occurrences. (The
nature of the relationship is explained in more detail herein.)
This transition is one which is frequently desired in an
application program. It would be desirable to provide simple and
economical means permitting such transitions.
It is therefore an object of my invention to provide means for
creating such application programs in a simple, rapid and
inexpensive manner, interactively and nonprocedurally. It is a
further object to provide means for permitting the database users
themselves to create the application program. It is another object
to provide in such an application program simple and eco~omical
means permitting the user of the database to make a transition from
viewing members of a first set of records to viewing members of a
related set of records.
~8259
-59-
BRIEF DESCRIPTION OF THE INVENTION
A method of retrieving from a destination relation in a stored
relational database, signals representing record occurrences
related to a record occurrence of a starting relation, comprises
the steps: providing, for a relationship between particular
relations in the database, stored signals representing relationship
attributes including a specification of a relationship field common
to the particular relations: accessing, responsive to selection of
a starting particular relation and a relationship in which the
starting relation participates, the stored relationship attribute
signals; generating, responsive to the relationship attributes,
generic cursor signals representing a generic cursor defined
against the other particular relation as a destination relation:
storing the yeneric cursor signals in working storage~ copying,
responsive to a signal representing selection by an operator of a
particular record occurrence in the starting relation and to an
operation selection signal from the operator, values of the
speciEied relationship field from the particular record occurrence
to locations in the generic cursor to form a completed cursor;
accessing in the stored database, responsive to the completed
cursor, destination relation record occurrence signals defined by
the completed cursor, and storing the accessed destination relation
record occurrence signals in working storage.
In preferred embodiments, the method comprises the further
step of displaying representations of the stored destination
68~59
-60-
relation record occurrence signals together with representations of
a plurality of selectable operations performable with respect to
destination relation record occurrences.
According to another aspect of my invention, there is provided
record retrieval means for retrieving from a destination relation
in a stored relational database, signals representing record
occurrences related to a record occurrence of a starting relation.
The means comprise storage means for providing, for a relationship
between particular relations in the database, stored attribute
signals representing relationship attributes including a
specification of a relationship field common to the particular
relations, and means for accessing, responsive to selection of a
starting particular relation and a relationship in which the
starting relation participates, the stored relationship attribute
signals.
The record retrieval means further comprises means for
generating, responsive to the relationship attributes, qeneric
cursor signals representing a generic cursor defined against the
other particular relation as a destination relation, means for
storing the generic cursor signals in working storage, and means
for copying, responsive to a signal representing selection by an
operator of a particular record occurrence in the starting relation
and to an operation selection signal from the operator, values of
the specified relationship field from said particular record
occurrence to locations in the generic cursor to form a completed
,~
~268259
-61-
cursor. Further, the record retrieval means comprises means for
accessing in the stored database, responsive to the completed
cursor, destination relation record occurrence signals defined by
the completed cursor, and means for storing the accessed
destination relation record occurrence signals in working storage.
In preferred embodiments, the storage means further provides,
for a relation in the database, stored descriptor signals
comprising a relation name, and a relationship identiEier signal
for each relationship in which the relation participates, the
relationship identiEier signal being an index to the stored
attribute signals Eor the corresponding relationship. The stored
attribute signals further comprise name signals representing names
of the particular relations related by the relationship.
The record retrieval means further comprises means for
controlling an initial display of names of relations in the
database, means for accessing, responsive to operator selection of
a starting relation name during the initial display, a
corresponding relationship identifier siqnal in the descriptor
signals, the means for accessing the stored relationship attribute
signals being responsive to the accessed relationship identifier
signal for accessing appropriate stored relationship attribute
signals. The record retrieval means Eurther comprises means for
controlling a next display, responsive to the accessed attribute
signals, of a representation of the name of a particular relation
related to the starting relation, means for deriving, responsive to
~68~59
-62-
operator selection of a represented particular relation name as a
destination relation during the next display, the attribute
identifier for the relationship between the starting and
destination relations; and means for accessing the relationship
attribute signals, responsive to the derived attribute identifer,
the means for generating being responsive to the accessed attribute
signals.
Further, in preferred embodiments, the storage means further
provides stored format signals representing a modiiable run-time
display format Eor display of representations-of selectable
starting relation record occurrences, and of selectable operation
names, and provides associated stored control siynals for each
selectable operation. The stored attribute signals Eurther
comprise a name of the relationship. The record retrieval means
further comprises means for modiying, responsive to the operator
selection of a starting relation during the next display, the
stored format signals to represent an additional selectable
operation identified by the relationship name. The record
retrieval means further comprises means or generating,
responsive to the operator selection of a destination relation,
control signals associated with the additional selectable operation
and comprising a cursor index to the stored generic cursor signals;
and means for storing the generated control signals. The means for
copying is responsive during display according to the run-time
ormat signals to operator selection of a starting relation record
.. , ,~ . ~ .
8~59
-63- 7084~ 60
occurrence and of the relationship name, to access the cursor
index.
Further, in preferred embodiments, the s-tored attribute
signals further comprises status specification signals specify-
ing parent or child relationship status of each particular
relation related by the relationship, and representations of an
ascend relationship name and a descend relationship name; and
name selection means responsive to the status specification sig-
nals for accessing the relationship ascend name for display with
record occurrences of a starting relation having relationship
child status, and for accessing the relationship descend name
for display with record occurrences of a starting relation hav-
ing relationship parent status. The means for modifying the
stored format signals is responsive to the name selection means.
The invention referred to above will now be described
in more detail with reference to Figures 1, 5 and 16 - 26 of
the drawings.
12~X59
~ -64- 70840-60D
DETAILRD DESCRIPTION OF THE INVENTION
Data processinq system generally. Referring now to the
drawing, and in particular to Fig. 1, the data processing system 10
has a processor 12, having a main memory 14. Secondary memory 16
is provided in the form of one or more disks. Main memory 14 and
secondary memory 16 together comprise storage 17. The description
of tha present invention does not concern itself with details of
moving signals representing portions of programs or data between
main memory and secondary memory, as that is well understood in the
art of managing data processing systems and the present invention
does not pertain to it. It is assumed that signals in all parts of
storage 17 are available to processor 12.
One or more terminals or consoles, connected to processor 12,
each provides a CRT screen as a display means 18 and a keyboard as
signal input means Z0. Other signal input means, such as mice,
touch screen, voice actuation, and the like, are contemplated by my
invention. If my invention is practiced in a large data processing
system, there may be additional processors within the system, such
as input/output processors, and the operations referred to herein
as performed by the "processor" may in fact be divided among such
processors. Such details do not affect the scope of the invention.
Keyboard and PF ke~s. Referring now to Fig. 5, keyboard 20
provides the usual keys of a typewriter keyboard, indicated
generally at 200, with space bar 202. At the top of keyboard 20
~8~59
-65- 70840-60D
are 16 keys 204, arranged in groups of four: these are called PF
(programmed function) keys. Each is assigned a number from one to
sixteen, and displays its assigned number. With the use of the
shit key, these keys provide thirty-two possible programmed
functions. In addition keyboard 20 provides an Enter key 206 and a
pad of screen-position-marker control keys 208. (The
screen-position-marker is more usually called a "cursor", but that
term will not be used for this element in the present description,
in order to avoid confusion with the "cursor" used in fetching
multiple records from a relational database.)
Storane 17. In the description which follows, and in the
description of my copending application, which is incorporated
herein by reference, the convention is observed that words
beginning with "@" are names of pointers to data structures or to
elements within storage 17: that words beginning with "$" are names
of parameters for particular program elements, and that words
ending with "~" are names of indexes to elements within lists or
sets in data structures. Elements within a data structure are
named by words beginning with the data structure name ~or an
abbreviation thereof), followed by a period: e.g. "qry.source" is a
storage element tor in some cases the signals stored in such
storage element) named "source" and located within data structure
"OUERY". Words beginning with "DO" are names of modules within the
calling program: words beginning with "WZ" are names of external
procedures called by the calling program.
1~682S~
-66- 70840-60D
Storage 17 of data process;ng system lO is regarded
conceptually as divided into program storage and data storage.
In the program storage portion o storage 17 tFig. 17) there
are provided signals representing an operating system 100, which
forms no part of the invention and may be Oe any desired design,
but which must provide means suitable for controlling system lO to
read and write (obtain signals from, or place signals into) storage
17, and an access method 102 suitable eor controlling data
processing system 10 to retrieve record occurrences rom the
database in storage 17, to modify or delete record occurrences in
the database, and to add new records to the database. In addition,
operating system 100 must include program for the control of
display 18 and keyboard 20, and specifically, must be able to
respond to an appropriate command ("Write/Read Screen") in a
calling program by sending signals representing a stored screen
image to display 20, receiving keyboard input signals, modifying
the stored screen image in accordance therewith, and in addition
storing certain of the keyboard input signals.
Callinq Proqram. Program storage 17 further provides signals
representing a "calling program" which calls programming elements
for the operation of the data processing system. In the embodiment
described in detail in my copending application, and shown in Fig,
17, the calling program is titled PACE RUN, but other programs may
also be calling programs if they provide means for accomplishing
the calling Eunction generally in the manner described for PACE
1~i8~
-67- 70804-60D
RUN. In particular, the DD Deflnition program module 500 and the
Application ~uilder program module 508 of Fig. 18 are also call-
ing programs.
The data structures and modules for which storage space
is shown allocated in Flgs. 16 and 17 are described in detail in
my description of DATABASE MANAGEMENT MEANS, included as
"INSERT A".
Summary of DATABASE MANAGEMENT MEANS. In brief summary
of the disclosure of INSE~T A, the modules within the program
storage portion of storage 17 of Fig. 17 of the present applica-
tion are used to control the operation of da-ta processing system
10 with respect to the data structures shown in Fig. 16 of the
present application. The operation of system 10 under such con-
trol is such that representations of a se-t of record occurrences
in database 150 of Fig. 16, the set being defined by the cursor
in data structure 158, are displayed to the terminal user on
display 18, in a screen format 166, selected from a set of screen
formats in screen-file data structure 151 in a manner that has
been explained in INSERT A.
The screen format provides for a display of representa-
tions of the record occurrences in a form that permits the user
to actuate keyboard 20 to select some or all of the represented
record occurrences for further operation. In addition, the screen
format provides for a display to the user of representations of a
68;~59
-68- 70840-60D
plurality of selectable operations, performable by the data
processing system these representations are displayed in
associatiOn with identifiers of the PF keys 2~4 (as well as ENTER
key 206) which may be actuated to select an operation. Data
processing system 10 retrieves the defined record occurrences, and
meryes the retrieved record occurrences with the screen format to
define a stored screen imaqe, and then operates under the control
o operating system 100 to display a representation of such image
on display 18.
Keyboard 20 is enabled during such display, and input signals
from the keyboard provide enumerating or characterizing signals.
System 10, operating under the control of the modules of Fig. 17,
derives from such input signals, together with the signals of the
cursor of data structure 158, signals defining a result relation,
defined either enumeratively or characteristically.
In addition, other signals input through keyboard 20 during
such display provide operation selection signals, efecting
selection of one of a plurality of selectable operations,
performable by the data processing system,
Such derived signals (both defininy the result relation and
selecting an operation) are stored in data storage 17, and are then
available for use in further controlling data processing system 10
in accordance with the calling program.
s~
-
-69- 70840-60D
The Present lnvention. According to a first aspect of my
present invention, the relational operator means described and
claimed in my copending application is employed sequentially with
respect to more than one screen-file and more than one database, to
effect the interactive construction and execution of a database
maintenance application program.
Operation according to this aspect of my invention will first
be outlined: it will then be described in greater detail.
Reference is made to Fig. 18. In this conceptual showing are
represented the operations of data processing system 10, with
respect to the working storage and database storage portions of
storage 17, under the successive control of certain program
modules. It will be understood that during such operation, the
signals representing each program module are copied from program
storage and are used to control the physical state of various
hardware elements of system lO in order to effect the desired
physical operations. In this figure, for simplicity. the data
processing system is not itself explicitly represented. However,
the lines labeled "accesses" represent operation by processor 12 to
read (obtain signals from) the represented storage structures in
storage 17, the lines labeled "constructs" represent operation by
processor 12 to allocate storage for and write (place signals into)
the represented storage structures in storage 17. The indicated
inputs from keyboard 20 are understood to be input signals from
keyboard 20 to processor 12. ~he parameters $screen-file and
$database are understood to be signals representing appropriate
~2~8Z~9
-70- 70840-60D
values of these parameters, input to processor 12 in any
appropriate manner.
Outline. According to my invention, the signals representing
the DD Screen-file 502, the meta-meta-database 50~, the AB
Screen-Eile 510, and the @Default screen-set 511 are provided in
storage 17 before operation begins. Referring to Fig. lB, data
processing system 10 first operates under the control of a first
program module (DD Definition~ 500 with respect to a first
screen-file (DD screen-Eile) 502 and a first database 50~, both to
be described below. The data processing system advantageously
employs the relational operator means of my copending application
and receives input signals from keyboard Z0, which are interpreted
by data processing system 10 operating according to module 500 in
order to derive and store in the database storage, signals
representing a second database 506, which will be described below.
Next, data processing system 10 operates under the control of
a second program module (Application Builder) 50a with respect to a
second screen-file (AB screen-file) 510 and a screen-set 511 cailed
"@DEFAULT", both to be described, and with respect to database 506
constructed during the previous step. Data processinq system 10
advantageously employs the relational operator means oE my
copending application and receives input signals from keyboard 20,
which are interpreted by data processing system 10 operating
according to module 50~ in order to derive and store in working
i8;~59
-71- 70840-60D
storaqe signals representing a third screen-file 512, to be
described below.
Finally, data processing system lO operates according to an
interpretor program, such as the PACE RUN module 514 described in
my copending application, with respect to the constructed
screen-file 512 and the third database 516, employing the
relational operator means of my copending application, in order to
permit interactive maintenance and use of database 516 from the
system terminal. The constructed screen-file 512 thus functions as
an application program for the interactive use of database 516, as
will be descrlbed.
The first database 50g is a meta-meta-database, that is, it
comprises a generic aescription of any database definition
(meta-database). It contains relations whose record occurrences
are generic definitions of the elements of a database: files,
views, records, and relationships. During operation of data
processing system 10 according to module 500, the user provides
names of relations, column or domain names, attribute definitions,
field lengths and types, and all the necessary information about
the particular database 516 whose record occurrences will
ultimately be manipulated by the user, using the application
program. The definition of the particular database 516 thus
provided by the user, and forming database 506, may be called a
"meta-database", that is, a description of a particular database.
The meta-database 506 is itself a relational database.
32s9
-72- 708~0-60D
By employing the relational operator means of my copending
application, as has been described above, the data definition
process may advantageously be accomplished interactively and
nonprocedurally. The user need not learn a data definition
language, or memorize names of data items or operations. Thus,
nonprogrammers are enabled to perform data definition.
Further, the definition of built screen-file 512 may also be
advantageously accomplished interactively and nonprocedurally by
the employment of my relational operator means, and thus may be
carried out by nonprogrammers. In effect, a nonprogrammer is thus
enabled to create an application program.
Further, according to another aspect of my present invention,
when the constructed application program is run (that is, when
constructed screen-file 512 is employed to permit interactive
maintenance of database 516), the plurality of operations, shown on
the display and selectable by means of a PF key 204, in addition to
the operations described in my copending application, includes a
further type of operation generically referred to as a "descend"
operation. This operation enables the user easily to obtain a
display of record occurrences related to an initially displayed
record occurrence, as will be explained.
Data dictionaries. Data dictionaries, or descriptions of
databases, are in general well known in the database management
art, and may be constructed in a number of ways. A data dictionary
1~6~Zs9
-73- 70840-60D
consists of descriptors of data attributes, such as names of fields
and field lengths. In particular, the base tables, fields, keys,
files, and view tables of the database are defined in the data
dictionary.
Further, some prior art data dictionaries for a relational
database have provided definitions of the relationships between the
tables (relations), or in some cases the records, of the database.
Relationships. Referring now to Fig. 24, certain records of an
imaginary database are shown by way of example. It is assumed that
this database provides tables (relations) called Customer, Order,
Item, and Part. Other tables may be present.
A record from the Customer table tWhich comprises many such
Customer records) includes the fields named CustomerK, Customer
Name, Address, and Balance, as well as others not here pertinent.
It is assumed that the CustomerN is a unique key in the Customer
table, that is, its value uni~uely identifies a customer. A record
~rom the Order table (which comprises many such Order records)
includes the Eields Customer#, Order # and Date, with other fields
not here pertinent. It will be apparent that if the value of the
CustomerN oE a Customer record is the same as that of the CustomerN
of an Order record, this fact may be used to relate the Customer
record to the Order record, or vice versa. The fact that a
CustomerN field is present in every Customer record and in every
Order record relates the Customer table to the Order table. As
there may be many Order record occurrences related to a single
325~
-74- 70~40-60D
Customer record occurrence, the Customer record is defined as the
"parent" or "owner" and the Order record is defined as the "child"
or "member".
A database manager, having a database which already providPs a
Customer table, may defille an Order table having the fields Order~
and Date. In order to provide a relationship between the Order
table and the Customer table, it is necessary that the Order record
further include the Customer~ of the customer to which that Order
record is related. If this field is not already defined in the
Order table, it must be added to support the relationship.
Further considering Fig. 2~, an Item record is related to an
Order record by two fields, the CustomerN and the Order~. The
values of both must coincide if a particular Item record is related
to a particular Order record. There may be many Item records
related to a single Order record. A Part record may be related to
an Item record by the Part~: many Item records may be related to a
single Part record.
Relationship attributes. As is known in the prior art, a
relationship is defined by the attributes:
name of parent record, name of child record
set of parent relationship fields (must be a deined unique
key)
set of child relationship fields
. .
259
75- 70840-60D
integrity rules (described below)
The parent relationship fields in the Order record oE Fig. 24,
for example, are the Customer~ and the Order~. These are also the
child relationship ields in the Item record.
Thereore, the process of definition o a relationship
includes the following steps:
1. Define the parent rslation and the parent relationship
fields.
2. During the process of defining the fields in the
prospective child relation, specify the parent table for the
relationship. The parent table must have a defined unique key in
each record occurrence.
3. Specify which unique key (if there is more than one) in
the record occurrences of the parent table is to be used for the
relationship. The field definitions of this key are copied into
the definition of the child table.
4. Define integrity rules for t~e relationship. These may be
provided as default rules, or modiEied by the user.
5. Continue with the definition of child table fields not
participating in tlle relationship.
.,, ~ ,....
,
1;~68259
-76- 70840-60D
Integrity rules govern the addition, modification, or deletion
of records in related tables. For example, if relationships are
defined between customer and order tables in a database, an
integrity rule can be deEined such that a record occurrence cannot
be added to the order table unless there is already present a
record occurrence in the customer table to which the added order
record can be related.
According to my invention, two further attributes of a
relationship are defined and signals representing them are stored
in the Data Dictionary, namely the ascend and descend names of the
relationship. The ascend name refers to the relationship when the
user is viewing the child records the descend name is used wllen
the user is viewing the parent records. Thus, when viewing the
Order table, the name of the relationship might be "Customer"; when
viewing the Customer table, the name of the relations}-ip might be
"Orders". (Note that the relationship is one to many, Customer to
Orders.)
llowever, the names of the relationship need not necessarily be
the same as the names of the related tables. For example, if an
Employee table and a Manager table are related as child and parent,
the ascend relationship name might be "reports to" while the
descend relationship name might be "supervises".
For convenience herein, the term "descend" is sometimes
employed to refer generically to oper~tions performed at run-time
1;~ 32~9
-77- 70840-60D
with respect to actual record occurrences, involving the
relationship viewed Erom either direction.
~ eferring to Fig. 18, according to my invention, for each
relation (base table or view) in database 516, there is provided a
relation descriptor 570, which provides signals representing the
name of the relation and other pertinent information, such as names
oE fields within it, types of fields, lengths of fields, and the
like.
When all attributes have been defined, data processing system
lO assigns a relationship ID~ to the set of attributes of each
defined relationship: signals representing these attributes are
stored in ~elationship Attribute storage 520 within Data Dictionary
506 in storage 17, and are indexed by the relationship IDN~ For
each relationship in which the relation participates, the
relationship IDN is included in the descriptor 570 for that
relation.
Data Definition Module 500. Considering my invention in
greater detail, and referring now to Fig. 18, the program storage
portion of storage 17 provides a program module 500 called DD
Def inition .
The DD deinition module can be constructed as a calling
program to the modules (other than PACE RUN) shown in Fig. 17. That
is, data processing system 10, during operation under the control
~:6~Z59
-78~ 70840-60D
of module 500, can operate according to the modules described in my
copending application which permit interactive definition of
enumeratively defined result relations, with the selection of one
o the selectable operations.
Specifically, when called by DD Definition module 500, the
relational operator means o my copending application operates with
respect to screen-file 502 in data storage 17, which provides a set
oE screen formats suitable Eor eliciting from the terminal user a
definition oE database 516, and with respect to the meta-dictionary
504. Screen-file 502 includes LIST, DISP~AY, and MODIFY type
screen formats 503, with associated control signals 505 (POP
tables, Screen Maps, and the like) all as described in my copending
application. (A LIST screen displays a list of record occurrences,
while a DISPLAY screen displays more complete information (more
fields) or a sinqle record occurrence.)
Fig. 19 shows a LIST screen format from screen-file 502, used
to display a list of all existing tables (named Customer, Item,
Order and Part) in an exemplary database, together with tl-e first
thirty characters of each table's comment field. Actuation of PF
key 204-10 on keyboard 20 when this screen is clisplayed results in
a transition to the display of the complete comment field for a
particular table (enumerated in the manner described in my
copending application) using a DISPLAY format, the means for
accompli9hing such transitions have been described in my copending
application. Actuation of PF key 204-G results in a transition to
8~59
-79- 70840-60D
the display oE an ADD screen format from screen-file 50Z, as shown
in Fig. 20, also by means described in my copending application.
Actuation of PF key 204-1 (Advanced Functions) when the LIST
screen of Fig. 19 is displayed results in a transition to display
of the Advanced LIST screen, with representations of PF keys 20
associated with another plurality o selectable operations (Fig.
8). (This transition, although not explicitly described in my
copending application, is accomplished by WZPXI module 114 in a
manner similar to that described for similar transitions.) Among
this plurality of selectable operations are several operations
relating to the defining of relationships in which the listed
tables participate. In particular, a selectable operation is
provided Eor "Create Relationship".
Actuation of PF key 204-6 for Create Relationship during
display of the Advanced LIST Tables screen results in a transition
to display according to a screen format (not shown), which permits
the user to define the attributes of the relationship. (In
alternative embodiments this Eunction might be accossed Erom a LIST
Fields screen.) Signals representing such attributes are stored by
daLa processing system 10 in Data Dictionary S06, within the data
structure 520, "relationship attributes", indexed by the
relationship IDN.
Operating according to naming module 526 of DD Definition
module 500, data processing system 10 accesses within Data
~8~59
-80- 708~0-60D
Dictionary 506 the deinitions of the two related tables, retrieves
the names of the tables, and assigns the names of the tables as the
default ascend and descend names o the relationship.
Actuation of PF key 204-9 dur;ng display of the Advanced LIST
screen results in a transition to the DISPLAY RELATIONS~IIP screen
tFig. 9). This screen provides a display of representations of the
characters oE the assigned ascend and descend names of the
relationship. Actuation of PF key 204-9 (Modify) during display of
this screen causes a transition to a MODIFY screen Eormat (by means
described in my copending application); in this format,
representations of the characters of the ascend and descend names
are displayed in open areas, that is, areas modifiable by the user
through keyboard Z0. The user can then use typewriter keys 200 of
keyboard 20 to provide input signals representing modified
relationship names. Signals representing the characters of the
assigned (default) names or the modified names, if any, are stored
in data element 524 of data structure Relationship Attributes 520,
indexed by relationship ID~, within Data Dictionary 506 for
database 516. The names o the relations which are related by
attributes 520 are stored at 527.
When the construction of Data Dictionary 506 is complete,
operation according to t}-e next module 508 can begin.
Application Builcler module 508. Continuin~ with the more
detailed consideration of my invention, an Application nuilder
i8Z59
-81- 70840-60D
module 508 is provided in the program storage portion o~ storage
17. Operating accord;ng to this module, data processing system 10
may also advantageously employ the relational operator of my
copending application, which operates with respect to the
meta-database 506 and A8 screen-file 510 (Fig. 18). ~lowever, the
operations performed by data processing system 10 to accomplish the
functions described below may also be carried out by other suitable
means. In o~tline, operating according to the Application Builder
module, Dr system 10 constructs within storage 17 a particular
screen-file 512 tailored for the maintenance of one or more
particular target relations within database 516. This operation
will now be considered in greater detail.
Operation accordlng to module 508 begins after the terminal
user has selected a database. The database must have been defined:
that is, its meta-database or Data Dictionary 506 must have been
defined and signals representing it stored in storage 17 in the
manner described above, and in particular, the ascend and descend
names of all defined relationships must have been defined and
representations of the characters of the names stored at 524.
Data processing system 10 under the control of Application
8uilder module 508 operates with respect to the input parameters
$database and $screen-file. The particular value of $database
designates the database 516 to be managed by the application
program: the Data Dictionary 506 for that database is accessed.
,~
1;~6~1Z5~
~~'` -82- 70840-60D
The particular value oE $screen-file designates the AB screen-ile
510.
The @Deault screen-set 511 is also accessed. Screen-set 511
provides archetype (default) screen formats 521 for each
screen-type (LIST, DISPLAY, SELECT, ADD, MODIFY, DFLFTE) and an
archetype POP table 509 associated with each screen format. The
archetype screen formats are similar to those shown in Figs. 8, 13
and 14 of my copending application but lack specific
representations of the target relation name and the column or
domain names, and other information regarding the PF keys. Such
representations are replaced by open elements. The POP table 509
specifies which PF keys 204 can be represented on a particular
ormat, and includes Eor each PF key signals necessary for carrying
out the operation selected by that key, as described in my
copending application. The POP table is not complete, in that PF
keys for descend operations may be added at a later stage, as will
be described.
Since screen-set 511 is provided separately from AB
Screen-file 510, the Formats 523 can be edited globally by the
user; for example, the language of the fixed text can be changed.
A particular @Default screen-set 511 is associated with a
particular Data Dictionary 506.
Screen-file 510, with respect to which data processing system
10 operates according to the modules of Fig. 17 when called from
~ 2Ç~8~59
-83- 70O40-60D
Application Builder module 508, provides AB screen formats 523,
used for the display of record occurrences retrieved from Data
Dictionary 506, with associated control signals 525 comprising POP
tables, Screen Maps, For-Display-L:ists, and other data structures
as described in more detail in my copending application.
Operating first according to the Display module 550 of
Application Builder module 508, and using the input parameter
$database, designating the database 516, data processing system 10
(advantageously employing the relational operator means Oe my
copending application) retrieves Erom Data Dictionary 506 signals
representing a list of names of relations (base tables or views) in
database 516. Representations oE the names are displayed in a
Eirst screen format from AB formats 523, as seen in Fig. 25. By
positioning the screen-position-marker and actuating the ENTER key
206 (Fiy. 5), the user can select an initial table.
Operating further according to module 550 of module 508, data
processing system 10 uses the name of the selected initial table to
obtain from ~he descriptor 570 for that table, a list of
relationship ID~s Eor relationships in which that tabla
participates. The relationship ID#s are usea to index data
structure 520 in Data Dictionary 506, and to retrieve signals
representing the names of the related tables from 527.
Pepresentations of the names are displayed in a second screen
ormat from AD formats 523, as seen in Fig. 26.
8~S9
-84- 70~40-60D
By actuating ENTER key 206 and positioning the
screen-position-marker by means of keys 20~ tFig. 5), the user can
select one or more related tables (relations) for inclusion in the
application program. In the present description, the table which
is initially displayed (or whose name is initially displayed) is
referred to as a "starting" relation, while a selected related
table which is subsequently displayed (or whose name is
subsequently displayed) i8 referred to as a "destination"
relation.
This process is repeated until either there are no related
tables unselected, or the user actuates PF key 20g-6 (Create
Program) during display of the screen format of Fig. 26.
The archetype screen formats 521 in screen-set 511 are next
copied for modification. Signals representing the selections made
by the user duriny previously described displays are then used hy
data processing system 10, operating according to Create
Screen-Eile module 552, to modify t}-e copied archetype screen
formats 521 to define screen-sets for all selected tables. A
screen-set 522 is provided for the "starting" relation, and a
screen-set 532 is created for each "destination" relation. The
signals stored in Data Dictionary 506 are retrieved and used at
this time to provide for the representation of screen fields,
column headers, prompts, and other fixed text. The modified screen
ormats of 522 and 532 are stored as part of constructed
screen-file 512.
~ 5 ~
~` -85- 70840-60D
In addition, Create Screen-file module 552 provides means for
constructing, by referring to the archetypa POPs 509 and the Data
Dictionary 506, within screen-file 512 the associated control
signals at 530 and 534 comprising POP tProcedure Operation) tables,
PSMPS (Procedure Screen Maps), and other elements described in more
detail in my copending application, associated with the defined
screen sets and required for the proper use of such screen sets.
For example, such Data Dictionary stored signals as those defining
the type and length Oe the fields are retrieved and used to
construct an appropriate Screen Map.
In this process, the relationship attributes of 520 are used
in three ways. First, the screen formats 522 in the screen set for
tl-e starting relation are modified to provide for the display o
the representation of a PF key 204 in association with the name of
the relationship (from 524) to the destination relation. Since the
name of the starting relation is known, the appropriate
ascend~descend name can be selected for the direction of the
relationship. Further, the POP table within control signals 530
for each screen format 522 is modified to include signals
representing an oper defined for that PF key. The oper.action is
"descend~ via screen~"~ the oper.name is the name of the
relationship, copied from data storage element 524. Each descend
operation is uniquely identified by "descend~", which indexes a
unique PDSC data structure 538 (described below). There may be
more than one descend transition defined on a given screen-formats
each is identified by a unique descend~ in the pop.oper.action.
1~:6~3259
86- 70840-60D
Second, an additional screen-set 532 is constructed in
screen-Eile 512, by modifying a copy Oe the archetype sareen-set
521 ;n accordance with the information in Data Dictionary 506
describing tlle destination relation tscreen fields, relation name,
column names, and the like) as described above. Appropriate POPs,
PSMPs and other control data structures are defined and signals
representing them are stored in screen-file 512 at 534.
Third, operating according to Application Builder module 508,
data processing system lO builds (allocates storage and stores
signals therein~ a PDSC data structure 538 within screen-file 512.
A particular PDSC data structure is built for each selected
transition from a irst or "starting" relation to a second or
"destination" relation, and is identified, as stated above, by a
unique descend~.
ReEerring now to Fig. 23, PDSC data structure 538 comprises
two portions 540 and 542. Portion 540 provides signals
representing control information, the second portion provides
signals representing a cursor defined against the destination
relation, but not completely speciEied. The selection area or
"where clause" of this cursor includes one or more locations
identified by parameters @1, @2, ..., while the signals oE control
portion 540 are employed (at a later time, as will be explained) by
data processing system lO to obtain signals to be placed in the
locations, representing values for the parameters. Specifically,
the parent relationship fields must be copied into the cursor at
82S9
~~` -87- 70840-60D
the @1, @2 ... locations in order to retrieve related child recard
occurrences throuqh this cursor. In constructing PDSC data
structure 53~, the specificat;on o eields identified by parameters
@1, @2 ... and of the control information signals in portion 540 is
derived rom the attributes of the relationship stored at 5Z0 in
Data Dictionary 506 within storage 17. The function of the
parameters @1, @2 ... will become clear in what follows.
PDSC data structure 538 is stored in built screen-ile 512.
By selecting an initial table, from the display of Fig. 25,
the user defines a value for "Initial Table" within data structure
PDEF 153 in Screen-file 51Z. A default order of screen-format
presentation is defined by data processing system 10 operating
according to Create Screen-File module 552.
Advantageously, a further module 554 "Screen Edit" may be
provided in Application 8uilder module 508. Actuation of PF key
204-9 "Edit Screen Sets" during display of the screen format shown
in Fig. 25 causes data processing system 10 to operate according to
this module, and under its control, representations oE the screen
formats 522 and 532 are displayed to the user in "prototype" form,
that is, with specific headers and relation names taken from Data
Dictionary 506, but with X's or other symbols representing the
record occurrences. No record occurrences are actually retrieved
from database 516 at this time. Appropriate m0ans for editing the
appearance of the screen formats is provided, in addition, the
3259
~ ~ -88- 70840--~OD
order of presentation of the formats may be changed by the user.
The presentation of PF keys on each format may also be edited~ for
instance, to prevent deletion oE record occurrences at a later
time, the PF key for the Delete operation can be removed from the
format.
Interpretation of constructed proqram. When the built
screen-file 512 has been completely defined and signals
representing it have been stored in the working storage portion of
storage 17, it constitutes in effect an application program Eor the
0 interactive, nonprocedural maintenance of the database 516 for
which it was constructed. When it is desired to use this
application program, an interpretor must be employed, and in
particular, the PACE RUN module described in my copending
application serves as such an interpretor. For the purpose of
interpreting the signals representing the "descends", two
additional program modules tnot shown in my copending application)
are provided in program storage portion of storage 17: PXIDSC
module 600 and WZFETCII(qid) module 602. Additionally, the DO DSC
module 107 within the calling program calls the DO QUERY module
108: this function is not shown in my copending application.
WZFETCII module 602 calls WZRETRIEVE module 118 to rotrieve a
single record occurrence from datahase 516, without displaying it.
The parameter "qid" identifies the query to be used in the
retrieval. Other particular features of the FETCII module are not
pertinent herein.
1~8~s9
~ -89- 70840-60D
When the constructed application program is run, data
processing system 10 operating according to the PACE RUN module in
the manner described in my copending application accesses and opens
screen-file 512. The signals stored in PDEF 153 are used to access
an initial screen Eormat 522 and initial relation (table) from
database 516. If the eormat was so modified during the previous
operation of the data processing system according to Application
Builder module 508, the initial screen format includes a
representation of a PF key 204 for a descend transition to a
0 display of a related relation. Record occurrences defined by
cursor 158 are retrieved from the initial target relation and
merged with the initial screen format to define a stored screen
image.
As described in my copending application, the stored screen
image is displayed, and signals representing either enum~ration or
characteristic selection of a result relation are input through
keyboard 20 and stored in working storage 17. Input signals
representing selection of an operation by actuation of a PF key 204
on keyboard 20 are stored in the data element for.fpf-key within
FOR data structure 164.
When the operation selection signals input by the user through
keyboard 20 represent actuation of the PF key 204 corresponding to
a specific descend transition, data processing system 10 operating
according to WZSCRIO module 120 copies the signals representing tlle
pop.oper for that PF key into QUERY.oper, as has been explained in
1i~68~S9
-90- 70~40-60D
my copending application. The oper.action for that PF key is
"descend~ via screen~", identifying the particular PDSC structure
538 within screen-ile 512 that corresponds to that descend
transition. Data processing system 10 then returns to DO PXI
module 112, with signals r0presenting the action "descend~" stored
in data element ATAB 172.
Operating according to DO PXI module 112, data processing
system 10 tests the signals in ATAB 172, as described in my
copending application. In this case, in response to signals
representing the action 'Idescend~ data processing system 10
operates urther according to the module PXIDSC 600 to call
FETC~I(qid) module 602, which calls RETRIEVE module 118.
Operating according to RETRIEVE module 118 and according to
the stored signals deining the result relation (either the marked
records in Seen-List 170 or the modified cursor in data structure
158, as described in my copending application), data processing
system 10 copies from database 516 signals representing the first
record occurrence in the result relation. Since the result
relation is deined from the "starting" relation, the record
occurrence retrieved in response to FETC~I is a member o~ the
starting relation, defined by the modified query identiEied by
qid. The retrieved record is not displayed: it is stored in System
Buffer 168 (Fig. 16). When the record has been retrieved, PXIDSC
600 calls DO DSC module 107.
8~59
~ -91- 70840-60D
Data processing system 10, operating according to DO DSC
module 107 and accessing the first portion 540 of PDSC data
structure 538, copies from the retrieved record occurrence, signals
representillg the values of the relationship Eields, to the
locations indicated by the corresponding parameters ~ 2 ...
within second portion 542 of PDSC 538 as defined by first portion
540. The copied fields are the keys which are present in both the
parent records and the related child records, as previously
described. Therefore, the values of these fields are efective to
define which are the related record occurrences in the destination
relation. This operation completes the cursor provided by PDSC
538. The cursor is now completely defined against the
"destination" relation.
Signals representing the completed cursor from PDSC 538 are
now placed within a CURSOR data structure 158, and the module DO
QUERY is called to open the cursor and define a new QUERY data
structure 162 corresponding to the new cursor, all as described in
my copendinq application. (The cursor defined against the
"starting" relation remains open.) The current screen-file
continues to be accessed; the new screen~ is provided from the
descend action (descend~ via screen~). Operation of the data
processing system according to this module, with respect to a
particular cursor, has been explained in detail in my copending
application.
.,
1~8X5~
-92- 708~0-60D
The result in the present case is that the records in the
"destination" relation, defined by the cursor ~provided by PDSC 53n
and completed with specific relationship field values from the
retrieved record occurrence from the "starting" relation), are
sequentially retrieved from database 516, merged w;th a
screen-format of screen-set 532 within screen-file 512, and
displayed to the user on display 18. The user can actuate PF keys
204 in the manner described in my copending application, in order
to modify the record occurrences whose representations are
displayed; for example, the user can update or delete occurronces,
or can add new ones to the "destination" relation of database 516.
When the user has viewed as many of the record occurrences
within the "destination" relation as is desired, and has performed
any desired operations on them, actuation of the Return PF key
204-16 causes DOOUERY module 108 to return to its caller.
Alternatively, when all record occurrences within the destination
relation have been viewed, such return is accomplished
automatically by unstacking the recursion. The next record
occurrence o the "starting" relation is then retrieved by FETC}a
module 602. The descend process is now repeated for the record
occurrences from the "destination" relation related to the next
record occurrence oE the "starting" relatlon. When all related
record occurrences for all the record occurrences of the starting
relation have been viewed, operation according to WZRXI modulo 114
with respect to the cursor for the starting relation is resumed.
8~59
-93- 70840-60D
The LIST screen is redisplayed, with members of the star~ing
relation represented on it.
Operation, An example of the above operation will be
described, referriny now to the exemplary records shown in Fig.
24, Operating according to DD Definition module 500 and to input
signals Erom keyboard 20, data processing system 10 constructs a
Data Dictionary 506 for the "Sales" databasa 516. During such
construction, a relationship is defined by the user between the
Customer records and the Order records. The Customer table is
defined as the parent table, the Customer# field is defined as the
parent relationship field. Signals representing these definitions
are stored in attribute storage 520; further, "Customer" is stored
as the ascend name, and "Orders" as the descend name, of the
relationship, and signals representing the characters of these
names are stored at 524, A relationship ID~ is assigned to these
attributes, and is an index to relationship attribute storage 520.
The ID~ is stored in a descriptor 570 for the Customer table, and
also in a descriptor 570 for the Order table.
Next, operating according to Application Builder module 50~,
~0 and according to input signals from keyboard 20, data processing
system 10 accessas AB screen-file 510 and Data Dictionary 506 for
the "Sales" database 516. Data processing system 10, operating
according to module 550, and employing the relational operator of
my copending application, displays a list of table names (Customer,
Order, Item, and Part) retrieved from Data Dictionary 506, in a
12682s9
-9~- 70840-60D
format (such as that of Fiq. 25) from AB Screen-file 510. The
Customer table is selected by the user as the initial table:
signals representing this table are stored in "Initial Table" of
PDEF data structure 153.
Data processing system 10, Eurther operating according to
module 550, accesses the descriptor 570 of the Customer table in
Data Dictionary 506, and using the Relationship IDN (or IDNs) found
therein, accesses the relationship attributes storage 520. The
name of each table in the database 516 that is related to the
Customer table (in this case there is only ono, the Order table) is
displayed on display 20 in a format like that of Fig. 26. The
Order table is selected by the user as a related table to be
included in the application program.
The LIST screen format is selected by the user as the initial
screen, signals representing this format are stored in 'initial
screen" of PDEF data structure 153. Data processing system 10,
operating according to module 552, and referring to Data Dictionary
506, accesses the @Default screen-set 511 and copies and modifies
formats 521 and POPs 509. (Other control data structures, such as
Screen Maps, are also constructed at this time.) SpeciEically, the
archetype LIST format is modified for the Customer table to provide
a PF key (for illustration, PF key 20~-11) associated with the
characters "Orders", retrieved from data element 52~, indexed by
the Relationship IDN: the POP table for that screen is modiEied to
include a pop.oper "descendNl via screenN". (The value of screenN
1~i8~S9
-95- 708~0-60D
is assignable by the user; it is assumed that the LIST screen is
selected for the descend operation.) A PDSC data structure 538 is
constructed for descendHl. This PDSC structure in lts first
portion 5~0 contains the pair, "@1, customer.customer~". That is,
the customer~ of the Customer record is the relationship ield for
this relationship, as is found from the signals stored in the
attributes for the relationship between Customer and Order tables,
indexed by Relationship IDH. In slecond portion 542 of PDSC 538 is
provided a cursor, defined against the Order table of database 516,
but with the relationship field incomplete, and indicated by @1.
Finally, the archetype screen-set formats 521 and associated
POPs 509 are copied and modified to construct for the destination
relation the formats 532 and control signals 534. The remainder of
the built screen-file 512 (if any) is constructed, and is edited by
the user as desired.
At a later time, a user of the data processing system terminal
initiates operation according to PACE RUN 514 and built screen-file
512. According to the signals in E'DEF data structure 153, and
employing the relational operator of my copending application, data
processing system lO operates to display the LIST screen format
from formats 522 with record occurrences Erom the Customer table.
This display includes among the representat;ons of the selectable
operations the characters "11) Orders". The user enumerates
particular listed Customer record occurrences in a manner described
in my copending application, and actuates PF key 20~-ll. In the
~682~;9
-96- 70840-60D
manner described in my copending application, tlle signals
representing actuation of this PF ~ey are employed to ratriave from
the POP table for the LIST screen format 522 the corresponding
pop.oper, wllich is copied into qry.oper. The qry.oper-action is
"descendKl via LIST screen"; this is copied to ATA8 data structure
172.
Operating according to PACE RUN, data processing system 10
employs the signals representing "descend~l" to access the PDSC
data structure 538 previously built for this descend operation.
The first of the enumerated Customer records (from the initial LIST
screen) is fetched from database 516 and stored in System 8uEFer
168. The value of its Customer~ field is copied to the location in
PDSC portion 542 indicated by @1, thus completing the cursor. DO
QUERY module 108 is then called for operation with respect to this
cursor, in a manner described in my copending application. Order
record occurrences for which the Customer~ relationsl~ip field has
the value that has been copied from the Customer record in the
System ~uffer are retrieved, and are displayed to the user on a
LIST screen format 532.
The user can operate upon the listed Order record occurrences
in the manner described in my copending application. Specifically,
the user can modify or delete such record occurrences, or the user
can add ne~ record occurrences ~subject however to the integrity
rules in the relationship attribute storage 520, which are enforced
in a manner not described nerein). When all such desired
-, , .;. :,
1~68~sg
~` -97- 708~0-60D
operations have been performed, the next enumerated Customer record
from the initial LIST screon is fetched, and its Customer~ ;s
copied to the @l location of the cursor portion 5~2 of PDSC data
structure 538. The Order record oc:currences defined by this cursor
will then be retrieved. This process continues until it has been
performed with respect to all enumerated Customer racords from the
initial LIST SCREEN.
Thus the operations which users most commonly desire to
perform upon a database can all be accomplished, interactively and
nonprocedurally, through the operation of the application program
in the Eorm of the built screen-file 512.
Operation of the data processing system according to my
invention thus provides particularly simple means for the
nonprogrammer to create an application program for the interactive,
nonprocedural maintenance o a relational database, including
easily accomplished transitions to the display of any records
related to initially displayed records. The creation of
application programs of this complexity and flexibility has
hitherto required the amployment of expert programmers over a
considerable time, and the end product is frequently not as well
suited to the actual purposes of the ultimate user as may be
attained by the employment of my invention.
~L2682S~
-` -98- 70840-60D
--END OF INSERT B--
2S~
-99- 70840-60D
DESCRIPTION OF THE PRESENT INVENTION
BACRGROUND OF THE INVENTION
During the operations involved in maintaining a relational
database, several kinds of errors can occur. Certain errors are
"fatal", that is, the operation of the data processing system
cannot proceed at all (for example, a permanent error in the
operation of the disk). Certain other errors are not fatal, but
require correction before the operation can be continued. In an
interactive system, such errors can be corrected by a terminal
user.
In particular, there are two levels of such errors. At the
first or field level, constraints on fields (for example. that a
value entered into a given field be alphabetic or numeric) are
violated. At the second or integrity level, more complex
constraints are violated: for example, a record may be defined in
the data dictionary as a parent record in a relationship, and there
may be a constraint preventing deletion of a parent record if there
are records present related as child records to the parent record.
If the user attempts to delete the earent record when such child
records are present, this is an error. It is desirable to provide
means for detecting the error.
~lX~8;~S9
-100- 70840-60D
In interactive systems, both levels of errors are within a
class of errors that can be corrected by an interactive user of the
systemS if an indication oE the error is p~esented on the display,
the user, by means of the keyboard, ean eorreet the error, and
operation of the system can eontinue.
It would therefore be desirable to provide means for deteeting
and presenting to the interactive user errors of the class that ean
be interactively correeted. It is an objeet of my invention to
provide such means.
BRIEF DESCRIPTION OF THE INVENTION
Aecording to my invention, interactive error-handling means is
provided for use in a relational database management system. The
error-handling means comprises display means and input means, and
further comerises storage means providing: record occurrence
signals comprising record oecurrences in a relational database:
status signals: curreney signals: format signals: and message file
signals representing the characters of displayable error messages.
Further, the storage means provides means defining an operation
buffer and first and seeond record oecurrence buffers.
The error-handling means further comprises ealling means,
operation means, and fetch means. The operation means comprises
means responsive to an operation call signal for validating an
operation seleeted to be performed with respect to record
8~5~
~ -101- 70840-60D
occurrence signals in the second record occurrence buffer and
providing an output signal having one o two values, representing
valid and invalid conditions. The operation means Eurther
comprises first means responsive to an invalid condition value of
the output signal for generating corresponding status invalid
signals, and providing an operati~n return signal: and second
means responsive to a valid condition value of the output signal
for performing the selected operation with respect to the record
occurrence signals, and providing an operation return siqnal.
The fetch means comprises noninteractive means and interactive
means. The noninteractive means is responsive to a fetch call
signal, a noninteractive condition, and the currency signals for
retrieving record occurrence signals from the database, Eor placing
the retrieved signals into the first and second buffers, for
incrementing the currency signals, and for providing a fetch return
signal. The interactive means is responsiva to a fetch call signal
and an interactive condition signal. The interactive means
comprises: means responsive to the status valid signals and to the
currency signals for retrieving the record occurrence siqnals from
the database, and for copying the retrieved signals into the Eirst
and second buEfers, and means responsive to the status invalid
signals for copying the record occurrence signals rom the irst to
the second buEEer. Further, the interactive means comprises
display means responsive to the format signals and to the signals
in the second buffer for controlling the display to display a
representation of the record occurrence, and is responsive to
32~j9
-102- 70840-60
operator input signals from the input means, for placing an
operation selection signal in the operation buffer, and provid-
ing a fetch return signal. The display means is further respon-
sive to the sta-tus invalid signals and the message signals for
displaying representations of an error message.
The calling means is responsive to the operation return
signal and to the status invalid signal for providing a fe-tch
means call signal, and is responsive to the fetch return signal
for providing an operation call s:ignal.
In a preferred embodiment, the display means is further
responsive to operator input signals to modify the signals in
the second buffer. Further, the fetch means further comprises
condition means responsive to a format identifier signal, to a
first value of a condition parameter signal, and -to the status
invalid signal to provide an interactive condition signal, ancl
is responsive to a format identifier signal, to a first value
of a condition parameter signal, and to the status valid signal
to provide a noninteractive condition signal.
The present invention will now be described in more
detail with reference to Figures l, 5 and 27 - 29 of the draw-
ings.
Referring now to the drawing, and in particular to
Fig. 27, the program modules for which storage is allocated in
the program storage, as shown in this Figure, have been fully
described in INSERTS A and B, with the exception of WZFETCH
module 602. This module will be described herein in greater
68~9
-103- 70840-60
detail than .in INSERT B, in which such module is shown but only
briefly described.
Referring to Fig. 28, the data structures for which
storage is allocated to the working storage o~ Fig. 27 have been
described in INSERTS A and B, with certain exceptions to be
described below. In particular, according to the present inven-
tion, the TCOM data structure 160 further comprises signals
representing Status data structure 700, and the QVERY data
structure 162 further comprises signals representing a fetch
position
~68259
-104-
70840-60D
(qry.Ech-pos 707) and a pointer @pgm-buf. A Program suffer 703
is provided in working storage, pointed to by @pgmbuF in QUERY
data structure 162. A Message File data structure 702 is pro-
vided in working storage. A Data Dictionary s-truct~lre 506, more
fully described in INSERT B, provides relationship attributes
520 for each relationship defined in the database, and descriptors
570 for each relation (-table) in the database. In the preferred
embodiment, the Data Dictionary is itself modeled as a relational
database and provided in database storage, but this is not essen-
tial to the present invention.
Referring now to Fig. 29, the structure of the WZFETCEImeans 602 is shown in greater detail. ~ required input signal
to data processing system 10 of Fig. 1 when operating according
to WZFETCII is the parameter $qid, which identifies the query 162
(Fig. 28) (and by implication the cursor) which specifies the
particular record occurrence or occurrences to be obtained from
the physical database 150. The data processing system cannot
operate according to WZFETCH without this parameter. There are
in addition three optional parameiers: $screen-file, screen# (or
$screen-name), and $errors-only. The first two of these para-
meters identify the particular screen format signals (166 oE
Fig. 28) to be usea to control display 18. The $errors-only
parameter can have one of two values (yes or no), and its sig-
nificance will be explained below.
~6~325~3
-105- 70840-60D
WZFETC~I comprises three structures: a Main module 704, an
Interactive module 706, and a Non-interactive module 708.
Operating according to Main module 704, data processing system
10 operates to test whether signals representing the $screen-file
and screen~ parameters have been provided to WZFETC}I, and whether
the value of the $errors-only parameter is "yes" or "no". The
following conditions are recognized.
First, if no screen format has been identified, data
processing system 10 operates according to the Non-interactive
module 704. If a screen-format has been identified, and if
$errors-only = yes, then data processing system 10, operating under
control of Main module 704, tests signals provided in the Status
structure 700 of TCOM data structure 160 (Fiq. 28). These signals
are provided in a manner to be explained. If the value represented
by these signals indicates an error, previously detected in a
manner to be explained, then data processinq system 10 operates
urther according to Interactive module 706. If the value
represented by the Status structure signals indicates no error,
then data processing system 10 operates further according to
Non-interactive module 708.
Finally, iE a screen format has been identified and
$errors-only = no, data processing system 10 operates urther under
control of the Interactive module 706.
68259
106- 70840-60D
Non-interactive module 708 calls WZRETRIEVE module 118 (Fig.
27)~ operating according to module 118, as has been explained in my
copend;ng application, dat~ processing system lO calls the
operating system access method to copy from database 150 signals
representing a record occurrence defined by the current cursor.
The copied signals are placed in System Buffer 168 (Fig. 28). Upon
return to Non-interactive module 704, data processing system 10
operates to copy the retrieved signals into Program Buffer 703
(Fig. 28), and increments the gry.fch-pos signals in 707. System
10 then returns to operation according to whatever module called
WZFETCH, as will be described.
~lternatively, operating according to Interactive module 706,
data processing system lO first derives from the input parameters
$screen-file and screen~ signals for accessi~g the screen format
signals 166 to be used to control display 18. If necessary, data
processing system 10 calls WZ OPEN SCREEN-FILE module 106 (Fig. 27)
at this time. Next, data processing system 10 tests the signals
comprising Status data structure 700 in TCOM 160.
If these signals do not indicate that an error has previously
been detected (in a manner to be explained), then data processing
system lO calls WZRETRIEVE module 118, as in non-interactive module
708, to copy from database 150 signals representing a record
occurrence specified by the query identified by $qid and pointed to
by qry.fch-pos. System 10 then copies the signals from System
Buffer 168, where they were placed by system lO during operation
8~9
-107- 70O40-60D
according to WZRETRIEVE, to Program BufEer 703, and inerements tho
signals eomprising qry.feh-pos 707.
If the Status data strueture signals at 700 indieate that an
error has previously been deteeted, then data proeessing system 10
copies signals representing the previously retrieved reeord
oeeurrenee from System Buffer 168 to Program Buefer 703.
WZRETRIEVE is not ealled.
In either ease, data proeessing system 10 next operates
aeeording to sereen serviees WZSCRLOD and WZSCRIO modules 116 and
120, as deseribed in detail in my eopending applieation, ~hieh
control the data processing system including display 18 to display
representations of the reeord oecurrence in Program Huffer 703.
In the error case, an error parameter signal, derived from the
Status signals at 700, is employed by data processing system 10,
operating according to the screen serviees modules, to eopy from
Message File 702 signals representing displayable characters
comprising an error message appropriate to the particular error.
Thus representations of the record occurrence and the error message
are displayed on display 18 according to format signals 166.
In either interaetive case, as explained in my copending
applieation, signals representing a sereen image are stored, and
are employed by data proeessing system 10, under the eontrol of
operating system 100, to eontrol display 18. At this time, the
~6825~
-~ -108- 70840-60D
interactive user of the data processing system can actuate keys on
keyboard 20, effective to modify the stored screen image signals,
and to input operation selection signals representing a selected
operation.
During operation of tile data processing system according to
WZSCRIO module 120, and according to WZFORMS module 122 called
therefrom, errors of the kind described above as violation of field
constraints are detected. For e~ample, if the user attempts to
modify the screen to show representations of alphabetic characters
in a field which is specified, in descriptor 570 for the record, as
numeric, this error will be detected, and a representation of a
message (from message file 702) will be displayed to the user.
Until this error is interactively corrected, system 10 will not
return from operation according to WZFORMS 122.
Upon return from the screen services modules, data processing
system resets the signals of Status data structure 700 to indicate
no integrity-level error, and returns to Interactive module 706.
At this time, signals representing the actuated PF key 204 on
keyboard 20 are present in qry.oper.
Operating further according to Interactive module 706, data
processing system lO tests the signals representing the operation
selection by the interactive user (input by an actuated PF key
204). Certain operations (scrolling of the display, skip, retry,
continue and others not pertinent here) can be carried out by data
~68Z59
-109- 70840-60D
processing system 10, operating according to Interactive module
706; for others, data processing sys-tem 10 must return to a pre-
vious module. FETCEI always provides $Status signals (end-of-query
or success).
Operation according to WZFETCII will now be described.
Referring now to Fig. 27, apart from the descend operation which
is not discussed llerein, the context in which data processing
system 10 operates according to WZFETCH is most commonly tha-t in
which a modified cursor has been created during a previous opera-
tion of the data processing system according to the relational
operator of the present invention.- The modified cursor specifies
a result relation of record occurrences. Further, the interactive
user has actuated a PF key 204 on keyboard 20, effective to select
one of the transition operations that cannot be handled by system
10 operating according to the WZDISP, WZSELECT, or WZPXI modules
of Fig. 27. Specifically, such operations are transitions to the
Add, Modify or Delete screen formats 166, or a descend transition
to display of related record occurrences, as described in INSERT
B.
In operation, in this context, data processing system
10 returns to DO PXI module within the P~CE RUN or other calling
program; signals representing a modified cursor and a selected
operation are present in working storage.
i~6~3~5~
-- -110- 708~0-60D
Operating according to DO PXI module 112, data processing
sytem 10 tests the signals representing the selected operation. If
the operation is a descend, this is handled as described in my
previously mentioned copending application. IE the action is a
transition to the Add, Modify or Delete screen formats, DO PXI
calls DO UPDATE module 126, still within PACE RUN or other calling
program.
The Add screen case will not be described in detail herein.
~riefly, a default Add screen may be advantaqeously deined
interactively by'the user, in which certain open fields are
displayed with characterizing information therein. For this
purpose, system 10 operates according to WZFETCH but instead of
retrieving a record occurrence from database 150, retrieves a
deEault record (800) containing the default characterizing
information.
For the Modify or Delete screen formats 166, data processing
system 10 operating according to DO UPDATE module 126 calls
WZFETCH. If the status value is end-of-guery, the system 10
returns to DO PXI module 112
.
If the transition to a Modify or Delete screen was selected by
the user while viewing a Display screan format 166, which displays
a representation of a single record occurrence, then data
processing system 10 will operate according to WZFETC~I to obtain
that record occurrence for display according to the Modify or
Delete screen format. The Modify or Delete screen format is
employed by data processing system 10, operating according to
1~68~59
~~` -111- 70840-60D
Interactive module 706 the representation of the record occurrence
is displayed to the user. For a Modify operation, the user can
interactively modiEy the fields of the represented record
occurrence, and actuate Enter key 206 to select the operation of
modification of the corresponding record occurrence signals in the
database. (Note that modiEying the representation does not in
itself modify the physical records in the database, which must be
accomplished in a separate operation, after validation, as Will be
described.) Alternatively, the user can actuate PF key 704-1 to
Skip Record, or can actuate Return PF key 204-16.
Data processing system 10 then returns to DO UPDATE module
126, which calls WZUPDATE module 115. For purposes of the present
description, WZUPDATE module 115 is assumed to provide means for
accomplishing both Modiy and Delete operations. Operating
according to module 126, data processing system 10 accesses siqnals
comprising integrity constraints from Data Dictionary attribute
storage 5Z0 (advantageously such signals have previously been
copied into working storage). Data processing system 10 employs
such integrity constraint signals together with signals
representing user input (operation selection, with record
occurrence modification for a ModiEy operation) to check the
validity of the selected operation. The signals in the Program
Buffer 703 comprise the record occurrence with respect to which the
operation will be carried out.
1~6825~
-112- 70840-60D
If the selected operation is not valid, it is not performed~
however, signals representing the error condition are generated by
system 10 and stored in Status data structure 700 in TCOM 160,
after which system 10 returns to DO UPDATE. The kind of error that
is detected at this time has been previously described, with the
example Oe an attempt to delete a parent record occurrence to which
child record occurrences are related by a relationship, when the
relationship attributes 520 prohibit such deletion.
Additionally and advantageously, other errors are also
detected at this time. For example, a particular record occurrence
may be "locked" (unavailabls because another interactive user is
operating with respect to it, through another terminal), so that
the operation, although valid, cannot be performed at this time, it
may be desired to retry the operation after a brief time interval.
If the operation is valid and can be performed, system 10
operating according to module WZUPDATE performs the operation and
returns to DO UPDATE.
Data processing system 10, operating according to DO UPDATE
module 126 calls WZFETCH. Operating according to WZFETCH, as has
been described, system 10 also tests the Status data structure, and
in response to an error condition, copies the signals comprising
the previously retrieved record occurrence Erom System ~ufEer 168
(where they were placed when initially retrieved during the
126~25~
~ -113- 70840-60D
previous WZFETC~I operation) to the Program Buffer 703. The screen
services modules are called, as previously described, to control
display ln to display the previously retrieved record occurrence,
together with an error message rom Message File 702.
Advantageously, the fiela or fields which were in error are flashed
in the display.
The interactive user can read the error message and correct
the entry. When the user has actuated eitber the Enter key or one
of the PF keys 204-1 or 204-16, system 10 returns from operation
according to WZFETC~ to DO ~PDATE module 126. Module 126 calls WZ
UPDATE module 115 as before described; system 10 validates the
selected operation tand the modified record occurrence signals for
a Modify operation) and if the error has been corrected, carries
out the selected operation.
The $errors-only parameter is employed in the following
manner. In some cases it may be desired to oEfer a selectable
operation to the interactive user SUC}I as "Delete ~11", in which a
plurality of record occurrences tdefined advantageously by a result
relation provided in a previous operation) are all to be deleted
from database 150. The user has no need to view each record
occurrence before it is deleted, if the operation is valid with
respect to that record occurrences however, iE the operation is
8;~5~
-l14- 70840-60D
invalid as to any one of the record occurrences, it is desirable
that the user be able to view that occurrence with an error
message, so that the operation can be corrected or skipped as to
that record, and the operation can proceed as to remaining
records. Alternatively, as described above, it may happen in a
data processing system in which many interactive users are
accessing the record occurrences in database 150 during the same
time, that a particular record occurrence cannot be retrieved at a
particular moment. In such a case, it is desirable to permit the
interactive user to select a Retry operation, which if successful,
will permit the system to continue operation.
For this purpose, DO UPDATE module 126 calls WZ FETCH module
602 and WZ UPDATE module 115 alternately until the selected
operation has been carried out with respect to all record
occurrences specified by the cursor. Signals representing a "yes"
value of the $errors-only parameter are employed by system 10 when
operating according to WZFETCH module 602. In response to such
signals, when operating according to Main module 704, system 10
employs the signals comprising the ~tatus structure in TCOM 160.
If the value represented by these signals indicates that there has
been no error in carrying out the selected operation on the
previously retrieved record occurrence, system 10 operates
according to Non-interactive module 708 to retrievo the next record
occurrence, place signals comprising it into the Program Buffer,
and increment the qry.fch-pos signals 707. The operation will then
be validated with respect to the newly fetched record occurrence.
, .
1268~s~3
~~ -l15- 70840-60D
However, if the signals comprising the Status structure 700
indicate an error condition rom the previous operation of system
lO according to WZ UPDATE 115, then system 10 operating according
to Main module 704 will call Interactive module 706. As described
above, the signals comprising the previously retrieved record
occurrence will be copied to Program Buffer 703, and the screen
services modules will control display 18 to display representations
of such record occurrence and an error message from File 702,
according to the for~at 166 specified by screen~.
Upon input of signals by the interactive user including an
operation selection signal, system 10 clears Status structure 700
of the indication of the previously detected integrity level error
and returns to DO UPDATE, which calls WZ UPDATE module 115. I~ the
interactive user's signals have corrected the error (or selected
Retry or Skip, or other appropriate operations) the systern can
perform the appropriate action, and continue with operation
according to the remaining record occurrences. If not, system lO
again fails to validate the operation, and places appropriate
signals in Status structure 700. No return to DO PXI or other
calling program is possible until the error has been corrected.
Thus no part of DO PXI or other calling program need provide means
for handling such errors.
It will be observed that the means and operation according to
my invention provide particularly convenient means for an
interactive user to correct input errors in a large number of
1268X59
-116- 70840~60D
cases. The detection of the error, and the interactive means for
correcting it, are provided for in the query-access level of the
operation of the data processing system. This offers particular
advantages when a programmer is constructing an interactive
database maintenance program comprising other operations to be
performed upon the database record occurrences, which employ
Modify or Delete operations, as the programmer need not be con-
cerned with this level of error.
