1.0	Executive Summary
2.0	Introduction to EUROPA
	2.1	Organisation
	2.2	Overall Aims
	2.3	Aims of SIGs
		2.3.1	Architecture SIG
		2.3.2	Applications SIG
		2.3.3	Implementations SIG
	2.4	Membership of EUROPA
3.0	Outline of EUROPA ||C++
	3.1	Functionality
		3.1.1	Basic Features of UC++
		3.1.2	The Eiffel// System	Introduction	Eiffel// Overview	Processes	Communication	Synchronization	Sharing	Implementation	Conclusion
		3.1.3	Particular Items for Dicussion
	3.2	"Environmental" Issues
		3.2.1	Interface Issues
		3.2.2	Support for Applications
		3.2.3	Patterns of Usage
	3.3	Basic Philosophical Issues
		3.3.1	Type or allocation
		3.3.2	Single against multiple threads
		3.3.3	Language extensions or "purity"
4.0	Promotion
	4.1	Promotion among hardware, software and applications vendors
	4.2	Links with other groups
	4.3	HPC Courses
	4.4	Communications
		4.4.1	World Wide Web
		4.4.2	Internet
		4.4.3	FTP site
		4.4.4	EUROPA ||C++ Archive
5.0	Timetable for Recommendations
6.0	Applications and Requirements
7.0	Membership

1.0 Executive Summary

This document outlines the work of the EUROPA Working Group on Parallel C++ (ESPRIT Project 9502).

In particular, it sets out an initial approach to the creation of a de facto standard parallel C++, ||C++. ||C++ will contain elements of several models of a parallel C++ to which EUROPA hopes that the community of workers in that area will contribute.

At this juncture, EUROPA wishes to stimulate debate among the constituency and has, therefore, decided to propose a model for what a parallel C++ might look like. The approach that has been adopted, although it is very much stressed that this is without any commitment at this point, is to set out UC++ and Eiffel; two approaches which have their adherents.

EUROPA wishes the community to discuss these as possible starting points. In order to start such a discussion, a number of questions are posed within this document, relating to various issues which need to be addressed if not immediately resolved.

This document sets out the timescales to be adopted by EUROPA in moving towards||C++.

2.0 Introduction to EUROPA

Purpose of this document

The EUROPA Working Group on Parallel C++ brings together a group of major users of object-oriented systems in order to agree a definition of a parallel object-oriented language derived from C++ which can be used to provide support for real end user applications of high performance computing (HPC).

This Roadmap sets out the stages through which the EUROPA Working Group ("EUROPA") will strive to meet that goal. It also sets out the results of the initial discussions within EUROPA'S Architecture SIG as an opening gambit in meeting this aim.

This document intends to be a "dynamic" document, inviting the community to make its input to the definition process. It will lead to a revised definition which will later be stabilised. In this way we hope to achieve maximum consensus and secure its broad adoption.

EUROPA welcomes comments from the parallel C++ community and contact points are given elsewhere in this document. various organisations have been invited to participate/make their comments known as part of the process, in addition, if organisations or individuals wish to make their views known or to take an active part in the process then they should contact EUROPA as soon as possible.


EUROPA aims to agree (and separately from this Working Group activity, implement) a parallel C++, ||C++, whose form will be agreed among its members. ||C++ will be supported by major European suppliers and will have the aim of becoming a de facto standard.

The objective is not to standardise, per se, but to develop a rugged definition of a parallel C++ which can be supported in a wide range of uses and which has been verified as able to support the sorts of applications that future ISVs will want to build. The result will, in virtue of its wide acceptance, be widely used and therefore close to standard.

In order to maximise market acceptance the implementation and underpinnings should be as widely accepted as possible. This will promote portability, maintainability and interest from systems implementors who wish to create bespoke systems. Additionally, (and perhaps crucially for solutions provision), it will give confidence to the end-user that the implementation is not simply vendor-specific.

||C++ will itself be the subject of initial standardisation and definition between LPAC and its partners. It is anticipated that the resulting definition will become the de facto European standard for (parallel) C++ on parallel and distributed systems. It will build upon discussion which have already taken place between LPAC and partners.

