JPH10501083A - Method and system for calling a function from a program running in another environment - Google Patents

Abstract

(57) Abstract: Computer program functions 211 and 212 written in a first programming language and designed to be executed in a first environment are written in a second programming language and executed in the first environment. A method is disclosed that allows it to be invoked as a request from a computer program 220 that is not possible. The computer program 220 supplies the request and has the ability to suspend and resume its operation. Requests are placed in queue 206 and removed from queue 206 by thread 204 running in the first environment. Functions 211 and 212 cannot be executed by computer program 220 because computer program 220 does not provide the necessary environment.

Description

DETAILED DESCRIPTION OF THE INVENTION                     From a program running in another environment                     Methods and systems for calling functions Field of the invention   The present invention relates to distributed computing, and in particular, to the C programming language. C program from a computer program that is not written in It relates to calling functions written in the programming language. More specifically, The present invention relates to a distributed computing (DCE) such as a multiple virtual storage (MVS) environment. g Environment, a distributed computing environment) The use of DCE services from the system.Background of the Invention   Recent advances in distributed computing have been driven by the Open Software Fountain System (OSF). dation) of the DCE. The purpose of DCE is to operate a heterogeneous computer To provide some degree of transparent computing in a virtual environment. OSF Is a portable source code written in C language and this source code Provide specifications to support porting. OSF DCE is UNIX, MS-D Multiple operating systems including OS, VMS, CRAY and SAA environments Available or planned for the system. Its features include a common communication protocol. Protocols, common system administration and common data services. Concrete In general, the OSF DCE provides generality and integrates the following key components: The purpose is to support the conversion. ・ Remote Procedure Call (RPC) that hides the complexity of a distributed environment broth) Naming to use information independently of location, system, local naming conventions Directory ・ Distributed file system for transparent use of remote files Security to prevent unauthorized access to distributed resources ・ Access to DCE service by MS-DOS personal computer PC integration to help provide ・ System management function   As mentioned above, DCE is written in C language, and UNIX operating system Developed on a rating system.   MVS is an IBM Corporation System / 370 and System Operating system running on a system / 390 mainframe computer Stem. MVS is described in an assembler (Asm) for these computers. ing.   Since most DCE functions are written in C language, It can be easily called from the application described in. These functions Is based on the C library driven by the presence of the "main" function in the C program. It is assumed that it is called from the “C environment” established in this way.   For information on the "C environment" and C programming in general, see Kernighan (B.W.K.) ernighan) and D.M. Ritchie, "The C Programming Language : Second Edition ”, 1988, published by Prentice Hall (Japanese title“ Programming Word C Second Edition ", translated by Haruhisa Ishida, Kyoritsu Shuppan).   In the DCE function, the application uses the link conventions, stack and recovery rules. It is expected to use routines and pass arguments or parameters to functions. It is assumed that the vehicle travels in the "C environment", including those that can be used. parameter The differences in data passing will now be described as examples of different environments.   In the C function, it is assumed that the parameters are passed using "pass by value". With pass-by-value, the called function must be parameterized with primary variables instead of the original variables. Data value. The called function directly returns the value of the variable of the calling function. It cannot be changed, and it is necessary to change a private temporary copy of the called function. I can't do it. If the calling function's variables need to be changed, the calling , You must provide the address of the variable to be changed, and in the function called Declare that parameter as a pointer and access the variable indirectly through it Must.   MVS uses “call by reference” to pass arguments to functions. It is assumed to be. For pass-by-reference, the called routine is -Has access to the original parameters but not the original.   Applications not written in C, especially those written in 370 assembler Applications do not provide the environment expected by DCE functions. system/ One example of such an application written for a 370 computer is the IB Transaction processing software of CICS Corporation of M Corporation It is.   This problem was described above with respect to the DCE function, but the function written in C language has For all software not written in C that you want to access, Even exists.   Earlier solutions to the problem of calling a function from one environment to another are notable. It has been aimed at solving problems with certain environments and specific applications. sand In other words, general to the problem of non-C applications that call functions written in C There have been no attempts to provide a strategic solution. To solve these, the C function Call setup routine first to prepare what looks like C environment Includes non-C caller routines. Then, the C function is called, and upon completion, The C calling routine collects the results of the C function and resolves the error condition etc. , The closing routine must be called. Such a solution Oversight of border setting The performance is low due to the presence of the code, the programming is complicated and there are many errors.   Thus, as a bridge between two environments ("C environment" and "non-C environment") Provides an interface for specific environments and specific applications DCE services can be accessed from non-DCE environments without the need for special code This is advantageous.   The previous interface between the environments was the bootstrap module or the initial The initialization module has a significant amount of programming logic. these The initialization module is typically used by apps that try to use the function in another environment. Applications (users) allocate resources such as memory. These The interface can easily be stopped without stopping the consuming application. I can't let it. Therefore, without stopping the using application, It is not possible to refresh the interface with certain characteristics. Cut off Followed by states with different characteristics adjusted using a customization file It would be advantageous to provide an interface that can be restarted atDisclosure of the invention   Thus, the present invention is written in a first programming language and runs in a first environment. A computer program function designed to be Written in the language Cannot execute in one environment, supply requests, and suspend and resume operations. In a way that can be called as a request from a computer program that has Creating a thread that runs in the first environment; Providing a queue for receiving a request from a computer program. Taking and queuing the request; and De-queuing and loading and executing functions within the thread. And a method comprising:   In the preferred embodiment, before the application program itself continues execution Instead of the application program waiting for the function to complete execution, Interrupting the computer program after the queuing step. And after the executing step, upon completion of the function, the computer program Restarting the system is further included in the method. Application P The program may continue processing while waiting for the function to complete execution. it can.   In a preferred embodiment, the first programming language is a C programming language. And the first environment is a C programming environment.   This method allows the functions to be loaded individually on demand, but is preferred In the example, a plurality of functions are provided in a function module, and the function module is loaded. After loading the function, Before execution, the address of the requested function is obtained from the function module and The step of executing comprises a call to the obtained address. Function module It can be used, for example, to associate security-related DCE functions, etc. If the numbers are collected in a single module and the performance of the loading step improves, The advantage is brought. Also, in the preferred embodiment, multiple threads are provided. These multiple threads remove requests from a single queue and share a common function. To share. Again, use multiple threads to improve the throughput of processing requests. Better performance improves performance.   In the preferred embodiment, the function is a DCE function written in C and the assembler The computer program described in (Asm) runs in an MVS environment.   The present invention relates to a computer program function written in the C programming language. Is not written in the C programming language, is not executed in the C environment, supplies a request, Request from a computer program capable of suspending and resuming operation A data processing system for calling and calling in a C environment Means for creating threads, queuing means for requests, and computer .Means for receiving requests from programs and for placing requests in queue means Means for interrupting the computer program, and means for interrupting the computer program. Means for removing the request from the queuing means, and loading of the function within the thread. And hands for execution Including steps and means for resuming the computer program upon completion of the function A system is also provided.BRIEF DESCRIPTION OF THE FIGURES   Embodiments of the present invention will be described with reference to the accompanying drawings shown as examples.   FIG. 1 is a block diagram of the interface of the present invention.   FIG. 2 is a flowchart of an initial setting operation of the interface shown in FIG.   FIG. 3 is a flowchart of a request processing operation of the interface of FIG.Detailed description of the invention   A program written in the C language is usually used for multiple programs. Commonly used in a program or a piece of programming written for The programming fragment is the source of the program (human (Readable) Structured so that it is not completely listed in the code. Such a blog The ramming fragments are called functions, and where they appear in the source code, There is only a name reference. Functions should be listed completely later in the program Or you can list them completely in the library. Later, when compiling the program or linking the program. Illuminated. Squirrel of functions Must be called from a complete program, not a standalone program. It is necessary. DCE function   Example 1 includes a DCE function sec_login_ that is desired to be called from the MVS environment. Show setup_identity (). If you are familiar with using C functions, Use of functions and input / output parameters, rather than the actual programming code You will notice that the syntax is shown. The purpose of this function is to This is to set the work identification. This function checks the authenticated network operation. Create all of the local environments needed to run. But topical operating No system environment is established at all, and therefore it is not It is expected that such an environment will be established. The network set by this operation Network identity is determined by another DCE function, sec_login_validate_identity (). Not usable until verified. Information about this and other DCE functions Is "OSF DCE Appllcation Development Reference", 1993, Prentice It is described in Hall. The input parameters for this function are as follows:   principal Prince on the registry account corresponding to the calling process Pointer to a string containing the ipal name.   flags on how to use the new network credentials A set of flags containing information. The output parameters of this function are as follows:   login_context Points to an opaque handle to login context data. Pointer.   status Pointer to completion status.   The interface of the present invention is used to set the environment expected by the DCE function, It is also used for passing necessary input / output parameters. Interface overview   This interface is described as a bridge between non-DCE and DCE environments. I can tell. A code that runs in a non-DCE environment (Thrower code) create. User of this interface (application program, etc.) ) Indicates the "Thrower code" and the corresponding "Catcher code" that runs in the DCE environment. Provide both. This interface converts Thrower code to Catcher code Provides a mechanism for passing control to the Catcher code and returning control to the Thrower code I do. With this interface, all types and content parameters can be You can now pass between Thrower code and Catcher code, and drive in C environment. It is guaranteed that the Catcher code expecting to run in the C environment.   The "Thrower code" supplied by the user side is the special Described for certain non-DCE environments. The functions required for this user-side description code are: It is as follows. 1. Loading the Bootstrap module and loading it Branch 2. Provide SUSPEND and RESUME functions 3. Creating Request Control Block and Interface Module Branch to code   The "Catcher" code supplied by the user side is the "Catcher" code that the non-DCE environment tries to use. C "function group, and Has a header to provide tri points. This code is "fetchable Compiled with the "(extractable)" compiler option. If the function execution is required, then the MVS operating system System can load the function into memory, the size of the module, its entry -It means that information such as the location of points can be found at the time of execution. But M The VS lacks the C environment so calling the stub module directly Can not. Interface components   The interface of the present invention consists of a number of software parts, The parts of are used for the interface initialization listed in Table 1. And those used for request processing listed in Table 2. These A portion of the seat is shown in FIG. Interface initial settings   Referring now to the flowchart of FIG. 2, the operation of the embodiment of the interface will be described. The description starts with the initial setting of the interface.   In step 301, the Thrower code 220 is executed by the Bootstrap module (see FIG. 1). (Not shown) into memory and branch to this module. Step 302 So, the Bootstrap module reads the Parameter List Thus, the operation of the Bootstrap module is customized. The Parameter List contains Parameters to customize the interface Data is included. Table 3 shows parameters included in a normal Parameter List.   The number of DCE threads 204 that process the received request is determined by the parameters in the Parameter List. Parameters. The maximum size of a request that this interface will process at one time. The maximum size of the request queue 206 is also included in the Parameter List.   To tailor or customize this interface for different requirements The library containing the main Interface module 202 to be loaded is It is included in arameter List. This adjustment will be described later.   Stub module 210 executed in DCE environment from there Libraries that can be loaded must be included in the Parameter List. Again, use this to adjust or customize this interface. Can be. Frequently used Stub modules 210 include disk storage devices Preloaded as part of the initialization process so that it can be used without access to the Can be The name of such a Stub module 210 is included in the Parameter List. included.   Referring to the flowchart of FIG. 2, at step 303, the Bootstrap module The interface module 202 is loaded. In step 304, Bootstrap The module creates the DCE thread 204 to create the main Interface The control is passed to the ace module 202. In step 305, the thrower code 220 , The address of the SUSPEND exit used for "waiting" in the Thrower code 220 and the Thro Enter the address of the RESUME exit used for "restart" of the To the module 202. In step 306, the Interface module 202 , An entry that can be called with the request from the Thrower code 220 as an argument • Return the point to the Thrower code 220.   In a variant of the interface embodiment, asynchronous initialization is used. This place In this case, control is returned to the Thrower code 220 before the initialization is completed. to this Thus, the Thrower code 220 waits for the DCE environment to be fully established. No longer need to be detained.   Different parameters to restart system or change interface characteristics The interface is restarted either because a restart using the List was requested The Bootstrap module will not work for further purposes unless it is run . Request processing   Referring now to the flowchart of FIG. 3, the processing of a request by this interface will be described. explain. In step 401, the thrower code 220 creates a request control block. create. Request Control Block is used to pass requests to the interface Is done. Table 4 shows the contents of a normal Request Control Block.   In step 402, the Thrower code 220 converts the stub function Request Control Block containing information about Using the pointer to point as an argument, the entry point of the Interface module 202 Call. In step 403, the Interface module 202 Put it in O's request queue 206. In step 404, the interface module 20 2 notifies available DCE threads 204 to process the request. At step 405, the Interface module 202 calls the SUSPEND exit. This The address of the SUSPEND exit is supplied by the Thrower code in step 305 ing.   In step 406, the notified DCE thread 204 waits for a FIFO request. Remove the request from the queue 206. At step 407, the DCE thread 204 Request using the pointer supplied by the Thrower code in step 402  Address the Control Block. In step 408, the DCE thread 20 4. From the Request Control Block, the IDs of the stub functions 211 and 212 and the IDs The name of the included Stub module 210 is determined. In step 409, the Stub module If the file 210 is not already loaded, it is loaded and its entry Record points. If the Stub module 210 is already loaded, Proceed to step 411.   A Stub module including one or more stub functions 211, 212 written in C Rule 210 is an entry point that can be called with a function number as an argument. And this entry point is the direct entry point of the requested function To the caller. Stub module has fetchable option , Which means that if the execution of a function is required, The MVS operating system can load the function into memory That information such as file size and entry point location can be found at runtime. means. However, MVS lacks C environment, so Stub module is directly Cannot call. An example of such a stub module 210 is shown in Example 2. .   The code contains the required function number as an argument and the first entry point ( EUVQLKUP). This code is the entry point for the specified function number. Null if not found, entry for that function otherwise ・ End with the point as the return value.   Each of the stub functions 211 and 212 included in the Stub module 210 includes: There are other entry points. In the example, these are called "stub_functionl Entry point "and" stub_function2 entry point ".   In step 411, the DCE thread 204 determines whether the stub functions 211 and 212 Call the entry point of the Stub module with D as an argument. Step 41 At 2, the Stub module 210 returns from the call of step 411 and returns The entry points of the stub functions 211 and 212 To return.   In step 413, the same as when the DCE thread 204 calls a normal C function. Call stub functions 211 and 212 in the same form and pass Pass a single parameter consisting of the resulting 4-byte value. In step 414, the stub Functions 211 and 212 run in the DCE thread 204 having a "C" environment; Through the 4-byte value passed from the Thrower code 220, the Parameter Li Access st. Stay In step 415, the stub functions 211 and 212 call the necessary DCE functions and In step 416, place the result in the appropriate return parameter, and in step 413, The process returns to the called DCE thread 204.   In step 417, the DCE thread 204 executes the initialization in step 305 of the initialization. Call the RESUME exit passed the dress. In step 418, the RESUME exit By awakening the Thrower task using the VS POST macro, the DC The completion of the E request is indicated to the waiting Thrower task. In step 419, the new The awakened Thrower code 220 puts the DCE thread 204 to sleep, and Int It waits for another request from the erface module 202 for request processing. Step 42 At 0, the thrower code returns from the SUSPEND exit entered at step 405. , And passes control to the Interface module 202. At step 421, the The module 202 indicates that the request has been completed and the call initiated in step 402 Return from the jump.   The ability to adjust this interface during initialization will now be described. Adjusting the interface   Code running in a non-DCE environment will shut down this interface and initialize It can be restarted by calling the code. If you do this , Different Parameter By specifying a List, you can load different versions of the interface it can. Table 3 shows an example of the contents of the Parameter List. This shutdown and restart For example, while keeping the Thrower task (application program) running Introduced an updated version of the interface, thus Desirable when maximizing availability. Cancel request   As described above, the Thrower code 220 indicates that the Interface module 202 Provide addresses (SUSPEND and RESUME) for suspending and resuming rower code 220. Pay. A request is received by the Interface module 202 and the request queue Placed in column 206 and waiting for processing by DCE thread 204 If this is the case, the SUSPEND exit is called and the consumer continues to use the thrower until the request is completed. Perform all necessary actions to wait for code 220. When the request was queued Until the DCE thread 204 indicates that the request has been completed. The Stub module 210 ("Catcher" code) running under the 04 Can access any of the parameter storage provided by the code 220 Has the property.   Since there is a need for system consistency, the parameters belonging to the Thrower code 220 Storage is accessed by all of the “Catcher” code in the Stub module 210. Not to try Until it becomes clear, it cannot be released or reallocated. From this, Terminate the Thrower code 220 while the Thrower code 220 is waiting for the completion of the request. The problem arises when you need to free up that storage. In addition, DCE Since canceling a request in the environment is an asynchronous event, Sophisticated synchronization even when issuing DCE cancellations for running requests Without the logic, the Thrower code 220 does not know whether the request has been completed. Should be.   To overcome this problem, a Stub module running under the DCE thread 204 If the "Catcher" code in rule 210 may still be running Also has a protocol and a set of functions that allow the removal of the Thrower code 220 used. In addition to this protocol, inherent in this solution is Inte The rface module 202 provides a "remove window" lock function. This The "Catcher" code of the Stub module 210 is replaced by the previous DCE request A means is provided to indicate whether a request to revoke a request can be accepted . Removal protocol   To conform to this protocol, the Thrower code 220 must be in the SUSPEND exit. Interface module 2 before releasing the parameter storage. Get "agreement" from 02 Must be guaranteed (eg, during removal processing). this “Agree” is obtained by issuing a cancellation request to the Interface module 202. Can be If the response from the cancellation request is satisfactory, the Thrower code 220 , Removal can proceed. But if the response is not satisfactory, thrower code 220 must not proceed. In this case, the Thrower code 220 is It is preferable to retry the cancellation request after only waiting.   The “Catcher” code in the Stub module 210 must comply with the exclusion protocol. If not, the structure must be as shown in Example 3. . The “Catcher” code for the Stub module 210 appears in the “Uncancel” window. If not, it is considered a candidate for cancellation. "Catcher of Stub module 210 The code must call the setcancel function to set the cancellation off. Trying to enter such a window by specifying that To the Interface module 202. Similarly, "C" of the Stub module 210 The atcher code has completed copying from or to the Thrower storage. You can cancel this by calling the setcancel (ON) function Indicates that   In the preferred embodiment, using the "Compare and Swap" instruction, The change of cancellation status of "Catcher" code of Stub module 210 is changed by Thrower code Synchronization between the "Catcher" code of Stub module 210 and 220 Guarantee. For example, before “setcancel (OFF) is issued, If the request is received and processed, the request is marked as canceled. , Thrower code is allowed to free its parameter storage. Stub module A subsequent call to setcancel (OFF) by the "Catcher" code in This results in the cancellation of the request, and the "Catcher" code in the Stub module 210 Recovery logic to trap Unless you have control, the control is absolutely the "Catcher" code of the Stub module 210 Do not return to.   However, setcancel (OFF) request of “Catcher” code of Stub module 210 If the request to cancel the Thrower code 220 is processed “after” the processing, b The request for the “Catcher” code in module 210 has already been marked as “irrevocable”. And the request to cancel the thrower code 220 fails.

