Jerome Fine replies: Perhaps an actual example can help. I one had the responsibility of choosing a CPU, OS and language (well to be truthful, the choices were made - I needed to figure out if the choices were OK) to ensure that a READER (scanner device at one end) connected via a microwave link to a WRITER (laser plate maker at the other end which produced the actual plate to print a single newspaper page - about a mile away in the printing press building). As many plates as were required were produced by the 6 WRITERs (a computer guided laser printer which produced metal plates). This was being done back in 1981 and there was no reasonable device to hold the scanned image from the READER. Due to the way in which the WRITER functioned, it had to be pre-charged in some manner prior to the signal being sent via the microwave link from the READER to the WRITER. The timing window was about 200 milliseconds between the time the pre-charge was complete and when the information from the READER was required to start being sent to the WRITER. Otherwise, the plate produced by the WRITER would be faulty. The timing sequence was: (a) Check to see of the READER was ready to send (b) Check to see if the WRITER was ready to receive (c) Tell the WRITER to start the pre-charge (d) Wait until the WRITER says the pre-charge is complete (e) Tell the READER to start sending The real time aspect was that there could be NO MORE than 200 milliseconds between (d) and (e) and in practice, the program aimed for about 50 milliseconds with a maximum of 100 milliseconds. Incidentally, the communications between the PDP-11 and the computers in the READERs and WRITERs used serial lines at about 2400 baud, so the messages (about 10 characters each) could consume a non-trivial portion of the total time limit. Since there were 4 READERs and 6 WRITERs (any number of READERs could be connected to up to 6 WRITERS) and there were times when all 4 READERs were sending to at least 4 WRITERs, the co-ordination of 4 READER tasks and 6 WRITER tasks was not trivial. In addition, that was the function of the high priority job. In the low priority job, there were record keeping functions done of which plates had been made, etc. Sometimes the low priority job was very slow. It was ONLY a PDP-11/23 running RT-11. The low priority job ran 3 tasks which allowed personal to keep track of the completed plates for any issue of the newspaper. We might also have used TSX-PLUS as the OS, but I doubt that it could have kept up. Plus, we were restricted to a maximum of 248 KBytes and the production system only had 192 KBytes if I remember correctly. Running about 15 separate jobs under TSX-PLUS might not have been fast enough and they would have needed more memory (about 24 KBytes each). Each READER and WRITER was handled by a separate "task" in the high priority job. Do you begin to understand why a real time OS must be able to guarantee that each "task" be scheduled within a specified time limit so that the command to the READER to start sending could be completed within the window? Sincerely yours, Jerome Fine RT-11/TSX-PLUS User/Addict