EP0799447A1 - Method and system of calling functions from programs running in another environment - Google Patents

Abstract

A method of allowing computer program functions (211, 212) written in a first programming language, designed to execute in a first environment, to be called as requests from a computer program (220), the computer program (220) being written in a second programming language, and being incapable of executing in a first environment is disclosed. The computer program (220) provides requests and has the ability to suspend and resume its operation. The requests are placed on a queue (206), and removed from the queue (206) by a thread (204) running in the first environment. The functions (211, 212) cannot be executed by the computer program (220), since it does not provide the required environment.

Description

Method and System of calling functions from programs running in another environment

Field of the Invention

The present invention relates to distributed computing and in particular to the calling of functions written in the C programming language from computer programs neither written in the C programming language, nor executing in a C environment. More specifically, the invention relates to the use of Distributed Computing Environment (DCE) services from programs running in environments other than DCE, such as a Multiple Virtual Storage (MVS) environment.

Background of the Invention

A recent development in distributed computing is the emergence of Open Software Foundation's (OSF) Distributed Computing Environment (DCE). The aim of DCE is to provide a degree of transparent computing in heterogeneous operating environments. OSF provides portable source code, written in the C language, and specifications to assist portage of the source code. OSF DCE is available or planned for many operating systems, including UNIX, MS-DOS, VMS, CRAY and SAA environments. Common communication protocols, common system management, and common data services are among the features. In particular, OSF DCE is intended to offer commonality and to help integrate the following key components:

o Remote Procedure Call (RPC) that hides the complexities of the distributed environment; o Naming directory, to use information independent of location, system or local naming conventions; o Distributed file system, for transparent use of files at remote locations; o Security, to prevent unauthorised access to distributed resources; o PC integration, to help provide MS-DOS PC's access to DCE services; o System management facilities.

As mentioned above, DCE is written in C and was developed by OSF on the UNIX operating system. MVS (Multiple Virtual Storage) is an operating system which runs on System/370 and System/390 mainframe computers from IBM Corporation. MVS is written in Assembler (Asm) for these machines.

Because most DCE functions are written in the C language, they can be easily called from applications which are themselves written in C. These functions expect to be called from a 'C environment' which has been established by C libraries driven by the existence of a 'main' function within the C program.

Further information on the 'C environment' and on C programming in general can be found in "The C Programming Language: Second Edition" by BW Kernighan & DM Ritchie, 1988 published by Prentice Hall.

The DCE functions assume that the application is running in this 'C environment', with its expected linkage conventions, method of usage of a stack and recovery routines as well as the method of passing arguments or parameters to the functions. The difference in passing of parameters will now be described as an example of the different environment.

A C function expects parameters to be passed to it using "call by value". In call by value, the called function is given the values of its parameters in temporary variables rather than the originals. The called function cannot directly alter the value of a variable in the calling function, it can only alter its private, temporary copy. If it is necessary to alter a variable in the calling function, then the caller must provide the address of the variable to be modified and the called function must declare the parameter to be a pointer and access the variable indirectly through it.

MVS expects to pass arguments to functions using "call by reference". In call by reference, the called routine has access to the original parameter, not a local copy.

Applications which are not written in C, particularly those applications written in 370 Assembler, do not provide the environment that the DCE function expectβ. An example of βuch an application which is written for Syβtem/370 computers is the CICS family of transaction processing software from IBM Corporation. Although the problem has been described above with reference to DCE functions, it exists for any software not written in the C language which wishes to access functions written in the C language.

Previous solutions to the problem of calling functionβ in one environment from another environment have been directed to solving the problem for a particular environment and a particular application. They have not attempted to provide a general purpose solution to the problem of a non-C application invoking functions written in C. These solutions include the non-C calling routine first calling a setup routine to prepare what looks like a C environment for C functions. The C functions are then called and on completion, the non-C calling routine must call a closing routine to collect the results of the C functions and resolve any error conditions and the like. Such a solution has poor performance because of the overhead of setting up the environment and is both complex and error- prone in programming.

So it would be advantageous to provide an interface as a bridge between the two environments (the 'C environment' and the 'non-C environment') to allow DCE services to be accessed from a non-DCE environment without the need for specific code for a particular environment and a particular application.

Previous interfaces between environments have a considerable amount of programming logic in the bootstrap or initialisation module. These initialisation modules are normally allocated resources such as memory by the application which wishes to exploit the functions in another environment (exploiter). These interfaces cannot easily be stopped without stopping the exploiting application. So it is not possible to refresh the interface with different characteristics without stopping the exploiting application. It would be advantageous to provide an interface which could be shutdown and restarted with different characteristics, tailored using a customisation file.

