LPS/11 Users Manual

A package of programs for solving small linear programming (LP) problems on a PDP-11 computer is described. The package consists of eight executable programs, equivalent to corresponding procedures in an MPS, and includes both the primal and dual algorithms and two parametric algorithms. The programs are written entirely in FORTRAN IV (the PDP dialect) and are designed for all in-core operation during solution of the model case. The size of models is arbitrarily limited to 100 rows and 250 columns to make this mode of operation possible on a relatively small computer. The eight programs are quite similar to the corresponding procedures in large MPSs, both in construction and operation, and give essentially identical results. Output formats are also very similar to those of standard MPSs. It is possible to modify the programs for larger models and to transfer them to other computers but certain internal changes will be required. Some of these considerations are discussed in the final section

On Complaints About Applying Models Effectively

There is a growing dissatisfaction in many quarters with the use of mathematical modeling, and skepticism about its effectiveness, particularly with large-scale models. In the past two to three months alone, this has been brought to my attention in at least six instances, some forcefully. I believe this is an extremely serious matter. Despite impressive prestige and far-ranging efforts in an almost unbelievable number of places, systems analysis is never its own sponsor. During the past quarter century, an impressive array of theories, techniques, methods and know-how has been created and effective use of this technology is now sorely needed in meeting extremely serious problems. However, no funded activity can long survive and prosper if it is not perceived as contributing something meaningful to society. In short, our time has come but we had better be able to deliver because, otherwise, we are merely an expensive frill. Admittedly, the effectiveness of modeling is not entirely in the hands of technical specialists an issue to which IIASA is devoting much attention. However, it is useful to be aware of how our efforts are viewed by others who do sponsor projects in the field and some of the misgivings and complaints which they express

User-Oriented Networks: A Series. Part I-A. Foreword and Purpose of Series. Part I-B. Definition, Overall Goals, and Problems

This paper is the first of a series of working papers on data processing networks of a certain type, termed User-Oriented Networks. The need for some such series of discussions is brought about by current activities at IIASA aimed at creating a telecommunications network connecting Laxenburg with various centers in the NMOs and with at least a few large computing centers. The goals of such a network differ from those of conventional, existing networks and the nature of the network, if implemented as now being discussed, will introduce a number of new operational problems. The main purpose of this series is to bring to light the kinds of problems which will be encountered and to suggest designs which will minimize the difficulties and enhance overall effectiveness. This series is concerned only peripherally with hardware, per se. Other investigators are much better equipped to evaluate particular componentry and necessary hardware interfaces and line protocols. At the same time, however, suggestions which will be made will have strong implications for capacity and compatibility among nodal units and the interconnecting telecommunication lines. In some parts of the series, rather specific recommendations will be made for computers needed as nodal switch points. For the most part, this series is concerned with programming considerations, both for operation of a network and for its use. The programming of application software systems or application programs on large computers is not a principle area of discussion but, of course, the requirements for such work will arise from time to time and provide major considerations for network capability. The term "programming" is used herein in a broader sense which encompasses the flow of data among nodes of the net~ork and the kind of higher-level protocols, command and con-trol languages, symbology standards, etc., which will be required. This writer is aware that many suggestions to be made -- or their implications -- may be impractical at the present time for either financial or political reasons. However, these cannot be considered permanent constraints or the network can never be realized. On the other hand, it is not intended that anything will be suggested which is technologically or logically infeasible. In general, it is hoped that the series will arouse discussion and criticism by a number of people at IIASA. It is necessary to think very carefully about the consequences of any design decision in such a long-range and far-reaching undertaking as an international network of the kind being contemplated. Part I-B following defines the kind of network contemplated in terms of overall goals and then discusses nine general classes of problems which are immediately foreseen. Part II will take up the inter-user communication problem and suggest an overall network design which satisfies these requirements

User-Oriented Networks: A Series. Part II. Inter-User Communication and Its Implications for Network Topography

