REGISTER  |  SIGN IN
United States Patent5896530
WhiteApril 20, 1999
Title
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 my be of heterogeneous configuration, to cooperatively process various application 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 via communication channels to other hosts within the network and a dialog manager which uses a transaction processor interface to communication 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 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, views 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-dependant variation of import/export are automatically integrated with the application at load module bind time, requiring no source code changes.
Inventors:White; John W. (Dallas, TX)
Assignee:Sterling Software, Inc. (Dallas, TX)
Appl. No.:374451
Filed:January 18, 1995
Current U.S. Class:718/102 707/1 
Field of Search:395/700,671,600 707/1-5
U.S. Patent Documents
4333144June 1982Whiteside et al.
4454579June 1984Pilat et al.
4455619June 1984Masui et al.
4525780June 1985Bratt, et al.
4530051July 1985Johnson et al.
4575816March 1986Hendrickson et al.
4615001September 1986Hudgins, Jr.
4734854March 1988Afshar
4809170February 1989Leblang et al.
4841441June 1989Nixon et al.
4860204August 1989Gendron et al.
4881166November 1989Thompson et al.
4882674November 1989Quint et al.
4901231February 1990Bishop et al.
4961133October 1990Talati et al.
4984180January 1991Wada et al.
5008853April 1991Bly et al.
5038296August 1991Suno
5062040October 1991Bishop et al.
5075847December 1991Fromme
5212792May 1993Gerety et al.
5220657June 1993Bly et al.
5261100November 1993Firinami et al.
Foreign Patent Documents
A-0 052 712Jun., 1982EP
A-0 150 273Aug., 1985EP
A-0 248 403Dec., 1987EP
A-0 315 493May., 1989EP
A-0 333 619Sep., 1989EP
A-63 259 757Apr., 1987JP
Other References
Zinov'ev, E.V.; Strekalev, A.A.; Mikelevich, E.L., "Pascal implementation of transactions for network data banks", Journal: Avtomatika I Vychislitel'naya Tekhnika, vol. 19, No. 5, pp. 78-83, publication Date: 1985, Country of Publication: USSR, CODEN: AV. .
Uhlir, S., "Enabling the User Interface", IBM Systems Journal, vol. 27, No. 3, 1988, pp. 306-314, Armonk, New York. .
IBM Technical Disclosure Bulletin, "Method to Create and Activate Profile Functions for Multiple-User Profiles", vol. 28, No. 2, Jul. 1985, pp. 787-789, New York. .
IBM Technical Disclosure Bulletin, "Routing Incoming Calls to X25 Applications", vol. 32, No. 4B, Sep. 1989, pp. 94-95, New York. .
Sheets, Kitrick and Lin, Kwei-Jay, "A Kernel Level Remote Procedure Call Mechanism", Proc. IEEE 11th Annual International COMPSAC87, Oct. 7-9 1987, Tokyo, Japan, pp. 687-693. .
Buchwald, L.A., Davidson, R.W., Stevens, W.P., "Integrating Applications with SAA", IBM Systems Journal, vol. 27, No. 3, 1988, pp. 315-323, Armonk, New York. .
Birrell, et al., "Implementing Remote Procedure Calls". .
ACM Transactions on Computer Systems, vol. 2, No. 1, Feb. 1984, pp. 39-59. .
Standard ECMA--127, "Basic Remote Procedure Call Using OSI Remote Operations", ECMA, Dec. 1987. .
Martin, James, Information Engineering Book 1. Introduction, Prentice-Hall, Englewood Cliffs, NJ 1989, pp. 14,16-18, 29-31, 38, 50, 53-54, 65-66, 70-71, 77, 77-82, 87, and 165. .
McClure, Carma, Case is Software Automation, Prentice-Hall, London, 1989, p. 1-Entire Book. .
Texas Instruments Incorporated, "Information Engineering Facility .TM. Construction Toolset Guide," TI Part Number 2739755-0001 Second Edition Sep. 1988, pp. 3-17 to 3-18, 5-11 to 5-12. .
Digital Consulting Incorporated, "Computer-Aided Software Engineering Symposium", Andover, MA Spring 1989 Edition, pp. T-87, U-92-U95. .
Texas Instruments Incorporated, "Information Engineering Facility.TM. Central Encyclopedia Guide" TI Part Number 2739754-0001 Second Edition Mar. 1988, pp. 1-1 to 1-6, 8-6, 8-11, 8-19, 8-20 to 8-21, 8-23 to 8-25, 8-27 to 8-28, 8-31 to 8-32, 8-35 to 8-38, 8-79 to 8-81. .
Texas Instruments Incorporated, "Information Engineering Facility.TM. Analysis Toolset Guide", TI Part Number 2739751-0001 Third Edition Nov. 1988, pp. 5-2 to 5-7, 5-15 to 5-16, 5-19 to 5-20, 5-37, 5-68 to 5-69, 5-81 to 5-83, 6-2 to 6-4, 6-10, 6-16, 6-33 to 6-34, 8-3 to 8-10, 8-22, 8-79 to 8-80, 9-1 to 9-4, 9-12 to 9-13. .
Texas Instruments Incorporated, "Information Engineering Facility.TM. Methodology Overview," Plano, TX 1989, pp. 1, 17, 28, 34-35, 39, 41. .
Texas Instruments Incorporated, "Information Engineering Facility.TM. Design Toolset Guide," TI Part Number 2739752-0001, Third Edition Dec. 1988, pp. 3-5 to 3-6, 5-1 to 5-4. .
"Distributed System Software Design Paradigm with Application to Computer Networks," By Schneidwind, N.F., IEEE Transactions on Software Engineering, vol. 15, ISS. 4, pp. 402-412, Apr. 1989. .
"A Distributed and Transparent Environment for Software Engineerng Built on Networking Facilities: The PCTE Distribution Service", By Bugli Innocenti, E. IEEE Comp. Soc Press, Proceeding Workshop on the Future Trends of Distributed Comprising Systems in the 1900's, pp. 33-37, Sep. 1988. .
"Server Network: Software Integration Tools for CIM" By Zeicher, L.E., 1988 International Conference on Computer Integrated Manufacturing, pp. 226-235, May 1988. .
"Updating Software and Configuration Data in a Distributed Communications Network," By Symborski, C.W., Proceedings of the Computer Networking Symposium, pp. 331-338, Apr. 1988. .
"Management of Distributed Applications in Large Networks," By, Flavin, R. A., et al. Proceedings of the Twenty-First Annual Hawaii International Conference on System Sciences, vol. II Software Track, pp. 232-241, Jan. 1988. .
"Extending the Darts Software Design Method to Distributed Real Time Applications," By Gomaa, Hassen, Proceedings of the Twenty-First Annual Hawaii International Conference on System Sciences, vol. II Software Track, pp. 252-261, Jan. 1988..~
Primary Examiner: Oberley; Alvin E.
Assistant Examiner: Courtenay, III; St. John
Attorney, Agent or Firm:Baker & Botts, L.L.P.
Parent Case Text


