The "Perfect" RSX by Ino Better Editors Note: Mr. Better is a long-time RSX advocate or pest, depending on your point of view. While his ideas on the "Perfect" RSX depart from traditional suggestions, we at the DEC/Professional feel it is important to be impartial and publish all input, especially given the season. ------------------------- Once again the RSX community is starting to debate the future of the RSX systems (DEC/Professional, February 1986). Given past performances, I am sure Mr. Stamerjohn and others will get it wrong if left to themselves. The trend seems to be to make systems "idiot-proof". Though why anyone would want idiots on their system in the first place is beyond me. The following 11 items get to the heart of what the RSX user community really needs to be successful: a system for people who do not eat quiche. TCL (Terse Command Language) --- ------ ------- --------- Typing is not one of man's favorite activities. In a recent poll, typing did not even finish in the top 500. The growing popularity of UNIX is proof that people value terseness over learning the spelling of hundreds of DCL keywords. MCR is a step in the right direction, but it still does not take human engineering concepts far enough. People want a terse, easy-to-type command language. All common commands and switches should be chosen by keyboard home row position. Using this scheme, "F" replaces 'DIRECTORY', "J" replaces 'DELETE', and so forth. Once ASDFGHJKL is exhausted, the other rows would be used for less common commands. Abort Forever ----- ------- There are some programs which never seem to run correctly. This would normally not be a problem, but unfortunately, there are some people who will always try to run them. If abort forever is too technically difficult, a destroy user switch would be an acceptable alternative. Trust-Me Mode ----- -- ---- In 1974 I wrote a simple program to output time to a LCD display. Every second, the program issues an output, mark time, and wait for event flag directives. Every second RSX checks to make sure the directives are legal. In the last twelve years, RSX has checked over 378,432,000 times that all event flag numbers are legal, all buffers have good addresses, and I used the right logical unit number in the QIOW. To date, my program has never slipped up, but just in case, RSX is still on guard. The trend seems to be to make operating systems more and more paranoid. Over 25% of the code in RSX checks for errors which will not happen once a program is debugged. All these redundant checks take time. I did not buy my system so the CPU could be used for address checking. A new system generation option should be added to RSX to conditionally assemble out all paranoid code. RSX should have more faith in its programmers. We have to be pretty good to start with or we would have never finished the I/O Reference Manual. Dumb Mode ---- ---- Dumb mode is on the other end of the spectrum from trust-me mode. Dumb mode assumes you have mastered nothing. Dumb mode prompts for everything. Dumb mode not only checks your event flag, it questions your intentions and verifies your loyalty. Some people think DCL is dumb mode, but it is not even close. DCL is backwards. Instead of prompting for what we cannot remember, DCL asks for the obvious. I very rarely forget COPY needs an input file and output file. What I never remember is how to create a new version of a contiguous file. A dumb mode COPY would query for input file, output file, block size, contiguous, ownership, supercede, and should blocks be spanned. The latter would include a four page explanation on whether block spanning is critical to defense of the nation. Crash Notification AST ----- ------------ --- RSX has flags and traps for almost every event which can happen on a PDP-11 - except the big one. Most applications classify crash as an event. Most people get very excited when a crash occurs, especially those still using TECO and EDI. RSX should treat a crash like any other normal event. To start with, crash should cause a significant event so the system will reschedule active tasks. A new directive, Specify Crash Notification AST (SCNA$), would allow application code to take appropriate action when the system is crashing, such as turning off the reactor or disabling login's. Priority Based Scheduling -------- ----- ---------- RSX claims to be a priority based real-time system, but like many things, the developers did not get the implementation quite right. It is immaterial what priority task are assigned. People are what count. This is one area VMS got right. On my systems, I want my boss to get great response time. We gave his VMS account a base priority of 28 and he thinks he has the greatest system programming staff in the world. When his boss got an account, we gave her priority 32 (nobody above this level in the corporation knows how to type). When it comes for new equipment authorization, we simply let the priorities drift back to 1. RSX needs this feature. There is no pecking order in the system task directory. People are what is important, and some are more important than others. Byte Randomizing Utility ---- ----------- -------- One serious defficiency of RSX is in the area of security, specifically a mechanism for erasing potential secure data left on a disk. I envision a new comphrensive tool which would extend the state-of-the-art in disk security. One current problem with today's security algorithms is all data is garbaged. This discourages "bad guys" from using up money, time, and mainframes in attempting to recover the data. My new tool would indeed make data unrecoverable, but it would leave just enough good data to keep any intrepid disk salvager fruitlessly busy for weeks. The tool would use high speed buffering techniques to write all data to tape. The tape can then be read back to disk and critical portions turned into mush. At our site, we call this tool the Byte Randomizing Utility (BRU). The SYSGEN Game --- ------ ---- You meet Fred walking down the hall. He has five manuals under one arm, seven magtapes and an RP06 under the other, and looks as if his death sentence has just been commuted to life on Pluto. You ask "What's up?" and Fred grunts "SYSGEN." Your only reply is to say "Gee that's tough man, we'll take good care of the wife and kids." SYSGEN does not have to be like this. What is SYSGEN but a seemingly endless series of random questions with prizes for the person who has the right answers. What is ADVENTURE but a seemingly endless series of random questions with prizes for the person who has the right answers. SYSGEN should be called what it is - a game. People should work to get features for their system. Instead of some dull questions, tell the user "You are in a tall room with a dragon sleeping at the other end. The dragon has its tail curled around logical device names". People would fight to do your system generations. Magazines like this one would could triple circulation by publishing the RSX-11M-Plus V2.1 map and speculation on how the cave system would change in the new release. New meaning would be added to the phrase "RSX Wizard". Telephone Support --------- ------- Life is not fair. The other day I called telephone support and reported a problem. They agreed it was a problem and promised it would be fixed five months from now in the next release. I tried the same answer on one of my users and ended up in my boss's office getting my attitude adjusted. Telephone support is an excellent example of automating a process. It use to take months for Digital to respond to my SPR and fix a problem. It now only takes minutes for telephone support to tell me it will be months before my problem is fixed. I sometimes think we would all be better off if Digital took the money they receive for telephone support and held a monthly beer blast for the users at each local office. Problems would still take months to resolve, but the waiting would be more pleasant. Reduced MTSF ------- ---- Recent data show Mean-Time to Spot Failure (MTSF) values have risen 117% since the introduction of the Micro-11 system boxes. MTSF values in 1986 are expected to triple as Micro/VAX boxes become more common. In one typical case, a site covered by 8-5 basic service called one morning about a blown power supply. The responding Field Service engineer found a machine room with 112 Micro/VAX and Micro-11 systems. The engineer finally found the failed system just in time to leave for the day. The process repeated for the new engineer sent the next morning, and the third day, and so forth. Ten years ago, MTSF was less than 60 seconds. A simple glance around the machine room console lights immediately identified which system had failed. If bringing back console lights is too old fashion, box designers should consider flares, whistles, or neon signs. Expensive Memory --------- ------ One of the great myths propagated by the computer industry is how far computer prices have fallen in the last 30 years. The myth is illustrated by the story of the $1.98 Rolls-Royce: "If automobile prices in 1950 fell at the same rate as computers, you could buy a Rolls-Royce for $1.98." What the myth fails to mention is if automobile operating costs also matched what has happened to the computer industry, it would cost you $745,125 a mile to drive the $1.98 Rolls-Royce. Consider computer memory. Since 1979 the cost of memory has fallen threefold. In the same time the minimum RSX memory requirements have quadrupled (16KW to 256KW)!. The future is worse. VAX/VMS does not seem to even have a minimum memory requirement! Cheap memory leads to wasted memory. DIGITAL should hold the line on memory and not allow any more price reductions. My capital budget for next year will not stand any more savings. ------------------------- This short list hits the high points of how to make a better RSX. I realize the radical nature of these ideas may cause some of you to think this is a April Fool's spoof. Maybe so. But if it is, why do some ideas still seem to make sense?