Claims (1)

[Claims] 1. Written in a first programming language and designed to run in a first environment Computer program functions written in a second programming language, Not executable in the first environment, providing the request and suspending and resuming its operation. Can be called as said request from a powerful computer program Is a way to   Creating a thread that runs in the first environment;   Providing a queue for the request;   Receiving the request from the computer program;   Placing the request in the queue;   Removing the request from the queue by the thread;   Loading and executing a function within the thread;   A method that includes 2. further,   Suspending the computer program after the queuing step Steps   After the performing step, upon completion of the function, the computer program Steps to resume   The method of claim 1, comprising: 3. The first programming language is a C programming language Wherein the first environment is a C programming environment. A method according to any one of the preceding claims. 4. A plurality of functions are provided in a module, and the step of loading the functions comprises: Loading a module including the plurality of functions. A method according to any one of the preceding claims. 5. Further, after loading the module including the plurality of functions and before executing the functions. Obtains the address of the requested function from the module including the plurality of functions. And wherein the step of executing comprises retrieving the obtained address. The method according to claim 4, characterized in that: 6. A plurality of threads are created, wherein the plurality of threads are from a single queue. A method according to any of the preceding claims, wherein the request is eliminated and a common function is shared. A method according to claim 1. 7. Creating the thread comprises loading a required function The method according to any of the preceding claims, characterized in that it also comprises: 8. 2. The method according to claim 1, wherein the function is a DCE function. The method described in the section. 9. The computer program runs in an MVS environment A method according to any one of the preceding claims. 10. Providing the request includes providing a pointer to request data. Claims according to any one of the preceding claims. the method of. 11. Before executing the function in the thread,   Said computer to set an indication that the function must not be canceled A table that the function must not be canceled if requested by the program Setting the indication;   The necessary parameters supplied by the computer program, From the storage allocated to the computer program, Copying to storage;   The computer should clear the indication that the function must not be cancelled. Must not cancel the function if requested by the data program Steps to clear the display of things   And before completion of the function in the thread,   The computer to set an indication that the function must not be canceled Must not cancel the function if requested by the data program Setting an indication of that;   The returned parameters supplied by the function were allocated to the function Copy from storage to storage allocated to the computer program Steps and   The computer should clear the indication that the function must not be cancelled. Place requested by the data program Clearing the indication that the function must not be canceled,   The method of any one of the preceding claims, comprising: 12. Written in a first programming language and designed to run in a first environment Computer program functions written in a second programming language, Not executable in the first environment, serving the request, suspending and resuming its own operation Can be called as the request from a computer program having A data processing system for   Means for creating a thread that runs in a C environment;   Queuing means for the request;   Means for receiving a request from the computer program;   Means for placing a request in said queuing means;   Means for removing said request from said queuing means by said thread; ,   Means for loading and executing functions within the thread;   Including system. 13. further,   Means for interrupting the computer program;   Means for resuming the computer program upon completion of the function;   13. The system of claim 12, comprising: 14． The first programming language is a C programming language; 13. The method of claim 12, wherein the environment is a C programming environment. Item 14. The system according to Item 13. 15. A plurality of threads are created, said plurality of threads being a single queue means 13. The method according to claim 12, wherein a request from the common function is removed and a common function is shared. The system according to claim 14. 16. The function is a DCE function, and the computer program is an MV The vehicle according to any one of claims 12 to 15, wherein the vehicle travels in an S environment. The system according to paragraph.