.NONUMBER .LM 0 ^PY^- .PAGE SIZE 58,85 .LM 10 .RM 75 .NO FILL .NO JUSTIFY # .SKIP 5 ^IC0000^IS328^GThe RSX Multi-Tasker^IS204^IC1000^G .SKIP ^IC0000^IS328^GJuly, 1987^IS204^IC1000^G .SKIP .CENTER ##^IS144^G"By Hook, by Crook, Or by Cytoplasmic Streaming"^IS204^G .SKIP .CENTER Fine Realtime Commentary Since 1975 .SKIP 6 .CENTER ^&Table of Contents\& .SKIP 2 .TAB STOPS 65 Food for Thought RSX-1 The Editor's Corner RSX-1 By-Laws and By-Ways RSX-3 Submitting Articles to the Multi-Tasker RSX-4 And That's The Way Things Are RSX-5 RSX BBS Announcement / Call for Hardware RSX-5 Private LUNs for Low-Level I/O Routines RSX-6 The Hitchhiker's Guide to RSX, Part I RSX-11 .JUSTIFY .FILL .SKIP 15 .LM +5 .RM -5 Opinions expressed in the editorial section of the Multi-Tasker are those of the Editor. They do not represent the official position of the RSX SIG or that of DECUS leadership in general. .LM -7 .RM +7 .PAGE .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Food for Thought .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT # .SKIP 7 .AUTOPARAGRAPH #########################^IC0000^IS328^GFood for Thought^IS204^IC1000^G .SKIP "If you ask me to name the proudest distinction of Americans, I would choose - because it contains all the others - the fact that they were the people who created the phrase 'to ^IS144^Gmake^IS204^G money.'## No other language or nation had ever used these words before; men had always thought of wealth as a static quantity - to be seized, begged, inherited, shared, looted or obtained as a favor. Americans were the first to understand that wealth has to be created. The words 'to make money' hold the essence of human morality." .SKIP 2 .INDENT 30 ^IS144^G- Ayn Rand^IS204^G .INDENT 30 ^IS144^G##Atlas Shrugged^IS204^G .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Editor's Corner .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .SKIP 9 ########################^IC0000^IS328^GThe Editor's Corner^IS204^IC1000^G .SKIP .CENTER Bruce R. Mitchell .SKIP I made a big boo-boo last month. By now you probably all know about it. There was indeed a June issue of The Multi-Tasker, but it went in after the deadline for submission. It's not clear whether it made it into the June issue of the SIG newsletters, and I won't know until after the deadline for this issue. If it missed, you are now reading both June and July in the same issue of the SIG newsletters. Love those symposia ... As usual, RSX presented a full slate of presymposium seminars, technical sessions, meetings, and raised a row as well. VMS users who attended their Magic session will not soon forget that RSX rules at symposia. By the end of the week, most other SIGs were arriving at the RSX suite to present tribute ... or possibly they looked at it as "protection". You may wonder why the SIG makes such a major effort to become so "visible" at symposia. That is a reasonable question. Aside from it being a lot of fun, it's easier to get and hold someone's attention if they know who you are, and think you can back it up. Linda Ziegler and Karen Noel presented sessions at Nashville that deserve special attention and thanks from the entire RSX user community. Linda, of course, is the VAX/RSX implementer. Karen is a new member of the RSX team, the implementer of a shiny new RSX product - Coprocessor RSX. "So what's coprocessor RSX?" you ask. Coprocessor RSX is probably the most exciting thing to come down the pike since the 11/74 multiprocessor. Take a KXJ11 card. Plug up to 4 of them into the backplane of a MicroVAX II. Make a few additions to M-Plus, add a few drivers on both systems, and what do you have? You have a VAX that can run native mode RSX applications ^IS144^Gconcurrently^IS204^G with VMS. Peer to peer. In the same backplane. Do we need this? Yes! Think of the applications for it! In most industrial applications, the front-end PDP-11s feed process information into VAXes handling a workcell or process line. Why put in separate 11s with cabinets and disks when you can put them into the backplane of the VAX? Let the two systems share peripherals. It cuts the cost of a typical process control system by 50 percent, at a guess. We need this. Not just as the RSX SIG, but as system implementers. It's exciting. It's got possibilities nobody has thought of yet. It's not expensive. And it promises to extend the lifetime of the PDP-11 for a long, long time to come. All of us owe Karen and Linda a big vote of thanks for the time and effort they invested bringing this project to fruition. I hope that I may convince them to write an article about it for a future issue of the newsletter. Thanks are due to ^IS144^Gall^IS204^G the members of the RSX implementation team who attended Nashville. For some reason we seem to take their ongoing efforts and attendance at symposia for granted. We're footing the bill for them, you say? That is true ... but remember this: True RSX wizardry is getting scarce. And, sure as the carp flop upriver to spawn (it was a dry spring in Minnesota) it's not easy to keep that type of people around when DEC offers jobs that promise more recognition, higher pay, and state of the art equipment. For all the people at DEC who support RSX and fight to keep it alive - Cathy Ziegelmiller, Dick Day, Brian McCarthy, and their entire group - on behalf of the RSX SIG, thank you. We don't say it often enough. Everything I want to talk about won't fit into this column, so I guess I'll cut it off. But not without a few editorial comments first. No, you don't have to get out the fire extinguishers - no flaming this month (well, not much ...) .SKIP 2 .CENTER ----- By-Laws and By-Ways ----- .SKIP At Nashville, the SIG distributed petitions to request a U.S. Chapter referendum on an amendment to the DECUS U.S. Chapter By-Laws. As most of you know, the Chapter By-Laws govern the way that DECUS is run. To make a long story short, what we propose is a change in the section of the By-Laws which allows members to propose changes to the By-Laws. In other words, we want to amend the section which lets us amend sections. The current wording of the section that we suggest be changed is shown below: .SKIP 2 .LM +5 .RM -5 11.0.1##Initiation of Amendments .SKIP The Board of Directors may propose an amendment to the Bylaws by a two-thirds (2/3's) vote of the Board of Directors voting members. Chapter Members may propose an amendment by submitting a petition signed by ten percent (10%) of the chapter membership total as of the first day of the current year. Such petition will be delivered to the President of the Board of Diretors. Within sixty (60) days of receipt by the Board, the signatures will be validated and the ballots distributed to the Chapter Membership so that they might vote on the proposed amendment. .LM -5 .RM +5 .SKIP The change to this section that we propose is minor. It is a single sentence change. The change is italicized below: .SKIP 2 .LM +5 .RM -5 Chapter Members may propose an amendment by submitting a petition signed by ^IS144^GChapter Members numbering at least ten percent (10%) of the vote in the most recent election of the Board of Directors.^IS204^G .LM -5 .RM +5 .SKIP This amendment will give active DECUS members more control over the Society. The numbers necessary to amend will change from around 5,000 (10% of 50,000 members) to 3,500 (10% of 35,000 votes in the most recent election). Certainly both are huge numbers of signatures. Neither quantity is easy to obtain, but it is easier to find 10 percent of the active members - those who take the time to vote - than 10 percent of all members, including "inactive" ones. There would be a fighting chance for collection of enough signatures at one symposium to propose amending the By-Laws. At last count we had a few hundred signatures obtained at Nashville. We need more. Lots more. More from the people who attend symposia. More from the people who don't attend symposia. More from LUGs. More from individual members. I have petition forms. Write me or call me and I will be happy to send them out. If you have petition forms from Nashville and you're waiting to get them filled up - don't wait! Get everybody you know to sign them, then send them back. They don't have to be full up to be "acceptable". ^&Every signature counts.\& Just drop me a note stating that you support this petition, with your name, signature, and DECUS number (if you know it). That puts us one closer to those 5,000 signatures. Take control of your future. The Board election turned out well for us. Now help us put even more control of DECUS back in the hands of you, the members at large. .TEST PAGE 5 .SKIP 2 .CENTER ----- Submitting Articles to the Multi-Tasker ----- Please submit machine readable media if you can. RK05, RK07, RL01, RL02, RM03, RX01, RX02, RX50, TK25, TK50 or 9 channel magtape at 800 or 1600 BPI are all acceptable. I can read paper tape too. Anything I can't read can be converted; don't let that stop you from submitting. All RSX volume formats are acceptable except ROLLIN or PRESRV. The Editor can now Kermit articles into the Multi-Tasker host. The reverse is unfortunately not true; the Multi-Tasker host is normally an isolate. If you want to submit via Kermit, call beforehand with a phone number, login for the host machine and system uptimes. Submissions which aren't machine readable take longer to get into print. The editor is lazy and types mass quantities only once a month when progress reports are due. If you preformat a submission in RUNOFF, please set page size 58,80; left margin 10; right margin 75; and, when changing margins, use incremental changes rather than absolute. The editor blesses you for the consideration. Send all submissions to: .SKIP .NO FILL .NO JUSTIFY Bruce R. Mitchell Machine Intelligence and Industrial Magic PO Box 816 Byron, MN 55920 (507)#775-6268 .JUSTIFY .FILL .TEST PAGE 5 .SKIP 2 .CENTER ----- And That's The Way Things Are ----- _... this month in Pool Lowbegone, where the Field Circus representatives are strong, the coprocessor RSX implementers are mighty good-looking, and the backplane voltages are above average. .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT RSX BBS Announcement / Call for Hardware .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 #########^IC0000^IS328^GRSX BBS Announcement / Call for Hardware^IS204^IC1000^G .SKIP .CENTER James Bostwick and Bruce Mitchell .CENTER RSX SIG Steering Committee .SKIP The RSX SIG has perennially considered establishing an "RSX users only" computer bulletin board. Whenever the topic came up, one problem was always insurmountable: Lack of funding for the necessary hardware. Well, that's all changed. An RSX bulletin board system is now reality, thanks to the generous donation of a PDP-11/24 from Digital Basics of Burnsville, Minnesota. We are pleased to announce that the basic system is available for use. The BBS modem phone number is (612) 777-7664. The line supports Bell 103 protocol (110/300 baud) and Bell 212 protocol (1200 baud). Considering the type of traffic that we see on DEC-oriented bulletin board systems, it's hardly surprising to find that an alpha mnemonic for that number is: (612) SPR-PONG. (Now you can play, too!) To obtain an account on the BBS, call it up and log in using the account name ACCOUNT, password REQUEST. This gets you into a slaved procedure which requests your name, address, telephone number and DECUS membership number. No accounts are given out without this information, so dig out that membership card or look on your newsletter subscription mailing label to find your DECUS number. On verification of the submitted information, we mail an account notice letter to the address given in the request. This letter contains the account name, virgin password, and a copy of the user procedures. With this information in hand, you are welcome to log in at any time. We must point out that the software for the system is still under development; the behavior of the system is therefore subject to change without much notice. As we start up, functions available include back issues of the Multi-Tasker, general news, user-to-user MAIL and outgoing KERMIT of all of the above. We hope to have conferencing up before the end of the year. .SKIP 2 .CENTER Call for Hardware! We need hardware for the bulletin board system. What we have is the 11/24 with 128 Kw of memory and an RL01. We need more memory, disk drives and packs, but anything and everything is welcome. So - root through those spares cabinets and back rooms. Pull out what you can give us. Q-bus, Unibus, PDP-8, PDP-11, VAX, whatever; you name it, we'll take it. Front panels, side skins, power supplies, anything. If we can't use it on the BBS, we'll flog it for something that we can use. No donation is too small; single cards are just as welcome as complete 11/83s. Contact your friendly Multi-Tasker editor at the address and number in the editorial section to arrange for us to take that useless 11/751 off your hands! .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT Private LUNs for Low-Level I/O Routines .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 ###########^IC0000^IS328^GPrivate LUNs for Low-Level I/O Routines^IS204^IC1000^G .SKIP .CENTER Alan E.#Frisbie .CENTER Flying Disk Systems, Inc. .CENTER 4759 Round Top Drive .CENTER Los Angeles, CA##90065 .CENTER (213) 256-2575 .SKIP This article describes how the writer of low-level I/O routines can reserve private LUNs for error messages, special devices, etc., even when a high-level language allocates its own LUNs. In my business, I write device drivers for some pretty weird devices. Some of those devices have more functions and options than a Chinese menu. This is no problem for ^&me\&, of course; a good driver can map a QIO function code to almost any device function. The problem comes when the customer says, "Fine, now write us some programmer-friendly subroutines to make it easy for us to issue QIOs to our bizarre device. And by the way, we're using the Mongolian Software Pascal-Zero compiler for all of our development." What the customer ^&doesn't\& say is that his programmers know nothing ^&but\& Pascal-Zero, have no concept of QIOs, LUNs or TKB options, and have never used RSX before. They also think that status values returned from subroutines never need to be checked. If a programmer-friendly (even to Pascal-Zero) routine is to issue a QIO to the XX: device, it needs a private LUN. The question is, which one? Also, since the application programmer never bothers to check the error status, we want to print a message on the terminal if the device dies or the programmer screws up. Again, what LUN do we use for the error message? In an all-Macro environment it is easy to say, "LUN 1 is assigned to device XX: and LUN 5 is assigned to the terminal."## The assignments can be made either at Taskbuild time with the ASG option or at runtime with the ALUN$ directive. It is not that simple with "high-level" languages like Pascal-Zero, or with programmers that forget that your device needs a LUN of its very own. Newer high-level languages generally mask the details of LUN assignment by assigning them dynamically. The first file opened is assigned LUN 1, the second is assigned LUN 2, etc. If they are opened in a different order, the LUN assignments are different. As soon as you think you are safe by using LUN 10 for your QIOs, some bozo opens 10 files simultaneously. Likewise, you can never depend on LUN 5 being assigned to the terminal, either. What to do? Fortunately, the Taskbuilder comes to the rescue by providing up to nine "secret" LUNs beyond the number specified by the user in the TKB "UNITS=" option. Five of these are reserved for DEC's use and another one is semi-reserved. This leaves us with three LUNs that are all ours, plus one that we can share! How does the Taskbuilder do this and how do we use it? The Taskbuilder builds the Logical Unit Table ("LUT") for your task and assigns device names to each LUN. It then checks for the existence of certain "reserved" symbols in your object files. If one of these reserved symbols is found, the word at that location is filled with a "private" LUN beyond the numbers already assigned. The LUT is extended by one entry and a default device name is assigned to that LUN. The reserved symbols and their default device assignments are as follows: .Skip 2 .LM +13 .Indent -13 _.NLUNS#######Filled with the number specified by the TKB "UNITS=" option. The following assignments receive numbers above "n" in this order, assuming that they are defined. .Skip .Indent -13 _.MOLUN##TI:##"Message output" LUN used by Fortran IV, Fortran-77 and ??? for error message output to TI:. Perfect for error messages. .Skip .Indent -13 _.MBLUN##SY:##"Mailbox" LUN used by RMS for DECnet applications. .Skip .Indent -13 _.PTLUN##SY:##"Plotter" LUN for plotter/graphics software. If you are not using DEC's graphics software, it's fair game. .Skip .Indent -13 _.USLU1##SY:##"User" LUN 1. Reserved for you! .Skip 1 .Indent -13 _.USLU2##SY:##"User" LUN 2. Reserved for you! .Skip 1 .Indent -13 _.NOVLY##OV:##Overlay handler LUN. Hands off. .Skip 1 .Indent -13 _.ODTL1##TI:##ODT terminal LUN. Hands off, unless you want ODT to use another terminal for I/O. (This can be useful.) .Skip .Indent -13 _.ODTL2##CL:##ODT listing LUN. Used with ODT's "L" command for dumping to the optional listing device. .Skip .Indent -13 _.TRLUN##CL:##Used by the TRACE debugging aid for its listing. .LM -13 .Skip P/OS systems have one additional reserved symbol (.SUML1) for the standard utility module. Its usage and position in the table is left as an exercise for the reader. This list can also be found in Appendix E of the Taskbuilder manual. The example shown below uses both .MOLUN and .USLU1 for error messages and custom device I/O, respectively. Only the details essential for illustrating the principles are shown. Code specific to a particular high-level language calling sequence is not shown. .Skip 2 .Literal .TITLE LDEMO LUN Assignment Demo ; Demonstration of "private" LUN use in low-level I/O routines. ; This demo performs some QIO operation on device XX: We use ; .USLU1 (User reserved LUN #1) for I/O to XX:. LDEMO:: TST UL1FLG ; Is LUN already assigned? BGT 20$ ; If >0, Yes - skip to 20$ BEQ 10$ ; If =0, No - assign it ; ALUN$ failure. Print error message on LUN specified by .MOLUN. ; TKB has already assigned it to TI:, so we don't have to do it. MOV .MOLUN, ERRQIO+Q.IOLU ; Set TI: LUN in QIO DPB DIR$ _#ERRQIO ; Print the error message RETURN ; Return to high-level code ; Attempt to assign the first user LUN to the XX: device 10$: MOV .USLU1, ALUNXX+A.LULU ; Put private LUN in DPB MOV .USLU1, XXQIO+Q.IOLU ; And also into QIO DPB DIR$ _#ALUNXX ; Assign LUN to device XX: MOV $DSW, UL1FLG ; Save the ALUN$ status BR LDEMO ; And go test the status ; Here we do whatever must be done before issuing the QIO... 20$: DIR$ _#XXQIO ; Do QIO to device XX: RETURN ; Return to user ; >>> THE FOLLOWING TWO WORDS ARE FILLED BY THE TASKBUILDER: <<< .MOLUN:: .WORD 0 ; Filled by TKB with LUN for TI: .USLU1:: .WORD 0 ; Filled by TKB with our private LUN UL1FLG: .WORD 0 ; User LUN 1 assigned flag ALUNXX: ALUN$ 0, XX, 0 XXQIO: QIOW$ IO.WLB, 0, 24,, XXIOSB,, ERRQIO: QIOW$ IO.WVB, 0, 24,,,, ERRMSG: .ASCII /Error assigning LUN to device XX:/ .ASCII /Jim's fly is probably open./ ERRLEN = . - ERRMSG .END .END LITERAL .Skip The above code works with either Macro or high-level language callers. When using it with Fortran-77 and some other languages, however, the symbol .MOLUN may be multiply defined. This is because F77 uses .MOLUN for its own error messages to TI:. In this case you might simply choose not to define .MOLUN in your code, and use the copy that F77 defines. This causes it to be UNdefined if you ever use that routine without Fortran. The cleanest solution is to create a one-word object module that defines .MOLUN. This module is then inserted into SYSLIB, from whence it will be extracted if no other module defines .MOLUN. .; .; .Skip 2 .Test Page 14 .Literal .TITLE MOLUNX Definition of .MOLUN ; This definition of .MOLUN is written to be inserted in SYSLIB. ; Thus, .MOLUN is automatically defined regardless of whether the ; using program already defines it (as with FOR or F77). ; ; The Taskbuilder fills it in with a LUN and assigns it to TI: .MOLUN:: .WORD 0 .END .END LITERAL .Skip Assemble it, and insert the resulting object module into SYSLIB: .SKIP LBR LB:[1,1]SYSLIB.OLB=MOLUNX.OBJ/IN By use of these techniques the innocent high-level applications programmer is insulated from the vulgarity of LUN allocation and assignment, Taskbuilder options and the like. Even better, the low-level I/O routine writer (i.e., you) no longer must spend countless hours explaining these subjects to each new applications programmer. Now, if I could only do something similar with event flags... .COMMENT .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT The Hitchhiker's Guide to RSX, Part I .COMMENT +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ .COMMENT .TEST PAGE 15 .SKIP 6 #############^IC0000^IS328^GThe Hitchhiker's Guide to RSX, Part I^IS204^IC1000^G .SKIP .CENTER A-to-Z Base Product Marketing .CENTER Digital Equipment Corporation .CENTER Continental Boulevard, MKO1-2/E25 .CENTER Merrimack, NH##03054 .SKIP Through the kind intervention of a Digital employee, the Multi-Tasker is pleased to present "The Hitchhiker's Guide to RSX". This is probably the best overall coverage of the current RSX environment available. It is also a valuable reference for all application programmers, not just business application developers. This document is being serialized due to its length. This is the first of three parts, covering chapters 1 through 4. .PAGE # .SKIP 6 .CENTER HITCHHIKER'S GUIDE TO RSX .SKIP 2 .CENTER An Introduction to RSX for Business-Application Developers .SKIP 6 .CENTER Revision 0.0 .SKIP 4 .CENTER Disclaimer .SKIP This is a preliminary version and is not quite one-hundred percent complete. Please send comments, questions, and recommendations -- on this document -- to A-to-Z Base Product Marketing, MKO1-2/E25, Digital Equipment Corporation, Continental Boulevard, Merrimack, New Hampshire 03054. .SKIP The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. .SKIP The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such license. .SKIP No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies. .SKIP 3 .CENTER Copyright (C) 1986 by Digital Equipment Corporation .CENTER All Rights Reserved. .CENTER Printed in U.S.A. .SKIP 2 .CENTER September, 1986 .PAGE .CENTER Table of Contents .SKIP 2 .NO FILL .NO JUSTIFY Chapter 1 Introduction 1.1 Purpose of this Guide 1.2 Intended Audience 1.3 On the Synergy of Operating Systems and Applications 1.4 Elements of Application Tuning Chapter 2 Overview of RSX 2.1 History of RSX 2.2 RSX Version 3.0 Chapter 3 Getting Started 3.1 The Three Faces of RSX 3.1.1 Micro/RSX 3.1.2 Pregenned M-Plus 3.1.3 RSX-11M-Plus 3.2 Installation and Startup 3.2.1 Installing Micro/RSX 3.2.2 Installing Pregenerated M-Plus 3.2.3 Installing M-Plus 3.3 Logging in and other First Day Tasks 3.3.1 Logging into the Prebuilt Accounts 3.3.2 Post Installation Cleanup 3.3.3 Customizing Startup 3.3.4 Configuring Terminals and Printers 3.3.5 Creating User Accounts 3.4 Installing Layered Products 3.4.1 Installation on Micro/RSX 3.4.2 Installation on M-Plus Chapter 4 Terminals 4.1 Cost of I/O 4.2 Specific Cost of Terminal I/O 4.2.1 Interrupt Service 4.2.2 Scheduler Overhead 4.3 Minimizing Costs 4.3.1 Blocking Output Requests 4.3.2 Blocking Terminal Input 4.3.3 Using DMA Terminal Hardware .JUSTIFY .FILL .PAGE .CENTER Hitchhiker's Guide to RSX .SKIP .CENTER D O N ' T P A N I C .SKIP 3 .CENTER Chapter 1 .SKIP .CENTER Introduction .SKIP 2 This guide introduces the RSX operating system to the Small Business Application developer. It contains information about aspects of RSX which are of particular interest and importance to application developers considering or in the process of migrating commercial applications to RSX, or creating new ones. Much information is also of use to developers considering a move to VAX/VMS, since the two systems share many characteristics. The guide describes general principles for developing a new application or adapting an existing one to RSX. It also covers certain areas of special importance to small business application designers. RSX is a mature operating system and there are many case histories of successful use in a small business environment. Unfortunately, there are also instances in which developers encountered difficulty in making the transition from simpler environments. In many cases the effort required to correct the problems proved to be trivial. All that was lacking was information. There is nothing about RSX making it unsuitable as a base for small business software. Developers who invest the time and energy in developing an understanding of the strengths and weaknesses of RSX maximize their chances at a smooth, successful and inexpensive conversion. .SKIP 2 1.1##The Purpose of this Guide Operating systems are all different. The most frequent problem in migrating an application from one system to another is moving a set of programs designed around the strengths and weaknesses of the original system without considering the target's characteristics. In many cases, such oversights are the result of time pressure. In others, they are due to lack of information about which areas need the most attention and how to attain the most improvement for the least amount of work. This guide helps point the way. This is not a substitute for the various developer's materials available for RSX, but is rather a summary intended to assist third party software developers in assessing the desirability of moving to RSX, and in minimizing the number of pitfalls into which such a developer might fall. If you are new to RSX it is of assistance during those first days in which adjusting to any new system is difficult. The principles and techniques described are largely independent of the implementation language to be used. An efficient RMS file design improves the performance of an application program whether it is written in Fortran, Basic, or Pascal. Many persons reading this guide do so in preparation for a migration of an existing application from CTS-300 or CTS-500 to RSX and VMS, and some special notice is taken of this path. .SKIP 2 1.2##Intended Audience This guide is addressed to people with a variety of backgrounds. You might be a third party software developer considering a move to RSX. You might have already decided to give RSX a try, and are wondering how to plan migration of your software. You could be part way through a conversion and finding difficulties in locating the information you need. You might be facing a particular problem and looking for a quick solution. It is assumed that you know something of commercial application development and have a favorite programming language. If you are coming from a CTS-300 environment you may find that many of the facilities and concepts available with RSX are complex. If you are coming from VMS on the other hand, RSX seems more familiar. .SKIP 2 1.3##On the Synergy of Operating Systems and Applications Operating systems are alike in that they serve as a mechanism by which system resources are allocated to various objects, terminals, or programs. They are different, however, in the overall design which determines the type of expected user application. Some are designed to react as quickly as possible to an event, some are designed for security against power or component failures, and some are optimized for a particular language. In all cases there is synergy between an application and the operating system. Since each system has a distinct set of strengths and weaknesses, it behooves the application developer to make changes that take advantage of strengths and avoid weaknesses. Problems do not usually reside exclusively in the operating system or the application, but most often result from attempts to treat one operating system as though it had the properties of another. The importance of an application designer's understanding the characteristics of the chosen operating system cannot be overemphasized. The return on such an investment can be staggeringly large. In one case a simple change of subroutine linkages taking 20 minutes resulted in a twofold performance improvement. In another case, optimization of a single subroutine resulted in tenfold improvement of a critical module. .SKIP 2 1.4##Elements of Application Tuning There are two distinct aspects of design and tuning of applications in a commercial environment. The first is the number of resources required by a particular program, such as the number of files, CPU cycles or terminal operations. The second is speed and efficiency with which the operating system can deliver those resources. Identifying the contributions that an application makes to system load is difficult for many developers. A module may work well with small numbers of users, but under full load the overall system may deteriorate quickly. All too often this condition does not occur until the product is actually installed at a customer site where there is less time and fewer opportunities to investigate the problem. The purpose of this document is to help you anticipate such problems and to apply corrective action as early and inexpensively as possible. When a performance problem occurs, the solution must be to reduce the demand for resources or increase the speed with which the requests are satisfied. Since delivery of a resource can never be instantaneous, the first effort should be to eliminate the requirement. The sections following describe ways you may reduce or eliminate demands on an operating system by your application. .PAGE .CENTER Chapter 2 .SKIP .CENTER Overview of RSX .SKIP 2 The 1970 announcement of the PDP-11 resulted in an industry demand for a high quality, high performance and comprehensive multi-tasking operating system. The RSX family began with an initial adaptation from the PDP-15 and grew with additions of RSX-11A, -11B, -11D, -11S, -11M, IAS, P/OS, -11M-Plus and, preserving the family ties with the 32 bit big brother, VAX-11 RSX. Many VMS concepts can be traced to previous work on RSX. .SKIP 2 2.1##Historical Overview A number of operating systems were developed for the PDP-11 including RT-11 as a 16-bit follow-on to OS/8, DOS-11 for larger machines and more sophisticated customers, and RSTS for the education market. DEC mythology has it that at one time or another there were 27 different PDP-11 operating system projects funded and underway. In the early years, the scientific/industrial market was of primary importance to Digital and RSX was the flagship product. Most early minicomputers were used for process control and data collection, and it was essential that the system software offer the greatest possible degree of flexibility. Hardware was expensive and if a month or two of bending and squeezing the software meant that memory requirements could be reduced by 4KW it was well worth the effort. Furthermore, there was no end to the variety of configurations which could be assembled. OEMs and end users were willing and able to create their own hardware which could range from a simple parallel digital interface to DMA communication ports. And, since their world was primarily real time, they required that response times to external events be both extremely fast and highly predictable. RSX was designed to satisfy the most exacting real-time requirements and could be tailored to almost any configuration of off the shelf and custom hardware. Every feature has an associated cost. The modularity of RSX meant that the process of creating a working system was complex, even if the hardware configuration was comparatively simple. Users who didn't have critical realtime requirements were nevertheless obliged to deal with a human interface designed for operating four or five processes at once. This was particularly true for the less technically oriented commercial users who were beginning to experiment with minicomputers as an alternative to batch processing. Multi-user protection was not supported in the early versions. Early MCR bore an unfortunate resemblance to certain UNIX shells. Memory was divided up into partitions which always seemed to be mismatched with the job at hand, the system simply stopped if a particular resource was exhausted, there was no data management other than block I/O, and the only implementation languages were Macro and Fortran. Terminals seemed to be supported only as an afterthought. But even scientists tire of creating record management routines, and over the years RSX was improved in ways attractive to non-technical users. As underlying hardware became less expensive it was possible to ease the requirements for partitions in memory and provide more facilities in the Executive. RMS finally appeared with multi-key ISAM. Partitions and POOL management became dynamic; round-robin scheduling and swapping support were added. DCL was provided (albeit only as an "alternative" to MCR). DECnet was put in place and, wonder of wonders, the terminal driver was made full duplex and could support type-ahead, trap CTRL/Cs and process escape sequences. Still, the SYSgen problem remained, and it was finally decided to produce a pre-SYSgenned, bounded version of RSX - Micro/RSX - with commercial features which could be handled by a computer naive customer. The Micro PDP-11 was the first PDP-11 intended for installation by a first time user. Since the hardware was user-installable it was felt that the software should be as well. Moreover, it was considered that the Micro customer represented a new class of RSX user - a person not concerned with the traditional scientific/realtime features of RSX, but simply desiring a system which could quickly and easily be put to work. Rather than require these users to describe the target hardware configuration in detail, the Micro/RSX software accommodates itself to whatever is available. .SKIP 2 2.2##RSX Version 3.0 Family Micro/RSX was the first member of what is now the RSX Version 3.0 family and has been joined by RSX-11M-Plus in both pregenned and full kit form. Micro/RSX and pregenned M-Plus eliminate the SYSgen process and adapt themselves to any legal hardware configuration during system startup. M-Plus still requires a SYSgen to move from the baseline (distribution) Executive to full timesharing, but even this process has been considerably simplified. The features available with RSX V3.0 include: .LM +8 .SKIP 2 .INDENT -3 o##Full support for all of today's PDP-11 high performance CPUs, memory to 3.8 MB and I/D hardware where available. .SKIP .INDENT -3 o##Support of all modern disks and peripherals. .SKIP .INDENT -3 o##Disk structure, named directories and logical names compatible with VMS. .SKIP .INDENT -3 o##RMS including multi-key ISAM compatible with VMS. .SKIP .INDENT -3 o##Terminal emulation and remote file access via DECnet. .SKIP .INDENT -3 o##Sharable, clustered and supervisor-mode libraries. .SKIP .INDENT -3 o##Sharable, checkpointable common regions. .SKIP .INDENT -3 o##Multiple stream print and batch queues. .SKIP .INDENT -3 o##Implicit device spooling. .SKIP .INDENT -3 o##Synchronous and asynchronous I/O on up to 256 channels per task (not supported by all languages). .SKIP .INDENT -3 o##DCL with extended help and command line continuation. .SKIP .INDENT -3 o##Disk data caching. .SKIP .INDENT -3 o##Password encryption. .SKIP .INDENT -3 o##Multi-volume backup to disks and tape. .LM -8 .SKIP Application implementation languages and tools available under RSX include: .LM +8 .SKIP 2 .INDENT -3 o##BASIC-Plus-2 .SKIP .INDENT -3 o##COBOL-11 .SKIP .INDENT -3 o##COBOL-81 .SKIP .INDENT -3 o##Datatrieve-11 .SKIP .INDENT -3 o##DBMS-11 .SKIP .INDENT -3 o##DECnet .SKIP .INDENT -3 o##DIBOL-83 .SKIP .INDENT -3 o##FMS-11 .SKIP .INDENT -3 o##FORTRAN-IV .SKIP .INDENT -3 o##FORTRAN-77 .SKIP .INDENT -3 o##MACRO-11 .SKIP .INDENT -3 o##Pascal .SKIP .INDENT -3 o##RPG II .SKIP .INDENT -3 o##Sort/Merge .LM -8 .SKIP With the availability of Version 3.0, RSX has become a high performance, high functionality operating system base for commercial applications. .PAGE .CENTER Chapter 3 .SKIP .CENTER Getting Started .SKIP 2 This section is for users who have never installed or used RSX. It is intended to get you "on the air" as quickly as possible beginning with that uncertain moment your system has been installed and checked-out, and you're about to open the first box containing the software. It also outlines the general process by which the software is installed and customized so that you may estimate the amount of time required. .SKIP 2 3.1##The Three Faces of RSX Beginning with the Version 3.0 release, RSX comes in three highly compatible "flavors". (There are also two other members of the RSX family, RSX-11M and -11S but these have become special purpose products and are only of interest to the traditional RSX customer.) .SKIP 2 3.1.1##Micro/RSX The low-end member of the family is Micro/RSX, the first version of RSX with a full set of commercial features. Micro/RSX was specifically tailored for the MicroPDP-11 and is the first version which can be taken out of the box, installed and used by a non-technical person. Micro/RSX served as the basis for A-to-Z V1.0 and is usually the system of choice for Micro-11 configurations. .SKIP 2 3.1.2##Pregenned M-Plus The intermediate family member is the "Pre-SYSgenned" or RL02 version of M-Plus. This is variant of M-Plus which is configured so that it runs on a wide variety of hardware configurations including the MicroPDP-11. It is self tailoring and, with the exception of certain features specifically selected through SYSgen, is identical to the full M-Plus system. This is the most appropriate system for commercial users on configurations other than the Micro-11. This version is only distributed on RL02 disk packs, and there are restrictions about which disk types may be used on the target system; otherwise, it is usable as soon as it is copied to the system disk. Unless you require special hardware support or Executive features which are not part of this version, you should use this version of M-Plus. Due to size constraints of the RL02, some parts of the full M-Plus system are missing. If any of these components are required on your system they may be copied from an M-Plus kit. .SKIP 2 3.1.3##RSX-11M-Plus M-Plus is the high end, full functionality system and must be tailored (SYSgenned) before it can be used. It is distributed in source form along with a baseline system (minimal Executive) with which a SYSgen may be performed. SYSgen is a question and answer process in which the user describes the exact combination of Executive features and device support desired. The Executive and associated utilities are then assembled and linked together to form a bootable system image. This image is further tailored by setting up partitions, installing tasks, etc. until a runnable system is finished and ready to be installed. More on SYSgen later. .SKIP 2 3.2##Installation and Startup Once the three versions of RSX are installed there are few differences between them. The three versions do, however, differ in the way they are shipped to the customer and in how they are installed. These differences are due to which assumptions can be made about the underlying hardware. .SKIP 2 3.2.1##Installing Micro/RSX Installing Micro/RSX on a MicroPDP-11 requires only that the software be copied onto the system disk. The distribution media consist of either a set of RX50 diskettes or a single TK50 cartridge tape. In either case, the first medium contains a bootable, standalone version of BACKUP. All that is necessary to install the software is to insert the first media unit into the appropriate drive and turn the machine on. Once the PDP-11 completes its self-check it notices that a medium is in place and bootstraps BACKUP into memory. BACKUP announces itself and then determines the processor type. The distribution kit actually contains two complete Executives. One of the system images is intended for use on processors such as the 11/73 and 11/83 that support separate instruction and data space mapping. The other is for processors such as the 11/23 which do not support I/D space mapping. The drive to be used as the system disk is initialized (and cleared of all existing data!); then the system software is copied into place. When the copy operation is complete, you are directed to remove the media and restart the system. The restart requests the time and date and then runs automatically through the remainder of the startup procedure. When startup completes, the console terminal logs itself out to prevent an unauthorized person from gaining access to your system. The system is now fully operational and ready for use. The entire process requires less than an hour. Micro/RSX was designed around systems with limited disk capacity and consequently there are some optional software packages which are distributed separately. These options are primarily those required for software development. If you have these options they may be installed right away or at some future time as needed. The procedures for installing optional software on Micro/RSX are described below. .SKIP 2 3.2.##Installing Pregenerated M-Plus The pregenerated M-Plus kit is the quickest and easiest way to get RSX-11M-Plus running on your system and, for most commercial customers, it is the most appropriate combination of SYSgen parameters. Installation involves copying the software onto the target system disk, selecting the appropriate system image file and installing the system disk handler. This process is not as automated as that for Micro/RSX and the dialog appears somewhat mysterious, but the procedure is only slightly more complicated. The entire installation is described, step by step, in a special chapter in the "RSX-11M-Plus System Generation and Installation Guide". The process does not require any great degree of computer experience as long as you have this guide handy when you begin the installation. The kit consists of a single RL02 which contains two ready-to-run system images with all necessary system files and utilities. The RL02 pack can be bootstrapped and (except for the lack of free space on the distribution volume) used straight away. One of the system images is intended for use on PDP-11 processors such as the 11/73 and 11/83 which suppor separate instruction and data space mapping. The other is for use on processors such as the 11/23 which do not support I/D space mapping. The non-I/D Executive can also run on I/D systems and it is, in fact, the system that runs when you first boot the distribution disk. Installation begins with bootstrapping the distribution disk on the target system. When the startup procedure asks for the time and date, the procedure aborts and a special standalone Backup/Restore is bootstrapped from the RL02. This special system allows initializing the target disk, locating and marking any bad blocks, and copying all contents of the distribution kit onto the target disk. At this point all files are in place, but the target disk is not bootable. What remains is to choose the appropriate Executive (I/D or non-I/D), configure it for the target system, and then make the system image bootable. These procedures are largely automated, though they do require you to type in some very strange commands that produce even stranger output on the console. It is from this type of dialog that SYSgen acquired its evil reputation. As of Version 3.0, however, it is no longer necessary to understand the process in any detail. You are not required to make any decisions other than selecting an Executive based on your processor type. Simply follow the instructions carefully. The last step begins with rebooting the kit disk. Interrupt the startup procedure and, following the instructions provided in the SYSgen and Installation guide, load the driver for the system disk, bring it on line, and set default to the desired system area. Selecting the proper system is the only decision you have to make and, unless you have good reason to do otherwise, it is determined by your hardware as described above. You then create a copy of the system image and invoke VMR which performs an automatic procedure to tailor the selected Executive to your system disk. You then make the image bootable by booting the image just tailord and "saving" it in such a way that the bootstrap code can locate the image file. The installation is now complete. The entire installation process requires less than two hours. .SKIP 2 3.2.3##Installing M-Plus Installing M-Plus is a two stage process. First, you copy the distribution kit to the target system disk. Second, you do SYSgen to build an Executive tailored to your specific hardware configuration and software needs. This process can be performed on an existing RSX system or on a new system. Compared to previous versions, SYSgen for RSX V3.0 is painless and largely automatic. If your hardware configuration is standard and you have no special requirements of the system, you can be finished in a few hours. If you are working on the target system you can direct SYSgen to "Autoconfigure" your hardware; it uses the results as the default answers to the most difficult questions. Furthermore, you can direct SYSgen to create a "full functionality" Executive thereby eliminating a large number of intricate questions about Executive options. If you accept all the default answers, the dialog section of SYSgen is largely a matter of confirming that little used options are, in fact, not desired. If you are an inexperienced M-Plus user, you are strongly advised to Autoconfigure on the target and accept all the defaults. In this way you get your system up and running as quickly as possible. Once you have more experience you may repeat SYSgen to create an Executive more closely tailored to your needs. Most commercial users find that the full functionality Executive suits their needs perfectly. On the other hand, if you have an unusual hardware configuration or have special needs, you may wish to contract for enough support to get you through the installation. RSX can be tailored to fit almost any hardware configuration manufactured, but the process of discovering all the ins and outs of CSR and vector assignments is a complex one. This is no time to play the hero. If you have doubts about your capabilities, call for help. Details of the installation and SYSgen process are beyond the scope of this section, and are described in the "RSX System Installation and Generation Guide". There are many different paths depending on what existing systems are available but the simplest is installation on new hardware. The sequence of events for installing on a new system is roughly as follows: Boot the distribution media. This starts up standalone Backup (actually an RSX-11/S system image) which you use to format the target disk and scan it for bad blocks. Copy the first of two backup save sets from the distribution media to the target disk. The result is a hardware bootable disk containing a baseline system which runs on almost any hardware and contains just enough functionality to complete a SYSgen. Boot the target disk. The baseline system automatically copies the second backup save set from the distribution kit to the target disk. Apply any necessary Updates. Unless you have obtained your software shortly after a major release of RSX there are likely one or more Update kits which must be applied to the target disk before you proceed with the SYSgen. This process is largely automatic. Invoke the UPDATE command procedure to apply the corrections. Invoke SYSgen. Again, there are many paths and options but the best plan for a beginner is to go straight through from the beginning to the end, accepting defaults wherever possible. While the simplest path does not require you to answer many questions, a copy of the dialog is useful if anything goes wrong. If you do not have a hardcopy terminal as the system console it is wise to connect a printer so that all output is saved. SYSgen asks a number of questions about how the Executive is to be built. Unless you know better you should always take the default. The exception is the question labeled SU100 which asks if you wish to run Autoconfigure. If you are running on the target hardware you should answer YES. Doing so results in an operation in which the system interrogates all the devices it can find and configures your peripherals accordingly. The only other questions you are asked concern hardware which was expected but is missing (why SYSgen asks if you have a card reader is a mystery) or about options that are costly or infrequently used (modem support on terminal lines). After about 15 minutes of dialogue SYSgen assembles and links the Executive and all the privileged tasks. Watch the dialog as it unfolds and compare it to the example in appendix D of the SYSgen guide. The remainder of SYSgen takes about three hours. The process is automatic but you are asked an occasional question, so it's a good idea to check in from time to time to see how things are progressing. When SYSgen completes you have a fresh copy of the Executive which is not hardware bootable. Follow the directions in the Guide to software boot the new Executive and enter the time of day. This action is only a sanity check to see that everything worked properly. SAVe the Executive. SAV causes the new Executive to be rebooted and begin the standard system startup procedure. If everything still looks all right, abort the startup as directed and SAVe the system again, this time with the /WB (Write Bootstrap) switch. This final step changes the bootstrap blocks of the target disk to point to the newly generated Executive. The system restarts automatically and you are on the air. .SKIP 2 3.3##Logging In and Other First Day Tasks Once your system is installed and operational the first thing you should do is log in as the system manager and make any additional adjustments you feel are necessary. Typical chores involve post-installation clean-up, selecting appropriate startup options, creating user accounts, configuring terminals and printers, and installing layered products. .SKIP 2 3.3.1##Logging Into the Prebuilt Accounts RSX is distributed with a System account and a User account. You can log into either one from an unused terminal (such as the console terminal once startup has completed. Press the Return key until you get the system prompt, which may be either ">" or "$". Type "HELLO" and press Return. You are prompted for a username and password. When these are entered and verified against the system accounting file, login completes. The prebuilt account username/passwords are SYSTEM/SYSTEM (or MICRO/RSX on Micro/RSX) and USER/USER. Once the login task validates your account it extracts other information about your account from the authorization file and then executes two command files on your behalf. The first of these, LB:[1,2]SYLOGIN.CMD, (if it exists) is executed for all users and, in its most common form, determines your terminal type with SET TERMINAL/INQUIRE and then chains to the LOGIN.CMD file in your default directory. If LOGIN.CMD exists, it is also executed. In the case of the USER account it prints out a welcome message and some introductory information. These two login files can be used to control the accounts in your system. In the case of A-to-Z they are used to direct the user directly from login into the appropriate A-to-Z menu. RSX supports two Command Line Interpreters (CLIs). MCR is the traditional CLI still favored by RSX old timers, while DCL is probably more familiar to newcomers. The account entry in the authorization file determines which of the two is established for a particular user during login. You may switch from MCR (usually identified by the ">" prompt) by typing .SKIP > SET /DCL=TI: .SKIP You may switch from DCL (usually identified by the "$" prompt) by typing .SKIP $ SET TERMINAL/CLI=MCR .SKIP Most users learn one CLI and stick with it. You should modify the authorization file entry for each account according to the user preference. .SKIP 2 3.3.2##Post Installation Cleanup The Pregenerated (RL02) version of M-Plus contains both an I/D and the non-I/D Executive. Once installation is complete you may delete the unused files to recover disk space. A command procedure is provided for this purpose. The System Generation and Installation guide tells how to proceed. The procedure is completely automatic. It determines which Executive is in use and deletes the unused files. At its conclusion the procedure reports the number of disk blocks recovered. You may postpone this task if you have sufficient disk space for the early days of usage. .SKIP 2 3.3.3##Customizing Startup The Micro and RL02 systems are shipped to you with certain system parameters, such as the number of batch and print queues, set to values appropriate for an "average" configuration. These parameters are stored in a file (LB:[1,2]SYSPARAM.DAT) which is readable by non-technical users and which is interpreted by the system startup procedure. Statements in this file determine such things as the amount of checkpoint space and secondary POOL allocated, what combination of batch and print queues are to be started, what to do about error logging, and so on. Provision is made for controlling every commonly used element of the system. If you can use an editor, you should have little difficulty modifying this file to your own taste. It is unlikely that you must do anything further. If you have chosen M-Plus, you are supplied with a skeleton system startup control file, LB:[1,2]STARTUP.CMD. This sample file is sufficient to get you on the air but it is expected that you want to modify it and know how to do so. Regardless of the system, if you have added A-to-Z and are running primarily A-to-Z applications you find that A-to-Z manages all of the usual system startup tasks. If you have requirements beyond those managed by A-to-Z you probably know how to take care of them. .SKIP 2 3.3.4##Configuring Terminals and Printers When RSX configures your system it can detect the presence of the various device controllers on the system, but in the case of serial and parallel ports it makes no attempt to determine the type of device, if any, which is attached. You have several options: If the devices are all terminals, you can let SYSLOGIN.CMD do the work with SET TERMINAL/INQUIRE which polls the terminal to determine its type whenever a user logs in. If the devices are a mix of printers and terminals and you are running Micro or pregenerated RSX, you can edit the parameter file LB:[1,2]SYSPARAM.DAT and designate each of the lines or ports with the appropriate device type and line speed. The next time your system is re-started the devices are identified and brought on line. If you don't want to be bothered, or if you are installing a system for a customer who may not want to be bothered, you should consider adding A-to-Z to the system. A-to-Z includes a process which runs at system startup which polls all available ports and determines the device type and speed of each line. This information is stored in a table where it is available for inspection or modification by the customer. The advantage of this is that if a terminal is moved or the speed of a device is inadvertently changed, the customer can deal with the problem directly without any special training. .SKIP 2 3.3.5##Creating User Accounts The procedures for adding, changing, and removing accounts are identical for all three systems. A utility (ACNT) may be invoked by any privileged user to make changes to the system accounting file (LB:[0,0]RSX11.SYS). Take care that this file is not inadvertently deleted. If the file is deleted you will have difficulty regaining control of your system. Before you enter a new account you should know certain things required by ACNT. You are asked to supply a username, typically the user's last name, which must be unique on the system, a password which is a "hard to guess" word of up to 39 characters, a User Identification Code (UIC) which classifies the user according to group and access privileges, a default CLI (DCL is easiest for most new users to learn), and a disk and directory for the user's files. The items are entered one at a time and the default directory is created if it does not already exist. The new user may log in immediately after you have entered the information for the account. There are several other items which you may enter including a session identifier, first name, and so on. You may also modify an existing account if you wish to change any parameter. Note that beginning with Version 3.0 of RSX you may opt for password encryption on an account by account basis. Such passwords may not be examined once they have been entered, so they must be specified anew if the original has been lost. If you have A-to-Z you may wish to manage your accounts with the facilities provided for the A-to-Z Manager. Unless you have special needs you should find that the facilities provided by A-to-Z are adequate and are much easier and safer to use. .SKIP 2 3.4##Installing Layered Products Installation on any version of RSX is largely a matter of copying files into the appropriate directories, possibly taskbuilding certain modules, and adding the necessary initialization commands to the system startup procedures. On M-Plus this is usually accomplished by a command file, supplied with the layered product, which conducts a dialogue with the system manager to determine which options are to be selected and then performs all the necessary tasks. Some products require that the system manager manually edit the system startup file and provide the appropriate commands. Micro/RSX has a more automatic installation architecture which makes it possible for a person with little or no computer expertise to manage the installation. A-to-Z has combined elements of both of these architectures. If you are installing A-to-Z layered products you may do so via an option on the A-to-Z Manager's Menu. The procedure is the same regardless of which version of RSX lies underneath. .SKIP 2 3.4.1##Installation on Micro/RSX The Micro/RSX user does nothing more than choose the product to be installed (in case there is more than one product module in the kit) and handle the media. The architecture and the layered product developer do the rest including making decisions about the underlying hardware, product specific installation and startup procedures, and integration with other components on the system. To install a product the user logs into the system manager's account (or the A-Z manager's account) and invokes the installation procedure OPTION.CMD (or selects the application installation option from the A-to-Z manager's Auxiliary Functions Menu). System software then requests that the installer identify the appropriate device drive according to the media type, insert the media, select the application to be installed, and then insert more media as required. While the particular product may require some customization there is nothing further required to get it running on the underlying system. .SKIP 2 3.4.2##Installation on M-Plus Layered product installation on M-Plus (both the Pregenerated and full SYSgen flavors) assumes a more sophisticated system manager with particular requirements. In this case the layered product developer supplies a kit containing all the components of the product and, with the nicer products, a command procedure with which the manager picks and chooses from the different combinations. The developer is still required to be sensitive to aspects of the product which may change from system to system such as re-linking privileged tasks or relocation of files and modules across disks. The developer is also responsible for providing information regarding the installation, usually in the form of an installation guide. The installation guide and the release notes are the basis from which the system manager decides between various options or, in some cases, redesigns the installation procedure to satisfy specific system conditions. There is no set pattern for installation on M-Plus. Generally, the Installation Guide provided with the product directs the manager to log in and create a temporary directory. The guide also describes conditions that must be set up before installation can proceed. Certain tasks may have to be installed or optional software may have to be moved into place. The manager then mounts the media, usually a magnetic tape or a disk pack, and copies the installation control file (traditionally INSTALL.CMD) into the temporary directory. The command file is invoked and, through a dialogue with the manager, determines what actions to take. Once the dialog phase is completed, the command file performs the remainder of the installation: copying and converting files, linking tasks, and setting up the database. The installation guide also usually provides the manager with information about what modifications must be made to the system startup procedure in order for the product to operate properly. Products for M-Plus differ considerably in the degree to which the installation is automated. Some come with a list of instructions for the system manager including general directions on what to add to the system startup command file. Others are more automatic. The trend is towards automation as available hardware resources become more plentiful and squeezing the last free byte out of a file becomes less important. An example of such automation is the A-to-Z Base System which not only controls its own installation, but carries with it elements of the Micro/RSX layered product architecture. This makes it much easier for a computer naive system manager to install and manage an application mix. It also makes it easier on the product developers since the kitting procedure for A-to-Z applications on Micro/RSX and M-Plus is the same. Only the media are different. .PAGE .CENTER Chapter 4 .SKIP .CENTER Terminals .SKIP 2 Terminal I/O is a prominent aspect of modern commercial applications on timesharing systems. It is, in fact, one of the primary reasons that the old batch processing systems have been replaced. It is also, unfortunately, a major source of system overhead. Problems related to this aspect of application design are particularly insidious because the cost of moving characters to and from a terminal is so easy to overlook. Most programmers understand that opening and closing files is costly. Far fewer consider what is happening when a screen is being painted. .SKIP 2 4.1##Cost of I/O The cost of a particular I/O operation can be divided into two general categories. The first is the number of instructions executed to move data from the program to the device controller (overhead). The second is time the device requires to move the data between the controller and the outside world (latency). With disks, much of the time required to fulfill an I/O request is latency due to the mechanical movement of the head and spindle. Once the disk head is moved to the proper cylinder, large quantities of data can be transferred very quickly, usually without CPU intervention. More on disks and files in the next section. .SKIP 2 4.2##Specific Cost of Terminal I/O Terminals are another problem altogether. There is a short latency period while a character is shifted into or out of a UART register but the real problem is that there are ever so many more I/O operations involved in moving a block of characters to or from the terminal. A disk can transfer thousands of characters in a single operation whereas most terminals make the transfers one byte at a time. .SKIP 2 4.2.1##Interrupt Service Terminals can cause almost 2000 CPU interrupts per second, and each interrupt requires the Executive to suspend processing to service the device. Even worse, terminals are unpredictable on the input side. Operating system software can keep track of the head position of a disk drive and can make a guess at how long a given operation takes. This permits operating systems to optimize the queue of waiting I/O requests. But there is no way that the system can predict how long it takes an operator to press a character key - the computer simply has to wait for the interrupt. .SKIP 2 4.2.2##Scheduler Overhead RSX considers completion of any I/O request to be a "significant event". Such events signal to the system scheduler that there may have been a change in various lists of tasks waiting to execute, e.g. I/O completion may have unblocked a task of higher priority than the current task, thereby requiring a context switch. With even a small number of commercial applications painting screens, the scheduler may be executing hundreds of times per second. Excessive context switching (thrashing) is a factor in almost every system performance problem encountered so far. The worst possible circumstance is when interactive tasks competing for memory are being checkpointed to disk. In this case each character moving to or from a program causes several far more costly disk reads and writes to take place. So the cost of moving a single character is the sum of the code to actually move the character to or from the device plus any program overlays which may have occurred plus the interrupt service routines plus the context switching. When many hundreds of characters are being moved back and forth every second the system overhead is considerable. .SKIP 2 4.3##Minimizing Costs There is little you can do to reduce the number of characters which must be moved to and from the terminal. You can, however, do a great deal to reduce the operating system overhead associated with terminal intensive applications by reducing the number of I/O requests necessary to move the requisite characters. .SKIP 2 4.3.1##Blocking Output Requests Whether or not DMA hardware is available, it is very important to gather small groups of characters together before sending them to the terminal. Throughput improvements of 10 to 1 are reported when scattered output requests are converted to calls to a central routine which assembles character strings into a single buffer. The amount of processing to move the characters to the terminal is the same in either case, but if the number of I/O requests is reduced there is a corresponding reduction in scheduler overhead. It is not always easy to determine just how an implementation language such as BASIC or DIBOL performs terminal I/O, but making the effort to find out is well repaid. For example, the following three DIBOL code fragments produce output that looks exactly the same to the operator: .SKIP .NO FILL .NO JUSTIFY WORST, ######DISPLAY (CHAN,'A') ######DISPLAY (CHAN,'B') ######DISPLAY (CHAN,'C') .JUSTIFY .FILL .SKIP This results in three I/O requests and some unnecessary interpreter overhead. .SKIP .NO FILL .NO JUSTIFY BETTER, #######DISPLAY (CHAN,'A','B','C') .JUSTIFY .FILL .SKIP This eliminates some of the interpreter overhead but there are still three I/O operations (and consequently three calls to the scheduler, etc.) involved. .SKIP .NO FILL .NO JUSTIFY BEST, #####DISPLAY (CHAN,'ABC') .JUSTIFY .FILL .SKIP Best of all. It is admittedly unlikely that the output data is so easy to assemble. Most often it is necessary to feed the data fragments to a subroutine along with a flag which serves as a "Do It Now" or "More Coming" signal. But it's worth it. .SKIP 2 4.3.2##Blocking Terminal Input It wasn't long ago that many operating systems were designed to only accept data from an operator in line mode - a series of characters terminated with the Return key. No sane Fortran programmer wants to see characters one at time or, Heaven forbid, a five character escape sequence. Operating system people were glad to avoid the headaches of having to worry about mapping all the ANSI escape sequences into terminator codes. They preferred to tell any developer who wanted to know whether an input string had been terminated with Up-Arrow or Down-Arrow to figure it out themselves. But terminals kept getting smarter and even people working in laboratories type with their elbows now and again, so eventually operating systems began to support commercial features, beginning with single character input and some going so far as providing elementary block mode facilities. There is, however, a certain amount of holdover code in language processors put in place in the good old days to give operating systems the appearance of block mode input and, in some cases, this code can get in the way. Thus, it is once again important for the designer to understand how a high level language translates input statements into RSX directives. Some languages, DIBOL for example, convert what appears to be a field level request ("READS") into a series of requests for single characters. The latest versions of such languages may, however, provide a means of control over such actions. This is important because grouping input characters or data has the same benefit that blocking output has. It often makes the job of the developer more difficult, and sometimes impossible, if the functionality of an application is going to be preserved. If you cannot avoid processing the input stream a byte at a time, so be it. But if it is possible to change the character-at-a-time to post entry validation you enjoy considerable improvement in overall system efficiency. .SKIP 2 4.3.3##Use DMA Terminal Hardware DMA terminal interface hardware reduces the number of interrupts the Executive must service to move a block of characters to a device. The terminal driver is able to treat the output side of the device much as it does a disk. The output operation is initiated and, except for the bus cycles stolen by the interface to fetch the next character, the CPU is free to perform other tasks. However, there is no great improvement with such an interface if characters are fed to it individually or in small groups. The greatest gain is seen when output data is gathered into a single block and sent to the device with a single I/O request. It is possible to output an entire screenful of information including escape sequences for formatting and setting character attributes.