Separating work unit priority and accountability from address spaces

Abstract

Work units are identified, managed and reported on as a group or enclave. The dispatching priorities of the work units are separated from the address spaces executing the work units. Instead, the dispatching priorities are tied to the priority of the enclave allowing work units to be executed within an address space at a priority independent from the address space. Additionally, resources used by the work units are accumulated and allocated to the requestor of the work.

Claims

What is claimed is:

1. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting, a shared storage in the data processing system being addressed through one or more virtual storage address spaces assignable to any requestor, each virtual address space containing a set of contiguous numerical addresses which may be the same in different virtual address spaces, each virtual address space having a unique address space identifier and an associated address translation table, the virtual addresses in each virtual address space being dynamically translatable to real address locations in shared storage by processor hardware/software using the address translation table, each of said virtual address spaces having an assigned address space priority, and program work units being located in the one or more of said virtual address spaces of any user, said method comprising

executing by the data processing system program work units for a plurality of requestors,

assigning to each requestor a home virtual address space which need not be the virtual address space containing a program work unit to be executed for the the requestor for which the virtual address spaces have different address space priorities,

generating an enclave control block (the enclave) in system storage to coordinate system accounting for any requestor, assigning an enclave priority to the enclave for use by work units of the requestor independently of the address space priorities of the virtual address spaces containing program work units of the requestor,

referencing each program work unit (work unit) of the requestor on an enclave queue with the requestor's enclave priority to collect the work units of the requestor for execution by the data processing system independent of the address space priorities of the program work units,

scheduling for execution in an execution scheduling queue each work unit in each enclave queue with a scheduling priority equal to the enclave priority of the work unit in the enclave queue after execution is requested for the work unit to support the requestor-based accounting,

scheduling for execution any work unit of the requestor not in the enclave queue by putting the work unit into the execution scheduling queue with a scheduling priority equal to a home address space priority of the virtual address space containing the work unit after execution is requested for the work unit to support the address-space-based accounting, and

initiating execution of a work unit having a highest scheduling priority in the execution scheduling queue when a processor in the system is available to execute the work unit.

2. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

assigning an enclave subpriority to each work unit of the enclave in the enclave queue, and

providing to the execution scheduling queue both the enclave priority and the enclave subpriority for each work unit of the enclave ready for execution for controlling the execution sequence of work units of the requestor associated with the enclave.

3. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

setting a home address space priority in an address space control block (ASCB) associated with each virtual address space to provide a scheduling priority indicator for each work unit contained in the virtual address space, and

using the scheduling priority indicator in the ASCB as the execution priority of the work unit when the work unit is ready for execution and is put in the execution scheduling queue when the work unit is not assigned to an enclave.

4. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 2, said method further comprising:

generating a work unit block (WUB) to represent each of the work units, enabling the WUB to control execution of the work unit by writing a pointer to an entry point in executable code representing the work unit to associate the WUB with the work unit,

associating each work unit with its home address space by writing in each WUB a direct or indirect pointer to the ASCB of the home address space asssociated with the work unit, and also associating each work unit with an enclave when the work unit is assigned to an enclave by writing in the WUB a direct or indirect pointer to the enclave control block of the requestor using the work unit.

5. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 3, said method further comprising:

utilizing the enclave control block to represent an associated enclave queue which may enqueue any number of work units,

chaining into the enclave queue a direct or indirect pointer to each of the work units in the enclave for which execution has been requested by the requestor of the enclave, and

setting in each enclave control block a representation of a next work unit in the associated enclave queue to be scheduled for execution.

6. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 5, said method further comprising:

selecting the work unit having the highest enclave priority currently in the enclave queue as the next work unit of the enclave to be scheduled for execution in the execution scheduling queue.

7. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

changing the execution priority of a work unit in the enclave queue to the priority of the associated enclave when the priority of the enclave is changed by the system.

8. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

changing the execution priority of a work unit in the execution scheduling queue to the priority of the enclave associated with the work unit when the priority of the enclave is changed by the system while the work unit is on the execution scheduling queue.

9. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

inserting each work unit having an enclave priority into the enclave queue with an enclave subpriority determined by the home address space priority of the work unit.

10. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

deleting an enclave from the system when termination conditions occur which have been specified for the enclave by the requestor associated with the enclave.

11. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

disassociating each work unit from the enclave queue after execution of the work unit.

12. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 1, said method further comprising:

providing enclave space in an accounting record in the system associated with each enclave existing in the system,