This is a divisional of application Ser. No. 08/086,564, filed Jun. 30, 1993, now U.S. Pat. No. 5,428,782, which is a continuation of Ser. No. 972,882, filed on Nov. 3, 1992, abandoned, which is a continuation of Ser. No. 414,221, filed on Sep. 28, 1989, abandoned.
Claims

What is claimed is:
1. A computer-accessible medium storing a global transaction information table for use by a dialog flow manager when processing a transaction, the global transaction information table comprising:
an overhead containing a plurality of pointers as well as containing a plurality of fields for designating information about said transaction;
at least one of said plurality of pointers pointing to an entry in a transaction panel entries table;
at least one of said plurality of pointers pointing to an entry in a transaction language entries table; and
at least one of said plurality of pointers pointing to an entry in a transaction procedure entries table.

2. The computer-accessible medium of claim 1, said plurality of fields further comprising:
an application identification field;
a release number field;
a time field for indicating generations time for this global transaction information table;
a data field for indicating generation date for this global transaction information table;
a documentation report name field;
a documentation generation name field;
a transaction panel entries field for designating the number of entries in said transaction panel entries table;
a transaction language entries field for designating the number of entries in said transaction language entries table; and
a transaction procedure entries field for designating the number of entries in said transaction procedure entries table.

3. The computer-accessible medium of claim 1, wherein said at least one of said plurality of pointers pointing to an entry in a transaction panel list, further comprising:
a pointer pointing to a menu entry in said transaction panel entries table;
a pointer pointing to a help entry in said transaction panel entries table;
a pointer pointing to a glossary entry in said transaction panel entries table; and
a pointer pointing to a first entry in said transaction panel entries table.

4. The computer-accessible medium of claim 1, wherein said at least one of said plurality of pointers pointing to an entry in a transaction language entries table is pointing to a first entry in said transaction language entries table.

5. The computer-accessible medium of claim 1, wherein said at least one of said plurality of pointers pointing to an entry in a transaction procedure entries table is pointing to a first entry in said transaction procedure entries table.

6. The computer-accessible medium of claim 1, wherein said transaction processing entries table further comprises:
a plurality of pointers;
a plurality of fields for designating information about said transaction;
at least one of said plurality of transaction panel entries pointers pointing to panel map data for said transaction;
at least one of said plurality of transaction panel entries pointers pointing to transaction menu entries table; and
at least one of said plurality of transaction panel entries table pointers pointing to said transaction procedure entries table.

