phipps@garth.UUCP (Clay Phipps) (12/29/88)
In article <4150@watvlsi.waterloo.edu>, smcmahon@watvlsi.waterloo.edu (Scott H. McMahon) writes: >In article <1951@scolex> seanf@sco.COM (Sean Fagan) writes: >>[Elxsis are a] bit like a 64-bit VAX; everybody should buy one 8-)). What ? You can fit 12 Elxsi CPUs into one computer and you want only one ? :-) At ELXSI, one motto was "we came to bury VAX, not to praise it". :-} >>Cybers (my favorite machines 8-)) are ... 64-bit in 180-state. > >[Cyber 180s are] my favourite architecture among the heavy duty 64bit frames. >...the 180 is a good clean design that too many people are unaware of >(not necessarily their fault). Part of this "ignorance" ...is CDC's fault. > >Does anyone out there have an opinion re: the 180 line?? The consensus in Europe appears to be that the CDC Cyber 180s are ... I know ! I know ! A blazing high-performance FORTRAN machine, right ? No, a great COBOL machine ! This is no secret inside CDC itself. In Europe, far more C180s are bought to run COBOL than FORTRAN. The C180 architecture has more of an IBM S/370 than a DEC VAX feel to it. It is register-oriented for conventional computation, but memory-oriented for BDP and vector computations. It has 16 64-bit X-registers (data), and 16 48-bit A-registers (addresses). Index values stay in X-registers. Instruction fields are organized usually into nybbles of 4 bits, addressable in "parcels" of 16 bits. Instructions are 16 | 32 | 48 bits long, although descriptor parts may make some BDP and maybe vector instructions even longer (I forget by how much). There is only one "instruction format" per opcode, and there are few cases in which the same operation can be performed with more than one opcode. The "BDP" (i.e., business data processing, as in COBOL) or string instructions have the feel of the IBM S/370, although the C180 may have some operations that the S/370 doesn't but the VAX does. The routine-call instructions and some branches are slow, relative to the rest of the instructions in the C180 higher-performance machines. The address space is segmented more like the GE/Honeywell MULTICS machines, with 4 bits of ring-id, 12 bits of segment-id, and 32 bits of byte-offset, and there are mechanisms to enforce restrictions on calls between programs or routines residing in different rings. System-wide page sizes can be chosen to optimize performance. In one configuration with many MBs of real memory, changing only the page size from 4K to 8K produced a dramatic improvement in response time for a heavy software-development workload. The C180, especially the smaller model 930 and kin, should be well-suited to a native UN*X, except for any assumptions that pointers are the same size as some size of integer. Although this is not "comp.os", a few other comments on the OS: The C180 native operating system: NOS/VE, is powerful, but it has no pipes or redirection features. Perhaps its best feature is its humane command language, esp. its regular interface for command parameters, so that a user can query a command (with the "discp": "display_command_parameters" command) to discover its parameters and their allowable values. Each parameter usually bears both a long "self-explanatory" name and a very terse abbreviated name. As a result, the absence of the moral equivalent of a "man" page doesn't leave a user helpless. The worst feature might be its file system, apparently designed as a reach from the C170's flat file system. Some of the things that ought to be simple, such as the notion of directories, came out complicated. -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
bga@raspail.UUCP (Bruce Albrecht) (12/31/88)
In article <2304@garth.UUCP>, phipps@garth.UUCP (Clay Phipps) writes: > The C180, especially the smaller model 930 and kin, > should be well-suited to a native UN*X, except for any assumptions > that pointers are the same size as some size of integer. With the standard disclaimer about not being an official representative of CDC, etc., I believe that we have announced plans to release Unix in 1990. NOS/VE has a Unix emulator, but it's rather slow because starting new processes is not as efficient as in a native Unix. > > Although this is not "comp.os", a few other comments on the OS: > The C180 native operating system: NOS/VE, is powerful, but it has no pipes > or redirection features. Perhaps its best feature is its humane command > language, esp. its regular interface for command parameters, so that > a user can query a command (with the "discp": "display_command_parameters" > command) to discover its parameters and their allowable values. > Each parameter usually bears both a long "self-explanatory" name and > a very terse abbreviated name. As a result, the absence of the moral > equivalent of a "man" page doesn't leave a user helpless. > The worst feature might be its file system, apparently designed as a reach > from the C170's flat file system. Some of the things that ought to be > simple, such as the notion of directories, came out complicated. I like NOS/VE a lot, so I'm going to pick some nits, here. Although it has no pipes, most programs have input and output file parameters, and it is possible to create file connections from some files to other files. It has the most sophisticated command language I've seen, with all the control structures of a higher level language (except case, which can be done with if/elseif), variables of basic types or records, and full expression processing of strings, integers and reals. NOS/VE comes with an on-line manual system, which includes an indexed search mechanism unavailable in man. Also, NOS/VE utilities all use the same command language facilities, so all of SCL is available, rather than some new convention changing from utility to utility in Unix. Each utility can also specify their own manual if help is desired. I will admit that the file system has some defiencies. There are no links, no shorthand to specify parent directories, and wildcards will definitely not be available before 1990, if at all (it's on the list, but some things can get deferred indefinitely). The quasi-directory $local is in many ways the NOS/VE equivalent of /tmp and /dev, although it doesn't allow subdirectories. With the new SCL file variables, file paths can be abbreviated, which is nice. There are a couple of things the NOS/VE file system has that Unix doesn't, are individual file permissions by user and group, and the ability to force all I/O for a file through a procedure. I could probably write a book on why NOS/VE is better than Unix, but I doubt many of you would want to read it, or much more than what I've written so far (if that much).
karl@ficc.uu.net (karl lehenbauer #) (01/05/89)
In article <1121@raspail.UUCP>, bga@raspail.UUCP (Bruce Albrecht) writes: > I like NOS/VE a lot, so I'm going to pick some nits, here. Although it has > no pipes, most programs have input and output file parameters, and it is > possible to create file connections from some files to other files. It... Yeah, even Kronos (super-old 6600 operating system) had standard input and output, tho' severly batch oriented (no stderr either.) It seemed really cool at the time. > ...I will admit that the file system has some defiencies. > There are no links, no shorthand to specify parent directories, and wildcards ^^^^^^^^^ > will definitely not be available before 1990, if at all (it's on the list, but > some things can get deferred indefinitely). WHAT?!?? That is, like, a fatal deficiency. One of the cool things about the Unix command line interface is how easy it is to do wildcards without jacking a bunch with your program. Consequently, unlike other systems, most commands for which wildcards are appropriate support them. Argument processing under Unix hasn't been standardized yet so it the combination occasionally causes programs to screw up. (For example, try under Sys V to 'touch' a file whose filename starts with a dash.) Nonetheless, if I understand you properly, CDC filesystem software is absurdly substandard by present-day standards. -- -- uunet!ficc!karl "The greatest dangers to liberty lurk in insidious -- karl@ficc.uu.net encroachment by men of zeal, well-meaning but without understanding." -- Justice Louis O. Brandeis
bga@raspail.UUCP (Bruce Albrecht) (01/05/89)
In article <2618@ficc.uu.net>, karl@ficc.uu.net (karl lehenbauer #) writes: > WHAT?!?? That is, like, a fatal deficiency. One of the cool things about the > Unix command line interface is how easy it is to do wildcards without jacking > a bunch with your program. Consequently, unlike other systems, most commands > for which wildcards are appropriate support them. Argument processing under > Unix hasn't been standardized yet so it the combination occasionally causes > programs to screw up. (For example, try under Sys V to 'touch' a file whose > filename starts with a dash.) Nonetheless, if I understand you properly, > CDC filesystem software is absurdly substandard by present-day standards. Wildcards are a nice feature, but I don't think the lack of them is fatal. We do have a System Command Language (SCL) function that returns a list of files in a catalog, and I think it is possible to write an SCL function that returns a list of the files in a catalog that match a wildcard specification. However, most NOS/VE commands aren't set up to process of list of files, so the main use for wildcards in NOS/VE would be a construct like: FOR EACH file in $wildcard('abc*') DO command i=file FOREND Wildcards make make some things easier, but the lack of them doesn't prevent one from getting the job done. I'm curious, though, about 'present-day standards'. Does VMS have wildcard file names? How about MVS or other IBM, Unisys, etc., mainframe operating systems?
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/06/89)
In article <1128@raspail.UUCP> bga@raspail.UUCP (Bruce Albrecht) writes: > >Wildcards make make some things easier, but the lack of them doesn't prevent >one from getting the job done. I'm curious, though, about 'present-day >standards'. Does VMS have wildcard file names? How about MVS or other IBM, >Unisys, etc., mainframe operating systems? No smilely face, so you must be serious !!! VMS wild cards (of course) UNIX and all varients (unicos, etc.) wild cards (ditto) Unisys (EXEC-8, very old version) form of wild cards and a limited directory facilty ("program files") CMS (ibm under VM) has them (if memory serves, I could be wrong on this) MULTICS (if memory serves) wc RSTS (dec pre-vms, pre vax) wc etc. Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
steve@nuchat.UUCP (Steve Nuchia) (01/06/89)
In article <83995@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: >CMS (ibm under VM) has them (if memory serves, I could be wrong on this) Small nit to a small side issue, but what the heck. I didn't learn CMS for nothing -- now I can talk about it on the net. Barf. CMS does not support wild cards in anything like the fashion we are used to. Filenames in CMS are three words, separated by spaces. The third word is the "minidisk", a kind of directory, and the other two are pretty much free-format identifiers. Some programs will accept an asterisk for a whole word, others will take trailing asterisks within a word, some may even take embedded asterisks. Quite a few make you type in the whole file name, and barf on attempted wildcards. If you get a chance to avoid CMS, take it. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/07/89)
In article <2794@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >In article <83995@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes: >>CMS (ibm under VM) has them (if memory serves, I could be wrong on this) > >Small nit to a small side issue, but what the heck. I didn't learn >CMS for nothing -- now I can talk about it on the net. Barf. Never said I liked it. > >CMS does not support wild cards in anything like the fashion we >are used to. Filenames in CMS are three words, separated by spaces. >The third word is the "minidisk", a kind of directory, and the other >two are pretty much free-format identifiers. Some programs will accept >an asterisk for a whole word, others will take trailing asterisks within >a word, some may even take embedded asterisks. Quite a few make you >type in the whole file name, and barf on attempted wildcards. But they are there. CDC doesn't have'm at all. But all in all I'd rather have a CDC than an IBM running CMS. > >If you get a chance to avoid CMS, take it. > Beats some of the choices (TSO) >-- Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
smryan@garth.UUCP (s m ryan) (01/08/89)
>Wildcards make make some things easier, but the lack of them doesn't prevent >one from getting the job done. I'm curious, though, about 'present-day >standards'. Does VMS have wildcard file names? How about MVS or other IBM, >Unisys, etc., mainframe operating systems? The person you're arguing with has a sad case of Unix-on-the-brain: if it ain't done exactly like in Unix, it ain't worth squat. Think of all the wonderful things Unix offers that NOS/VE doesn't: - only two segments, static+heap and stack. - no shared codes except libraries staticly assigned to segments. - no unified command processing. - no concept of subsystem which permit a layerring of commands. - no segment=file concept so all disc io gets an extra transfer through system buffers between the user space and discs. - no ability for file and system security. Given all these features, I can certainly see why Unix is the way of the future. By the way, while NOS does not have a `standard error file,' it does have dayfiles. Lordy, lordy, I wish I had dayfiles on Unix. -- The tears of Hreithmar quickly dried. -- s m ryan He claimed his proce: to fill the hide with scarlet gold and cover well -- Andwari's Gem and thus avoid a vengeance fell. -- 1/8
jesup@cbmvax.UUCP (Randell Jesup) (01/11/89)
In article <2618@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer #) writes: >WHAT?!?? That is, like, a fatal deficiency. One of the cool things about the >Unix command line interface is how easy it is to do wildcards without jacking >a bunch with your program. Consequently, unlike other systems, most commands >for which wildcards are appropriate support them. Minor correction: You're talking shells, not "Unix". It should be possible to write a shell for almost any usable computer, a shell that does wildcarding ala Unix. Many people mistake Csh, bourne-shell (Sh), or Korn-shell (Ksh) with "Unix". -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
karl@ficc.uu.net (karl lehenbauer) (01/12/89)
In article <5657@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > You're talking shells, not "Unix". It should be possible to write >a shell for almost any usable computer, a shell that does wildcarding ala Unix. >Many people mistake Csh, bourne-shell (Sh), or Korn-shell (Ksh) with "Unix". Well, it is really more than just the shell, because Unix programs get their arguments through the argc/argv mechanism, and they are for the most part written to expect an arbitrary number of file names on the command line, hence they are written to expect the shell to expand wildcards, as all the shells you mention do. So to the extent that the shells and the the contents of /bin and /usr/bin are Unix, Unix supports wildcards. Granted, there is no support necessary for this at the kernel level, although Unix' storing of directories as regular files makes processing them easy. -- -- uunet!ficc!karl "The greatest dangers to liberty lurk in insidious -- karl@ficc.uu.net encroachment by men of zeal, well-meaning but without understanding." -- Justice Louis O. Brandeis