My RSX Wish List One favorite pastime whenever RSX programmers gather is discussing what bells and whistles they would like to see in the next RSX release. The rules of this game are simple. A change cannot break anything that was allowed in previous releases or be so radical that it alters the basic principles of RSX. Besides being a good way to pass time, sometimes you actually get to see your ideas in DIGITAL code. If you look back through the early RSX Special Interest Group's wish lists and menus, you see about 30-40% of the items are now in today's systems. WISH #1: The RSX Super Manual ----------------------------- My list starts with the documentation. RSX systems tend to be located on factory floors, warehouses, laboratories, or broom closets. In fact almost evevywhere except close to the desk where I keep my manuals. I can carry four volumes. Invariably, the fifth volume I left behind has the answer I need. Ten years ago, I discovered the perfect RSX manual for the programmer who has to travel. I unstapled and removed the appendixes from every manual, including layered products like Fortran, and constructed one master manual. This single volume contains a full synpopsis of all commands, utilities, library routines, language syntax elements, system data structures, and possible error codes and messages. The RSX Manual set has improved by an order of magnitude since V1.0. It has also grown from five volumes to 12 three-ring binders. DIGITAL has already written the RSX Super Manual, it simple needs to be packaged correctly. WISH #2: Resource Wait ---------------------- VMS has many features that came from RSX. One of the VMS features I would like to see RSX adopt is resource wait. When a VMS process issues a system call and system resources are not available, the normal mode is to simply let the process wait until the resources become available. Almost every RSX directive error code but one indicates a programming error. IE.UPN means there was not enough system pool to execute the directive. Invariably the code to handle directive errors looks like the following: 1000$: ;Issue directive BCC 2000$ ; If CC - success CMP #IE.UPN,$DSW ;Did we fail on pool BEQ 1100$ ; If EQ - yes, skip HALT ;Programming error 1100$: WSIG$S ;Wait for some event BR 1000$ ; Try directive again The executive could handle this just as easily. If the resources (pool) are not available, the executive needs only to back up the PC to the directive and put the task into Significant Event wait. Like VMS, this would be the normal mode and a new directive (or TKB switch) would allow a task to handle the IE.UPN errors directly. WISH #3: Directive Errors ------------------------- This wish is tied to #2 and again comes from VMS. Once the IE.UPN error is handled by the executive, almost all other errors are now fatal conditions (with the provebial exceptions). Programs would be simplier and easier to debug if there was a task controllable mode that would let the executive abort the program on a directive error. TKTN could be made smart enough to output the directive, directive error, and descriptive text. WISH #4: Dumb QIO's ------------------- Outputting "HI WORLD" on the terminal can be a major operation in RSX. RSX needs simple, clean directives for doing simple, clean I/O to the user's terminal. VMS offers two alternatives the QIO$ directive: INPUT$ and OUTPUT$. These, in even a simplier form, would be useful for RSX. WISH #5: Attach, Attach, Who Has the Attach ------------------------------------------- If you have ever attached a device, you have encountered an interesting RSX feature. The error 'device already attached' (IE.DAA) is only returned if you try to attach the device twice. If someone else has attached the device, your request simply waits until they release the device. People have used a variety of interesting algorithms to determine if their attach will not succeed immediately. What is needed is a way for RSX to tell you this directly. Digital had a solution at one time, unfortunately it caused some undesirable side-affects and was retracted. WISH #6: RS-232 Support ----------------------- RSX supports RS-232 very nicely, as long as the device at the other end of the cable is a VT100. But the world includes such things as industrial programmable controllers, liquid scintillation counters, badge readers, terminal switches, and moisture meters. All have smart microprocessors and communicate using RS-232. None act like a terminal. The typical site will mix terminals and non-terminals on a single DZ11 or DH11. So you must use the terminal driver. The feature list needed is long. At the minimum, programmers need mechanisms that reliably read input arriving at 960 characters a second. Some devices tend to use BREAK as a signal, so there needs to be a way for a program to force BREAK. One device I have programmed required you to send it any character for it to send a data character back. There are literally hundreds of other little idioscyracies that need to be handled. The ultimate solution is a terminal driver that separates the interface interrupt logic from the software character handling. The current full-duplex terminal driver QIO's with some extensions would be supported. In addition, the driver would allow sites to 'plug-in' their own modules that implement line specific protocols. WISH #7: InterTask Communications --------------------------------- The best applications model the real-world: one program handles shipping, another the warehouse, and a third billings. Communications among people is a broadcast model, either single source (a memo from your boss to your group) or multi-source (an informal meeting around the coffee pot). RSX intertask communication most closely resembles a chain-letter. One task can send one message to one other task. The cycle repeats if the message must be broadcast. Breaking the chain brings seven years of bad luck. The only broadcast communication's vehicle in RSX is the global event flag. The information content is limited. RSX needs a broadcast communications mechanism which also extends restrictions on message size. The best analogy is a software Ethernet. A message can be addressed to a single destination, multi-cast to several destinations, or broadcast to the world. Like the real-world or Ethernet, messages age and would be discarded after a period of time. WISH #8: Device Driver AST's ---------------------------- This wish is strictly for hackers. RSX system programmers have long used device drivers that were not attached to any real device. The virtual disk (VD:) is an example. A user assigns a contiguous file to a virtual disk unit. Then when program issues a read or write for disk block 1234 to VDx:, the driver simply adds the starting block number of the file and fowards the request on to the real disk driver. A file is now a disk. The virtual disk driver acts as a filter for QIO's. It would dramatically increase the power of this technique if there were some means for the filter driver to be notified when the I/O completed, i.e. a device driver AST. Consider one way the virtual disk could be extended. Two disk drives could be treated as a single disk. The virtual disk driver would make single QIO read for 10 blocks into two requests when the boundary between the two drives was crossed. Imagine the performace if a ML11 (memory disk) and RP06 where tied together for a data base application. The keys could be positioned to be on the ML11 and the bulk data on the RP06. Device driver AST's also has exciting possiblities for communications, graphics, and real-time control. WISH #9: Home Directory ----------------------- Programmer's have homes. In my case my address is DL1:[7,114]. In my home I keep my EDTINI.EDT file, my mailbox, and other personal items. But when I change my UIC, RSX loses my address and I cannot find my home again. It is fairly easy to set a logical device (HO0:) to the home disk. What is needed is a simple means of determining the home directory and teaching programs such as EDT or mail programs to reference this directory. WISH #10: TKB (Same Day Delivery) --------------------------------- I started programming RSX in 1974. Considering I have spent 1/2 of that time at a terminal, I have proabably logged over 10,000 hours of connect time. And it seems about half of that waiting for TKB to finish. TKB is the bottleneck in the RSX program development cycle. The Fast Task Builder (FTB) is not a solution. Improvements are needed in building overlaided programs that link to overlaid resident libraries. I would be willing to use a TKB that uses 256KW of memory if it linked my tasks in 25% of the time. It may not be possible to improve TKB performance. But it would certainly be worth the effort. WISH #11: 32-bit Addressing --------------------------- This is simplier than it sounds. Version 3.1 of RSX-11M introduced the PLAS (memory management) directives. It then became possible for programs to manage large regions of memory. The next release of RSX-11M-Plus will have the fast mapping feature, speeding up use of the PLAS features by 20 times. All that is missing is a clean set of system library routines that let programmers take full advantage of the memory on their system. For example, it would be very powerful to have allocate/dellocate routines which let a program use a memory region as a 32-bit address pool. This is my TOP-11 wish list, in no particular order of importance or complexity. I would be interested in getting your list or feedback on my thoughts.