Edmond Desmond a, Steven Adler a, Lars Ewell a,,John Haggerty a, Hyon Joo Kehayias a, Steve Pate b , Martin Purschke a,Ryan Roth c ,Chris Witzig a F.A. Kirsten² and E.J. Barsotti³

The PHENIX online control system is responsible for the configuration, control and monitoring of the PHENIX detector data acquisition system and ancillary control hardware. The detector consists of 11 distinct subsystems which are distributed physically and partitioned logically while ultimately being combined into a single operating unit. The online system consists of a large number of embedded commercial and custom processors as well as custom software processes which are involved in the collection, monitoring and control of the detector and the event data. These processing elements are distributed over a diverse set of computing platforms including VME based Power PC controllers, Pentium based NT systems, and SUN Solaris SPARC processors. CORBA has been adopted as the standard communication mechanism for PHENIX online system. This paper will describe the design, implementation and use of CORBA to achieve a uniform and platform independent control environment while providing for the access, control and monitoring of the online detector elements over the distributed and diverse control environment. Synchronous and asynchronous communication issues will be discussed as well as the development of CORBA compliant components which were developed to achieve client / server isolation and deterministic system behaviourbehavior. The use and interaction between JAVA based clients and C++ based CORBA servers to further achieve a platform neutral environment will be presentedDetailed instructions are given for preparing manuscripts in camera-ready format for publication in a Conference Issue of the Transactions on Nuclear Science. Papers published in Conference Issues are reproduced directly from the manuscript prepared by the author.

These instructions are intended to insure that papers will be reproduced clearly and in a uniform size and format. Authors are required to follow them explicitly.

Style instructions for various word processors are available.

I. Introduction

The PHENIX online system is responsible for the configuration, monitoring and control of the PHENIX detector. [1] The detector consists of up to 411,172 detector elements which are distributed over 11 sub detectors and 2 physical arms. These detector elements are read out through a data acquisition system which includes some 440100 DSP processors which are occupyconfigured among 110400 - 500 VME based boards and in over 1030 VME crates each of which are controlled by a Motorola Power PC processor running VxWorks. [21] In the PHENIX online system events are collected in an The data events are collected from these DSPs into an event builder which will be composed of up to a 32 by 32 an array of up to 32 by 32 Pentium processors running the NT operating system. [32] Operator control, monitoring and archiving applications will execute on Sun Solaris, IRIX and Linux based computers. With such a diverse computing environment, it was imperative that the control code that was developed be reuseable over the different platforms. In order to develop an online system which could be developed independent of and operate transparently over these diverse platforms, CORBA was chosen as the mechanism for distributed object communication. The PHENIX online system components were developed primarily in C++ to take advantage of object oriented design techniques. Code was developed with the native Sun C++ compiler being used on Solaris, GNU g++ for VxWorks development, and Microsoft's C++ v6.0 for NT. Client applications are written in C++ and Java.

IONA Technologies Orbix [4] was chosen for the implementation of CORBA. IONA provides a CORBA implementation for all the above platforms including the Motorola Power PC which was essential for the PHENIX online system. IONA's OrbixWeb was chosen for the Java IDL compilerThe IEEE Transactions on Nuclear Science (TNS) is a publication of the Institute of Electrical and Electronics Engineers (IEEE) that is issued six times a year. Each issue has a thin section consisting of papers that were submitted directly to TNS. These papers have been re-formatted by IEEE into a very uniform, standard format. Some issues also include a thicker section which is a Conference Issue. Conference Issues contain only papers that originated in a specific IEEE conference or symposium. Examples are the Nuclear Science Symposium/Medical Imaging Conference (NSS/MIC) and the Real-Time Computer Conference (RTC).

The papers in a Conference Issue are published directly from camera-ready manuscripts that are prepared by the authors. It is imperative that such manuscripts be prepared in a manner that results in a uniform appearance. This document presents detailed instructions for the formatting of such manuscripts. This document also serves as a model for a properly formatted manuscript.

