MXPA98006738A - Lengu administrator interface - Google Patents

Abstract

Routines Defined by the User (UDR), capable of being expressed in one or more languages, are handled by determining a native language to the UDR, for example, looking for a catalog of the system. If a language administrator with the native language has not already been loaded, the language manager is loaded into a network server memory. If the UDR has not already been instantiated, the UDR is instantiated and initialized. Then, an execution context for the UDR is created and this UDR is executed. The language manager's load is handled by a general language interface, load the language manager, create a context of the language manager and execute this language manager

Description

LANGUAGE ADMINISTRATOR INTERFACE BACKGROUND The present invention relates to a language manager for a database management system (DBMS). The advent of powerful, yet economical computers has made these machines an integral part of many organizations. An important class of application for these computers includes a database, which is a body of information, which is organized logically, so that the information can be stored, searched and retrieved by a "database engine" - a collection of software methods (programming and computer instructions) to manipulate data in the database. This database allows users to perform operations, such as placing, adding, deleting and updating records stored on the computer, without a detailed knowledge of how the information that actually makes up the records is stored on the computer. A powerful type of DBMS is known as a relationship DBMS where the stored information appears to the user as a set of tables, each of which is called a "relation". In each relationship, the information is arranged in rows and columns, with the columns of data being related to each other by one or more predetermined functions. In addition, each column has an attribute and each attribute has a domain that includes data values in that column. The structure of a relationship database can be modified by selectively redefining the relationships between the tables. A database engine can perform complex searches in a relationship database, quickly and easily, using any of several database interrogation protocols, such as the method expressed by the Structured Interrogation Language (SQL) or by other mechanisms. The relationship between the tables that enable the results of a search will be cross-referenced automatically with the corresponding information with other tables in the database. A variety of operations will be performed on the tables in the database, which include joint operations, projects and selections. These operations can be done in standard form as well as with the data types defined by the user. To access a particular line of information in the relationship DBMS, a question compiler converts a user's request, typically expressed in SQL, into a set of operations that will be performed in one or more input relationships, to Provide a solution in response to the user's request. Also, the user's request may, under certain predetermined conditions, cause one or more user-defined routines (UDR) to be executed. These UDRs can be performed either as internal programs or external programs. An internal program is a program that runs within the execution environment managed by the DBMS. The internal program is typically written in an interpreted language, which is only supported within the environment of the DBMS. In contrast, an external program is capable of operating in an environment managed by an operating system. External programs are typically expressed in a high level language, which can be patented or can be a standard language, such as Ada, Basic, C, C ++, Cobol, Java, Pascal or a programming language of the fourth generation, among others. Although most relationship database administrative systems support pre-defined procedures, performed as internal programs, not all systems support external programs. Likewise, in systems that support external programs, the supported language can be interpreted, as opposed to compiled, which leads to less than optimum performance of the process. Other complex code systems support specific languages, These systems are inflexible in that a modification of an existing language or an addition of a new language is tedious.

Compendium An apparatus, operated by computer, supports one or more User Defined Routines (UDR), capable of being expressed in one or more languages. The device first determines a native language to the UDR, looking for a system catalog. Next, the device checks if a language manager, associated with the native language has already been loaded and if not, the device loads the language manager into a memory of a server in the network. The device then checks if the UDR has already been exemplified and if not, exemplifies and starts the UDR. The device then creates an execution context for the UDR, after which the UDR is executed. The load of the language manager is handled by a general language interface, able to start the language manager, load this language manager, create a context of the language manager and execute this language manager. Advantages of the invention may include one or more of the following. The system described here makes it possible for UDRs to be executed in a relationship DBMS in a manner that is independent of the details of realization of the UDR. In addition, a support installation for multiple languages is provided. A database language administrator allows a particular language and its means of UDR support to be developed subsequent to a development of a database engine. Likewise, an alternative support medium can be developed for an existing language. Additionally, repairs can be made without replacing the network server or coding modules. The UDR can be done in a number of languages. The UDR can be done in a number of languages. The support of multiple languages reduces the complexity in the realization of the UDR, since the software can be coded to take advantage of the specific forces of specific languages. In addition, language interpreters can be added or modified on request, in an operation system. Similarly, UDRs can be added or modified upon request in an operation system. These UDRs can be arbitrarily processed in their performance, which includes the realization of new data types and operations for the database engine. Other features and advantages will be apparent from the following description and from the claims.

