 |
Description  |
|
|
FIELD OF THE INVENTION
The present invention relates to a single interface which allows computer
applications to efficiently access multiple records of databases stored in
a plurality of different file system formats. By means of the interface,
the computer applications access the records using a single set of access
procedure commands which are independent of the filing system formats in
which the databases are stored.
BACKGROUND OF THE INVENTION
FIG. 1 schematically illustrates a conventional data processing machine or
computer. The computer 10 comprises a processor or CPU 12, a main memory
14 and a disk memory 16 which are interconnected by a bus 18. Also
connected to the bus 18 is an input device 20, such as a keyboard, as well
as a display system 22. The display system 22 comprises a graphics
interface 24 and display device 26 such as a CRT display.
The CPU 12 may maintain databases by storing the databases in data files in
the disk memory 16. Each database may be stored in accordance with one of
a plurality of file system formats. A file system format is an arrangement
for organizing the data of each record of a database into a data file. The
organization of the data of each record of a database within the data file
controls the manner in which the database may be accessed.
Typically, the CPU 12 executes application programs which are resident in
the main memory 14. An application is a program for performing a "high
level" task or a task on a higher level of generality. Such "high level"
tasks relate more to solving real world problems than "low level" tasks
which relate more to operating the CPU 12 itself. Many applications
involve the examination and alteration of the data of records of
databases, which, for example, are stored in the disk memory 16. The
application performs such manipulations of the data of records by means of
executing record access procedures comprised therein.
Typically, procedures are program segments written for, and comprised
within, an application program. Record access procedures ordinarily only
access the records themselves, rather than the data files in which they
are stored. For instance, record access procedures may maintain
(manipulate the data of) records or permit the browsing of records, e.g.,
permit the display of a selected page of records. The former procedures
relate to altering a record including adding and removing records from the
database. The latter procedures relate to displaying selected records
including filtering or displaying only selected fields of each record.
Maintenance procedures usually require the performance of at least one
database access operation in order to alter or retrieve records of the
database. Database access operations are generalized routines for
maintaining a database, retrieving records from a database and positioning
a pointer to point to a particular record within a database. Typically,
the database access operations are performed by executing a program module
pertaining to that particular operation and the particular file system
format in which the database is stored. The file system, which has a
program module for performing each database access operation, executes the
appropriate program module to perform the requested access operation. The
procedures of the application may call the modules, pass parameters to and
receive messages and parameters therefrom. The procedures are otherwise
typically isolated from the program modules and the data files in which
the database is stored.
Most file systems support, i.e. can perform, the same basic set of database
access operations. However, on account of the differences between
different database storage formats of different file systems, the actual
steps executed by each program module differ greatly. Thus, each
application, although able to use the same logical sequence of each
procedure, must accommodate the program modules of a variety of file
systems in order to execute these procedures. Such an arrangement, whereby
the applications themselves incorporate the record access procedures, is
disadvantageous because:
1. The design of each application program, under this arrangement, is more
time consuming and effort demanding;
2. The expansion of applications is more difficult;
3. The record access procedure command set, i.e. the set of requests for
performing each record access procedure, of each application program, is
not consistent with any other application; and
4. The efficiency of application software is not optimal.
The interaction of an application program with the database operations of a
multiplicity of file system formats is schematically illustrated in FIG.
2. FIG. 2 schematically illustrates the group of operation program modules
for three different file systems designated file system 1, file system 2
and file system 3. Each of the file systems has a corresponding group of
databases in data files which accord with its own format. Each file system
also provides program modules for executing database access operations
such as: set current record position, get current record position, get
first record, get previous record, get next record, get last record,
insert one new record, delete current record, update current record, and
select current record.
FIG. 2 also schematically illustrates two application programs, designated
application A and application B. Application A interacts directly with the
file system 1 and file system 2 program modules and application B
interacts directly with the file system 2 and file system 3 program
modules. As such, application A incorporates record access procedures
which support, i.e. can cause the execution of, the database access
operation program modules of file systems 1 and 2. Application B, on the
other hand, incorporates record access procedures which support the
database access operation program modules of file systems 2 and 3. As
indicated above, the direct interaction of the application programs with
the file system program modules is highly deleterious and duplicative.
Accordingly, it is an object of the present invention to provide a common
interface by which application programs may perform record access
procedures which support, i.e. can perform, database access operations for
any one of a plurality of file system formats. Another object of the
present invention is to insulate the applications from the various file
system program modules. It is a further object of the present invention to
provide a universal record maintenance procedure command set, i.e. a
single set of messages for performing each record access procedure, which
may be used by any application.
SUMMARY OF THE INVENTION
As indicated above, in a data processing machine, a user application often
needs to access the records of databases stored in accordance with any one
of a plurality of file system formats. Records are manipulated by record
access procedures which in turn require the performance of database access
operations. Each file system incorporates many of the same database access
operations. However, because of differences in the actual data storage
formats used by different file systems, these similar database access
operations are executed in very different manners. This requires the
record maintenance procedures to accommodate many different program
modules to effect the same data access operation for different file system
formats.
The present invention provides a record maintenance interface which has a
group of procedures including a set of record access procedures. The
record access procedures support, i.e., can perform, a set of database
access operations by maintaining program modules for a variety different
file system formats. The record maintenance interface receives commands,
or messages requesting the execution of particular record access
procedures, from the user or application. These commands are from a single
set and are independent of the particular filing system format in which
the database is organized. Illustratively, commands to execute the
following record access procedures may be received by the record
maintenance interface:
(a) Browsing procedures
Move Up One Line
Move Down One Line
Move To Top Of Page
Move To End Of Page
Scroll One Page Up
Scroll One Page Down
Display From Top Of File
Display From End Of File
(b) Record maintenance procedures
Insert One Output Line
Delete Current Line
Update Current Line
Select Current Line
In the execution of these procedures one or more database access operations
may also be performed such as:
(a) Record positioning operations
Get Current Record Position
Set Current Record Position
(b) Record retrieval operations
Get First Record
Get Previous Record
Get Next Record
Get Last Record
Get Current Record
(c) Record maintenance operations
Insert One New Record
Delete Current Record
Update Current Record
Select Current Record
Illustratively, the record access procedures are requested by commands or
messages issued from an input/output device, such as a keyboard and
display system, or by an application. When a command is received by the
record maintenance interface (RMI), the requested record access procedure
is executed by a CPU. The execution of a record access procedure may
require the performance of one or more database access operations. If such
is the case, the RMI points to the specific program module that must be
executed. The program module is selected in accordance with the file
system format of the database and the desired operation to be carried out.
The specific program module is then executed by the CPU of the data
processing machine.
In the execution of various procedures, including the record access
procedures, different messages may be generated. Some relate to an error
condition triggered by the failed attempt to perform a step such as a
failed attempt to execute a program module. Other messages merely
communicate the effect of the successful execution of the requested record
access procedure on the record or database of interest. The RMI
illustratively communicates messages relating to the execution of
procedures to the input/output device or application.
Use of the RMI of the present invention has a number of significant
advantages:
1. The application program is easier to maintain as the application
programmer need not maintain the database interface aspect of the program.
Further, as the record management interface is updated, the database
aspect of each user application is automatically updated or subsequently
easily updated.
2. Record access procedures occur on a higher level of generality. In other
words, the programmer need not be concerned with the particulars of
designing any of the procedures of the interface. Further, the programmer
need not be concerned with determining which filing system formats to
support, i.e. which file system program modules to incorporate.
3. The user and programmer need only learn one general set of record access
procedure commands rather than a set for each application.
4. The storage space of each application which performs record access
procedures is reduced as the record access procedures are removed and
consolidated in one program.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 depicts a conventional data processing machine.
FIG. 2 schematically illustrates the traditional interaction of application
programs and databases of multiple file system formats.
FIG. 3A schematically illustrates the interaction of application programs
with databases of multiple file system formats via a record maintenance
interface.
FIG. 3B schematically illustrates the performance of a record access
operation of an application interacting with a record maintenance
interface.
FIG. 4 schematically illustrates, with greater detail, the interaction of
an application program with the record maintenance interface.
FIG. 5 depicts a flow chart illustrating the Main procedure.
FIG. 6 is a flow chart illustrating the execution of the RMI.
FIG. 7 is a flow chart illustrating the Display One Page procedure.
FIG. 8 is a flow chart illustrating the Get First Output Line procedure.
FIG. 9 is a flow chart illustrating the Get Next Output Line procedure.
FIG. 10 is a flow chart illustrating the Filter Record procedure.
FIG. 11 illustrates the formatting of an output line by the Filter Record
procedure.
FIG. 12 is a flow chart illustrating the Accept and Process Commands
procedure.
FIG. 13 is a flow chart illustrating the Insert One New Record procedure.
FIG. 14 is a flow chart illustrating the Delete Current Record procedure.
FIG. 15A is a flow chart illustrating the Update Current Record procedure.
FIG. 15B is a flow chart illustrating the Edit Record procedure.
FIG. 16 is a flow chart illustrating the Select Current Record procedure.
FIG. 17A is a flowchart illustrating the Move Down One Line procedure.
FIG. 17B illustrates the effect of moving down one line on the list window
as per the Move Down One Line procedure.
FIG. 17C is a flowchart illustrating the Scroll Up One Line procedure.
FIG. 17D illustrates the effect of moving down one line on the list window
as per the Scroll Up One Line procedure.
FIG. 18 is a flow chart illustrating the steps for pointing to the program
module of a particular file system for any database access operation.
DETAILED DESCRIPTION OF THE INVENTION
FIG. 3A schematically depicts the interaction of two application programs
denoted application A and application B with databases stored in data
files. These data files are stored in one of three file system formats
denoted file system 1, file system 2 and file system 3. The interaction
with the databases is via a record management interface (RMI).
FIG. 3B schematically depicts the execution of an application and its
interrelationship with the RMI. The application 30 or user 40 via an input
device 20 (FIG. 1), issues a command or message requesting the execution
of a particular record access procedure. The record access procedures are
stored in the CPU 12, main memory 14 or disk memory 16 (FIG. 1).
Preferably, they are stored in the main memory 14 (FIG. 1). These commands
are received by the RMI 36 and processed by an Accept and Process Commands
procedure 35 comprised therein. The execution of the Accept and Process
Commands procedure 35 by the CPU 12 (FIG. 1) is discussed in greater
detail below. The requested procedure 37-1, 37-2 or 37-3, i.e., the record
access procedure corresponding to the issued command, is then executed by
the CPU 12 (FIG. 1).
The execution of the procedures 37-1 to 37-3 may require the performance of
at least one database access operation 39, 41, 43, 45. In order to perform
a particular database access operation 39, 41, 43 or 45, the particular
program module 39-1, . . . , 39-N, 41-1, . . . , 41-N, 43-1, . . . , 43-N,
45-1, . . . , 45-N of the file system 32-1, 32-2 or 32-3 in which the
database is stored, and which performs the desired operation 39, 41, 43 or
45, must be executed by the CPU 12 (FIG. 1). For example, to perform the
database access operation 39 on a database maintained by the file system
34-2, the program module 39-2 is selected and executed. The program
modules may be stored in the CPU 12 (FIG. 1), the main memory 14 (FIG. 1)
or the disk memory 16 (FIG. 1). Typically, they are stored in the disk
memory 16 (FIG. 1). The RMI 36 points to the location of the program
module 39-1, . . . , 39-N, 41-1, . . . , 41-N, 43-1, . . . , 43-N, 45-1, .
. . , 45-N pertaining to the file system 34-1, 34-2 or 34-3 which
maintains the database of interest of the desired operation 39, 41, 43 or
45 and issues a request to the CPU 12 (FIG. 1) to execute it. The CPU 12
(FIG. 1) then executes the program module 39-1,. . . , 39-N, 41-1, . . . ,
41-N, 43-1, . . . , 43-N, 45-1, . . . , 45-N of the file system 34-1, 34-2
or 34-3 pointed to by the RMI. This program module 39-1, . . . , 39-N,
41-1, . . . , 41-N, 43-1, . . . , 43-N, 45-1, . . . , 45-N accesses a
database stored in the data file 32-1, 32-2 or 32-3 maintained by the file
system 34-1, 34-2 or 34-3.
Referring now to FIG. 4, the interaction of the RMI 36 with an application
30 or user 40 is schematically illustrated in greater detail. An
application 30 or user 40 first opens the data file 32 containing the
records of interest. This is achieved by issuing an "open" request to the
CPU 12 (see FIG. 1). In response to a successful execution of the open
command, a file pointer pointing the opened file is returned to the
application 30 or user 40. The application 30 or user 40 transmits this
pointer to the RMI 36 which maintains it as depicted in block 44-1. Also,
the application 30 or user 40 prepares the Edit Record Data and Filter
Record procedures. In this manner, the user 40 or application 30 may
select one of a plurality of Edit Record Data and Filter Record procedures
supported by the RMI 36 for use in a particular session. These procedures,
depicted in blocks 40-2 and 40-3 will be discussed in greater detail
below.
After opening the file 32, the application 30 may perform record access
procedures by issuing commands from a file system independent set to the
RMI 36 via a first communication channel 38. In response thereto, the RMI
36 executes procedures, including the requested procedures, and
communicates various messages back to the application 30 via the first
communication channel 38.
Alternatively, the RMI 36 may be executed in an interactive session with
the user 40 via the input device 20 (see FIG. 1) and display system 22
(see FIG. 1). In such a case, as discussed in greater detail below, the
RMI 36 maintains a list window 42 on the display device 26 (FIG. 1). The
RMI 36 receives commands from the user 40 via the input device 20 (FIG. 1)
and communicates messages back to the user 40 via the list window 42.
Upon receiving a command from either the application 30 or the user 40, the
RMI 36 executes, among other procedures, the requested record access
procedure. As depicted in the block 44, at least two procedures are
maintained in the computer 10 (FIG. 1) by the RMI 36, an Edit Record Data
procedure 44-3 and an Output Line Filter procedure 44-2. These procedures,
and others will be discussed in greater detail below.
In the execution of a record access procedure, a database operation may
also need to be performed. In such a case, the RMI 36 points to the
appropriate database access operation program module. The module is
selected depending on the desired data access operation and the file
system format 34 in which the database containing the record of interest
is stored.
After pointing to a particular program module, the RMI 36 then issues a
request to the CPU 12 (FIG. 1) via a second communication channel 46 to
execute it. Upon the successful execution of the program module, a message
may be returned to the RMI 36 such as a record retrieved from the data
file 32. Alternatively, the RMI 36 may receive an error message indicating
a failed attempt to execute a program module. These messages are
transmitted by the CPU 12 (FIG. 1) via the same communication channel 46.
When the application 30 or user 40 desires to cease using the RMI 36 the
user 40 or application 30 issues a "close" command to the CPU 12 (FIG. 1).
This closes the data file 32 used during the session. With the exception
of opening and closing the data files, the user 40 or application 30 is
isolated from the low-level detail of accessing the database.
Thus, an application program 30, or the user 40 in an interactive session,
may access the records of a database using the RMI 36. The access
procedures provided by the RMI 36 include browsing the records of a
database, updating the records of a database and inserting or deleting new
records into a database. The operation of the RMI 36 and these procedures
is discussed in greater detail below.
Turning now to FIG. 5, an exemplary Main procedure or program segment of an
application 30 is schematically illustrated. This procedure is initiated
by the application 30. Execution begins with step 100 where the data file
32 (FIG. 4) containing the database of interest is opened by the
application program 30 (FIG. 4) or user 40 (FIG. 4). Next execution
proceeds to step 102 where it is determined if the file was successfully
opened. If not, execution of the Main procedure jumps to step 116 and
ceases. If the database file was successfully opened, execution continues
with step 104 where the Edit Record Data and Filter Record procedures are
prepared. These procedures are discussed in greater detail below.
Execution then continues with step 106 where space for a record buffer and
output line variable are allocated. Since a particular record may be of
any length, a variable storage space must be allocated for temporarily
storing records. Additionally, the output line variable will also be of
variable length depending upon the mode of execution. If an application
program 30 (FIG. 4) will receive the output, then the output line variable
needs to support the display of an output line of any length. If the RMI
36 (FIG. 4) is executed in user interactive mode, the output line variable
must support the width of one line which may be displayed in the list
window 42 (FIG. 4) defined by the user 40 (FIG. 4). As such, the length of
the output line will vary and space must be allocated appropriately.
Execution next continues with the step 108 where a file pointer for saving
parameters is allocated. The allocation of the file pointer depends upon
what parameters are associated with each data file of a particular file
system format. For instance, the Btrieve file system format requires
allocation for the following parameters: the position block, record buffer
address, record buffer length, key buffer address and key. Thus, in this
step 108, the Main procedure allocates space for the file pointer
parameters in accordance with the file system format of the particular
opened data file.
After allocating the file pointer, execution then proceeds to step 110
where the Main procedure determines the dimensions and location of the
list window 42 (FIG. 4) (if in user interactive mode). Preferably, the
user 40 (FIG. 4) is queried via the display device 26 (FIG. 1) as to the
height and width of the list window 42 (FIG. 4) and its location. In
response thereto, the user 40 (FIG. 4) enters via the input device 20
(FIG. 1) the desired dimensions and coordinates. The RMI 36 (FIG. 4) then
opens a list window 42 (FIG. 4) on the display device 26 (FIG. 1) for
communicating the status of executed procedures, including record access
procedures, to the user 40 (FIG. 4).
Execution next proceeds to step 112, where the Main procedure initiates the
RMI 36 (FIG. 4). Therein, the RMI 36 (FIG. 4) receives record access
procedure commands from the user 40 (FIG. 4) via the input device 20 (FIG.
1) or the application 30 (FIG. 4) via a first communication channel 38
(FIG. 4). The execution of this procedure will be discussed in greater
detail below. The RMI 36 (FIG. 4) communicates the status of requested
procedures to the user 40 (FIG. 4) via the list window 42 (FIG. 4) or to
the application 30 (FIG. 4) via the communication channel 38 (FIG. 4). The
RMI 36 (FIG. 4) is executed until the user 40 (FIG. 4) or the application
30 (FIG. 4) decides to end the session. Execution then returns to the Main
procedure at step 114 whereby all opened data files are closed by the user
40 (FIG. 4) or application 30 (FIG. 4). Execution then proceeds to step
116 of the Main procedure and ceases.
Turning now to FIG. 6, execution of the RMI (called in step 112 of FIG. 5)
is schematically shown in greater detail. Upon the calling of the RMI,
execution begins at step 120 where a list window 42 (FIG. 4) is opened in
accordance with the specifications (i.e., position and dimensions) entered
by the user 40 (FIG. 4) at step 110 (see FIG. 5). In the case of user 40
(FIG. 4) interaction, the RMI 36 (FIG. 4) transmits messages to the list
window 42 (FIG. 4) of the display device 26 (FIG. 1). Execution then
continues with step 122 where the first page of output lines is placed in
the list window 42 (FIG. 4) by executing the procedure Display One Page Of
Output Lines for the first page. Execution of this procedure will be
discussed in greater detail below.
Next, step 123 is executed wherein the active line variable is set to "1"
or the first line. This variable is used in user interactive mode for
highlighting the record of interest in the window, i.e., the record which
the user 40 desires to examine or edit. Initially, as will be discussed
below, the first page of records is displayed in the list window 42 (FIG.
4). As such, it makes sense to initially point to the first record (which
is initially displayed on line "1").
Execution then continues with step 124 where the user 40 (FIG. 4) or
application 30 (FIG. 4) commands are accepted by the RMI 36 (FIG. 4) and
processed. As will be discussed in greater detail below, the user 40 (FIG.
4) or application 30 (FIG. 4) may request one of a number of record
browsing or maintenance procedures by issuing the appropriate command. The
RMI 36 (FIG. 4) accepts these commands and executes the requested record
access procedures until the user 40 or application 30 (FIG. 4) desires to
end the session. Execution then continues with step 126 where the list
window 42 (FIG. 4), if opened, is closed. Thereafter, in step 128,
execution of the RMI ceases and execution control returns to step 114 of
the Main procedure (see FIG. 5).
In FIG. 7 the Display One Page Of Output Lines procedure (which is executed
in step 122 of FIG. 6, for instance) is schematically illustrated in
greater detail. This procedure is executed in conjunction with the user
interactive mode of operating the RMI 36 (FIG. 4). This procedure actually
outputs the examined records for display in the list window 42 (FIG. 4)
and comprises the following steps. The list window 42 (FIG. 4) is cleared
in a first step 162. Execution then continues with step 164 in which a
line number counter is set to one. This counter is used to indicate the
next line of the list window 42 (FIG. 4) which is to receive record data
for display.
Execution then continues with step 166 which determines whether the output
line variable is currently blank. This variable is used to temporarily
store formatted record data to be displayed on one line of the list window
42 (FIG. 4) (the formatting of record data is discussed in greater detail
below). If this variable is blank then either no records in the database
of interest have yet been displayed (or retrieved) or the end of the
database has been reached. In either case, it is desireable to display the
first page of output lines (i.e., a page of the first group of records of
the database). Hence, if the output line variable is blank, then execution
continues with step 168 in which the Get First Output Line procedure is
executed. Otherwise, execution continues with step 170. As will be
discussed in greater detail below, the Get First Output Line procedure
performs several steps including returning a formatted output line, which
is placed into the output line variable, if its execution was successful.
In the step 170, a determination is made as to whether there is an output
line to be displayed. The determination must be affirmative if the output
line was determined not to be blank at the step 166. However, in the case
that the line was blank at step 166 a subsequent determination is made to
determine if the Get First Output Line procedure was successful in
obtaining a formatted output line for display. If there is no output line
to be displayed, execution jumps to step 186 and the Display One Page Of
Output Lines procedure ends.
If there is an output line for display, then execution proceeds to step
172. In this step 172, the formatted output line, that is, the contents of
the output line variable, are displayed on the line of the display device
26 (see FIG. 1) indicated by the line number variable. Execution then
continues with step 174 where the database access operation Get Current
Record Position is performed. This operation is one of the basic database
operation supported by all file systems. As such, the RMI 36 (FIG. 4)
points to the particular Get Current Record Position module pertaining to
the file system format in which the database of the records of interest is
stored. This selection process will be discussed in greater detail below.
The purpose of this operation is to enable the RMI 36 (FIG. 4) to keep
track of the current record of interest. Preferably, in the user
interactive mode, the RMI 36 (FIG. 4) indicates the record of interest to
the user 40 (FIG. 4) by highlighting it on the display device 26 (see FIG.
11).
Execution then continues with step 176 where the current record position,
returned by the Get Current Record Position module, is temporarily stored.
Should the user 40 (FIG. 4) or application 30 (FIG. 4) desire to alter a
record, the RMI 36 (FIG. 4) can use this record position value to cause
the execution of the changes on the desired record of the database.
Execution then continues with step 180 where the line counter is
incremented. At this point it is desireable to determine whether the list
window 42 (FIG. 40), as dimensioned by the user 40 (FIG. 4), can display
another line. Thus, in line 182 such a determination is made by comparing
the line number counter to the maximum number of page lines supported by
the list window 42 (FIG. 4). If this maximum number is exceeded then
execution continues with step 186 in which execution of the Display One
Page Of Output Lines procedure ceases and returns to the procedure from
which it was called.
If more lines can be displayed, execution continues with step 184 where the
Get Next Output Line procedure is executed. As will be discussed in
greater detail below, this procedure retrieves the next record and causes
it to be filtered (also discussed in greater detail below). After step
184, execution loops back to step 170 in which a determination is made as
to whether a formatted output line is available for display. In this case,
step 170 determines if the Get Next Output Line procedure was successful.
Thus, execution loops through steps 170 through 184 until either no more
output lines are available for display or no more lines of data may be
displayed in the list window 42 (FIG. 4).
Turning now to FIG. 8 the Get First Output Line procedure (executed, for
example, by step 168 of FIG. 7) is schematically shown in greater detail.
First, step 190 is executed in which the Get First Record module,
pertaining to the file system format of the database containing the record
of interest, is pointed to and executed. Again, as with all program
modules, the Get First Record module is selected in accordance with the
particular file system format of the database. This selection process will
be discussed in greater detail below. The Get First Record operation
returns the first record of the database.
Execution next proceeds with step 192 in which the CPU 12 (FIG. 4)
determines whether the execution of the Get First Record operation of step
190, moved the internal file system pointer to the end of the data file.
If the end of the file 32 (FIG. 4) was reached, meaning that no records
subsequent to the last accessed record exist in the data file 32 (FIG. 4),
execution proceeds to step 200 and ceases. If not, then execution
continues with step 194 in which the Filter Record procedure, which will
be discussed in greater detail below, is executed. The Filter Record
procedure extracts the data of particular fields of interest from a record
and returns the data in a formatted output line.
Next, in step 196 it is determined whether the Filter Record procedure has
returned a formatted output line. If not, this indicates that a blank
record was read from the database and the module Get Next Record module is
pointed to and executed in step 98. Again, as with all program modules,
the particular program module pointed to is selected in accordance with
the file system of the database and will be discussed in greater detail
below. This operation retrieves the next record of the database. If in
step 196 a formatted record is returned then execution continues with step
200.
Execution from steps 192 or 196 continues with step 200 where the procedure
ends or remains locked in the loop of steps 192-198. Execution remains in
this loop only in the case that a blank record was read and the end of the
file 32 (FIG. 4) has not been reached. This proceeding through steps
192-198 will continue for each blank record retrieved from the database.
Finally, either the end of the data file 32 (FIG. 4) will be reached (and
execution will branch to step 200 via step 192) or a non-blank record will
be retrieved (and execution will branch to step 200 via step 196). Thus,
all blank records are skipped by this procedure and only records with data
are returned.
If either a non-blank record is retrieved or the end of the file is
reached, execution proceeds to step 200 in which the Get First Output Line
procedure ends. Execution then returns to the calling procedure.
Additionally, a formatted output line (if the procedure was successful) is
returned.
Turning now to F | | |