The object of these instructions is to result in camera-ready manuscripts that have a uniform appearance that is as close as is practicable to that of papers in a "thin" issue (See, for example, Part II of Vol. 43, No.1, February 1996).

To achieve this uniform appearance, it is required that authors follow the instructions in this document. Manuscripts that do not conform may be rejected unless the appearance is corrected.

In this document, the words ìpaperî and ìmanuscriptî are used. ìPThe word ìpaperî refers to the technical content of the document prepared by the author. ìManuscriptî refers to the pages that convey the technical content of the paper.

II. ____________________________

of the document prepared by the author. The "manuscript" consists of the pages that convey the information in the paper.

Architecture Description II. The Structure of a Paper

The abstract should contain from 50 to 200 words and should concisely state what was done, how it was done, principal results and their significance. The abstract will appear later in various abstracts journals and should contain the most critical information of the paper.

A major design goal of the PHENIX online system was to decouple the knowledge of client application from a detailed knowledge of the remote implementation objects

A major design consideration in the development of the online system was to decouple the client application software from the knowledge of the location and implementation of the software components. A secondIn addition, it was a design goal of the online system to develop a software componentsframework which would be reusable over the different platforms and which would use a common set of services and components which provide the mechanism for by which distributed client applications to locate, obtain object references, and invoke methods on those objects. Reusability requires that the same code and thus the same API be useable on the different platforms Such a It was desirable that the software framework of components should also provide a common mechanism by which remote objects are created, managed and deleted. These requirements require that this framework must run on all of the above platforms and environments. Clearly one of the issues of such a distributed system is to hide the differences in network and processor architecture from the applications. The different APIs which are prevalent between NT and Solaris for network access must also be hidden from the application program. Further, it is necessary that the client applications use the same methods to access and invoke operations on the required remote objects. In order to meet these requirements, CORBA was selected as the communication standard to achieve these objectives.

The Introduction expands upon the Abstract, presenting background information on the work, the history of the subject matter, why the work presented in the paper was done, and why it is significant.

CORBA provides a platform independent and transparent mechanism for communication between distributed objects through the use of an Interface Description Language ( IDL), and through the use of proxy objects. Objects are described to a client application through the IDL description. This language defines the interface only of and object. It describes the objects attributes, methods, method arguments and exceptions. This description is independent of the language in which the object being described is implemented. Compilation of this IDL object description results in the creation of client stub code which is implemented in the language for which the IDL compiler is bound. When a client application binds to a CORBA object, this stub code is used to create a proxy object for the remote object. Invocations of methods to the remote object are implemented as calls to the local proxy object. It is the proxy object which does the communication with the remote object, taking care of communication details such as byte code marshalling and socket connections. To the client application then, remote object method invocation looks exactly like an invocation on a local object, which, in fact it is. The result has been that client applications have been built without knowledge of the platform of the remote target object.

By using CORBA for remote communication, the server application where built with a high degree of portability. Since no application code has to deal with low level communication protocols or platform dependent network APIs, the server applications where almost entirely ported between the Solaris, NT and IRIX platforms. Some code modification were required however, when porting application components between the Solaris and VxWorks environments. This is due to the current lack of support in Orbix for the CORBA 2.0 IDL to C++ mapping in the VxWorks environment. This difference in C++ mapping is expected to be eliminated with the release of CORBA 3.0 for VxWorks from IONA.

The CORBA communication protocol used throughout the online system is the Orbix proprietary protocol. This is due to the above mentioned lack of support for the CORBA 2.0 standard. The CORBA 2.0 standard currently supports the Internet InterOrb Protocol (IIOP). The online system will migrate to the IIOP protocol when it becomes available for VxWorks.

Client applications may access server component objects through either synchronous or asynchronous communication mechanisms. Clients issue synchronous communication calls to obtain state information about a particular object. State information is typically contained in the attributes of an object. Clients access attributes through through accessor methods of an object. Accessor methods execute synchronously and thus block the caller until the method completes. All CORA IDL methods, which return a value, execute synchronously.