collecting accounting information occurring during the execution of each work unit of an enclave, and

posting the accounting information for each work unit into the accounting record in the space provided for the enclave associated with the work unit.

13. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 12, said posting step further comprising:

posting in the enclave control block each work unit associated with an enclave at least before the associated enclave is deleted from the system.

14. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 13, said posting step further comprising:

specifying in the posting step system resources used by the work unit for executing the work unit.

15. A method for enabling requestor-based accounting of executions of program work units in a data processing system also supporting address-space-based accounting as defined in claim 13, said posting step further comprising:

deleting an enclave from the data processing system when terminating conditions occur as specified for the enclave by the requestor associated with the enclave.

Description

TECHNICAL FIELD

This invention relates in general to executing work within a data processing system, and in particular, to executing work within an address space of the data processing system at a priority, which is independent from the priority of the address space. Additionally, the invention relates to accumulating resources consumed by the work and providing the total of accumulated resources to the requestor of the work.

BACKGROUND ART

Various data processing systems use virtual addressing in order to increase the addressability of storage. Such systems further include one or more address spaces. Each address space is a consecutive sequence of integer numbers (virtual address), together with the specific transformation parameters which allow each number to be associated with a byte location in storage. One example of a data processing system using address spaces is offered by International Business Machines Corporation and is defined according to the Enterprise Systems Architecture (ESA). The Enterprise systems Architecture is described in detail in Enterprise Systems Architecture/390 Principles of Operation, IBM Publication Number SA22-7201-01 (April 1993), which is hereby incorporated herein by reference in its entirety.

In one example, a system may include various address spaces, such as a primary, secondary and home address space. As is known, many of the attributes of an address space, and in particular, the home address space, are inherited by the work units associated with that address space. In particular, a work unit inherits its addressability (i.e., a work unit can always address its home address space), priority and accounting from its home address space.

The tie between the work unit and the address spaces, especially the home address space, has caused some problems in managing system performance and balancing work load within the data processing system. This is particularly true when server spaces are involved. A server space is an address space which is performing work for a client (i.e., the initiator or requestor of the work). When a server space is performing work for a client, there may be no addressing tie to the original home address space. Therefore, the server space becomes the home address space for the work being performed. As a result, the work executes with the priority of the server space. This has an effect of causing low and high priority work to execute at the same priority, thereby potentially degrading system performance.

Similarly, the tie between a work unit and its home address space has an negative impact on accounting for the resources consumed by the work unit. Since the work unit executes with the server space as its home address space, the server space is charged for the resources consumed instead of the requestor. Thus, charges are not properly allocated to the client.

Therefore, a need exists for a mechanism in which priority and accounting are removed from the address spaces, and in particular, the home address space. Further, a need exists for a mechanism in which priority is directly tied to the work unit, such that the priority of the work unit is independent of the priority of the address space. Yet further, a need exists for a technique to provide the initiator of work with the cost of that work.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method and system for executing work within a data processing system. The data processing system has one or more address spaces, and each of the address spaces has an address space priority. One or more work units are associated with an enclave having an enclave priority. Each of the work units is executed in at least one of the address spaces at a priority, which is based on the enclave priority.

In one embodiment, the enclave priority is independent of the address space priority of any of the address spaces. Therefore, work units executing within an address space may execute at a priority which is different from the priority of the address space.

In a further embodiment, the enclave is created by attaching the enclave to an enclave vector table and providing an indication that the enclave is attached to the enclave vector table.

In still a further embodiment, the enclave is deleted, by, for example, disassociating the work units from the enclave and removing the enclave from the enclave vector table.

In another aspect of the invention, the resources consumed by the work units are accumulated and a total of the accumulated resources is provided to the owner or initiator of the work units.

The separation of priority and accounting from address spaces, in accordance with the present invention, advantageously increases system responsiveness. For example, each work unit may be executed at an appropriate priority level for the particular work unit instead of at the priority of the address space, which may be too low or too high.

Further, the technique of the present invention enhances accounting of resource consumption by accruing resource consumption of the work units to the requestor of the work. This ensures that the proper address space is charged for the work being performed. Yet further, resource consumption of the enclave can be managed collectively by, for example, a system resource manager of the operating system.

Additional benefits are realized by the technique of the present invention. It is possible to monitor the performance of the enclave, and if it is unsatisfactory, the enclave priority may be changed automatically such that each work unit within the enclave is dispatched and executed at the new priority value.

Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 depicts one example of a block diagram of a data processing system incorporating the enclave facility of the present invention;