7. The computer-accessible medium of claim 1, wherein said transaction procedure entries table is an array of transaction procedure entries each describing a single application-supplied procedure, the combination of which includes all procedures required for the processing of an application.

8. The computer-accessible medium of claim 1, wherein said transaction language entries table is an array of transaction language entries each describing a language in which documentation is available.

9. The computer-accessible medium of claim 1, wherein said transaction processing entries table is an array of transaction processing entries, each describing a single transaction panel, the combination of which includes all panels needed for a particular transaction.

10. The computer-accessible medium of claim 3, wherein said transaction procedure entries table is an array of transaction procedure entries each describing a single application-supplied procedure, the combination of which includes all procedures required for the processing of an application.

11. The computer-accessible medium of claim 3, wherein said at least one of said plurality of pointers pointing to an entry in a transaction language entries table is pointing to a first entry in said transaction language entries table.

12. The computer-accessible medium of claim 3, wherein said at least one of said plurality of pointers pointing to an entry in a transaction procedure entries table is pointing to a first entry in said transaction procedure entries table.

13. The computer-accessible medium of claim 6, wherein said plurality of fields of said transaction panel entries table further comprises:
a panel name field;
one of said plurality of transaction panel entries pointers pointing to an input transaction procedure entry for said transaction;
one of said plurality of transaction panel entries pointers pointing to an output transaction procedure entry for said transaction;
one of said plurality of transaction panel entry pointers pointing to a help table;
a transaction menu entries field for designating the number of transaction menu entries for said single transaction panel, if it is a menu panel; and
one of said plurality of transaction panel entries pointers pointing to a first entry in said transaction menu entries table for said panel, if it is a menu panel.

14. The computer-accessible medium of claim 6, wherein said transaction procedure entries table is an array of transaction procedure entries each describing a single application-supplied procedure, the combination of which includes all procedures required for the processing of an application.

15. The computer-accessible medium of claim 7, wherein said transaction procedure entries table further comprises:
a plurality of fields:
at least one of said plurality of fields containing a pointer pointing to a view map object header;
at least one of said plurality of fields containing a character describing a data base type for said procedure entry; and
at least one of said plurality of fields containing a pointer pointing to an entry location of said application supplied procedure.

16. The computer-accessible medium of claim 8, wherein acid array of transaction language entries further comprises:
a plurality of fields;
one of said plurality of fields is a language name field;
one of said plurality of fields is a documentation report name field; and
one of said plurality of fields is a documentation generation name field.

17. The computer-accessible medium of claim 9, wherein said transaction procedure entries table is an array of transaction procedure entries each describing a single application-supplied procedure, the combination of which includes all procedures required for the processing of an application.

18. The computer-accessible medium of claim 9, wherein said at least one of said plurality of pointers pointing to an entry in a transaction panel list further comprises:
a pointer pointing to a menu entry in said transaction panel entries table;
a pointer pointing to a help entry in said transaction panel entries table;
a pointer pointing to a glossary entry in said transaction panel entries table; and
a pointer pointing to a first entry in said transaction panel entries table.

19. The computer-accessible medium of claim 9, wherein said at least one of said plurality of pointers pointing to an entry in a transaction language entries table is pointing to a first entry in said transaction language entries table.

20. The computer-accessible medium of claim 9, wherein said at least one of said plurality of pointers pointing to an entry in a transaction procedure entries table is pointing to a first entry in said transaction procedure entries table.

21. The computer-accessible medium of claim 9, wherein said transaction processing entries table further comprises:
a plurality of pointers;
a plurality of fields for designating information about said transaction;
at least one of said plurality of transaction panel entries pointers pointing to panel map data for said single transaction panel;
at least one of said plurality of transaction panel entries pointers pointing to a transaction menu entries table; and
at least one of said plurality of transaction panel entries table pointers pointing to said transaction procedure entries table.

22. The computer-accessible medium of claim 10, wherein said transaction procedure entries table further comprises:
a plurality of fields:
at least one of said plurality of fields containing a pointer pointing to a view map object header;
at least one of said plurality of fields containing a character describing a data base type for said procedure entry; and
at least one of said plurality of fields containing a pointer pointing to an entry location of said application-supplied procedure.

23. The computer-accessible medium of claim 14, wherein said transaction procedure entries table further comprises:
a plurality of fields:
at least one of said plurality of fields containing a pointer pointing to a view map object header;
at least one of said plurality of fields containing a character describing a data base type for said procedure entry; and
at least one of said plurality of fields containing a pointer pointing to an entry location of said application-supplied procedure.

24. The computer-accessible medium of claim 15, wherein said plurality of fields for said transaction procedure entries table further comprises:
a pointer to an input view within said view map object header;
a pointer to an output view within said view map object header; and
a pointer to a profile view within said view map object header.