Attributes of objects are identified by an attribute identifier in the IDL file which describes the CORBA interface of an object. When the IDL file is compiled with the IDL compiler, each attribute causes the generation of an accessor function. Each accessor function signature defines a return parameter through which the attribute is returned. The object attributes may be a basic IDL data type or a complex user defined type.

The following example shows an attribute definition in an IDL file and the resulting CORBA accessor function.

While synchronous method invocation is used to return state information, all communication to cause an object to take some action takes place through asynchronous communication. The use of asynchronous communication provides for a further decoupling between client and server applications and provides for a more robust system. With asynchronous communication client applications do not need to have direct connections to every object they need to interact with. In addition, operations can take place in parallel in that invocations via asynchronous calls do not block while the call is being completed. This communication is carried out through a service called the Event Notifier which is described later in this paper.

The body of the paper presents the work in a clear and understandable manner. The body is normally divided into sections, subsections and sub-subsections as required to enhance the readability of the paper.

Readers of TNS are expected to be technically knowledgeable, but not necessarily specialists in the subjects being treated. Sufficient detail should be given that someone acquainted with the field of work (not necessarily an expert) can understand the relevance of the work, how it was done, and possible applications of the work. On the other hand, papers should not be longer than necessary to carry the significant information. For example, detailed operating instructions for an electronic device are usually not appropriate in a TNS article. Most papers will contain between three and eight pages. More than eight pages is rare and strongly discouraged.

Tables and figures may be included where they aid in the presentation of the work in a significant manner. Tables and figures should be sized such that they contrast appropriately with the text in the paper and thus are not excessively large or small.The decouplingdecoupling of servers from client application goes beyond how the object is invoked, and includes how a object is located and how the object reference is is obtained and how an invocation is made to a remote object. Three main components were developed to provide for these functions. These components are a naming service, an event or message delivery server and an object manager component

Before an invocation can be made on a remote object, the client application must obtain a reference to that object. cClient applications obtain references to servers through a CORBA naming service. In the PHENIX online system, all objects are known by an ASCII name string. This string is defined according to an agreed upon convention which identifies the type of component being addressed and the detector system of which it is a member. This convention will be described later. The naming service provides a mapping between these ASCII names and a reference to an object. When a CORBA server starts up, it registers its name with the nameserver. Client applications gains access to online services by requesting a reference for a named service given name. The nameserver itself is addressed by an ASCII name, known as its marker, which is known by all servers. The nameservice has methods for registering objects with the service as well as for resolving or obtaining the reference to objects. These methods are defined in the IDL description of the nameserver below:

interface nameserver {

exception Reject { string reason ; };

exception NotFound { string reason;};

void BindName ( in string objectname,

in Object objectReference )

raises ( Reject);

};

Figure 1: Nameserver IDL description.

Only components which perform a service are registered with the nameserver. Component objects which perform specific tasks, are accessed indirectly through a component called an object manager which will be described later.

The nameserver is automatically notified when a registered server is no longer available through the use of the CORBA IO Callback mechanism. This mechanism provides a means for a registered function to be called when a client disconnects from a server. In Orbix, each connection to a client takes place through a file descriptor. This file descriptor is assigned when the connection is made and freed when the connection is broken. The callback mechanism is passed the file descriptor when connections are made or broken. The register function is then used to remove from the nameserver the name and object reference to the object that was associated with this connection. Thus the nameserver maintains up to date lists of servers. This same mechanism can be used to restart servers that have gone down. Anticipated use of this mechanism is to notify A further enhancement will be to provide notification to operators of the loss of critical servers.

Client applications may access server component objects through either synchronous or asynchronous communication mechanisms. Clients issue synchronous communication calls to obtain state information about a particular object. State information is returned through accessor methods of an object. This information is typically contained in the attributes of an object. Accessor methods execute synchronously and thus do not return until the method completes. All CORA IDL methods which define a parameter as an out parameter or which return a value, execute synchronously.