Description of the Drawings Figure 1 is a block diagram of a network server with a DBMS and one or more language administrators; Figure 2 is a schematic illustration of the components of each language manager; Figure 3 illustrates a catalog inscription of the system representative procedure (SYS_PROCEDURE); Figure 4 is a flow diagram illustrating an interrogation execution process; Figure 5 is a flow chart illustrating a grammatical analysis process; Figure 6 is a schematic illustration of the modules within a language manager and their interactions with a routine administrator; and Figure 7 is a diagram of the entity relationship of the language manager.

Description Referring now to Figure 1, a database network server 110, having one or more language administrators, 190-192, is shown. A client 178 can communicate directly with the database network server 110. Alternatively, a client 198 may communicate with the network server 110 using a shared memory (SM) 197. The requests of the client 178 are they supply a grammar analyzer 180 to analyze the instructions and functions of the database. The grammar analysis functions are provided to a determiner 184 of the user-defined routine (UDR). In response, the determiner of the UDR 184 searches for the function in a system catalog 186, for more details in the grammatical analysis functions, which include the language in which the function is written. After retrieving information about the function of the system catalog 186, the determiner 184 of the UDR passes this information to the routine administrator 188. This routine administrator 188, in turn, connects to one or more language administrators (LM) 190-192. The tasks performed by each LM 190-192 include: identifying a routine (function or procedure) using a unique descriptor that contains static routine information, handles the loading and unloading of the UDR modules in the memory of the network server 110, creates a data structure that contains the dynamic information necessary to execute a case of the routine in the context of an SQL exposition, and handles the actual execution of the UDR. Language administrators 190-192 also provide language-specific facilities so that routine administrator 188 needs only to invoke the appropriate language administrator. Thus, if the language manager 192 handles function calls related to Java, language administrator 192 may have a Java-specific exception system. The languages handled by the routine administrator can include C, Java, Cobol, Stored Procedure Language (SPL), among others. Each language manager, 190-192, communicates with a language execution engine that uses a shared memory. For example, since language manager 192 handles Java-related calls, language manager 192 is connected to shared memory (SM) 194, which, in turn, is accessible by a language-specific virtual machine, for example. example, the Java virtual machine (VM) 196. Upon receiving the functions of grammatical analysis from the determiner 184 of the UDR, the routine administrator 188 determines whether the language manager, which supports a particular grammatical analysis function, has been loaded in the memory of the network server 110. Otherwise, routine administrator 188 loads the required language manager into memory. Thus, routine administrator 188 loads language administrators dynamically, as necessary. Details regarding the invoked function are passed to the appropriate LM, 190 or 192, which, in turn, determines whether the required function has been loaded. The LM, 190 or 192 thus provides the necessary facilities for the network server 110 to load and execute the UDRs.

