Portable and dynamic distributed applications architecture

Abstract

A system and method is shown for enabling a plurality of computers and associated computer resources, some or all of which may be of heterogeneous configuration, to cooperatively process various applications such that the execution is transparent to the user regardless of where the application is actually executing. This distributed applications architecture performs an information distribution service between multiple transaction processing systems by working with a transaction processor via communication channels to other hosts within the network and a dialog manager which uses a transaction processor interface to communicate with the transaction processor. The architecture employs a map service which provides an editor to create the maps for the application panels, a compiler to generate the maps into a linkable form, and a linkable interpreter which translates the linkable form into the screen presentation format for that platform. To distribute an application, the source code for the procedures, view and panels are moved as a block to the new system. This is possible because once the application source code is complete, all application logic, user interface control tables, view definitions, and other application-specific tables for one transaction definition are packaged by the present invention in a single load module on the system where the application will reside. The load module is then compiled using the target system's compiler, link editor, and bind process. Thus, all environment-dependent variations of import/export are automatically integrated with the application at load module bind time, requiring no source code changes.

Claims

What is claimed is:

1. A distributed environment for executing transaction processing applications across a selected set of heterogeneous computing platforms, comprising:

a logical terminal;

a data stream input from said logical terminal;

a communications line adapted to be connected to said logical terminal for communicating said data stream input along said communications line;

a communications processor adapted to be connected said communications line for receiving said data stream along said communications line from said logical terminal;

a hookup line adapted to be connected to said communications processor for directing said data stream input along said hookup line;

a central processing unit (CPU) adapted to be connected to said hookup line for receiving said data stream along said hookup line from said communications processor;

a bus adapted to be connected to said central processing unit for forwarding said input from said central processing unit to a computer memory;

an information engineering task for managing dialog flow between said input and any designated logical terminals resulting from execution of a particular transaction;

a transaction definition table built specifically for said particular transaction;

a disk;

a database management system managing a database on said disk;

an SQL command interface for accessing said database, further adapted to return information obtained from said database in response to requests for such information received from said task or said transaction definition table.

2. The distributed environment of claim 1, wherein said transaction definition table maintains pointers to at least one view, at least one panel and at least one procedure to be associated with said particular transaction.

3. The distributed environment for executing transaction processing applications of claim 1, wherein said database further comprises:

a first portion delegated for data storage or retrieval; and

a second portion delegated for profile view maintenance.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer software architectures, and more particularly to a system and method enabling a plurality of computers and associated computer resources, some or all of which may be heterogeneous in configuration, to cooperatively process a variety of applications such that the user sees the same image of the application no matter where the application is actually executing.

2. Description of the Related Art

In today's processing environment, business applications may be designed and implemented to operate in either a transaction mode or an interactive mode. Transaction mode is normally used when implementing applications within an environment in which many users are competing for limited resources. Interactive mode is most effectively used when resources can be dedicated to a user. In either mode, sharing of processor, data base, and/or terminal resources is normally limited to a homogeneous set of processors, operating systems, and/or transaction processing monitors.

Applications implemented using the transaction model, generally are structured as shown in FIG. 1. Each application load module includes logic for initialization, data import, data processing, data export, and termination.

Application logic is most frequently written in "C" or COBOL program languages. User interface (e.g., screen format) control tables are defined and packaged separately from the application's load module, although there is strong coupling between the user interface definition and the application's data processing logic. Working storage contains data elements which are in a form directly usable by the application program.

Looking now at FIG. 1, initialization logic 12 provides for opening data sets, connecting to any data bases needed for the particular instance of the application, and initializing working storage 10 to default values. Complex applications are implemented as dialogs consisting of several transaction executions per unit of work. This implementation mode is referred to as "conversational transactions" and requires that the state of the conversation be saved and restored for each transaction execution. Conversational transactions maintain the conversation state in working storage 10. At initialization, working storage 10 is refreshed from a copy which was saved at the time the transaction last terminated (for a given terminal).

Data import logic transforms an input data stream 22 from a hardware-dependent representation into the data elements comprising working storage 10. The data stream 22 could originate from a (terminal) device or from another transaction. In the, case of devices, the application program logic 12 for data stream 22 decomposition is coupled with, and reflects, device characteristics. In the case of data received from transactions, the application program logic 12 is coupled with the data representation syntax and semantics of the sender.

Data processing logic 14 performs the computation and data manipulation for the application. Information is read from and written to system data base(s) 18, data files, and/or other information systems. Application-dependent integrity checks are performed. Queries are made of the information systems and the responses placed in working storage.

Data export logic 16 transforms working storage 10 data elements into a hardware-dependent representation. The destination for the output data stream 24 can either be a device or a transaction. In the case of devices, the application program logic for data stream 24 formatting is coupled with, and reflects, device characteristics. In the case of data transmitted to transactions, the data representation syntax and semantics of the data stream 24 must match the receiver's application logic.

Termination logic 16 includes closing data sets and committing any logical data base transactions which occurred during this execution instance of the application. If this is a conversational transaction, the current application state (working storage) is saved.

The interactive model provides applications with dedicated resources, including memory, data bases, files, and terminal. Implementation of conversational dialogs is easier than with the transaction model since the application state does not have to be explicitly saved/restored on every interaction with a terminal. Communications with other processors is achieved through "remote procedure calls" (RPC). RPCs are sometimes also used within the transaction model, or between interactive processes and transactions. In any of these cases, an RPC requires that the calling procedure (with all of its resources), the communications resource, and the called procedure (with all of its resources) be dedicated during the time of the call. Furthermore, the calling procedure's resources (such as the terminal) can not, in general, be used by the called procedure. RPCs have the same characteristics as inter-transaction data transfers, namely that the data representation syntax and semantics of the data stream must be synchronized between the client and server sides of an RPC.