Attributes of objects are identified by an attribute identifier in the IDL file which describes the CORBA interface of an object. When the IDL file is compiled with the IDL compiler, each attribute causes the generation of an accessor function. Each accessor function signature defines a return parameter through which the parameter is returned. The object attributes may be a basic IDL data type or a complex user defined type.

The following example shows an attribute definition in an IDL file and the resulting CORBA accessor function.

While synchronous method invocation is used to return state information, all communication to cause an object to take some action takes place through asynchronous communication. The use of asynchronous communication provides for a further decoupling between client and server applications and provides for a more robust system. With asynchronous communication client applications do not need to have direct connections to every object they need to interact with. In addition, operations can take place in parallel in that invocations via asynchronous calls do not block while the call is being completed. This communication is carried out through a service called the Event Notifier.

The event notifier provides routing of messages from a client to one or more remote objects. In addition, this service provides the mechanism for the decoupling of clients from servers. The event notifier provides an implementation of the Observer design pattern. [5]is a server which is registered with and accessed through the nameserver. Objects which perform some action, register themselves with the event notifier. Each object registers its name and its object reference with the event notifier. Wh

The Event Notifier works by first having an Oobjects that has an interest in receiving an asynchronous message or eventevent to be subscribe to receive those eventsregistered with the Eevent Notifier. Registering an object to receive an event results in the creation of a mapping between a character string representation of the object character name and the CORBA object reference for that object. This mapping is maintained by the Event Notifier. When a client application wishes to send a message or command to a remote object it constructs an event message. This message is a CORBA structure which contains a name of the target object, the name of the sending client, an event number and any data which is to be sent to the destination object. Once an object is registered, When the Event Notifier receives the request to send the message, the Eevent Notifier lookscan look for the nameup, and associate its character name identifier with the if found invokes a takeevent method on the target object.reference to the object . When an object is registered with the Event Notifier, an event list is submitted with the request for registration. The event Notifier will use this event list to filter events, and to only pass along those events for which the object wishes to be notified of. Applications use the Event Notifier by first obtaining a reference to it from the ONCS Name Service which will be described below Service. Once a reference to the Event Notifier has been obtained, a client application can send a command to any registered object by invoking the sendevent method of the Event Notifier. The sendevent method takes as an argument a structure which contains the identity of the destination object, an event identifier and any auxiliary data which is required by the destination object for this command.

The Event Notifier has public methods to register, and remove an object as well as to send events to any registered objects. These public methods are defined in the Interface Definition Language (IDL) file for the Event Notifier and is given below in Fibure 2..

interface EventNotifier {

typedef sequence<unsigned long> eventIdlist;

// subscribe an object to receive events in the eventidlist

oneway void subscribe( in eventIdlist eventidlist, in string destobjname,

in Object eventreceiver );

};

Figure 2: Event Notifier IDL description.

The Event Notifier is modeled after the OMG CORBAservices Event Services [65]. This is a service which is defined by the OMG to provide indirect communication between event producers and consumers. This service employs a construct called an event channel. The event channel appears to be an object which implements either a push or pull model of events. That is, event generators can push events into the event channel and events are pushed on to the event receiver. Alternatively, an event receiver can request or pull events from the event channel and the event channel will in turn pull any pending events from the event supplier. The ONCS Event Notifier mechanism is patterned after the push push event model.

Before a client application can invoke an accessor function on a remote object, it must obtain a reference to that object. Object references for any object are obtained from an object manager, an instance of which resides in each CORBA server. The object manager is a component which is responsible for the creation, deletion, and management of all component objects in the online system. The object manager stores an object name, and reference for each object created. It also will search for and return a reference given an object's ASCIIascii name string.

Exception handling and error reporting is handled in two different ways in the PHENIX online system according to whether the method which generates the exception has been called synchronously or asynchronously. All synchronous CORBA methods are defined, in the online system, to generate exceptions. For each exception defined in the IDL file, the IDL compiler generates a class which is of the same name as the exception. The constructor for this class takes a parameter for each member of the exception. All method exceptions are defined in the online system as having at least one member which is a string value. This string value is used to return a string representation of the reason for the exception.