FIG. 2 depicts one embodiment of the fields associated with an enclave control block, in accordance with the principles of the present invention;

FIG. 3 depicts one embodiment of the fields associated with an enclave vector table, in accordance with the principles of the present invention;

FIG. 4 is one embodiment of the logic associated with a technique for separating priority and accounting of work units from address spaces, in accordance with the principles of the present invention;

FIGS. 5a-5b depict one example of the logic corresponding to creating an enclave, in accordance with the principles of the present invention;

FIG. 6 depicts one example of the logic corresponding to scheduling a work unit, in accordance with the principles of the present invention;

FIG. 7 depicts one example of the logic corresponding to deleting an enclave, in accordance with the principles of the present invention; and

FIG. 8 depicts an overview of one example of the interaction between a transaction manager and an operating system in performing the technique of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

In accordance with the principles of the present invention, mechanisms are provided for separating work prioritization from the address space in which the work executes. As described in detail below, the priority at which a particular work unit executes is derived from a priority value associated with an enclave and not the address space executing the work unit. The priority of the work unit and the enclave is independent from the address space. In other words, the priority of the address space does not matter to the work unit. In another embodiment, accounting mechanisms are provided for tracking the resources used by the work units and reporting these resources to the initiator of the work units. In one example, an initiator is a program or user requesting work. In another example, the initiator is an address space associated with the enclave, e.g., the address space that requested the work or the address space that owns the enclave.

One embodiment of a data processing system incorporating the mechanisms of the present invention is depicted in FIG. 1. Data processing system 10 is defined following, for example, the Enterprise Systems Architecture/390 (ESA/390) offered by International Business Machines Corporation. One embodiment of ESA/390 is described in detail in Enterprise Systems Architecture/390 Principles of Operation, Publication Number SA22-7201-01 (IBM Corporation, April 1993), which is hereby incorporated by reference in its entirety.

In one example, data processing system 10 includes, for instance, at least one central processing unit 12, a storage 14 and one or more input/output (I/O) devices 16. Each of these components is described in detail below.

As is known, central processing unit (CPU) 12 (or central processing units, if there are more than one) is the controlling center of the data processing system. In one example, central processing unit 12 executes an operating system 18, such as International Business Machines' Multiple Virtual Storage (MVS) operating system, for controlling sequencing and execution of instructions, programs, and data, and for providing timing functions and other machine related functions. In addition, in accordance with the principles of the present invention, operating system 18 includes an enclave facility 20, which as described in detail below is used to separate work prioritization and accountability from address spaces.

Central processing unit 12 is coupled to a storage (or memory) 14. Storage 14 is a repository for programs and data loaded into the storage by one or more input devices. Storage 14 is, for instance, directly addressable and provides for high-speed processing of data by central processing unit 12. In one embodiment, storage 14 includes one or more virtual address spaces 22. Typically, an entire virtual address space 22 is not resident within the main memory. Instead, only that portion associated with a program or data being accessed or used by one or more of the central processor units is resident with the main storage.

Storage 14 is also coupled to input/output devices 16. One example of input/output devices 16 includes printers, magnetic tape units, direct access storage devices (DASD), displays, keyboards, communications controllers, teleprocessing devices, and sensor-based equipment.

As described above, an enclave facility is provided, in accordance with the principles of the present invention, to separate work priority and accounting from address spaces. At this time, the enclave facility and, in particular, enclaves and structures associated with the enclaves will be described in detail.

An enclave is a unit or group. In one embodiment, an enclave represents one or more work units and enables the work units to be managed and reported on as a single group. The enclave has a number of characteristics associated therewith, including, for instance, an enclave priority, performance objectives, accounting and management characteristics. The characteristics of the enclave are used in defining attributes for each work unit. For example, in accordance with the principles of the present invention, the priority at which a particular work unit is dispatched and executed is based upon the priority of the enclave. That is, the enclave priority determines where on a dispatching queue a particular work unit is placed.

One structure associated with an enclave is an enclave control block, which contains a number of fields used in defining the enclave. (An enclave control block contains the storage representing an enclave.) One example of the fields associated with an enclave control block (ENCB) 24 is described below with reference to FIG. 2:

a) EncbEyeCatcher is a 4-byte character field storing an acronym. In one example, the eye catcher is ENCB.