There are however, many difficulties encountered with today's technology. For example, application source code is not portable. Much of the application logic is dependent upon a particular transaction processing monitor, operating system, data base management system, processor type, terminal devices, and/or other variations in the software environment. A very high degree of homogeneity between software environments is required to minimize the cost of porting applications from one environment to another. Multiple sets of source code are required to support the variations in software environment, with the attendant maintenance and function synchronization problems.

As a result of the above, programmers must be trained to generate source code for each specific software environment. Not only is this a waste of training resources, but this amounts to high costs in programmer time in generating source code to enable an application to meet the peculiarities of each particular environment.

As indicated above, user interface control tables (e.g., screen formats) are packaged separately from application program logic. This results in synchronization problems at execution time. In most cases, a synchronized update to both user interface control tables and application program logic can not be performed in real time. In order to avoid data integrity problems, application updates require that the application is taken offline and all pending input for the transaction is flushed prior to installation. Application logic is, nevertheless, tightly coupled with specific device characteristics, requiring application changes to support new user interface technology.

Conversational transactions require explicit application program logic to save/restore working storage. The conversation state is maintained with respect to a (terminal) device, not a user. If a user changes terminals, he can not resume the conversation which he started at the original device. Any software modifications to a conversational transaction which results in a redefinition or restructuring of the elements in working storage can not be implemented in real-time. In order to avoid data integrity problems, application updates require that the application is taken offline and all saved working storage reinitialized prior to installation.

Inter-transaction communications, including resource (e.g., transaction, terminal) sharing across distributed systems, is restricted to one instance of a single-image transaction processing system, and also requires synchronized installation of communicating application transactions. A synchronized update, across multiple systems, can not be performed in real time. In order to avoid data integrity problems, application updates require that all involved transactions be taken offline and all pending communications be flushed prior to installation.

Currently available techniques for cooperative processing require dedicated communications resources, dedicated processes, implementation-specific/complex program interfaces, and often asymmetric logic between user and server. For these reasons, it is difficult to quickly implement cooperative processing for small applications. Furthermore, some of the performance/cost objectives associated with a transaction model are compromised by excessive resource consumption associated with direct inter-application communication.

Implementation of business applications in interactive mode is not generally appropriate for high volume applications due to the lack of flexibility in the administration/control of computer resources, in addition to the inability to modify active, distributed applications in real time.

SUMMARY OF THE INVENTION

In view of the above problems associated with the related art, it is an object of the present invention to provide a system and method of computer software architecture for enabling a plurality of computers, and associated computer resources, some or all of which may be heterogenous in configuration, to cooperatively process applications, including applications built from a single application source base.

Another object of the present invention is to provide improvement in application programmer productivity by limiting program logic to the processing logic; specifically isolating it from data import and data export logic. Because this logic is built into the common execution code used by all applications, there is a significant reduction in need for specialized application logic for menus, help, and cooperative processing functions as well as message handling functions. As a result, a programmer need only be trained for the single unified system execution and development environments. Furthermore, the programmer may quickly generate applications which can be distributed across multiple heterogeneous computer systems without requiring source code changes and enable modifications to an application to be implemented with one load module, one documentation set, and one data base bind.

Yet another object of the present invention is to provide improvement in user productivity by furnishing uniform help and menu functions between applications, affording users with menu, help and glossary access to functions from every application panel, and requiring users to remember fewer transaction codes.

A further object of the present invention is to provide lower system maintenance costs and improved system performance by enabling multiple functions to be accomplished in one reentrant package, enabling reduction of system definition resources required by each application, providing resource sharing across multiple heterogeneous computer systems, enabling control of resource utilization, requiring management of fewer transactions and external screens, enabling users to access applications on any heterogeneous system without being aware where the application is being run (e.g., the system running the application is transparent to the user), providing common application execution environment for a variety of platforms including mainframes, minicomputers, and workstations, as well as providing application scalability to meet a user's processing requirements.

Yet a further object of the present invention provides improved application quality control and maintenance by providing common application execution and development environment for a variety of platforms, providing real-time application upgrades, reducing development costs by enabling development of application on low cost platform for installation on different higher cost platforms, accessing and maintaining application components in a synchronized fashion, enabling applications to be tested as a large integrated application set before deployment, and simplifying deployment of applications by reducing the number of load modules and system definitions required to install those load modules.

These objects are accomplished in a preferred embodiment of the present invention known as Distributed Applications Architecture (hereinafter referred to as "DAA"). The DAA can be installed on a variety of platforms including mainframe computers, minicomputers, and individual workstations. Once DAA is installed, along with its required support subsystems, services and utilities, then DAA-generated applications may be accessed from any of these platforms. The support subsystems may be customized from products readily available in the market place.

DAA works with a transaction processor via communication channels to the other hosts within the network. It also employs a map service. The map service should provide an editor to allow application programmers to create the maps for the application panels, a compiler to generate maps into a linkable form, and a linkable interpreter which translates the linkable form into the screen presentation format for that platform.