Operations which are invoked on remote objects via asynchronous CORBA calls cannot return information to the caller either through return parameters and cannot return exceptions. These asynchronous method calls are defined in the IDL file as oneway operations. Clients do not block on these calls. The function calls themselves are not guaranteed to complete. In order to return operation completion status on these functions, a return event message is generated in the server side object whose method is being invoked. The message is returned to the source object whose name is a source Object field of the message that was sent.

III. Use of Java clients to interact with C++ based servers.

Client applications which require run-time access to the online system have been written in both C++ and Java. However Java is becoming the language of choice for the PHENIX online system monitoring and control applications. The well known portability and expanding libraries of support classes are strong incentives to use Java for client applications. Java applications, and applets are limited in their access to remote objects. Java applications may access remote objects either through the Java Remote Method Invocation (RMI) package or through native methods. However RMI limits access to servers written in Java, while native methods limits the portability of the application to the language and machine for which the native language interface was written.By using CORBA as the standard for interprocess communication, these strengths are extended by providing language and platform independent access to remote objects.

CORBA based Java applications access remote objects through a local proxy object, just as with CORBA application which are written in C++. These proxy objects are implemented in stud code which are generated as a result of the compilation of the IDL files which define the interface to the target objects.

Java client programs can be developed to run as applications or as applets. When developing Java programs as applets, the normal Java security restraints apply. The Java security model limits an applet to access the server from which the applet was launched. [8] This limitation applies whether the application uses CORBA or not. In order for applets to use CORBA from a browser , such as Netscape, to access remote objects which are on different platforms, each invocation of a CORBA method must be given permission through the brower security manager. Applets must also be cognizant of the browser for which it is being developed as the archiving file format is different between Internet Explorer and Netscape. The browser in which the applet is running must also be known as the security API is also different between these two browsers. The Java security model places other restrictions on what resources an applet may have access to. While some online Java programs have been written to run as applets, in order to simplify the development environment all Java programs are currently being written as applications.

Inprise'sUse Jbuilder [7] is being used as the development environment for many of the Java applications. This product provides a visual drag and drop integrated development environment for rapid interface development. The graphical interface of the Java applications are being built using the Java Swing class library [4]. This library is not tied to the graphical environment such as Windows or Motif on which the application runs.

for Java Development.

When Java applications execute, each class that is accessed is downloaded from the server at runtime. This can result in slow execution time. In order to improve application performance, Java client application classes are collected into Jar files. The Jar file, which is a compressed archive format file, is downloaded once when the application is started.

client applications developed for the PHENIX online system programs When developing Java applications as applets, the normal Java security restraints apply. This is true whether the application uses CORBA or not. This means that, for applets that are to be executed from a browser, such as Netscape, each invocation of a CORBA method must be given permission through the brower security manager.

The use of CORBA has succeeded in the goal of providing a platform independent development and operating environment. Client application code is independent of the target server platform while server development is highly portable. The migration to the use of IIOP protocol will allow enhanced functionality with the use of CORBA 2 and 3 services, such as the naming service and Event Notification Service. Work on improving the robustness of the system with the implementation of serialization of objects through the use of the CORBA loader service will continue.

The servers and object manager components reside execute in NT, Solaris, and VxWorks environments. This code was ported with only minor modifications between ports to provide for the different IDL to C++ mappings. APIs for spawning tasks that were implementation dependent. The CORBA components themselves were ported with no change other than the recompilation of the IDL files for each platform. Development on NT was done through Visual C++. All development on Solaris was done with the native Solaris C++ compiler version 4.2. All development on the Power PC in VxWorks was done with the gnu C++ compiler.

IVX. Acknowledgments

This section is normally used to acknowledge contributors to the work who are not listed as authors of your paper, or to acknowledge funding agencies.Work supported by the U.S. Department of Energy, under Contract No. DE-AC02-76CH00016.

Authors may optionally include a Conclusions section at the end of the body of the paper. The Conclusions sectionIt can be used to summarize the salient points of the paper, the important results, the state of completion of the work, and further work that needs to be done. This sectionIt should not, however, simply repeat statements made in other parts of the paper.

