An interface is a software package used, alone or in conjunction with other interfaces, to transfer data from one geographical information system to another, or between different representations within a single GIS. The aim in this paper is to extend the traditional view of an interface to include interfaces that use communication networks to move data between (and within) GIS. We suggest that, to exchange data across a network, the best solution may be to construct a set of communicating interfaces, each able to send data to, and receive data from, other communicating interfaces. We describe a working set of communicating interfaces that transfer data between a number of GIS data representations.

Abstract The paper describes in detail the implementation of INMON, a prototype monitor for recording and displaying interaction networks. The interaction network is designed to show the interrelationships between significant events that occur during the processing of an interaction on a loosely‐coupled distributed system. By being directed at analysing what happens in an interaction, this approach is fundamentally different from other graphical representations that show what happens during the execution of a single program on a distributed system. Examples are given of interaction networks recorded by INMON. The approach is based on very general models of a distributed system and of an interaction, and could be widely applied. We conclude by summarizing what is needed to provide facilities within any operating system for recording interaction networks.

article Free AccessLaboratory-style teaching of computer science Authors: J. P. Penny Department of Computer Science, University of Canterbury, Christchurch, New Zealand Department of Computer Science, University of Canterbury, Christchurch, New ZealandView Profile , P. J. Ashton Department of Computer Science, University of Canterbury, Christchurch, New Zealand Department of Computer Science, University of Canterbury, Christchurch, New ZealandView Profile Authors Info & Claims ACM SIGCSE BulletinVolume 22Issue 101 February 1990pp 192–196https://doi.org/10.1145/319059.323449Published:01 February 1990Publication History 26citation495DownloadsMetricsTotal Citations26Total Downloads495Last 12 Months158Last 6 weeks46 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

Transferring data from one geographic information system to another commonly requires a sequence of interfaces, software packages that convert data from one format to another. Construction is described of a model interface that uses a relational database management system and compiler-building tools that work from a machine-readable definition of a data format. Parallels are drawn with conversion and translation problems in other areas from which software tools might be obtained for automation of interface construction. Three interfacing strategies are examined. In particular, the advantages and limitations are discussed for the strategy of using a standard interchange format. The principal conclusion is that achieving a widely-accepted method of defining geographic data formats should be an important objective of efforts at standardization.

A formal basis is proposed for determining what data should be recorded for monitoring to evaluate response-time performance of a time-sharing system. The proposal is made because of perceived limitations of traditional performance monitors. The essential idea is that one views requests from each user as being handled by a single, abstract, interactive process, which can be in any of a possibly large number of disjoint states. These states are defined by whether or not each interactive process is running on, or is queued for, any of a specified set of system resources. The value of the proposal is illustrated by describing the advantages and limitations of a software monitor developed to measure components of response time for interactive work on Prime Series 50 machines. After a discussion of the possibility of other implementations of the formal model, the essential requirements for such implementations are summarised.

The combination of a large number of students and a rapidly developing discipline imposes considerable responsibilities on those charged with providing curricula in computer or computing science. Rather than philosophize about the nature of the discipline itself in this paper, we intend to discuss at a pragmatic level the problems we see at the present time in our own case, and the steps we are taking to resolve them.

The complexity of operation in a computer system makes difficult the task of examining its behaviour theoretically. In a study made here of a time-shared computer system, the author shows, however, that a fairly simple theoretical analysis can be particularly valuable as an adjunct to a simulation study.

The system design of a general-purpose digital computer, CIRRUS, is described. An extensive order code with reasonable order execution times has been achieved at relatively low cost. Comprehensive multiprogram operation is provided. These facilities have been produced largely with microprogramming. The basic hardware is comprised of general purpose registers, a half-word arithmetic unit and two stores, all of which may be inter-connected with considerable flexibility. A substantial contribution to economy has been made by the use of a prewired ``read-only'' store of large capacity for encoding microprograms.