b) EncbVersion is a 1-byte unsigned integer representing the version of the enclave control block.

c) EncbNext is a 4-byte address pointing to the next enclave control block.

d) EncbPrev is a 4-byte address pointing to the previous enclave control block.

e) EncbToken is an 8-byte character field representing an enclave token. In one example, the enclave token includes the following:

1) An EncbEnvt.sub.13 offset, which is a 4-byte unsigned integer offset into an enclave vector table (ENVT), described below, indicating where this enclave block has been registered. The offset when added to the address of the enclave vector table locates an entry in the enclave vector table (ENVTE); and

2) An EncbTokenSeq#, which is a 4-byte unsigned integer sequence number assigned during registration of the enclave block as a unique identifier of this enclave block.

f) EncbPseudoID is a 2-byte unsigned integer including an offset into the enclave vector table (i.e., ENVT slot number). If the id is equal to one, then it is the origin of the array in the enclave vector table. There is a high order bit, which is usually on, and which is ignored when the id is used as an index.

g) EncbDP is a 1-byte unsigned integer representing the dispatching priority of the enclave. In one embodiment, this dispatching priority represents the major priority for each work unit.

h) EncbFirstWEBAddr is a 4-byte address of the first work unit (i.e., work element block).

i) EncbTotalCpuTime is an 8-byte character field representing total accumulated enclave CPU time.

j) EncbEncCreatTime is a 4-byte bitstring indicating the time that the enclave was created.

k) EncbArrivalTime is an 8-byte bitstring representing a timestamp indicating when the work request arrived in the system. In one example, the time is in store clock (STCK) format.

l) EncbOwnerOucbPtr is a 4-byte address indicating the owner address space, which owns the enclave.

m) EncbOwnerPrevEncb is a 4-byte address indicating the previous Encb on a chain of enclaves with the same owner.

n) EncbOwnerNextEncb is a 4-byte address indicating the next Encb on a chain of enclaves with the same owner.

o) EncbSavedCpuTime is an 8-byte character representing a value of the EncbTotalCpuTime when the service request manager (SRM) of the operating system last calculated service.

p) EncbNdp is a 1-byte unsigned integer representing a new dispatch priority at which associated work units are to be run (by, for example, SRM). This may differ from the EncbDP. When SRM wishes to change the priority, the value of EncbNdp is copied into EncbDP.

q) EncbPeriodStartService is a 4-byte string representing the amount of CPU service accumulated when the period started.

One or more of the following controls are used by the operating system and, in one example, the work load manager (WLM) of the operating system, for classification. Some of the fields described below receive their values as a result of performing classification and many of the following fields are directly associated with the respective fields in IWMCLSFY, described below:

r) EncbWLMServiceClassToken is a 4-byte unsigned integer indicating the service class token, which is input to the enclave control block as a result of classification, described below.

s) EncbWLMServiceClassName is an 8-byte character field representing the service class name, which is input to the enclave control block as a result of classification.

t) EncbScte is a 4-byte address representing a pointer to a service class table entry, which is also input to the enclave control block as a result of classification.

u) EncbWlmClsfyConnTkn is a 4-byte bitstring identifying who is performing the classification.

v) EncbWlmClsfyTrxName is an 8-byte character field representing the name of the transaction requesting the work.

w) EncbWlmClsfyUserid is an 8-byte character field representing a userid associated with the work request.

x) EncbWlmClsfyTrxClass is an 8-byte character field indicating a name of a transaction class.

y) EncbWlmClsfySourceLu is a 17-byte character field representing a source logical unit (LU) name associated with the requestor of the work.

z) EncbWlmClsfyNetid is an 8-byte character field identifying the network associated with the requestor.

aa) EncbWlmClsfyLuName is an 8-byte character field representing the local logical unit (LU) name associated with the requestor.

bb) EncbWlmClsfyPlan is an 8-byte character field indicating an access plan name for a set of associated Structured Query Language (SQL) statements. (SQL, offered by International Business Machines, is known in the art.)

cc) EncbWlmClsfyPackage is an 8-byte character field representing a package name for a set of associated SQL statements.

dd) EncbWlmClsfyConnection is an 8-byte character field identifying the name associated with the environment creating the work request.

ee) EncbWlmClsfySourceLuLen is a 4-byte signed integer representing the length of the source LU.

ff) EncbWlmClsfySspmPtr is a 4-byte address pointing to the subsystem parm block.