Referring now to Figure 2, the details are shown in a representative language administrator 190 (Figure 1). The LM 190 has an initialization component 170, a load component 172, a context component 174 and an execution component 176. The initialization component 170 establishes variables for the predetermined settings, when the LM 190 is first invoked and loaded in memory of. The load component 172 is made available to the network server processes, to load the specific modules of the UDR into the memory. The load component 172 provides a common interface to a set of language-specific calls, which variably installs any coding required by the specific language, such as loading an interpreter, installing codes and / or data modules containing the specific routine, checking licenses for the modules to be loaded, and to download modules and / or remove specific codes from the memory language. The context component 174, which is made available to the network server processes, to handle the context for the UDRs, provides a common interface to a set of language-specific calls that create and destroy state context cases for routines particular. The execution component 176 of the LM is made available to the processes of the network server, to carry out the execution of a UDR. A component of execution 176 provides a common interface for general routine management and a set of language-specific calls that establish, call and return the values of the UDRs. The LM 190 also has a general language interface component 177, which is a specification for a set of calls necessary to perform a specific language interface. These demands are used by the components of the load, context and execution, 172-176, to perform their duties. The general language interface component 177 thus provides a common interface for language-specific functions that (1) upload and download modules containing the UDRs; (2) create and destroy the language context for each routine; and (3) classify arguments, execute a routine and return the results. In the realization of the general language interface component 177, a succession of functions for each language is loaded from a module that can call routine C, which can be reloaded as required. A Routine Interface C is an example of the General Language component for the routine C. It performs specific actions necessary to call the UDR routines written in C from the network server 110. The Routine C Interface provides the necessary functions to load and unload a coding module of the shared object; assign and release a parameter structure for a routine; convert and drive arguments in a set of calls, execute the routine and return the result of the routine. In another embodiment of the general language interface component 177, which uses a Stored Procedure Language (SPL), the SPL interface performs specific actions necessary to call the SP modules from the network server. An SPL interface provides functions to lock the procedure in the procedure cache during execution, convert and pass arguments, execute the Stored Procedure and return the result. Returning now to the routines that carry out the general language interface on the client's side, the routine interface of the client's side carries out specific actions required by the network server to call the routines resident in the client's code . This client routine interface provides the necessary functions to inform the client of the need for a particular routine and module to be executed. The customer's routine interface also converts and passes arguments to the client that executes the routine and returns the results from the client. The following data structures and function calls are prototypes of those used to create a language interface specific to the Language Administrator. The descriptors created or used by these calls are maintained in lists linked by the functions of the Top Level Language Manager, and can be subject to the least recently used cache (LRU), Each supported UDR language provides an example of each one of these calls. Calls are loaded from a simple shared object module. The name of the initialization function will be stored in a table of the SYSROUTINELANGS system catalog, for each language.