In order to achieve its aims, EUROPA brings together a number of major users and suppliers in order to pool their experience of different applications areas. These will verify that the system as defined is robust enough to support various classes of applications eg high performance database systems, large scale MIS systems, numerical applications, in which these vendors have particular expertise.

2.1 Organisation

The organisation of the Working Group, relative to the Special Interest Groups working within it, involves the Architecture SIG playing a pivotal role, defining the architecture and working principally with the Applicatins SIG in refining of that architecture. The implementation of this work will be carried out by the Implementatins SIG by the means of Real World Applications to form a de fact international standard.

2.2 Overall Aims

The EUROPA Working Group on Parallel C++ will define a common standard parallel C++ with an associated parallel abstract machine model. It will thus create a medium for the rapid prototyping and development of parallel applications in C++ which will be widely portable.

2.3 Aims of SIGs

2.3.1 Architecture SIG

The aim of the Architecture SIG is to define the architecture for EUROPA ||C++ in a three-stage process via a draft (which will be submitted to the Applications and Implementations SIGs for recommendations), revised and "final" versions.

2.3.2 Applications SIG

This group will refine the architecture devised by the Architecutre SIG to support real-world applications of the Application SIG's members.

2.3.3 Implementations SIG

The Implementations SIG will implement the work of both Archtitecture and Applications SIGs on real delivery systems.

The draft definition, defined by the Architecture SIG, once submitted for recommendations will be discussed at a plenary meeting to be held in late May/early June, whereupon a draft definition will be presented to the whole world. Recommendations from the Applications SIG and Implementations SIG will be integrated into the definition. The revised definition will be used by implementors and submitted to standards bodies.

Membership of EUROPA

The following (in alphabetical order) are presently taking part in EUROPA:

Where two country identifiers are shown, interest has specifically been shown across one or more components of a multinational organisation.

3.0 Outline of EUROPA ||C++

3.1 Functionality

The functionality of ||C++ is central to the work of EUROPA. Architecture SIG (ArchSIG) debated the means of best procedure at some length. It acknowledged that there are a number of different views as to how best to proceed towards ||C++. These cover a broad range of philosophical views as to how such a language might be constructed/defined. ArchSIG believes that the best way in which EUROPA can proceed is to attempt to fix ideas and to invite comment from as wide a section of the parallel C++ community as it can reach.

In order to fix ideas and to start to proceed towards a specification and in the absence of an aternative Parallel C++ implementation, ArchSIG suggest that UC++ be adopted as a basis for discussion only, without commitment to making EUROPA C++ identical to UC++. Rather the aim is to invite comment, with the aim of incorporating the best of the various models.

UC++ implies a particular mode; its salient features are described in 3.1.1 below and the associated documentatin [1]. An alternative model has been suggested to EUROPA by Denis Caromel from INRIA (see 3.1.2 and the associated papers [2] and [3]). However, it should be noted that there are many points of commonality in the two models.

The two approaches are outlined in the next sections.

3.1.1 Basic Features of UC++ Introduction

The UC++ Project is a collaboration between the London Parallel Applications Centre (LPAC), University College London (UCL) and International Computers Ltd (ICL). The aim of the work is to enable C++ to be used effectively and efficiently for programming parallel and distributed applications.

UC++ aims to set a standard for parallel and distributed programming with C++. One of the significant motivations behind the work on UC++ comes from the requirements of the industrial parners (ICL) who want to develop applications for their range of parallel machines (including the DRS 6000 and the Goldrush ranges, all of which are multi processor machines).

C++ was designed as a sequential programming language, but is increasingly being used to build parallel and distributed applications. A number of other researchers have looked at creating a parallel C++, with approaches ranging from using class libraries only to completely redefining the language in order to include parallel semantics. UC++ takes and intermediate approach that combines the use of libraries with minimal additional syntax to simply define and control parallel behaviour. This approach was arrived at by considering the kinds of programmes that UC++ would be used to write and trying to keep it as simple as possible. UC++ Overview

