Method of, system for, and computer program product for providing a run time subsystem for run time libraries6332168Abstract Method of, system for, and computer program product for providing a central repository for information regarding run time library usage and a run time subsytem for using the run time libraries in accordance with the information contained in the central repository. The run time subsystem loads run time libraries when initialized and when requested to do by requests from application programs in accordance with the information contained in the central repository. The run time subsystem's use of the central repository provides improved application program performance, improved system utilization, and improved migration. Claims We claim: Description BACKGROUND OF THE INVENTION
TABLE A
Example of Application Profile DataBase
1. load(CEL16,LPA) // find this version in LPA at RTSS init
2. load(CEL15,CSA) // load this version in CSA at RTSS init
3. default_library = CEL16 // use this lib whenever no choice is made
4. system_library = CEL16 // use this for system programs
5. default_load = private // if must load, do it into private, not CSA
6. application(catial) = CEL15 // special level for catia
7. application(payroll) = CEL14+ // payroll needs 1.4 or higher,
// because uses a service new in 1.4
8. application(mapicx),load_csa = CEL17 // override default and load
// in CSA due to high usage
// this important application
In the example of Table A, the numbers on the left of each line of the APDB are for explanation purposes only, and correspond to the following list which explains each Application Profile Data Base entry: 1. Indicates that the RTSS is to find the Run Time Library known by the name CEL16 in LPA storage when it initializes. If the Run Time Library is not found, it will be loaded into CSA storage. A library vector is also pre-built. 2. Indicates that the RTSS is to load the Run Time Library known by the name CEL15 in CSA storage when it initializes. A library vector is also pre-built. 3. Indicates to the RTSS that whenever an application program has not specified a Run Time Library level (either via the APDB or possibly through a new runtime option), this is the level of the Run Time Library to use. 4. Indicates to the RTSS that whenever a system component uses a RTL, this is the level of Run Time Library to use. 5. Indicates to the RTSS that whenever an application program uses a level of Run Time Library for which no load directive was used (such as line 1 or line 2 above directing a CSA load or LPA use), the Run Time Library is to be loaded in user private storage instead of CSA. This can be done (optionally) to conserve CSA for low use Run Time Libraries. 6. This is a line directing that a specific application program (called "catia1") be linked with a specific version of the RTL (CEL15). In the preferred embodiment, the name "catia1" may be required to be included in the application program via a compile or link option, resulting in something akin to a signature CSECT. Otherwise, it may be difficult to determine a job or transaction name at runtime, due to differences in environments (TSO, batch, CICS, IMS, . . . ). 7. This is a line directing that a specific application program (called "payroll") to be linked with version CEL14 of the Run Time Library or above. This would be common if an application program uses a service new with a particular release. In this case, the application program only requires access to that release or a later one, since upward compatibility is insured. 8. This is a line directing that a specific application program (called "mapicx") to be linked with version CEL17 of the Run Time Library, and the Run Time Library should be loaded in CSA if it is not already loaded. The effect of this directive is that CEL17 is not loaded when the RTSS pre-loads all other versions that it knows about. The reason for this is so that a common version of the APDB can be shared across all members of an organization's systems even though this application program may only reside on one of them. This Run Time Library will be loaded if ever needed, but if it is needed, such as on the particular set of machines running this application program, it is needed with frequency justifying loading it into common (CSA) storage. The names of Run Time Libraries shown in FIG. 3 are important to the design. In the case of the load directive to LPA, the name CEL16 is being assigned to whatever version of Run Time Libraries is found in LPA by the RTSS. In all other cases, where RTSS is to load Run Time Libraries, the name is the name assigned to a DD card in the RTSS started task JCL where the DD card points to a dataset containing that level of the Run Time Libraries. While a user may name a library "FRED", the ability for the RTSS to support that version of the library and function may be compromised. In the preferred embodiment, the Run Time Libraries are given names corresponding to their release numbers. The RTSS may be implemented without support to ever stop the RTSS, except when reinitializing the operating system. Alternatively, the RTSS may be implemented with such support to better enable dynamic library additions or changes. Referring now to FIG. 4, the flowchart illustrates operations representative of a conventional system for initializing an application program and for linking this application program to Run Time Libraries. The conventional system begins at process block 405 when an application program is started by the operating system, such as submitting a batch job under the "MVS/ESA" operating system ("MVS/ESA" is a trademark of the International Business Machines Corporation.). Thereafter, in process block 410 a language runtime, such as "LE/370", attempts to load the necessary language runtime modules as part of initialization for this application program. These language runtime modules are either found in LPA (MVS Link Pack Area) in memory or are loaded from disk storage via a STEPLIB JCL statement. After process block 410, decision block 415 determines if the necessary language runtime modules were found or loaded. If the necessary language runtime modules were not found or loaded, then the conventional system causes process block 440 to produce an error message indicating the failure and the application program is stopped. Returning now to decision block 415, if the necessary language runtime modules were found or loaded, then the conventional system causes process block 420 to build a library vector (LV) which contains information on how to invoke routines inside the language runtime modules, to store a pointer to this library vector (LVP) for later use, and to build other internal control structures for the language runtime. Thereafter, the conventional system causes process block 430 to give control to the application program to begin executing. Referring now to FIG. 5 through FIG. 10, flowcharts illustrating operations preferred in carrying out the present invention are shown. In the flowcharts, the graphical conventions of a diamond for a test or decision and a rectangle for a process or function are used. These conventions are well understood by those skilled in the art, and the flowchart is sufficient to enable one of ordinary skill to write code in any suitable computer programming language. In this preferred embodiment, the present invention may be implemented as three processes: 1) a process for starting the Run Time Subsystem, illustrated in FIG. 5 and FIG. 6; 2) a process for application program to Run Time Subsystem communication, illustrated in FIG. 7; and 3) a process for initializing application programs using the Run Time Subsystem, illustrated in FIG. 8, FIG. 9, and FIG. 10. Referring first to FIG. 5, the flowchart illustrates the operations preferred in carrying out the process for starting the Run Time Subsystem. The computer program causes process block 505 to start the Run Time Subsystem (RTSS) when the operating system starts (e.g., when the "MVS/ESA" operating system starts) so that the RTSS may be ready to provide its function to application programs as described below. Thereafter, decision block 510 determines if an Application Profile Data Base (APDB) exists. If the Application Profile Data Base does not exist, then process block 545 causes the Run Time Subsystem to issue an error message to indicate a failure and the Run Time Subsystem stops. Returning now to decision block 510, if an Application Profile Data Base exists, then process block 515 reads the contents of the Application Profile Data Base into memory for processing. Thereafter, decision block 520 determines if any errors were encountered in the Application Profile Data Base. If an error was encountered in the Application Profile Data Base, then process block 550 issues an error message for each error found in the Application Profile Data Base. Decision block 555 then determines if any error found in the Application Profile Data Base is a fatal error. If an error found in the Application Profile Data Base is a fatal error, then process block 560 stops the Run Time Subsystem when such a fatal error is encountered. If no errors found in the Application Profile Data Base are a fatal error, then processing continues from decision block 555 to decision block 525. Returning now to decision block 520, if no errors were encountered in the Application Profile Data Base, then decision block 525 determines if an LPA statement exists in the Application Profile Data Base. An LPA statement indicates that a version of the language modules will be found in the LPA area of storage. The LPA statement will also cause a version of modules found in the LPA to be known by a specific name. If an LPA statement exists in the Application Profile Data Base, then decision block 530 determines if the version of LPA language modules can be located. If the version of LPA language modules can be located, then process block 540 builds a Library Vector (LV) and Library Vector Pointer (LVP) corresponding to the version of language modules located in the LPA area of storage. Thereafter, processing continues to decision block 605 on FIG. 6. This processing path is illustrated by flowchart connectors A, 599 on FIG. 5 and 601 on FIG. 6. Returning now to decision block 530, if the version of LPA language modules can not be located, then process block 565 issues an error message indicating a failure in locating LPA language modules. Thereafter, processing continues to decision block 605 on FIG. 6. This processing path is illustrated by flowchart connectors A, 599 on FIG. 5 and 601 on FIG. 6. Returning now to decision block 525, if an LPA statement does not exist in the Application Profile Data Base, then processing continues to decision block 605 on FIG. 6. This processing path is illustrated by flowchart connectors A, 599 on FIG. 5 and 601 on FIG. 6. Referring now to FIG. 6, after control passes from decision block 525, process block 540, or process block 565, as indicated by flowchart connectors A, 599 on FIG. 5 and 601 on FIG. 6, then decision block 605 determines if a CSA statement exists in the Application Profile Data Base. The CSA statement indicates that a version of the language modules will be loaded in the CSA area of storage. This CSA statement will also cause the version of language runtime modules listed to be loaded and known by the specified name. If a CSA statement exists in the Application Profile Data Base, then process block 610 causes the version of language runtime modules listed to be loaded in the CSA area of storage and to be known by the specified name. Thereafter, decision block 615 determines if the loading of the version of language runtime modules was successful. If the loading of the version of language runtime modules was successful, then process block 620 builds a Library Vector (LV) and Library Vector Pointer (LVP) corresponding to the version of language modules loaded in the CSA area of storage. Thereafter, decision block 625 determines if there is another CSA statement in the Application Profile Data Base. If there are not any more CSA statements in the Application Profile Data Base, then the Run Time Subsystem is initialized, and process block 630 awaits communication buffers, which will be received from application programs when they begin executing. These communication buffers will contain requests that the Run Time Subsystem provide information on the whereabouts of specific versions of the language runtime modules. Thereafter, decision block 635 tests for the receipt of the communication buffers containing a request from an application program. If communication buffers containing a request from an application program have been received, then control passes to process block 700 on FIG. 7, the beginning of the process for application program to Run Time Subsystem Communication. Returning now to decision block 635, if communication buffers containing a request from an application program have not been received, then processing loops back to process block 630 to await communication buffers. Returning now to decision block 625, if there is another CSA statement in the Application Profile Data Base, then processing loops back to process block 610 to process this CSA statement. Returning now to decision block 615, if the loading of the version of language runtime modules was not successful, then process block 640 issues an error message indicating a failure in loading language modules. Thereafter, processing continues to decision block 625 to determine if there is another CSA statement in the Application Profile Data Base. Returning now to decision block 605, if a CSA statement does not exist in the Application Profile Data Base, then processing continues to process block 630 to await communication buffers. Referring now to FIG. 7, the flowchart illustrates the operations preferred in carrying out the process for application program to Run Time Subsystem communication. The process starts at process block 700 when communication buffers containing a request from an application program have been received and this process is started by decision block 635 of FIG. 6. Thereafter, decision block 705 determines if the communication buffer from the application program contains an Application Group Identifier (AGI). This Application Group Identifier may be used to associate this application program with a version of the language runtime modules via information from the Application Profile Data Base. If the communication buffer from the application program contains an Application Group Identifier, then decision block 710 determines if the Application Group Identifier is specified in the Application Profile Data Base. If the Application Group Identifier is specified in the Application Profile Data Base, then decision block 715 determines if a conflict exists between the Library Identifier (LI) specified by the Application Profile Data Base (as indicated by the matching Application Group Identifier) and the Library Identifier specified by the application program. If no conflict exists between the two Library Identifiers, then process block 720 packages into the return buffer the LVP matching the Library Identifier specified in the Application Profile Data Base. Thereafter, process block 730 sends the return buffer back to the application program address space, where the return buffer will be processed by language runtime modules. Thereafter, the process stops at process block 765. If no errors result from this processing of the return buffer by the language runtime modules, then the language runtime modules will complete initialization allowing application program to begin executing using the correct version of the language runtime modules. Returning now to decision block 715, if a conflict does exist between the Library Identifier specified by the Application Profile Data Base and the Library Identifier specified by the application program, then process block 760 places a warning message indicating the conflict into the return buffer. Processing then continues to process block 720 for packaging of the LVP into the return buffer. Returning now to decision block 710, if the Application Group Identifier is not specified in the Application Profile Data Base, then process block 755 packages an informational message into the return buffer which will be sent back to the application program indicating that the Application Group Identifier was not in the Application Profile Data Base, but that the application program requested it. Thereafter, process block 750 packages the default LVP into the return buffer as the information contained in the communication buffer from the application program indicates that the Run Time Subsystem should use the default version of the library runtime modules (as specified in the APDB). This is represented back to the application program address space by sending the default LVP in the return buffer. Thereafter, processing continues to process block 730 which sends the return buffer back to the application program address space, where the return buffer will be processed by language runtime modules. Returning now to decision block 705, if the communication buffer from the application program does not contain an Application Group Identifier, then decision block 735 determines if the communication buffer from application program contains a Library Identifier. This Library Identifier may be used to match this application program with the version of the language runtime modules that it represents. If the communication buffer from application program contains a Library Identifier, then decision block 740 determines if there is a Library Identifier in the Application Profile Data Base matching this Library Identifier from the communication buffer. If there is a Library Identifier in the Application Profile Data Base matching this Library Identifier, then process block 745 packages the LVP matching the specified Library Identifier into the return buffer. Thereafter, processing continues to process block 730 which sends the return buffer back to the application program address space, where the return buffer will be processed by language runtime modules. Returning now to decision block 740, if there is no Library Identifier in the Application Profile Data Base matching this Library Identifier from the communication buffer, then processing continues to process block 755 which packages an informational message into the return buffer which will be sent back to the application program indicating that the Library Identifier did not match a Library Identifier in the Application Profile Data Base. Returning now to decision block 735, if the communication buffer from application program does not contain a Library Identifier, then processing continues to process block 750 which packages the default LVP into the return buffer. Referring now to FIG. 8, the flowchart illustrates the operations preferred in carrying out the process for initializing application programs using the Run Time Subsystem. The process starts at process block 800 when an application program has been started (e.g., by submitting a batch job under the "MVS/ESA" operating system). Thereafter, decision block 805 determines if the Run Time Subsystem is enabled (by internally checking for the presence of a special signature CSECT). If the Run Time Subsystem is enabled, then decision block 810 determines if the Run Time Subsystem has been started successfully (as detailed in FIG. 5 and FIG. 6). If the Run Time Subsystem has been started successfully, then decision block 815 determines if an Application Group Identifier exists. If an Application Group Identifier exists, then process block 820 puts the Application Group Identifier into the buffer that will be sent to the Run Time Subsystem for processing. Thereafter, decision block 825 determines if a Library Identifier exists. If a Library Identifier exists, then processing continues to process block 905 on FIG. 9. This processing path is illustrated by flowchart connectors B, 898 on FIG. 8 and 901 on FIG. 9. Returning now to decision block 825, if a Library Identifier does not exist, then process block 840 packages in the buffer that will be sent to the Run Time Subsystem an indication that the application program should use the default Library Identifier. This indicates that the application program has no specific language runtime library requirement, rather that is should be given whatever the installation has indicated via the Application Profile Data Base is the default level. Thereafter, processing continues to process block 910 on FIG. 9. This processing path is illustrated by flowchart connectors C, 899 on FIG. 8 and 902 on FIG. 9. Returning now to decision block 815, if an Application Group Identifier does not exist, then processing continues to decision block 825 to test whether a Library Identifier exists. Returning now to decision block 810, if the Run Time Subsystem has not been started successfully, then process block 835 issues an error message that the Run Time Subsystem is not available and terminates the application program. In an alternative embodiment, process block 835 may proceed with application program initialization without Run Time Subsystem involvement as illustrated in FIG. 4. Returning now to decision block 805, if the Run Time Subsystem is not enabled, then process block 830 starts the application program without Run Time Subsystem involvement as illustrated in FIG. 4. Referring now to FIG. 9, after control passes from decision block 825 as indicated by flowchart connectors B, 898 on FIG. 8 and 901 on FIG. 9, then process block 905 puts the Library Identifier into the buffer that will be sent to the Run Time Subsystem for processing. Thereafter, process block 910 sends the communication buffer to the Run Time Subsystem for processing. This may be accomplished using the Subsystem Interface (SSI) in the "MVS/ESA" operating system, or by other operating system specific interprocess communication mechanisms well known to those skilled in the art. Thereafter, process block 915 waits for a reply from the Run Time Subsystem process. Thereafter, decision block 920 tests for the receipt of the reply from the Run Time Subsystem. This may be an actual test, or the application program initialization logic may be awakened using standard operating system interprocess communication techniques well known to those skilled in the art. If the reply has not been received, then processing loops back to process block 915 to wait for a reply from the Run Time Subsystem process. Returning now to decision block 920, if the reply has been received, then decision block 925 determines if the reply contains a Library Vector Pointer (LVP) which is the linkage mechanism to the language runtime modules. If the reply contains a Library Vector Pointer, then processing continues to process block 955 on FIG. 10. This processing path is illustrated by flowchart connectors D, 998 on FIG. 9 and 1001 on FIG. 10. Returning now to decision block 925, if the reply does not contain a Library Vector Pointer, then decision block 930 determines if the reply indicates that application program initialization should use JCL STEPLIB in lieu of an LVP. If the reply does not indicate that application program initialization should use JCL STEPLIB in lieu of an LVP, then process block 945 issues an error message indicating that a severe error has occurred and stops the initialization of the application program. Returning now to decision block 930, if the reply indicates that application program initialization should use JCL STEPLIB in lieu of an LVP, then process block 935 loads the language runtime modules from LPA or from steplib as illustrated in FIG. 4. Thereafter, decision block 940 tests for successfully loaded language runtime modules. If the language runtime modules did not successfully load, then process block 950 issues an error message and stops initialization of the application program. Returning now to decision block 940, if the language runtime modules successfully loaded, then processing continues to process block 965 on FIG. 10. This processing path is illustrated by flowchart connectors E, 999 on FIG. 9 and 1002 on FIG. 10. Referring now to FIG. 10, after control passes from decision block 925 as indicated by flowchart connectors D, 998 on FIG. 9 and 1001 on FIG. 10, then process block 955 uses the LVP returned from the Run Time Subsystem to link the application program with the language runtime modules needed. The LVP is used to find these modules in storage. The remainder of the language initialization can proceed using these modules now that they have been successfully found. Thereafter, process block 970 gives control to the application program to execute as the language environment has been initialized. Returning now to process block 965, to which control is passed from decision block 940 as illustrated by flowchart connecters E, 999 on FIG. 9 and 1002 on FIG. 10, process block 965 builds the Library Vector (LV) and its pointer (LVP) as illustrated in FIG. 4, as the Run Time Subsystem has indicated that this is the approach to use instead of being given an LVP for preloaded language runtime modules. Thereafter, processing continues to process block 955 to link the application program with the language runtime modules needed. Although the above preferred embodiment is implemented in an MVS operating system environment, those skilled in the art will recognize that the present invention may be applied to other operating system environments. Referring now to FIG. 11, a block diagram illustrates a computer system 1100 used in performing the method of the present invention, forming part of the apparatus of the present invention, and which may use the article of manufacture comprising a computer-readable storage medium having a computer program embodied in said medium which may cause the computer system to practice the present invention. The computer system 1100 includes a processor 1102, which includes a central processing unit (CPU) 1104, and a memory 1106. Additional memory, in the form of a hard disk file storage 1108 and a computer-readable storage device 1110, is connected to the processor 1102. Computer-readable storage device 1110 receives a computer-readable storage medium 1112 having a computer program embodied in said medium which may cause the computer system to implement the present invention in the computer system 1100. The computer system 1100 may also include user interface hardware, including a mouse 1114 and a keyboard 1116 for allowing user input to the processor 1102 and a display 1118 for presenting visual data to the user. The computer system may also include a printer 1120. Although the present invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the spirit and the scope of the invention.
|
Same subclass Same class Consider this |
||||||||||