Additionally, as seen in FIG. 2, in the preferred embodiment of the present invention, the DAA employs a DBMS 18 (Data Base Management System) which uses a standard form SAA SQL 20 to support application code DBMS functions and to save user/application profile information. It should be noted that more than one DBMS could be used; for example, one to support application functions and one to save profile information. Furthermore while a DBMS not using the standard form SAA SQL could be used, it should be realized that the embedded application DBMS code should be source compatible on the various platforms.

Looking in more detail at FIG. 2, each application transaction consists of the Information Engineering Task (IET) 26, application program logic 32 and working storage 10.

The hardware-specific input data stream 22 consists of the information input to the application. Information included is: data, hardware type of the input device, and characteristics of the output expected.

The IET 26 processes the input data stream 22 to prepare it for the application program logic 32. The setup decomposes the data stream 22 by converting the characters input to the application to its native data type for application program use. The application program 32 tells the IET 26 which data sets will need to be accessed. The IET 26 receives routing information from the terminal device characteristics and routing information table 30 via communication route 28, and `opens` those data sets.

The main storage logic 10 performs the computation and data manipulation for the application. Application program logic 32 pulls information from, and stores information on, data bases(s) 18 in the system using a preselected subset of Structured Query Language (SQL) commands 20 although other languages could be employed. When the computation and manipulation are completed, the IET 26 begins its cleanup.

The IET cleanup consists of two steps. First, composing the data generated from the application 32 into a format set by the programmer. The information is sent out as the output data stream 24. Second, `closing` data sets which had been opened for use by the application.

All of the application logic, user interface control tables, view definitions, and other application-specific tables for one transaction definition are packaged in a single load module.

The DAA Application load module, shown in FIG. 3, includes all the components necessary for a user to invoke a DAA application through DAA from a terminal on any other DAA system. The components in this module control routing of information, accessing data bases on different systems if necessary, cleaning up data sets when the application is finished, and presenting the information when complete. The load module also includes references to HELP, INFOrmation, and GLOSsary information stored on the system.

The DAA Transaction Definition Table (TDT) 34 defines all the elements of a DAA load module and is provided by the DAA.

The IET interface 26 is a logic element also provided by the DAA. The IET interface merges the information stored in the views 38 with the panels 40 designed by the programmer to form the application data structure.

The Terminal Mapping System (TMS) 34 is another logic element of the DAA. The TMS 34 is provided by the DAA and takes the data stream input to the DAA and converts it into IBM 3270 format data streams.

Views 38 are designed by the programmer to define the types of variables used by the application. A view 38 tells the IET interface what format the procedure 32 needs the data in. The IET interface 26 converts the input data stream to match that format. After data is processed by the procedures 32 also, IET 26 converts the information stored in the views 38 to the format for the output data stream, or to the format specified for other procedures 32. The views 38 allow data to pass locally between procedures 32 on the system the user is logged onto and remotely to procedures on other DAA systems.

Panels, or screens 40 for the application are built from programming definitions using a screen painter and a special compiler. Panels 40 developed in this way are transferrable across all systems at the source code level.

Menus 42 are special screens used to guide the application user through the procedures for an application, are defined by the programmer, and are expandable in source form.

Once the application source code is complete, all programmer designed blocks shown in FIG. 3 are built into one load module by the DAA software on the system where the application will reside. To move (or distribute) an application, the source code for the procedures 32, views 38, and panels 40 are moved as a block to the new system. The load module is compiled using the target system's compiler, link editor, and bind process. No source code changes are necessary.

No matter how complex the application, all application components of a load module are automatically in synchronization and consequently can be installed in real-time. Application-independent DAA logic and control tables are implemented as dynamically loadable libraries. DAA upgrades are automatically reflected in application load modules, ensuring synchronization of DAA functions across all application load modules. Additionally, this makes the application easier to distribute, and requires the application user to remember fewer transaction codes.

Application procedures contain no code related to either data import or data export. Application procedures are restricted to perform computation and data manipulation using data elements defined in working storage and optionally an interface to some information system. An information system supported by DAA is relational data base access via a well defined subset of Structured Query Language (SQL) commands. Other information systems could be employed by the application.

Data import/export functions are completely isolated from any application procedure. All environment-dependent variations of import/export, including network protocol, device characteristics, transaction processing monitor, operating systems, processor types, etc., are automatically integrated with the application at load module bind time. Import/export functions are driven from implementor-defined views and user interface control tables. User interface control tables describe the characteristics of the user interface, and how elements of working storage map to/from the user interface. "Import" and "export" views describe elements of working storage which are to be communicated between transactions. "Profile" views are used to describe elements of working storage which are to be saved/restored at initiation/termination time for each transaction execution.

At execution time, a view definition is used to encode or decode an information packet to/from working storage. Each element of working storage, which is selected by the view definition, is encoded into an identifier/value pair in the information packet. The identifier uniquely identifies, across all application versions of working storage, a particular element, independent of the element's location or length in working storage. At any time during the life cycle of an application, a programmer may change the location and/or length of elements in Working storage, rebuild a new version of the application load module, and productionize the new load module. When a view is decoded from the information packet back to working storage, the element value is stored in the location/length defined by the application at the time of execution (i.e., not at the time of information packet creation).

These characteristics of view management significantly reduce the possibility for data integrity problems introduced by modifying application load modules in real time. The current state (profile) can be successfully restored to an application which modified its working storage layout. Application load modules which communicate with each other can be modified asynchronously, in real time, across heterogeneous environments, including changes to the import/export view and working storage layout.

