WO2001015054A1

WO2001015054A1 - Computing system and programming environment therefor

Info

Publication number: WO2001015054A1
Application number: PCT/AU2000/001007
Authority: WO
Inventors: Raymond John Huetter
Original assignee: Bullant Technology Pty Ltd
Priority date: 1999-08-25
Filing date: 2000-08-25
Publication date: 2001-03-01
Also published as: WO2001015054A9

Abstract

A scalable programming environment for a computer system, the environment including one or more constructs, more specifically scalability constructs. Examples of the scalability constructs include a data object structure construct, a garbage collector construct and a resource governor construct.

Description

COMPUTING SYSTEM AND PROGRAMMING ENVIRONMENT THEREFOR

The present invention relates to a computing system and, more particularly, to a system particularly suited, although not exclusively so, to a system which can provide a programming environment for dealing with transactions in a scalable environment.

BACKGROUND

Historically, computer systems have been found not to be easily scalable. That is to say for any selected operating environment it has been found that the amount of work performed per unit time tends to fall away as the total number of tasks requiring concurrent execution increases.

A further problem in current systems is that transactions (that is, those operations requiring to follow the ACID constraints of Atomicity, Consistency, Isolation and Durability) do so only by the use of relatively inefficient and complicated programming, in some cases taking the programmer outside of what is otherwise an object oriented environment.

It is an object of the present invention to address or ameliorate one or more of the abovementioned problems or concerns . BRIEF DESCRIPTION OF INVENTION

In the context of the present specification the term "scalability construct" refers to constructs which have characteristics which enable a given computing environment to more closely attain or approach maximum utilisation of system resources. This term is further discussed and defined in the detailed description of invention and with reference to particularly preferred embodiments.

Accordingly, in one broad form of the invention there is provided a scalable programming environment for a computer system; said environment including one or more constructs.

In a further broad form of the invention there is provided a scalable programming environment for a computer system; said environment including one or more scalability constructs.

Preferably said scalability constructs enable said environment more closely to attain and approach maximum utilisation of system resources.

Preferably said scalability constructs include a system aid; said system aid adding a system aid overhead which consumes system resources.

Preferably said system aid overhead consumes system resources at a rate which is substantially independent of system resource utilisation. Preferably said one of said scalability constructs comprises a data object structure and said system aid overhead comprises that portion of said data object structure which retains and keeps track of historical records. Preferably said one of said scalability constructs comprises a garbage collector and said system aid overhead comprises objects in said system which have the capacity to flag changes to said system so as to aid the action of said garbage collector. Preferably said one of said scalability constructs comprises a resource governor and said system aid overhead comprises the interposition of a task acting as a resource governor between a pool of resources for consumption and resource consumers . In one particular preferred form said one of said scalability constructs is an object structure.

Preferably both data and tasks are implemented as objects .

Preferably tasks comprise either user tasks or system tasks .

Preferably user tasks have a time perspective at which they read the state of objects.

Preferably objects can be designated as persistent objects or transient objects. More preferably persistent objects are referenced via a directed graph of persistent objects which originates at the persistent root

Preferably persistent objects can only be changed in a transaction.

Preferably objects which are persistent can only reference other objects which are persistent.

Preferably objects which are transient can reference both objects which are persistent and objects which are transient.

In a particular preferred form said environment includes in combination, at least a first construct and a second construct .

In a further particular preferred form said environment includes in combination, at least a first scalability construct, a second scalability construct and a third scalability construct.

Preferably said constructs are selected from the set of scalability constructs comprising a data object construct, a resource governor construct and a garbage collector construct .

In a particular preferred form said first scalability construct is a data object construct. In an alternative preferred form said first scalability construct is a resource governor construct .

In yet an alternative preferred form said first scalability construct is a garbage collector construct. In yet a further preferred form said first scalability construct is a data object construct and said second scalability construct is a resource governor construct.

In an alternative preferred form said first scalability construct is a data object construct and said second scalability construct is a garbage collector construct.

In yet an alternative preferred form said first scalability construct is a resource governor construct and said second scalability construct is a garbage collector construct . In yet a further broad form of the invention there is provided a method of implementing transaction processing; said method comprising executing transactions on a computer system in the environment described above incorporating one or more scalability constructs. Preferably said data object construct comprises a method of operating on an object, said object comprising at least a first data record in a system comprising a plurality of said objects; the method including the following steps when at least one field in said at least a first data record is to be changed:

(a) first making a copy of at least those fields of said data record which are to be changed so as to produce a copy record; then in any order:

(b) i. recording in a field of the updated data record the time in said system at which said updated record is created; ii. forming a link between said updated data record and said at least a first data record; iii. making the change to said at least one field of the copy record so as to produce an updated data record. Preferably step (b) is carried out in the order steps (b)i. (b)ii. (b)iii.

Preferably said method operates according to the rule that only the current record of an object can be changed.

In a further preferred form said data object construct comprises a data structure for a computer; said data structure comprising at least one data record; each said data record of said data structure comprising a plurality of fields including:

(a) a time of creation field; (b) a pointer to a record field;

(c) one or more data fields.

Preferably at least one field in said at least one data record includes a pointer to another said object. In an alternative preferred form said data object construct comprises a method of operating on an object; said object comprising at least a first data record in a system comprising a plurality of said objects, the method comprising executing the following steps when at least one field in said at least a first data record is to be changed by a change agent so as to create an updated data record:

(a) first making a copy of said data record so as to produce a copy record; then in any order: (b) i. recording in a field of the updated data record a change number associated with the change agent making the change in said system reflecting the relative time at which said updated record is created. ii. forming a link between said updated data record and said at least a first data record; iii. making the change to said at least one field of the copy record so as to produce an updated data record. Preferably step (b) is carried out in the order sub- steps (b)i. (b)ii. (b)iii.

In yet a further preferred form said data object construct comprises a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at least:

(a) a time of creation field reflecting relative time of creation of said data record; (b) a pointer to a record field which contains information as to the location of another data record within said data structure. In a further particular preferred form said data object construct comprises an object having the structure defined above and wherein fields in said data records include pointers to objects.

In yet a further broad form of the invention there is provided a method of operating a computer; said method invoking at least one change agent; the change agent operating on a data structure in an environment as defined above .

Preferably said change agent is further adapted to operate on records within said objects which have a transition point stored in said time of creation field. Preferably said method of operating a computer operates according to the rule that only the current record of an object can be changed.

Preferably said environment is implemented in software. In an alternative preferred form said environment is implemented in hardware .

In yet an alternative preferred form said environment is implemented in microcode.

In a further preferred form said resource governor construct comprises a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising: (a) instituting a special purpose task as a resource governor; (b) said resource governor distributing said usable resources to said resource consumers; (c) said resource governor receiving from said resource consumers said used resources . Preferably said usable resources include tasks, unused objects, a unit of network bandwidth or a designated unit of an input/output operation.

Preferably each said resource consumer includes an input buffer.

Preferably each said resource consumer device includes an output buffer. Preferably said input buffer is a non- locking buffer. Preferably said output buffer is a non- locking buffer. More preferably said input buffer is a ring buffer. More preferably said output buffer is a ring buffer. In an alternative preferred form said resource governor construct comprises a method of allocation of tasks to execution devices in a computer system; said computer system of the type having a plurality of tasks for execution and one or more execution devices capable of executing said tasks whereby a task for execution is input to at least one of said execution devices, is then executed by said at least one execution device and is then output from said at least one execution device as an executed task; said method comprising: (a) instituting a special purpose task as a task allocator;

(b) said task allocator distributing said tasks for execution to said execution devices; (c) said task allocator receiving from said execution devices said executed tasks. Preferably said execution device includes an input buffer.

Preferably each said execution device includes an output buffer.

Preferably said input buffer is a non- locking buffer. Preferably said output buffer is a non-locking buffer. More preferably said input buffer is a ring buffer. More preferably said output buffer is a ring buffer. In a further preferred form said environment includes a resource consumer construct, said resource consumer construct comprising a structure suitable for use in conjunction with a resource governor, said structure comprising a resource consumer having at least one input buffer and from which said resource consumer takes usable resources for use.

Preferably said resource consumer accepts resources for use of a predefined type from said at least one input buffer. Preferably said resource consumer obtains said usable resources for use only from said at least one input buffer. Preferably said at least one input buffer receives resources of only said predefined type.

Preferably said resource consumer experiences no contention for execution of said usable resources for use. In a particular preferred form said structure further includes an output buffer into which said resource consumer places said usable resources following execution by said resource consumer.

Preferably said at least one input buffer is a non- locking buffer.

Preferably said output buffer is a non- locking buffer. More preferably said input buffer is a ring buffer. More preferably said output buffer is a ring buffer. In yet a further broad form said garbage collector construct comprises a method of identification of unused data blocks in a computer system; each data block having a unique reference; said method comprising the steps of:

(a) designating a special purpose task as a cleaner task which identifies unused data blocks; (b) each task adapted to indicate to the cleaner task the identity of a unique reference which it has displaced. Preferably said cleaner task, during execution, takes into account the identity of those unique references which are indicated as having been displaced.

Preferably said garbage collector construct comprises in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order:

(a) initiating said cleaner task, said cleaner task defining a set of unused objects which comprises initially all objects in said system; (b) said cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs; during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse; (c) said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse .

In an alternative preferred form said garbage collector construct comprises a method of removal or release of unused objects from a computer system; said method comprising the steps of:

(a) following the method defined in Claim 63 to identify a set of unused objects,

(b) making available to said system for re-use the memory locations occupied by said set of unused objects.

In yet an alternative preferred form said garbage collector construct comprises a data object identification system operating according to the method defined above.

In yet an alternative preferred form the abovedescribed environment includes said garbage collector construct comprising a data object identifier and removal system operating according to the method defined above and wherein said cleaner task makes available to said computer system for reuse data objects which have been identified as unused data objects .

Preferably said environment includes a computer architecture which supports a cleaner task; said architecture arranged, in an at least first mode of operation, to take and store elsewhere a value immediately prior to said value being over-written .

Preferably said value which is stored elsewhere is accessible to a cleaner task. Preferably said environment is implemented in hardware. In an alternative preferred form said environment is implemented in software.

In yet an alternative preferred form said environment is implemented in microcode. In yet a further preferred form said garbage collector construct comprises a method of identification of unused data blocks in a computer system implemented as a cleaner task which can run concurrently with other tasks performed by the computer system; each data block having a unique reference; said method comprising the steps of:

(a) designating a special purpose task as a cleaner task which identifies unused data blocks; (b) each task adapted to indicate to the cleaner task that it has caused a unique reference to be overwritten.

Preferably said cleaner task, during execution, takes into account the identity of those unique references which are indicated as having been displaced.

In yet a further broad form of the invention there is provided, an object structure in a scalable computing environment, comprised of a plurality of objects controlled by a resource governor; each said object comprising a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at least: (a) a time of creation field reflecting relative time of creation of said data record; (b) a pointer to a record field which contains information as to the location of another data record within said data structure; said resource governor following a method of allocation of usable resources; said method comprising a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising:

(a) instituting a special purpose task as a resource governor;

(b) said resource governor distributing said usable resources to said resource consumers;

(c) said resource governor receiving from said resource consumers said used resources . In a particular preferred form the object structure and resource governor further includes a garbage collector or cleaner tasks which adopts a method of removal or release of unused objects, said method comprising in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order:

(a) initiating said cleaner task, said cleaner task defining a set of unused objects which comprises initially all objects in said system;

(b) said cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs; during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse; said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the present invention will now be described with reference to the accompanying drawings wherein : Fig. 1 is a block diagram illustrating the generalised application of combinations of scalability constructs for the creation of computing systems and programming environments therefore according to preferred embodiments of the present invention;

Fig. 1.1 illustrates a data structure according to a first preferred embodiment of a first scalability construct applicable to embodiments of the invention;

Fig. 1.2 illustrates diagrammatically an example of a preferred method of operation of the structure of Fig. 1.1;

Fig. 1.3 is a pseudo code implementation of the creation of a data structure of Fig. 1.1; and

Fig. 1.4 is a pseudo code implementation of a preferred method of operation of Fig. 1.2 on the data structure created by the pseudo code of Fig. 1.3.

Fig. 2.1 is a block diagram of a governor arrangement for a prior art computer system;

Fig. 2.2 graphically illustrates behaviour which can be experienced by the system of Fig. 2.1 under high load; Fig. 2.3A is a block diagram of a structure according to a first preferred embodiment of a second scalability construct applicable to embodiments of the present invention; Fig. 2.3B is a block diagram of a structure according to a second preferred embodiment of a second scalability construct applicable to embodiments of the present invention;

Fig. 2.4 is a block diagram of a resource governor arrangement according to a further preferred embodiment of a second scalability construct applicable to embodiments of the present invention;

Fig. 2.5 is a block diagram of a task governor according to a further embodiment of a second scalability construct applicable to embodiments of the present invention;

Fig. 2.6 steps A-H illustrate detailed steps of operation of the governor of Fig. 2.5;

Fig. 2.7 illustrates graphically the behaviour of the system of Fig. 2.5 for large system loads; Fig. 2.8 is a block diagram of a transaction processing system to which an example of a second scalability construct has been applied; and

Fig. 2.9 is a block diagram of a further system to which an example of a second scalability construct has been applied Fig. 3.1 illustrates a simplified prior art object oriented system;

Fig. 3.2 is a block diagram of a system of objects suitable for application of the method of a third scalability construct applicable to embodiments of the present invention; Fig. 3.3 is a sequential block diagram of a method of object identification for removal according to a first embodiment of a third scalability construct applied to the system of Fig. 3.2; and Fig. 3.4 is a block diagram of a computer architecture to which a further preferred embodiment of a third scalability construct has been applied;

Figs. 4.1 to Fig. 4.4 is a first example of the application of a combination of scalability constructs in a transaction environment;

Fig. 5 is a block diagram of a second example of the application of a combination of scalability constructs in accordance with an embodiment of the invention;

Fig. 6 is a block diagram of a further example of a combination of scalability constructs applied to create a virtual machine within a computer system;

Fig. 7A is a graph of concurrent tasks against transactions per second for two computer systems expressed on linear scale axes; and Fig. 7B expresses the same data as for Fig. 7A on log scale axes . DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Various embodiments of the present invention provide a scalable programming environment for a computer system by the adoption of a combination of constructs. The constructs are termed "scalability constructs" because they have the common attribute that they assist the environment to more closely attain or approach maximum utilisation of system resources. In particular instances, the constructs provide an environment in which transactions may be performed in an object oriented environment.

Having described some basic structures and approaches embodied in scalability constructs, these structures and approaches will be combined in various ways by way of example to illustrate a scalable environment for a computing system operable according to various embodiments of the present invention.

In this specification "construct" refers to either a particular structure for software or a method of operation applicable to a computer system.

Scalability is the ability of a system to behave well and make efficient use of resources as the load on that

(computer) system is increased. The term "well behaved" is used in the mathematical sense, which is to say there are no discontinuities up to a point of genuine system hardware limitation. For assistance in understanding these concepts and to better define them they will be placed in context with reference to Figs 7A and 7B.

Fig. 7A is a graph of concurrent tasks against transactions per second for two computer systems expressed as linear scale axes. Fig. 7B expresses the same data as log scale axes .

System 1 comprises a reference hardware platform 501 running under a reference operating system 502. System 2 comprises the same reference hardware platform 501 also running the same reference operating system 502.

With this reference configuration of hardware and operating software both system 1 and system 2 will have the same hardware limits of maximum transactions per second which can be executed and maximum number of concurrent tasks which can be executed. The extent to which either system will be able to achieve these limits and the functional interaction between these limits is dependent on the software of each system which determines how the hardware is driven and how efficiently that hardware is driven. For any given system including systems 1 and 2 there will be a theoretical limit on the number of transactions per second which the systems can perform and a theoretical limit on the number of concurrent tasks which can be executed. In an ideal system the number of transactions per second which can be executed will be the system maximum for any number of concurrently executing tasks up to the system maximum number of concurrent tasks. The ideal characteristic 503 is shown hatched in Figs. 7A, 7B.

The degree to which any given system can approach ideal characteristic 503 is, in effect, one measure of its "scalability" . That is to say, it is a measure of the ability of the system to continue to achieve (or approach) the theoretical maximum number of transactions per second available on the system as the number of concurrent tasks the system is asked to perform increases towards the system maximum - that is, as the scale of the concurrent tasks increases . Whilst the absolute values applicable to ideal characteristic 503 of any given system may be difficult to define with precision experimental tests carried out on computer systems operating with software embodiments of the present invention do assist in providing an indication of lower boundaries of ideal characteristic 503 to which real world systems can aspire to reach.

More specifically, experimental data derived from benchmark experiments as outlined in Annexure B give rise to system characteristic curves for system 1 and system 2 as will now be described.

System 1 utilises currently commercially available database software 504 and, with that commercially available database software 504, a transaction processor 505 was defined for the purpose of executing a predetermined reference transaction schedule 507. The execution of this transaction schedule 507 gives rise to the scalability curve 506 for system 1. In the case of system 2 a transaction processor 508 is defined to run within a virtual machine environment 509. The virtual machine environment 509 incorporates one or more of the scalability constructs according to embodiments of the present invention. When transaction processor 508 is asked to execute the same transaction schedule 507 as was executed by transaction processor 505 of system 1 a scalability curve 510 for system 2 results as also shown in Figs. 7A, 7B .

It will be observed that the scalability curve 506 of system 1 shows that system 2 is able to achieve an approximately 2 order of magnitude increase in number of transactions per second as compared with system 1 and is also able to achieve an approximately 2 orders of magnitude increase in maximum number of concurrent tasks for that maximum number of transactions per second as compared with system 1.

The experiments indicate that embodiments of the present invention which incorporate one or more of the scalability constructs of the present invention allow any given system to approach more closely the hardware imposed system maximums for scalability generally and maximum number of transactions per second executable by the system and maximum number of concurrent tasks achievable by the hardware. Similar results have been achieved where resources other than tasks are measured in this way.

A particular comparison between a system with scalability constructs and one without such constructs is detailed in Annexure B of this specification. In the description which follows three particular scalability constructs will be described in some detail, the first construct being a data object structure, the second construct being a resource governor and the third construct being a garbage collector. These scalability constructs will then be combined by reference to examples applied in a scalable programming environment for a computer system.

With particular reference to Fig. 1 the examples will be described within the environment of a computer system 450, at least a portion of which is a transaction processing system 230 implemented by a virtual machine 451 and which stores data pertaining to the transactions on disk drive 231 which is in communication with the virtual machine 451 by means of 5 I/O 232.

1. First Scalability Construct - Data Object - Detailed

Description

The structure of current computer systems and the data structures or data record structures which they manipulate do 10 not readily lend themselves to the efficient processing of what might be termed historical information. That is, for example, most systems only track historical information if a specific program is written to do so and is kept running so that it can take note of and log changes as they occur over 1.5 time.

Such an approach to historical data management is inherently inefficient, particularly in large or heavily loaded systems .

In addition, particularly in an object oriented virtual 0 machine or operating system, there is a perceived need to provide a basic data record structure which provides an efficient basis for one or more of implementing transactions, read consistency and reduced blocking in such an environment. With reference to Fig. 1.1 there is illustrated an exemplary system 10 comprised, in this instance, of four data record structures comprising respectively, first object 11, second object 12, third object 13 and fourth object 14. First object 11 has its structure shown in detail. The other objects of the system 10 adopt the same structure.

First object 11 consists of an at least first block or data record 15. The data record 15 comprises a set or group of cells or data fields 16 made up of individual data fields 16a, 16b, 16c, 16d ... 16z.

In this instance first data field 16a holds data pertaining to the time of creation of data record 15. This may be an actual time value or it may be a system clock or a system step value. The important information that must be contained in the data is timing information or relative timing information such that in use of the object 11 and the system 10 it will be possible to determine subsequently when data record 15 was created relative to the time of creation of other data records and objects within system 10. Henceforth in this specification the term "transition point data" or "transition point" will be used to refer to the data in data field 16a which pertains to the time of creation or relative time of creation of data record 15. In this instance the transition point data in field 16a is designated T₀ in Fig. 1.1 and is representative of the time of start or time of coming into existence of system 10 wherein, at this time T₀, first object 11 comprises only first block or data record 15. Data field 16b contains pointer data P₀ ■ The intention is that this data will comprise address data pointing to the location of that data record from which the current data record was created. In this instance because data record 15 is the first or initial data record of object 11 there is no earlier data record to point to and hence pointer data P₀ comprises a null pointer.

The balance of the data fields 16c...l6z contain data which can be said to represent information relevant to or representative of the state of object 11 in system 10 at the time represented by transition point data T₀ in data field 16a. The data may relate to any subject matter. An example is provided below where the data concerns personnel information. The data could, of course, relate to any area of human endeavour to which system 10 may be usefully applied. In use, system 10 will have reason to update the data record 15 of object 11. The update will always be performed in such a way as to retain the data of the data field 15 before the update took place. In one preferred update mechanism an update to data record 15 is performed in the following steps.

Step A: System 10 creates a copy of data record 15, in this instance the copy is second data record 15(1) which is created at transition point Ti which is to say at the time Ti when the data in one or more of the fields 16c-16z is updated.

Step B: Update the copy record 15(1) by: i. updating the data in data field 16a to reflect current time (the transition time) Ti; ii . update the pointer data in data field 16b to pointer Pi representing data pointing to the memory location of first data record 15; iii. updating the data in data fields 16c-16z of data record 15(1) to record new data current from transition point Ti . Any subsequent updates to the data in first object 11 follow the same update procedure leading, in this instance as shown in first object 11 of Fig. 1.1, to the creation of record 15 (n) reflecting an update at transition point T_n and pointing via pointer data P_n to the address/location of data record 15(1) and then to the subsequent creation of data record 15(n+l) reflecting update data in fields 16(c)-16(z) as at time or transition point T_n+i and pointing via pointer data P_n+ι in data field 16 (b) to the address of data record 15 (n) .

A similar record creation and update procedure will occur during the operation of system 10 in respect of second object 12, third object 13 and fourth object 14.

For consistency of the operation of system 10 it is important that the transition point data reflects discrete steps synchronised in some fashion with, for example, a master system clock (not shown) whereby transitions (or updates) take place at or reflect changes made at discrete, predetermined increments.

In a simple example the system 10 might permit state transitions to occur only on the second every second so that the data comprising the transition point data will always be an integer value. In this instance, an integer value such as, for example, the integer "2" appearing in data field 16a of first object 11 will reflect the same time or time of creation or time of transition or time of update as the integer "2" in data field 16a of a data record of second object 12, third object 13 or fourth object 14. The system 10 may thus infer that all data records having transition point data comprising the integer "2" were created/updated at the same time and that that time is after the time of creation/update of data records having the integer "1" in their data field 16a and before the time of creation/update of data records having the integer "3" in their data fields 16a.

Also, by virtue of being synchronised or orchestrated by a master system clock, it follows that if the system denotes current system time by an integer, for example, the integer "10" then it automatically follows that the data record of any given object which has the highest integer less than or equal to "10" in its data field 16a represents the "current" data record for that object in the system 10.

A further requirement in this embodiment for the objects 11, 12, 13, 14 is that each object has an identifier or "handle" which is unique to that object in the system 10. In this instance the unique identifier for first object 11 is handle 18 which may, for example, be a designated data field such as, for example, data field 16c which will have the same unique data value in it for all data records 15 (0) -15 (n+1) comprising first object 11.

Similarly, second object 12 has a unique identifier comprising handle 19, third object 13 has a unique identifier comprising handle 20 and fourth object 14 has a unique identifier comprising handle 21.

With reference to Fig. 1.2 a specific example of the use of the four objects 11, 12, 13, 14 comprising system 10 is provided and wherein like numbers indicate like components as for the embodiment described with reference to Fig. 1.1.