UC++ takes a pragmatic and minimalist approach to adding parallel features to C++. It does not aim to be comprehensive, safe, parallel language but instead provides two principle feature:

Active objects, which encapsulate processes.

Asynchronous function calls (or message passing), allowing active objects to be called without the caller being blocked.

These provide the programmer with the basic facilities to write parallel applications. Anything more sophisticated is either programmed explicitly or, ideally, uses classes from a library.

A previous project investigated ways of extending C++ to include parallel behaviour. This showed that using only class libraries was too awkward (especially if existing code was to be reused), while the option of redesigning C++ with full parallel semantics was too complex and effectively resulted in a new language. The work did show, however, that implementing the parallel behaviour via a library was viable, providing that minor syntactic and semantic extensions were made to C++ to control the library. This combination provided the right set of facilities, was relatively easy to implement and, importatly, provided the kind of features that application programmers were looking for. Active Objects

The unit of parallelism in UC++ is the "active object". Any class instance can be made active, which means it exists as a separate process. A parallel program is, therefore, a collection of communicating active objects, where communication takes place by calling the public member functions of active objects. This style of parallelism is directly derived from the standard object-oriented model, which fits well with C++, and provides coarse-grain (object-level) parallelism.

An active object is only accessible by calling its public member function; an object defines its own local address space (being a separate process). Pointers to active objects may be passed to any other active object, but all other pointers, and the data they point at, are local to the active object they were created by. The treatment of pointers is a compromise between providing a full global address space and redefining C++ so that pointers are not memory addresses. As pointers in C++ are already unsafe, this places the onus for correct use fully on the programmers, this is believed to be an acceptable compromise. Threads

Each active object executes one thread of control at a time; there is no internal multi-tasking. A thread of control is active within an active object when it receives a member function call request. Once active it will execute the member function either until it terminates or until control passes out of the active object during a call to another active object.

While a member function is being processed, all other incoming calls are queued. The next call in the queue will not be processed until either the current call terminates or the current call is blocked wating for another active object. The latter case provides a strictly limited form of co-routine and is important for removing a number of potential deadlock situations.

The single thread model of UC++ active objects has been chosen deliberately. It keeps the implementation simple and portable, while providing the level of parallelism that typical parallel C++ programs actually need. It has the advantage of avoiding the need for language-implemented facilities such as critical sections and exclusive access to variables. Semaphores, if needed, can be created using classes without the need to provide underlying primitive mechanisms. Activenew

When programming with UC++, an active object is created using the keyword "activenew", for example:

X*x = activenew X;

Activenew modifies the standard behaviour of "new" such that the new object will be allocated within a separate process. "X" can be any class and it is up to the programmer to ensure that the creation and use of the object are valid.

It is also possible to explicitly allocate an active object to a named resource using the "on" keyword:

Y*y = activenew Y on machineN

The resource name is bound to a physical resource when the program is loaded. The features allow UC++ programs to explicitly control active object allocation in heterogeneous environments and to force particular configurations of active objects. Remote Member Function Calls

Active objects are accessed by calling their public member functions. By default, function calls are synchronous, so that the caller waits until the remote object has finished executing the function. In order to allow parallel exectution to be initiated, asynchronous member function calls are provided. A new function call operator is used:

y->fn( @ 1,2,3@ ) ;// Asynchronous call

As soon as the funciton call has been made, the sending process is free to continue. If a result needs to be returned, it is up to the programmer to provide an explicit mechanism (eg, provide a third active object to act as a synchronising buffer).

When passing parameters between active objects, they must be marshalled and unmarshalled; that is, representation of the data is required that can be sent across the communication medium. The IOStream library provides a framework for serialising object representation so that they can be stored on disk and read back later. Further, C++ programmers are familiar with providing suitable I/O functions for classes and dealing with issues such as pointers. Thus, parameters are passed between active objects by exploiting the idea of streams; UC++ message passing uses streams to marshal and unmarshal objects when they are passed between active objects.

In order to pass a class object from one active object to another, the programmer needs to provide two stream functions which convert to and from a character based representation. The built-in types are converted using the existing stream function. Once the functions are in place, they will be used automatically when calling remote member functions. This approach has the advantage of being both simple and providing full control over object representations. UC++ Implementations