The Acknowledgments and References sections are at the very end of the paper. The Acknowledgments section can be used to recognize sponsors of the work, or others who have contributed to the success of the work.

It is important to include a References section. It should give references to previous works that were an important foundation to the development of the work described in your paper. Where specific manufactured products are mentioned in the paper, the name and address of the manufacturer should be cited in the References. (See also Section V in this paper.)

III. Manuscripts

This document is an example of the required layout and format of manuscripts submitted for publication in the Conference Issue of an NSS/MIC or an RTC.

Manuscripts must be printed on only one side of a page. The paper size must be U.S. Letter size paper (8.5 x 11 in) or A4 Letter paper (21.0 x 29.7 cm). They must be printed on a printer having 300 dots/inch, or better, resolution.

Manuscripts must have two columns per page. Column parameters are listed in Table 1.

Table 1

Column Parameters.

The printed area of the manuscript should be centered on the page. Appropriate margins for accomplishing this are in Table 2.

Table 2

Margin specifications for the two paper sizes

A proportionally-spaced, serif font is required. The strongly preferred font is Times, which is available in most word processors including LATEX (in LATEX, an equivalent font is acceptable if Times is not available). An exception to this is that lettering in figures is typically of a sans serif typeface (e.g., Helvetica or Geneva). The main body of the manuscript is in 10 point font. The line spacing should result in about 6 lines per inch. Table 3 summarizes the font sizes to use in various parts of the manuscript. A non-proportionally-spaced font such as courier should not be used in the text, in figure or table captions, or within a figure or table.

Center the title on the page so it runs across the upper portion of both columns on the first page, but stays within the left and right margins. The title should be in a 14 point font, using upper and lower case letters (not all capitals).

The initials and last name(s) of the author(s), their organizations, and their mailing addresses should appear on separate lines, in upper and lower case letters. In the case of multiple authors, initials and last names of all authors should appear together, one or more authors to a line. Likewise, authorís organizations and mailing addresses should appear together, preferably one to a line when practical to do so. Use 12 point type for author names and 10 point for organization names and addresses. Allow 0.4 in (1.0 cm) between the organization address(es) and the top of the columns on page 1. See the title of this document for an example.

In this document you will see examples of the proper formats for section headings and for table and figure headings. Specifications for these headings are given in Table 3. Note that there must be a double space between the enumeration character(s) and the text of the heading.

The above is an example of a subsection heading.

The above is an example of a sub-subsection heading.

IV. Figures and Tables

Where possible, place figures and tables on the same page as the place of their first mention. All figures and tables must be given sequential numbers. Tables must have a caption at the top as shown in Table 1. Figures must have a caption at the bottom as shown in Figure 1.

Figure 1: Example of the placement of a figure and its caption in a single column.

Figures and tables should preferably fit within a column. However, if necessary because of the amount of detail, they may extend across both columns (but may not extend into the margins). Table 3 is an example of a two-column wide table.

Table 3.

Required type sizes for the various parts of the manuscript

Lettering in figures should be large enough to reproduce clearly. Such lettering may be in a sans serif typeface, to emulate hand drawing.

Photographs should have a glossy finish (not a half tone). Black and white photographs are preferred, but color is acceptable if the contrast is sufficient to reproduce well when printed in black and white.

If your figures are prepared separately from the text, they must each be securely attached to your manuscript in the appropriate places.

V. Bibliographic References

All bibliographical references should be numbered in sequence as they appear in the paper. They are to be listed at the end of the paper in the References section. Examples of correct format for several types of references are at the end of this document [1], [2], [3]. ]. When referring to a reference in the text, place the corresponding reference number in square brackets as illustrated in the previous sentence. Note that journal names must be in italics.

VI. Equation Numbers

Each equation must be in a separate line and must be accompanied by a sequential equation number enclosed, in parentheses (1) which is flush with the right-hand margin of the column. For example:

AO = (1)

VII. Page Numbers