gg) EncbWlmClsfySspmLen is a 4-byte signed integer representing the length of the subsystem parm block.

hh) EncbWlmClsfyAcctPtr is a 4-byte address pointing to the account info block.

ii) EncbWlmClsfyAcctLen is a 4-byte signed integer representing the length of the account info block.

jj) EncbWlmClsfyCollection is an 18-byte character field representing the name for a group of associated packages.

kk) EncbWlmClsfyCollectionlen is a 4-byte signed integer representing the length of the collection name.

ll) EncbWlmClsfyCorrelation is a 12-byte character field representing the name associated with the user/program creating the work request.

mm) EncbWlmClsfyCorrelationlen is a 4-byte signed integer representing the length of the correlation name.

nn) EncbWlmSubsysName is a 4-byte character field representing the subsystem name of the requestor.

oo) EncbWlmFunctionName is an 8-byte character field representing the function name.

In a manner described herein, the enclave control block is attached to an enclave vector table 26, which is described below with reference to FIG. 3. The enclave vector table includes a header and an array. Initially, the header is described. The header includes, for example, the following:

a) EnvtEyeCatcher is a 4-byte character field representing an acronym. In one example, the eye catcher is ENVT.

b) EnvtSize is a 4-byte signed integer representing the size of the enclave vector table. In one example, it is used for validating an enclave token.

c) EnvtFreeEntryPtr is a 4-byte address indicating the offset (from the ENVT) of the first free entry or 0 if all entries are in use.

The EnvtFreeEntryPtr includes, for example, a high order bit (EnvtFreePtrHighBit), which is turned off when EnvtFreeEntryPtr is copied into an Encb.

d) EnvtNextAvailSeqNum is a 4-byte unsigned integer indicating the next available sequence number in the enclave vector table. Every enclave block will have a unique sequence number. Zero is never valid.

e) EnvtEntriesInUse is a 2-byte unsigned integer representing the current number of allocated enclaves.

f) EnvtEncbSize is a 2-byte unsigned integer indicating the size of the enclave control block in bytes. This control is used by WLM to obtain ENCB storage.

The following controls are associated with the array of the enclave vector table:

g) Envte.sub.-- Next.sub.-- Free.sub.-- Ptr is a 4-byte address indicating the next available free entry in the enclave vector table. If this is the last free entry, then the value of Envte.sub.-- Next.sub.-- Free.sub.-- Ptr is zero. If the high order bit is on, then this entry in the array is available for use.

h) Envte EncbPtr is a 4-byte address pointing to the enclave control block.

Using the structures described above, processing associated with the enclave facility of the present invention will be described in detail. One example of a technique for separating the priority and accounting of work units from address spaces, in accordance with the principles of the present invention, is depicted in FIG. 4 and described in detail below.

Initially, a work request is received by a transaction manager from, for example, a user or a program, STEP 50 "RECEIVE WORK REQUEST." (One example of a transaction manager is DB2 offered by International Business Machines Corporation.) The work request is, for example, a business transaction which includes one or more work units to be processed. When the transaction manager receives the work request, it initiates creation of an enclave by for example, invoking a service referred to as IWMECREA, STEP 52 "CREATE ENCLAVE." As described in detail below, during creation of the enclave, an operating system, such as MVS, allocates storage for an enclave control block, classifies the work request via, for instance, a service referred to as IWMCLSFY, sets the enclave priority and attaches the enclave control block to the enclave vector table.

Subsequent to creating the enclave, one of the work units of the work request is scheduled, STEP 54 "SCHEDULE WORK UNIT." As described in detail below, in one example, the transaction manager commences scheduling of a work unit by invoking a service referred to as IEAMSCHD. During scheduling, the operating system queues the work unit to the enclave and to a dispatching queue. Thereafter, the work unit is dispatched, STEP 56 and executed by the operating system, STEP 58.

During execution of the work unit and/or after execution of the work unit completes, an accounting is performed by the operating system to track the resources used by the work unit, STEP 60 "ACCOUNTING." In accordance with the principles of the present invention, resources used by the work unit accrue to the initiator of the work (i.e., e.g., the owner of the enclave or the requestor of the work), instead of the address space executing the work unit.

Subsequently, a determination is made as to whether there are any more work units, INQUIRY 62. If there are more work units, then processing continues with scheduling the next work unit, STEP 54. It should be noted that more than one work unit may be scheduled, dispatched, and/or executed at a time. The above-described processing flow is only one example.