In this example first object 11 has a unique identifier or handle 18 designated "object#l" and, initially, comprises first data record 15(0) having three fields in it, namely first field 16a containing transition point data T₀, a second field 16b being a pointer field containing pointer data for the purpose of pointing to (linking to) data records in the same object, but created earlier. The pointer in this embodiment can be termed a "backward pointer" in that it will always point to a data record having a transition point earlier in system time than that of the pointer's own record. In addition first data record 15(0) also includes a data field 16c comprising the name of the person whose personnel file first object 11 represents, in this case the person "Michael" . Finally a fourth data field 16d in first data record 15(0) of first object 11 represents a pointer to the personnel record of the person to whom Michael reports. At the time of creation of a first data record 15(0) Michael reports to no one and hence the data in data field 16d represents a null pointer.

Initially this example system 10 comprises three objects at system time T₀, namely first object 11 relating to the personnel record of "Michael", a second object 12 comprising the personnel record of "Greg" and a third object 13 comprising the personnel record of "Gary" . At system time T₀ Michael and Gary report to no one whilst Greg via pointer date Po in data field 16d of data record 15(0) of object 12 points to the address of third object 13 which is to say Greg reports to Gary.

At system time Ti Michael's personnel record comprising first object 11 is updated to reflect the fact that Michael now reports to Greg. To do this the steps previously described are carried out, which is to say a copy of data record 15(0) is created as record 15(1), the transition time data in field 16(a) of record 15(1) is updated to time T_l7 the pointer data in field 16d is updated to point to second object 12 and the pointer data in field 16b is changed so as to point to record 15(0) . It will be observed that at system time Ti first object 11 now comprises two records whilst second object 12 and third object 13 continue to comprise only a first data record 15(0) .

At system time T₂ Michael's personnel record comprising first object 11 is updated to reflect the fact that he now reports to Gary in the process creating a third data record 15(2) utilising the update process previously described.

Finally, in this example, at system time T₃ a new personnel record in the form of fourth object 14 is created to hold the personal record of a new person "Viki" and, at the same time, Michael's record is updated to reflect the fact that he now reports to Viki, in the process creating fourth data record 15(3) in first object 11. Also at system time T₃ Greg is made to report to Viki with the result that second object 12 is updated to include a second data record 15(1) having pointer data in data field 16d which points to fourth object 14.

Hence, at system time T₃ the current record in first object 18 is record 15(3), the current record in second object 12 is record 15(1), the current record in third object 13 is record 15(0) and the current record in fourth object 14 is record 15(0), these records being the records having transition point data in respective fields 16a closest in system time to time T₃ for each respective object.

A characteristic of system 10 including objects 11, 12, 13, 14 having data record structures and methods of updating those structures as outlined above in respect of these preferred embodiments is that any given object includes data within it which reflects an immediately accessible data record representing the data state of that object for all discrete system times from system start time (designated T₀) to current system time, in this case system time T₃ in the example given in Fig. 1.2. Typically, in use, the objects 11, 12, 13, 14 will include pointers in one or more of data fields 16c, d ... to the handles 19, 20, 21 of other objects 12, 13, 14 thus forming a working system 10 with references between objects performing an at least first directed graph. The data structures of Fig. 1.1 and the method of updating fields within the data records reflected in the description with reference to Fig. 1.2 can be implemented in hardware, software or microcode. There now follows a description with reference to Fig. 1.3 of a pseudo code implementation of the creation of a data record of the type described with reference to Fig. 1.1. In this example the data record 15(0) of object 11 of Fig. 1.1 is created by the routine "construct" by setting data field 16a according to line A, establishes the link between the newly created record and a previous one in field 16b at line B and changes data fields 16c, 16d at lines C, D.

Having thus created data record 15(0) the pseudo code of Fig. 1.4 implements an operation on the data record 15(0) whereby a second record 15(1) is created which points back to first record 15(0).

This is done by assigning a new value to the attribute "aFirstRecord" at line 4.A in Fig. 1.4. In use of system 10 tasks invoke the routine or "method" setDataFieldA which causes changes in one or more fields of first block or data record 15(0) thereby resulting in a new record 15(1) being created at a transition point (kernel .nextTick) which points back to record 15(0).

A task which causes such changes is a "change agent" .

In this way a data structure, in this instance in the form of object 11 in system 10, can hold within it a chain of blocks or data records which hold a historical record of data changes made by the change agent to block 11 at various transition points of system 10.

In a typical system 10 objects such as object 11 will include unique identifiers or handles 18 which can be pointed to by the fields of blocks or data records in other objects within the system thereby to create a directed graph of objects .

2. Second Scalability Construct - Resource Governor - Detailed Description

Many current computer operating system environments are structured to be multi -tasked, multi -threaded systems whereby the processing tasks of the underlying hardware which the operating system resource manages are managed so as to provide efficient, time shared usage of the execution cycles of the underlying CPU or CPU's. In practice these existing systems are not particularly fine grained and it is frequently observed, where such systems utilise the spinlock method of resolving resource requests, that they reach a point of diminishing returns as the task load increases on the underlying CPU's.

More broadly the structure of existing systems tends to lead to a dramatic growth in resource conflicts as system load increased.

With reference to Fig. 2.1 current computing systems spend a significant amount of time resolving resource contentions which occur within the system during operation.

A typical prior art computer system 201 will have a number of tasks or other resources in a work pool 202 from which resource consumers such as first worker 203, second worker 204 and third worker 205 take tasks/resources for execution/consumption and return thereto after execution/consumption .

Because all of the workers are taking work from the one pool directly, resource contentions occur which require resolution before useful work can be done.

With reference to Fig. 2.2, as reflected in graph 207, it can be that underlying CPU utilisation can be devoted 90% or more to resolving resource contention (lightly shaded area 208 in graph 207) and 10% or less to what might be termed "useful" work or activity (cross-hatched area 209 in graph 207) .

With reference to Fig. 2.3A there is illustrated a resource consumer 210 according to a first preferred embodiment of the invention comprising a resource consumer device 211 which accepts resources for consumption via input buffer 212. The arrangement is such that resource consumer device 211 can take only one defined resource at a time from input buffer 212 thereby providing an inherently contention- free structure for consumption of resources by resource consumer device 211.

With reference to Fig. 2.3B a resource consumer 215 according to a second embodiment of the invention is illustrated comprising, in this instance, a resource consumer device 216 which receives resources for consumption from input buffer 217 and then, after consumption of resources, outputs the consumed resources to output buffer 218.

In use for the embodiments of both Fig. 2.3A and Fig. 2.3B resources for consumption are fed to the input buffers 212, 217 and from whence, in order of delivery into buffer 212, 217 the resources are taken by respective consumer devices 211, 216. In this way no contentions occur within the consumer devices 211, 216 because the consumer devices can operate simply on the basis of working on (consuming) one resource at a time and, in the case of the second embodiment of Fig. 2.3B, simply placing an executed or consumed resource into output buffer 218 before looking to, and only to, input buffer 217 for the next resource for consumption by resource consumer 216.

In the context of computer systems "resources" can be any definable unit of work which can be worked upon by a resource consumer. So, for example, the resource can be a task for execution by the resource consumer which, itself, can be a CPU or thread of a computer system. A resource can also be a data block or other definable unit of data which requires work to be performed on it. More broadly, a resource can be a unit of network bandwidth or a definable input/output operation. With reference to Fig. 2.4 the arrangements of Fig. 2.3A or 2.3B and, more specifically in this instance, the arrangement of Fig. 2.3B can be applied via the intermediary of a resource governor or resource allocator to a system of resource allocation which allows allocation and consumption of resources without the consuming devices becoming involved in the allocation process. Stated another way, in this embodiment, the resource consumers do not need to have their execution interrupted for the purpose of resource allocation or resolution of contention. In the arrangement of Fig. 2.4 the consumers are numbered as for the second embodiment of Fig. 2.3B with the first resource consumer and its components incorporating the suffix a, the second resource consumer and its components the suffix b and so on.

In this instance a plurality of resources 219 await allocation in resource pool 220. The resources 219 are allocated for consumption by consumers 215a, 215b exclusively by a special purpose thread or task known as the resource governor 221.

The resource governor 221 allocates resources to buffers 217a, b ... consecutively, providing there is room in the buffers to take the resources for consumption. The resource governor 221 also receives from output buffers 218a, b ... consumed resources which are either re-allocated to an input buffer or are returned to the resource pool 220.

Because the resource governor 221 is the only entity which supplies resources to input buffers 217a, b ... and receives consumed resources from output buffers 218a, b ... there is no locking required and no resource contention.

The combination of the single purpose resource governor 221 with the buffering arrangement illustrated in Fig. 2.4 means that the resource consumers 215a, b ... do not become involved in resource contention issues and can devote themselves exclusively to resource consumption in the form of what might generally be termed useful work.

With reference to Fig. 2.5 a particular example of an application of the arrangement of Fig. 2.4 is illustrated where the resources 219 are tasks for execution by a multitasking computer system. In this instance the resource pool 220 comprises tasks which are dormant in the system. When dormant tasks become active the governor 221 removes them from the pool 220 and puts them into the next available input buffer 217a, b ....

The resource consumers 215a, b ... remove tasks from their respective input buffers 217a, b ..., execute them and then place them into output buffers 218a, b ... following which the governor 221 removes these tasks from the output buffers and reschedules them.

This particular embodiment exhibits the property that the resource scheduling overhead varies linearly with the number of consumers 215a, b ... available to do work and not with the total amount of work to be done. Figs. 2.6A to 2.6H provide a particular example of the arrangement of Fig. 2.4 and, more particularly, the arrangement of Fig. 2.5 where the resources comprise tasks in the form of additions of integers which need to be performed by consumers or workers which, in this case, are simple adder devices .

Again, like components are numbered as for Fig. 2.4 and Fig. 2.5. In this instance the resource pool 220 itself comprises a structure of the type described with reference to Fig. 2.3B where the consumer takes the form of an addition requestor 222 having an input ring buffer 223 into which completed additions are placed and an output ring buffer 224 into which addition operations 225 are placed for working on by consumers, in this instance in the form of adders 215a, 215b.

Governor 221 accepts addition operation 225 (the addition of integers 1 and 2) (Fig. 2.6B). The governor 221 then puts the addition operation 225 into the input ring buffer 217a of first adder 216a (Fig. 2.6C).

First adder 216a then takes the addition operation 225 from input ring buffer 217a and performs the addition (to produce the result integer 3) as shown in Fig. 2.6D .

Having completed the addition operation ("the work") first adder 216a then inserts the (completed) addition operation 225 into output ring buffer 218a as shown in Fig. 2.6E.

Governor 221 then takes the (completed) addition operation 225 from the output ring buffer 218a and puts it into the input ring buffer 223 of (addition) resource pool 220 as shown in Fig. 2.6F.

Figs. 2.6G and 2.6H show the application of the basic sequence just described with reference to Figs. 2.6A through to 2.6F where there are multiple addition operations 225a, b, c, d ... p for execution by one or other of first adder 215a or second adder 215b.

The arrows in Fig. 2.6H indicate the direction of insertion into respective input buffers and removal from the respective output buffers.

It will be appreciated that this basic arrangement can be scaled to handle a significantly larger number of addition operations by adjusting the size (length) of the various buffers with reference to the rate at which the adders can perform addition operations and the governor can put and get addition operations.

In all instances it will be observed that all additions are allocated by the special purpose governor 221. It will also be observed that, in all instances, each adder is not concerned with resource allocation or resource conflict resolution. By virtue of the buffering arrangement illustrated each adder is devoted to performing sequentially the work which it is defined to do, in this instance addition, so long as addition operations are available for removal from an input buffer of that adder.

With reference to Fig. 2.7 experiments have indicated that an expected behaviour of a computer system where resources are governed utilising the methods and structure previously described may follow the characteristic curve of system load (tasks) graphed against work done by the system initially rises steeply as per portion 226, then plateaus at plateau point 227 before falling away gradually in accordance with portion 228. This characteristic can be interpreted that, under heavy task load, the system overhead associated with scheduling of tasks grows gradually with increasing number of tasks. Obviously a saturation point is ultimately reached (not shown) as will occur with any real -world system which is bounded by resource constraints, be they number of CPU's, CPU execution speed, memory resources etc.

With reference to Fig. 2.8 a further example of the application of the governor arrangement and the buffering arrangement described with reference to Figs. 2.3 and 2.4 is illustrated. Again, like components are numbered as for the description with reference to Fig. 2.4.

In this particular instance there is a resource pool in the form of task pool 220 from which tasks are scheduled exclusively by resource governor 221. In this instance system 230 is a transaction processing system and has available to it disk storage 231 which is written to and read from via an I/O subsystem 232 which is communicated with exclusively by a special purpose task termed the delta writer 215c which is devoted to writing transactions to disk storage 231.

The delta writer 215c is a particular resource consumer for the transaction processing system 230.

The other resource consumers are first CPU 215a and second CPU 215b, each adapted to consume all other kinds of tasks derived from task pool 220.

The special purpose governor task 221 is aware of the special purpose delta writer 215c and allocates all transactions requiring a disk write to the input buffer 217c of delta writer 215c. Having performed the disk I/O portion via I/O subsystem 232 the executed transaction write tasks are placed in output ring buffer 218c from which governor 221 can then remove these executed tasks for reallocation or return to task pool 220. In use the CPU's 215a, 215b are not required to be involved in time consuming disk I/O operations. Furthermore contentions for resources including disk I/O resources are removed from the transaction processing system 230 by use of the single special purpose governor 221 (which may itself be a task) which is designated as the sole task permitted to place resources for consumption into the input ring buffers 217a, b, c and remove consumed resources from the output buffers 218a, b, c and also to exclusively take resources from and place resources back into task pool 220.

With reference to Fig. 2.9 there is shown a further preferred embodiment of the invention where a single resource consumer accesses more than one input buffer.

In this instance the resource consumer comprises a multiple input buffer resource consumer 240. Like components are numbered as for the task implementation of Fig. 2.5.

In this instance there is a first input buffer 217al and a second input buffer 217a2.

First input buffer 217al receives resources for consumption in the form of tasks from task governor 221.

Second input buffer 217a2 receives resources for consumption in the form of particular data structures in the form of unused or available objects supplied by garbage collector or cleaner task 241. The resource consumer device 216a, in this instance, is a CPU programmed to recognise and request, as required or needed, different types of resources for consumption including, in this instance, tasks from input buffer 217al and unused or available objects from second input buffer 217a2.

As for earlier embodiments no resource contention is experienced by CPU 216a nor is it required, during resource consumption, to resolve conflicts or contentions. When a resource for consumption of type "task" is required by CPU 216a it is programmed to obtain resources for consumption of that type only from first input buffer 217al. Similarly it is programmed to recognise resources for consumption of type "objects" and is programmed to obtain those, when it requires, exclusively from second input buffer 217a2.

The structures previously described have broad application within computer systems and can, for example, include the situation where a computer system will apply multiple applications of the structure of Fig. 2.4.

3. Third Scalability Construct - Garbage Collector - Detailed Description

All computer operating systems utilise memory systems for the storage and manipulation of data. During usage it typically occurs that portions of memory contain data which is no longer required. The system needs to be made aware that these memory portions have become available for further use. In one sense it can be said that these memory portions now contain "garbage" and there is a requirement to collect the "garbage" so as to free up the memory resources for further system use .

In an "object oriented" form of computer system the system can be thought of as producing and using objects, the "objects" being data objects having data fields which either contain data values or pointers to objects.

Fig. 3.1 illustrates a generalised object oriented system 301 containing a first data object 302 and a second data object 303. The first data object 302 comprises a single data record having a number of different data fields, one of which is a pointer field 304 containing data which points to (that is contains the memory location of) a data field 305 containing numbers in second data object 303.

In such a system memory resources can become unavailable where, for example, data objects come to point back to each other forming an island 306.

In order to get rid of this "garbage" thereby to free unused system resources most systems use some form of garbage collection . Two commonly used current forms are "reference counting" and "mark/sweep" .

Problems with current systems include inability to locate islands, a requirement that the operating system suspend processing while garbage is being collected and a general inability to consistently and comprehensively first identify and then remove unwanted or unused data objects (garbage) .

With reference to Fig. 3.2 there is illustrated a system 310 suitable to perform data processing on a computing platform (not shown) .

The system 310 comprises a plurality of data objects

311, 312, 313, 314, 315. Each object comprises at least one data record having at least a pointer field 311a adapted to point to the location of another object, in this case object

312. In all instances each object has a unique reference or "handle" 311b associated with it. (The corresponding handle of an object is identified by the suffix b so, for example, the handle of object 312 is handle 312b) . The system 310 can be described as a "directed graph" of objects 311, 312 ... having a remembered or initial starting point 320. In this instance first object 311 is the first object of the system 310 pointed to by starting point 320.