It is preferred that authors not number the pages of their manuscript. If you do, number them lightly in blue pencil on the bottom or back side of each page. DO NOT print page numbers on your manuscript!

VIII. Additional Information

An IEEE publication that presents additional information to authors is available [4]. [Note that certain parts of that publication are not applicable to camera-ready manuscripts (e.g., Section V.)]

Appendix I of the reference mentioned above [4] also includes lists of preferred unit symbols (e.g., A for ampere, etc.) which should be used in your paper.

Remember that many readers are not as close to the subject area as you are; many acronyms will be meaningless to them. Therefore, acronyms special to your field must be defined the first time they are used. Examples include: BER (bit-error rate), VCO (voltage-controlled oscillator), and LBNL (Lawrence Berkeley National Laboratory).

Acronyms that are general to engineering need not be defined (e.g., JFET, ROM, A/D). Further examples are given in Appendix II of the reference [4].

If there is more than a small amount of text, figures, etc. on the last page of the manuscript, it is preferred that this information be roughly divided in half with the first half put at the top of the left column and the second half put at the top of the right column as is the case with this page.

Columns on a page should start at the same height and should be as close to the same length on a page as is practical. For example, the space before the subsection heading, C. Format of Title of Paper and Authors' Names, on the second page of this document has been removed such that this subsection differs from itís style definition thus allowing the right column to begin at the same height as the left column. Likewise spaces before this pageís top left subsection heading and top right section heading have also been removed so that the columns not only start at the same height but at the specified margin 0.75 in (1.9 cm) from the top of the page. Columns should end at or near the specified bottom margin of 0.75 in (1.9 cm).

IX. Acknowledgments

IX. Acknowledgments

This section is normally used to acknowledge contributors to the work who are not listed as authors of your paper, or to acknowledge funding agencies.

X. References

X. References

NOTE: This file is conftns.doc dated 2/23/99.

If further information on the formatting of manuscripts for Conference Records is needed, contact the Conference Editor for the particular conference in question. Conference Editors for the NSS, MIC and RTC are as follows:

Charles L. Britton, Ph.D.Edward J. Barsotti Prof. Edward J. HoffmanBenjamin M. W. Tsui, Ph.D.

Oak Ridge National Laboratory37W948 Tanglewood Dr. UCLA School of MedicineCB #7575, 152 MacNider Hall

P.O. Box 2008, MS 6006Batavia, IL 60510 USA 10833 Le Conte Ave.The University of North Carolina at Chapel Hill

Oak Ridge, TN 37831-6006Phone: (630708) 879-1245 B2-086 CHS

Phone: (423) 574-1878FAX: (630) 406-9735 Los Angeles, CA 90095-6948 USAChapel Hill, NC 27599 USA

FAX: (423) 576-2813E-mail: confedit@fnal.gov (630) 879-1245 after September 1, 1996 Phone: (310) 825-8851(919) 966-5659

FAX: (708) 406-9735 E-mail: nssconfedit@ornl.gov FAX: (310) 825-4517(919) 966-2963

(630) 406-9735 after September 1, 1996 E-mail: ieee_ejh@mail.nuc.ucla.edutsui@bme.unc.edu

E-mail: confedit@fnal.gov

Donald R. Machine, PEJean-Pierre DufeyFred Kirsten

Scientific Systems International, Ltd.ECP Division, CERN3261 Gloria Terrace

1110 First St.

Los Alamos, NM 87544CH 1211 Geneva 23, SWITZERLANDLafayette, CA 94549 USA

Phone: (505)662-671241 22 767 4408(510) 932-1918

FAX: (505)662-671241 22 767 9425(510) 933-3456

Office E-mail: d.r.machen@ieee.org

A number of files of useful publishing information for authors is available and a current review status of NSS papers is available via the World Wide Web at:

The publishing information includes directions for setting certain word processors, such as Microsoft Word, Word Perfect and LATEX, to achieve this format. Also available are source files for this document in Microsoft Word and LATEX.

NOTE: This is ConfTNS-1C dated 10/31/985/924/976.