Luxury! The HP2000 year number (2 digits, I think) had to be manually bumped by the system operator and the day-of-the-year reset.
One year (1980?) they were slow getting back to work after New Years, and we were up to day ~374 of the year before they reset it. (Luckily, because of the leap year calculations I was doing, my bulletin board program displayed the correct date despite all that.)
Was that before or after the modem wars, when anything above 2400 was a wild west shoot-out between proprietary formats? (US Robotics and … those other guys.)
It was pretty awesome doing uunet Coherent updates at 14.4k. Vroom!
I recall that it was really the 28.8 kbps and higher modems that had the big standards wars (V.34 vs VFast and the inevitable V.Everything that followed, and the later X2 vs K56Flex wars).
US Robotics modems were always the ones that I coveted but that I could never afford.
RSTS/E behaved pretty much the same as CP/M. No logins, and a single process. When sysgening the 11/84 and 11/83 boxes I always mounted a scratch disk. There were too many obscure ways for it to fail.
We used RSTS to run DZTEST, which excercised our IO cards. You would put loopback plugs on the ribbon cables coming out of the cards, and the test software would bounce messages around.
RSX11-M was a pretty solid system. If it crashed, the probable cause would be a faulty IO card (most of our cards were IO because we were running traffic signals off them). You could count on the bus address of the dead card to be in one of the registers which it dumped to the console.
I had managed to get a USR X2 prior to it betting ‘adjusted’ to the v.90 spec for a reasonable price (combination of working for a large reseller of USR products and a mail in rebate.) it was… amusing. I can almost whistle the train-up conversation on it. (if you have a butt set or a non-intrusive line monitor, you can get a taste of it by eavesdropping on a fax machine doing it’s thing- the train up conversation is almost the same as the 14.4 and 28.8 modems of the day,
Are you sure you’re not remembering RT-11, or RSTS without the /E? I only interacted with RSTS/E as a user - the systems I got really down into the internals of were RSX-11M/M+ and TSX-11 - but I’m certain I remember logging in, and the acronym is for Resource Sharing/Time Sharing, which implies multiple processes serviced through time slicing pretty strongly.
I’m sure I’ve used a RSTS/E system that had many simultaneous users, around 1978 or thereabouts. Each user had numeric group and user ids.
EDIT: Oh, duh, you are referrring to the sysgen itself, which I’m sure was single-process, just like RSX11M. I’m a little fuzzy today!
Yeah, it sure was, it’s a very strong very real-time system. I used to crash it a lot, but frankly that was because we were doing things DEC never anticipated, like poking bits in the executing kernel and shutting down garbage collection entirely and stuff like that. We were driving the system well beyond what DEC thought it could do when we tested the Harpoon missile, and the Peacekeeper launch systems’ HGG, for example.
I don’t miss TKB memory mapping, I have to say. Kids today have no concept of what it was like to literally map the bits of their compiled program to specific locations in memory…
No actually you are right. I was confused about the variant of RSTS I had been using, and when I talked about a single process I meant that for us RSTS was a single user system.
We operated the SCATS traffic signal system. Each PDP-11 would connect to 120 traffic signal controllers. It performed all the adaptive traffic signal coordination, as well as managing the state of the system (detecting faulty lamps and detectors) and allowing remote administration of each intersection.