25. The computer-accessible medium of claim 17, wherein said transaction procedure entries table further comprises:
a plurality of fields:
at least one of said plurality of fields containing a pointer pointing to a view map object header;
at least one of said plurality of fields containing a character describing a data base type for said procedure entry; and
at least one of said plurality of fields containing a pointer pointing to an entry location of said application-supplied procedure.

26. The computer-accessible medium of claim 18, wherein said at least one of said plurality of pointers pointing to an entry in a transaction language entries table is pointing to a first entry in said transaction language entries table.

27. The computer-accessible medium of claim 18, wherein said at least one of said plurality of pointers pointing to an entry in a transaction procedure entries table is pointing to a first entry in said transaction procedure entries table.

28. The computer-accessible medium of claim 18, wherein said transaction procedure entries table is an array of transaction procedure entries each describing a single application-supplied procedure, the combination of which includes all procedures required for the processing of an application.

29. The computer-accessible medium of claim 21, wherein said transaction menu entries table is an array of transaction menu entries each describing a single menu entry.

30. The computer-accessible medium of claim 21, wherein said plurality of fields of said transaction panel entries table further comprises:
a panel name field;
one of said plurality of transaction panel entries pointers pointing to an input transaction procedure entry for said single transaction panel;
one of said plurality of transaction panel entries pointers pointing to an output transaction procedure entry for said single transaction panel;
one of said plurality of transaction panel entry pointers pointing to a help table;
a transaction menu entries field for designating the number of transaction menu entries for said single transaction panel, if it is a menu panel; and
one of said plurality of transaction panel entries pointers pointing to a first entry in said transaction menu entries table for said panel, if it is a menu panel.

31. The computer-accessible medium of claim 21, wherein said transaction procedure entries table is an array of transaction procedure entries each describing a single application-supplied procedure, the combination of which includes all procedures required for the processing of an application.

32. The computer-accessible medium of claim 22, wherein said plurality of fields for said transaction procedure entries table further comprises:
a pointer to an input view within said view map object header;
a pointer to an output view within said view map object header; and
a pointer to a profile view within said view map object header.

33. The computer-accessible medium of claim 22, wherein said view map object header includes a plurality of fields containing static information about each view necessary to complete a panel.

34. The computer-accessible medium of claim 23, wherein said plurality of fields for said transaction procedure entries table further comprises:
a pointer to an input view within said view map object header;
a pointer to an output view within said view map object header; and
a pointer to a profile view within said view map object header.

35. The computer-accessible medium of claim 23, wherein said view map object header includes a plurality of fields containing static information about each view necessary to complete a panel.

36. The computer-accessible medium of claim 25, wherein said plurality of fields for said transaction procedure entries table further comprises:
a pointer to an input view within said view map object header;
a pointer to an output view within said view map object header; and
a pointer to a profile view within said view map object header.

37. The computer-accessible medium of claim 25, wherein said view map object header includes a plurality of fields containing static information about each view necessary to complete a panel.

38. The computer-accessible medium of claim 28, wherein said transaction procedure entries table further comprises:
a plurality of fields:
at least one of said plurality of fields containing a pointer pointing to a view map object header;
at least one of said plurality of fields containing a character describing a data base type for said procedure entry; and
at least one of said plurality of fields containing a pointer pointing to an entry location of said application-supplied procedure.

39. The computer-accessible medium of claim 29, wherein said array of transaction menu entries further comprises:
a plurality of fields;
one of said plurality of fields contains a selection code for said single menu entry;
one of said plurality of fields contains a pointer to a transaction panel entry to be used for said selection code;
one of said plurality of fields contains a pointer to a transaction procedure entry to be used to said selection code; and
one of said plurality of fields contains a description of said single menu entry.

40. The computer-accessible medium of claim 31, wherein said transaction procedure entries table further comprises:
a plurality of fields:
at least one of said plurality of fields containing a pointer pointing to a view map object header;
at leant one of said plurality of fields containing a character describing a data base type for said procedure entry; and
at leant one of said plurality of fields containing a pointer pointing to an entry location of said application-supplied procedure.

41. The computer-accessible medium of claim 31, wherein said view map object header includes a plurality of fields containing static information about each view necessary to complete a panel.

42. The computer-accessible medium of claim 33, wherein said plurality of fields further comprises:
an application name field;
a view name field;
a time field designating compile time of a particular view;
a date field designating compile data of said particular view;
a version field;
a view format field;
a view map object field array designating how many view map object field entries are associated with said particular view; and
compile date of said field designating how many are associated with said a pointer to said particular view's view map object field array.

43. The computer-accessible medium of claim 35, wherein said plurality of fields further comprises:
an application name field;
a view name field;
time field designating compile time of a particular view;
a date field designating compile data of said particular view;
a version field;
a view format field;
a view map object field array designating how many view map object field entries are associated with said particular view; and
a pointer to said particular view's view map object field array.