Disclosure of the Invention

Accordingly the invention provides a method of allowing computer program functions written in a first programming language, designed to execute in a first environment, to be called as requests from a computer program, the computer program being written in the second programming language, and being incapable of executing in a first environment, said computer program providing said requests and having the ability to suspend and resume its operation, the method comprising the steps of creating a thread running in said first environment; providing a queue for said requests; receiving requests from the computer program; placing the requests on a queue; removing by means of the thread of said requests from the queue; and loading and executing the function within the thread.

In a preferred embodiment, rather than the application program waiting for the function to complete execution before the application program itself continues with execution, the method further comprises the steps of, after said placing step, suspending the computer program; and after said executing step, on completion of the function, resuming the computer program. The application program can continue processing, whilst waiting for the function to complete execution.

Also in a preferred embodiment, the first programming language is the C programming language and the first environment is the C programming environment.

The method provides for functions to be loaded individually on demand, but in a preferred embodiment a plurality of functions are provided in a module of functions and after loading the module of functions and prior to execution of a function, an address of the requested function is obtained from the module of functions, and the execution step consists of calling the obtained address. Using a module of functions gives the advantage of, for example, grouping functions such as DCE functions relating to security into a single module with resulting improved performance in the loading step. Also, in a preferred embodiment a plurality of threads is provided, the plurality of threads removing requests from a single queue and sharing common functions. Again, performance is improved by the use of multiple threads to improve the throughput of processing of requests.

in a preferred embodiment the functions are DCE functions (written in C) and the computer program (written in Assembler (Asm)) runs in an MVS environment.

The invention also provides a data processing system for allowing computer program functions written in the C programming language to be called as requests from a computer program neither written in the C programming language, nor executing in a C environment, the computer program providing requests and having the ability to suspend and resume its operation, the system comprising: means for creating a thread running in the C environment; a queue means for requests; means for receiving requests from the computer program; means for placing the requests on a queue means; means for suspending the computer program; means for removal by the thread of said requests from the queue means; means for loading and execution of the function within the thread; and on completion of the function, means for resuming the computer program.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a block diagram of the interface of the present invention;

Figure 2 is a flow diagram of the initialisation operations of the interface of figure 1; and

Figure 3 is a flow diagram of the request processing operations of the interface of figure 1.

Detailed Description of the Invention

Programs written in the C language are usually structured so that pieces of programming commonly used within that program or pieces of programming which have been written for use within a number of programs are not listed out in full in the source (human-readable) code of the program at each occurence of the piece of programming. Such pieces of programming are called functions and where they appear in the source code there is just a reference to the name of the function. The functions may be listed in full later in the program, or they may be listed in full in a library, which is referenced later, when the program is compiled, or when it is linked. Listings of functions are not self-contained programs, but need to be called from complete programs.

DCS functionβ Example 1 shows a DCE function, βec_login_βetup_identity(), which it is desired to call from an MVS environment. As those familiar with the use of C functions will be aware, example 1 shows the syntax of use of the functions and the input and output parameters, rather than the actual programming code for the function. The purpose of the function is to set up a user's network identity. The function creates any local environment necessary to perform authenticated network operations. It does not establish any local operating system environment and hence expects such an environment to be established by the calling routine. The network identity set up by this operation cannot be used until it is validated by another DCE function, sec_login_validate_identity( ) . Further information on this and other DCE functions can be found in OSF DCE Application Development Reference, 1993, published by Prentice Hall.

Example 1 A DCE function, sec_login_setup_identity()

Further information on this and other DCE functions can be found in OSF DCE Application Development Reference, 1993, published by Prentice Hall.

♦include <dce/βec login.h>