The current UC++ implementation was designed to be quick to implement and portable across a range of machines. It consists of two major components; a translator from UC++ syntax to standard C++, and a runtime library to provide process management and message passing. As UC++ is translated to C++ it can be used in any system that supports a C++ compiler. This has the advantages of avoiding any issues to do with full C++ compilation (which can be very complex) and needing to consider target code generation.

The runtime library is also written in C++, with generic interface to the output from the translator and backend that can be customised to different operating systems. All process management and message transport is assumed to be provided by the host operating system. Conclusions

UC++ has been designed as a practical way of using C++ for programming parallel and distributed applications. The combination of using class libraries, minor syntactic extensions to C++ and a translator from UC++ to C++, has been found to provide the most flexible and effective way of achieving the goals of the UC++ project.

3.1.2 The Eiffel// System Introduction

An alternative model was suggested to ArchSIG by Denis Caromel of INRIA (see associate paper [3]). However, it should be noted that there are many points of commonality in the two models.

Extension of the Eiffel language, the Eiffel// programming language is a parallel language supporting programming on multi-processors architectures, with asynchronous communications, strong typing and sequential processes. Eiffel// Overview

One of the goal of this language is to make easier programming of parallel programs. To achieve this goal, we aim at bringing to parallel programming the reuse aspect of object-oriented programming [4]. Together with the language, a programming method is provided for defining parallel applications.

We use the following technical features:

- communication towards a process: syntactically equivalent to a routine call,

- polymorphism between objects and processes: a variable statically defined with an object type (not a process) can dynamically reference a process;

- a systematic asynchronous communication between processes (but synchronous communication is also possible);