44. The computer-accessible medium of claim 37, wherein said plurality of fields further comprises:
an application name field;
a view name field;
a time field designating compile time of a particular view;
a date field designating compile data of said particular view;
a version field;
a view format field;
a view map object field array designating how many view map object field entries are associated with said particular view; and
a pointer to said particular view's view map object field array.

45. The computer-accessible medium of claim 38, wherein said plurality of fields for said transaction procedure entries table further comprises:
a pointer to an input view within said view map object header;
a pointer to an output view within said view map object header; and
a pointer to a profile view within said view map object header.

46. The computer-accessible medium of claim 38, wherein said view map object header includes a plurality of fields containing static information about each view necessary to complete a panel.

47. The computer-accessible medium of claim 40, wherein said plurality of fields for said transaction procedure entries table further comprises:
a pointer to an input view within said view map object header;
a pointer to an output view within said view map object header; and
a pointer to a profile view within said view map object header.

48. The computer-accessible medium of claim 40, wherein said View map object header includes a plurality of fields containing static information about each view necessary to complete a panel.

49. The computer-accessible medium of claim 41, wherein said plurality of fields further comprises:
an application name field;
a view name field;
a time field designating compile time of a particular view;
a date field designating compile data of said particular view;
a view format field;
a view map object field array designating how many view map object field entries are associated with said particular view; and
a pointer to said particular view's view map object field array.

50. The computer-accessible medium of claim 46, wherein said plurality of fields further comprises:
an application name field;
a view name field;
a time field designating compile time of a particular view;
a date field designating compile data of said particular view;
a version field;
a view format field;
a view map object field array designating how many view map object field entries are associated with said particular view; and
a pointer to said particular view's view map object field array.

51. The computer-accessible medium of claim 48, wherein said plurality of fields further comprises: an application name field; a view name field; a time field designating compile time of a particular view;
a date field designating compile data of said particular view;
a version field;
a view format field;
a view map object field array designating how many view map object field entries are associated with said particular view; and
a pointer to said particular view's view map object field array.

52. The computer-accessible medium of claim 51, wherein said view map object field array further comprising:
a displacement of a data element in a transaction view work area;
a length of said data element;
an indicator representing the number of occurrence for said data element; and
a data element type indicator.

53. The computer-accessible medium of claim 52, wherein said data element type indicator indicates whether the data element is binary, character, signed, unsigned, small, short, long, hyper, unsigned small, unsigned short, unsigned long, unsigned hyper, single or double.

54. A transaction load module which is treated as an indivisible unit by a transaction processing system thereby ensuring load module integrity and synchronous installation of all components of a transaction, comprising:
a global transaction information table having a table of referenced internal procedures, a table of referenced external procedures, an input view associated with each of said internal procedures, an input view associated with each of said external procedures, an output view associated with each of said internal procedures, an output view associated with each of said external procedures, a profile view associated with each of said internal procedures, a profile view associated with each of said external procedures, a table of all referenced panels, a refresh procedure associated with each referenced panel, and an input procedure associated with each referenced panel;
views associated with a specific transaction;
panels associated with a specific transaction;
transaction procedures;
a set of resources used in conjunction with said transaction procedures; and
a working storage for processing said specific transaction in light of said views, panels, procedures and resources;
said table, views, panels, procedures, set of resources, and working storage being combined within in one load module.
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 pecularities 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 fashio, 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. The 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 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 CPU66 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 accomodating 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 lanugages 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, intput/output procedure pointers, number of associated menu entries, and pointer to 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
0F 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 depicting cooperative processing;

FIG. 8 is a block diagram of a heterogeneous environment showing distributed resource intercommunications supported by the present 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 interrelationships 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 (GCOBPROG) procedure according to the preferred embodiment off the present invention;

FIGS. 36a-c are a flowchart depicting the generate C program (GCPROG) 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-f are a flowchart depicting the edit language list (EL) procedure according to the preferred embodiment of the present invention;

FIG. 41 [omitted];

FIGS. 42a-d 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 (CP0) 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 (CC0) procedure according to the preferred embodiment of the present invention;

FIGS. 59a-c are a flowchart depicting the compile COBOL program (CCOB0) procedure according to the preferred embodiment of e 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 A 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, occurring 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 users 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 return 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 UNIX86.

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 appllications 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 ______________________________________

The format of the Function Key Prompts is `Fnn=prompt` where "nn" is a one or two digit number identifying the function key number, and "prompt" is variable length indicator of the association d function.

