 |
Description  |
|
|
BACKGROUND OF THE INVENTION
2. Field of Use
This invention relates generally to a method for storing data in a
distributed processing, interactive computer network intended to provide
very large numbers of simultaneous users; e.g. millions, access to an
interactive service having large numbers; e.g., thousands, of applications
which include pre-created, interactive text/graphic sessions; and more
particularly, to a method for storing data used in generating such
applications, the method featuring steps for establishing data stores, the
stores including first store portions maintained during data usage
sessions and second store portions maintained during and between data
usage sessions, the method also featuring steps for associating storage
control parameters with the data, steps for supplying data to the stores
in excess of store capacity, and steps for deleting data from the stores
on a least-recently-used basis, so that data is retained at the stores
dependent on the storage control parameters and data usage experience.
2. Prior Art
Interactive computer networks are not new. Traditionally they have included
conventional, hierarchical architectures wherein a central, host computer
responds to the information requests of multiple users. An illustration
would be a time-sharing network in which multiple users, each at a remote
terminal, log onto a host that provides data and software resource for
sequentially receiving user data processing requests, executing them and
supplying responses back to the users.
While such networks have been successful in making the processing power of
large computers available to many users, problems have existed with them.
For example, in such networks, the host has been required to satisfy all
the user data processing requests. As a result, processing bottlenecks
arise at the host that cause network slowdowns and compel expansion in
computing resources; i.e., bigger and more complex computer facilities,
where response times are sought to be held low in the face of increasing
user populations.
Host size and complexity, however, are liabilities for interactive networks
recently introduced to offer large numbers of the public access to
transactional services such as home shopping, banking, and investment
maintenance, as well as informational services concerning entertainment,
business and personal matters.
As can be appreciated, commercial interactive networks will have to provide
attractive services at low cost and with minimal response times in order
to be successful. Unlike military and governmental networks where, because
of the compulsory nature of the service performed, costs, content and
efficiency are of secondary concern, in commercial services, since use is
predominantly elective, and paid for by the consumer, costs will have to
be held low, content made interesting and response times reduced in order
to attract and hold both users who would subscribe to the service and
merchandisers who would rely on it as a channel of distribution for their
good and services. Accordingly, and as will be appreciated, the ability of
the network to rapidly satisfy large numbers of user requests with minimal
resources is fundamental to the ultimate success of the network.
As pointed out in our parent application, Ser. No. 388,156 filed Jul. 28,
1989, now issued as U.S. Pat. No. 5,347,632, breakthrough performance
improvement, essential to the feasibility of broad-based, interactive
services can be realized by storing application data local to the user
sites and relying on the user site computing resources to manage the
interactive session. As more fully described in our parent application, by
locating application data closer to the user, for example, at the user
terminal configured as a reception system and/or a concentrator facility
hierarchically disposed between the reception system and the service host,
line traffic and associated response time that would otherwise be required
to retrieve data from a conventional, time-share host can be substantially
reduced. Further, since the host and concentrator computers of the
reception-system based systems we described can be configured as server
facilities, they can be provided substantially less expensively than
conventionally time-share hosts, thereby, reducing the capital and
operating costs required for the service.
However, formulating storage facilities for use in such a network is not
without significant problems. As will be appreciated, the amount of
storage capacity available at conventional user sites, and for that
matter, concentrator facilities, is limited. Accordingly, because of
capacity limitations, it would not be physically and economically
practical to attempt to store the entire service database at the reception
system or concentrator sites. Further, even if storage capacity sufficient
to accommodate substantial portions, if not all, of the service database
could be provided, the need to maintain the application data current would
foreclose storing all data locally or at the concentrator. As will be
appreciated, the data for numerous applications of a successful
interactive service must remain current for the service to be commercially
viable. News stories, stock quotes, prices of goods, as well as items like
airline and entertainment seating and scheduling are all time sensitive
and must be regularly updated to avoid inconvenience and potential legal
liability. Accordingly, even if all data could be provided locally, it
would be unwise and objectionable to do so.
SUMMARY OF INVENTION
Accordingly, it is an object of this invention to provide a method for
storing data in an interactive-service network.
It is another object of this invention to provide a method for storing data
in an interactive-service network, which method reduces communication line
traffic required to support the service at user sites.
It is still another object of this invention to provide a method for
storing data in an interactive-service network, which method allows
adequate amounts of data to be stored in limited-capacity storage
facilities.
It is yet another object of this invention to provide a method for storing
data in an interactive-service network, which method allows for
maintaining currency of the data used to present applications.
It is a again a further object of this invention to provide a method for
storing data in an interactive-service network which method automatically
configures the data stores to include data tailored to the service usage
experience.
Briefly, the method for storing data in accordance with this invention
achieves the above-noted and other objects by featuring steps for
establishing data stores of prescribed capacities within the network from
which data may be obtained for generating the service applications during
user sessions. Further, the method features steps for associating storage
control parameters with the application data to be stored and supplying
data to the respective stores in excess of their respective capacities.
Yet further, the method features steps for retaining data at the stores
based on the respective prescribed storage control parameters and the
date-usage experience at the respective stores.
In accordance with the invention, data stores are established within the
service network, preferably at least at the user reception system, and, if
provided, also at network concentrator facilities hierarchically located
between the reception system and the network host. The size of the
respective stores depends on the available resources; i.e., RAM and disk
memory, and is allocated between a temporary cache and variable-content
permanent stage, the cache being provided at available RAM and a fixed
disk file, and the stage being configured as a variable-content, fixed
disk file. In accordance with the invention, data stored during a data-use
session; e.g., a user interactive session, is stored at the cache
distributed between RAM and the cache disk file, while data retained
between data-use sessions is stored at the stage permanent disk file.
As a further feature of the invention, data is supplied to the respective
stores in excess of their respective capacities, and in preferred form
excess data is deleted in accordance with a least-recently-used criterion
and storage candidacy conditions ascribed to the data. Still further, in
preferred form a version storage control parameter may also be applied.
In operation, as data is supplied to the store; for example, a reception
system store during a user interactive session, data is retained at the
store based on the available cache space within the store; i.e., reception
system available RAM and designated disk file. Particularly, data items
designated by a data identification number are placed on a list of
recently called data items, the most recently called items being at the
top of the list. As new data is called, it pushes previously called data
down on the list, with the result that a data item pushed below the list
capacity forfeits its presence on the list if not recalled before being
pushed off. If data is recalled during a session, it once more is promoted
to the top of the data list. At the end of a session, data items at the
cache are written to a stage least-recently-used list, the stage retaining
data items between sessions in the same fashion the cache retains data
during a session. The result is, over a series of sessions, the stage
automatically configures itself; i.e., self-configures, with the data most
often called. And, as will be appreciated, where the most frequently
called data is retained, the efficiency of the limited capacity store to
reduce response time is maximized; i.e., need for line data requests is
minimized by having data tailored to the user readily available.
Also in accordance with the invention, to insure currency is maintained for
time-sensitive data; as for example, data relating to news, pricing,
availability, etc., storage candidacy and version control parameters are
impressed on the data to avoid storage of data considered too sensitive to
be maintained on a least-recently-used basis alone. In preferred form, a
range of storage candidacy values are provided and ascribed to the data
that dictate whether the respective data can be stored beyond the user
session or between user sessions. In this regard, multiple storage
qualifying categories can be established with a combination of control
parameters concerning data version, storage candidacy value and
application of the least-recently-used criterion above described.
Yet further, in preferred form, the application data is organized as
objects having a header with one or more data segments, the header being
formulated to include the data identification, storage candidacy, and
version storage control parameters. Still further, in accordance with the
preferred form, the storage method may be applied to all levels of storage
in the interactive-service network; i.e., reception system, concentrator
facility and host.
DESCRIPTION OF THE DRAWINGS
The above and further objects, features and advantages of the invention
will become clear from the following more detailed description when read
with reference to the accompanying drawings in which:
FIG. 1 is a block diagram of the interactive computer network in which the
data-storage method of the present invention may be employed;
FIG. 2 is a schematic diagram of the network illustrated in FIG. 1;
FIG. 3a and 3b are plan views of a display screen for a user reception
system employed in a network in which the data-storage method of the
present invention may be practiced;
FIGS. 4a, 4b and 4c are schematic drawings that illustrate the structure of
objects, and object segments that may be used in a network in which the
data-storage method of the present invention may be employed;
FIG. 5 is a schematic diagram that illustrates major layers for a reception
system which might be used for supporting applications in a network in
which the data-storage method of the present invention may be practiced;
FIG. 6 is a block diagram that illustrates native code modules for a
reception system which might be used for supporting applications in a
network in which the data-storage method of the present invention may be
practiced;
DESCRIPTION OF THE PREFERRED EMBODIMENT
General System Description
FIGS. 1 and 2 show a network in which the method of the present invention
for storing data might be used. As seen the network, designated 10, and
described more fully in U.S. Pat. No. 5,347,632, the contents of which are
incorporated herein by reference, includes a plurality of reception units
within a reception layer 401 for displaying information and providing
transactional services. In this arrangement, many users each access
network 10 with a conventional personal computer; e.g., one of the IBM or
IBM-compatible type, which has been provided with application software to
constitute a reception system (RS) 400.
As seen in FIG. 1, interactive network 10 uses a layered structure that
includes an information layer 100, a switch/file server layer 200, and
cache/concentrator layer 300 as well as reception layer 401. This
structure maintains active application databases and delivers requested
parts of the databases on demand to the plurality of RSs 400, shown in
FIG. 2. As seen in FIG. 2, cache/concentrator layer 300 includes a
plurality of cache/concentrator units 302, each or which serve a plurality
of RS 400 units over lines 301. Additionally, switch/file server layer 200
is seen to include a server unit 205 connected to multiple
cache/concentrator units 302 over lines 201. Still further, server unit
205 is seen to be connected to information layer 100 and its various
elements, which act as means for producing, supplying and maintaining the
network databases and other information necessary to support network 10.
Continuing, switch/filer layer 200 is also seen to include gateway systems
210 connected to server 205. Gateways 210 couple layer 200 to other
sources of information and data; e.g., other computer systems. As will be
appreciated by those skilled in the art, layer 200, like layers 401 and
300, could also include multiple servers, gateways and information layers
in the event even larger numbers of users were sought to be served.
RS 400 formulated in this fashion is capable of communication with the host
system to receive information containing either of two types of data,
namely objects and messages. Objects have a uniform, self-defining format
known to RS 400, and include data types, such as interpretable programs
and presentation data for display at monitor screen 414 of the user's
personal computer 405. Applications presented at RS 400 are partitioned
into objects which represent the minimal units available from the higher
levels of interactive network 10 or RS 400. In this arrangement, each
application partition typically represents one screen or a partial screen
of information, including fields filled with data used in transactions
with network 10. Each such screen, commonly called a page, is represented
by its parts and is described in a page template object, discussed below.
Applications, having been partitioned into minimal units, are available
from higher elements of network 10 or RS 400, and are retrieved on demand
by RS 400 for interpretive execution. Thus, not all partitions of a
partitioned application need be resident at RS 400 to process a selected
partition, thereby raising the storage efficiency of the user's RS 400 and
minimizing response time. Each application partition is an independent,
self-contained unit and can operate correctly by itself. Each partition
may refer to other partitions either statically or dynamically. Static
references are built into the partitioned application, while dynamic
references are created from the execution of program logic using a set of
parameters, such as user demographics or locale.
Objects provide a means of packaging and distributing partitioned
applications. As noted, objects make up one or more partitioned
applications, and are retrieved on demand by a user's RS 400 for
interpretive execution and selective storage. All objects are interpreted
by RS 400, thereby enabling applications to be developed independently of
the personal computer brand used.
Objects may be nested within one another or referenced by an object
identifier (object-id) from within their data structure. References to
objects permit the size of objects to be minimized. Further, the time
required to display a page is minimized when, in accordance with the
method of the present invention, referenced objects are stored locally at
RS 400 (which storage is determined by prior usage meeting certain
retention criteria to be described more fully below), or have been
pre-fetched, or in fact, are already used for the current page.
RS 400 includes a means to communicate with network 10 to retrieve objects
in response to events occurring at RS 400 and to send and receive
messages.
In accordance with the method of the present invention, RS 400 includes a
means to selectively store objects according to a predetermined storage
criterion, thus enabling frequently used objects to be stored locally at
the RS, and causing infrequently used objects to forfeit their local
storage location. The currency of objects stored locally at the RS 400 is
verified before use according to the object's storage control parameters
and the storage criterion in use for version checking.
Selective storage tailors the contents of the RS 400 memory to contain
objects representing all or significant parts of partitioned applications
favored by the user. Because selective storage of objects is local,
response time is reduced for those partitioned applications that the user
accesses most frequently.
Since much of the application processing formerly done by a host computer
in previously known time-sharing networks is now performed at the user's
RS 400, the higher elements of network 10, particularly layer 200, has as
their primary functions the routing of messages, serving of objects, and
line concentration. The narrowed functional load of the higher network
elements permits many more users to be serviced within the same bounds of
computer power and I/O capability of conventional host-centered
architectures.
SYSTEM CONFIGURATION
As shown in FIG. 1, interactive computer network 10 includes four layers:
information layer 100, switch and file server layer 200, concentrator
layer 300, and reception layer 401.
There are two types of information in the network 10 which are utilized by
the RS 400: objects and messages.
Objects include the information requested and utilized by the RS 400 to
permit a user to select specific parts of applications, control the flow
of information relating to the applications, and to supply information to
the network. Objects are self-describing structures organized in
accordance with a specific data object architecture, described below.
Objects are used to package presentation data and program instructions
required to support the partitioned applications and advertising presented
at a RS 400. Objects are distributed on demand throughout interactive
network 10. Objects may contain: control information; program instructions
to set up an application processing environment and to process user or
network created events; information about what is to be displayed and how
it is to be displayed; references to programs to be interpretively
executed; and references to other objects, which may be called based upon
certain conditions or the occurrence of certain events at the user's
personal computer, resulting in the selection and retrieval of other
partitioned applications packaged as objects.
Messages are information provided by the user or the network and are used
in fields defined within the constructs of an object, and are seen on the
user's RS monitor 412, or are used for data processing at RS 400.
Additionally, and as more fully described hereafter, messages are the
primary means for communication within and without the network. The format
of messages is application dependent. If the message is input by the user,
it is formatted by the partitioned application currently being processed
on RS 400. Likewise, and with reference to FIG. 2, if the data are
provided from a co-application database residing in delivery system 20, or
accessed via gateway 210 or high function system 110 within the
information layer 100, the partitioned application currently being
processed on RS 400 causes the message data to be displayed in fields on
the user's display monitor as defined by the particular partitioned
application.
All active objects reside in file server 205. Inactive objects or objects
in preparation reside in producer system 120. Objects recently introduced
into delivery system 20 from the producer system 120 will be available
from file server 205, but, may not be available on cache/concentrator 302
to which the user's RS 400 has dialed. If such objects are requested by
the RS 400, the cache/concentrator 302 automatically requests the object
from file server 205. The requested object is routed back to the
requesting cache/concentrator 302, which automatically routes it to the
communications line on which the request was originally made, from which
it is received by the RS 400.
The RS 400 is the point of application session control because it has the
ability to select and randomly access objects representing all or part of
partitioned applications and their data. RS 400 processes objects
according to information contained therein and events created by the user
on personal computer 405.
Applications on network 10 act in concert with the distributed partitioned
applications running on RS 400. Partitioned applications constructed as
groups of objects and are distributed on demand to a user's RS 400. An
application partition represents the minimum amount of information and
program logic needed to present a page or window, i.e. portion of a page
presented to the user, perform transactions with the interactive network
10, and perform traditional data processing operations, as required,
including selecting another partitioned application to be processed upon a
user generated completion event for the current partitioned application.
In accordance with the invention, objects representing all or part of
partitioned applications may be stored in a user's RS 400 if the objects
meet certain criteria, such as being non-volatile, noncritical to network
integrity, or if they are critical to ensuring reasonable response time.
Such objects are either provided on diskettes 426 together with RS 400
system software used during the installation procedure or they are
automatically requested by RS 400 when the user makes selections requiring
objects not present in RS 400. In the latter case, RS 400 requests from
cache/concentrator layer 300 only the objects necessary to execute the
desired partitioned application.
APPLICATIONS AND PAGES
Applications, i.e. information events, are composed of a sequence of one or
more pages opened at screen 414 of monitor 412. This is better seen with
reference to FIG. 3a and 3b were a page 255 is illustrated as might appear
at screen 414 of monitor 412. With reference to FIG. 3a, each page 255 is
formatted with a service interface having page partitions 250, 260, 280,
and 290 (not to be confused with application partitions). Window page
partitions 275, well known in the art, are also available and are opened
and closed conditionally on page 255 upon the occurrence of an event
specified in the application being run. Each page partition 250, 260, 280
and 290 and window 275 is made up of a page element which defines the
content of the partition or window.
NETWORK OBJECTS
As noted above, in conventional time-sharing computer networks, the data
and program instructions necessary to support user sessions are maintained
at a central host computer. However, that approach has been found to
create processing bottlenecks as greater numbers of users are connected to
the network; bottlenecks which require increases in processing power and
complexity; e.g., multiple hosts of greater computing capability, if the
network is to meet demand. Further, such bottlenecks have been found to
also slow response time as more users are connected to the network and
seek to have their requests for data processing answered.
The consequences of the host processing bottlenecking is to either compel
capital expenditures to expand host processing capability, or accept
longer response times; i.e., a slower network, and risk user
dissatisfaction.
However, even in the case where additional computing power is added, and
where response time is allowed to increase, eventually the host becomes
user saturated as more and more users are sought to be served by the
network. The network described above, however, is designed to alleviate
the effects of host-centered limitations, and extend the network
saturation point. This objective is achieved by reducing the demand on the
host for processing resources by structuring the network so that the
higher network levels act primarily to maintain and supply data and
programs to the lower levels of the network, particularly RS 400, which
acts to manage and sustain the user screen displays.
More particularly, the described network features procedures for parsing
the network data and program instructions required to support the
interactive user sessions into packets, referred to as objects, and
distributing them into the network where they can be stored and processed
at lower levels, particularly, reception system 400.
As shown in FIG. 4c, the network objects are organized as a family of
objects each of which perform a specific function in support of the
interactive session. More particularly, the network object family is seen
to include 6 members: page format objects 502, page element objects 504,
window objects 506, program objects 508, advertisement objects 510 and
page template objects 500.
Objects 500 to 510 shown in FIG. 4c are themselves made up of further
sub-blocks of information that may be selectively collected to define the
objects and resulting pages that ultimately constitute the application
presented to the user in an interactive text and graphic session.
More specifically and as shown schematically in FIG. 4a, objects 500 to 510
are predefined, variable length records consisting of a fixed length
header 551 and one or more self-defining record segments 552 a list of
which is presented in FIG. 4c as segment types 512 to 540.
In accordance with this design, and as shown in FIG. 4b, object header 551
in preferred form is 18 bytes in length and contains a prescribed sequence
of information which provides data regarding the object's identification,
its anticipated use, association to other objects, its length and its
version and currency.
More particularly, each of the 18 bytes of object header 551 are
conventional hexadecimal, 8 bit bytes and are arranged in a fixed pattern
to facilitate interpretation by network 10. Particularly, and as shown in
FIG. 4b, the first byte of header 551; i.e., byte 1, identifies the length
of the object ID in hexadecimal. The next six bytes; i.e., bytes 2 to 7,
are allocated for identifying access control to the object so as to allow
creation of closed user groups to whom the object(s) is to be provided. As
will be appreciated by those skilled in the art, the ability to earmark
objects in anticipation of user requests enables the network to anticipate
requests and pre-collect objects from large numbers of them maintained to
render the network more efficient and reduce response time. The following
4 bytes of header 551; bytes 8 to 11, are used to identify the set of
objects to which the subject object belongs. In this regard, it will be
appreciated that, again, for speed of access and efficiency of selection,
the objects are arranged in groups or sets which are likely to be
presented to user sequentially in presenting the page sets; i.e., screens
that go to make up a session.
Following identification of the object set, the next byte in header 551;
i.e., byte 12, gives the location of the subject object in the set. As
will be appreciated here also the identification is provided to facilitate
ease of object location and access among the many thousands of objects
that are maintained to, thereby, render their selection and presentation
more efficient and speedy.
Thereafter, the following byte of header 551; i.e., byte 13, designates the
object type; e.g., page format, page template, page element, etc.
Following identification of the object type, two bytes; i.e., bytes 14,
15, are allocated to define the length of the object, which may be of
whatever length is necessary to supply the data necessary, and thereby
provides great flexibility for creation of the screens. Thereafter, in
accordance with the preferred form of the invention, a single byte; i.e.,
byte 16, is allocated to identify the storage characteristic for the
object; i.e., the criterion which establishes at what level in network 10
the object will be stored, and the basis upon which it will be updated. At
least a portion of this byte; i.e, the higher order nibble (first 4 bits
reading from left to right) is associated with the last byte; i.e., byte
18, in the header which identifies the version of the object, a control
used in determining how often in a predetermined period of time the object
will be updated by the network.
Following storage characteristic byte 16, header 551 includes a byte; i.e.,
17, which identifies the number of objects in the set to which the subject
object belongs. Finally, and as noted above, in accordance with the
invention, header 551 includes a byte; i.e., 18, which identifies the
version of the object. Particularly the object version is a number to
establish the control for the update of the object that are resident at RS
400.
As shown in FIG. 4a, and as noted above, in addition to header 551, the
object includes one more of the various segment types shown in FIG. 4c.
Segments 512 to 540 are the basic building blocks of the objects. And, as
in the case of the object, the segments are also self-defining. As will be
appreciated by those skilled in the art, by making the segments
self-defining, changes in the objects and their use in the network can be
made without changing pre-existing objects.
As in the case of objects, the segments have also been provided with a
specific structure. Particularly, and as shown in FIG. 4a, segments 552
consists of a designation of segment type 553, identification of segment
length 554, followed by the information necessary to implement the segment
and its associated object 555; e.g., either, control data, display data or
program code.
In this structure, segment type 553 is identified with a one-byte
hexadecimal code which describes the general function of the segment.
Thereafter, segment length 554 is identified as a fixed two-byte long
field which carries the segment length as a hexadecimal number in INTEL
format; i.e., least significant byte first. Finally, data within segments
may be identified either by position or keyword, depending on the specific
requirements of the segment.
NETWORK MESSAGES
In addition to the network objects, and the display data, control data, and
the program instructions they contain as previously described, network 10
also exchanges information regarding the support of user sessions and the
maintenance of the network as "messenger". Specifically, messages
typically relate to the exchange of information associated with initial
logon of a reception system 400 to network 10, dialogue between RS 400 and
other elements and communications by the other network elements amongst
themselves.
To facilitate message exchange internally, and through gateway 210 to
entities externally to network 10, a protocol termed the "Data Interchange
Architecture" (DIA) is used to support the transport and interpretation of
information. More particularly, DIA enables: communications between RS 400
units, separation of functions between network layers 100, 200, 300 and
401; consistent parsing of data; an "open" architecture for network 10;
downward compatibility within the network; compatibility with standard
industry protocols such as the IBM System Network Architecture; Open
Systems Interconnections standard; support of network utility sessions;
and standardization of common network and application return codes.
Thus DIA binds the various components of network 10 into a coherent entity
by providing a common data stream for communications management purposes.
DIA provides the ability to route messages between applications based in
IBM System Network Architecture (SNA), (well known in the art, and more
fully described in Data and Computer communications, by W. Stallings,
Chapter 12, McMillian Publishing, Inc. (1985)) and non-SNA reception
system applications; e.g. home computer applications. Further, DIA
provides common data structure between applications run at RS 400 units
and applications that may be run on external computer networks; e.g. Dow
Jones Services, accessed through gateway 210. As well, DIA provides
support for utility sessions between backbone applications run within
network 10. A more detailed description of network messaging in provided
in parent application Ser. No. 388,156 now issued Sep. 13, 1994 as U.S.
Pat. No. 5,347,632, the contents of which patent are incorporated herein
by reference.
OBJECT LANGUAGE
In accordance with the design of network 10, in order to enable the
manipulation of the network objects, the application programs necessary to
support the interactive text/graphic sessions are written in a high-level
language referred to as "TBOL", (TRINTEX Basic Object Language, "TRINTEX"
being the former company name of one of the assignees of this invention).
TBOL is specifically adapted for writing the application programs so that
the programs may be compiled into a compact data stream that can be
interpreted by the application software operating in the user personal
computer, the application software being designed to establish the network
Reception System 400 previously noted and described in more detail
hereafter.
The Reception System application software supports an interactive
text/graphics sessions by managing objects. As explained above, objects
specify the format and provide the content; i.e., the text and graphics,
displayed on the user's screen so as to make up the pages that constitute
the application. As also explained, pages are divided into separate areas
called "partitions" by certain objects, while certain other objects
describe windows which can be opened on the pages. Further, still other
objects contain TBOL application programs which facilitate the data
processing necessary to present the pages and their associated text and
graphics.
As noted, the object architecture allows logical events to be specified in
the object definitions. An example of a logical event is the completion of
data entry on a screen; i.e., an application page. Logical events are
mapped to physical events such as the user pressing the <ENTER> key on the
keyboard. Other logical events might be the initial display of a screen
page or the completion of data entry in a field. Logical events specified
in page and window object definitions can be associated with the call of
TBOL program objects.
RS 400 is aware of the occurrence of all physical events during the
interactive text/graphic sessions. When a physical event such as
depression of the forward <TAB> key corresponds to a logical event such as
completion of data entry in a field, the appropriate TBOL program is
executed if specified in the object definition. Accordingly, the TBOL
programs can be thought of as routines which are given control to perform
initialization and post-processing application logic associated with the
fields, partitions and screens at the text/graphic sessions.
RS 400 run time environment uses the TBOL programs and their high-level
key-word commands called verbs to provide all the system services needed
to support a text/graphic session, particularly, display management, user
input, local and remote data access.
TBOL programs have a structure that includes three sections: a header
section in which the program name is specified; a data section in which
the data structure the program will use are defined; and a code section in
which the program logic is provided composed of one or more procedures.
More specifically, the code section procedures are composed of procedure
statements, each of which begins with a TBOL key word called a verb.
The name of a procedure can also be used as the verb in a procedure
statement exactly as if it were a TBOL key-word verb. This feature enables
a programmer to extend the language vocabulary to include customized
application-oriented verb commands.
Continuing, TBOL programs have a program syntax that includes a series of
"identifiers" which are the names and labels assigned to programs,
procedures, and data structures.
An identifier may be up to 31 characters long; contain only uppercase or
lowercase letters A through Z, digits 0 through 9, and/or the special
character | | |
