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
seanf@sco.COM (Sean Fagan) (01/09/89)
In article <2371@garth.UUCP> smryan@garth.UUCP (s m ryan) writes: >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. Having has experience with all three OS's under discussion (NOS, NOS/VE, and Unix), I think I can make a few comments. >Think of all the wonderful things Unix offers that NOS/VE doesn't: >- only two segments, static+heap and stack. Hmm, let me see. In Xenix '286, I can get a segment (it will be a data-only segment until I tell it otherwise), and do with I want with it (except make it a stack, but that's a hardware limitation). Unix also normally has two "segments," but they are code and data (with stack going in code). >- no shared codes except libraries staticly assigned to segments. Text is shared. And, didn't you just say that Unix only has two segments? Please make up your mind. Under Unix SysVr3.x, making a shared library is *very* easy, and anybody can do it. I've been told that it's even easier to do under SunOS 4.0, but I don't have any experience with that. Besides, what did you want to share, if not libraries? Data, I suppose, but shared memory "segments" (there's that word again) provide a method of doing that (and, from what I understand of SunOS's shared libraries, you should be able to share data that way as well). >- no unified command processing. This can be either good or bad. NOS/VE *does* have unified command processing (NOS doesn't), but it's also very cumbersome. Unix, which doesn't have UCP, has also evolved into a fairly standard method. Embos, which runs on Elxsi's only, has the best command-line interface I've ever seen, putting NOS/VE to shame. >- no concept of subsystem which permit a layerring of commands. You could run a different shell. NOS, btw, has a truly horrible idea of a shell: you *can* specify your own shell, but it gets reloaded after every command has been executed (since it doesn't have VM, other than segmentation [i.e., Base + Offset, where Base is set by the OS], and you only have 2**17 usable address bits). The shell is, in my opinion, more flexible, but subsystems are neat (in NOS, a subsystem can schedule it's own processes to run, if it wants to). >- no segment=file concept so all disc io gets an extra transfer through > system buffers between the user space and discs. Memory mapped files have been in Unix for quite a while. BSD 4.3 was, I believe, the first "real" release to support them publicly. >- no ability for file and system security. Ahem. AT&T SysVr3.2 will, supposedly, be B1 secure. This is the same level as NOS. NOS/VE doesn't have that much more over NOS, and, again, Embos beats them both. >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. NOS/VE does, however. It still has dayfiles, though. A problem with dayfiles occurs, however, when you start running out of disk space, and the system wants to report this *in* the dayfile. BTW, with Xenix 2.3-with-C2-security, you will have auditing, which will give you most of the information you would want to get from dayfiles (except that programs under NOS often put little messages into the dayfile, such as what routine they're in [if you wanted to know]). NOS/VE has its advantages, as does NOS. Unix is, for my purposes, much more user-friendly than either (I should, I think, say "programmer-friendly," since NOS/VE was designed for users, while Unix was designed for programmers). NOS and NOS/VE get tremendous I/O throughput (NOS more than NOS/VE), while Unix tends to get trememdous programmer throughput. Embos, of course, beats them all. -- Sean Eric Fagan | "Merry Christmas, drive carefully and have some great sex." seanf@sco.UUCP | -- Art Hoppe (408) 458-1422 | Any opinions expressed are my own, not my employers'.
3ksnn64@pur-ee.UUCP (Joe Cychosz) (01/09/89)
In article <2371@garth.UUCP> smryan@garth.UUCP (s m ryan) writes: > >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. I would settle for just having a standard interface to simulate the B-display message. Sendmail does this to some extent. This way if you have a long running program you could always do a ps and tell where it is. I sure do miss telling people to look in there dayfiles.
vandys@hpcupt1.HP.COM (Andrew Valencia(Seattle)) (01/10/89)
/ hpcupt1:comp.os.misc / smryan@garth.UUCP (s m ryan) / 3:07 pm Jan 7, 1989 / >Think of all the wonderful things Unix offers that NOS/VE doesn't: >- only two segments, static+heap and stack. The Regions VM system allows a sparse and pretty much arbitrary address space. Since V.2 and above have this, it seems to be pretty much a part of UNIX. >- no shared codes except libraries staticly assigned to segments. Regions has shared libraries, albeit a lame implementation. Sun's merge with AT&T should hopefully improve this. Many vendors have improved markedly on this base implementation, all the way up to dynamically-loaded libraries. >- no unified command processing. Meaning a common JCL? Dunno. I worked with RJE and JES2, and can appreciate the benefits of having a common way of managing jobs. But a flexible and interactive environment like UNIX makes it hard to just lay down the law on how a job should be presented to the system. Bourne shell scripts are probably as close as you get. >- no concept of subsystem which permit a layerring of commands. Not true. When you enter mailx, for instance, you are in a "subsystem" with a tailored set of commands. A true hierarchy could even be implemented, although nothing in UNIX forces this. *Should* it force it? I think not. But that's just a personal opinion. If you can sell it to the standards bodies, more power to you! >- no segment=file concept so all disc io gets an extra transfer through > system buffers between the user space and discs. Mapped files are available on many VM systems. Again, the Sun/AT&T merge should hopefully provide Sun's mapped files implementation in terms of the Regions VM system. I'd say you can start counting on this feature becoming standard. >- no ability for file and system security. Various vendors have qualified all the way up to B1. What sort of security did you have in mind? Your *average* UNIX system doesn't have such security, as it can get in the way of normal user operations, especially past the C level. >Given all these features, I can certainly see why Unix is the wave of the >future. Vendors are definitely listening to what customers want. If we don't, we lose. So we are (at least around here). Andy Disclaimer: these are only my own opinions!
ron@ron.rutgers.edu (Ron Natalie) (01/10/89)
> - only two segments, static+heap and stack. > - no shared codes except libraries staticly assigned to segments. This has little to do with the operating system, but more to do with the underlying hardware. UNIX on certain enlightened systems have both features. It's just hard to implement these things portably when you may or may not be able to support them on a given architecture. _Ron
smryan@garth.UUCP (s m ryan) (01/10/89)
>>- no concept of subsystem which permit a layerring of commands. > >You could run a different shell. NOS, btw, has a truly horrible idea of a >shell: you *can* specify your own shell, but it gets reloaded after every >command has been executed (since it doesn't have VM, other than segmentation >[i.e., Base + Offset, where Base is set by the OS], and you only have 2**17 >usable address bits). The shell is, in my opinion, more flexible, but >subsystems are neat (in NOS, a subsystem can schedule it's own processes to >run, if it wants to). That's subcontrol points. Actually, the real problem with NOS shells is their `features' which cause destructive interaction with CONTROL and EXCST. I'm not sure how many people even know what a NOS/VE subsystem is. Oh, sure, you could stack up local variables on some file and hope no one removes them. Subsystems are akin to objects, permitting a hierarchial organisaion of the environment. >>- no ability for file and system security. > >Ahem. AT&T SysVr3.2 will, supposedly, be B1 secure. This is the same level >as NOS. NOS/VE doesn't have that much more over NOS, and, again, Embos >beats them both. You haven't seen selective security until you've seen permits. I don't know what all these levels mean, but does supposedly really mean the same as already implemented? Will it include access levels? Er, why does Unix always seem to be run with the DEBUG switch set? Doesn't seem to have any problem with running SYOT from IAOT jobs. >>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. > >NOS/VE does, however. It still has dayfiles, though. A problem with >dayfiles occurs, however, when you start running out of disk space, and the >system wants to report this *in* the dayfile. SYSTEM, ACCOUNT, and ERRLOG can all be terminated and purged. CSUCS had a local mod to permit job dayfiles to be terminated and purged. > (except >that programs under NOS often put little messages into the dayfile, such as >what routine they're in [if you wanted to know]). In fact many people do. Not all of those little messages go to the dayfile. Line 1 and 2 messages can replaced as often as desired without adding to the dayfile. Do an <ESC>e and you can find out what stage your job is at. Unix is much better of course: either you get little messages until your terminal runneth over or you get dead silence. >NOS/VE has its advantages, as does NOS. Unix is, for my purposes, much more The problem with people with Unix-on-the-brain is their inability to recognise what other people have done. What I like about Unix just about matches what I dislike. And I detest programs that require specific file names. -- 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
smryan@garth.UUCP (s m ryan) (01/11/89)
>This has little to do with the operating system, but more to do with >the underlying hardware. UNIX on certain enlightened systems have >both features. It's just hard to implement these things portably >when you may or may not be able to support them on a given architecture. It has alot to do with the operating system. VSOS virtual memory is essentially a flat one-segment model, but the operating system supports file mapping and something akin to segments with Q5MAPIN. (Geez, I didn't think VSOS could teach anything to anybody.) The problem is expecting Unix to run on a PDP-11 and machines with real VM. -- So Loki left for elves of night, -- s m ryan who lived anigh the halls of plight. He found a pike who swam alone -- Andwari's Gem and cast the drowning net of Ron. -- 1/8
woolsey@nsc.nsc.com (Jeff Woolsey) (01/12/89)
In article <2381@garth.UUCP> smryan@garth.UUCP (s m ryan) writes: >I'm not sure how many people even know what a NOS/VE subsystem is. Oh, >sure, you could stack up local variables on some file and hope no one >removes them. You mean like ZZZZZC0, ZZZZZC1, ZZZZZC2? (CCL scratch files) >Er, why does Unix always seem to be run with the DEBUG switch set? Doesn't >seem to have any problem with running SYOT from IAOT jobs. Gee, we used to do that for real during Systems Time on NOS. Great fun submitting a job which kills off IAF, does a SYSEDIT, and brings IAF back up, all from a terminal at home. >>>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 history mechanisms are a sorry excuse for a dayfile. A dayfile, however, can be heuristically treated like a history mechanism. A custom Unix shell could make history LOOK more like a dayfile, but it won't be quite as useful. >>NOS/VE does, however. It still has dayfiles, though. A problem with >>dayfiles occurs, however, when you start running out of disk space, and the >>system wants to report this *in* the dayfile. >SYSTEM, ACCOUNT, and ERRLOG can all be terminated and purged. CSUCS had >a local mod to permit job dayfiles to be terminated and purged. CDC eventually provided that feature on the DAYFILE command. What I always wanted was an option so that the user could have the system write ACCOUNT dayfile messages into the user dayfile, too. Especially if the site is recording permanent file activity in the ACCOUNT file. -- -- When it comes to humility, I'm the greatest. -- Bullwinkle J. Moose Jeff Woolsey woolsey@nsc.NSC.COM -or- woolsey@umn-cs.cs.umn.EDU