When using DL/1 or other data bases, it is desirable, or often even necessary, to have a collection of functions and sub-functions packaged as TRANA and while another set of functions are packaged as TRANB to minimize the number of data bases associated with a given transaction. Therefore, according to the preferred embodiment of the present invention multiple functions are packaged in each transaction module. Packaging multiple functions within a single transaction code (hereinafter referred to as a "trancode") improves user friendliness. Furthermore, it also minimizes the number of objects that must be managed when installing an application in a new system or when re-deploying a new release of an application. The size of any resulting transaction module is a design consideration and must balance technical and performance considerations with user friendliness and ease of maintenance.

A terminal as contemplated by the present invention is a presentation facility, such as a video terminal screen, and an input mechanism, normally a keyboard. However, as noted previously, this input could be a program, voice, barcode, mouse, or other input as well as a keyboard. Similarly, the display could be a program as well as the more conventional terminal display. Each logical terminal has a name that is unique within the DAA network.

The terminal is the primary interactive input/output facility for DAA applications according to the preferred embodiment of the present invention. Once the input has been prepared to the user's satisfaction, he may press ENTER (or an equivalent) to invoke the transaction. This transaction input stream will be passed to the appropriate system in the network. Once arriving at the appropriate system, it will be processed according to the transaction code. Once the transaction has been invoked, the application or the Information Engineering Task (IET) runtime controller, will be responsible for interpreting the input stream and in turn invoking the appropriate procedure.

Output generated by DAA transactions will be presented to the logical terminal, formatted according to the interface and device characteristics associated with the terminal (e.g., any necessary control sequences associated with display devices will be included in the the data stream). The primary human interface to the DAA environment is through terminals that present panels of information from the applications via transactions executing in the various systems. Often, the terminal is a
24.times.80 video screen with keyboard. However, a "terminal" could also be a program (e.g., an interactive program such as a spread sheet package). Each logical terminal is uniquely defined within each system.

An application as contemplated by the present invention is a collection of transactions that perform a set of functions on behalf of the application. Each application has a four character name that is unique within each deployed runtime system.

A transaction with DAA according to the present invention is a collection of resources (panels, reports, procedures, databases, etc.) to be utilized in behalf of an application to perform various functions for that application. Each transaction is uniquely identified within each runtime system into which is is deployed. Additionally, each transaction comprises a set of load modules or programs that perform the specified functions in the appropriate environment for that transaction. Each transaction has a primary program (load module) which may, in turn, invoke sub-modules on behalf of that transaction.

As shown in FIG. 9, each DAA application transaction is composed of application procedures, panels, views, working storage, DAA run-time functions, a Transaction Definition Table (TDT), and other tables. As can be seen according to the preferred embodiment of the present invention, portion 152, containing the DAA runtime procedures and tables, is application independent. Portion 154, containing the TDT, procedures (input, refresh), panels (menu, application) and views (import, export, profile), remains application dependent. Procedures have direct access to working storage, but are completely isolated from panels and views (and consequently isolated from the mechanics of inter-transaction communication, device communication, profile management, etc.).

Each transaction may perform multiple functions in behalf of the application. These functions are represented by application procedures. A procedure as contemplated by the present invention is a collection of code that performs a particular set of functions on behalf of a transaction. Each procedure has a name that is unique within the associated transaction. An application procedure may be invoked as a result of a panel being presented to the transaction that contains this procedure. A procedure may also be invoked by a distributed application transferring a request for service through a network request (LINK) to the designated system/transaction thereby invoking the designated transaction procedure. Upon completion of execution of a procedure, the procedure may stipulate that a panel is to be prepared and presented back to the application user or it may designate that control is to be passed to another system/transaction/procedure with a remote request or it may designate that control is to return to the calling system/transaction/procedure that invoked this procedure.

A panel within DAA according to the present invention is a defined format for information interchange with a logical terminal (e.g., an IBM 3279 display terminal). Each panel is uniquely identified within the associated transaction. Associated with each panel is an INPUT procedure and REFRESH procedure. The input procedure is invoked when the corresponding panel is received from a terminal. The optional refresh procedure is executed upon the restart of an application or from a HELP suspension in order to refresh data to be presented on the panel prior to output display of the panel.

An input procedure is an application program that is invoked when a panel is received by a system from a terminal/process. When an input panel is received from a logical terminal, the input procedure associated with the panel is invoked.

A refresh procedure is an application program that is invoked prior to displaying a panel that is requested from a menu or is invoked upon restart of an application that has been suspended for HELP documentation presentation. The refresh procedure is typically used to retrieve data from data bases prior to display on the panel. The refresh procedure may also be invoked when a panel is to be presented as an initial user request from a menu. A refresh procedure may be associated with a menu selection and/or a panel. If a refresh procedure is associated with a menu selection, this procedure will be invoked prior to the display of the panel. If, however, a menu selection does not explicitly have a refresh procedure, then the refresh procedure on the panel specification will be invoked. If neither the menu selection nor the panel specification specify a refresh procedure, then the panel will be presented from the data in working storage, as populated from the profile view.