In normal use each of the data objects will also include a plurality of data fields 311c, 312c, ... which will contain data required by the computing operation relevant to the current computing tasks which system 310 is being asked to undertake in programmed manner. In use the system 310 will be in a state of flux with many tasks running as a consequence of which new objects are created and pointer fields are continually being updated to point to different objects according to the demands of the computing task or tasks at hand. So, for example, a sixth object 316 can come into existence having handle 316b (numerically identified in this case as #2750) and, further, the system is updated whereby pointer field 311a of first object 311 is updated to point to handle 316b instead of handle 312b. In this instance the manner in which the update to first object 311 takes place is a superposition operation on pointer field 311a as indicated in superposition equation inset 317 where the handle in pointer field 311a (VAR A) is substituted by the handle of the value VAR B + 1. The original handle in pointer field 311a has thus been "displaced" by another handle.

As a result of this operation second object 312 is no longer pointed to by any other object in the directed graph of system 310. Hence second data object 312 is now effectively garbage and a candidate for identification for removal .

The manner of identification for removal of data object 312 from the system 310 will now be exemplified according to a first preferred embodiment of the invention with reference to Fig. 3.3. In this instance the method of identification for removal will be allocated to a specific task running on the system 310 and is henceforth termed a "cleaner task" .

In this embodiment, a requirement for the data identification for removal system (cleaner task) of Fig. 3.3 to operate is that system 310 maintains a list 318 of all handles 311b, 312b ... during execution. More generally it needs to be possible for the cleaner task to discover all objects and all initial starting points. The maintenance of the list 318 is one way of ensuring this.

Initially, immediately prior to commencement of a garbage collection or data object identification for removal process being initiated the system 310 is as indicated in Fig. 3.3A comprising second data object 312 now isolated and with first data object 311 having three pointer fields 311al, 311a2 and 311a3 pointing to respective handles 313b, 314b and 315b of respective third, fourth and fifth objects 313, 314, 315.

Initial starting point 320 points to handle 311b of first object 311.

Also, for the purposes of operation of the cleaner task of this embodiment, a set of unused objects 321 or "garbage set" is initialised and will initially comprise an empty list. Also defined is a displaced set 322 which is designated to contain all handles which have been displaced during system operation, at least during a predetermined period of time or period of system operation. In this instance, initially, the displaced set 322 is empty which is to say it contains no handles (or information which would allow the location of handles) which have been displaced during operation of system 310. In this instance the condition or time when system 310 will place displaced handles into the displaced set 322 is when the system 310 is in a mode of operation termed, in this example, "displaced mode on". When system 310 is not in this mode it is said to be in the mode "displaced mode off". In this instance the system 310 will be put into displaced mode on when the cleaner task is active.

In this instance the system 310 also maintains a known set of objects 323 in the form of a list of all objects 311, 312, ... in system 310. This arrangement is one way of ensuring that the cleaner task can discover all objects of system 310 at any given time.

The cleaner task can now proceed as follows with reference to Figs. 3.3A through to 3.3F of Fig. 3.3: Example: Cleaner Task Operation

Fig. 3.3A

1. There is one known initial starting point or "root" 320 in the system 310. 2. At some point of execution there is a directed graph of five objects as shown in Fig. 3.3A. 3. At this point the second object 312 cannot be reached from any object within the directed graph attached to the root . 4. There is one user task in the system.

5. There is one cleaner task in the system.

6. The cleaner task is dormant, and the system is in displaced mode off.

7. The cleaner task wakes. Fig. 3.3B

8. The cleaner task copies all references from the known set 323 into the garbage set 321.

Fig. 3.3C

9. The cleaner task puts the system into displaced mode on. 10. The cleaner task then proceeds to walk or traverse the directed graph of objects looking for object references (handles) . Fig . 3 . 3D

11. At some point the cleaner is walking through the fields or cells of second object 313 and is at third field or cell 313a3. 12. At this point the user task deposits a handle reference 314b to third object 314 into first field 313al of second object 313.

13. The user task then deposits a handle reference to fourth object 315 into second field or cell 311a2 of first object 311.

14. This deposit causes the handle or reference to object #3 to be displaced.

15. This displaced handle reference {3} to third object 314 is put into the displaced set 322. 16. The cleaner task continues independently of the user task. Fig. 3.3E

17. At the end of the walk or traverse the cleaner task puts the system into displaced mode off. 18. At this point 3 and 5 are in the garbage set and 3 is in the displaced set.

19. The cleaner task removes each handle from the displaced set 322 and uses each such handle as the initial starting point or root and performs a traverse of the graph readable from each such handle. Fig. 3.3F

20. The cleaner task removes the reference to object 3 from the garbage set 321.

21. The final garbage set 321 has the handle 315b of second object 312 in it.

22. This object is garbage and can be deleted or re-used.

In a particular preferred form any handle which has previously been encountered during a traversal of a given directed graph will cause the cleaner task to backtrack up that directed graph. Summary The system described with reference to Fig. 3.3 works on an underlying assumption that any data field inspected will be in a stable state with valid data in it. So, for example, there can be systems where data fields move into an indeterminate state during a number of clock cycles of the system. It is assumed that the cleaner task and any of the other tasks upon which it relies will not make use of data whilst in an indeterminate state.

It will be observed from the description with reference to Fig. 3.3 that an expected characteristic of operation of system 310 is that the at least one user task has the ability to recognise displaced handles and, at least while the system is in displaced mode on, to place either the displaced handles or information pertaining to the identity of the displaced handles, into the displaced set 322 or otherwise make available that information to the cleaner task in order to allow the cleaner task to conduct the (subsequent) traverses described with particular reference to Figs. 3.3E and 3.3F and, specifically, step 19. That is, stated in another way, the designated cleaner task expects assistance from all other tasks running on the system, at least during a predetermined period of operation which, with reference to Fig. 3.3, is designated "displaced mode on" . The collection of displaced handles permits the tasks to keep executing or be executed even whilst the cleaner task is in operation.

This concept of the system "remembering" displaced data in the form of displaced handles can be implemented in hardware, software, or microcode.

Described below is a particular embodiment where this characteristic is implemented directly at the hardware level. Computer Architecture Implementation

With reference to Fig. 3.4 the identification methods inherent in the cleaner system previously described with reference to Figs. 3.2 and 3.3 can be facilitated by arranging that when a first value 401 in a first register 400 is about to be overwritten the value 401 is first written to a second register 402.

This procedure can be carried out for operations on multiple values over multiple registers during a predefined window of operation of the architecture or during a predefined mode of operation of the architecture.

The architecture can be implemented in software or in microcode or in hardware, for example as part of a microprocessor 403.

Examples of Combinations which provide a Scalable Programming Environment for a Computer System

With particular reference to Fig. 1 the examples will be described within the environment of a computer system 450, at least a portion of which is a transaction processing system 230 implemented by a virtual machine 451 and which stores data pertaining to the transactions on disk drive 231 which is in communication with the virtual machine 451 by means of I/O 232. With reference to Fig. 1 in the examples which follow an example of the first construct in the form of data objects 11 applied in a transaction processing system 230 is described.

With further reference to Fig. 1 the transaction processing system 230 brings within its scope initially the use of the first construct in the form of object 11 followed by the combination of the first construct in combination with the second construct in the form of the resource governor 221 operating in conjunction with resource consumers 215a, 215b further operating in combination with a specialised system task in the form of delta writer 215c.

A final example with reference to Fig. 1 and as further detailed in Fig. 6 describes the implementation of an object oriented virtual machine 451 operable under the language detailed in annexure A to this specification. Annexure A forms part of and is to be read in conjunction with this description.

Wherever possible like components in the examples have been numbered as for earlier descriptions relating to the various constructs .

4. Transaction Example with Delta Writer Example

With reference to Fig. 4.1 the virtual machine 451 includes data relating to a bank account holder Peter who has a first account having financial details stored in object 11A and a second account whose financial details are stored in object 11B. General information as to the relevant details for Peter such as name, address and the like are stored in a third object IIC. Initially object 11A has a first data record 15A(1) created at system time "1". Similarly second object 11B has a first record 15B(1) and third object IIC has a first record 15C(1) . Each of these records contains data relating to the person "Peter" at system time "1" . In this example first object 11A representing details of the first account shows an account balance of $100 in value field 15A(l)d. Similarly the current balance (at time "1") in Peter's second account is $300 as indicated in field 15B(l)d of object 11B. Object IIC contains fields pertaining to the identity and address details of "Peter" including a name field 15C(l)c and an address field 15C(l)d.

The account ID field 15A(l)c of first object 11A points to the handle of third object IIC similarly the identity details of the second account represented by second object 11B include a pointer in identity field 15B(l)c also pointing to the handle of third object IIC. At this stage no changes have been made to either the first or the second account since before a system time equal to "1" .

Should Peter decide to transfer $100 from his second account to his first account as represented by Fig. 4.2 (for example by way of a teller machine) then virtual machine 451 would handle the transaction as follows: Fig. 4.1

(a) read balance of both accounts; (b) write new balance of $200 into account 2 ; i. lock, create copy record with no time stamp ii. make change to balance Fig. 4.2

(c) write new balance of $200 in account 1; i. lock, create copy record with no time stamp ii. make change to balance. Fig. 4.3

(d) once transaction is complete i. all newly created records are written to disk for durability; ii. all new records are stamped with the transaction time tick for atomicity.

(e) Objects are unlocked and execution continues. With reference to Figs. 1 and 2.8 all writes to disk 231 are allocated to a special purpose system task known as the delta writer 215c.

In this example task allocation, as indicated in Fig. 2.8 and Fig. 1 is performed by governor 221 operating in accordance with the description given in respect of Fig. 2.8 earlier .

5. Cleaner Example including description of Ancient Tick and Epoch Writer With reference to Fig. 5.1, Fig. 2.9 and Fig. 1 a cleaner task 241 operates as previously described with reference to Fig. 3.3. In addition, for the example illustrated in Fig. 5.1, the system 450 elects to set the oldest time perspective (referred to as the "ancient tick") at integer equals "2" . The result of this is that when traversing graphs in accordance with the description given with respect of Fig. 3.3 the cleaner will not remove from the garbage set records having a time perspective earlier than the value of the ancient tick - unless the record in question is the oldest record in an object. The result of applying this algorithm is that record 15A(1) remains in the garbage set thereby being identified by the cleaner task 241 as no longer used. The system of Fig. 1, by virtue of its use of objects 11, 11A, 11B, IIC has a time perspective as given by fields 15(1) a ....

Hence the system can control the depth of the time perspective by the setting of the "ancient tick", in this case to the integer "2" .

The system can also include a system task known as the Epoch Writer 452 which periodically writes to disk 231 snap shots of the full system state at the current time perspective for the purpose of providing stable storage for recovery. 6. Virtual Machine Example

Fig. 6 illustrates an example of a virtual machine 451 adapted to execute user tasks and special tasks where the special tasks are system tasks or system agents which, together, provide a scalable, object oriented environment for the conducting of transactions.

The virtual machine 451 operates in accordance with the description given with reference to Fig. 1 and the examples above .

The virtual machine 451 includes a first construct in the form of use of objects 11 having the structure previously described with reference to Fig. 1.1. The machine also includes a second construct in the form of a resource governor 221 which operates in the manner described with reference to Figs. 2.4 and 2.5. The machine 451 includes a third construct in the form of the garbage collector or cleaner task 241 which operates in the manner described with reference to Fig. 3.3.

Other constructs which the system uses include delta writer 215c and epoch writer 452.

The virtual machine 451 operates within a transaction processing system 230 which itself operates within system 450.

In this instance tasks performed by resource consumers of the virtual machine 451 are broken up into two kinds, either "user tasks" or "system tasks" . The system tasks are as follows:

• Governor - allocates user tasks to appropriate system agents/CPUs - e.g. tasks - CPUs, Delta, Locksmith,

Plumber, idle task queue.

• Cleaner - removes/recycles unused memory - and updating the Ancient Tick.

• Supervisor - Checks all system agents are running properly and attempts to recover from faults.

• Locksmith - Checks whether tasks are deadlocked and interrupts them. • Unblocks tasks that are waiting for 1/0.

• Command - accepts administrative instructions (e.g. from console) .

• Delta - writes transaction log records to stable storage .

• Epoch - periodically writes snapshots of the full system state at a time perspective to stable storage.

• Watchdog - keeps track of statistics and state of operating environment .

• Inspector - for debugging. Checks task and memory consistency.

• Gremlin - tries to make mischief and trigger supervisors .

• Storeman - watches the files created by Delta and Epoch writer and removes old outdated files.

In this system objects are either persistent objects or transient objects. The system guarantees that persistent objects will always be available, as needed.

Persistent objects are defined, in this instance, by reachability which is to say the system defines a persistent route or starting point and builds a directed graph of persistent objects from this - refer Fig. 6. In this instance the system operates according to the following rules: 1. The persistent graph of objects can only be changed in a transaction. 2. All user tasks have a time perspective.

3. There are specialised system tasks (which are not user tasks) which perform specified system functions (see above) .

4. Persistent objects can only reference other persistent objects.

The system 450 can operate in a distributed environment and can service clients, for example in the form of thin clients 453 accessible via a network connection or other communications medium. An appropriate language by which the constructs of the virtual machine 451 can be manipulated is given in Annexure A, which annexure is incorporated within this specification. The language itself can be implemented using, for example, C++. 7. System Aid Overhead

With reference to the detailed examples provided above in relation to specific scalability constructs such as the data object structure, the garbage collector and the resource governor it is to be noted that these three examples of scalability constructs each incorporate a system aid overhead. That is to say each incorporates structures or methods of operation which, particularly in a lightly loaded system, may seem to add unnecessary steps or "overhead" . In the case of the data object structure the structure is arranged to retain and keep track of changes made to it. In some simple implementations this would seem to be an unnecessary requirement given that not all of the historical information thus kept will be called into use. Similarly with the garbage collector, the garbage collector requires that all objects have the ability to flag certain relevant changes to the system in which the garbage collector is operating.

In relation to the resource governor a resource governor module is interposed between resources for consumption (a task pool for example) and resource consumers (CPUs for example) .

As perhaps best seen in Fig. 7B this system aid overhead can result in a system operating according to the present invention (system 2 in Fig. 7B) operating less efficiently at very low system load than a comparable system (system 1 in Fig. 7B) which do not incorporate such overheads. However, at higher system loads as evident in both Fig. 7A and 7B it is the system aid overhead which permits overall far more efficient operation of the system.

It has been noted in tests that, in at least some examples, the system aid overhead 511 stabilises such that it consumes system resources at a rate which is substantially independent of system resource utilisation. Again, the reader is referred to Annexure B for a very specific comparison of a system with scalability constructs compared with one without such constructs.

The above describes only some embodiments of the present invention and modifications, obvious to those skilled in the art can be made thereto without departing from the scope and spirit of the present invention.

INDUSTRIAL APPLICABILITY

Embodiments of the abovedescribed invention are applicable to the construction of programming environments for computer systems. The programming environments thus created may be rendered wholly or partially in software, firmware or hardware or combinations thereof.

The programming environment may be (or form part of) an operating system. Alternatively the programming environments can be programmed as a virtual machine adapted for operation under or within a third-party-provided operating system.

Particular forms of implementations are suitable for the execution of transactions which adhere to ACID principles.

The system as a whole, or portions of it can be used as the basis for database systems, thin client servers and clients, Internet deep content provider systems, application service provider systems, application servers, ultra fast transaction machines and simulation machines, Smart QoS Internet switch systems, phone internet systems and end user devices including personal digital assistants and the like.

ANNEXURE

Virtual Machine Language

Language Reference Manual Draft 70A 1 Company Confidential

Table of Contents

Lexical Conventions 10

Source 10

Location 10

Tokens 10

Compilation Process 12

Name Scope 12

Name Resolution 12

Lexical Errors 12

Syntax Notation 12

Object Lifecycle 14

Object Instantiation 14

Object Destruction 14

Tasks 15

Properties 15

Clauses 17

Clause List 17

Classes 19

Class Definition 19

Description Clause 20

Library Clause 21

Help Clause 22

Author Clause 22

Geneπcs Clause 23

Inherits Clause 24

Extension Clause 25

Exposure Clause 27

Options Clause 28

Constants Clause 30

Attributes Clause 31

Depends Clause 32

Ensures Clause 33

Security Clause 34

Method Clause 35

Methods 37

Description Clause 37

Help Clause 38

Extension Clause 39

Exposure Clause 40

Options Clause 41

Parameters Clause 42

Depends Clause 43

Returns Clause 44

Ensures Clause 45

Security Clause 46

Locals Clause 47

Begin Clause 48

Driver Clause 49

Statement 51

Assert Statement 51

Assignment Statement 52

Case Statement 53

Continue Statement 55

Debug Statement 56

For Statement 57 70A 2

Language Reference Manual Draft Company Confidential

If Statement 59

Label Statement 60

Leave Statement 61

Lock Statement 62

Message Statement 64

Raise Statement 65

Retry Statement 66

Return Statement 67

Rollback Statement 68

Transaction Statement 69

Trap Statement 70

Until Statement 72

While Statement 73

Expressions : 75

Operators 75

Precedence 75

Add Operator + 76

And Operator 76

Callback Operator 78

Concatenation Operator | 79

Construct Operator 79

Divide Operator / 80

Downcast Operator 80

Grouping ( ) 82

Is Operator 83

Is Equal Operator = = 83

Is Less Operator < 84

Is Less Equal Operator < = 85

Is Greater Operator > 86

Is Greater Equal Operator > = 87

Is Not Equal Operator ! = 88

Modulus Operator % 89

Multiply Operator * 89

Negate Operator - 90

Not Operator ...., 91

Or Operator 92

Power Operator ^Λ 93

Subtract Operator - 94

Data types and Literals 95

Boolean Data Type and Literal 96

Character Data Type and Literal 96

Date Data Type and Literal 97

Datetime Data Type and Literal 98

Float Data Type and Literal 99

Identifier Data Type and Literal 100

Integer Data Type and Literal 100

Interval Data Type and Literal 101

Money Data Type and Literal 102

Raw Data Type and Literal 103

String Data Type and Literal 104

Tick Data Type and Literal 104

Time Data Type and Literal 105

Version Data Type and Literal 106

Language Grammar 108

Syntax Errors 115

ARGS01 115

ARGS02 115

70A 3

Language Reference Manual Draft Company Confidential

ASRT02 116

ATTR01 116

ATTR02 116

ATTR03 117

ATTR04 117

AUTH01 117

CASE01 117

CASE02 118

CASE03 118

CASE04 118

CDEP01 118

CDEP02 119

CENS01 119

CENS02 119

CEXP01 119

CEXT01 120

CLAS01 120

CLAS02 120

CLAS03 120

CLAS04 121

CLAS05 121

CONS01 121

CONS02 121

CONS03 122

CONS04 122

CONS05 122

CONS06 123

CONS07 123

CONS08 , 123

CONS09 123

CONS10 124

CONS11 124

CONT01 124

COPT01 124

CSEC01 , 125

DBUG01 125

DBUG02 125

DESC01 126

DOTM01 126

DOTM02 126

DRVR01 126

DRVR02 127

DRVR03 127

EVAL01 127

EXEC01 127

EXEC02 128

EXEC03 128

EXEC04 128

EXEC05 129

EXEC06 129

EXPR01 129

EXPR02 129

FOR01 130

FOR02 130

FOR03 130

FOR04 130

FOR05 131

HFI Dm 70A 4

Language Reference Manual Draft Company Confidential

IF02 131

IF03 132

IF04 132

INHT01 132

INHT02 132

INVT01 133

INVT02 133

LABL01 , 133

LBRY01 133

LBRY02 134

LEVE01 134

LOCK01 134

LOCK02 134

LOCK03 135

LOCS01 : 135

LOCS02 135

LOCS03 136

LOCS04 136

MDEP01 136

MDEP02 136

MENS01 137

MENS02 137

MESG01 137

MESG02 137

MESG03 138

MESG04 138

MESG05 138

METH01 139

METH02 ^■. 139

METH03 139

MEXP01 139

MEXTOl 140

MOPT01 140

MSEC01 140

NCLX01 141

OTHR01 141

OTHR02 141

OTHR03 141

OTHR04 142

PARMOl 142

PARM02 142

PARM03 142

PHRSOl 143

PHRS02 143

POW01 143

POW02 144

PROD01 144

PROD02 144

PROD03 144

PROD04 145

RAIS01 145

RAIS02 145

RAIS03 145

RETN01 146

RETS01 146

RETS02 146

RETS03 146

R F YP01 70A 5

Language Reference Manual Draft Company Confidential

REXP03 147

REXP04 148

REXP05 148

REXP06 148

RMSG01 148

ROLL01 149

RTRY01 149

SUMM01 149

SUMM02 149

SUMM03 150

SUMM04 150

SUMM05 150

SUMM06 150

TERM01 151

TERM02 151

TERM03 151

TERM04 152

TERM05 152

TERM06 152

TERM07 152

TERM08 153

TERM09 153

TERM 10 153

TERM 11 153

TERM 12 154

TERM 13 154

TERM 14 154

TERM 15 155

TERM 16 155

TERM 17 155

TERM 18 155

TERM 19 156

TERM20 156

TERM21 156

TERM22 , 156

TERM23 157

TERM24 157

TERM25 157

TERM26 158

TERM27 158

TERM28 158

TERM29 158

TERM30 159

TRAN01 159

TRAN02 159

TRAP01 159

TRAP02 160

TRAP03 160

TRTH01 160

TRTH02 161

TRTH03 161

TRTH04 161

TRTH05 161

TRTH06 162

TRTH07 162

TRTH08 162

TRTH09 162 i INTI m

70A 7

Language Reference Manual Draft Company Confidential

SEMT55 179

SEMT56 179

SEMT57 179

SEMT58 180

SEMT59 180

SEMT60 180

SEMT61 181

SEMT62 181

SEMT63 181

SEMT64 181

SEMT65 182

SEMT66 182

Compilation Warnings 183

WARN01 183

WARN02 183

Glossary 184

Index 192

70A 8

Language Reference Manual Draft Company Confidential

Lexical Conventions

This topic describes the structure of program source.

Source

Object definitions in bullαnt are specified as text held in source files. Source files may be given any valid file system name but must have a suffix of '.sb'.

Location

To be known to the bullαnt ecosystem, source files for objects must exist within a known library location.

Tokens

The readable form of a program consists of a sequence of tokens. A token is a collection of one or more characters that are grouped together into meaningful words such as 'while' and symbols such as '< ='.

The following sections describe the various kinds of tokens.

Names

Various things such as classes, methods and variables are given names by the programmer. Names (also known as identifiers) must adhere to the following convention :

A name is a sequence of one or more characters;

Names must start with a letter (a .. z, A .. Z), an underscore (_), or the dollar

Subsequent characters may also include the numeric digits (0 .. 9);

A name can be_, any length.

The compiler is not case sensitive. Tokens like 'poker' and 'POKER' are recognized as he same name. The compiler however does preserve case - names are recorded in heir original form.

Keywords

The following tokens are the keywords that constitute the bullαnt language. abstract all ancestor and application assert attributes author begin callback case character$ class config concrete constants construct continue date$ datetime$ debug depends description downcast driver elif else end ensures error exception exposure extension false fatal final for foreach function generics glyph help hex$ hidden host ιdentιfier$ If immutable in inherits 70A 9

Language Reference Manual Draft Company Confidential

library locals lock method money$ mutable none not null obsolete options or other parameters peer private public raise raw$ reason restricted retry return returns rollback route security self settings severity step task test tick$ time$ transaction trap true unknown until varying version$ warning when while

Reserved Words

The following words are reserved by the bullαnt language:

Boolean character date datetime float identifier integer money object raw string tick Time version

Special Characters

The following characters are used in the bullαnt language:

# @ : +

/ ^Λ % < = ' >

{ } [ ] ( ) \

Their usage is explained in following sections.

Special Pairs

The following character pairs are used in the bullαnt language:

Their meanings are explained in following sections.

Reserved Sequence bullαnt reserves the naming sequence $$somename' for internal use. By convention programmers should avoid using names with this pattern in their applications.

White Space

Blanks, tabs and new lines lexically separate tokens. White space itself is ignored by the bullαnt compiler.

Comments

The hash sign '#' is used to indicate the start of a comment. A comment runs from the hash sign to the end of the line The compiler ignores comments. tt h i i s an example of a comment

Compiler Actions

The compiler recognizes commands embedded in program source These commands are known as actions and are identified by an at sign - '@' The following actions are currently supported. 70A 10

Language Reference Manual Draft Company Confidential

@on start compiling again

Using @off and @on, the programmer can temporarily remove code from the source without having to use commenting.

• return cards to the deck deckSize = deckSize + handSize

• don't compile the following lines @Off if deckSize ' = 53 # assuming a joker raise CardCheat end if ©On

Compilation Process

The compilation process has five stages:

Scan All library locations are scanned for changed or new source files;

Class Source files are parsed to identify classes;

Method Source files are parsed to identify methods;

Bind The compiler builds the bind tables,

Statement Source files are parsed to produce executable code.

Name Scope

There are four levels of name scope - method, class, library, system. The following rules apply:

• A name declared within a method is local to that method and is only known within the method;

• A name declared within a class can be used anywhere within the class or subclass;

• A class may be used by its short name within a class belonging to the same library; '

• A class may be used from a different library by specifying its full name.

Name Resolution

Names are resolved in the order method, class, library then system.

Lexical Errors

The compiler detects the following structural problems in source files: Non-readable control characters;

• Incomplete strings, for example unclosed quotes, ■ Incorrect use of single quotes.

Syntax Notation

The following notation is used to describe the syntax of the bullαnt language.

70A 11

Language Reference Manual Draft Company Confidential

70A 12

Language Reference Manual Draft Company Confidential

Object Lifecycle

This topic describes the lifecycle of objects.

Object Instantiation

The operator construct has special meaning - it is used to create instances. An instance of a class is created by sending a message using construct to its class: lCard : = Construc ( cCard ( ) )

In the above example 'ICard' is a local variable and 'cCard' is a class.

Construction Sequence

When an object is instantiated via construct the system executes the following sequence :

1. The object is physically created;

2. All attributes are initialized;

3. Each OnConstruct() method in the ancestry is run in turn from root to leaf;

4. If a suitable Construction() method exists it is run;

5. The class ensures clauses are run (if any exist) from root to leaf.

Construction Method

A ConstructionQ method may be defined for each class. The ConstructionQ method enables the programmer to initialize the specific instance of the class. The Construction() method may accept parameters.

OnConstruct Method

To allow procedural initialization of objects, the system applies special treatment to methods named OnConstruct. When an object is instantiated, the system executes the OnCβnstruct method (if one exists) in each of the individual classes in the ancestry of the class being instantiated. ^J

The OnConstruct method may not accept parameters.

Object Destruction

An object instance remains in memory as long as there are references to it. The system automatically destroys the instance when there are no longer references to it.

There is no explicit way to force an instance to be destroyed. 70A 13

Language Reference Manual Draft Company Confidential

Tasks

Tasks are independent processes, bullαnt is a multi-tasking language - the bullαnt environment may contain any number of concurrent tasks. Tasks may spawn other tasks.

A task is a context within which objects call each other. A task has an associated set of properties that may be queried by objects within the task.

As they are also objects, tasks are used to represent users, business processes or system agents.

By definition, tasks are independent, but they may collaborate through a variety of communication mechanisms

Properties

70A 14

Language Reference Manual Draft Company Confidential

70A 15

Language Reference Manual Draft Company Confidential

Clauses

Clauses are the basic building blocks the programmer uses to set up classes and methods in bullαnt. Many clauses can be used in both in slightly different formats. Some clauses relate specifically to one object or the other.

Clause List

Following is a list of clauses used by bullαnt classes and methods. Click on a Class or Method below to go to a more detailed description of the associated clause.

70A 16

70A 17

Language Reference Manual Draft Company Confidential

Classes

A class defines both an object and its type. Every instance of an object belongs to a particular class The Class Definition describes the syntax of classes. A class is delimited by the keyword phrases class NAME and end class.

Class Definition

Description

The class definition lists the properties of a class. A class defines both an object and is the type of that object Every instance of an object belongs to a particular class.

Syntax class NΛMC

[ description ] library help ] author ] generics] inherits βΛtension ] e<posure ] options ] constants ] attributes ] depends ) ensures ] 70A 18

Language Reference Manual Draft Company Confidential

[ security ] [ { method } ] end class

Important Information

^■ Only one class may appear in a source file;

^■ The library and inherits clauses are mandatory;

• A class is delimited by the keyword phrases class NAME and end class;

■ Clauses used must appear in the order in which they are listed above.

Some Examples

In the following example the class is very simple and has only one method. It demonstrates the basic structure of a class.

_# #

# file: .. /examples/clas_class . sb # # # class cClassExample description

"A class to demonstrate the class structure." library examples author

"Your Name" inherits object method start begin

"Hello Universe! ". Prin ( ) end method , end class

# #

Description Clause

Description

The description clause records a comment that describes the class. It is useful for the purposes of code commenting and ease of reference.

Syntax descript ion LITΈRALSTRING

Important Information

^■ The description is optional and has no side effects;

■ The default is null;

^■ It is primarily for annotation and use by the bullαnt tool set; 70A 19

Language Reference Manual Draft Company Confidential

It is held with the class in the system meta data. Some Examples

The following example demonstrates how a description clause is used.

# _#

# file: .. /examples/clas_descnptιon. sb # # # class cClassDescriptionExample description

"Example class showing use of the description" library examples inherits object end class

# #

Library Clause

Description

The library clause defines the library in which bullαnt can find the class.

Syntax library

NAMELIBRARY

Important Information

■ The library clause is mandatory;

^# Each class belongs to a library;

The named library must be a known library within the system.

Some Examples

In the following example the class belongs to the examples library.

# #

# file: .. /examples/clas_library. sb # # # class cClassLibraryExample description

"Example of class library clause" library examples inherits object end class

# # 70A 20

Language Reference Manual Draft Company Confidential

Help Clause

Description

The help clause records a reference to text that provides help on the class.

Syntax help

LITERALSTRING

Important Information

^■ The help clause is optional and has no side effects;

■ The default is null;

■ It is primarily for annotation and use by the bullαnt tool set; It is held with the class in the system meta data.

Some Examples

In the following example the help clause refers to some example help text about the class.

# #

# file: .. /examples/clas_help. sb #

# _# class cClassHelpExample description

"Example of class help clause" library examples help

" ReferenceManual/ClassHelp"

« inherits object end class

# #

Author Clause

Description

The author clause records the name of the writer of the class.

Syntax author

L I TFRΛLSTRING

Important Information

^■ The author clause is optional and has no side effects;

^■ The default is null;

It is primarily for annotation and use by the bullαnt tool set; 70A 21

Language Reference Manual Draft Company Confidential

It is held with the class in the system meta data.

Some Examples

In the following example the author of the class is bullαnt Pty Ltd.

# _#

# file /examples/clas_author sb #

# # class cClassAuthorExample description

"Example of class author clause" library examples author

"bullant Pty Ltd" inherits object end class

# #

Generics Clause

Description

The generics clause defines a list of variables to be used as place holders for a type passed by the calling message.

