G:tut (06/04/82)
I think CMS is better than Unix. Of course, I use Unix every day for programming, documentation, and electronic mail, whereas I avoid CMS whenever possible. Nonetheless, I think CMS is superior, for several reasons: 1) CMS allows commands to be abbreviated. Instead of laboriously entering "cat" every time you want to see a file, you type "t", which is short for "type". 2) The question mark is not reserved, and can be used as a help facility. For example, "batch ?" yields an explanation of the batch command, rather than the C shell's unfriendly "No match" message. Incidentally, the ? was inspired by RSTS, which we all know is a paragon of software design. 3) You can't delete all your files in a single command without trying really hard. Only the last command below actually removes everything: erase * erase * * erase * * a erase * * a1 4) CMS can read almost any kind of tape; Unix tape work is a pain unless you're using tar. There's a lot to be said for IBM standard label tapes-- they can be read around the world, and have lots of useful information on them. In contrast, tar tapes can't be read on V6 systems, and blocked tar tapes made on Berkeley Unix can't be read on non-Berkeley V7 systems. Berkeley's tar cannot append information to a tape. 5) Much good software is available for CMS that doesn't run well on Unix. SPSS, IMSL, Tell-a-graf, etc, are all written in Fortran, and we all know the shortcomings of f77. When it was written, IBM's FORTHQ was a pioneering optimizing compiler; it is still very solid. In the end, though, one wonders why this message is being sent over a Unix-based network. When it comes to communications, IBM is very weak. Bill Tuthill
otto (06/05/82)
The last time I used CMS it had the weird property that if I took a snapshot of the files owned by user X (because he had a file I wanted to read or something), then user X edited that file by reading it, changing it, then writing it (with the same name but in a new disk location), MY access of that file would bomb out. The reason for this bomb out was that my pointer to his file was still pointing to disk location where the old file was located, not to the updated copy. Has this been fixed? If not, how do people deal with this strange property on a day-to-day basis. George Otto Bell Labs, Indian Hill ----------------------
G:cliff (06/05/82)
The property that one person changing a shared file can munge it up for anyone else using it is still a large part of the CMS philosophy. The only way around it is for the person with write permission on the file to be nice about the way he/she updates it. It is ok to create new files on the disk, and a simple RENAME does not hurt the other person (who doesn't see either the new file or the new name). So you make your update to a new file, quickly rename the old one to something like BLAH OLD1 and quickly rename the new one. This is how we update the system disks. Great, huh? You can imagine what happens to a disk that has two people writing on it... -Cliff Frost
jcwinterton (06/08/82)
The real problem with CMS's access to files with concurrent readers and writers is that CMS just don't give a d..n. What file system? John Winterton