To better understand the present invention and the relationship of its component parts in the development environment, refer now to FIG. 5. Although the components seen there will be discussed in great detail later, a working understanding of their relationship with the hardware involved is necessary.

A user may input data or invoke an application at terminal 58. Terminal 58 directs such input to communications processor 62 via communications line 60. Communications processor 62 routes the input to central processing unit 66 (CPU) via hookup line 64. At this point the CPU 66 addresses computer memory 70 via bus 68. Within computer memory resides the general transaction definition tool 72 (GTD), connected to transaction definition table 36 (TDT). The TDT overhead 36 points to specific locations in memory 70 for maps (panels) 40, views 38, and procedure logic 32. Application procedure logic in turn communicates through disk interface or data base management system 74, residing on operating system 76, to source object data sets on disk 18 via SAA SQL commands 20.

In the execution environment of the preferred embodiment of the present invention, turning now to FIG. 6, a user invokes an application at terminal 58. Terminal 58 directs the request along communication line 60 to communication processor 62. Processor 62 in turn forwards the invocation to CPU 66 via hookup line 64. At this point the CPU 66 addresses computer memory 70 via bus 68. Within computer memory resides the transaction definition table 36 (TDT), the information engineering task 26 (IET), and transaction processing subsystem interface 78. TDT 36 points to specific locations in memory 70 for maps (panels) 40, views 38, and procedure logic 32. IET 26 employs transaction processing subsystem interface 78, to interface with outside systems. In processing the application, it works with DBMS interface 74, which resides on operating system 76, to access a data base on disk 18 via SQL commands 20. Likewide IET 26 maintains its ROLLFILE 80 via SQL commands 82 to ROLLFILE database management system 84.

Transaction and terminal resources are directly accessible from only one (single-image) transaction processing system. DAA implements an information distribution service between multiple transaction processing systems. The distribution service provides for the distribution of information packets, with guaranteed delivery, as well as the dispositioning of these information packets. Dispositioning typically utilizes transaction processing system facilities in order to forward the information packet to an application transaction or (terminal) device. Information packets destined for devices may be modified in order to conform with the device characteristics which are present at time of dispositioning, thus accommodating dynamic changes to device configurations. Isolation of data import/export functions from application procedural logic enables applications to transparently utilize this DAA distribution service facility in order to share resources (e.g., transactions, terminals) across distributed systems in heterogeneous software environments.

More specifically, the Information Engineering Task (IET) is an executable DAA procedure that receives control whenever an application program is executed and provides a number of devices to the application program which isolate it from the hardware and software environment in which the application runs. It communicates panels, views, and information between the user, user profile, application procedure and remote DAA application procedures. Thus the services it performs include panel input/output processing, managing user documentation requirements, providing menu navigation, and handling cooperative processing interfaces for the application, as well as required DBMS setup, application synchronization and cleanup.

The IET uses a Transaction Definition Table (TDT, described below), and compiled view objects generated automatically by Generate Transaction Definition (GTD, described below) from the Transaction Definition File (TDF, described below) to correlate information to be communicated to the user, user profile, application procedures and DAA remote procedures. This information is stored in the transaction view data area and is the major interface between the application and the IET. The transaction view is initialized from the input screen and profile view when performing panel input/output processing and initialization of the transaction view from the input/output/interface views and profile views when performing cooperative processing.

The isolation that the IET provides enables the application procedure to contain primarily application specific logic. The languages (primary and DBMS) used in application procedures are written in languages which are implemented consistently across all DAA platforms so as to ensure application portability.

Prior to having DAA, and specifically, the transaction driver program, IET, a programmer did not require a table of pointers to his maps and procedures. Each transaction would have unique program logic containing the necessary decisions to explicitly call the proper procedures to process appropriate input from a user and to use various screen maps for output as required. This meant the programmer was required to provide code to handle all the possible dialog flows, and screen input/output.

In DAA, the IET module provides the dialog flow management and handles all the screen input/output including help documentation and glossary request. The programmer under DAA is only required to handle input and output variables from/to screen maps and remote procedures.

Since IET is a fixed program module that is common to all DAA transactions, it is not possible for embedded logic to call the appropriate user procedure and to use its unique screen maps. This problem requires that all information used to drive the application screens and procedures be contained in a separate linkable table. This table must have sufficient information to allow IET to choose the appropriate screen maps, call appropriate procedures before and after screen input/output, save and restore appropriate program variables (views), restart a transaction at the last known state and provide appropriate linkage to remote DAA transaction procedures. This table is known as the Transaction Definition Table (TDT) and is created by the DAA development tool, GTD, based on transaction definition information provided by the developer, or application programmer, and stored in the Transaction Definition File (TDF).

The TDT is a table of names, pointers, and control information required by the IET module at run time to properly communicate panels, views and information between the user, link-edited procedure and remote DAA procedures. The TDT is simply the anchor of information that allows IET to control execution flow. The TDT is constructed so that the developer's procedure code is unaware of the TDT's existence and frees the developer from writing his own code to correlate input/output application panels, help panels, glossary panels, as well as saving and restoring pertinent program variables (views) across multiple executions of a transaction for any given user.

The TDT consists of a variety of information such as application identification, version number, last transaction build date, help documentation file name, number of documentation languages supported, a pointer to first documentation language table entry, and a SQL support procedure entry point addresses for such functions as Connect, Commit, and Release. Map and procedure tables as well as menu and documentation language table entries also comprise part of the TDT.