Syntax generic s

{ { NAME NAMECLASS } , | none }

Important Information

^■ The generics clause is optional;

■ NAME IS used in place of a type in the class methods;

^■ Methods within the class can use NAME as if it inherits from NAMECLASS;

■ The calling message passes a type to be substituted for NAME;

Once a type is specified for NAME, the compiler enforces the use of that type;

■ When a message calls a method in a class with a generics clause, the class name follows the form CLASSNAME(TYPE[,TYPE, .. ] ) . Where TYPE specifies the type to be substituted for the corresponding generic type;

■ The type specified by the calling message must be a subtype of the type specified in the generics clause;

• The generics clause can be used in 'container' classes such as lists, where the list could be of many different types. 70A 22

Language Reference Manual Draft Company Confidential

Some Examples

Inherits Clause

Description

The inherits clause lists those classes inherited by the current class.

Syntax inherits

NAMEC ASS [ ( TYPE [ , TYPE , . ] ) ] ,

Important Information

The inherits clause is mandatory;

A class inherits the methods, constants and attributes, depends, ensures, and security clauses, of its ancestors;

If the inherited class contains a generics clause, the types to be substituted are specified as TYPE;

A class may inherit from any number of classes;

The compiler will detect any circular inheritance.

Some Examples

In the following example, class cClassInheritsExampleChild inherits from cClassInheπtsExampleParent.

The child class inherits the attributes and method of its parent and adds its own method 'start'.

#

# file /examples/clas_ιnherιtsl sb # class cClassInheritsExampleParent description

"Example of class inherits clause" library examples inherits object attributes aValuel integer, aValue2 integer method CalculateSum returns rSum integer begin return aValuel + aValue2 end method end class

#__ _. 70A 23

Language Reference Manual Draft Company Confidential tt # ft file /examples/clas_mherιts2 sb #

# (j class cClassInheritsExampleChild description

"This is the child class" library examples inherits cClassInneritsExampleParent method start begin

"Class inherits example" prin ( ) aValuel = 3 aValue2 .= 4

CalculateSum( ) . Prin ( ) "<end> " prin ( ) end method end class

# #

Extension Clause

Description

The extension clause describes whether a class may be directly instantiated or may be extended.

An abstract class higher in the hierarchy may be a template for subclasses, and as such be a general description.

Further down the hierarchy, concrete classes are capable of being instantiated but also of being extended by child classes.

Leaves may be final classes that can be instantiated, but are no longer capable of being inherited by child classes.

Syntax extension

{ abstract | concrete | final }

Important Information

■ The extension clause is optional;

■ The default is concrete;

■ The extension keywords have the following meanings:

Abstract Objects cannot be created of this class, the class must be inherited and extended by subclasses. Abstract classes may contain abstract, concrete or final methods;

Concrete Objects can be created of this class (instantiation), but they can also be inherited and extended by other classes. Concrete classes must not contain abstract methods;

Final These classes cannot be inherited from, they can only be 70A 24

Language Reference Manual Draft Company Confidential instantiated. Final classes must not contain abstract methods.

Some Examples

In the following example there are three classes. The first class is abstract and cannot be instantiated. The second class inherits from the first and may be instantiated and may be extended. The third class inherits from the second, may be instantiated but may not be extended.

# #

# file /examples/clas_extensιonl sb # # # class cClassExtensionExamplel description

"Example of class extension clause" library examples inherits object extension abstract end class

# #

# _#

# file /examples/clas_extensιon2. sb # # # class cClassExtensιonExample2 description

"Example of class extension clause" library examples « inherits cClassExtensionExamplel extension concrete attributes aValuel integer = 1, aValue2 integer = 2 method start begin

"Class extension example" print () aValuel print ( ) aValue2 print ( )

'<end>" print ( ) end method end class

# #

# _#

# file /examples/clas_extensιon3 sb # 70A 25

Language Reference Manual Draft Company Confidential

H _# class cClassExtensιonExample3 description

"Example of class extension clause" library examples inherits cClas ExtensιonExample2 extension final method start begin

"Class extension example" .print ( )

(aValuel | ", " |aValue2) . prin () "<end> " print ( ) end method end class

# #

Exposure Clause

Description

The exposure clause defines those classes that may send messages to the current class.

Syntax exposure

NAMECLASS ,

Important Information

^■ The exposure clause is optional;

^■ By default, objects of any class may send messages to the current class;

If the exposure clause is used, only those classes listed may then send messages to the objects of the current class;

^■ Exposure is checked at compile time, and violation results in a compilation error

Some Examples

In the following example there are two classes. The first class, cClassExposureExamplel, uses an exposure clause to define that only the second class may use it. The second class instantiates the first and sends the message SayHelloQ to it.

No class other than cClassExposureExample2 may make calls to cClassExposureExamplel .

# ft file /examples/clas_exposurel sb #

# _# class cClassExposureExamplel 70A 26

Language Reference Manual Draft Company Confidential

description

"Example of class exposure clause" library examples inherits object extension concrete exposure cClassExposureExample2 method SayHello begin

"Hello" .Print ( ) end method end class

# _#

# file: .. /examρles/clas_exposure2. sb #

_{# #} class cClassExposureExample2 description

"Example of class exposure clause" library examples inherits ob ect extension concrete method start begin

"Class exposure example" print ( ) construc (cClassExposureExamplel) . SayHello ( ) "<end>" .prin ( ) end method end class

_{# #}

Options Clause

Description

The options clause allows a class to be set to obsolete. An obsolete class may still be used, but generates a warning. Its purpose is to allow for code evolution.

Syntax options 70A 27

Language Reference Manual Draft Company Confidential

[ obsolete ]

Important Information

The options clause is optional;

The default is null;

The option keyword has the following meaning :

Obsolete The class is obsolete. Usage of the class will generate a compiler 'warning'. It has no other side effects.

Some Examples

In the following example the first class is marked obsolete. The second class inherits from it. The compiler produces a warning at compile time. ft ft

# file: .. /examples/clas_options . sb # ft # class cClassOptionsExamplel description

"Example of class options clause" library examples inherits object extension abstract options obsolete end class

# _{r #} ft ft

# file: .. /examples/clas_options2. sb # _{# #} class cClassOptionsExample2 description

"Example of class options clause" library examples inherits cClassOptionsExamplel extension concrete method start begi n

"Class options example" . rint ( )

" <end>" .prin ( ) end method 70A 28

Language Reference Manual Draft Company Confidential

end c lass #

Constants Clause

Description

The constants clause defines a list of constants.

Syntax constants

{ NAME l i era 1 } ,

Important Information

The constants clause is optional;

A constant is a named literal;

Each constant has the value and type of the literal supplied;

A constant is used in a program script instead of literal values;

It is not a variable - it cannot be the target of an assignment statement;

It may be used in any place where a literal is permitted;

Constants are inherited by (and may be used within) sub-classes.

Some Examples

In the following example there are two constants named INITIALl and INITIAL2.

The first is an integer literal of value 3, the second a string literal of value 'Three'.

The literals are used to initialize the two attributes aValuel and aValue2. # #

# f i le /examples/clas_cons tants sb # ft # class cClassConstantsExample description

" Example of c lass constants clause " l ibrary examples inheri ts obj ec t constants

INITIALl 3, INITIAL2 "Three" attributes aValuel integer = INITIALl, aValue2 string = 1NITIAL2 method start begin

"Class constants example" print ( ) aValuel prin ( ) aVa lue2 prin ( ) 70A 29

Language Reference Manual Draft Company Confidential

'-.end> " print ( ) end method end class ft_-_ -_ -.

Attributes Clause

Description

The attributes clause lists the attributes (or variables) that may be used within a class

Syntax attributes

{ NAMΓ NAMECLAΞS [ expression } , . .

Important Information

The attributes clause is optional;

The attributes clause declares a set of instance-level variables that are the contents of the object;

An attribute name must not duplicate the name of a class already in the library;

An attribute name must not duplicate the name of a method already in the ancestry of the class;

The type of the attribute is defined by the class name appearing after it;

By default, when the object is instantiated all attributes are initialized to null;

The programmer may explicitly initialize each attribute in the attributes clause by supplying an expression;

The expression is evaluated when the object is instantiated and before any OnConstruct jnethods are run.

Some Examples

In the following example there are two integer attributes - aValuel and aValue2.

They are initialized to 1 and 2 respectively.

I ft file /examples/clas_attπbutes sb class cClassAttributesExample description

"Example of class attributes clause' library e ■ amples mliei i ts obj ec t atti ibu es aValuel integer = 1, aVd¹ JC integer = 2 70A 30

Language Reference Manual Draft Company Confidential method start begin

"Class attributes example" . rint ( ) aValuel .prin ( ) aValue2 print ( )

"<end>" .print ( ) end method end class

# ft

Depends Clause

Description

The depends clause lists at class level the pre-conditions of attributes to detect invalid states prior to the execution of public methods.

Syntax depends

{ NAME expressi on ) , . .

Important Information

^■ The depends clause is optional;

^■ The depends clause lists a set of pre-conditions that verify the state of the object before execution of any public method;

^■ Each condition is a named expression;

^■ Expressions are evaluated in the order in which they appear;

^■ Evaluation stops on the first expression not true;

■ If an expression evaluates to not true an exception is raised using the name of the expression.

Some Examples '

In the following example there are two named expressions (GOODl and GOOD2) that verify the attributes aValuel and aValue2 respectively. The start method sets aValuel to an invalid value that will be detected by the depends clause when the object receives the PπntValues message. As a consequence the PrintValues method is not run.

Contrast this with an ensures clause. With depends clauses invalid states are detected prior to the execution of public methods, while with ensures clauses invalid states are detected after the execution of public methods.

# #

# file .. /examples/clas_depends . sb # ft # class cClassDependsExample description

"Example of class depends clause"

examples

ob ect 70A 31

Language Reference Manual Draft Company Confidential

atrnbutes aValuel integer = 1, aValue2 integer = 2 depends

GOODl aValuel > 1, GOOD2 aValue2 > 1 method start begin

'Class depends example" print ( )

"This will cause an exception" print ( ) aValuel ^•= -1

PrintValues ( ) end method method PrintValues begin

(aValuel | " , " | aValue2) Print ( ) end method end class

#

Ensures Clause

Description

The ensures clause lists at class level the post-conditions of attributes to detect invalid states after the execution of public methods.

Syntax ensures

{ NAME expression } ,

Important Information

The ensures clause is optional;

The ensures clause lists a set of post-conditions that verify the state of the object;

The conditions validate the boundaries of the object after the object is constructed and after each public method;

Each condition is a named expression;

Expressions are evaluated in the order in which they appear;

Evaluation stops on the first expression not true;

An error message refers to the name of the expression

Some Examples n the following example there are two named expressions (GOODl and GOOD2) hat validate the attributes aValuel and aValue2 respectively. The 'start' method deliberately sets aValuel to an invalid state, so that it will be detected by the ensures clause after the object executes the PrintValues method. 70A 32

Language Reference Manual Draft Company Confidential

Contrast this with a depends clause. The depends clauses detects invalid states before execution of public methods, while the ensures clause detects invalid states resulting from execution of public methods.

# tt

# file- . /examples/clas_ensures . sb # # ft class cClassEnsuresExample description

"Example of class ensures clause" library examples inherits object attributes aValuel integer := 1, aValue2 integer := 2 ensures

GOODl aValuel > 1, GOOD2 aValue2 > 1 method start begin

"Class depends example" .prin ( )

"This will cause an exception" .prin ( ) aValuel := -1

PrintValues ( ) end method method PrintValues exposure private begin

(aValuel | "_¥ " \ aValue2 ). Prin ( ) end method end class

_# ft

Security Clause

Description

The security clause lists security conditions to be applied at instance level.

Syntax security expression , . .

Important Information

■ The security clause is optional;

• The security clause lists a set of expressions designed to check the authority of a task to access the object; 70A 33

Language Reference Manual Draft Company Confidential

Whenever a task attempts to execute a public method of any instance of the class, these expressions are evaluated in the listed order;

^■ The object resulting from each such evaluation is a key that must be present in the task's key ring;

If the key ring has the appropriate keys, the task executes the method;

• If not, bullαnt raises an exception with the name 'SBX_SECURITY_VIOLATION'.

Some Examples

In the following example the class uses itself as the security key.

# ft

# file . /examples/clas_securιty . sb # # _# class cClassSecurityExample description

"Example of class security clause" library examples inherits object security cClassSecurityExample method start begin

"Class security example" .prin ( )

"<end>" .print ( ) end method end class , ft ft

Method Clause

Description

A method is a named set of actions to be taken by an object when that method is invoked by a message.

Syntax method NAME description ] help ] extension ] exposure ] options ] parameters ] depends ] returns ] ensures ] security ] local ] 70A 34

Language Reference Manual Draft Company Confidential

[ begin | driver ] end method

Important Information

The method clause is optional;

The clauses used must appear in the order listed above;

There may be any number of methods in a class;

The name of the method may not be a reserved word or the name of a class from the same library;

The method clause is delimited by the keyword phrases method NAME and end method.

Some Examples

In the following example the method shown is very simple. It is presented to show the basic structure of a method. ft ft

# file: .. /examples/mthd_method. sb #

# _# class cMethodExample library examples inherits object method start begin

"Hello Universe! ". Print ( ) end method end class

# #

70A 35

Language Reference Manual Draft Company Confidential

Methods

Methods are the containers for actions that are executed by an object when it receives a message Each object contains methods defined by its class and classes it has inherited from. A method is delimited by the keyword phrases method NAME and end method.

This topic describes the syntax of methods. Click on the table below to go to a particular clause. The method clause description formally describes the syntax of a method

Description Clause

Description

The description clause records a comment that describes a method.

Syntax description

LITLRΛLSTRING

Important Information

It is optional and has no side effects;

The default is null;

The description is primarily for annotation;

The description clause records a comment about the method in the meta data ;

The comment should describe the purpose or function of the method 70A 36

Language Reference Manual Draft Company Confidential

Some Examples

In the following example there is a description clause showing how such a clause is used .

# _#

# f i le : . . / examples /mthd_descript ion . sb # # ft class c ethodDescriptionExample l ibrary examples inheri ts obj ect method start description

" A method to demonstrate the use of the description clause " begin

" Hel lo Universe ! " . Print ( ) end method end c lass ft #

Help Clause

Description

The help clause records a reference to text that provides help on the method.

Syntax help

L ΠΈRALSTRING

Important Information

^« It is optional and has no side effects;

The default is null; ^■ The help reference is held along with the class in the system meta data;

The help reference is primarily for annotation and is used by the bullαnt tool set.

Some Examples

In the following example the help clause refers to some help text on the method. tt #

# file- .. /examples/mthd_help. sb # ft ft class cMethodHelpExample description

"Example of method help clause"

1 brary examples 70A 37

Language Reference Manual Draft Company Confidential obj ec t method start description

"This is the method description text" help

" ReferenceManual/MethodHelp" begin

"Method description example" print ( )

#

# method body would go here

#

"<end>" print ( ) end method end class ft #

Extension Clause

Description

The extension clause provides the mechanism to control the implementation of a method .

Syntax extension

{ abstract | concrete | final }

Important Information

- The extension clause is optional; ^■ The default extension is concrete;

• The extension keywords have the following meanings: abstract Tjie method is a prototype and cannot be invoked directly. It is expected to be overridden in a child class. It must not contain any implementation code and hence must not have a begin or driver clause; concrete The method has implementation code but may be overridden in a child class. It must contain either a begin or driver clause; final The method has implementation code that may not be overridden It must contain either a begin or driver clause.

Some Examples

In the following example the start method has an extension of final. A class that inherited this class could not override the start method ft #

# file /examples/mthd_extensιon sb # ft # class cMethodExtensionExample library examples inherits 70A 38

Language Reference Manual Draft Company Confidential obj ec t method start extension final begin

"Method extension example" .print ( )

" <end> " .print ( ) end method end class

#

Exposure Clause

Description

The exposure clause defines which classes may use the method.

Syntax exposure

{ hidden | private | public | NAMEC ASS , . . }

Important Information

■ The exposure clause is optional;

■ The default exposure is public;

^■ The exposure clause provides the mechanism to control the access to a method;

^■ The exposure keywords have the following meanings within a method : hidden The method cannot be seen by a child class or a client; private The method can be seen by a child class but cannot be seen by a client; public The method can be seen by a child class or a client;

^■ If classes are explicitly listed then only those classes listed may access the method;

^« Exposure is checked at compile time, and violation results in a compilation error.

Some Examples

In the following example the start method is public. It may be called from any other class. tf tt

# f i le : . . / examples /mthd_exposure . sb # ft # c la ss cMethodExposureExample

L ibr ary examples inher s ob ec t 70A 39

Language Reference Manual Draft Company Confidential method start exposure public beg J n

"Method usage exeimple" .print()

» ft method body otild go here α

" <end> " . print ι 0 end method end class

#

Options Clause

Description

The options clause specifies additional options about the method.

Syntax options

{ glyph I immutable | mutable | obsolete }

Important Information

^■ The options clause is optional;

■ The default is mutable;

■ Multiple options can be specified, with the restriction that mutable and immutable cannot both be specified;

■ The options keywords have the following meanings: glyph The method may be presented graphically; immutable The method will not change instance attributes; mutable The method may change instance attributes; obsolete Methods marked obsolete should not be used by new methods. A warning is raised at compile time if used. The purpose of obsolete is to allow code evolution so that old methods can be phased out in favor of new methods.

Some Examples

In the following example the start method is marked obsolete. Code that relies on this method will compile but will give a warning. tf tt

# file: .. /examples/mthd_options . sb ft class cMethodOptionsExample library examples inherits object method start 70A 40

Language Reference Manual Draft Company Confidential options obsolete begin

"Method usage exampj ,e" . print ( )

#

# method body would go here

#

"<end>" .print ( ) end method end class

#-

Parameters Clause

Description

The parameters clause declares the list of arguments accepted by a method.

Syntax parameters

{ { NAME NAMECLASΞ } none )

Important Information

■ Parameters are optional;

■ The default is none;

■ All parameters are passed by handle reference;

■ The actual parameter at runtime may be a sub-class of the declared class.

Some Examples

In the following example the method SetValues accepts two parameters - pValuel and pValue2, both integers. When the start method sends a message to

SetValues, it passes the parameters 3 and 4. ft ft

# file: .. /examples/mthd_parameters . sb #

# # class cMethodParametersExample library examples inherits object

attributes aValuel integer, aValue2 integer method start begin

"Method parameters example" .print ( )

SetValues (3,4) aValuel . print ( ) aValue2.print ( )

" <cnd> " print ( ) 70A 41

Language Reference Manual Draft Company Confidential end method method SetValues parameters pValuel integer pValue2 integer begin aValuel = pValuel aValue2 = pValue2 end method end class

#

Depends Clause

Description

The depends clause declares a list of pre-condition that must be satisfied before a method can be run.

Syntax depends

{ NAME expression } , . .

Important Information

The depends clause is optional;

The depends clause lists the set of conditions that must be true before the method accepts the message;

Each condition is a named expression;

The expressions are evaluated in the order they appear;

Evaluation stops on the first expression that does not evaluate to true;

In which case an exception is raised using the name of the expression as the name of the exception;

A depends failure means that the method does not accept the message on the basis that the initial conditions are not satisfactory.

Some Examples

In the following example the SetValues method has two propositions in its depends clause - GOODl and GOOD2. Both these propositions are evaluated before the method body is run. The first time the method is invoke the parameters satisfy the constraints. The second time the method is invoked the first constraint fails first and the exception GOODl is raised, the code following does not run and the second message does not print

# -

# file /examples /mthd_depends sb ft ___ class cMethodDependsExample

1 ibrary e> ampl s inh t l s OD ect 70A 42

Language Reference Manual Draft Company Confidential

a tributes aValuel integer, aVa]ue2 integer method start begin

"Method depends example" print ( )

"This message succeeds" .print ( )

SetCoord(3,4)

"This message fails" print ( )

SetCoord(-l, -1)

"<end>" print ( ) end method method SetCoord parameters pValuel integer, pValue2 integer depends

Goodl pValuel > 0, Good2 pValue2 > 0 begin aValuel := pValuel aValue2 : = pValue2 end method end class