Working storage, sometimes also referred to as a transaction view, contains all data items that will be referenced by all panels, views, and procedures for this transaction. Working storage is passed to each procedure within the transaction for use in executing the logic of that procedure. Working storage consists of a fixed section, which is used to communicate between DAA run-time functions and application procedures, and a variable section, which is entirely application-defined.

Within DAA, according to the preferred embodiment of the present invention, application procedures communicate with each other, and with outside resources, via "views". Views are used to help isolate application procedures from the mechanics of inter-system communications, device presentation management, help facilities, menus, and other DAA common services. This isolation of the application logic from "services" ensures that:

an application can be serviced, without programming changes, through continually evolving communications, storage, presentation, packaging, processing, etc., technologies.

an application can be implemented on a variety of platforms and architectures, based on cost/performance measurements (not on migration costs).

an application can be implemented on a variety of user environments, including variances in national language, human interface hardware, and user preference.

an application can be altered in real time, including data interchange (view) re-definitions, without disruption or loss of data.

A view within DAA as contemplated by the present invention is a designated collection of data items that are utilized by the application. A view is a named collection of such data items and includes the identification and length of these data items as they relate to the particular transaction. The primary types of views are profile, import, and export. A profile view identifies all data items which are to be saved in the user's profile between executions of this transaction. An import view defines all data items to be presented to a called procedure by a calling procedure. An export view defines all data items to be presented upon completion of the execution of a called procedure to the calling procedure.

The profile view is a subset of working storage sometimes known as (transaction view) that is to be saved in the users profile for this application. At the completion of the execution of a procedure, the profile view for that procedure is extracted from working storage and written to the profile data base. As this transaction is reinvoked by subsequent data entry or application restart, this profile view is read from the profile data base and used to repopulate working storage. The profile view is intended to be a subset of working storage which defines the data requirements of the current user dialog state while minimizing the overhead associated with maintaining user profiles.

The import, or input, view is a collection of data items that are presented to a procedure when a procedure is LINKed-to from a calling system/transaction/procedure. When a procedure completes and indicates an Exit State of LINK, the DAA control program (IET) will extract from working storage the data items identified by the import view for the called procedure and package that with the control information necessary to specify the calling and called system/transaction/procedure. This message is routed to the designated system and transaction for execution. The import view, when received at the called system/transaction/procedure, is used to populate working storage for the called transaction.

The export, or output, view is a collection of data items representing the results of the execution of a called procedure. The export view is a subset of items contained in working storage at the completion of a procedure execution when the exit state is set to RETURN. This export view is packaged with interface control information into a message to be routed back to the calling system/transaction. When this message arrives at the designated system/transaction/procedure, the profile view for that system/transaction/procedure is retrieved from the profile data base and used to populate working storage. The export view is then extracted from the message just received and used to populate (and overlay profile data in) working storage. The specified procedure is then restarted.

A transaction view is a collection of data items to be used by the collection of procedures, panels, and views that make up a transaction. These data items may be thought of as COBOL Data Definitions or as C structures, although other lanugages may be used, that specify each of these data items. The transaction view is passed as a working storage area to each procedure within the transaction for use in executing the logic of that procedure.

When the TDT is first referenced, the GTD system will generate the "system required" portion of the transaction view and place this in the associated SRCLIB (described later). The transaction view name is usually of the form "tdtTVW". The application designer is then required to add any application-unique data items to this transaction view. Once specified, the transaction view is used as a data reference source for procedures, panels, and other views.

APPLICATION PORTABILITY. Application portability is achieved by supporting, on all DAA system platforms, and for evolving system environments: identical application source programs; identical application definitions; and identical application development environments.

Source program portability, or identical application source programs, for all supported platforms, is achieved by adherance to a selected set of industry-adopted standards, combined with a platform-independent program interface.

Examples of industry-adopted standards which are used to assure source program portability include: "C" program compliance with draft proposed ANSI "C" (X3J11), including the defined function library; "COBOL" program compliance with ANSI X3.23-1985 (Intermediate Level); and "SQL" compliance with ANSI X3.135-1986. Adherance to these standards are checked on all platforms having ANSI compliant compilers or pre-compilers. Deviation from the standard, including non-portable use of system-specific functions, is checked whenever feasible.

Examples of areas in which industry-wide standards do not exist include: interface to a transaction processing system; interface to a presentation system; communications between cooperative processes; routing messages to terminals, transactions, systems; user interface; profile management; help and user documentation. These functions are provided by DAA, but are completely isolated from application logic.

