Talk:Cray Time Sharing System

It is likely that the 1st paragraph has the order of development wrong. Indications are that LASL (now LANL) refined documentation and software developed initially from LLL (now LLNL). The mere fact that LTSS is the "Livermore" Time Shring System and LRLTran came from LLL and the use of LRL to refer to LLL means that paragraph 1 may require editing. An oral interview of the one of principals seems to confirm this. Awaiting confirmation from other written documentation. 143.232.210.44 17:14, 25 August 2006 (UTC)--enm 25 Aug 2006 19:00 (UDT)[reply]

Removed from main article text: "This entry was written by a non-CTSS user and likely needs more work." JulesH 11:37, 14 December 2006 (UTC)[reply]

I once worked in the NERSC system's group prior to NERSC moving to LBL. NERSC was primary author of CTSS, LTSS was the Livermore Computing primary OS. Los Alamos and other members of CUG did some secondary work, mostly in storage interfaces. Cray Research continued to offer it's Cray Operating System (COS) product for those sites interested in batch-orientated computing.

The LRLTRAN compiler was called civic. It incoporated many features of the Fortran 77 and later 8x standards. CTSS was largely coded in LRTRAN with the supporting library BASELIB using highly-optimised Cray Assembly Language (CAL) to further increase performance and reduce size. This was neccessary due the Cray computers not supporting virtual memory - only bounds checking.

Both LTSS and CTSS drew inspiration from the Multics project. CTSS offered a number of comparitively advanced features for it's time.

Checkpoint/restart. Process core dumps contained enough information to allow a process to be resumed. This facilitated debugging as well as allowing users to restart a compute run after an interruption.

Process channels. Five channels (a-e) were available to users. Each channel could run a chain of programs in a father-son-grandchild-.... relationship.

Process priority. Users could adjust the scheduling priority, but high priority runs were billed at a higher rate.

Strong debugging support. The DDT debugger was closely linked to efforts in the systems and compiler teams.

Strong support for compartmentation of processes and data by security level.

Garth of Izar (talk) 01:03, 23 April 2009 (UTC)[reply]