stack smashing Was: Re: Scanning Formats (TIFF vs. JPEG)

This talk about stack smashing brought up an interesting memory. I don't think I've ever seen a description of a special project that I worked on in the early 70's while at CDC SSD. This was a project for the Air Force Logistics Command, called Advanced Logistics System or ALS. The idea, which was pretty darned advanced for the time, was to maintain a real-time online database of all materials worldwide managed by AFLC. Each item would be tagged with a card and its status and location maintained in a large shared database as it moved through the system. Notions of equivalent and substitutible items were part of the process and a whole pile of software that dealt with making tradeoffs on time-to-delivery and priority was to be written. Yes, this also included nuclear devices. The programming of the applications was done by something like 1400 GSA personnel writing reams and reams of COBOL. Initially, most of the big-iron vendors submitted responses to the RFP. The first time, only CDC managed to pass the benchmark and it was decided to release a revised RFP that would enable more than one vendor to qualify. In the end, IBM managed to get the benchmark to run, but refused to submit a bid. This project was a huge cash cow for CDC, bringing in over $500M over the first half of the 1970's. The hardware was pretty straghtforward. Up to 4 CYBER 74s couipled to 4MW of ECS and multiple-access controllers on the mass storage (a farm of 844 disk drives), tapes and unit record equipment. Remote terminal equipment was 1700 minis connected to various third-party small card-handling equipment. I think the modems for the leased lines were Milgo. But the operating system was the interesting part. An application consisted of a number COBOL modules, each running as an independent task grouped together in a job called a "chain". Modules were normally resident in ECS and swapped into any available machine for running. Inter-module communication was performed via a special COBOL CALL statement, with normal COBOL parameter passing. Each machine cluster could run 128 chains consisting of 64 modules. The odd part of this was that all of those wonderful COBOL rules for parameter conversion had to be implemented in executive (privldeged) mode. In fact, other than for device drivers, the whole operating system was located in the CPU, which was very unlike most other CDC operating systems. Data management was a bit bizarre, operating outside of the normal file system, but running as its own set of modules. Eventually, Proxmire called a halt to the project, but I think it represents an interesting milestone in large online database applications. I don't recall any protection issues arising as part of this. Each module was constrained by its own RA and FL and communication with other modules was vetted by the OS executive. To be fair, the CDC machines did not have to deal with issues of virtual memory and the XJ instruction was very fast, saving and reloading the entire register file more than twice as quickly as it could be done with programmed loads and stores. While never implemented, it would have been easy for the lead (master) module in each chain to constrain what a member module could or could not do. Database record locking was done on a module basis, but a lock could be passed from one module to another within the same chain. Yet, I don't think one CDC programmer in 50 back then had ever heard of the OS, called TCM (eventually rechristened Zodiac in honor of a certain personage that was haunting the Bay Area at the time). I doubt that even the most hard-bitten CDC retro freak even remembers it now. Another blast from the past. Cheers, Chuck