In Part I (IIASA WP-75-81), three types of networks were identified: commercial, cooperative, and user-oriented. It is the last which is of long-range interest to IIASA. A possible fourth type -- data base networks -- although of great interest to IIASA, need not be considered separately for the problem discussed here. The usual arrangement for a commercial network permits many users to connect to a single central computing system and to utilize whatever services it provides. One of these services is the ability for one user to send messages to any other user who is on-line. This is frequently extended to provide a "mail-box" function for users not on-line at the time, and also to broadcast messages to all users or to leave "mail" for all users, or for all users of a group. The important point to note is that these services are functions of the central computing system. In a cooperative network, the user first accesses the network and then, with network protocols, connects to a particular central computing system. From then on, the situation is no different from a commercial system. The network's central control system may have a limited ability to broadcast emergency messages, but users can only communicate with other users on the same central computing system. In a user-oriented network, the above arrangement negates one of the principal purposes of the network, i.e. the ability for users to communicate easily with one another even though they may be using different central computing systems or even none at all. In order to analyze this problem easily, we need to invent some succinct symbology

A Fresh Approach to Data Base Management Systems. Part I: Concepts, Considerations and Justifications

This paper is in two parts. In this part, some of the concepts and considerations in the design of a data base management system are set forth, together with justifications for some of the decisions made. In Part II, a particular system is described, essentially in the form of a tutorial users manual. Some further justifications are given there as well as a couple of more discussions of a conceptual nature. Although the two parts are intended to form a set, they can each stand largely alone. A few definitions given in Part I are used in Part II without restatement

User-Oriented Network: Part IV. A Suggested Set of Network Commands

In the discussions in Parts II and III (IIASA WP-75-82 and WP-75-83), several commands and their mnemonics were invented. This was done as occasion required without any overall description of style or extent. Before proceeding with further discussions of possible network facilities and features, it seems appropriate to define a more comprehensive set of commands in a consistent manner

User-Oriented Networks: A Series. Part III. User-System Communication

In Part II (IIASA WP-75-82), a network was described in overall terms which easily handles inter-user communications. This largely ignored, of course, a major function of the network, namely, productive work on large central computing systems (denoted there and here by SYS). The sequence was deliberate. Networks are usually thought of as built around a SYS or set of them, in other words, the network is an adjunct to the central computer(s). The viewpoint in user-oriented networks is just the opposite: central computing systems are facilities available on the network but not indispensable units for all functions of the network. It seemed desirable to establish this viewpoint first. The above observations, or even a working network as described in Part II, do not diminish the importance of central computers nor make the inherent difficulties of using a variety of them disappear. There will be much to say in subsequent parts of this series about the problems of incompatibility among systems and the confusing variety of conventions, formats and protocols. However, the network scheme of Part II is even more important in dealing with these problems than in handling inter-user communication. Properly used, it can deal fairly effectively with incompatibilities among systems so long as this is necessary, and can be employed to gradually force more standardization in the future

Hypernumbers: Real or Imaginary?

On 22 August 1975, Dr. Charles Muses gave a talk at IIASA on hypernumbers, in which he has worked extensively. The talk was fascinating to me and he expressed many viewpoints with which I very much agree and which are not often voiced. He left reprints of two papers which I was eager to read. In general, his discussion and some of the claims he put forth stimulated me to re-examine a subject to which I had not given serious thought for perhaps fifteen years or more. On reading the papers, however, I found myself confused by the notation, especially by apparent inconsistencies. Also, the proliferation of "species and subspecies" of numbers without any apparent motive, and the incomplete development of the theory were troublesome. Furthermore, the use of exponential forms and the introduction of "bimatrix arithmetic" before the set or sets of numbers and their arithmetic (on which Muses lays great stress, properly I think) are rigorously defined, gives an impression of sleight-of-hand. Finally, the statement that "specific details of method cannot be discussed explicitly at this time because of negotiations in progress" is a virtual invitation to examine the subject critically. This paper does so from one viewpoint, namely the use of matrix arithmetic as a convenient mechanism for calculation with quantities which are noncommutative and, in some ways, non-unique. Rather than attempt to "straighten out" Muses' notation, I will simply start from the beginning with notation of my own, standard in so far as applicable. Accidental similarities with other parts of Muses' notation should not be assumed to imply equivalence

Software Systems Viewed as an Analogy to Industrial Organizations

This paper is not "scientific" in any usual sense. Rather, software systems are described by means of analogies with large industrial and other organizations. The curious nature of software is first pointed out, and then its major dimensions are listed. Typical attributes of a large organization and its functions are briefly set forth and then these abstractions are related to systems of programs. The dual nature of an organization and its technology is suggested and then applied to systems of programs and the data structures on which they operate. The role of the user is discussed, several aspects being shown. Finally, a few maxims for building, maintaining, and using software systems are given. "An idea, like a ghost, ..., must be spoken to a little before it will explain itself." (Dickens