Furthermore, there is one interface between DAA and application procedures. The application procedure is called, passing it the address of working storage. Interaction between DAA run-time services and the application is via a fixed portion of working storage. The application uses working storage to request services such as display a specific panel or link to a procedure. However, the application does not specify data requirements, logical control sequence, or any other mechanics of the service. Parameters of DAA services are isolated from the application logic, making the application source program independent of system-specific implementations.

The runtime environment for DAA applications provides for the major functions to be supported by a run time driver (IET) and associated run time subroutines. An application (input) procedure is invoked as a result of input from a panel or input from a remote procedure call(i.e., LINK). In either case, the structure and content of working storage, as well as the calling sequence itself, is identical. It is transparent to the application whether input was received from a panel or another procedure (except that an optional RETURN may be made to a calling procedure). These two forms of input are further described in the following paragraphs.

When panel input is received from a terminal to a procedure, the user's profile view is extracted from the ROLLFILE and placed in working storage. Working storage is presented to the procedure and the procedure is executed, which typically performs application-dependent data base query/updates, manipulative logic on data items in working storage and/or data bases, and preparation of output data elements in working storage (which may be saved in the user's profile or displayed to the output terminal when control is returned to IET). If, for example, the designer of the application receives input, reads data from the data base, places that data in working storage, and returns control to IET, the same panel will be displayed with the newly populated working storage data.

If the logic of the input procedure is such that it determines from terminal input or user action request (e.g., a function key) that an alternative panel is to be displayed, it may do so by inserting the new panel name in the IEF1-PANEL field and returning control to the IET. IET will prepare a panel for the input terminal consistent with the panel specification. If the IEF1-PANEL field is left blank, the master menu will be displayed.

The designer has the option of interrogating the user action request (e.g., function key), located in working storage element IEF1-FUNKEY, to determine action to be taken by this procedure in response to a user action request from the terminal. Note, however, that certain action requests are reserved for use in dialog actions defined in the consistent user interface (and implemented by IET).

An external procedure is a procedure which is physically located in a different transaction and possibly different system. The external procedure itself is not included in the calling transaction load module but a reference to this external procedure is made to correlate the import and export views for this procedure.

An application procedure can use the LINK and RETURN exit states to invoke external procedures. Distributed Resource Control (DRC) is used to route the request to the designated system/transaction. The procedure name, as specified, must be a well defined procedure name within the called system/transaction. If it is not well defined, then the menu for the called transaction will be displayed to the user.

The invoked system/transaction/procedure operates in the same DAA environment as the parent transaction/procedure and has the same options (i.e., if a panel is to be displayed upon completion of the execution of this called procedure, the procedure may do so by entering a panel name in the IEF1-PANEL field and returning control with the IEF1-XSTATE field blank to display this panel to the requesting user).

A called external procedure may return control to the calling procedure by setting the variable IEF1-XSTATE to RETURN. In this case, the IET control program will extract data items from working storage as specified by the export view for this called external procedure, package that with the interface control block that initiated this call request and submit this output message to the calling system/transaction/procedure. Upon return to the calling system/transaction, the IET control program at that system will extract the profile view for the calling procedure from the profile data base and use it to populate working storage of the calling transaction, followed by a population (and consequent overlay) of working storage based on the export view received from the called external procedure. The calling procedure will be reinvoked for further processing.

DAA profile management is a service which is automatically provided to all application procedures executing in the DAA environment. Profile management saves and restores an identified subset of working storage, completely independent of application procedure logic. Profile management enables DAA transactions to have the characteristics of conversational transactions (except profiles are by user instead of terminal), without requiring application logic. Consequently, DAA procedures have some of the ease-of-programming features inherent with interactive-mode applications, while retaining the resource administration advantages inherent with transaction processing.

One side effect of DAA's profile management is that working storage is set according to the definition of the user profile (and not necessarily the last execution of the procedure). This encourages application procedures to be coded for serial re-usability and/or reentrancy.

Application definition portability, both with respect to supported platforms and evolving system environments, is achieved by using tables (as opposed to generating code) within the application load module.

Tables to describe the application requirements and definitions are independent of the specific implementation environment. For example, panel tables do not have any device-related information nor do import/export views have any protocol-specific information. Environmental dependencies, such as terminal devices or inter-system communications protocol, are isolated from the application definition. Consequently, DAA support for changes to the environment, either through explicit application transfer to another environment, or through natural evolution of the current environment, is achieved without impacting the application.

DAA provides a platform-independent interface to a structured development process, plus an automated mechanism for transferring an entire application development environment between platforms.

"Generate Transaction Definition" (GTD) is an interactive tool used for semi-automating the transaction development process. GTD provides the developer with a mechanism for specification of all transaction elements. The user creates and edits the Transaction Definition Table (TDT), which identifies the elements to be included in the transaction and the relationship between the elements. GTD also provides the mechanism for specifying parameters of DAA services, such as dialog