Each of the map tables for application, menus, help, information and glossary panels contains such information as panel name, TMS screen map pointer, input/output procedure pointers, number of associated menu entries, and a pointer to the first associated menu entry. Each of the procedure tables contains such data as procedure name, procedure entry-point address, intput/output/profile view table pointers, and SQL DB use flag. Each of the menu table entries contains such information as menu select code, panel entry pointer, panel procedure entry-point address, and displayable menu description string. Each of the documentation language table entries contains such specifics as documentation language name and documentation file name.

The Transaction Definition File (TDF) is a file of records used by GTD as the "blueprint" for constructing a DAA transaction. This TDF is an integral part of GTD because it contains all the information necessary to compile and link all the correct components of a given DAA transaction. The programmer simply uses GTD's menus and screens to add and delete the appropriate components and GTD files this information into the TDF.

Therefore, the content of the TDF is created and maintained by the developer using the GTD tool. The TDF is used by GTD to assist the programmer in the edit of his procedure code, panel maps, and menus. Once these components have been edited, the TDF is used by GTD to compile and create various object modules that are link-edited along with the IET to produce a transaction load module.

The TDF consists of a variety of types of records such as header, panel, menu, and procedure. The header typically contains a list of source, object, load and map libraries along with pertinent names, such as application and transaction-view names. Each panel is a record containing panel name and input/output processing procedure names. Each menu screen is a record containing menu name, menu panel name, input/output processing procedure names and displayable description string. Each procedure definition is a record containing procedure name, input/output/profile view files names, and language type.

The Generate Transaction Definition (GTD) never requires a programmer to build files containing instructions on compiling and linking the correct parts, because the GTD builds and maintains the TDF. Furthermore, the GTD provides for development of applications that execute under control of the IET.

More specifically, GTD is a menu driven user interface that is intended to be uniform across all DAA platforms providing the application developer with structured application development such as definition, creation/edit, construction, application transfer features and various utilities necessary for development in an environment with multiple heterogeneous development and execution hosts. Application programmers define application components and their interrelationships by using definition screens within GTD. They include procedure code, panel maps, menus, program data views and documentation. This information is stored in the TDF and later used by GTD when accessing any of the components for modification or for DAA application construction. The developer uses GTD to edit the application source components and to construct the executable application load module.

During construction, GTD uses the TDF and the application defined program data views to create object modules which are used by IET in order to perform its services for the application program. Whenever a GTD application is constructed, GTD ensures that all objects created are up to date with the source files so that the application will always be synchronized.

GTD provides for development of applications that execute under control of the IET through the user interface, and performs background functions at each stage of the application development. These stages can be defined as definition, composition, construction and deployment. During definition GTD requires the user to define all of the components of the application, their physical storage location, their interrelationships, and any additional attributes or information. The definition information is stored in the TDF. During the composition phase GTD provides the application developer with menu access to each of the components listed in the TDF and provides generators and editors for each of these components.

During construction, GTD retrieves the information in the TDF and generates the TDT and view module which are used by the IET module at run time. GTD then compiles each of the components listed in the TDF using the appropriate compiler for each type of component in a predefined order by type. These types include the TDT and view modules GTD generates, menus and panel maps and procedure code. GTD provides the application developer with construction alternatives. Components may be constructed conditionally or unconditionally based on date and time information which is updated each time a source component is modified during the composition phase or when an output object is created or replaced during construction. When performing conditional construction GTD checks the date and time on each source component and each output object. When the source component has a later date than the output object, GTD reconstructs the output object. Conditional and unconditional construction method approaches ensure the synchronization and consistency of the load module when construction is performed on all components in the TDF. To complete construction, GTD binds all of the load module components together into a load module using a linkage editor and installs the load module in the location referred to by the TDF.

During the deployment phase GTD provides the capability to transfer all, or selected, application components from one machine to another. The application developer identifies the target machine, the physical location on the target machine where the TDF file could be located, and the components to transfer. This transfer process accesses the components listed in the TDF and transfers them to an appropriate location on the target machine extrapolated from the target machine TDF file location. The transfer is accomplished using an available file transfer communications program between the source and target machines. As part of the transfer process all textual data is translated to the target machine format and the physical locations and names in the TDF are changed to conform to the target machine conventions.

These and other features and advantages of the invention will be apparent to those skilled in the art from the following detailed description of a preferred embodiment, taken together with the accompanying drawings, in which:

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting current program application development without the present invention;

FIG. 2 is a block diagram depicting program application development according to an embodiment of the present invention;

FIG. 3 is a block diagram of a sample load module according to the present invention;

FIG. 4 is a graphical representation of internal configuration of a transaction definition table (TDT), according to the present invention;

FIG. 5 is a block diagram demonstrating the development environment according to the present invention;

FIG. 6 is a block diagram depicting the execution environment according to the present invention;

FIG. 7 is a graphical representation of application portability due to the implementation of the depicted cooperative processing;

FIG. 8 is a block diagram of a heterogeneous environment showing distributed resource intercommunications supported by the preset invention;

FIG. 9 is a block diagram of transaction concepts according to the preferred embodiment of the present invention;

FIG. 10 is a block diagram depicting DAA procedure execution and profile view according to the present invention;

FIG. 11 is a block diagram depicting an user interface scenario according to the present invention;

FIG. 12 is a block diagram showing possible navigation routes from session to session, for a typical dialog according to the present invention;

FIG. 13 is a block diagram showing possible navigation routes from transaction to transaction, for a typical dialog according to the present invention;