STATE udrim_XLANG_parse (Grammar analysis of the char * string of the external name external_name, // name given in the value of the external key of the user of the name of the module and a char * module, // name of the symbol to be used in the module name by the functions of the char * symbol); // subsequent language. The name of the argument symbol of the module is set to the name of the module and any other information in the string is analyzed grammatically in the argument of the symbol. If there is no module name, a single string, for example "NULL" must be copied to the external name. If there is no extra information in the external name string, the argument of the symbol is set to an null string. For security, both arguments must be the size of the attribute of the full external name of the SYS_PROCEDURES table. This function is used when the initialization of the udrlm desc structure occurs.

?? Make any STATUS load udrlm_XLANG_load (proccache_t * rdesc, specific to routine language and module // routine descriptor specified, for example, udrlm_mdesc * mdesc binds shared objects and looks for symbols, if the field); // mdesc reference account module descriptor is zero, then the structure is not fully initialized and there is a first reference to the module specified in rdesc. In this case, this function will load the module and fill the specific field of the mdesc language, as necessary. After the module is loaded, this function will be called again with the mdesc reference accounts greater than zero. In these cases, the specific routine must be loaded and the specific rdesc language field filled appropriately. (In routine language C, for example, the first call is dlopenO and subsequent calls make dlsym () s locate functions in the module). All memory must be assigned from a broad set of the system. FÜNCSUCC returns after being successful.

STATE udrlm_XLANG_unload (Make any download udrlm_mdesc * mdesc language-specific); // Module module descriptor specified, for example, separation of shared objects. FUNCSUCC returns when it succeeds.

STATUS This function will be called udrlm_XLANG_context_open (before the first execution proccache_t * rdesc, from a User Routine in routine descriptor // an exposure (for example at the start of a udrlm_rinst ** SQL exposition, or when a rinst is resolved) // // descriptor of new routine limited to the example (ref). last). If * rinst is NULL, this function will be assigned to a new structure and any other memory needed by the language context for the UDR. Otherwise there is a previously assigned context structure that is recycled from the cache and is not initialized for the first use of the Reference Routine. The memory must be allocated from a session set. FUNCSUCC returns when it succeeds.

Note: This function allocates both common and language-specific memory in order to minimize the number of allocation calls and reduce memory fragmentation. For example, logically, everything in the state of the language.

STATUS Perform any cleanup udrlm_XLANG_context__close (specific to the language udrlm_rinst * rinst; after the final use of the // context descriptor context structure) it will release the rinst structure and the associated specific resources of the language, it will be called when the memory descriptors are removed Cache: Return FUNCSUCC to success STATUS udrlm_XLANG_execute (Sets and executes a udrlm_rinst * rinst, routine that uses arguments // given example descriptor. The rinst will be used void * args, // to keep the information state arguments through void * rets); // multiple calls to this routine return values. The return values will be placed in the roots and the return status will be placed in the rinst in the successful execution. The return of STATUS indicates the result of the execution attempt, not the result of the UDR itself.

STATE reload module (This function can be ModuleName, // SQL call to reload module by reinstalling a routine module, All Language) // executions of UDR languages: e to use are with reference to this module, while this function is operating will continue using the old module, until the end of the exposure. If the module is not already installed, it will be loaded for the first time.

STATUS replace_module (This function can be OldModuleName, // SQL call for module by reinstalling replace a module of NewModuleName, // routine.) All new module executions by using UDRs are referenced Language) // to this module, while this language for using function is operating, it will continue using the old module until the end of the exposure When the first routine that uses the specific language is invoked, the language interface itself is loaded and initialized, following these steps: 1) the structure udrlm_ldesc is located or created for the language, 2) the row for the language is selected from the catalog SYSROUTINELANGS. If there is no row for this language, an error is returned, 3) the row specified by a "langinitfunc" attribute of the SYSROUTINELANGS table specifies the language initialization routine in the SYS_PROCEDURES catalog, 4) a standard C language load module operation is executed: a udrlm_mdesc structure and a udrlm_rdesc structure are initialized from the table SYS_PROCEDURES. - The function udrlm_lang_load_module () of the construction language C is called, to load the language initialization interface module. 5) The function udrlm_XLANG_init () that has reference in the attribute langinitfunc, is called to initialize the structure udrlm_ldesc. With the last reference to a UDR that uses a specific language falls, the language interface is interrupted and removed. The stages that occur during the Language Fall are: 1) The udrlm_ldesc structure of the language is removed from the language list to prevent new routines from using this language. 2) The function udrlm_XLANG-shunt () is called to clean resources. 3) The udrlm-clang-unload-module () function of the C construction language is called, to download the language interface module. If any routine that references the language under consideration is subsequently invoked, and the language entries in the SYSROUTELANGS and SYS_PROCEDURES catalog have not been DELETED, the specific language module will be reloaded and initialized. If the catalog inscriptions are DELETED, the subsequent function invocations will try to load the language, but an error will occur when the language is not in the catalog. Also, when all the routines with reference to the module have dropped, the module will be removed as well. The steps taken during a module FALL are: 1) The function udrlm_unload () is called for a routine. 2) If the last reference in the specific module exists, it will be removed by calling the udrlm_XLANG_unload_module () function of the language. 3) If there is the last reference to language A. It is called the function udrlm_XLANG_shunt (). B: The udrlm_ldesc function is released. C. The udrlm_clang_unload_module () function of the C construction language is called to download the language interface module. D. The udrlm_mdesc function of the language module is released. Turning now to Figure 3, a representative system procedure table (SYS_PROCEDURE) is shown. The SYS_PROCEDURE table has a number of arguments, argument type column, return type column, language type column and language specific exposure column. Using the SYS_PROCEDURE table, the determiner 184 of the UDR can search for specific data in the function being analyzed, which includes the type of language, the number of arguments accepted, the type of arguments to be returned and other information specific to the language / routine . Referring now to Figure 4, an interrogation execution process 200 is illustrated. In the process 200, the client initially sends an SQL command to the network server 110 (step 202). Next, this server 110 of the network grammatically analyzes the command (step 204). Once analyzed, the interrogation is optimized in step 206 by an optimizing device. Next, the instructions for performing the required interrogation is executed (step 208) before the process 200 exits (step 210). Turning now to Figure 5, the grammatical analysis process 204 (Figure 4) is shown in more detail. Initially, the process 204 identifies the function that is invoked from an SQL command (step 222). Next, process 204 resolves the function by calling a particular example using the table SYS_PROCEDURE of Figure 3 (step 224). The process 240 of grammatical analysis then identifies the particular language that is invoked (step 226). Next, the process 204 determines whether the desired language manager has already been loaded into the memory (step 228). Otherwise, the administrator of the desired language is loaded (step 230). Alternatively, if the language manager has been loaded, the process 204 proceeds to step 232. From step 228 or 230, the grammatical analysis process 204 proceeds to step 232 where the language manager determines whether the function invoked has already been loaded in memory. If not, the process 204 exemplifies the desired function (step 234) and performs an initialization of the specific function, as necessary (step 236). From step 236 or step 232, in the event that the invoked function has already been loaded, routine 204 creates an execution context (step 238). Next, the function 204 of the grammatical analysis exits (step 240). Figure 6 illustrates details of the interactions between routine administrator 188 and language administrators 190-192. The administrators 188, 190 and 192, interact by means of a plurality of medium layers, including layer 302 of the subsequent determination of the routine, an example of the subsequent determination layer 303, a final limit execution box 320, a layer 321 of repetition execution and a cleaning layer 330. Interaction between layers and administrators is achieved using data structures, as discussed below. The structure of the Routine Descriptor (RDESC) is used by the LM components in all sessions to store static information about a particular routine. The RDESC structure is assigned in a shared system wide memory and a cache memory for reuse. The Routine Example structure (RINST) describes the context of a routine sequence in an SQL exposition. This RINST structure contains references to static, routine, status and dynamic data for each execution. Each routine invocation logically has a different RINST, but for efficiency, these structures can be cached and recycled between exposures on a broad session basis. The structure of the Language Descriptor (LDESC) is used for vector LM operations to the appropriate language functions. The structure of the LDESC is filled by the specific language code when this language is initialized and linked in the list of languages by the Language Administrator. The structure of the Module Descriptor (MDESC) is used to describe a simple module of the UDR, each of which can contain many routines. The structure of the MDESC contains public information, which includes the name of the module, and private information used only by the language functions of the module. The MDESC structure is filled when the module is loaded and linked in the module list by the Language Administrator. Turning now to the middle layers, 302 and 303, of subsequent determination, for each routine, the subsequent determination layer 302 supplies a key to the language manager's load routine 304, which, in turn, loads a structure of RDESC . After the LM load routine 304 has been executed, the structure of the RDESC is passed into the language initialization module 306. After that the RDESC data structure has been initialized, this RDESC structure is provided to a load module 308, after which the RDESC structure is fully initialized. The initialized RDESC structure is then provided to the subsequent determination layer 303, where, for each example, a context-open module 310 of the language manager and the context open module 312 process the RDESC structure of the routine descriptor. From the pre-determination layer 303, the fully initialized RDESC structure is provided to the open LM context module 310, which, in turn, generates a RINST data structure. This RINST data structure is initialized at this stage, before going back to the pre-determination layer 303. Upon completion of the process from the pre-determination layer 303, the routine administrator layer 300 supplies the RDESC structure to a middle execution layer, which can furthermore be divided into a final limit execution layer 320 and an execution layer 321. repetition In the case of the end limit execution layer 320, the routine example data structure is provided to a shared-state module 322 of the language manager. The shared state module 322 copies the status information in the RINST data structure. This updated RINST data structure is again provided to the final limit execution layer 320. Additionally, for each repetition, the RINST routine sample data structure, as well as the arguments provided for an execution routine 324 of LM. The resulting structure of RINST and produced from the execution routine 324, are provided to a execution routine 326, which returns the output back to the execution unit 321 of repetition. From the repetition execution unit 321, the routine management layer 300 communicates with the cleaning layer 330 which, in each case, supplies an RINST data structure to an LM context closure module 332 to free memory and the storage data associated with the various data structures. The data structure RINST then passes to a closed context module 334, which supplies the status information back to the cleaning layer 330. Referring to Figure 7, a language management entity relationship diagram of the UDR is illustrated. In this diagram, four possible relationships, 380-386 exist. The 380 relationship, exemplified by two parallel lines, indicates a one-to-one relationship. The ratio 382 indicates a one-to-many relationship, illustrated in a line next to a left arrow. The 384 relation indicates a mapping from zero to many, it is shown as a circle at once of the left arrow. Finally, the zero to one ratio of 386 is shown as a zero next to a vertical line. The language management entity relationship of the UDR is discussed in the context of the 380-386 relations. In Figure 7, a Storage Module 372 may contain one or more routines, each represented by a Routine Key 350, a Language Module 370 may have reference to one or more Storage Modules 372. Each Storage Module 372 has exactly one Module Descriptor 374, and each Language Module 370 has exactly one Language Descriptor 376. This Language Descriptor 376, in turn, has a Module Descriptor 374, which can be used by one or more languages. A Routine 352 descriptor has a Module Descriptor 374. The Module descriptor may have reference to one or more Routine Descriptors 352. Each Routine Descriptor 352 contains an Argument Description 354 and a Return Description 356. A Routine Descriptor 352 may be contained in many Routine Examples. Each Routine Example contains a list 366 of Routine Arguments, a list 364 of Routine Returns, a Routine Status set 362, and a Routine Context 360, none of which is referenced by any other Routine Example 358.

An exemplary C language interface, an example of the General Language Interface, which provides the function calls, is described below.

STATE udrlm_clang_init (Fill the udrlm_ldesc. The udrlm_ldesc *); // other functions in this section language descriptor enter the structure for use by the Language Administrator. These functions are statically linked in the CPU module, so a load is not necessary. FUNCSUCC returns when it succeeds.

STATE udrlm_clang_shut (A NOP because the udrlm_ldesc *); // structure udrlm_ldesc of the language descriptor C language has not been clarified.

Since the language of the network server, in this case C, is the basis of the Language Administrator itself, these functions are built to code in the network server 110, rather than being dynamically loaded. Also, unlike other languages, the C language initialization function is called at the beginning of the system, rather than the moment of language loading. The techniques described here can be performed in the ardware (computer equipment) or software (program and computer instructions) or a combination of the two. Preferably, the techniques are performed in computer programs that run on programmable computers, which each include a processor, a storage medium that can be read by the processor (which includes volatile and non-volatile memories and / or elements of storage) and appropriate input and output devices. The program code is applied to the data that enters using an input device to perform the functions described and to generate output information. This output information applies to one or more output devices. Each program is preferably performed in a high-level procedure or an object-oriented programming language, to communicate with a computer system. However, programs can be made in a set language or machine, if desired. In any case, the language can be compiled or interpreted. Each computer program is preferably stored in a device or storage medium (for example, the CD-ROM, hard disk or magnetic disk) that can be read by a programmable computer for general or special purposes, to configure and operate the computer when the storage medium or device is read by the computer, to carry out the described procedures. The system can also be realized as a storage medium that can be read by computer, configured with a computer program, where this storage medium, thus configured, causes a computer to operate in a specific and previously defined way. Other embodiments are within the scope of the following claims.

Claims (22)

1. CLAIMS 1. A method, performed by a database network server, to manage one or more User Defined Routines (UDR), capable of being expressed in one or more languages, this method includes: determining a native language to the UDR; check if a language manager, associated with the default native language, has already been loaded and, if not, load the language manager into the network server's memory; check if the UDR has already been exemplified and, if not, exemplify and initialize this UDR; and create an execution context for this UDR.
2. 2. The method of claim 1, further comprising executing the UDR.
3. 3. The method of claim 1, further comprising supplying a C language manager.
4. 4. The method of claim 1, further comprising providing a Java language manager.
5. 5. The method of claim 1, wherein the Java language manager communicates with a Java virtual machine, which uses a shared memory.
6. 6. The method of claim 1, wherein the determination of the native language to the UDR further comprises searching for a system catalog.
7. 7. The method of claim 1, further comprising creating and initializing a routine descriptor structure (RDESC), a routine example structure (RINST), a language descriptor structure (LDESC) and a module descriptor structure ( MDESC).
8. 8. The method of claim 1, wherein the load of the language manager further comprises a general language interface, capable of initializing the language manager, loading the language manager, creating a context of the language manager and executing this language manager .
9. 9. A method, performed by a database network server, to manage one or more user-defined routines (UDR), capable of being expressed in one or more languages, this method includes: determining a native language to a UDR; selectively enable a language manager, associated with the native language determined; execute the UDR, with the use of the language administrator enabled selectively.
10. 10. A computer system, which includes: a processor; a memory array, coupled to the processor; an exhibitor, coupled to the processor; a data storage device, coupled to the processor, for storing a database management system (DBMS), to handle one or more User Defined Routines (UDR), capable of being expressed in one or more languages and a software (programs and instructions of the computer), resident in the memory array or the data storage device, to carry out the following operations: determine a native language to the UDR; check if a language manager, associated with the native language, has already been loaded and if not, load the language manager into the network server's memory; create an execution context for the UDR.
11. 11. The computer system of claim 10, further comprising a shared memory, for communications between the language-specific virtual manager and a language machine.
12. 12. The computer system of claim 11, wherein the UDR is interpreted by the language-specific virtual machine.
13. 13. The computer system of claim 10, wherein the UDR is compiled and executed by the language-specific virtual machine.
14. 14. The computer system of claim 13, wherein the language-specific virtual machine comprises a Java virtual machine.
15. 15. The computer system of the claim 10, which further comprises a structure of the routine descriptor (RDESC), a routine example structure (RINST), a structure of the language descriptor (LDESC) and a structure of the module descriptor (MDESC).
16. 16. The computer system of the claim 10, which also comprises a general language interface, capable of initializing the language manager, loading the language manager, creating a context of the language manager and executing this language manager.
17. 17. A computer software for a DBMS, this software resides on a computer-readable medium and includes instructions to cause the computer to perform the following operations: determine a native language to the UDR; check if a native language, associated with the native language, has already been loaded and if not, load the language manager into a network server memory; check if the UDR has already been exemplified and if not, exemplify and initialize this UDR; and create an execution context for the UDR.
18. 18. The software of claim 17, further comprising instructions for executing the UDR.
19. 19. The software of claim 17, further comprising instructions for searching a system catalog in the determination of the native language to the UDR.
20. 20. The software of claim 17, further comprising instructions for creating and initializing a structure of the routine descriptor, a structure of a routine example (RINST), a structure of a language descriptor (LDESC) and a structure of a code descriptor. module (MDESC).
21. 21. The software of claim 17, wherein the instructions for loading the language manager further comprise instructions for supplying a general language interface, capable of initializing the language manager, loading the language manager, creating an context of the language manager and execute this language manager.
22. 22. The software of claim 17 further comprising instructions for executing the UDRs in a variety of languages, using a routine manager.