- wait-by-necessity (automatic future): a process is automatically synchronized when trying to use an awaited data (the result of an asynchronous call not yet returned by the called process;

- routines and requests are a weak version of first class objects: it allows for the programming of libraries of services, and libraries of frameworks for the programming of various concurrency control models [5]. Processes

This approach to a ||C++ standard was based on the introduction of a "process" type, as used in the Eiffel// system (say Eiffel parallel) developed by Denis Caromel.

This is based on the idea that an instance of a class can be a process, but not every instance of a class is a process. It is achieved by building a class of type "process" allowing all objects which the programmer wishes to have encapsulated in a process as heirs of this class. Passive objects (ie objects which themselves are not process objects) belong at run-time to a process object, thus giving a distributed structure of active objects encapsulating passive objects.

The approach adopted here is one which has been made from a consideration of the philosophical issues of a class-based approach to incorporating parallelism as opposed to the allocation method of parallelism which has been adopted in other implementations of ||C++. The two approaches raise various issues such as extensions to the existing C++ language base, syntactic changes and others.

Proposed syntax for ||C++:

class A : PROCESS, { ... Communication

In this proposal, communication between objects encapsulated in separate processes is via a message passing system implemented as asynchronous member function calls. The function calls between separate processes are implicitly (by default) asynchronous, thus allowing parallel execution of objects although a synchronous method is supplied (where the client object is suspended on the function call until the server object returns with a value - as happens in standard sequential C++, and in the member function calls between passive objects encapsulated within the same process object) but this must be stated explicitly in the function call or in the process definition. Function calls between passive objects encapsulated within the same process object is implicitly (by default) synchronous as happens in standard sequential C++.

Proposed syntax for ||C++:

p -> f ( parameters ); Synchronization

Return values from synchronous member function calls is as standard sequential C++, with a new mechanism provided for return values from asynchronous function calls. This mechanism is defined as an automatic future mechanism, with the "future" type being the default variable type for an asynchronous function call. In sending an asynchronous function call, the caller does not look at the return value until it is explicitly used for some computation. Should the value not have been returned at this point, a "wait" is automatically triggered in the client process object, suspending it until a value has been returned by the server process object. This implicitly adds a process/object synchronization mechanism between separate process objects.

Proposed syntax for ||C++:

v = p -> f ( parameters );

... // triggers a wait if v is awaited

if ( v.Awaited ) { // test the status of an awaited object

v.Wait // Explicitly triggers a wait if awaited Sharing

The semantics of communication between processes is a copy semantics for passive objects: all parameters are automatically transmitted by copy from one process to another. Of course, active objects are subject to a reference semantics: all processes are transmitted by reference from one process to another. As a consequence, shared objects (ie passive objects which are shared between process objects) are not allowed as such. The implication of this is that any passive object within a process which is to be shared between separate process objects must be made a process heir. This is simply achieved by inheriting from the process class, which also provides an automatic FIFO synchronization. Implementation

The Eiffel// language has been implemented as an extension of the commercial ISE Eiffel system, running on a network of workstations.

This proposal model does not address the issue of how to efficiently map process objects (processes) to suitable available processors. It is believed that this feature does not belong to the language level. We only provide for a mechanism of virtual machine names: each process can be created on such a virtual name, and at the system level, a dynamic mapping is made from virtual to physical processors, specified before each system execution. Various strategy can then be implemented on top of this basic feature.

The other important issue to consider it that although the current implementation of this (as a Eiffel// system) has adopted a single threaded approach, it is believed (although currently not implemented) that a multi-threaded approach may be required to usefully supply the level of medium to coarse grained parallelism that a system such as this is intended to supply. The solution we propose for this requirement is the use of compilation techniques in order to map several language processes into one operating system process, such taking advantage of multi-threaded architectures. Conclusion

From a few concepts and no syntactical extensions except for a special class (process), Eiffel// permits to build libraries for parallel programming:

- library of service routines in order to program the process activities,

- library of abstractions for concurrency control, a collection of classes which permit to tailor the programming of concurrency control to the particular application to program (implicit, explicit or declarative). Both these libraries are available for the application programmer, but also user-defined and extensible when needed.

3.1.3 Particular Items for Discussion

The above discussion raises several issues to be debated among the EUROPA WG and the broader parallel C++ community.

EUROPA wishes to initiate a discussion on the following issues, recognising that they do not form an exclusive list. Response is welcomed from interested parties. Kernel Library

Is the kernel library of classes for parallelism required or a library for abstraction of concurrency (ie implicit against explicit programming of processes)? Kernel Library Functionality

Particular features which have been suggested for inclusion in the kernel library are queue manipulation subsystems, synchronisation of communication, abstract control types, decision at class level, re-use of routines, replication, atomic classes, "service" routines. EUROPA wishes to canvas views on these as a list for inclusion. Does the community consider that there is additional appropriate kernel functionality? Synchronous/Asynchronous Operation

Should overloading of function for synchronous/asynchronous operation be introduced?

3.2 "Environmental" Issues

||C++ will not work in isolation; the exigencies of working in real applications situations dictates this. ||C++ is intended to support working in a wide variety of areas and must take due cognisance of the exigencies of inclusion in an environment which may contain legacy code, "alien" languages and a wide variety of architectures. It must also provide support for appropriate tools to make the development, support and long-term maintenance of code written in it a viable proposition, not only for research laboratories, but also for commercial applications developers such as ISVs.

EUROPA's ArchSIG therefore poses the following issues to the community:

3.2.1 Interface Issues

Any model defined for Parallel C++ must interface with external systems. In particular, the following issues must be addressed: Interface Libraries for Data Parallel Classes

Should a standard interface to libraries for data parallel classes be provided? In particular, the interface between ||C++ and HPF needs defining.

This could be done in collaboration with those working on HPF in other EC projects and those individuals are particularly invited to make their input. Interfaces to MPI/PVM

What are the requirements for interfaces to systems such as MPI or PVM? Would all features of these need to be incorporated? It should be noted that this might require a gateway, in view of the differences associated with the protocols involved. Support for Profilers and Debuggers

Support for profilers and debuggers is also required. The Application Programming Interface (API) needs to be able to "plug in" here, and the IEEE format for symbol tables must be examined.

EUROPA welcomes input from those actively working in the area.

Comments are welcomed.

These areas offer ||C++ the opportunity to integrate tools, etc, from other EC programmes as well as other national and international projects throughout the world. EUROPA welcomes input from as broad a range of interested parties as possible.

3.2.2 Support for Applications

A range of users from various applications areas (eg, scientific, industrial (the traditional Fortran community) and commercial) need to be supported. These must include novice as well as experienced users. Thus: Automatic Mapping

A certain level of automatic mapping should be provided, but this could be over-ridden by very experienced programmers. Useability/Efficiency Compromise

||C++ must make a suitable compromise between useability and efficiency.

3.2.3 Patterns of Usage

The range of applications which ||C++ must support implies a wide range of models of usage. Such models may be defined by sector - eg commercial, financial, scientific - as well as system architecture, eg heterogeneous, non-heterogeneous and by applications architecture, eg database, numerical, real-time, hybrid systems. Commonly occurring patterns must be identified, and the major algorithmic paradigms must be catered for.

3.3 Basic Philosophical Issues

The adoption of particular architecture presupposes the resolution of certain "philosophical" issues. EUROPA wishes the community to discuss the following issues:

3.3.1 Type or Allocation

Should a type or allocation style be adopted?

3.3.2 Single v Multiple Threads

Should the approach be based on multi-thread or single thread? Note that the former could be built onto the latter, but not vice versa.

3.3.3 Language Extensions or "Purity"

Language extension against no extensions - retaining the "purity" of the language, ie, given an industry standard C++, should we add to that language (which would require changing the parser) or should we make semantic changes by using a filter/text editor to detect additions to the basic language?

Discussion Papers

[1] T O'Brien (ICL), G Roberts, M Wei, J Poole, R Winder (UCL), A McEwan, (LPAC), "UC++: Parallel and Distributed Programming with C++", OOPSLA '94

[2] T O'Brien (ICL), G Roberts, M Wei, R Winder, J Poole, D Titcombe (UCL), A McEwan, M Plaxton (LPAC), "UC++ V1.4 Language and Compiler Documentation" LPAC and UCL Department of Computer Science Technical Document (1995)

[3] D Caromel (INRIA), "Towards a method of Object-oriented Concurrent Programmng", CACM, 36,9 pp90-102 (1993)

[4] Caromel D., "Concurrency and Reusability: From Sequential to Parallel", Journal of Object-Oriented Programming, (3) 3, September, 1990.

[5] Caromel D., "Programming Abstractions For Concurrent Programming", TOOLS PACIFIC'90, 1990, November, Sydney, Australia.

4.0 Promotion

EUROPA will actively seek to promote the work that it is carrying out. It will achieve this through:

i The promotion of its work amongst hardware, software and applications vendors;

ii links with other groups throught Europe and the world;

iii the promotion of its work in education.

EUROPA will also make extensive use of the World Wide Web (WWW) and Internet in support of its activities.

4.1 Promotion Among Hardware Software and Applications Vendors

EUROPA is very conscious of the need for participation from as wide a variety of end users as possible. Without the participation of hardware, software and applications vendors, EUROPA cannot achieve its aims. Further, it requires them to take an active part in the process and thereby to contribute to EUROPA's aims.

To this end all three classes were invited to participate in the Architecture SIG, ArchSIG; there is an applications SIG, AppSIG, which will be led by applications vendors CAP Gemini; and an implementations SIG, ImpSIG, which will be led by a hardware manufacturer and will address the issues surrounding implementation of ||C++ on various platforms.

Naturally AppSIG and ImpSIG pre-suppose the existence of a defintion of ||C++. AppSIG and ImpSIG are being asked to consider the results of the deliberations of ArchSIG as a starting point and to make comments upon the suitability of the models proposed above with particular regard to their areas of competence.

4.2 Links With Other Groups

Links with other groups will be established; this will include other groups working on related projects within Europe, and world-wide, particularly in the USA. In order to initiate the latter, Russel Winder of UCL will visit major groups in the USA known to be working on parallel version of C++. Other persons from Europa interested in contribution to the EUROPA work will be invited to participate in the meetings of the Working Group, and the Plenary meetings (see section 5.0), together with people from potential user communities (covering both Scientific/Industrial and Commercial).

EUROPA has already attempted to contact many of the active groups in the world. If you have not been contacted, please contact EUROPA via one of the addresses listed below.

4.3 HPC Courses

The London and South East Centre for HPC (SEL-HPC), funded by UK JISC, is preparing a teaching package for Parallel C++, based upon UC++. This will consist of course notes, code and teaching materials. They will also give courses based upon this material.

A mailshot will be prepared relating to the course. Seeking expressions of interest and inviting input as to content, etc. The cycle is planned so that the course will be available for use during the next academic year. Those interested in contributing are advised to contact Prof Heather Liddell ( or Mr John Steel at LPAC/SEL-HPC (

Those Higher Education Establishments who come under UK JISC will be eligible for free attendance at course and copies of course material. Further copies of course material may be made available through the Commission. However, SEL-HPC reserves the right to levy a small charge to cover its costs.

4.4 Communications

EUROPA intends to use electronic as well as paper communications as part of its means of dissemination of information. The following cover major areas of interest to Members, Associates and Participants.

4.4.1 World Wide Web

EUROPA has set up a group of WWW pages which may be reached at:

The WWW pages contain both public and private areas. Admission to the private areas is for members, associate members and participation for non-public discussion including SIG discussions and proceedings, minutes, etc.

Admission to the private areas is at the discretion of the Chairman of the EUROPA Working Group who can be reached via email sent to the address in 4.4.2.

4.4.2 Internet

The EUROPA directorate can be mailed at:

4.4.3 FTP site

For retieval of copies of the latest version of UC++, please look in EUROPA's anonymous ftp site, which is:

directory is /pub

4.4.4 EUROPA Parallel C++ Archive

EUROPA has also set up an archive of known parallel C++ documentation which can be accessed via the WWW pages. All are invited to submit relevant papers to it. Instructions on how to do so are given interactively.

5.0 Timetable for Recommendations

6.0 Applications and Requirements

Definition of classes of application to be supported and their associated requirements. This will require work by the AppSIG and discussion between ArchSIG and AppSIG. Input from the ImpSIG will also be required.

It is intended that EUROPA ||C++ will support the following applications (amongst others): Parallel databases, commercial applications, distributed systems, numerical modelling.

7.0 Membership

There will be two classes of members: Members and Associates Members together with a third class, "participant". The latter will be "on the mailing list".

Some funding is available for Members through the Commission of The European Union (see below).

Note 1: The Governing Contract relates to the contract between the Community and LPAC/QMW governing the operation of EUROPA.

Note 2: Under the Governing Contract, funding for travel and accommodation is only available for those bodies approved by the EU for fuding. Those wishing to join as Members/Associate Members who are in any doubt should contact EUROPA c/o EUROPA will then provide, or seek clarification where appropriate.

Note 3: Those taking part in EUROPA may not claim funding unless they have previously lodged a Membership form with EUROPA which has been approved for funding by the EU where appropriate.

Full Members

  1. Full Members will have:
    1. Voting rights - one per organisation;
    2. shall be eligible for funding under the Governing Contract up to such limits as may from time to time be agreed;
    3. the right to attend all meetings (Plenary and Technical) subject to such limits upon numbers as may be agreed and claim reimbursement for qualifying expenses under ii up to such funding limits as may from time to time be in place;
    4. access to all working documentation, etc, which shall be generated by the Working Group;
    5. shall be required to sign a standard Confidentiality Agreement covering work undertaken and background information, subject to such limitations as may be imposed by the Governing Contract.

Associate Members

  1. Associate Members shall:
    1. Not have voting rights;
    2. not be eligible for funding under the governing contract up to such limits as may from time to time be agreed;
    3. have the right to attend all meetings (plenary and technical);
    4. have access to all working documentation, etc, which shall be generated by the Working Group, subject to approval of its release by the full members;
    5. may be required to sign an undertaking of confidentiality. A further category "Participant" has been added to the structure outlined within the Prospectus. This will refer to those parties who are held on the Group's mailing list.

In order to comply with CEU regulation regarding the drawing of funds from EUROPA for travel and subsistence.

EUROPA Home Page