FIG. 14 is a block diagram showing possible navigation routes from panel to panel, for a typical dialog according to the present invention;

FIG. 15 is a block diagram depicting an example of DAA dialog flow, according to the preferred embodiment of the present invention, combining consistent user interface definitions with programmable dialog flow commands;

FIG. 16 is a block diagram depicting remote procedure execution/data flow, according to the present invention;

FIG. 17 is a block diagram showing the inter-relationships between various components used to implement distributed resource control according to the preferred embodiment of the present invention;

FIG. 18 is a block diagram demonstrating the logical flow of control and data assocated with the LINK/RETURN implementation between transactions according to the preferred embodiment of the present invention;

FIG. 19 is a block diagram depicting the logical flow of control and data associated with data interchange between terminals and transactions according to the preferred embodiment of the present invention;

FIGS. 20a-f are a flowchart detailing the functions performed by the GTD at the highest menu level, according to the preferred embodiment of the present invention;

FIG. 21 is a flowchart depicting the procedure display procedure according to the preferred embodiment of the present invention;

FIGS. 22a-b are a flowchart depicting the FE procedure which checks for an user-inputted end indicator for GTD panel functions according to the preferred embodiment of the present invention;

FIGS. 23a-c are a flowchart depicting the edit transaction parameters (ET) procedure according to the preferred embodiment of the present invention;

FIGS. 24a-r are a flowchart depicting the GTD get TDF (GTDT) procedure according to the preferred embodiment of the present invention;

FIGS. 25a-b are a flowchart depicting the GTD read TDF record (TDTGET) procedure according to the preferred embodiment of the present invention;

FIGS. 26a-e are a flowchart depicting the generate transaction view (GTVW) procedure according to the preferred embodiment of the present invention;

FIG. 27 is a flowchart depicting the edit transaction parameters (ETP) procedure according to the preferred embodiment of the present invention;

FIGS. 28a-f are a flowchart depicting the edit panel list (EP) procedure according to the preferred embodiment of the present invention;

FIG. 29 is a flowchart depicting the edit panel (EPE) procedure according to the preferred embodiment of the present invention;

FIGS. 30a-f are a flowchart depicting the edit procedure list (EC) procedure according to the preferred embodiment of the present invention;

FIG. 31 is a flowchart depicting the add procedure user interface (ECA), procedure according to the preferred embodiment of the present invention;

FIGS. 32a-b are a flowchart depicting the change procedure entry (ECC) procedure according to the preferred embodiment of the present invention;

FIG. 33 is a flowchart depicting the edit filename (DO-EDIT) procedure according to the preferred embodiment of the present invention;

FIGS. 34a-b are a flowchart depicting the edit procedure (ECE) procedure according to the preferred embodiment of the present invention;

FIGS. 35a-c are a flowchart depicting the generate COBOL program (GCBPROG) procedure according to the preferred embodiment of the present invention;

FIGS. 37a-d are a flowchart depicting the edit menu list (EM) procedure according to the preferred embodiment of the present invention;

FIG. 38 is a flowchart depicting the prepare menu display (EMS) procedure according to the preferred embodiment of the present invention;

FIG. 39 is a flowchart depicting the edit menu list (EMX) procedure according to the preferred embodiment of the present invention;

FIGS. 40a-e and 41 are a flowchart depicting the edit language list (EL) procedure according to the preferred embodiment of the present invention;

FIGS. 42a-e are a flowchart depicting the put TDF (PTDT) procedure according to the preferred embodiment of the present invention;

FIGS. 43a-b are a flowchart depicting the write TDF record (TDTPUT) procedure according to the preferred embodiment of the present invention;

FIGS. 44a-b are a flowchart depicting the generate transaction/view, COBOL/C program (GC) procedure according to the preferred embodiment of the present invention;

FIG. 45 is a flowchart depicting the generate COBOL procedure user interface (GCOBP) procedure according to the preferred embodiment of the present invention;

FIG. 46 is a flowchart depicting the generate C procedure user interface (GCP) procedure according to the preferred embodiment of the present invention;

FIGS. 47a-f are a flowchart depicting the generate maps user interface (GM) procedure according to the preferred embodiment of the present invention;

FIGS. 48a-d are a flowchart depicting the generate menu panels (GPM) procedure according to the preferred embodiment of the present invention;