When there are no more work units to be processed, the enclave may be deleted, STEP 64 "DELETE ENCLAVE." In one example, deletion of the enclave is initiated via the transaction manager by invoking a service referred to as IWMEDELE. This service is described in detail below. Thereafter, processing is complete, STEP 66 "END."

The above-described technique is explained using a transaction manager (e.g., DB2) and an operating system (e.g., MVS). This is only one example. It will be apparent to those skilled in the relevant art that the technique may be performed between other systems, other transaction managers, and/or other operating systems without departing from the spirit of the invention.

Each of the above-mentioned services will now be described in detail. As previously discussed, in order to create an enclave, a service referred to as IWMECREA is used. However, in one example, prior to invoking IWMECREA, IWMCLSFY is invoked in order to initialize certain classification parameters used by IWMECREA. This particular invocation (i.e., IWMCLSFY in a modified form) allows the parameters to be accumulated in a parameter area without calling the classify service routine. One example of the syntax associated with the IWMCLSFY service is described below. (In this embodiment, some of the fields are listed as required and others are listed as optional. This is only one example and it may be different for other embodiments):

    ______________________________________
    ?IWMCLSFY   ›TRXNAME({xtrxname.vertline.NO.sub.-- TRXNAME})!
                ›USERID({xuserid.vertline.NO.sub.-- USERID})!
                ›TRXCLASS({xtrxclass.vertline.
                 NO.sub.-- TRXCLASS})!
                ›ACCTINFO({xacctinfo.vertline.
                 NO.sub.-- ACCTINFO})
                  ACCTINFL(xacctinfl)!
                ›SOURCELU({xsourcelu.vertline.
                 NO.sub.-- SOURCELU})!
                ›NETID({xnetid.vertline.NO.sub.-- NETID})!
                ›LUNAME({xluname.vertline.NO.sub.-- LUNAME})!
                ›SUBSYSPM({xsubsyspm.vertline.
                 NO.sub.-- SUBSYSPM})
                  SSPMLEN(xsspmlen)!
                ›COLLECTION({xcollection.vertline.
                 NO.sub.-- COLLECTION})
                  COLLECTION.sub.-- LEN(xcollection.sub.--
                   len)!
                ›PLAN({xplan.vertline.NO.sub.-- PLAN})!
                ›PACKAGE({xpackage.vertline.NO.sub.-- PACKAGE})!
                ›CONNECTION({xconnection.vertline.
                 NO.sub.-- CONNECTION})!
                ›CORRELATION({xcorrelation.vertline.
                 NO.sub.-- CORRELATION})
                  CORR.sub.-- LEN(xcorr.sub.-- len)!
                 CONNTKN(xconntkn)
                 SERVCLS(xservcls)
                ›SRVCLSNM(xsrvclsnm)
                ›RPTCLSNM(xrptclsnm)!
                ›RETCODE(xretcode)!
                ›RSNCODE(xrsncode)!
    ______________________________________

    ______________________________________
    ?IWMECREA     CLSFY(xclsfy)
                  ARRIVALTIME(xarrivaltime)
                  FUNCTION.sub.-- NAME(xfunction.sub.-- name)
                  ETOKEN(xetoken)
                 ›RETCODE(xretcode)!
                 ›RSNCODE(xrsncode)!
    ______________________________________

    ______________________________________
    ?IEAMSCHD       EPADDR(xepaddr)
                     PRIORITY(ENCLAVE)
                        ENCLAVETOKEN
                        (xenclavetoken)
                      MINORPRIORITY
                       ({xminorpriority.vertline.ZERO})
    ______________________________________

    ______________________________________
    ?IWMEDELE          ETOKEN(xetonken)
                      ›RETCODE(xretcode)!
                      ›RSNCODE(xrsncode)!
    ______________________________________

• Inventors
  Greenspan, Steven Jay; Kinder, Stephen Joseph; Mall, Michael Gerard; Pierce, Bernard Roy;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Apr-14-1998
• Current US Classes:
  711/1
  711/203
  718/103
  718/104
• Application #
  768038
• International Classes
  G06F 013/00
• Field of Search
  395/674 395/673 395/401 395/413
• Examiner
  Toplu; Lucien U.
• Agent
  Kinnaman, Jr.; William A., Goldman; Bernard M.
• US Patent References:
  4084228
  4374409
  4633387
  4918595
  4943913
  5060150
  5134696
  5168566
  5202989
  5212793
  5220669
  5257375