_{# #}

Returns Clause

Description

The returns clause defines the return type of a method.

Syntax returns

{ NAME NAMECLAΞΞ [ ( TYPE [ , TYPE , . . ] ) ] | none }

Important Information

■ The returns clause is optional;

■ The default is none;

^■ The returns clause defines the class of the value to be returned by the method;

^■ The returns clause also defines a local returns variable; The returns variable is assigned by a return statement;

■ It can be used anywhere within the body of a method;

^■ If the method does not return a value, none or default should be specified. 70A 43

Language Reference Manual Draft Company Confidential

Some Examples

In the following example the returns clause defines that the method

CalculateSum returns an integer value.

# _ ft

# file: .. /examples/mthd_returns. sb #

# _# class cMethodReturnsExample library examples inherits object method start begin

"Method returns example" .print ( )

CalculateSum(3 , 4) . prin ()

"<end>" .print ( ) end method method CalculateSum parameters pValuel integer, pValue2 integer returns rResult integer begin return pValuel + pValue2 end method end class

# _#

Ensures Clause

Description

The ensures clause declares a list of post-conditions that should be satisfied when a method returns.

Syntax ensures

{ NAME expression ) , .

Important Information

The ensures clause is optional;

The ensures clause lists the set of conditions that should be true after the method has executed;

Each condition is a named expression;

The expressions are evaluated in the order they appear;

Evaluation stops on the first expression that does not evaluate to true;

In which case an exception is raised using the name of the expression as the name of the exception. 70A 44

Language Reference Manual Draft Company Confidential

Some Examples

In the following example the CalculateSum method has an ensures clause that verifies that the returned value is the sum of the two parameters. In the example there is a deliberate coding error - the sum will be incorrect. As a consequence an exception by the name good result will be raised.

# #

# file / examples/mthd_ensures sb # ft _# class cMethodEnsuresExample library examples inherits object method start begin

"Method ensures example" prin ( )

CalculateSum(3, 4) print ( )

"<end> " print ( ) end method method CalculateSum parameters pValuel integer, ρValue2 integer returns rResult integer ensures

GOOD_RESULT rResult == pValuel + pValue2 begin return pValuel + 2 # deliberate mistake; 2 should be pValue2 end method end class ft _. ft

Security Clause

Description

The security clause lists the security requirements of a method.

Syntax security expression .

Important Information

• The security clause is optional;

■ The security clause lists a set of expressions that assert the validity of the task to execute the method;

■ The expressions are evaluated in the order they appear each time any task attempts to execute the method;

The resulting object of each expression represents a key that must be in the tasks key ring , 70A 45

Language Reference Manual Draft Company Confidential

^■ If the task has all the required keys, it proceeds to execute the method;

^■ If the task does not have all the required keys the exception SBX_SECURITY_VIOLATION is raised;

^■ Keys may only be placed on a task's key ring by the Security Manager System.

Some Examples

In the following example the start method requires the handle of the class be on the tasks key ring. The task won't have this security key so the exception

SBX_SECURITY_VIOLATION will be raised. tt ft

# file /examples/mthd_securιty . sb #

# # class cMethodSecurityExample library examples inherits object method start security cMethodSecurityExample begin

"Method security example" .print ( )

"<end>" .print ( ) end method end class

# #

Locals Clause t

Description

The locals clause declares a list of variables that are local to the method.

Syntax

Locals

{ NAME NAMECLASS [ ^• = expression ] } . . .

Important Information

The locals clause is optional;

Local variables are only in scope during the method invocation, and are only available to that method;

Local variables are initialized before the method begins to execute;

By default locals are initialized to null;

The programmer may explicitly initialize each local in the locals clause by supplying an expression 70A 46

Language Reference Manual Draft Company Confidential

Some Examples

In the following example the start method has two locals variables IValuel and

IValue2. They are both integers and are initialized to 3 and 4 respectively. # _#

# file- .. /examples/mthd_locals . sb # # ft class cMethodLocalsExample library examples inherits object method start begin locals

IValuel integer := 3, lValue2 integer .= 4

"Locals clause example" .print ( ) (IValuel + lValue2 ). Print ( ) "<end>" .print ( ) end method end class

# #

Begin Clause

Description

The begin clause marks the beginning of a method's implementation code.

Syntax begin ,

[ statements ] [ traps ]

Important Information

The begin clause marks the commencement of the method implementation;

Locals and statements may appear after the begin;

A begin clause (or driver) is mandatory for concrete or final methods;

Abstract methods must not have a begin clause;

Methods must not contain both a begin clause and a driver clause.

Some Examples

In the following example the start method has a begin clause followed by some message statements. ft tt

# file- .. /examples/mthd_begιn . sb # # _# class cMethodBeginExample 70A 47

Language Reference Manual Draft Company Confidential library examples inherits ob ect method start begin

"Method begin example" .print ( ) "Hello Universe !". Prin ( ) "<end>" .print ( ) end method end class ft

Driver Clause

Description

The driver clause defines the method implementation as C/C++ code.

Syntax driver

LITERALSTRING_L function

LITERALSTRINGC

Important Information

• The driver clause nominates a C/C++ DLL function that implements the body of the method;

LITERALSTRINGL names the DLL library where the function is to be found. LITERALΞTRINGF names the function;

^■ The dispatch to functions that conform to the bullαnt driver call format are slightly faster; •

^■ A driver clause (or begin) is mandatory for concrete or final classes;

^■ Abstract methods may not have a driver clause.

Some Examples

In the following example the start method is a driver is a function named

VourFunction' in a DLL named 'yourDLL'. ft _#

# file: .. /examples/mthd_driver .sb # ft ft class cMethodDriverExample library examples i nheri ts object method start dri e

" yout DLL" 70A 48

Language Reference Manual Draft Company Confidential function

"yourFunction" end method end class

# 1,

70A 49

Language Reference Manual Draft Company Confidential

Statement

A valid statement is an executable language instruction to carry out a process and forms part of a bullαnt class or method. Statements are separated by white space.

This topic describes the syntax of statements. Click on the table below to go to a particular clause.

Statement Short Description assert Verifies a list of logical propositions assignment Deposits the result of an expression into a variable case Executes a nested group of statements by comparing a list of expressions continue Forces the next iteration of a loop debug Defines a group of statements used for debugging for A looping mechanism that provides explicit initialization, increment and termination if Executes a nested group of statements by testing a linear sequence of expressions label Names a point in program source leave Forces termination of a loop lock Defines an exclusive usage unit message Sends a message to an object raise Forces an exception condition retry Restores normal processing after an exception return Passes execution control back to the calling method rollback Cancels and leaves a transaction unit transaction Defines a transaction unit trap Defines a statement group to deal with an exception until A looping mechanism with loop control at the end of the cycle while A looping mechanism with loop control at the beginning of the cycle

Assert Statement

Description

The assert statement checks a list of logical expressions. It can assist in proving the correctness of a program and is useful as a debugging aid.

Syntax assert

{ NAME expressi on ) 70A 50

Language Reference Manual Draft Company Confidential

Processing

1. Expressions are evaluated in the order in which they are listed;

2. If all expressions evaluate to true then processing continues with the statement following assert;

3. If an expression is not true, processing stops;

4. Execution jumps to the nearest appropriate trap using the NAME of the expression as the exception name, with the default severity.

Important Information

Each expression must yield a Boolean value (equal to, not equal to, etc.); There must be at least one logical expression.

Some Examples

In the following example there are two expressions in the assert statement - named "LogicalConsistency" and "Logicallnconsistency" . The first expression is correct while the second is incorrect An exception by the name "Logicallnconsistency" occurs with a severity of error by default. # ft

# file- .. /examples/stmt_assert . sb #

# _# class cStatementAssertExample description

"Example of assert statement" library examples inherits object method start begin '

"Assert statement example" print ( ) assert

LogicalConsistency

1 '= 2, Logicallnconsistency 1 == 2 "<end>" .print ( ) end method end class

# ft

Assignment Statement

Description

Assignment evaluates an expression and inserts the result into a variable.

Syntax

NAMΓVARIABL E = expression 70A 51

Language Reference Manual Draft Company Confidential

Processing

1 The expression is evaluated;

2 The result of the expression is inserted into the named variable.

Important Information

^■ The named variable may be an attribute, parameter, local or returns variable,

The type resulting from the expression must match the type of the variable, but may be of a sub-class type.

Some Examples

In the following example there are two attributes - named 'aValuel' and ^laValue2'. Firstly, the attribute aValuel is assigned the integer value 3. Then the attribute aValue2 is assigned the value aValuel plus 1 (which would be 4). tt #

# f i le /examples/stmt_assιgnmen . sb #

# # class cStatementAssignmentExample description

"Example of assignment statement" library exam les inherits ob ect attributes aValuel integer , aValue2 integer method start begin <

"Assignment statement example" . prin ( ) aValuel = 3 aValue2 = aValuel + 1 '<end> " print ( ) end method end class ft #

Case Statement

Description

The case branching statement selects one of a group of statements to execute by comparing a list of expressions.

Syntax case expression,, [ when expression,, statements_! ] [ when other 70A 52

Language Reference Manual Draft Company Confidential statements₂ ] end case

Processing

The case expression is evaluated;

1 Each when expression in the list is then compared against the result of case;

2 As soon as a when expression equals the case expression SoftBlocks executes the group of statements immediately following;

3. No further when expressions are evaluated and execution continues with statements after end case;

4. If no when expression matches the case expression, bullαnt executes the statements following the when other clause, if there is one;

5. Processing continues with any statements after end case;

6. Only one nested group of statements is ever executed.

Important Information

^■ There may be any number of when expression clauses;

^■ There may be only one when other clause;

^■ There may be any number of statements nested inside each when clause;

Some Examples

The example shows a local integer variable ICount with an initial value of 1. The step statement adds 1 to this value. The case statement then uses the modulus operator to check whether the remainder will be 0, 1 or other when

ICount is divided by 3. The case statement evaluates the remainder and selects one of the nested print statements accordingly.

# _#

# file /examples/stmt_case sb #

# !. # class cStatementCaseExample description

"Example of case statement" library examples inherits object method start begin locals

ICount integer

"Case statement example" print ( ) for ICount = 1 step ICount = ICount + 1 test ICount <= 10 case ICount % 3 when 0

"remainder is 0' print ( ) 70A 53

Language Reference Manual Draft Company Confidential when 1

"remainder is 1' print ( ) when other

"remainder is something else" print ( ) end case end for

"<end>" print ( ) end method end class

#__- ft

Continue Statement

Description

The continue statement makes bullαnt repeat a loop until a control condition is satisfied.

Syntax continue { for | until | while | NAMΓLABEL }

Processing

1. The continue statement forces execution to ump to the controlling statement of a loop for the next iteration;

2. Whether or not the next repetition of the loop actually occurs depends on this controlling statement;

3 Statements that appear between the continue statement and the end of the loop are not executed.

Important Information

^■ Continue may be used only inside a loop - with a for, until or while statement;

^■ A label may be used to continue a named outer loop - the label must refer to a loop that contains the continue statement, although the continue statement may be nested;

■ If used, the label must appear immediately before a for, until or while statement.

Some Examples

The example shows a local integer variable 'ICount' with an initial value of 1. The step statement adds 1 to this value. The if statement then uses the modulus operator to check whether the remainder will be 0 or 1 when ICount is divided by 2

If the remainder is 0 (that is, the condition is true) then continue is executed next and sends control back to the for statement, to add 1 to ICount again

On checking the remainder again, the if statement now finds the value of ICount is 1 (that is, the condition is false): continue is therefore not executed bullαnt terminates the test, prints the message and ends both method and class ff __ _ ff

# f i le /examp les/stmt_contιnue sb ft 70A 54

Language Reference Manual Draft Company Confidential ft tt class cStatementContmueExample description

"Example of continue statement" library examples inherits object method start begin locals

ICount integer

"Continue statement example" .print ( ) for ICount : = 1 step ICount := ICount + 1 test ICount <= 10 if ICount % 2 == 0 continue for end if

"ICount is odd". rint () end for

"<end>" .print ( ) end method end class

_{# #}

Debug Statement

Description

The debug statement groups a set of statements used for debugging.

Syntax debug statements end debug

Processing

1. If debugging is on (either for one task or for all tasks) the nested group of statements is executed;

2. If debugging is off, the nested group of statements is not executed.

Important Information

For a single task, Task.SetDebug({ true | false } ) sets debugging on or off;

For all tasks, Peer.SetDebug( { true | false > ) sets debugging on or off;

Any number of statements may be nested within a debug .. end debug statement;

^■ Debug statements themselves may not be nested; 70A 55

Language Reference Manual Draft Company Confidential

^■ The retry statement cannot retry to a label within a debug .. end debug statement.

Some Examples

In the following example there are two debug .. end debug statements. The print statement inside the first is not executed, as task debugging is explicitly turned off by Task.SetDebug(False). When task debugging is explicitly turned on again by Task.SetDebug(True), bullαnt executes the statements inside the second debug.

# _#

# file- .. /examples/stmt_debug. sb #

# _# class cStatementDebugExample description

"Example of debug statement" library examples inherits object method start begin "debug statement example" .print ( )

Task. SetDebug (False) debug

"This text wont appear". Print ( ) end debug

Task SetDebug (True) debug

"this text does appear". Print ( )

Host . GetDatetime ( ) . Print ( ) end debug

Task SetDebug (False)

"<end>" .print ( ) end method end class ft #

For Statement

Description

The for statement sets up a processing loop in a single statement. This statement contains expressions for initializing (for), incrementing (step), testing (test) and terminating (end for) the loop.

Syntax for stalementS_f 70A 56

Language Reference Manual Draft Company Confidential step statements,; test expressιon_c statementSn end for

Processing

1. The for initialization statement (statements_f ) is executed once;

2. The test expression (expression^ is evaluated;

3 If the test is true, the nested statements (statements,,) are executed; processing moves to the step statements (statements^);

4. If the step statements (statements_s) are executed, the test is re- evaluated and the cycle repeated;

5. If the test is false, whether on the first or subsequent evaluations, execution then moves to any statement following end for.

Important Information

The for statement group may contain zero or more statements;

The step statement group may contain zero or more statements;

The nested statement group may contain zero or more statements;

The test must evaluate to a Boolean expression;

The nested statements may include a continue statement to force the next iteration of the loop;

The nested statements may include a leave statement to terminate the loop early.

Some Examples

In the following example there is a local variable named 'ICount'. The for statement initializes the value of ICount to 1. Step increments the value of ICount by 1. bullαnt repeatedly prints the value of ICount as long as it does not exceed 10. ft

# f ile /examples/ stmt_f or sb ft class cStatementForExample description

"Example of for statement" library examples inherits object method start begin locals

ICount integer

"For statement example" print ( ) for ICount = 1 step ICount = ICount + 1 70A 57

Language Reference Manual Draft Company Confidential test ICount <= 10

ICount print () end for

"<end>" .print ( ) end method end class #

If Statement

Description

The if branching statement determines whether to execute a nested group of statements based on the evaluation of an expression. Using elif, a series of these statements can be daisy-chained.

Syntax if expression_! statements_! [ elif expressιon_e statements₂ ] . . . [ else statements₃ ] end if

Processing

1. The if expression (expression^ is evaluated first, followed by each elif (expression^ in sequential order, until one is found that is true;

2. bullαnt then executes the nested group of statements immediately following;

3. If none of the expressions is true, bullαnt executes the nested group of statements following the (optional) else clause;

4. Execution continues with any statements following the end if;

5. Only one nested group of statements is ever executed.

Important Information

■ The test must evaluate to a Boolean expression;

- There may be any number of statements in each nested group.

Some Examples

In the following example there is a local variable named 'ICount'. The for statement iterates the value in ICount from 1 to 10. The if statement uses the modulus operator (%)to generate a remainder of either 0 or 1.

If the remainder is 0 the continue statement is executed and control jumps back to the for statement, missing the print message.

If the remainder is 1 the continue statement is not executed and control executes the print message.

#

# file . /examples/stmt_ιf . sb # class cStatementlfExample 70A 58

Language Reference Manual Draft Company Confidential

description

"Example of if statement" library examples mheri ts object method start begi n locals

ICount integer

"If statement example" .print ( for ICount : = 1 step ICount := ICount + 1 test ICount <= 10 if ICount % 2 == 0 continue for end if

"ICount is odd". print () end for

"<end>" print ( ) end method end class

#

Label Statement

Description

The label statement names a statement in the program source.

Syntax label NAME

Processing

A label is not executable and has no side effects.

Important Information

Labels are referenced by continue, leave and retry statements.

Some Examples

In the following example there are two local variables - 'ICountl' and 'ICount2', both integers. The first for statement iterates the value in ICount from 1 to 10. The nested for statement iterates ICount2 from 1 to 10 for each value of ICountl.

The if statement detects when ICount 1 is 3 and ICount2 is 8. At this point bullαnt executes the leave statement. Processing continues after the outer end for.

# tf

# f i le - / examples / stmt_label . sb #

# tf 70A 59

Language Reference Manual Draft Company Confidential class cStatementLabelExample description

"Example of label statement" library examples inherits object method start begin locals

ICountl integer, lCount2 integer

"Label statement example" .print ( label OuterLoop for ICountl := 1 step ICountl := ICountl + 1 test ICountl <= 10 for lCount2 := 1 step lCount2 := lCount2 + 1 test lCount2 <= 10 if ICountl == 3 and lCount2 = = 8 leave OuterLoop end if lCount2.prin ( ) end for end for

"<end>" .print ( ) end method end class ft

Leave Statement

Description

The leave statement forces termination of a loop. Syntax leave { for | until | while | NAMELABEL }

Processing

Processing jumps to any statements following the end of the loop.

Important Information

A leave statement may only be used inside a loop - a for, until or while statement;

^■ A leave for, until or while statement leaves the current loop of that kind;

^■ A la bel may be used to leave a named outer loop - the label must refer to a loop that contains the leave statement, although the leave statement may be nested ; 70A 60

Language Reference Manual Draft Company Confidential

* If used, a label must appear immediately before a for, until or while statement

Some Examples

This example uses leave to a label.

There are two local variables - 'ICountl' and 'ICount2', both integers. The first for statement iterates the value in ICount from 1 to 10. The nested for statement iterates ICount2 from 1 to 10 for each value of ICountl .

# ft

# file /examples/stmt_leave. sb # # _# class cStatementLeaveExample description

"Example of leave statement" library examples inherits object method start begin locals

ICountl integer, lCount2 integer

"Label statement example" .print ( ) label OuterLoop for ICountl := 1 step ICount]- := ICountl + 1 test ICountl <= 10 for lCount2 •= 1 step lCount2 := lCount2 + 1 test lCount2 <= 10 if ICountl == 3 and lCount2 == 8 leave OuterLoop end if lCount2 print ( ) end for end for

"<end>" print ( ) end method end class ft ft

Lock Statement

Description

The lock statement is used to gain exclusive access to a shared object. 70A 61

Language Reference Manual Draft Company Confidential

Syntax lock expression statements end lock

Processing

1. The expression is evaluated first;

2. On the result of the expression an exclusive-use lock is taken;

3. The nested statements are executed;

4. At end lock, the exclusive-use lock is dropped;

5. Processing continues with the statements after end lock;

6. Should an exception occur within the nested statements, the lock is dropped and processing moves to an appropriate exception handler.

Important Information

■ The expression must evaluate to an object that has been marked as shared via object. SetShared(true);

^■ A lock statement cannot be used inside a trap statement;

^« A lock placed on an object that is not shared will raise an exception.

Some Examples

In the following example there is an attribute named 'aCount'. The first step is to mark the object as shared. After that point any usage of the object must be within a lock.

As an example the lock statement sets the value of count to be 1. ft

# f ile : . . /examples/ stmt_lock . sb ft class cStatementLockExample description

"Example of lock statement" library examples inherits object attributes aCount integer method start begin

"Lock statement example" . print ( )

Self . SetShared ( rue) lock self aCount := 1 end lock

" <end> " . print ( ) end method end class 70A 62

Language Reference Manual Draft Company Confidential

Message Statement

Description

The message statement sends a message to an object.

Syntax

[ target ] METHODNAME. ( parameters ) [MET ODNAME (parameters) ] where target i s of the form

C \ self | ancestor ( [ NAMECLASS ] ) } and parameters i s of the form [ expressi oU_p, ]

Processing

1. The target object is ascertained by evaluating expressιon if specified;

2. If self or ancestor is specified, or no target is specified, the target is the current instance;

3. The parameter expressions are evaluated (if any) from left to right to give the parameters;

4. The METHODNAME and parameter types should form a unique signature for a particular method which is then executed in relation to the target object;

5. If the message results in an object, it may be the target for the next message.

Important Information

^■ The target is optional and the default is self;

^■ Unless specified by

(which may be an instance name or another message) the 'target is the current instance;

• If ancestor is specified, the target is still the current instance but the method to be used is found in a parent class, which may be specified (NAMECLASS) ;

^■ If the result of a message is an object, it may be the target for another message So, a message may take the form : target.method l (pl,..).method2(p2,..).method3(p3,..) . where (target. method l (pl,..)) becomes the new target for method2, and so on along the message.

Some Examples

In the following example, the object's start method sends two messages to the self instance, requesting the passed string be printed.

# _ _ ft

# file /examples/stmt_message sb ft ft ft class cS atementMessageExample desc ription

'Example oi a message statement

1 J brary 70A 63

Language Reference Manual Draft Company Confidential examples inherits object method start begin

"Message statement example" .print ( ) self PπntThis ( "Hello Universe¹")

PnntThis ( "Hello again")

"<end>" print ( ) end method method PnntThis parameters pStπng string begin pString print ( ) end method end class

# ft

Raise Statement

Description

The raise statement is used to force an exception condition.

Syntax raise { NAME | exρressιon_n }

[ severity { warning | error | fatal } ] [ reason

]

Processing

1. bullαnt first evaluates any name expression

to determine the name o'f the exception; otherwise it uses the supplied name;

2. The reason expression (expression,) , if any, is evaluated next;

3 If the level of severity is warning or error, processing jumps to the nearest available exception trap;

4. The nearest trap is the first one matching the exception (either by NAME or all) working back through the message sequence;

5 If the seventy-level is fatal the task is terminated,

6 In either event, no following statements are processed.

Important information

By convention, a warning exception is used to show that processing has ended successfully but the context of the processing is questionable;

An error exception is used to show that processing could not finish, but that recovery is possible;

^■ A fatal exception is used to show that processing could not finish and that no recovery is possible;

The default is error, 70A 64

Language Reference Manual Draft Company Confidential

The reason appears in the trace file, and the console if active.

Some examples

# #

# file: .. /examples/stmt_raιse . sb # # # class cStatementRaiseExample description

"Example of raise statement" library examples inherits object method start begin

"Raise statement example" .print ( ) raise ExampleProblem reason "Just an example"

"<end> " .print ( ) end method end class

# #

Retry Statement

Description

The retry statement restores normal processing after an exception.

Syntax retry NAMELABEL

Processing

1. The present exception condition is cancelled;

2. Processing resumes with the statement following the named label.

Important information

■ The retry statement may only be used inside a trap statement;

■ The named label cannot be nested inside a trap, debug, for, lock, transaction, until or while statement.

Some examples

In this example there is a raise statement that raises an exception by the name of ΕxampleProblem'. There is a trap designed to deal with this exception and retry just after the raise.

A second trap appears as an example of how to trap any other exception. tt tt

# f i le : . / examples/ stmt_retry . sb # t_{f f}t 70A 65

Language Reference Manual Draft Company Confidential class cStatemcntRetryExample description

"Example of retry statement" library examples inherits object method start begin

"Retry statement example" print ( ) raise ExampleProblem reason "Just an example" label RetryPoint

"Retried" print ( )

"<end>" print ( ) trap ExampleProblem

"Retrying after ExampleProblem" print ( ) retry RetryPoint end trap trap all

"Some other exception has occurred" prin ( ) end trap end method end class tf

Return Statement

Description

The return statement passes control back to the calling method, and may return a variable

Syntax return { expression none }

Processing

1. The expression, if any, is evaluated first;

2 The result is deposited into the returns variable of the method;

3 No following statements are processed;

4 Before returning, the ensures clause (if any) is executed to establish that the method has satisfied any post-conditions. The class ensures clause (if the method was public) is then executed to confirm that the method is leaving the object in a valid state,

5 Execution returns to the calling message. 70A 66

Language Reference Manual Draft Company Confidential

Important information

A return expression is mandatory if the method has a returns clause with a returns type other than none;

^■ A return statement cannot be used inside an exception trap or debug statement.

Some examples

In the following example the method CalculateSum calculates the sum of two parameters and returns the result. tt tt tt file. . /examples/stmt_return. sb #

# _# class cStatementReturnExample description

"Example of return statement" library examples inherits object method start begin

"Return statement example" .print ( )

CalculateSum(3 , 4) .print ()

"<end>" .print ( ) end method method CalculateSum parameters pValuel integer, pValue2 integer returns , rResult integer begin return pValuel + pValue2 end method end class

# #

Rollback Statement

Description

The rollback statement cancels and exits a transaction unit.

Syntax rollback transaction

Processing

1. All changes made to the persistent graph within the transaction unit are undone; 70A 67

Language Reference Manual Draft Company Confidential

2. Processing continues with any statements following the associated end transaction

Important Information

A rollback statement may only be used inside a transaction statement.

Some Examples

In the following example there is a transaction unit that attempts to set the persistent root. If the persistent root is currently null the root is set to this object, otherwise the transaction is rolled back.

# tt

# file /examples/stmt_rollback sb #

# _# class cStatementRollbackExample description

"Example of rollback statement" library examples inherits object method start begin

"Rollback statement example" . Prin ( ) transaction if Peer .GetPersistent ( ) is null

Peer .SetPersistent (Self) else rollback transaction "Won't see this print". Print ( ) end if end transaction "<end>" Print () end method end class ft ft

Transaction Statement

Description

The transaction statement defines a transaction unit. A transaction unit is a section of code that must all be executed before any actions take effect

Syntax transac tion statements end transac tion

Processing

1 A transaction unit is created;

2 The nested statements are executed; 70A 68

Language Reference Manual Draft Company Confidential

3 The transaction unit is committed .

Important Information

There may be any number of statements in the nested group;

Nested transactions are not currently supported;

A transaction statement may not be used inside a trap statement.

Some Examples

# #

# file /examples/stmt_transactιon. sb # # ft class cStatementCommenceExample description

"Example of transaction statement" library examples inherits object method start begin

"Transaction statement example" .print ( ) transaction f Peer GetPersisten ( ) is null

Peer SetPersistent (Self ) else rollback transaction "Won't see this print". Print ( ) end if end transaction "<end> " print ( ) end method end class ft ft

Trap Statement

Description

The trap statement defines a group of statements to deal with an exception.

Syntax

{ trap { NAMEEXCEPTION , | all } s ta emen ts end trap } 70A 69

Language Reference Manual Draft Company Confidential

Processing

1. If a method raises or receives an exception during normal execution, control shifts to the exception trap for that method;

2. If there is an exception trap of the same name as the exception specified in the raise statement, then the associated group of code is executed;

3. If there is no appropriately named exception trap the exception propagates to the calling method.

Important Information

^■ Exception traps appear at the end of a method;

^■ There must be only one unique exception trap for each named exception in any given method;

^■ A trap all will trap any exception, and should be placed after all other traps;

^■ There may be any number of statements in any of the nested groups.

Some Examples

In the following example the first two raises are trapped explicitly by name and retried. The third raise is trapped by a trap all and is not retried.

# _#

# file: .. /examples/stmt_trap. sb #

# tf class cStatementTrapExample description

"Example of trap statement" library examples inherits object method start begin

"Trap statement example" .prin ( ) raise SomeProblem label RetryPoint "Retried" print () raise AnotherProblem label RetryAgam raise DontTrap "<end> " print ( ) trap SomeProblem

"Some problem has occurred" prin ( ) retry RetryPoint end trap trap AnotherProblem

"Yet another problem" print ( ) 70A 70

Language Reference Manual Draft Company Confidential retry RetryAgam end trap trap all

"Some other exception" . print ( ) end trap end method end class

#

Until Statement

Description

The until statement is a looping statement with loop control at the end of the cycle.

Syntax until expression statements end until

Processing

1. The nested group of statements is executed first;

2. The until expression is evaluated;

3. If the expression evaluates to true the loop is terminated and processing continues with any statements following the end until;

4. Otherwise, the loop continues and the nested group of statements is executed until the expression becomes true;

5. The nested group of statements is always executed at least once. Important Inforpiation

■ There may be any number of nested statements;

^» A continue statement may be used in the nested statements to force the next iteration;

■ A leave statement may be used in the nested statements to force the loop to end.

Some Examples

In the following example the local variable 'ICount' is initialized to 10. The until statement iterates the loop until ICount becomes 0. The nested statements print the value of ICount, and decrement it by one for each iteration of the loop. tt tt

# file /examples/stmt_untιl . sb # tf ___# class cStatementUntilExample description

"Example of until statement" library examples 70A 71

Language Reference Manual Draft Company Confidential

inheri s object method start begin locals

ICount integer := 10 "Until statement example" . print ( until ICount == 0 ICount print ( ) ICount := ICount - 1 end until "<end> " . print ( ) end method end class

#

While Statement

Description

The while statement is a looping statement with loop control at the beginning of the cycle.

Syntax while expression statements end while

Processing

1. The expression is evaluated first;

2. If the expression is true the nested group of statements immediately following it, are executed;

3. The expression is re-evaluated and if it is true the nested group of statements is again executed;

4. This loop continues until the expression no longer evaluates to true, at which point execution continues with any statements following the end while;

5. If the expression is originally not true, the nested statements are not executed.

Important Information

■ There may be any number of nested statements;

• A continue statement may be used in the nested statements to force the next iteration;

^■ A leave statement may be used in the nested statements to force the loop to end.

Some Examples

In the following example the local variable 'ICount' is initialized to 10. The while statement iterates the loop provided ICount is greater than 0. The nested 70A 72

Language Reference Manual Draft Company Confidential statements print the value of ICount, and decrement it by one for each iteration of the loop. tt tt

# file: .. /examples/smt_while . sb #

# # class cStatementWhileExample description

"Example of while statement" library examples inherits object method start begin locals

ICount integer := 10

"While statement example" .prin ( ) while ICount > 0

ICount .print ( )

ICount := ICount - 1 end while "<end>" .print ( ) end method end class

# #

70A 73

Language Reference Manual Draft Company Confidential

Expressions

This topic describes the expression operators.

Operators

Click on the table below to o to a articular o erator:

Precedence

The o erator precedence is:

70A 74

Language Reference Manual Draft Company Confidential

Add Operator +

Description

The add operator computes the addition of two expressions.

Syntax expressi on_^ + expressιon_b

Important Information

The compiler converts the infix '+' operator into a message of the form: expressιon_a.Add(expression_b);

The result will be the addition of the two expressions.

Some Examples

In the following example the start method prints the sum of 1 + 1. tt #

# file: .. /examples/expr_add. sb #

# # class cOperatorAddExample description

"Example of add operator" library examples inherits object method start begin

"Add operator example" .print ( )

(1+1) .print ( )

"<end> " .print ( ) end method end class ft #

And Operator

Description

The and operator computes the logical and of two expressions. Syntax expressιon_a and

70A 75

Language Reference Manual Draft Company Confidential

Important Information

The compiler converts the infix and operator to a message of the form : expressιona.And(expressιonb)

The result is the logical and of the two expressions according to the following truth table :

Some Examples

In the following example the start method uses the and operator to logically and the result of two comparisons.

# file: .. /examples/expr_and. sb # class cOperatorAndExample description

"Example of and operator" library examples inherits object method start begin

"And operator example" .print ( ] if 1 < 2 and 2 < 3

"1 < 2 and 2 < 3". print () else

"error" .print ( )

"<end> " .print ( ) end method end class ft 70A 76

Language Reference Manual Draft Company Confidential

Callback Operator

Description

The callback operator generates a callback object. A callback object allows a method to be passed as a parameter.

Syntax callback ( expression_a , expression_b [ ,

] . . . )

Important Information expression_a is the class; expression_b is the method name; expression,; (optional) are the types of the parameters to the method;

The result is a callback object;

The callback object may then be used as a message against a target object.

Some Examples

In the following example the start method uses the callback operator to generate a callback to the method PrintThis.

# #

# file: .. /examples/expr_callback.sb #

# # class cOperatorCallbackExa ple description

"Example of callback operator" library examples inherits object method start begin locals

ICallback $Callback

"Callback operator example" .print ( )

ICallback := callback (cOperatorCallbackExample,

"PrintThis" , string) self . !CallBack( "A string to be printed") "<end> " . prin ( ) end method method PrintThis parameters pString string begin pS ring . Print ( ) end method end class 70A 77

Language Reference Manual Draft Company Confidential tt _ tt

Concatenation Operator /

Description

The concatenation operator computes the concatenation of two expressions.

Syntax expression_s | expressιon_b

Important Information

The compiler converts the infix ' |' operator into a message of the form: e press/on_a.Concat(express/oni,)

The result is the concatenation of the two expressions;

Some Examples

In the following example the start method uses the concatenation operator to concatenate three separate strings into a single a string that gets printed. tt #

# file /examples/expr_concat . sb #

_# # class cOperatorConcatExa ple description

"Example of concat operator" library examples inherits object method start begin

"Concat operator example" print ( )

("Hello" I " " I "Universe" ) .print ( )

"<end>" print ( ) end method end class tf #

Construct Operator

Description

The construct operator creates an instance of a particular class.

Syntax construct ( CLΛSSWA Γ[ {generics, ) ] [parameters , ] )

Important Information

An object of type CLASSNAME IS created, 70A 78

Language Reference Manual Draft Company Confidential

^■ If the class has a generics clause, then generics are the classes to be substituted for the generic place holders;

^■ A 'construction' method may be defined within a class. The parameters must match those of the 'construction' method.

Some Examples

Divide Operator/

Description

The divide operator computes the division of two expressions.

Syntax

Important Information

The compiler converts the infix operator '/' into a message of the form :

The result will be the division of the two expressions;

Some Examples

In the following example the start method divides 8 by 4 and prints the result. _# #

# f ile - . . /examples/expr_dιvιde . sb # ft # class cOperatorDivideExample descript ion

" Example of divide operator " l ibrary examples inheri ts obj ect method s tart begin

" Divide operator example " print ( )

( 8 / 4 ) pnnt O

"<end>" print ( ) end method end class

_#___ __ __-#

Downcast Operator

Description

The downcast operator alters the resulting type of an expression. 70A 79

Language Reference Manual Draft Company Confidential

Syntax downcast ( NΛMEC LASS [ ( TYPE [ , TYPE , ] ) ] _a , NAMFC LASS [ ( TYPE [ , TYPE , ] ) ] _b )

Important Information

^■ The downcast operator instructs the compiler to treat the type of NAMECLASS[ (TYPE[,TYPE, .. ] ) ]₃ as though it was the type specified by

NAMECLASS[(TYPE[,TYPE, ■])]_b;

NAMECLASS[ (TYPE[,TYPE, ])]_a,b may be expressions that evaluate to a type;

NAMECLASS [(TYPE[,TYPE, ])]_b must be a sub-class of the type of NAMECLASS[(TYPE[,TYPE, ])]_a;

■ the result is NAMECLASS[(TYPE[,TYPE, ..] )]₃ but with type

NAMECLASS[(TYPE[,TYPE, ..])]_b.

Some Examples

In the following example there are two classes. The second class inherits from the first. The first class has a method that accepts a parameter of the first class.

The method downcasts the parameter to the second class and issues a message

# tt

# file . /examples/expr_downcastl sb # # # class cOperatorDowncastParent description

"Example of downcast operator" library examples inherits object method CallTh s parameters pArgument cOperatorDowncastParent begin downcast (pArgument , cOperatorDowncastParent) . PnntHello ( ) end method end class

# # ft #

# file /examples/expr_downcast2 sb # tf # class cOperatorDowncastChild description

"Example of downcast operator" library examples inherits cOperatorDowncastParent 70A 80

Language Reference Manual Draft Company Confidential method start begin

"Downcast operator example" .print ( )

CallThιs(self )

"<end>" .print ( ) end method method PrmtHello

"Hello Universe '". rin ( ) end method end class ft jf

Grouping ( )

Description

The grouping operator overrides operator precedence.

Syntax

( expression )

Important Information

^■ Parentheses may be used to override operator precedence;

- An expression inside parentheses is evaluated prior to any other evaluation;

^■ Parentheses may be nested indefinitely.

Some Examples

In the following example the grouping operator is used to override divides precedence over plus. ft tt

# file: .. /exambles/expr_groupιng. sb #

_# ft class cOperatorGroupmgExample description

"Example of grouping operator" library examples inheπ ts object method start beg in

"Grouping operator example" print ( )

(12 / 3 + 3) .pnnt() # will print 7

(L2 / (3 + 3)) .pπnt() # will print 2

"<end> " print ( ) end method end class

#__ tt 70A 81

Language Reference Manual Draft Company Confidential

Is Operator

Description

The is operator compares the handles of two objects.

Syntax expressιon_a is [ not ] expression_to

Important Information

^■ An expression of the form expressιon_a is expression_b yields true if the two expressions evaluate to the same handle;

^■ Otherwise it yields false;

^■ An expression of the form expression_a is not expression_b yields true if the two expressions do not evaluate to the same handle;

^■ Otherwise it yields false.

Some Examples

In the following example the is operator compares the handles of the same integer literal.

# #

# file: .. /examples/expr_is . sb

# class cOperatorlsExample description

"Example of is operator" library examples inherits object method start begin

"Is operator example" .print ( ) if 1 is 1

"handles are the same" .print ( ) else

"error ' " .print ( ) end if

"<end> " .print ( ) end method end class

#

Is Equal Operator ==

Description

The Is Equal operator performs an equivalence test between two expressions. 70A 82

Language Reference Manual Draft Company Confidential

Syntax expressιon_a ==

Important Information

^■ The Is Equal operator tests if expression_s is equivalent to

^■ The compiler converts the infix ' = =' operator into a message of the form : express/o/7_a. lsEqual (express/oπ_ft)

^■ The result will be Boolean.

Some Examples

In the following example there is an is equal operator being used by the if statement. f, tf

# file . / examples / expr_equal . sb

# class cOperatorlsEqualExample description

"Example of lsEqual operator" library examples inherits object method start begin

"lsEqual operator example" .print ( ) if 1 == 2 - 1

"1 equals 1". print () else

"error ! " .print ( ) end if '

"<end> " print ( ) end method end class ft

Is Less Operator <

Description

The Is Less operator performs a 'less than' test between two expressions.

Syntax expz essιon_a <

Important Information

^■ The Is Less operator tests if expressιon_a is less than expressιon_bl

The compiler converts the infix '<' operator into a message of the form : expression,, IsLess(expression_b) 70A 83

Language Reference Manual Draft Company Confidential

^■ The result will be a Boolean.

Some Examples

In the following example there is a less than operator being used by the if statement. tt _#

# file: . /examples/expr_less . sb # # _# class cOperatorlsLessExarnple description

"Example of is ess operator" library examples inherits object method start begin

"IsLess operator example" .print ( ) if 1 < 2

"1 is less than 2". print () else

"error ! " .prin ( ) end if

"<end>" .print ( ) end method end class ft ft

Is Less Equal Operator <=

Description

The Is Less Equal operator performs a 'less than or equal to' test between two expressions.

Syntax expressιon_a <= expression_b

Important Information

■ The Is Less Equal operator tests if expressιon_a is less than or equal to express/oA7_b;

^« The compiler converts the infix ^λ< =' operator into a message of the form: expressιon_a . IsLess Eq u a I ( expression^

^# The result will be a Boolean.

Some Examples

In the following example there is a less equal operator being used by the if statement. tt tt

# f ile /exarnples/expr_leq . sb # 70A 84

Language Reference Manual Draft Company Confidential tt tt class cOperatorIsLes EqualExample description

"Example of isLessEqual operator" library examples inherits object method start begin

"Is essEqual operator example" .prin ( ) if 1 <= 1

"1 is less than equal to 1". prin () else

"error¹ " print ( ) end if

"<end>" .print ( ) end method end class

_# #

Is Greater Operator >

Description

The Is Greater operator performs a 'greater than' test between two expressions.

Syntax expressιon_a > express ιon_b

Important Information

^■ The Is Greater operator tests if expression_s is numerically greater than express/o/7_b;

■ The compiler converts the infix '>' operator into a message of the form: express/0Λ)_a.IsGreater(express/0Λ?_£,)

■ The result will be a Boolean.

Some Examples

In the following example there is a greater than operator being used by the if statement

_# #

# file /examples/expr_great sb # ft # class cOperatorlsGreaterExample description

"Example of lsGreater operator" library examples 70A 85

Language Reference Manual Draft Company Confidential inherits object method start begin

"IsGreater operator example" . prin ( ) if 2 > 1

"2 is greater than 1". print () else

"error! " .print ( ) end l f

"<end>" .print ( ) end method end class

# #

Is Greater Equal Operator >=

Description

The Is Greater Equal operator performs a 'greater than or equal to' test between two expressions.

Syntax expression_a >= expression_b

Important Information

■ The Is Greater Equal operator tests if expression_a is greater than or equal to expression^,

' The compiler converts the infix '> =' operator into a message of the form : express/on_a.IsGreaterEqual(express/oπ_b)

■ The result will be a Boolean.

Some Examples

In the following example there is a greater than or equal to operator being used by the if statement.

# #

# file: .. /examples/expr_geq.sb #

# # class cOperatorlsGreaterEqualExample description

"Example of isGreaterEqual operator" library examples inherits objec method start begin

"IsGreaterEqual operator example" . print ( ) i f 2 >= 1 70A 86

Language Reference Manual Draft Company Confidential

" 2 is greater than or equal to 1". print () else

"error ! " .print ( ) end if

"<end>" print ( ) end method end class

# _#

Is Not Equal Operator !=

Description

The Is Not Equal operator performs a 'not equivalent' test between two expressions.

Syntax expression_a

Important Information

The Is Not Equal operator tests if expressions is not the same as expression^,

^■ The compiler converts the infix '! =' operator into a message of the form: express/O/7_a.IsNotEqual(express/ort_b)

^■ The result will be a Boolean.

Some Examples

In the following example there is a not equal operator being used by the if statement.

# #

# file: .. /examples/expr_neq. sb #

_# # class cOperatorisNotEqualExample description

"Example of isNotEqual operator" library examples inherits object method start begin

"IsNotEqual operator example" .print ( ) if 2 '= 1

"2 is not equal to 1". print () else

"error ! " .print ( ) end if

" <end> " .print ( ) end method end class tt ft 70A 87

Language Reference Manual Draft Company Confidential

Modulus Operator %

Description

The modulus operator computes the remainder after dividing two expressions

Syntax % expressιon_b

Important Information

■ The compiler converts the infix '%' operator into an expression of the fornrr expressιon_a Modulus(express/o/7_b)

The result will be the remainder after dividing the two expressions.

Some Examples

In the following example the start method is using the modulus operator to determine the remainder of 3 divided by 2 and 27 divide by 9.

# _#

# file /examples/expr_modulus sb #

# _# class cOperator odulusExample description

"Example of modulus operator %" library examples inherits object method start begin ₍

"Modulus operator example" print ( )

(3 % 2) printO

(27 % 9) print!)

"<end>' print ( ) end method end class

# #

Multiply Operator *

Description

The multiply operator computes the product of two expressions.

Syntax expressιon_α * expressιon_b

Important Information

^■ The compiler converts the infix '*' operator into a message of the form expressιon_a

70A 88

Language Reference Manual Draft Company Confidential

The result is the product of the two expressions;

Some Examples

In the following example the start method is using the multiply operator to determine the result when 3 is multiplied by 2 and when 27 is multiplied by 9. # _#

# file- . /examples/expr_multiply . sb # ft ft class cOperatorMultiplyExample description

"Example of multiply operator *" library examples inherits object method start begin

"Multiply operator example" .print ( )

(3 * 2) .print ()

(27 * 9) .prin ()

"<end>" .print ( ) end method end class

# #

Negate Operator -

Description

The negate operator computes the result of negating an expression. t

Syntax

- expression

Important Information

The compiler converts the prefix negate operator into a message of the form : expression. N eg a te()

The result is the negation of the expression.

Some Examples

In the following example the start method is using the negate operator to negate the value of one and to negate the result when 3 is multiplied by 2.

# #

# file . /examples/expr_negate. sb # #_ tf class cOperatorNegateExample description

"Example of negate operator"

11brary 70A 89

Language Reference Manual Drarf Company Confidential examples inherits object method start begin

"Negate operator example" .print ( )

-1.print ( )

- (3 * 2) . Prin ()

" <end> " . print ( ) end method end class tf

Not Operator

Description

The not operator computes a logical not on an expression.

Syntax not expression

Important Information

^■ The compiler converts the prefix not operator into a message of the form : expression. ot ( )

^■ The result is the logical not of the expression according to the following truth table :

Some Examples

In the following example the if statement is using the not operator. tt

# file . /examples/expr_no . sb tf class cOperatorNotExample descripti on

"Example of not operator" library exampl es inherits object method not 70A 90

Language Reference Manual Draft Company Confidential begin

"Not operator example" . print ( ) if not 1 == 2

"'1 == ?' is not true" .print ( ) else

"error ' " . print ( ) end if

"<end>" .prin ( ) end method end class ft

Or Operator

Description

The or operator computes the logical or of two expressions.

Syntax expression_a or expression_b

Important Information

* The result is the logical or of the two expressions;

^■ The compiler converts the infix or operator into a message of the form: expression_a .0 r( expression _b)

• The result is the logical or of the two expressions according to the following truth table:

Some Examples

In the following example the if statement is making use of the or operator. tt

# f le: .. /examples/expr_or . sb # class cOperatorOrExrimp] e description

"Example of or operator" 70A 91

Language Reference Manual Draft Company Confidential

Library examples inherits object method start begin

"Or operator example" .print ( ) if 1 == 2 or 1 < 2

"Either '1 == 2' or '1 < 2' is true" .print ( ) else

"error ! " .print ( ) end if

"<end>" .print ( ) end method end class ft _#

Power Operator ^Λ

Description

The power operator computes the result of raising one expression to the power of another.

Syntax expression_s expressιon_h

Important Information

^■ The compiler converts the infix '^Λ' operator into a message of the form :

* The result is ra'ising the expression_s to the power of expression^,.

Some Examples

In the following example the if statement 2 is being raised to the power 3. tt tt

# file: .. /examples/expr_po er . sb # # ft class cOperatorPowerExample description

"Example of power operator" library examples inherits object method start begin

"Power operator example" . print ( )

(2^Λ3) print () 70A 92

Language Reference Manual Draft Company Confidential

" <end> " print ( ) end method end class ft

Subtract Operator -

Description

The subtract operator computes the result of subtracting one expression from another.

Syntax expression_s - expressιon_b

Important Information

• The compiler converts the infix '-' operator into a message of the form: expressιon_a . S u btract(express/oπ_b)

^■ The result is the subtraction of expression_b from expressιon_a.

Some Examples

In the following example 2 is being subtracted from 3. tt #

# file: .. /examples/expr_subtract .sb # # # class cOperatorSubtractExample description

"Example of subtract operator" library examples inherits object method start begin

"Subtract operator example" .print ( )

(3-2) . prin ()

"<end>" .print ( ) end method end class

# # 70A 93

Language Reference Manual Draft Company Confidential

Data types and Literals

This topic describes the supported data types and their corresponding literals. Click on the table below to o to a articular data t e/literal :

70A 94

Language Reference Manual Draft Company Confidential

Boolean Data Type and Literal

Description

Boolean literals represent explicit Boolean values.

Literal Syntax

[ true I false | unknown ]

Operators lsEqual, IsNotEqual, Concatenate, Is, Not, And, Or

Important Information

There are only three possible Boolean values.

Some Examples ft #

# file: .. /examples/ltrl_boolean. sb # ft _# class cLiteralBooleanExample description

"Example of Boolean literal" library examples inherits object attributes aValue boolean := true method start begin « aValue . Print ( ) end method end class ft #

Character Data Type and Literal

Description

Character literals represents explicit single character values.

Literal Syntax

Operators lsEqual, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is 70A 95

Language Reference Manual Draft Company Confidential

Important Information

Empty quotes " are not allowed.

Some Examples

# tt

# file- . /examples/ltrl_character . sb # # ft class cLiteralCharacterExample descπ ption

"Example of character literal" library examples inherits object attributes aValue character := ' s' method start begin aValue . Print ( ) end method end class

# #

Date Data Type and Literal

Description

Date literals represent explicit calendar dates (year, month, day).

Literal Syntax ' date$ " 9999 - 99 - 99"

Operators

Add, Subtract, lsEqual, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is

Important Information

^■ The quoted date must be a valid Gregorian date;

^■ Date is in the form yyyy-mm-dd; Years are four digits.

Example tt tt

# f le. /examples/ltrl_date . sb # tf tt class cLi eralDateExample description

"Example of date literal" 70A 96

Language Reference Manual Draft Company Confidential

library examples inher ts object attributes aValue date := date$ "2003-03-25' method start begin aValue. Print ( ) end method end class

Datetime Data Type and Literal

Description

Datetime literals represent explicit points in time (year, month, day, hour, minute, second).

Literal Syntax datetime$ "9999-99-99 99 : 99 : 99"

Operators

Important Information

^■ Datetime is in the form yyyy-mm-dd hh : mm :ss;

■ The quoted date portion must be a valid Gregorian date;

■ Years are four digits;

^« The quoted time portion must be a valid time of day - 00: 00:00 through to 23: 59: 59.

Some Examples tt tt

# file: .. /examples/ltrl_datetime. sb # ft tt class cLiteralDatetimeExample description

"Example of datetime literal" library examples inherits object attπ butes aValue datetime = datetime$ " 2003-03-25 13:30:00" 70A 97

Language Reference Manual Draft Company Confidential

method start begin aValue. Print ( ) end method end class

#

Float Data Type and Literal

Description

Float literals represent explicit real numbers.

Literal Syntax

^ ^ [ { e l E } [ + I - J 9¹

Operators

Add, Subtract, Multiply, Divide, Power, Modulus, Negate, lsEqual, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is

Important Information

^■ There must be at least one digit before the dot; Zero is 0.0;

^■ Floating point numbers are held within the system in double precision (64 bit) format as defined by IEEE 754-1985.

Some Examples

# #

# file: .. /examples/ltrl_float . sb #

# ft class cLiteralFloatExample « description

"Example of float literal" library examples inherits object attributes aValue float := 3.141 method start begin aValue. rint ( ) end method end class ft ft 70A 98

Language Reference Manual Draft Company Confidential

Identifier Data Type and Literal

Description

Identifier literals represent explicit bullαnt unique identification stamps.

Literal Syntax identified "S¹. S¹. 9¹-

Operators lsEqual, IsNotEqual, Concatenate, Is

Important Information

^■ The first digit sequence must be a value in the range 1 .. 65535;

* The second digit sequence must be a value in the range 0 .. 4294967295;

^■ The third digit sequence must be a value in the range 0 .. 65535.

Some Examples

# tt

# file /examples/ltrl_ιdentιfler sb # # ft class cLiteralldentiflerExa ple description

"Example of identifier literal" library examples inherits object attributes aValue identifier = mdentifιer$"l 23 45" method start begin aValue Print ( ) end method end class

# ft

Integer Data Type and Literal

Description

Integer literals represent explicit whole numbers

Literal Syntax

9¹ 70A 99

Language Reference Manual Draft Company Confidential

Operators

Important Information

The digit sequence must represent a value in the range 0 .. 4294967295.

Some Examples

# tt

# file /examples/ltrl_mteger . sb # # ft class cLiterallntegerExample description

"Example of integer literal" library examples inherits object attributes aValue integer := 42 method start begin aValue. Print ( ) end method end class

# ft

Interval Data Type and Literal

Description

Interval literals represent explicit durations of time.

Literal Syntax interval$ " [ 9^xd] [ 9^] [ 9^] ^s ] "

Operators

Add, Subtract, Negate, lsEqual, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is

Important Information

There are four portions - days, hours, minutes and seconds;

• These portions are indicated by the letters d, h, m and s respectively;

^■ Each portion present must have a digit sequence in the range 0 .. 4294967295;

■ At least one portion is mandatory. 7QA 100

Language Reference Manual DrdiL Company Confidential

Some Examples tt tf if file /examples/ltrl_ιnterval . sb # tf ft class cLiterallntervalExample description

"Example of interval literal" library examples inherits object attributes aValue interval := mterval$"2d3h4m5s" method start begin aValue Print ( ) end method end class

# ft

Money Data Type and Literal

Description

Money literals represent explicit amounts of money. Literal Syntax money $ " g¹ ^¹"

Operators

Add, Subtract, Multiply, Divide, lsEqual, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is

Important Information

^■ The first digit sequence must be in the range 0 .. 4294967295;

■ The second digit sequence must be in the range 0 .. 99.

Some Examples tt _#

# file /examples/ ltrl_money . sb # ft ft class cLiteralMoneyExa ple description

"Example of money literal" library examples inherits objec 70A 101

Language Reference Manual Draft Company Confidential

attributes aValue money := money$" 150000.00' method start begin aValue. Print ( ) end method end class

#

Raw Data Type and Literal

Description

Raw literals represent explicit byte sequences.

Literal Syntax raw$ "x¹"

Operators lsEqual, IsNotEqual, Concatenate, Is

Important Information

^■ There may be any number of hexadecimal characters in the string;

^■ Empty strings are permitted.

Some Examples

# tt

# file: .. /examples/ltrl_raw. sb # ft tt class cLiteralExample description

"Example of literal" library examples inherits object attributes aRaw raw : = raw$ "0001ABCDEF" method start begin aValue . Print ( end method end class

# 70A 102

Language Reference Manual Draft Company Confidential

String Data Type and Literal

Description

String literals represent explicit sequences of characters.

Literal Syntax

"σ"" [ \ "α°" ] . . .

Operators lsEqual, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is

Important Information

^■ There may be any number of characters in the string; Empty strings are permitted;

• The backslash is used to create a single string that spans multiple lines;

^■ The string must be surrounded by double quotes.

Some Examples

# #

# file: .. /examples/ltrl_string.sb # # # class cLiteralStringExample description

"Example of string literal" library examples inherits object attributes aValuel := "A string", aValue2 := "A longer string which spans" \ "multiple lines" method start aValuel Prin ( ) aValue2. Print ( ) end method end class tf #

Tick Data Type and Literal

Description

Tick literals represent explicit bullαnt internal sequence numbers. It is used to identify a known, unique state of the bullαnt environment. 70A 103

Language Reference Manual Draft Company Confidential

Literal Syntax tick$ *9^l . S "

Operators

Is Equal, IsNotEqual, IsGreater, IsGreaterEqual, IsLess, IsLessEqual, Concatenate, Is

Important Information

^■ The first digit sequence must be a value in the range 0 .. 4294967295; " The second digit sequence must be a value in the range 0 .. 65535.

Some Examples

# _#

# file: .. /examples/ltrl_tιck. sb #

# ft class cLiteralTickExample description

"Example of tick literal" library examples inherits object attributes aTick tick := tιck$"23.45" method start begin aValue Print ( ) end method end class tt ft

Time Data Type and Literal

Description

Time literals represent explicit points in the day (hour, minute, second).

Literal Syntax time$ " 99 : 99 : 99"

Operators

Important Information

The quoted time must be a valid time of day - 00: 00: 00 through to 23 : 59: 59;

■ Midnight is 00: 00: 00. 70A 104

Language Reference Manual Draft Company Confidential

Some Examples tt tt ft file /examples/ltrl_tιme. sb # ft ft class cLiteralTimeExample description

"Example of time literal"

1 i brary examples i nherits object attributes aTime time := time$"13 : 30 : 00" method start begin aValue. Print ( ) end method end class

# ft

Version Data Type and Literal

Description

Version literals represent explicit version numbers.

Literal Syntax versions "9¹ [ . 9¹ [ . 9¹ [ . 9¹ ] ] ] "

Operators

Important Information

Each portion must be a number in the range 0 .. 255.

Some Examples tt tt

# file /examples/ltrl_versιon. sb #

# # class c iteralVersionExample description

"Example of version literal" librai y exampl PS mheri ts object 70A 105

Language Reference Manual Draft Company Confidential attributes aversion version := version$ "5.0.1" method start begin aValue. Print ( ) end method end class

# _#

70A 106

Language Reference Manual Draft Company Confidential

Language Grammar

This topic presents the language grammar in full.

Note

In this topic superscripts are used to denote points in the grammar where the compiler can detect syntax errors. Subscripts are used to denote points in the grammar where the compiler can detect semantic errors.

CLAS ClassDefimtion - The definition of a class

{ 'class ^NAME₁₅

[ DescπptionClause ] Library-Clause HelpClause ] AuLhorClause ] Inheri tsClaυse ClassExtensionClause ] ClassExposureClause ] ClassOptionsClause ] ConstantsClause ] AtLributesClause ] ClassDependsClause ) ClassEnsuresClause ] ClassSecurityClause ] MethodDefimtion... ] end class₁₀14 i6 π is 264950 )