boolean32 sec_login_setup_iden ity( unsigned_char_p_t principal, sec_login_flags_t flags, sec_login_handle_t 'login context, error_status_t "status) ;

Input parameters for the function are: principal A pointer indicating a character string containing the principal name on a registry account corresponding to the calling process. flags A set of flags that contain information about how the new network credentials are to be used. Output parameters for the function are: login context A pointer to an opaque handle to login context data. status A pointer to the completion status.

The interface of the present invention is used to set up the environment that the DCE function expects and also to pass the necessary input and output parameters.

Interface Overview

The interface can be described as a bridge between non-DCE and DCE environments. The code running in the non-DCE environment (the thrower code) builds the DCE request. The exploiter of the interface (the application program or the like) provides both 'thrower code' and corresponding 'catcher code' which runs in the DCE environment. The interface provides a mechanism for passing control from the thrower code to the catcher code and back again. The interface allows for parameters of any kind and content to be passed between the thrower and catcher code as well as ensuring that the catcher code is running in the C environment which it expects.

The 'thrower code' provided by the exploiter is written for the specific non-DCE environment in which the exploiter code is running, the functions required of this exploiter-written code are:

1. Load and Branch to Bootstrap Module;

2. Provision of a SUSPEND and RESUME function; and

3. Building of a Request Control Block and branching to the Interface Module code.

The 'catcher' code provided by the exploiter is the 'C functions that the non-DCE environment wishes to utilise with a header to provide entry points to those functions. The code is compiled with a "fetchable" compiler option, which means that if and when the function is required to be executed, the MVS operating system can load the function into memory and find out information, such as how large the module is, and what its entry point is, at run-time. However MVS cannot call the stub module directly because of the lack of a C environment.

Interface Components The interface of the present invention consists of a number of software parts, divided into those used for initialising the interface, listed in Table 1, and those used for the processing of requests, listed in Table 2. Some of these partβ are illustrated in Figure 1.

Table 1 Component parts of the Interface used during initialisation

Name of Language Module Name Purpose or Content* Part Written in (or Structure

Name if data)

Bootstrap Assembler EUV SMC Initialisation of the interface Module

Parameter Data EUVQIPL (Customisation file - includes List name of library from which Interface Module 202 is to be loaded)

Table 2 Component parts of the Interface used during request processing

Name of Language Module Name Purpose or Contents Part Written in (or Structure

Name if data)

Interface Assembler EUVQSAM (Can have multiple versions in Module 202 and C different libraries)

Request Data EUVQRPL Request parameter list. Control Contains: Block Name of stub function 211, 212 to be called;

Name of stub module 210 containing this function;

A parameter to be passed to the stub function 211, 212

(typically, this is a 4 byte address of a parameter list for communication between thrower code 220 and catcher code 210).

Stub Module C language Contains one or more stub 210 ("catcher code") functionβ 211, 212 in it (See

Example 2) .

Has an entry point called

EUVQLKUP.

Compiled with fetchable option

(described with reference to

Example 2) .

Thrower Language Simple routines running in the Code 220 other than C non-DCE environment to take requests from the user's application and pass them to the interface. Interface initialisation

Referring now to the flow diagram of figure 2, the operation of an embodiment of the interface will now be described, starting with the initialisation of the interface.

At step 301 the Thrower Code 220 loads into memory and branches to the Bootstrap Module (not βhown in figure 1). At step 302 the Bootstrap Module reads the Parameter List to customise operation of the Bootstrap

Module. The Parameter List contains those parameters which customise the interface. The parameters in a typical Parameter List are shown in Table 3.

Table 3 Contents of a Parameter List

o the number of DCE threads 204 to create o the maximum size of the request queue 206 o the library from which the main Interface Module 202 (EUVQSAM) should be loaded o the library from which any stub module(β) 210 should be loaded o the names of any stub module(s) 210 to preload as part of initialisation

The number of DCE threads 204 which process the received requests is a parameter in the parameter list. The maximum size of the queue 206 of requests that the interface will process at any one time is also in the parameter list.

The library from which the main Interface Module 202 is loaded is included in the list in order to enable the interface to be tailored or customised to different requirements. This tailoring will be described later.

The library where the stub modules 210 which execute in the DCE environment can be loaded from needs to be included in the parameter list. Again this may be used to tailor or customise the interface. Frequently used Stub Modules 210 may be preloaded as part of the initialisation process in order that they are available without access to disk storage or similar. The names of any such Stub Modules 210 are included in the Parameter List.

Again, referring to the flow diagram of figure 2, at step 303 the

Bootstrap Module loads the main Interface Module 202. At step 304, the Bootstrap Module passes control to the main Interface Module 202 by creating a DCE thread 204. At step 305 the Thrower Code 220 supplies the Interface Module 202 with the address of a SUSPEND exit, used to 'wait* the Thrower Code 220, and a RESUME exit, used to 'resume' the Thrower Code 220. At step 306 the Interface Module 202 returns to the Thrower Code 220 an entry point at which it can be called with requests from the Thrower Code 220.

In a variation of the embodiment of the interface, asynchronous initialisation is used. Control is returned to the Thrower Code 220 before the initialisation is complete. This avoids the need to have the Thrower Code 220 tied up for extended periods waiting for the DCE environment to be fully established.

The Bootstrap Module serves no further purpose, unless the interface is restarted, either due to a system restart or because a restart has been requested with a different Parameter List so as to change the interface characteristics.

Processing of requests

Referring now to the flow diagram of figure 3, the processing of requests by the interface will now be described. At step 401 the Thrower Code 220 builds a Request Control Block. A Request Control Block is used to pass requests to the interface. Table 4 shows the contents of a typical Request Control Block. Table 4 Contents of a Request Control Block

o the name of the Stub Function 211, 212 to be invoked o the name of the Stub Module 210 containing this Stub Function 211, 212 o a 4 byte parameter to be passed to the Stub Function 211, 212 (typically the address of a parameter list)

At step 402 the Interface Module 202 entry point is called by the

Thrower Code 220 with a pointer to a Request Control Block containing information about the Stub Function which it is desired to execute. At step 403 the Interface Module 202 places the request on a FIFO request queue 206. At Step 404 the Interface Module 202 posts an available DCE Thread 204 to process the request. At step 405 the Interface Module 202 calls a SUSPEND exit, the address of which was provided at step 305 by the Thrower Code.

At step 406 the posted DCE Thread 204 removes the request from the FIFO request queue 206. At step 407 the DCE Thread 204 addresses the

Request Control Block using the pointer provided by the Thrower Code at step 402. At step 408 the DCE Thread 204 determines from the Request Control Block the Stub Function 211, 212 ID and the name of the Stub Module 210 containing it. At step 409 if the Stub Module 210 is not already loaded, then it is loaded and its Entry Point recorded. If it is already loaded then execution proceeds to step 410.

A Stub Module 210 containing one or more of the stub functions 211, 212, written in C, has an entry point which can be called with a function no. and will return to the caller the direct entry point to the required function. The stub module is compiled with the fetchable option, which means that if and when the function is required to be executed, the MVS operating system can load the function into memory and find out information, such as how large the module is, and what its entry point iβ, at run-time. However MVS cannot call the stub module directly because of the lack of a C environment. An example of such a stub module 210 is shown in Example 2.

The code is entered at the first entry point (EUVQLKUP) with a parameter of the function number required. The code exits with either a null indication if no entry point can be found for the function number specified or with the entry point for that function.

There are further entry points for each of the stub functions 211,

212 contained within the stub module 210. These are βhown in the example as 'entry point for βtub_function 1' and 'entry point for stub_function 2' .

Example 2 A typical Stub Module

♦pragma linkage(EUVQLKUP, FETCHABLE) options(RENT,OPTIMIZE(0) ) #include <βtdlib.h>

extern void *stub_functionl(); extern void *stub_function2() ;

/* this is the EUVQLKUP entry point */ void *( *EUVQLKUP( const char *function_ID ) )()

{ if ( strncmp( "function_l ", function_ID, 16 ) == 0 ) return fetchep(stub_function_l) ; if ( strncmp( "function_2 ", function_ID, 16 ) == 0 ) return fetchep(stub_function_2);

return NULL; }

/* entry point for βtub_functionl */ /* This is shown as 211 in Figure 2 */ int stub_functionl(4_byte_parameter) void *4_byte_parameter;

{

/* code for function 1 is contained here */

}

/* entry point for stub_function2 */ /* This is shown as 212 in Figure 2 */ int stub_function2(4_byte_parameter) void *4_byte_parameter; {

/* code for function 2 is contained here */

} At step 411 DCE thread 204 calls the Stub Module Entry Point with the ID of the Stub Function 211, 212. At step 412 the Stub Module 210 returns from the call at step 411 with the Entry Point of the Stub Function 211, 212 requested to the DCE thread 204.

At step 413 the DCE thread 204 calls the Stub Function 211, 212 in the same way that a normal C function would be invoked, pasβing a single parameter consisting of the 4 byte value passed by the thrower code 220. At step 414 the Stub Function 211, 212 runs in the DCE thread 204 which has the "C" environment and access, via the 4 byte value passed from the Thrower Code 220, to the throwers' parameter list. At step 415 the Stub Function 211, 212 calls the necessary DCE functions, and at step 416 places any results in the appropriate return parameters and returns back to the DCE thread 204 from which it was called at step 413.

At step 417 the DCE thread 204 then calls the RESUME exit whose address was passed to it in step 305 of the initialisation. At step 418 the RESUME exit indicates to the waiting thrower task that the DCE request has completed by using an MVS POST macro to wake the thrower task. At step 419 the newly woken Thrower Code 220 causes the DCE thread 204 to sleep and wait for another request from the Interface Module 202 to proceβs a request. At step 420 the Thrower Code returns from the SUSPEND exit entered at step 405 and passes control to the Interface Module 202 which at step 421 signals that the request has been completed and returns from the call which started at step 402.

The ability of the interface to be tailored during the initialisation process will now be described.

Tailoring of the interface

The code running in the non-DCE environment can shutdown and restart the interface by calling the initialisation code. If this is done, specifying a different Parameter List, then this allows a different version of the interface to be loaded. Table 3 shows an example of the contents of a Parameter List. This shutdown and restart may be desired when, for example, the thrower task (application program) is to be kept running, while an updated version of the interface is to be installed, thus maximising availability of the thrower task. Request Cancellation

As mentioned above, the Thrower Code 220 provides addresses for the Interface Module 202 to SUSPEND and RESUME it. Once a request has been received by the Interface Module 202 and placed on the queue 206 awaiting processing by a thread 204, the SUSPEND exit is called and the exploiter takes whatever action is necessary to wait the Thrower Code 220 until suc time as the request has been completed. From the time the request is queued, until the thread 204 indicates that the request has completed, th stub module 210 ('catcher' code) running under the thread 204 has the potential to access any of the parameter storage provided by the Thrower Code 220.

Because of the need for system integrity, the parameter storage belonging to the Thrower Code 220 cannot be freed/reallocated until it is clear that any 'catcher' code 210 will no longer try and access it. This presents a problem if the Thrower Code 220 needs to be terminated and its storage freed whilst it is waiting for the request to complete. In addition, since cancelling requests in the DCE environment is an asynchronous event, even if the Thrower Code 220 were to issue a DCE cancel for the request still running, without sophisticated synchronisation logic, it would still be unaware of whether or not the request had terminated.

To overcome this problem, a protocol and a series of functions are used which allow the Thrower Code 220 to be purged even though the 'catcher' code 210 running under the DCE thread 204 may still be running. In addition to the protocol, an essential ingredient of the solution is the provision by the Interface Module 202 of a 'purge window' locking function. This function provides a means by which the 'catcher' code 210 can indicate that it can or cannot accept requests to cancel previous DCE requests.

Purge protocol

To conform to the protocol, the Thrower Code 220 must ensure that, if it is within the SUSPEND exit, it must first obtain 'agreement' from the Interface Module 202 before it frees any parameter storage (for example, during the processing of a purge). This 'agreement' is obtained by issuing a cancel request to the Interface Module 202. If the response from the cancel request is satisfactory, then the Thrower Code 220 can proceed with the purge. However, if the response is not satisfactory then the Thrower Code 220 must not proceed. In this event, the Thrower Code 220 preferably waits for a period of time then retries the cancel request.

The 'catcher' code 210 must be structured as shown in Example 3 if it is to conform to the purge protocols. The 'catcher' code 210 is considered to be a candidate for cancellation unless it is within a 'non- cancel' window. The 'catcher code' 210 signals to the Interface Module 202 that it is about to enter such a window by calling the setcancel function specifying that cancellation is to be set OFF. Similarly, once the 'catcher code' 210 has completed the copying from/into the 'thrower' storage, it indicates that it may now be cancelled by calling the setcancel(ON) function.

Example 3

*- *

/* entry point for stub_functionl */ int stub_functionl(4_byte_parameter) void *4_byte_parameter; {

/* 'catcher' code about to reference 'throwers' storage */ /* by copying parameters into DCE thread storage */

setcancel(OFF) /* indicate that CANCEL not allowed */

/* copy required parameters from 'throwers' storage */

setcancel(ON) /* indicate that CANCEL is allowed */

/* issue any DCE function calls but ensuring that only parameters in 'catcher' storage will be referenced */

/* 'catcher' code about to reference 'throwers' storage */ /* by copying returned parameters back to 'throwers' */ /* βtorage */

setcancel(OFF) ; /* indicate that CANCEL not allowed */

/* copy returned parameters into 'throwers' storage */

setcancel(ON) ; /* indicate that CANCEL is allowed */

return(OK) /* return to caller */ In a preferred embodiment, a 'Compare and Swap' instruction is used to ensure that changing the cancellation status of the 'catcher' code 210 is synchronised between the thrower Code 220 and the 'catcher' code 210. For example, if a cancel request is received and processed by the interface BEFORE the setcancel(OFF) was issued, the request will be marked as cancelled and the Thrower Code will be permitted to free its parameter storage. A subsequent call to setcancel(OFF) by the 'catcher' code 210 will result in the request being cancelled, and unless the 'catcher' code 210 has recovery logic to trap this event, control will never return to the 'catcher' code 210.

However, if the Thrower Code's 202 cancel request was processed AFTER the 'catcher' code 210 setcancel(OFF) request was processed, the 'catcher' code's 210 request will already be marked as 'non-cancellable' and the Thrower Code's 220 cancel request will fail.

Claims

Claims

1. A method of allowing computer program functions (211,212) written in a first programming language, designed to execute in a first environment, to be called as requests from a computer program (220), the computer program being written in a second programming language, and being incapable of executing in a first environment, said computer program providing said requests and having the ability to suspend and resume its operation, the method comprising the steps of:

creating (304) a thread (204) running in said first environment; providing a queue (206) for said requests; receiving (402) requeβts from the computer program (220); placing (403) the requests on a queue (206); removing (406) said requests from the queue (206) by means of the thread (204); and loading (410) and executing (414) the function (211,212) within the thread.

2. A method as claimed in claim 1 further comprising the steps of:

after said placing step, suspending (405) the computer program (220); and after said executing step, on completion of the function (211,212), resuming (417) the computer program (220).

3. A method as claimed in any preceding claim wherein the first programming language is the C programming language and the first environment is the C programming environment.

4. A method as claimed in any preceding claim wherein a plurality of functions (211,212) are provided in a module (210) and the step of loading of the function is a step of loading of the module containing said plurality of functions.

5. A method as claimed in claim 4 further comprising the step of, after loading of the module (210) containing said plurality of functions (211,212) and prior to execution of a function, obtaining (411,412) an address of the requested function from the module containing said plurality of functions; and wherein the execution step consists of calling (413) the obtained address.

6. A method as claimed in any preceding claim wherein a plurality of threads (204) is created, the plurality of threads removing requests from a single queue (206) and sharing common functions (211,212).

7. A method as claimed in any preceding claim wherein the step of creating a thread also comprises a step of loading functions to be requested.

8. A method as claimed in any preceding claim wherein the functions (211,212) are DCE functions.

9. A method as claimed in any preceding claim wherein the computer program (220) runs in an MVS environment.

10. A method as claimed in any preceding claim wherein the provision of requests comprises provision of a pointer to the request data.

11. A method as claimed in any preceding claim further comprising the steps, prior to execution (414) of the function (211,212) within the thread, of:

setting an indication that the function (211,212) should not be cancelled if so requested by the computer program (220); copying required parameters supplied by the computer program (220) from storage allocated to the computer program (220) to storage allocated to the function (211,212); and clearing an indication that the function (211,212) should not be cancelled if so requested by the computer program (220);

and further comprising the steps, prior to completion of the function (211,212) within the thread, of:

setting an indication that the function (211,212) should not be cancelled if so requested by the computer program (220); copying returned parameters supplied by the function (211,212) from storage allocated to the function (211,212) to storage allocated to the computer program (220) ; and clearing an indication that the function (211,212) should not be cancelled if so requested by the computer program (220).

12. A data processing system for allowing computer program functions (211,212) written in a first programming language designed to execute in a firβt environment, to be called as requests from a computer program (220), the computer program being written in a second programming language, and being incapable of executing in a first environment, said computer program (220) providing said requests and having the ability to suspend and resume its operation, the system comprising:

means for creating (304) a thread (204) running in a C environment; a queue means (206) for requests; means for receiving (402) requests from the computer program (220); means for placing (403) the requests on a queue means (206); means for removing (406) said requests from the queue means (206) by the thread (204); and means for loading (410) and execution (414) of the function (211,212) within the thread.

13. A system as claimed in claim 12 further comprising:

means for suspending (405) the computer program (220); means for resuming (417) the computer program (22)) on completion of the function (211, 212).

14. A system as claimed in claim 12 or claim 13 wherein the first programming language is the C programming language and the first environment is the C programming environment.

15. A system as claimed in any one of claims 12 to 14 wherein a plurality of threads (204) is created, the plurality of threads removing requests from a single queue means (206) and sharing common functions (211,212) .

16. A system as claimed in any one of claims 12 to 15 wherein the functions (211,212) are DCE functions and the computer program (220) runs in an MVS environment.