The workstation file system for the Cedar programming environment was modified to improve its robustness and performance. Previously, the file system used hardware-provided labels on disk blocks to increase robustness against hardware and software errors. The new system does not require hardware disk labels, yet is more robust than the old system. Recovery is rapid after a crash. The performance of operations on file system metadata, e.g., file creation or open, is greatly improved.

This paper presents an overview of the Cedar programming environment, focusing on its overall structure-that is, the major components of Cedar and the way they are organized. Cedar supports the development of programs written in a single programming language, also called Cedar. Its primary purpose is to increase the productivity of programmers whose activities include experimental pro-gramming and the development of prototype software systems for a high-performance personal computer. The paper emphasizes the extent to which the Cedar language, with run-time support, has influenced the organization, flexibility, usefulness, and stability of the Cedar environment. It high-lights the novel system features of Cedar, including automatic storage management of dynamically allocated typed values, a run-time type system that provides run-time access to Cedar data type definitions and allows interpretive manipulation of typed values, and a powerful deuice-independent imaging model that supports the user interface facilities. Using these discussions to set the context, the paper addresses the language and system features and the methodologies used to facilitate the integration of Cedar applications. A comparison of Cedar with other programming environments further identifies areas where Cedar excels and areas where work remains to be done.

This paper describes a workstation file system that supports a group of cooperating programmers by allowing them both to manage local naming environments and to share consistent versions of collections of software. The file system has access to the workstation's local disk and to remote file servers, and provides a hierarchical name space that includes the files on both. Local names can refer to local files or be attached to remote files. Remote files, which also may be referred to directly, are immutable and cached on the local disk. The file system is part of the Cedar experimental programming environment at Xerox PARC and has been in use since late 1983.

We present a new approach to the control of versions of software and other hierarchically structured entities. Any part of a system, from the smallest component to a complete system, may exist in different versions. The set of all possible versions under the refinement relation forms a partial order (in fact, a lattice). The fact that version V approximates version V in this order means that V is relevant to V in this sense: when constructing version V of a system, we can sometimes use version V of a component if nothing more appropriate is available. More precisely, a particular version of an entire system is formed by combining the most relevant existing versions of the various components of the system. We call this the variant structure principle; it makes precise the idea that components of a given version of the system can be inherited by more refined versions of the system.

This paper describes research associated with the development and evaluation of Odin-an environ-ment integration system based on the idea that tools should be integrated around a centralized store of persistent software objects. The paper describes this idea in detail and then presents the Odin architecture, which features such notions as the typing of software objects, composing tools out of modular tool fragments, optimizing the storage and rederivation of software objects, and isolating tool interconnectivity information in a single centralized object. The paper then describes some projects that have used Odin to integrate tools on a large scale. Finally, it discusses the significance of this work and the conclusions that can be drawn about superior software environment architectures.

Development of any large system or artifact requires the coordination of many developers. Development activities can occur concurrently. The goal of coordination is to enhance, not restrict, developer productivity, while ensuring that concurrent development activities do not clash with one another. This paper presents a formal model of concurrent development, in which develop-ment consists of a collection of modification activities that change files, and merges that combine the changes. We define a notion of consistency called coordination consistency that ensures that changes are not inadvertently destroyed and that the changes of each modification activity are correctly propagated to subsequent modi-fication activities. We briefly present a set of protocols for concurrent development using a hierarchy of stores that ensure coordination consistency. 1

Abstract not found

In an information distribution network in which records are repeatedly read, it is cost-effective to keep read-only copies in work locations. This paper presents a method of updating replicas that need not be immediately synchronized with the source data or with each other. The method allows an arbitrary mapping from source records to replica records. It is fail-safe, maximizes workstation autonomy, and is well suited to a network with slow, unreliable, and/or expensive communications links. The algorithm is a manipulation of queries, which are represented as short encodings. When a response is generated, we record which portion of the source database was used. Later, when the source data are updated, this information is used to identify obsolete replicas. For each workstation, the identity of obsolete replicas is saved until a workstation process asks for this information. This workstation process deletes each obsolete replica, and replaces it by an up-to-date version either promptly or the next time the application asks for this particular item. Throughout, queries are grouped so that the impact of each source update transaction takes effect atomically at each workstation. Optimizations of the basic algorithm are outlined. These overlap change dissemination with user service, allow the mechanism to be hidden within the data delivery subsystem, and permit very large networks.

This paper gives a survey of all common transparent distributed systems. We distinguish between Distributed File Systems (DFS) and Distributed Operating Systems (DOS). Our overview is focussed on systems providing at least access or location transparency. The paper is organized as follows: The introduction offers definitions of the features of each transparent distributed system as well as the services it is able to provide. We also propose a catalog of criteria that enables us to compare different systems independently of implementation done. The main entries we make are heterogeneity of the system's environment, communication strategy, as well as naming and security issues. Finally, we examine the reliability and availability of the separate systems and the way these issues are achieved. The following section consists of the survey. The description of each system is organized as follows: First, we introduce the main goal the system was developed for, the classification of th...