FIG. 49 is a flowchart depicting the generate skeleton panel user interface ((GSP) procedure according to the preferred embodiment of the present invention;

FIGS. 50a-j are a flowchart depicting the compile transaction definition/views/panels/procedures (CTREQ) procedure according to the preferred embodiment of the present invention;

FIGS. 51a-rr are a flowchart depicting the compile transaction definition (CT) procedure according to the preferred embodiment of the present invention;

FIGS. 52a-b are a flowchart depicting the add view name to table (TVA) procedure according to the preferred embodiment of the present invention;

FIG. 53 is a flowchart depicting the write buffer to file (WTS) procedure according to the preferred embodiment of the present invention;

FIGS. 54a-mm are a flowchart depicting the compile view (CV) procedure according to the preferred embodiment of the present invention;

FIG. 55 is a flowchart depicting the compile panels (CP) procedure according to the preferred embodiment of the present invention;

FIGS. 56a-c are a flowchart depicting the lower level compile panels (CPO) procedure according to the preferred embodiment of the present invention;

FIGS. 57a-d are a flowchart depicting the compile (CC) procedure according to the preferred embodiment of the present invention;

FIGS. 58a-j are a flowchart depicting the compile C program (CCO) procedure according to the preferred embodiment of the present invention;

FIGS. 59a-c are a flowchart depicting the compile COBOL program (CCOBO) procedure according to the preferred embodiment of the present invention;

FIGS. 60a-b are a flowchart depicting the bind transaction (BT) procedure according to the preferred embodiment of the present invention;

FIG. 61 is a flowchart depicting the file transfer panels/procedures/views/documentation (FT) procedure according to the preferred embodiment of the present invention; and

FIGS. 62a-bb are a flowchart depicting the information engineering task aspect of the preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the evolving world of distributed computing systems, it is necessary that the applications be supported with a strategy consistent with the environment in which the applications operate. These distributed networks are composed of systems (computers) connected with communications facilities of various types, including wide area networks, local area networks, and bus architectures. These systems support local data bases and distributed data bases that allow synchronized maintenance of information between multiple computer systems.

In most general case, the present invention provides the capability to develop interrelated applications and put these applications into service on multiple heterogeneous processors connected with heterogeneous communications facilities utilizing heterogeneous data bases. Currently the COBOL and C languages are being supported. It should be understood however, that other languages could be used in applications involving the present invention. Furthermore, while particularly DBMS is the primary data base management system employed in implementing the present invention, other data base management systems such as DL/1 could also be used. Lastly, it is contemplated that the present invention should not be limited to the TSO, Unix and OS/2 environment platforms currently supporting the present invention.

The distinguishing features of a preferred embodiment of the present invention include application portability, consistent user interface, dynamic application changes, and cooperative processing between heterogeneous computer architectures. Application portablility means that an application written in one of the supported programming languages (e.g., COBOL or "C"), along with all related copy (or include) files, user interface panel definitions, documentation, transaction definition tables, views, etc., can be moved and installed, without source-level modification, on any supported target platform.

"Dynamic application change" enables most application changes (including procedural, data base, or panel definition changes) to be made in real-time, without disruption of service or loss of data integrity. End users perceive installation of application changes as subsecond variances in response time, occuring only while the change is being installed. Individual transactions of a distributed cooperative processing application are updated asynchronously, without disrupting continuity or integrity of data communications. Consistent user interface means that a user, from any terminal in the network, has transparent access to all transactions in the network (subject to security constraints), that all transactions have a consistent form of dialog navigation, and that the panel layout, user interaction with panel elements, etc., is consistent across all transactions for any particular user's terminal.

The cooperative processing feature of DAA provides for data exchange between transactions residing on heterogeneous platforms, transparent to the application.

To meet the need for continuous operations and as well as implied dynamic change for applications, the preferred embodiment of the present invention modifies an application (including data base and panel presentation) dynamically with, in most cases, only subsecond interruption to service while the change is being implemented. This maintenance capability is segmented so that most changes for an application can be modified in one system (computer) without requiring the change to be synchronized throughout the distributed processing network. Certainly some applications, due to distributed calls between systems, will require synchronization of maintenance on multiple systems for certain types of application changes. However, the preferred embodiment of the present invention allows dynamic asynchronous change throughout a network.

The Distributed Application Architecture (DAA) environment according to a preferred embodiment of the present invention is comprised of a set of inter-connected systems, as shown in FIG. 7, discussed below each of which is uniquely named and addressable by other systems within the network. Systems participate in the DAA environment by allowing applications to use their resources (e.g., terminals, transactions). Each system is a homogeneous application processing environment which supports or simulates either a single-processor transaction processing system or a multi-processor single-image transaction processing system (e.g., IMS).

To illustrate this aspect cooperative processing between heterogenous systems, return to FIG. 7. Two interconnected systems are depicted as an example only as more systems can frequently be involved in any transaction. Input invoking a transaction is received at logical terminal 130 and forwarded to the DAA environment 132. Logical terminal 130 could be an IBM 3270 device, an intelligent workstation window, a local terminal or a non-DAA process. The DAA environment 132 is a homogeneous application processing environment (e.g., a transaction processing system). DAA environment 132 invokes the required transaction. An application may require a transaction 134 that only requires information from local database 136. Or, a transaction 138 may require information from both local database 136 and distributed database 140. At the same time, terminal 150 may address DAA environment 148 to invoke transaction 144 which requires information from local database 142 and distributed database 140. It is possible with the present invention that transaction 144 (or 134, 138, 146) could use local database 142, call another transaction (say 134, 138 or 146) to request information from local database 136, and return the information to the DAA environment 148 to be properly formatted and returned to terminal 150.

Looking now at FIG. 8, a more clear example of this cooperative processing across heterogenous platforms is shown. Assume a data input stream 92 is received from a UNIX computer 86. This data stream 92 invokes application 94 to process procedure 96. Procedure 96 obtains information from DBMS 100 via SQL requests 98. As procedure 96 is processing, information is needed from DBMS which in turn needs information from DBMS 124 to complete its processing. With the present invention, this information may now be obtained, while remaining transparent to the user on the UNIX 86.

To accomplish this, procedure 96 is returned to application 94 in the form of an output view (not shown) requesting a LINK to, for example, IBM Mainframe 88. Application 94 suspends procedure 96 and stores relevant data from procedure 96 in a profile view (not shown) which is in turn stored in ROLLFILE 102. Then application 94 makes a LINK request via communication line 104 to the mainframe 88. The mainframe 88 grants the request and directs the data stream coming across line 104 to application 106. Application 106 determines this data stream is looking for information from DBMS 112. Application 106 forwards the data stream to procedure 108 in the form of an input view (not shown). Procedure 108 executes on the data stream, requesting information from DBMS 112 via SQL request 110. While executing, procedure 108 determines it needs some information from DBMS 124 to complete its execution. Procedure 108 is returned to application 106 in the form of an output view (not shown), while relevant data is stored in a profile view (not shown) in ROLLFILE 114. Application 106 then requests a LINK with OS/2 workstation 90, which is granted. Application 118 accepts the incoming data stream and forwards it to procedure 120 in the form of an input view (not shown). Procedure 120 executes, obtaining information from DBMS 124 via SQL request 122. After completing execution, procedure 120 returns to application 118 in the form of an output view (not shown). Application 118 makes a copy of this transaction and places it in a profile view stored in ROLLFILE 126. Application 118 then makes a RETURN request to mainframe 88. Upon the return of data stream via communication line 116, application obtains the profile view stored in ROLLFILE 114 and restarts procedure 108. Procedure 108 completes its execution, requesting additional information needed from DBMS 112, if any, and returns to application 106. Application 106 makes a record of the completed transaction and stores it in a profile view (not shown) stored in ROLLFILE 114. Application 106 then makes a RETURN request to UNIX 86. As the data stream is returned via communication line 104, application 94 obtains the stored profile view on this transaction from ROLLFILE 102 and restarts procedure 96. Procedure 96 completes its execution, requesting additional information needed from DBMS 100, if any, and returns to application 94. Application 94 makes a record of the completed transaction in the form of a profile view (not shown) and stores it in ROLLFILE 102. Application 94 then formats the outgoing data stream 92 for the appropriate terminal and sends it to the user.

DAA provides the services required to share transaction and terminal resources across heterogeneous systems. A system as contemplated by the present invention is an application processing environment within a network, such as an IMS, CICS, UNIX, OS2, or VMS processing environment, among others. Each system within the DAA environment has a name to uniquely identify that system, and the run time directory at each system maintains sufficient information to support the routing of resource requests to the appropriate processing system within the DAA network. The feature of DAA which supports routing of resource requests is known as "Distributed Resource Control".

These systems support distributed applications by allowing segments of these applications to process on any of the network-connected systems. These applications are serviced by a collection of named transactions (system-unique name) that may be referenced by the systems within the network and the users of the network. These transactions may access data bases that are known to various portions of the network and may be addressed to data bases on the local system or to data bases that are distributed on a set of remote systems in the distributed data base environment.

The users of the distributed application architecture disclosed as the present invention are named (network unique name) workstation operators, or processes or machines that present themselves as "users" to the network. A user within the preferred embodiment of the present application typically accesses an application provided in the DAA network through a workstation terminal. The user may invoke various functions of the network by entering data into the terminal by voice, barcode, keyboard, mouse, data stream from a process, or other input device. Output is presented to users of the network via a terminal display; it is presented as a data stream to a process "user" within the network.

A user signs on to one of the systems within the DAA network using an User-ID (network unique name) and an identifying password. This user identification is employed within the DAA network to identify activity for security and accounting purposes, as well as for profile management to maintain the status of processing activity for the user.

A given user may have multiple applications active on multiple systems at any one point in time. This may be viewed as the electronic work desk for a user at a given system. The user may suspend processing of a given application, either by signing off the network or by switching to an alternative application within his portfolio. At the suspension of execution of each transaction the control program will retain, within the profile data base (hereinafter referred to as the ROLLFILE) for that user on that system, the collection of data items (Profile View, described further below) that represent the status of that suspended application.

Similarly, more than one user may have multiple applications active on multiple systems at any one point in time. The results of each panel of an application is stored as it is completed in a profile view, which profile view is uniquely identified by application name and user identification on a system. Although multiple users may be at different stages within a particular application, because of the present invention, each user is able to restart his particular application at the stage last completed by that particualr user, regardless of the system the user is logged onto and regardless Of what system the application resides.

The architecture of the preferred embodiment of the present invention provides for a `Display Active` transaction that allows the user to display the applications that are active for that particular user on the designated system. Utilizing the `Display Active` application display, the user may scroll thru the systems within the network by striking the appropriate function key. From this `Display Active` application panel, the user may also restart a suspended application, delete an application from the profile data base or may route the `Display Active` transaction to a designated new system.

According to the preferred embodiment of the present invention, applications can run in any of several systems and the user may desire to interface with applications involving multiple panels. Therefore, it is imperative that certain attributes be displayed on the user interface panel to identify critical parameters associated with the particular user interaction, such as: the user responsible for initiating the transaction, the system on which the curent application is running, the application (transaction) that is currently active for this display, the panel within that application that is curently being displayed, date and time of this interaction, error and information messages related to the interaction and standard prompting information that reflects actions the user may take from this particular panel. These standard panel attributes are detailed below for example purposes only.

    ______________________________________
    FUNCTION    INTERNAL NAME ROW    COL  LENGTH
    ______________________________________
    Transaction Name
                IEF1-TRAN     1      1    8
    Panel Name  IEF1-PANEL    1      10   8
    Panel Title NA/Optional   1      19   30
    System Name IEF1-SYSTEM   1      58   8
    Date/Time   IEF1-CURDT    1      62   18
    User ID     IEF1-USER     2      72   8
    Message ID  IEF1-MSGID    23     1    6
    Message Text
                IEF1-MSGTX    23     8    25
    Function Key Prompts
                NA            24     1    <79
    ______________________________________