DESC DescriptionClause - A string describing a class or a method description ^XLITERALST IN& BRY LibraryClause - The library to which a class bel ongs

'library ^NA ELIBRARY

HELP HelpClause - A reference to help text help 'L i Λ/LSTPING

AUTH AuthorClause - The name of the class author

INHT Inheri tsClause - A list of classes f rom wh ich a class inherits inherits "N^1LC_\SS,

CEXT Clasc FxtensionCl ause - Definition of class extensibi li ty extension { abstract I concrete | 'final }

CEXP CIπ t L -.posureC'lause - List of classes that may call the class 70A 107

Language Reference Manual Draft Company Confidential

exposure NΛ ΓCLASS,

COPT: ClasεOptionsClause - A list of class options options { obsolete )

CONS: ConstantsClause - A list of named constants constants { ^!NAΠE { LITERALCHARACTER

[ + I - ] LlTERALlNTEGE:⁵

{ + I - ] ²LITERALFLOAT

LITERALSTRING date$ ³LITERALSTRING₂₀ dateti e$ ⁴LITERALSTRΪNΠ_2] false hex$ ⁵LITERALSTRING₂₄ identifier$ ⁶LITF.RΛI,STRING₂₅ intervals LITERALSTRING_:7 moneyS ⁸LITERALSTRING₄₆ null raw$ LITERALSTRING₅₅ tick$ LITERALSTRING₆₆ timeS ⁹LITERALSTRING₅₆ true unknown

¹⁰version$ ^ULITERALSTRING₆₂ }

ATTR: Attrij utesClause - A list of the class attributes attributes { 'NAME [ ' [' [ Expression ] ^2|] ' ]

³NAI."EC ASS [

_{β 12} ] 1

CDEP: ClassDependsClause - A list of class level pre-conditions depends { ^XNAME

₅₈ },

CENS : ClassEnsuresClause - A list of class level post-conditions ensures { 'NAME ²Expressιon_sl

CSEC : ClassSecurityClause - Class level security conditions security 'Expression,

METH- MethodDefimtion - The definition of a method method 'NAME

DescriptionClause ) HelpClause } MethodExtensionC ause MethodExposureCJ use ] OptionsClause } Para etersClause } MethodDependsClauεe ] RetuznsClause J [ MethodEnsur sC L iuse ] [ MethodSecuri yC lause } 70A 108

Language Reference Manual Draft Company Confidential

[ BegmClause | Dri verC la use ] end 'method ^J,28 j J4 2 1 4 1 I S

MEXT MethodExtensionClause - Declaration of method extensibility extension { abstract | concrete | 'final )

MEXP MethodExposureClause - Declaration of method exposure exposure { hidden | private | public | 'NAMECLASS,

MOPT MethodOptionsClause - Declaration of method options options { glyph I immutable | mutable I 'obsolete } ,

PARM ParametersClause - A list of method parameters parameters { none

I { 'NAME₅₇ [ ' I ' ² ' ] ' ] ³NAMECLASS }

MDEP MethodDependsClause - A list of method pre-conditions depends { 'NAME

₅₈ }

RETS ReturnsClause - Declaration of method returns variable and type returns { none

'NAME [ ' [ ' ² ' ] ' ] ³NAMECLASS₁₂ ) ENS MethodEnsuresClause - A list of method post-conditions ensures { 'NAME ² Expressi on^ ₅₃ } ,

MSEC MethodSecuπ tyClause - Method security conditions security ' 'Expression , .

BGIN BegmClause - Method behaviour begin_{J6 38} [ Local sClause ]

[ SLa Lemen t_{i 2} [ Excep lonTrap

DRVR Or iverClause - Declaration of a driver driver 'LTTFRA SIRING function 'LITERA S^mRING₃₃

LOG'S LocalsClause - A list of local variables locals { 'N/ E [ ' [ ' [ Expr ession ] ^{^} ] ' ]

³NAMΓCLASS₅- [ : =₆ , Expressi on? ₉ ] } ⁵ ,

STM1 Sta tement - A statement 70A 109

Language Reference Manual Draft Company Confidential

Assei tSl at em 'tit

CaseStat emen ..

ContmucSta i ement

DebugStatemcnt

EvalStatemeni

ExecStatement

ForStaiement

If Statement

LabelSta tement

Lea veSta e en t

LockStatemeni-

RaiseSta tement

Re turns ta tement

RetryState ent

Rollbacks ta emen

Transactions tat ement

Until Statement

WhileStatement

OtherStatement )

ASRT: AssertStatement - The assert statement assert { 'NAME ²

}

CASE: CaseSta tement - The case statement case ' Expression

[ when ²Expressιon_{sη s8} , ..

[ Statement... ] ] .. I when other }

[ Statemen ... ] ] ..

CONT: ContinueStatement - The continue statement continue₁₉ { for₆₁ | until₆₁ | while₆ι I 'NAMELABEL₂₉ )

DBUG: DebugSta tement - The debug statement debug

[ Statement 'end ebug

EVAL. EvalStatement - - The eval statement

EXEC ExecSt emen - - The exec statement

@exec { N_'-'MCCO, 'S Γ VT₅ { ( LITERALINTEGER ' 1 ^•> 3 4 5 6 7

1 ³ : ⁴NAMELABΪ

⁵pop °Nv fVΛRTABLE_{12 45} }

FOR ForState ent - The for statement for [ Statement 'step [ Statement ²test ³Expres i n.,, .,₃ 70A 110

Language Reference Manual Draft Company Confidential

I Statemen . 'end for

IF: If Statement - The if statement

[ St tement ... ]

I Statement... ] ] .

[ else

[ Statement... ] ]

'end "if

LABL: LabelStatement - The label statement label 'NAME^

LEVE: LeaveStatement - The leave statement leave, ₉ { for₆₂ | until₆₂ | while_β2 | 'NAMELABEL₂₉ }

LOCK: LockSta tement - The lock statement lock Expression [ Statement... ]

RAIS: RaiseStatement - The raise statement raise₅₁ 'NAME

[ severity { warning | error | ²fatal ]

[ reason ^Expression ]

RETN: ReturnState ent - The return statement return { none |

₅₈ }

RTRY: RetryStatement - The retry statement retry_M 'NΛMFLABEL₅₃

ROLL: RollbackStatement - The rollback statement rollback 'transaction^

TRAN ransactionStatement - The transaction statement transaction,_!

( Statemen ... 'end ^transaction

UNTL UntilStatement - The until statement until -Express ιon₅₆ [ ^c,'ta tement .. ] "end 'until 70A 111

Language Reference Manual Draft Company Confidential

WILE WhileS ta tement - The while statement while

[ Statement ] end ²whιle

OTHR Other Statement - Assignment or message statement [ [ ₈ ^lExpressιon_{51 58} ( : == ³ EExxpprreessssιon_a 9 ι-> 4 = I ''DotMesεage

Message

TRAP ExceptionTrap - An exception handler

{ trap [ NA F I 'all ] [ Statement ] ²end ³trap }

EXPR Expression - An expression ^lPhrase [ or ²Phrase₅₁

PHRS Phrase - An expression phrase and ²Invert_{sl 58}

INVT Invert - An expression invert

[ not ] ^" ru hs

TRTH Truth - An expression truth

SUMM Sum - An expression sum

"P oduct [ { + - ! ' } ^b "Product

PROD Product - An expression product

"Poiver f * / \ % ^J 'Power

POW Power - An expression power

'Message [ ^Λ Messsdge

MESG Message - An expression message

{ NA ME^-IO) Α ql ist [ DotMessage_{3} Jb u t 4 6} ]

I ancestor ( [ NancCldss 1 )

Ncun Mc beige Λigl i t ,<^■ [ DotMessaciK. , ₀ , _6j 70A 112

Language Reference Manual Draft Company Confidential

erm { DotMesεage] 3 3b 40 41 J; 63

TERM Term - An expression term

L> i „ ALCHARACTER

Li ."^ΛΓ INTEGER

L r -^■ I F LOAT L^r ', LSTRING N\ C ASS

N, CONSTANT

NΛ^ VAUABLE [ ' [ ' se ¹Expressιon₅₆ '] ' ] callback ³( ^ΛExpressιon ₆ ^b, ^bExpressιon₅₆

{ , ^ηExpressιon_i6 ] ⁸) config date$ ⁹LITERALSTRING₂₀ datetimeS ¹⁰LITERALSTRIN&₂₁ downcast "( ¹ Expressιon ¹³, ¹⁴NAMECLASS₁₂ ¹⁵) exception false hex$ ^1DLITERALSTRING₂₄ host identifiers ¹⁷LITERALSTRING₂₅ intervals ¹⁸LITERA STRING₂₇ oneyS ¹⁹LITERALSTRING₄₆ null peer raw$ ^,0LITERALSTRING₅₅ route ²¹ ( ²²Expressιon ²³, ² Express lonRoutable ²⁵) self task tιck$ ^{^6}LITERALSTRING₆₆ timeS LITERALSTRING₅₅ true unknown versιon$ ²⁸LITERALSTRING₆₀ ( 'Expression ³⁰) }

ARGS ArgList - An argument list

DOTM DotMessage - Dot, message, argument list sequence

{ • NameMessage } ²ArgLιst-,₉ }

REXP PoutableExpression - A routable expression

N/> /ι"ABLE ^l ^NameMessage '( ⁵<Expressιon> , . ⁶)

RMSG koutableMessage - The name of a routable message

{ N I NAMEMEΓHOD I 'NMΛ VA I S^Z ) 70A 113

Language Reference Manual Draft Company Confidential

Syntax Errors

This topic itemizes the possible syntax errors detected by the compiler.

ARGS01

Reason

Missing symbol '('

Explanation

The compiler was expecting a [[message argument list]] and did not see the opening parenthesis

Correction

Correct the program source so as to specify the opening parenthesis or correct the message.

ARGS02

Reason

Missing expression after symbol Y

Explanation

The compiler was parsing a [[message argument list]] and did not see an expression after the comma.

Correction

Correct the program source so as to specify the missing argument or remove the extraneous comnrte

ARGS03

Reason

Missing matching ')'

Explanation

The compiler was parsing a [[message argument list]] and did not see a closing parenthesis

Correction

Correct the program source so as to specify the closing parenthesis.

ASRT01

Reason

Missing assert condition name 71

ANNEXURE

Scalability Benchmark Test

71 B 1

Description of Test

The Raw Transaction Test is designed to test three things:

• The peak transaction rate that the engine can sustain

• The scalability of the engine as the number of concurrent tasks increases

• The scalability of the engine as the capacity of the machine increases

The test is purposely very simple.

It models a simple bank which contains a set of accounts ( 10,000) from which money can be withdrawn or to which money can be deposited.

The test also has a concept of a task, which is constructed to go around the following cycle:

While the test is running

Select a random account Select a second random account

Commence transaction Withdraw $1 , 000 from the first account Deposit $ 1 , 000 into the second account

Commit the transaction Continue the loop

Essentially the task is asked to go around this loop as fast as it can, and this represents some form of transaction request interface to the bank.

The test involves a sequence of runs. The only difference in each run is the number of tasks that the system is requested to execute concurrently. This is increased for each run.

The test process is to create all the tasks, allow a short period of time to stabilize the system, and then execute for several minutes. The number of transactions is recorded as part of the test, and the final calculation is expressed as a 'number of transactions per second' .

71 B 2

The Test Environment

The test environment consisted of:

Machine

• Dual processor Xeon Pill 500 Mhz l Mbyte Cache

• Motherboard Intel C440GX+ Bios 72

• Memory - l Gbyte Micron 8ns ECC l OOMhz SDRAM

• Dual Channel Adaptec Raid 1 /5

• 10 9Gbyte Quantum Atlas l Ok Disk Drives

Operating System

• Windows NT 4.0 Service Pack 4

71 B

The Bullαnt Test

The bullαnt test involves the creation of three objects:

1 . An Account, which has a Balance

2. A Bank which has a set of Accounts

3. An Agent, which goes around a loop initiating transactions against the Bank

Software Version

• Bullant Kernel Version 5.0 Beta Test Results - bullant

bullant Test Results

2,000 _ 4,000 6,000 8,000 10,000

Concurrent Tasks 71 B 4

Bullαnt Test Results Discussion

The bullαnt test involved no special tuning of the environment or the system No changes were made in the bullant Kernel between each run

The system was monitored using the NT performance monitor During the test cycle the machine was running at 98%-99% CPU utilization, with less than 2% kernel mode during the entire test

All bullant agents were running (including the bullant garbage collector, known as the 'Cleaner Agent') These tasks did not interfere with the continuous execution of the test, and no sudden troughs in CPU utilization were observed

The peak transaction rate of 12, 445 transactions per second was achieved with 2,800 concurrent tasks At this rate every transaction is taking around 80 μseconds - this includes the business logic, the two phase commit delta write, the governing apd scheduling between tasks, the creation of objects the cleaning of garbage objects and the recycling of objects

Detailed observation of the test suggests that the system scales very well across the two processors, with almost no context switch load This confirms other multi-cpu scaling tests, indicating that the system will scale well across more than two CPUs

The system was effectively subjected to a 500% overload, when the task load was increased to 10,000 concurrent tasks. The scheduling overhead introduced by this overload was only 6 7%, and all tasks remained responsive and active with almost equal CPU allocation

This clearly demonstrates the concurrent task scaling capability of the bullant engine

71 B 5

Java Oracle Comparison Test

To compare the bullant result, a comparison test was constructed using Oracle and Java.

Java Implementation Details

Testing was performed using the following configuration:

Java JavaSoft JDK l .l .7.5

JIT Symatec JIT

JDBC Oracle 8.1 .5 OCI JDBC

The Oracle Type 2 (OCI) driver was chosen since both the JVM and Oracle server were running on the same machine. This enables the Oracle driver to utilize a bequeath connection to the database, enabling significantly improved throughput.

The default transaction isolation level, TRANSACTION_READ_COMMITTED, was used for the Oracle JDBC driver. This implies that dirty reads are prevented; but non-repeatable reads and phantom reads can occur.

Given the adaptive nature of current 'just in time compilers' for Java, a configuration parameter was included to allow the JIT to sample and optimize the running application. The creation of threads, etc, was as follows: loop create a new database connection create a new thread object with this connection until all of the threads in the test have been created loop start the next thread until all of the threads in the test have been started wait to allow the JIT to optimize reset the transaction counter loop sleep one minute print the current value of the transaction counter until the test has completed

Java code was optimized through the use of final classes, allowing the JIT to inline code segments where required. Standard JDBC optimizations were also applied through the use of ] ava . sql . Preparedstatements in all transactions.

Objects shared between all of the Java threads are as follows:

RNG The Java Random class was used for the RNG and shared between all threads.

Counter A shared counter object is used by all of the threads in order to record performance 71B

statistics.

Log A utility class providing logging in the event of exceptions, etc., is shared between all threads.

Oracle Implementation Details

The database tables and indexes used in the test were re-created each time the test was run in order to provide a known environment at the start of the run.

Each thread in the application has its own database connection. This was necessary since transactions in JDBC are controlled via the J ava . sql . Connection Object.

It was necessary for the Oracle database to be re-tuned for each benchmark run, specifically to support increasing numbers of connections. All Oracle tuning was achieved using the Oracle database creation wizard, using the suggested settings for an OLTP style database, for the specified number of concurrent connections. All of the default parameter: for Oracle were accepted, with the exception of the USER table-space size, which was set at 50 Mb (the default is 10 Mb).

Results

Concurrent Tasks Transactions Per Second

1 212

10 288

25 310

50 312

100 285

200 270

Java / Oracle Comparison

350 300

TJ c 250 o o o 200 tn 150 α. x

I- 100 50 0

50 100 150 200

Concurrent Tasks 71 B 7

Observations

Despite considerable effort, and the use of the performance tuning wizards, it was not possible to extend the test beyond 200 concurrent tasks. Beyond 200 tasks the system exhibited severe errors, with thread failure.

On the performance monitor the system exhibited periodic behaviour, with both significant kernel time and periods of inefficient CPU utilization. The CPU usage dropped to very low levels every 3-4 seconds, then climbing again. It never exceed 90% utilization. It is expected that the degradation in performance experienced in the test could be extended to more tasks, but this proved extremely difficult to achieve.

The system also exhibited significant kernel mode CPU use, and a substantial level of context switching. This suggested that the base architecture could experience difficulties in achieving linear scaling across multi-cpu machines.

71 B 8

Bullαnt Comparison

To compare the two tests they were plotted on the same graph. This is shown below.

Bullant Java/Oracle Comparison

- Java /Oracle

- bullant

2000 4000 6000 8000 10000

Concurrent Tasks

As the Java / Oracle comparison is very difficult to see on this graph, the following graph shows the same data in log log format:

Bullant Java/Oracle Comparison

- Java /Oracl ■ bullant

10 100 1000 10000

Concurrent Tasks 71 B 9

Discussion

These tests are very simple. Yet they illustrate a dramatic result:

1 . bullant is, at the very least, faster than a Java / Oracle combination by one order of magnitude

2. bullant is, at the very least, more capable of scaling to user or task load than a Java / Oracle combination by one order of magnitude

The tests suggest that these results will become even more extreme as the number of CPUs increase, because bullant scales almost linearly across CPUs whereas Java / Oracle did not do this in the test.

Claims

72

1. A scalable programming environment for a computer system; said environment including one or more scalability constructs. 2. The environment of Claim 1 wherein said scalability constructs enable said environment more closely to attain and approach maximum utilisation of system resources .

3. The environment of Claim 1 wherein a first one of said scalability constructs is an object structure and wherein both data and tasks are implemented as objects.

4. The environment of Claim 3 wherein tasks comprise either user tasks or system tasks.

5. The environment of Claim 4 wherein user tasks have a time perspective at which they read the state of obj ects .

6. The environment of Claim 5 wherein objects can be designated as persistent objects or transient objects.

7. The environment of Claim 6 wherein persistent objects are referenced via a directed graph of persistent objects which originates at the persistent root

8. The environment of Claim 6 wherein persistent objects can only be changed in a transaction. 73

9. The environment of Claim 6 wherein objects which are persistent can only reference other objects which are persistent .

10. The environment of Claim 7 wherein objects which are transient can reference both objects which are persistent and objects which are transient.

11. The environment of Claim 1 including, in combination, at least a first scalability construct and a second scalability construct. 12. The environment of Claim 1 including, in combination, at least a first scalability construct, a second scalability construct and a third scalability construct.

13. The environment of Claim 1 wherein a first scalability construct is a data object construct. 14. The environment of Claim 1 wherein said first scalability construct is a resource governor construct. 15. The environment of Claim 1 wherein said first scalability construct is a garbage collector construction. 16. The environment of Claim 11 wherein said first scalability construct is a data object construct and said second scalability construct is a resource governor construct . 74

17. The environment of Claim 11 wherein said first scalability construct is a data object construct and said second scalability construct is a garbage collector construct . 18. The environment of Claim 11 wherein said first scalability construct is a resource governor construct and said second scalability construct is a garbage collector construct.

19. A method of implementing transaction processing; said method comprising executing transactions on a computer system in the environment as claimed in claim 1.

20. The environment of Claim 13 wherein said data object construct comprises a method of operating on an object, said object comprising at least a first data record in a system comprising a plurality of said objects; the method including the following steps when at least one field in said at least a first data record is to be changed:

(a) first making a copy of at least those fields of said data record which are to be changed so as to produce a copy record; then in any order: 75

(b) i. recording in a field of the updated data record the time in said system at which said updated record is created; ii . forming a link between said updated data record and said at least a first data record; iii. making the change to said at least one field of the copy record so as to produce an updated data record.

21. The environment of Claim 20 wherein step (b) is carried out in the order steps (b) i . (b)ii. (b) iii .

22. The environment of Claim 20; said method operating according to the rule that only the current record of an object can be changed.

23. The environment of Claim 13 wherein said data object construct comprises a data structure for a computer; said data structure comprising at least one data record; each said data record of said data structure comprising a plurality of fields including: (a) a time of creation field; (b) a pointer to a record field;

(c) one or more data fields.

24. The environment of Claim 23 and wherein at least one field in said at least one data record includes a pointer to another said object. 76

25. The environment of Claim 13 wherein said data object construct comprises a method of operating on an object; said object comprising at least a first data record in a system comprising a plurality of said objects, the method comprising executing the following steps when at least one field in said at least a first data record is to be changed by a change agent so as to create an updated data record:

(a) first making a copy of said data record so as to produce a copy record; then in any order :

(b) i. recording in a field of the updated data record a change number associated with the change agent making the change in said system reflecting the relative time at which said updated record is created, ii. forming a link between said updated data record and said at least a first data record; iii. making the change to said at least one field of the copy record so as to produce an updated data record.

26. The environment of Claim 25 wherein step (b) is carried out in the order sub-steps (b) i . (b)ii. (b)iii. 77

27. The environment of Claim 13 wherein said data object construct comprises a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at least:

(a) a time of creation field reflecting relative time of creation of said data record;

(b) a pointer to a record field which contains information as to the location of another data record within said data structure.

28. The environment of Claim 13 wherein said data object construct comprises an object having the structure defined in Claim 27 and wherein fields in said data records include pointers to objects. 29. A method of operating a computer; said method invoking at least one change agent; the change agent operating on a data structure in an environment as defined in

Claim 27.

30. The method of Claim 29 where said change agent is further adapted to operate on records within said objects which have a transition point stored in said time of creation field. 78

31. The method of Claim 30; said method operating according to the rule that only the current record of an object can be changed.

32. The environment of Claim 27 implemented in software. 33. The environment of Claim 27 implemented in hardware.

34. The environment of Claim 27 implemented in microcode.

35. The environment of Claim 28 implemented in software.

36. The environment of Claim 28 implemented in hardware.

37. The environment of Claim 28 implemented in microcode. 38. The environment of Claim 14 wherein said resource governor construct comprises a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising:

(a) instituting a special purpose task as a resource governor; 79

(c) said resource governor receiving from said resource consumers said used resources . 39. The environment of Claim 38 wherein said usable resources include tasks, unused objects, a unit of network bandwidth or a designated unit of an input/output operation.

40. The environment of Claim 38 wherein each said resource consumer includes an input buffer.

41. The environment of Claim 38 wherein each said resource consumer device includes an output buffer.

42. The environment of Claim 40 wherein said input buffer is a non-locking buffer. 43. The environment of Claim 41 wherein said output buffer is a non- locking buffer.

44. The environment of Claim 42 wherein said input buffer is a ring buffer.

45. The environment of Claim 43 wherein said output buffer is a ring buffer.

46. The environment of Claim 14 wherein said resource governor construct comprises a method of allocation of tasks to execution devices in a computer system; said computer system of the type having a plurality of tasks 80

for execution and one or more execution devices capable of executing said tasks whereby a task for execution is input to at least one of said execution devices, is then executed by said at least one execution device and is then output from said at least one execution device as an executed task; said method comprising: (a) instituting a special purpose task as a task allocator; (b) said task allocator distributing said tasks for execution to said execution devices; (c) said task allocator receiving from said execution devices said executed tasks.

47. The environment of Claim 46 wherein each said execution device includes an input buffer.

48. The environment of Claim 46 wherein each said execution device includes an output buffer.

49. The environment of Claim 47 wherein said input buffer is a non- locking buffer. 50. The environment of Claim 48 wherein said output buffer is a non- locking buffer. 51. The environment of Claim 49 wherein said input buffer is a ring buffer. 81

52. The environment of Claim 50 wherein said output buffer is a ring buffer.

53. The environment of Claim 1 wherein said environment includes a resource consumer scalability construct, said resource consumer scalability construct comprising a structure suitable for use in conjunction with a resource governor, said structure comprising a resource consumer having at least one input buffer and from which said resource consumer takes usable resources for use. 54. The environment of Claim 53 wherein said resource consumer accepts resources for use of a predefined type from said at least one input buffer.

55. The environment of Claim 53 wherein said resource consumer obtains said usable resources for use only from said at least one input buffer.

56. The environment of Claim 54 wherein said at least one input buffer receives resources of only said predefined type.

57. The environment of Claim 53 wherein said resource consumer experiences no contention for execution of said usable resources for use.

58. The environment of Claim 53; said structure further including an output buffer into which said resource 82

consumer places said usable resources following execution by said resource consumer. 59. The environment of Claim 53 wherein said at least one input buffer is a non- locking buffer. 60. The environment of Claim 58 wherein said output buffer is a non-locking buffer.

61. The environment of Claim 59 wherein said input buffer is a ring buffer.

62. The environment of Claim 60 wherein said output buffer is a ring buffer.

63. The environment of Claim 15, wherein said garbage collector construct comprises a method of identification of unused data blocks in a computer system; each data block having a unique reference; said method comprising the steps of:

(a) designating a special purpose task as a cleaner task which identifies unused data blocks;

(b) each task adapted to indicate to the cleaner task the identity of a unique reference which it has displaced.

64. The environment of Claim 63 wherein said cleaner task, during execution, takes into account the identity of those unique references which are indicated as having been displaced. 83

65. The environment of Claim 15, wherein said garbage collector construct comprises a method of identification of unused objects in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; said method comprising the steps of, in order: (a) initiating said cleaner task, said cleaner task defining a set of unused objects which comprises initially all objects in said system;

(b) said cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs; during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse;

(c) said cleaner task traversing all graphs for which the starting point is any handle which has been 84

identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse . 66. The environment of Claim 15, wherein said garbage collector construct comprises a method of removal or release of unused objects from a computer system; said method comprising the steps of:

(b) making available to said system for re-use the memory locations occupied by said set of unused objects .

67. The environment of Claim 15, wherein said garbage collector construct comprises a data object identification system operating according to the method defined in Claim 65.

68. The environment of Claim 15, wherein said garbage collector construct comprises a data object identifier and removal system operating according to the method defined in Claim 63 and wherein said cleaner task makes available to said computer system for reuse data objects which have been identified as unused data objects. 85

69. The environment of Claim 1 including a computer architecture which supports a cleaner task; said architecture arranged, in an at least first mode of operation, to take and store elsewhere a value immediately prior to said value being over-written.

70. The environment of Claim 69 wherein said value which is stored elsewhere is accessible to a cleaner task.

71. The environment of Claim 69 implemented in hardware.

72. The environment of Claim 69 implemented in software. 73. The environment of Claim 69 implemented in microcode.

74. The construct of Claim 80 implemented in hardware.

75. The construct of Claim 70 implemented in software.

76. The construct of Claim 70 implemented in microcode.

77. The environment of Claim 15, wherein said garbage collector construct comprises a method of identification of unused data blocks in a computer system implemented as a cleaner task which can run concurrently with other tasks performed by the computer system; each data block having a unique reference; said method comprising the steps of :

(a) designating a special purpose task as a cleaner task which identifies unused data blocks; 86

(b) each task adapted to indicate to the cleaner task that it has caused a unique reference to be overwritten.

78. The environment of Claim 77 wherein said cleaner task, during execution, takes into account the identity of those unique references which are indicated as having been displaced.

79. An object structure comprised of a plurality of objects controlled by a resource governor in a scalable computing environment in a scalable computing environment; each said object comprising a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at least:

(b) a pointer to a record field which contains information as to the location of another data record within said data structure; said resource governor following a method of allocation of usable resources; said method comprising a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type 87

having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising: (a) instituting a special purpose task as a resource governor ;

(c) said resource governor receiving from said resource consumers said used resources. The object structure and resource governor of Claim 79 further including a garbage collector or cleaner task which adopts a method of removal or release of unused objects, said method comprising in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as 88

a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order:

(c) said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse . The system of Claim 1 wherein said scalability constructs include a system aid; said system aid adding a system aid overhead which consumes system resources . 89

82. The system of Claim 81 wherein said system aid overhead consumes system resources at a rate which is substantially independent of system resource utilisation. 83. The system of Claim 82 wherein said one of said scalability constructs comprises a data object structure and said system aid overhead comprises that portion of said data object structure which retains and keeps track of historical records. 84. The system of Claim 82 wherein said one of said scalability constructs comprises a garbage collector and said system aid overhead comprises objects in said system which have the capacity to flag changes to said system so as to aid the action of said garbage collector.

85. The system of Claim 82 wherein said one of said scalability constructs comprises a resource governor and said system aid overhead comprises the interposition of a task acting as a resource governor between a pool of resources for consumption and resource consumers.

86. A scalable programming environment for a computer system; said environment including one or more constructs . 90

87. The environment of Claim 86 wherein a first one of said constructs is an object structure.

88. The environment of Claim 87 wherein both data and tasks are implemented as objects. 89. The environment of Claim 86 or Claim 87 or Claim 88 wherein tasks comprise either user tasks or system tasks .

90. The environment of Claim 89 wherein user tasks have a time perspective at which they read the state of objects.

91. The environment of any one of Claims 86 to 90 wherein objects can be designated as persistent objects or transient objects.

92. The environment of Claim 92 wherein persistent objects are referenced via a directed graph of persistent objects which originates at the persistent root.

93. The environment of Claim 91 or 92 wherein persistent objects can only be changed in a transaction.

94. The environment of any one of Claims 91 to 93 wherein objects which are persistent can only reference other objects which are persistent.

95. The environment of any one of Claims 92 to 94 wherein objects which are transient can reference both objects which are persistent and objects which are transient. 91

96. The environment of any one of Claims 86 to 95 including, in combination, at least a first construct and a second construct .

97. The environment of any one of Claims 86 to 95 including, in combination, at least a first construct, a second construct and a third construct .

98. The environment of any one of Claims 86 to 97 wherein said first construct is a data object construct.

99. The environment of any one of Claims 86 to 97 wherein said first construct is a resource governor construct.

100. The environment of any one of Claims 86 to 97 wherein said first construct is a garbage collector construction.

101. The environment of ^'Claim 96 wherein said first construct is a data object construct and said second construct is a resource governor construct .

102. The environment of Claim 96 wherein said first construct is a data object construct and said second construct is a garbage collector construct. 103. The environment of Claim 96 wherein said first construct is a resource governor construct and said second construct is a garbage collector construct . 92

104. A method of implementing transaction processing; said method comprising executing transactions on a computer system in the environment of any preceding claim.

105. The environment of any one of Claims 96 to 103 wherein said data object construct comprises a method of operating on an object, said object comprising at least a first data record in a system comprising a plurality of said objects; the method including the following steps when at least one field in said at least a first data record is to be changed:

(a) first making a copy of at least those fields of said data record which are to be changed so as to produce a copy record; then in any order: (b) i. recording in a field of the updated data record the time in said system at which said updated record is created; ii . forming a link between said updated data record and said at least a first data record; iii. making the change to said at least one field of the copy record so as to produce an updated data record.

106. The environment of Claim 105 wherein step (b) is carried out in the order steps (b)i. (b) ii . (b)iii. 93

107. The environment of Claim 105 or Claim 106; said method operating according to the rule that only the current record of an object can be changed.

108. The environment of any one of Claims 96 to 103 wherein said data object construct comprises a data structure for a computer; said data structure comprising at least one data record; each said data record of said data structure comprising a plurality of fields including: (a) a time of creation field; (b) a pointer to a record field; (c) one or more data fields.

109. The environment of Claim 108 and wherein at least one field in said at least one data record includes a pointer to another said object. 110. The environment of any one of Claims 96 to 103 wherein said data object construct comprises a method of operating on an object; said object comprising at least a first data record in a system comprising a plurality of said objects, the method comprising executing the following steps when at least one field in said at least a first data record is to be changed by a change agent so as to create an updated data record: (a) first making a copy of said data record so as to produce a copy record; 94

then in any order:

(b) i. recording in a field of the updated data record a change number associated with the change agent making the change in said system reflecting the relative time at which said updated record is created, ii . forming a link between said updated data record and said at least a first data record; iii. making the change to said at least one field of the copy record so as to produce an updated data record.

111. The environment of Claim 110 wherein step (b) is carried out in the order sub-steps (b)i. (b) ii . (b)iii.

112. The environment of any one of Claims 96 to 103 wherein said data object construct comprises a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at least : (a) a time of creation field reflecting relative time of creation of said data record; (b) a pointer to a record field which contains information as to the location of another data record within said data structure. 95

113. The environment of any one of Claims 96 to 103 wherein said data object construct comprises an object having the structure defined in Claim 112 and wherein fields in said data records include pointers to objects. 114. A method of operating a computer; said method invoking at least one change agent; the change agent operating on a data structure in an environment as defined in Claim 112.

115. The method of Claim 114 where said change agent is further adapted to operate on records within said objects which have a transition point stored in said time of creation field.

116. The method of Claim 115; said method operating according to the rule that only the current record of an object can be changed.

117. The environment of Claim 112 implemented in software.

118. The environment of Claim 112 implemented in hardware.

119. The environment of Claim 112 implemented in microcode.

120. The environment of Claim 113 implemented in software. 121. The environment of Claim 113 implemented in hardware.

122. The environment of Claim 113 implemented in microcode.

123. The environment of any one of Claims 99 to 103 wherein said resource governor construct comprises a method of allocation of usable resources to resource consumers in 96

a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising:

(a) instituting a special purpose task as a resource governor;

(b) said resource governor distributing said usable resources to said resource consumers; (c) said resource governor receiving from said resource consumers said used resources.

124. The environment of Claim 123 wherein said usable resources include tasks, unused objects, a unit of network bandwidth or a designated unit of an input/output operation.

125. The environment of Claim 123 or Claim 124 wherein each said resource consumer includes an input buffer. 97

126. The environment of Claim 123 or Claim 124 or Claim 125 wherein each said resource consumer device includes an output buffer.

127. The environment of Claim 125 wherein said input buffer is a non- locking buffer.

128. The environment of Claim 126 wherein said output buffer is a non- locking buffer.

129. The environment of Claim 127 wherein said input buffer is a ring buffer. 130. The environment of Claim 128 wherein said output buffer is a ring buffer.

131. The environment of any one of Claims 99 to 103 wherein said resource governor construct comprises a method of allocation of tasks to execution devices in a computer system; said computer system of the type having a plurality of tasks for execution and one or more execution devices capable of executing said tasks whereby a task for execution is input to at least one of said execution devices, is then executed by said at least one execution device and is then output from said at least one execution device as an executed task; said method comprising:

(a) instituting a special purpose task as a task allocator; 98

(b) said task allocator distributing said tasks for execution to said execution devices;

(c) said task allocator receiving from said execution devices said executed tasks. 132. The environment of Claim 131 wherein each said execution device includes an input buffer.

133. The environment of Claim 131 or Claim 132 wherein each said execution device includes an output buffer.

134. The environment of Claim 132 wherein said input buffer is a non-blocking buffer.

135. The environment of Claim 133 wherein said output buffer is a non-blocking buffer.

136. The environment of Claim 134 wherein said input buffer is a ring buffer. 137. The environment of Claim 135 wherein said output buffer is a ring buffer.

138. The environment of Claim 86 or Claim 96 or Claim 97 wherein said environment includes a resource consumer construct, said resource consumer construct comprising a structure suitable for use in conjunction with a resource governor, said structure comprising a resource consumer having at least one input buffer and from which said resource consumer takes usable resources for use. 99

139. The environment of Claim 138 wherein said resource consumer accepts resources for use of a predefined type from said at least one input buffer.

140. The environment of Claim 138 or Claim 139 wherein said resource consumer obtains said usable resources for use only from said at least one input buffer.

141. The environment of Claim 139 or Claim 140 wherein said at least one input buffer receives resources of only said predefined type. 142. The environment of any one of Claims 138 to 140 wherein said resource consumer experiences no contention for execution of said usable resources for use.

143. The environment of any one of Claims 138 to 142; said structure further including an output buffer into which said resource consumer places said usable resources following execution by said resource consumer.

144. The environment of any one of Claims 138 to 143 wherein said at least one input buffer is a non- locking buffer.

145. The environment of Claim 143 wherein said output buffer is a non- locking buffer.

146. The environment of Claim 144 wherein said input buffer is a ring buffer.

147. The environment of Claim 145 wherein said output buffer is a ring buffer. 100

148. The environment of any one of Claims 100, 102 or 103 wherein said garbage collector construct comprises a method of identification of unused data blocks in a computer- system; each data block having a unique reference; said method comprising the steps of:

149. The environment of Claim 148 wherein said cleaner task, during execution, takes into account the identity of those unique references which are indicated as having been displaced. 150. The environment of any one of Claims 100, 102 or 103 wherein said garbage collector construct comprises in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; 101

each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order:

(c) said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse . The environment of any one of Claims 100, 102 or 103 wherein said garbage collector construct comprises a method of removal or release of unused objects from a computer system; said method comprising the steps of: 102

(a) following the method defined in Claim 148 to identify a set of unused objects,

152. The environment of any one of Claims 100, 102 or 103 wherein said garbage collector construct comprises a data object identification system operating according to the method defined in Claim 150. 153. The environment of any one of Claims 100, 102 or 103 wherein said garbage collector construct comprises a data object identifier and removal system operating according to the method defined in Claim 148 or Claim 150 and wherein said cleaner task makes available to said computer system for reuse data objects which have been identified as unused data objects.

154. The environment of Claim 86 or Claim 96 or Claim 97 including a computer architecture which supports a cleaner task; said architecture arranged, in an at least first mode of operation, to take and store elsewhere a value immediately prior to said value being over-written .

155. The environment of Claim 154 wherein said value which is stored elsewhere is accessible to a cleaner task. 103

156. The environment of Claim 154 implemented in hardware.

157. The environment of Claim 154 implemented in software.

158. The environment of Claim 154 implemented in microcode.

159. The construct of Claim 155 implemented in hardware. 160. The construct of Claim 155 implemented in software.

161. The construct of Claim 155 implemented in microcode.

162. The environment of any one of Claims 100, 102 or 103 wherein said garbage collector construct comprises a method of identification of unused data blocks in a computer system implemented as a cleaner task which can run concurrently with other tasks performed by the computer system; each data block having a unique reference; said method comprising the steps of:

163. The environment of Claim 162 wherein said cleaner task, during execution, takes into account the identity of those unique references which are indicated as having been displaced. 104

In combination in a scalable computing environment an object structure comprised of a plurality of objects controlled by a resource governor; each said object comprising a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at least:

(a) a time of creation field reflecting relative time of creation of said data record; (b) a pointer to a record field which contains information as to the location of another data record within said data structure; said resource governor following a method of allocation of usable resources; said method comprising a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; 105

said method comprising:

(a) instituting a special purpose task as a resource governor;

(c) said resource governor receiving from said resource consumers said used resources. The object structure and resource governor of Claim 164 further including a garbage collector or cleaner tasks which adopts a method of removal or release of unused objects, said method comprising in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order: 106

(b) said cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs; during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse; said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse .

107

AMENDED CLAIMS

{received by the International Bureau on 9 January 2001 (09.01.01); new claims 166-170 added; other claims unchanged (7 pages)}

(a) initiating said cleaner task, said cleaner task defining d set of unused objects which comprises initially all objects in said system;

(b) εaid cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs; during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse; said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse. In combination in a scalable computing environment an object structure comprised of a plurality of objects together with a garbage collector or cleaner task; each said object comprising a data structure for a computer; said data structure comprising a plurality of data records; each data record of said data structure comprising a plurality of fields including at. least: (a) a time of creation field reflecting relative time of creation of said data record; 108

(b) a pointer to a record field which contains information as to the location of another data record within said data structure; said garbage collector or cleaner task adopting a method of removal or release of unused objects, said method comprising in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at least one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of εaid tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order:

(b) said cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs; during traverse, removing 109

from said set of unused objects the handle, of each said object encountered during the traverse; said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing fiυni said set of unused objects the handle of each said object encountered during the traverse , The object structure and garbage collector of Claim 164 further including a resource governor said resource governor following a method of allocation of usable resources; said method comprising α method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising:

(a) instituting a special purpose task as a resource governor; 110

(b) said resource governor distributing said usable resources to said resource consumers; said resource governor receiving from said resource consumers said used resources. In combination in a scalable computing environment; a resource governor and a garbage collector; said resource governor following a method of allocation of usable resources; said method comprising a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising:

(a) instituting a special purpose task as a resource governor;

(b) said resource governor distributing said usable resources to said resource consumers; said resource governor receiving from said resource consumers said used resources; said garbage collector 111

comprising a garbage collector or cleaner task which adopts a method of removal or release of unused objects, εaid method comprising in a computer system which includes objects with references between objects forming an at least first directed graph; said computer system performing computing functions by way of a plurality of tasks each of which operate with or on said objects and at leaβt one of which tasks is designated as a cleaner task; the system having the property that it is possible for the cleaner task to discover all objects and all starting points; each of said tasks adapted to indicate to the cleaner task the identity of any handle which has been displaced; a method of identification of unused ones of said objects, said method comprising the steps of, in order:

(a) initiating said cleaner task, said cleaner task defining a set of unused objects which comprises initially all objects in said system,-

(b) said cleaner task traversing said directed graphs commencing at the respective initial starting points of said graphs,- during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse; 112

said cleaner task traversing all graphs for which the starting point is any handle which has been identified as displaced during execution of step b; and, during traverse, removing from said set of unused objects the handle of each said object encountered during the traverse . The resource governor and garbage collector of Claim 168 further including a resource governor,- said resource governor following a method of allocation of usable resources; said method comprising a method of allocation of usable resources to resource consumers in a computer system; said computer system of the type having a plurality of usable resources available for work or to be worked on and one or more resource consumers capable of consuming said usable resources whereby a usable resource is input to at least one of said resource consumers and is then consumed or worked on by said at least one resource consumer and is then output from said at least one resource consumer as a used resource; said method comprising:

(a) instituting a special purpose task as a resource governor;

(b) said resource governor distributing said usable resources to said resource consumers; 113

(c) said resource governor receiving from said resource consumers said used resoux'ces. A computer readable medium containing code which implements the scalable programming environment of any one of claims 1 to 28.