heintze@fmcsse.enet.dec.com (Siegfried Heintze) (10/18/90)
Having used VMS for many years and being terribly ignorant of the different
flavors of U*
I would like solicit comments from programmers experienced in both VMS and U*.
Specifically I would like to know what makes U* a better development
environment.
(I assume there is someone out there who is certain U* is a better development
environment.)
As I understand it, the biggest difference between the capabilities of VMS and
U* is that when
you get U* you get many important tools for free whereas in VMS you have to pay
extra.
VAXset is an example of a set of tools for VMS that includes LSE (a fully
programmable
language sensitive editor vaguely akin to EMACs editor using templates - I
think), PCA (Performance Coverage Analyzer, a profiler)
and SCA (source code analyzer - I don't know if U* has a counterpart). SCA has
been extremely useful because it is integrated with LSE and allows you make very
complex queries about
your source code like "find all the occurences of variables of type x whose name
matches
the pattern *jj*h in the set of routines whose names match j* in call tree x
..."
So, assuming VAXset is part of the VMS environment, what makes U* better?
(Feel free to answer in the context of "money is of no concern" as well as
"money is significant").
Siegmjr@hussar.dco.dec.com (Marcus J. Ranum) (10/18/90)
In article <16438@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes: >So, assuming VAXset is part of the VMS environment, what makes U* better? >(Feel free to answer in the context of "money is of no concern" as well as >"money is significant"). As a pure development environment, none is better than whatever one you're most familiar with. When I did [uck!] some coding on PCs, I used a toolkit that hid the PC from me by making it look Unix-like. If I do development on VMS, I'll try to work from within Eunice. Not because one or the other is inherently *better*, but because Unix is what I know best. [I happen to have learned Unix in preference to everything else because the way it works resonates nicely with the way I think] This argument cuts both ways, of course. The big benefit I think a lot of people see in Unix is that it offers the *potential* for a high degree of portability (inter vendor, inter platform, inter O/S - sometimes) if due care is taken. This makes a *BIG* difference if "money is significant" is the answer. mjr.
ckp@grebyn.com (Checkpoint Technologies) (10/18/90)
In article <16438@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes: >Having used VMS for many years and being terribly ignorant of the different >flavors of U* I would like solicit comments from programmers experienced >in both VMS and U*. > >Specifically I would like to know what makes U* a better development >environment. (I assume there is someone out there who is certain U* >is a better development environment.) > >So, assuming VAXset is part of the VMS environment, what makes U* better? >(Feel free to answer in the context of "money is of no concern" as well as >"money is significant"). > Sieg We switched from VMS to Unix for the reason that, these days, "portability" and "openness" are industry watchwords. Using VMS ties you specifically to DEC and whatever direction they choose to take. Using Unix means that we can abandon a vendor which is not supporting us adequately, and switch to another (which might not either), in search of the best available support. The switch from one vendor's Unix to another may not be trivial, but it's sure less painful than VMS to anything else. Personally, as a programmer I prefer the facilities of VMS, which are capable if not necessarily convenient; and the VMS manual set which, if not exactly readable, at least has all the details I have needed. I can't exactly say the same for Unix. I haven't used the VAXset, and now I probably never will. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
chris@mimsy.umd.edu (Chris Torek) (10/18/90)
In article <16438@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes: [much about tools deleted] >So, assuming VAXset is part of the VMS environment, what makes U* better? >(Feel free to answer in the context of "money is of no concern" as well as >"money is significant"). If one assumes that money is significant, a simple answer turns up, one which has little to do with availability of tools (though some to do with their prices). That answer is this: DEC uVAX 3 with VMS: cost approximately US$15,000; speed around 5 or 6 Meaningless Indicators of Processor Speed. Any SPARC or MIPS system with UNIX: cost approxmately US$5,000; speed around 20 Meaningless Indicators of Processor Speed. The MIPS numbers are extremely slippery, and the costs above are far too `rounded', but it is now clear that Unix boxes cost less and run faster than VMS boxes. The money saved can be spent on buying or developing production tools if necessary, and the result is a system that runs about four times faster. You can get a faster VMS machine by throwing more money at the problem, but you can also get a faster Unix machine the same way. For the price of a VAX 9000 system you can probably buy an Amdahl or a couple of dozen MIPS 6280s (the MIPS 6280 system being between 55 and 65 Meaningless IPS). This is, of course, a relatively recent development, but certainly an important one. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
herrickd@iccgcc.decnet.ab.com (10/19/90)
In article <16438@shlump.nac.dec.com>, heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes: > Having used VMS for many years and being terribly ignorant of the different > flavors of U* > I would like solicit comments from programmers experienced in both VMS and U*. > > Specifically I would like to know what makes U* a better development > environment. [much of his question omitted] > your source code like "find all the occurences of variables of type x whose name > matches > the pattern *jj*h in the set of routines whose names match j* in call tree x > ...." > This one "feature" of VMS is enough to make one climb the walls after one becomes accustomed to UNIX regular expressions. There are one or two other advantages of UNIX. dan herrick
wcs) (10/21/90)
In article <1990Oct17.211857.19213@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > >So, assuming VAXset is part of the VMS environment, what makes U* better? > As a pure development environment, none is better than whatever > one you're most familiar with. Only if the environment you're familiar with is good enough. When I switched to UNIX, the environment I was most familiar with was IBM TSO, and ANYTHING was better than that, except punch cards which I also knew well. (Unfortunately, vi is "good enough", so I stil haven't switched to EMACS, in spite of its obvious superiorities. :-) Marcus goes on to say good things about using toolkits to make the new environment emulate the old one when possible. Bill -- Thanks; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ Government is like an elephant on drugs: It's very confused, makes lots of noise, can't do anything well, stomps on anyone in its way, and it sure eats a lot.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/22/90)
Well, there are a lot of tools using the same conventions, so you can
learn something and use the info in many places. Regular expressions
come to mind.
There are a number of user interfaces, allowing the developer to use
the one most suited to his (her) needs or preferences. In the same vein
there are more editors than you can count, and many are customizable.
UNIX has a large number of tools which manipulate data and pass it on,
giving the ability to do many ad hoc text enquiries and manipulations
using pipes, without intermediate files. This is simply not practical in
VMS, due to the high overhead required for process creation. No matter
what the horsepower of the CPU, a pipe with more than a few processes is
slow. I have run DECshell on an unloaded large VAX (sorry, number
escapes me), and it is a pig.
The filenames are more consistant in UNIX, and you can have links when
needed to make directory structures intuitive. That doesn't mean simple,
just that you can find the same data file in /techrept/mit and
mit/techrept, without having multiple copies. You don't need to know
where a file is physically to get to it, that's the diference of
"~joe_s/doc/scan" as opposed to "BIGVAX::USR$DISK3:[JOES.DOCS]SCAN."
VMS assumes that it knows what you're doing, and UNIX assumes that
*you* know what you're doing. If a filename doesn't have a dot in it VMS
usually wants to add one, and a filetype. Often it guesses right, but it
still guesses.
UNIX has what appear to be better tools standard to allow multiple
users to develop on the same project, Notable SCCS and make. And there
are versions of these themes if you don't find vanilla fits your
situation.
Portability is important. You can do development on a number of
platforms, and if you follow some rules the result can be run on any and
all of them. You really can do development on mixes like Ultrix, SunOS,
and V.3.2, with all developers compiling the successive production parts
on their machine, but doing the editing and testing of modules against
the current base locally. NFS makes this possible.
Access control in VMS can be by access control list, that's not in
most versions of UNIX. UNIX uses groups to get the same functionality,
but it works poorly if you have a large number of files and need to
control access to each one individually. That is not usually needed or
even remotely useful in most software development environments.
That's about it for head to head in my mind, I find the UNIX
environment easy to tailor to the way I want a computer to work, and
that usually improves productivity.
--
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -meandyo@glasperl.masscomp (Andy Oram) (10/23/90)
It's been almost a week since Siegfried Heintze made his bold request. I'm
gratified to see no one has flamed him, but really no one has made a strong
answer either. The utilities and shell tricks and so forth are nice, but what
about the design choices that make UNIX popular for systems and applications
programming?
This group is comp.unix.programmer, after all. Isn't there someone out there
who can summarize the differences in working with the guts of VMX and UNIX,
someone who can speak from the experience of porting highly interactive
applications or writing device drivers or something like that? There must be
some good general learning experiences here.
Guess everybody's too busy developing more such experience...
(I don't have such direct experience, so I've limited myself to replying to
Mr. Heintze by E-mail.)
-------------------------------------------------------------------------------
Andrew Oram Concurrent Computer Corporation
(I don't represent Concurrent; this message represents my own opinion)
Digital Communications Route: andyo@westford.ccur.com
{harvard,uunet,petsd}!masscomp!andyo
Analog Communications Route: (508) 392-2865
Automatic UN*X documentation utility:
cref | compress | crypt | man
-------------------------------------------------------------------------------hamm@austoto.sps.mot.com (Steve Hamm) (10/25/90)
-----On 23 Oct 90 14:14:16 GMT, andyo@glasperl.masscomp (Andy Oram) said:
Andy> It's been almost a week since Siegfried Heintze made his bold
Andy> request. I'm gratified to see no one has flamed him, but really
Andy> no one has made a strong answer either. The utilities and shell
Andy> tricks and so forth are nice, but what about the design choices
Andy> that make UNIX popular for systems and applications programming?
Andy> This group is comp.unix.programmer, after all. Isn't there
Andy> someone out there who can summarize the differences in working
Andy> with the guts of VMX and UNIX, someone who can speak from the
Andy> experience of porting highly interactive applications or writing
Andy> device drivers or something like that? There must be some good
Andy> general learning experiences here.
I would speculate that there aren't that many people who have seriously
used both VMS and UNIX. I have, at least somewhat seriously, although
I don't consider myself expert on either one. I've used most of the
system service calls under VMS, and done some strange terminal I/O
stuff under BSD. More explicitly, I used VMS from versions 1.x to 4.x,
from 1979 to 1986, and UNIX from 1986 to present. I bought VAXset,
which was referred to earlier, when it first came out, and watched
it develop.
I develop simulation software, and do not do device drivers or kernel
hacking. My views would undoubtedly be different if I did device
drivers or internals.
Frankly, other than the portability argument, I don't think that
there's a lot of reason to switch from VMS to UNIX. (Other than
getting out from under DEC's very expensive domain.) VAXset compares
very favorably with the standard make/SCCS setup. VERY favorably: CMS
has features in it that make it look OK compared to SCCS/RCS. MMS
(comparable to make) is miserable and cryptic, but so is make. The
code/variable navigation capability of (PCS? forget the name) isn't
available under UNIX unless you buy some third party stuff. The VMS C
compiler was nearly ANSI three or four years ago -- most other vendors
haven't got their ANSI compilers out yet. And, as a command language
environment, UNIX has a lot to hate: every command is its own little
world, with its own syntax and, frequently, the same switch does
something entirely different. VMS has commands that behave according
to the same rules, with consistent syntax. There are some things that
I used to do under VMS with a one line, relatively short command, that
take a shell script with a find command to do under UNIX. Of course,
you can do anything with a complex enough find command ;-)
VMS, of course, has lots to get irritated about also, but I think a
person in the know can match point-for-point with similarly irritating
UNIX characteristics. I can get my job done, reasonably well, in
either UNIX or VMS.
Now I am using UNIX and wouldn't go back to VMS (well, if someone
offered me LOTS of $$, perhaps). Why? DEC lost the workstation war
(or at least the first round of battles), and my program runs on
workstations. If I port to a DEC machine, it will have to be one
running ULTRIX: VMS is an expensive, proprietary environment, and that
means lots of work, time, and effort in porting for a limited
audience.
--
Steve Hamm ------- Motorola Inc. Semiconductor Systems Design Technology
3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
Ph: (512) 928-6612 Internet: hamm@austoto.sps.mot.com
Fax:(512) 928-7662 UUCP: ...cs.utexas.edu!oakhill!austoto!hammgeoff@edm.uucp (Geoff Coleman) (10/25/90)
From article <ANDYO.90Oct23101417@glasperl.masscomp>, by andyo@glasperl.masscomp (Andy Oram): > This group is comp.unix.programmer, after all. Isn't there someone out there > who can summarize the differences in working with the guts of VMX and UNIX, > someone who can speak from the experience of porting highly interactive > applications or writing device drivers or something like that? There must be > some good general learning experiences here. > Sorry I missed the original question so I might be jumping in with both feet firmly implanted in mouth here. What do you mean by the guts of VMS and UNIX? If you are talking system level programming and accessing devices then Unix is a big winner IMHO. Why you ask? Well any O/S who's language of choice for opening and controlling devices is FORTRAN (or BLISS) ala VMS has definite drawwbacks. I seem to remember that when I wanted to open a tape drive I had to convert the C strings into structs with a length component etc. THe other obvious downfall of VMS from my point of view was the need to worry about the inifinite combination of file types (fixed length records, fixed block size) versus the UNIX philosophy of a file is a file is a file. As well there are the obvious problems of proprietary systems not easily supporting third party terminals etc. Of course all of this is a few years old. Geoff Coleman Unexsys Systems > Guess everybody's too busy developing more such experience... > > (I don't have such direct experience, so I've limited myself to replying to > Mr. Heintze by E-mail.) > > ------------------------------------------------------------------------------- > > Andrew Oram Concurrent Computer Corporation > (I don't represent Concurrent; this message represents my own opinion) > > Digital Communications Route: andyo@westford.ccur.com > {harvard,uunet,petsd}!masscomp!andyo > Analog Communications Route: (508) 392-2865 > > Automatic UN*X documentation utility: > > cref | compress | crypt | man > > -------------------------------------------------------------------------------
gringort@wsl.dec.com (Joel Gringorten) (10/27/90)
In article <1990Oct25.160937.28144@edm.uucp>, geoff@edm.uucp (Geoff Coleman) writes: |> Well any O/S who's language of choice for opening and controlling |> devices is FORTRAN (or BLISS) ala VMS has definite drawwbacks. I seem to |> remember that when I wanted to open a tape drive I had to convert the C |> strings into structs with a length component etc. It sounds like what you are recalling is conformance to the VAX-11 calling standard. This standard makes it possible for languages to call routines written any other language. You need not a clue as to what the routine was written in. This is considered a major feature of VMS. |> THe other obvious downfall |> of VMS from my point of view was the need to worry about the inifinite |> combination of file types (fixed length records, fixed block size) Oh, I see. You consider the fact that VMS supports multiple file and record types to be a bug. Some people consider things like ISAM file support built into the runtime library to be a feature. |> fixed block size) versus the |> UNIX philosophy of a file is a file is a file. You must mean the UNIX philosophy of a file is a stream of bytes. Guess what? The C runtime library under VMS supports stream files as the default file type as well as supporting the full complement of standard C lib file routines. To stick with the subject at hand... Fast process creation and pipes are major features of Unix that VMS doesn't have. Disparate existing programs can be linked together via program or shell control. The VMS distributed lock manager is a major feature that Unix doesn't have. Disparate programs can share data to record level without stepping on each others toes. Process creation is heavy. Programs can call other programs, but it's slow and difficult. But hey, they both have their philosophies, disadvantages and advantages. I worked on VMS for 5 years and Unix for last 6 years and have a lot of appreciation for both operating systems. It just so happens that Unix is my OS of choice now. I find prototyping quicker in Unix. It's simpler and more elegant. Being a hacker I like that. VMS is a better operating system for running comercial applications like banks. It has better data, file integrity and security features. It's also a whole lot more user friendly. I'd switch back to VMS if I had to. But, it would take a lot of money :-) -joel
peter@ficc.ferranti.com (Peter da Silva) (10/28/90)
In article <1990Oct26.131224@wsl.dec.com> gringort@wsl.dec.com (Joel Gringorten) writes: > Oh, I see. You consider the fact that VMS supports multiple file and record > types to be a bug. Some people consider things like ISAM file support built > into the runtime library to be a feature. Run-time library, yes. Operating system, no. You should not have to know what format a file is in to do things like search it for text strings. > The C runtime library under VMS supports stream files as the default file type > as well as supporting the full complement of standard C lib file routines. True, but only for files created by the C runtime library. > It's also a whole lot more user friendly. Yep. Everything is an option to "SET". -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
chris@mimsy.umd.edu (Chris Torek) (10/29/90)
>>[VMS is] also a whole lot more user friendly. In article <+SP6XL@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Yep. Everything is an option to "SET". Or `SHOW'. Lessee, now, to get a listing of files, was it `SHOW FILES'? No, wait, `SHOW FILES/DIRECTORY=CURRENT', er, no, `SET LISTING=FILES/CURRENT_DIRECTORY'... :-) (Or, to print a file to the screen, that was `PRINT FOO'? And to type one out on the letter-quality typewriter-device, that was `TYPE FOO'. Yeah, right.) [end scarcasm mode] The one nice thing I remember about VMS was that its `help' facility mostly worked. I did miss the equivalent of `apropos'.... (Mind you, this was VMS 2.3.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
hughes@copper.ucs.indiana.edu (larry hughes) (10/29/90)
In article <1990Oct25.160937.28144@edm.uucp> geoff@edm.uucp (Geoff Coleman) writes: > What do you mean by the guts of VMS and UNIX? If you are talking >system level programming and accessing devices then Unix is a big winner IMHO. >Why you ask? Well any O/S who's language of choice for opening and controlling >devices is FORTRAN (or BLISS) ala VMS has definite drawwbacks. I seem to >remember that when I wanted to open a tape drive I had to convert the C >strings into structs with a length component etc. THe other obvious downfall >of VMS from my point of view was the need to worry about the inifinite >combination of file types (fixed length records, fixed block size) versus the >UNIX philosophy of a file is a file is a file. > This really isn't an argument...where is it stated that the language of choice is FORTRAN or BLISS? This has never been my impression or experience. Also, what does "a file is a file is a file" mean? In Unix, a file is essentially a bytestream; a VMS (RMS actually) text file can be treated this way, and also gives you added benefits (ISAM, etc.) for other file formats. The "downfall" you describe about structs with a length component (they're called string descriptors) is how VMS achieves true language independence. It turns out that this IS awkward when programming in C (particularly because after system service calls you have to null terminate the strings yourself), but this is because most languages do not use null terminated strings, and VMS simply does not favor one language over another (even though DEC is supposedly rewriting most of the kernel in C). For the record, I'm a fan of both VMS and Unix...both have advantages, disadvantages, and their proper place. /=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
lewine@dg-rtp.dg.com (Donald Lewine) (10/30/90)
In article <1990Oct25.160937.28144@edm.uucp>, geoff@edm.uucp (Geoff Coleman) writes: |> Well any O/S who's language of choice for opening and controlling |> devices is FORTRAN (or BLISS) ala VMS has definite drawwbacks. This can also be considered a feature. If you are a C programmer then it is obvious that UNIX is well matched to C. On the other hand if you program in FORTRAN, BASIC, PASCAL, or ADA, then VMS does very well. If you want to build a complex application in a combination of programming languages then VMS is quite good. I will admit the the VMS call-by-descriptor mechanism is poorly supported by VAX C. |> The other obvious downfall |> of VMS from my point of view was the need to worry about the inifinite |> combination of file types (fixed length records, fixed block size) versus the |> UNIX philosophy of a file is a file is a file. Again, one man's bug is another's feature. If I want to print an ISAM file under VMS the print spooler will do it for me. The fact that the system supports many record types means that the appplications programmer does not have to. A C program can read any format as stdin and VMS's Record Management Service (RMS) converts it to new-line delimited strings. In UNIX it is not possible to support anything but flat ASCII files without special code in the application. That is why most UNIX systems have only flat ASCII files. This may be fine for software engineering but it is not what the Data Processing world wants. These are only my humble opinions. I have spent many years writing applications for both VMS and UNIX. I like them both but for different reasons. -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) (10/30/90)
In article <1990Oct25.160937.28144@edm.uucp>, geoff@edm.uucp (Geoff Coleman) writes: > From article <ANDYO.90Oct23101417@glasperl.masscomp>, by andyo@glasperl.masscomp (Andy Oram): >> This group is comp.unix.programmer, after all. Isn't there someone out there >> who can summarize the differences in working with the guts of VMX and UNIX, >> someone who can speak from the experience of porting highly interactive >> applications or writing device drivers or something like that? There must be >> some good general learning experiences here. >> > Sorry I missed the original question so I might be jumping in with both > feet firmly implanted in mouth here. > Likewise, I missed the original question: if the comments below are irrelevant or irritating, please place all responses in a file and copy it to /dev/null or NLA0:, whichever you prefer... Now, ignoring all OS wars and "mine's better than your's" claims, I humbly offer my experience as someone who's worked in both U*x and VMS. The following is very long, so you may want to save it for later. Applications: ------------- 1. Applications written in Unix that use fork, exec, or system will need to be changed and will suffer significant performance degradation under a corresponding VMS implementation. Also, the standard utilities usually invoked by system or exec are not present under VMS, so you may end up having to write your own replacements if there are no similar VMS utilities available. Usually, the VMS libraries provide routines to accomplish what the Unix programmer calls shell routines for, so it requires some modest code changes. This makes VMS programs much more self-contained at the possible expense of re-inventing algorithms (unless you're smart). 2. Files can be tricky for someone familiar with one OS looking at another OS, in either direction. This isn't really a major concern unless you need to communicate files from one OS to the other via FTP or similar transfer program. If so, then you may need to modify the VMS FDL description of the file to "Stream-LF" to get VMS to interpret your file the same way as Unix does. Also beware that binary mode transfers to VMS are likely to pad your file out with nulls until its size is an integral of 512 bytes. To get an FDL description of a file, use "CREATE/FDL filename"; the output filename.FDL file may be edited as described above, and then the file may be updated by the CONVERT/FDL routine as necessary. Since there are lots of parameters here, I won't go too deep, as some experimentation may be necessary. The RMS library (Record Management Services) under VMS provide a program level interface to many different types of files, allowing specific directives and general read/write requests for a file that force the RMS to do all the work like sorting, searching, etc. This generally makes writing database applications easier under VMS since you don't have to parse the file yourself, at the expense of a simple representation that may be interpreted in many ways. A few simple parameters in the VAX C extension of the fopen call allow optimization of file accesses to a particular method, allowing the programmer who knows how the file will be used to increase the speed of his program. 3. Another sometimes surprising element of VMS is that a single file can (and usually does) have multiple versions existing at any one time. This means that opening an existing file for create/write access will cause a new file with an incremented version number to be generated rather than replacing the currently existing file. Therefore, Unix utilities which use temporary files or similar concepts may need to be enhanced to clean up properly after themselves, whereas VMS programmers are likely to be very uncomfortable for a while with no backup of their work. 4. Overall, the C RTL is very similar between Unix and VMS, with the effort for VMS C being to adhere to the C "standard" (chuckle, chuckle :-) and make non-destructive language enhancements where needed. There are some changes, but those are usually documented, and are found by the linker under worst case. As far as the system RTL availability, the VMS has a large and very convenient RTL, which is implemented with a general callable interface that allows ANY supported language under VMS to access the RTL in a generic fashion. Unfortunately, this callable interface uses a "string descriptor" for string representation, which does not coincide with the zero-terminated string representation in C, so some extra effort needs to be made here, but once you do it a time or two, it becomes rote (and macro-able). 5. VMS supports a very large number of third-party terminal devices, so it is not probable that you are going to have problems here. Although VMS C implements curses, I find the native VMS SMG screen management utilities much more pleasing. 6. VMS has a large run-time library available, completely separate from C, which is available to perform a large variety of tasks, including lock management as mentioned by another poster here. This means that you can continue to write your programs with maximum portability in mind, in which case you make very few assumptions about your environment and do almost everything yourself, or you can write a VMS specific utility which is optimized both in speed and size for the VMS environment. Also, since portability is not a large requirement for VMS itself, some of the capabilities (such as screen management mentioned earlier) can take significant advantage of known environmental characteristics. Drivers: -------- Because the OS's are considerably different, driver writing is as well. A driver is, by definition, a three-way bridge between the operating system, a device, and the application program. If you are writing a device driver, there are several significant differences to be aware of. My general impression is that the Unix environment for a driver is much simpler and therefore easier to write to, whereas the VMS environment is more complicated, but provides better tools. 1. VMS has the concept of allocatable virtual memory, which may be obtained by calling system routines; most VMS device drivers use this technique for buffering data, etc. Unix (usually) also has the concept of allocatable virtual memory (implying non-pageable, kernel space), but few Unix drivers actually use this technique. The Unix drivers (that I've seen) usually pre-allocate a large chunk of memory at compile time and use that memory as needed. The problem arises in that, while VMS returns an error indicating when no memory is available, Unix simply "sleeps". This is effectively a suspending of the current process until memory becomes available. Unfortunately, the VMS driver does not depend on process context to execute, which brings us to point 2: 2. In Unix, when an application issues a driver request, the PC is transferred to the appropriate driver routine in kernel and remains there, in execution, until the request completes, at which time the routine exits and the user level code resumes. There is no Unix implementation of "no-wait", "asynchronous", or "background" IO. In VMS, the application issues a driver request. That process is then placed in a wait state after a VMS structure is initialized to describe the request. That structure is then passed through several parts of the device driver in several stages and interrupt levels to accomplish the request. Each intermediary routine is free to do its work and then exit which returns to the OS. When the user's request is finally completed, a specific "wakeup" is issued to the process with an output status. At this point, VMS introduces the "no-wait" IO, where the process is not actually placed in a wait state when its request is issued. The descriptive structure is created and begins its trek through the driver, but the process continues execution. The process can actively poll for completion of the request, or an asynchronous routine may be specified to be activated by the OS when the IO completion "wakeup" is issued. This allows true "no-wait" IO, along with multiple outstanding requests. 3. Everything except interrupt handlers in Unix are written in "user" context, whereas only the preliminary portion of a VMS driver (the FDT routines) are in user context. This means that all buffer validation and copying from the user space must be done from the FDT routines in VMS; copyout of data after the request completes is done by VMS based on addresses and flags in the structure describing the request. This also means that, whereas a Unix driver has a relatively straight- forward code flow, with perhaps a sleep to await later rescheduling, the VMS environment is more versatile at the cost of a much more complex code flow. Care must be taken in a VMS driver not to access user level data and such from most of the driver, whereas a Unix driver must insure user context for kernel memory allocation, sleep requests, and much more. 4. The VMS synchronization is much more specific and explicit, and in some cases much better than Unix synchronization, but that is partially because VMS is specific to Digital machines, whereas Unix is forced to be much more general. 5. With a few considerations, it is possible to re-load a driver into a running VMS system, and it is also possible to boot a VMS system without a driver. This generally means that the debugging turnaround is faster in a VMS environment: VMS: Boot system Unix: Boot system Compile & link driver Compile & link driver Install driver into system Build new system with driver Run test programs Reboot to run system w/driver Hit bug Run test programs Reboot system Hit bug Analyze dump Reboot system Fix, compile and link driver Analyze dump Install driver into system Fix, compile, and link driver Run test programs Build new system w/fixed driver : Reboot with new system Run test programs : where the Unix steps of building a system and rebooting take a significant amount of time as compared to the milliseconds it takes to install/load a VMS driver. Overall, VMS provides a much more versatile environment at the cost of a much more specific and complex driver environment. I've typically taken the approach of using a daemon process in Unix to provide a general process context for a "dispatcher" to emulate the VMS "fork dispatcher" functionality for asynchronous, multiple-event drivers. This is probably a result of my VMS background, and might have been done differently had I started out as a Unix programmer, but means that for most of the driver work I do, I find the VMS environment more convenient and spend some time reproducing elements of that environment in the Unix world. Both environments can be rewarding and fulfilling, but it takes an open mind and a willingness to examine ones algorithms and restructure them as necessary. My impression is that I would much rather be a VMS driver writer learning the looser Unix environment than the Unix driver writer that must climb a large learning curve to get into the VMS environment. If you can do both, then your only problem is switching mental gears about 40 times a day to answer various questions! ;-) If you have specific questions or comments, email me (address below), but no guarantee on turnaround time. -- -- Kevin Quick, Simpact Associates, Inc., San Diego, CA. Internet: simpact!kquick@crash.cts.com
linwood@cbnewsk.att.com (linwood.d.johnson) (10/30/90)
In article <27237@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes: > >>[VMS is] also a whole lot more user friendly. > > In article <+SP6XL@xds13.ferranti.com> peter@ficc.ferranti.com > (Peter da Silva) writes: > >Yep. Everything is an option to "SET". > > Or `SHOW'. Lessee, now, to get a listing of files, was it `SHOW FILES'? > No, wait, `SHOW FILES/DIRECTORY=CURRENT', er, no, `SET > LISTING=FILES/CURRENT_DIRECTORY'... :-) > > (Or, to print a file to the screen, that was `PRINT FOO'? And to type > one out on the letter-quality typewriter-device, that was `TYPE FOO'. > Yeah, right.) > The one nice thing I remember about VMS was that its `help' facility > mostly worked. I did miss the equivalent of `apropos'.... (Mind you, > this was VMS 2.3.) Yeah, all of that stuff is frustrating. But, try to redirect output/input to/from a file. Or send the output from one program to another. Man, you talk about wordiness. $ ASSIGN FOO.OUT SYS$OUTPUT $ ASSIGN SYS$INPUT FOO.INPUT But, VMS has a great debugger. The greatest debugger that I've ever used. Other than the debuggers that I've used on the PC. +===================================================================+ | Linwood D. Johnson | linwood@ihlpf.att.com | +-------------------------------------------------------------------+ | Disclaimer: Opinions expressed here are mine and mine only. | | Besides, who else would want them? | +===================================================================+ -- +===================================================================+ | Linwood D. Johnson | linwood@ihlpf.att.com | +-------------------------------------------------------------------+ | Disclaimer: Opinions expressed here are mine and mine only. |
linwood@cbnewsk.att.com (linwood.d.johnson) (10/30/90)
In article <1990Oct30.021328.13001@cbnewsk.att.com>, linwood@cbnewsk.att.com (linwood.d.johnson) writes: > In article <27237@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes: > > >>[VMS is] also a whole lot more user friendly. > > > > In article <+SP6XL@xds13.ferranti.com> peter@ficc.ferranti.com > > (Peter da Silva) writes: > > >Yep. Everything is an option to "SET". > > > > Or `SHOW'. Lessee, now, to get a listing of files, was it `SHOW FILES'? > > No, wait, `SHOW FILES/DIRECTORY=CURRENT', er, no, `SET > > LISTING=FILES/CURRENT_DIRECTORY'... :-) > > > > (Or, to print a file to the screen, that was `PRINT FOO'? And to type > > one out on the letter-quality typewriter-device, that was `TYPE FOO'. > > Yeah, right.) > > The one nice thing I remember about VMS was that its `help' facility > > mostly worked. I did miss the equivalent of `apropos'.... (Mind you, > > this was VMS 2.3.) > > Yeah, all of that stuff is frustrating. But, try to redirect > output/input to/from a file. Or send the output from one program to > another. Man, you talk about wordiness. > $ ASSIGN FOO.OUT SYS$OUTPUT > $ ASSIGN SYS$INPUT FOO.INPUT > > > But, VMS has a great debugger. The greatest debugger that I've ever used. > Other than the debuggers that I've used on the PC. Oh yeah. VMS has some great editors also. I used to love using the TPU mode of ed. We used to call it EVE (Extensible Vax Editor). It was great. You could define all of the functions of the keyboard to be something; like whatever you wanted it to be. I found the editors in the world of UNIX to be somewhat hostile when compared to EVE. +===================================================================+ | Linwood D. Johnson | linwood@ihlpf.att.com | +-------------------------------------------------------------------+ | Disclaimer: Opinions expressed here are mine and mine only. | | Besides, who else would want them? | +===================================================================+ -- +===================================================================+ | Linwood D. Johnson | linwood@ihlpf.att.com | +-------------------------------------------------------------------+ | Disclaimer: Opinions expressed here are mine and mine only. |
smb@cs.purdue.EDU (Scott M. Ballew) (10/30/90)
In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes: >4. Overall, the C RTL is very similar between Unix and VMS, with the effort > for VMS C being to adhere to the C "standard" (chuckle, chuckle :-) and > make non-destructive language enhancements where needed. There are some > changes, but those are usually documented, and are found by the linker > under worst case. If my memory serves me correctly, the VAX C compiler is identical for VMS and Ultrix (DEC's Unix). It was originally written for the Ultrix world and then retro-fitted to the VMS world. Similarly, VAX Fortran was originally written for the VMS world and then retro-fitted to the Ultrix world. >5. VMS supports a very large number of third-party terminal devices, so > it is not probable that you are going to have problems here. Although > VMS C implements curses, I find the native VMS SMG screen management > utilities much more pleasing. While this is true, the most frustrating "feature" of VMS if ran into in my VMS days was trying to get the VAX editors (EDT, EVE) to actually talk to these third-party terminals. I did the whole bit of describing to VMS (via there termcap-like method) what our terminals sent and expected only to find that for reasons of speed and efficiency, EDT (and perhaps EVE, I don't remember) did NOT use the SMG routines so would still not talk to our terminals correctly. In contrast, I have not yet run into a Unix program that did not use either the termcap library or curses (which uses the termcap library). >4. The VMS synchronization is much more specific and explicit, and in > some cases much better than Unix synchronization, but that is partially > because VMS is specific to Digital machines, whereas Unix is forced > to be much more general. Actually, since Unix was originally designed for DEC machines, this is not a valid statement. The difference really lies in the philosophy underlying the systems' designs. See Bach's book on the design of Unix for a discussion. Having worked under both systems, I agree that each has its relative strengths and weaknesses. However, being a bit of a hacker at heart, I prefer a system where the operating system gets in my way as little as possible, allowing me to get my work done. Unix, because of its research origins, does just that (though at times, it STILL gets in my way). VMS, on the other hand, is a much friendlier environment for the user who is not a programmer. It has a (fairly) regular set of options to (rather) intuitive command names. If the user does not wish to do anything that requires programming, it is a comfortable, secure enviroment. Unix is, however, far more customizable and extensible, in my opinion, than VMS and so, I have found it a much more comfortable environment in which to work. By the way, no one has mentioned Unix's biggest strength: since most implementations can be obtained with complete sources on line, it is realitively easy to repair bugs in or add features to any part of the system, something that VMS makes nearly impossible. Scott Ballew Cypress Network Operations Center Purdue University Department of Computer Sciences
terryl@sail.LABS.TEK.COM (10/31/90)
In article <1990Oct30.035412.15523@cbnewsk.att.com> linwood@cbnewsk.att.com (linwood.d.johnson) writes: > Oh yeah. VMS has some great editors also. I used to love using > the TPU mode of ed. We used to call it EVE (Extensible Vax > Editor). It was great. You could define all of the > functions of the keyboard to be something; like whatever you > wanted it to be. I found the editors in the world of UNIX to > be somewhat hostile when compared to EVE. Yeah, a stupid (And I do mean STUPID) standard editor that forces one to have line numbers while one is editing a file, and have said line numbers stay static even if one is adding/deleting lines, and those line added MUST not be out of the range of line numbers one is adding between, and having such stupid default line numbers such that one could add at MOST one line between two lines, and then forcibly going back into command mode (instead of input line mode), and forcing the user to MANUALLY renumber all of the lines in the d*mn file??? You call that a great editor??? Boy, I thought I had a warped view of the world..... (To be fair, this was MANY, MANY moons ago on a VMS 1.6 system, if memory serves me correctly, but gads how I hated EDIT!!! Luckily, it was somewhat easy to change all of the default numbering schemes, but there was ABSOLUTELY no way to defeat the line numbering scheme while in the editor, and every so often you would find yourself forcibly thrown out of line input mode back into command mode, where the only thing you could really do is a command to cause all of the lines in the file to be renumbered....)
terryl@sail.LABS.TEK.COM (10/31/90)
In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes:
+Drivers:
+--------
+
+Because the OS's are considerably different, driver writing is as well. A
+driver is, by definition, a three-way bridge between the operating system,
+a device, and the application program. If you are writing a device driver,
+there are several significant differences to be aware of. My general
+impression is that the Unix environment for a driver is much simpler and
+therefore easier to write to, whereas the VMS environment is more
+complicated, but provides better tools.
+
+1. VMS has the concept of allocatable virtual memory, which may be obtained
+ by calling system routines; most VMS device drivers use this technique
+ for buffering data, etc.
+
+ Unix (usually) also has the concept of allocatable virtual memory (implying
+ non-pageable, kernel space), but few Unix drivers actually use this
+ technique. The Unix drivers (that I've seen) usually pre-allocate a large
+ chunk of memory at compile time and use that memory as needed.
+
+ The problem arises in that, while VMS returns an error indicating when
+ no memory is available, Unix simply "sleeps". This is effectively a
+ suspending of the current process until memory becomes available.
+ Unfortunately, the VMS driver does not depend on process context to
+ execute, which brings us to point 2:
+
+2. In Unix, when an application issues a driver request, the PC is transferred
+ to the appropriate driver routine in kernel and remains there, in execution,
+ until the request completes, at which time the routine exits and the user
+ level code resumes. There is no Unix implementation of "no-wait",
+ "asynchronous", or "background" IO.
+
+ In VMS, the application issues a driver request. That process is then
+ placed in a wait state after a VMS structure is initialized to describe
+ the request. That structure is then passed through several parts of the
+ device driver in several stages and interrupt levels to accomplish the
+ request. Each intermediary routine is free to do its work and then exit
+ which returns to the OS. When the user's request is finally completed,
+ a specific "wakeup" is issued to the process with an output status.
Actually, no, the Unix driver does NOT "remain in execution" in the driver
until the request completes. For disk drivers, as an example, what happens is
that a request for a transfer is queued, and then the higher level OS code
will wait for the transfer to complete, thus giving up the processor to another
process so it may run. While it is true that some device drivers may do a busy
wait, waiting for some command to complete while in the driver, these are usu-
ally commands that are known to complete in a very short amount of time, but
they are usually the exeception, and not the rule (like clearing error condi-
tions).
As for the "no-wait", "asynchronous", or "background" IO, at the user
level, yes, that is true, but at the kernel level, it is possible to do this.
+3. Everything except interrupt handlers in Unix are written in "user"
+ context, whereas only the preliminary portion of a VMS driver (the
+ FDT routines) are in user context.
+
+ This means that all buffer validation and copying from the user space
+ must be done from the FDT routines in VMS; copyout of data after the
+ request completes is done by VMS based on addresses and flags in the
+ structure describing the request.
+
+ This also means that, whereas a Unix driver has a relatively straight-
+ forward code flow, with perhaps a sleep to await later rescheduling,
+ the VMS environment is more versatile at the cost of a much more
+ complex code flow.
+
+ Care must be taken in a VMS driver not to access user level data and
+ such from most of the driver, whereas a Unix driver must insure user
+ context for kernel memory allocation, sleep requests, and much more.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'm a little confused here on what you call "user" context. To me, a
"user" context consists of a transfer direction (eg a read or a write), a
transfer count, a starting block number, and a buffer address (to use my
previous disk analogy). That's it; nothing more, nothing less. Also, your
comment about Unix "must insure user context for kernel memory allocation,
sleep requests, and much more" is a little cryptic. All the driver has to
do is validate the user's buffer address, and that the transfer is valid
with respect to the disk geometry. Now Unix does provide both direct-from-
user-space I/O, and also from the internal kernel buffers into the user-
provided buffer address, but I'm still not sure what you mean by the above
quoted remarks. For transfers into/out of the internal kernel buffers men-
tioned above, the user context doesn't even come into play. It is taken care
of at a higher level. For transfers directly into/out of the user's buffer
address, again, most of that is taken care of at a higher level. By the time
it gets down to the driver level, all the driver sees is a transfer direction,
a transfer count, a starting block, and a buffer address. As far as the driver
is concerned, there isn't much of a distinction between a kernel buffer address
and a user buffer address.kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) (10/31/90)
In article <12234@medusa.cs.purdue.edu>, smb@cs.purdue.EDU (Scott M. Ballew) writes: > In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes: > >>4. The VMS synchronization is much more specific and explicit, and in >> some cases much better than Unix synchronization, but that is partially >> because VMS is specific to Digital machines, whereas Unix is forced >> to be much more general. > > Actually, since Unix was originally designed for DEC machines, this is > not a valid statement. The difference really lies in the philosophy > underlying the systems' designs. See Bach's book on the design of > Unix for a discussion. > > Scott Ballew > Cypress Network Operations Center > Purdue University Department of Computer Sciences I would agree with the position of Mr. Ballew's statement with regards to the origins of the Unix OS, but later developments in computer hardware have caused a divergence between Unix and VMS; Unix, while initially developed in a DEC environment, attempts to maintain a portability focus as much as possible, and therefore the synchronization mechanisms are limited to that subset that exists most broadly throughout the many architectures that today support the Unix environment. VMS, on the other hand, has been free to use and "feature" all of the hardware developments available in the DEC environment because it is not required to be portable outside that environment. VMS implements 32 discrete interrupt priority levels with OS tasks being specifically performed at the various levels; the recent addition of multiple CPUs in the SMP environment overlay a ranked spinlock structure onto this interrupt scheme to provide inter-cpu synchronization as well as intra-cpu syncronization. Unix provides 8 interrupt levels, accessed via standard spl routines which may or may not provide that many discrete interrupt lockout levels as determined by the underlying hardware. There are various spinlock additions to support SMP environments, although my limited experience with these indicates that they are not as complex (well developed?) as the VMS counterparts. Anyhow, I digress in defense of my original statement, and perhaps this topic is becoming more apropo to the comp.unix.internals newsgroup. -- -- Kevin Quick, Simpact Associates, Inc., San Diego, CA. Internet: simpact!kquick@crash.cts.com
peter@ficc.ferranti.com (Peter da Silva) (10/31/90)
In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes: > 4. Overall, the C RTL is very similar between Unix and VMS, with the effort > for VMS C being to adhere to the C "standard" (chuckle, chuckle :-) and > make non-destructive language enhancements where needed. Well, they made some arbitrary language "enhancements" as well, that didn't need to be done. For example, "#include stdio" instead of "#include <stdio.h>". Now you can keep on #including <stdio.h> instead of stdio, but it's quicker the other way... even though they're semantically identical. Arbitrary. > As far as the system RTL availability, the VMS has a large and very > convenient RTL, which is implemented with a general callable interface The number of features in the standard VMS library are nice. The interface to them from C has an un-necessary amount of suckiness, but the features themselves are handy. It also comes with a number of VM features that are very useful, equivalent to mmap() on SunOS. > 5. VMS supports a very large number of third-party terminal devices, so > it is not probable that you are going to have problems here. It's virtually certain that you will not be able to use non DEC-compatible terminals. It comes with a terminfo clone, but none of the editors support it. Dumb. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
emcguire@ccad.uiowa.edu (Ed McGuire) (10/31/90)
In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes: > VMS is specific to Digital machines, whereas Unix is forced to be much > more general. In article <12234@medusa.cs.purdue.edu> smb@tristram.cs.purdue.edu (Scott M Ballew) writes: > Actually, since Unix was originally designed for DEC machines, this is > not a valid statement. The difference really lies in the philosophy > underlying the systems' designs. This is pretty misleading. UNIX was originally developed for the PDP-7, not the VAX-11. These are a very different. UNIX was later ported to the PDP-11, and to the VAX-11 when it was released. More recently, it was ported to MIPS (the heart of the DECstation: not a Digital chip though). All these machines have different CPU architectures. VMS was designed for and around the VAX-11. Both claims are essentially correct: VMS is specific to and optimized for the VAX architecture, but probably could not be ported to anything else. UNIX was designed to be ported easily to another CPU, but cannot take advantage of all strengths of the architecture. And these differences are clearly reflections of different design philosophies. Though take a look at the modern PDP-11 sometime. RSTS/E provides a significant subset of the "look and feel" of VMS on a PDP-11. Hats off to those guys. -- peace. -- Ed "Just under half the DEC vice presidents who report to Senior VP Jack Smith are named Bill." -- Digital Review/October 22, 1990
linwood@cbnewsk.att.com (linwood.d.johnson) (10/31/90)
In article <8354@tekgvs.LABS.TEK.COM>, terryl@sail.LABS.TEK.COM writes: > > Oh yeah. VMS has some great editors also. [the rest deleted for the sake of brevity] [but the rest repeated to make a point] > > > Yeah, a stupid (And I do mean STUPID) standard editor that forces one > to have line numbers while one is editing a file, and have said line numbers > stay static even if one is adding/deleting lines, and those line added MUST > not be out of the range of line numbers one is adding between, and having > such stupid default line numbers such that one could add at MOST one line > between two lines, and then forcibly going back into command mode (instead > of input line mode), and forcing the user to MANUALLY renumber all of the lines > in the d*mn file??? You call that a great editor??? Boy, I thought I had a > warped view of the world..... > > (To be fair, this was MANY, MANY moons ago on a VMS 1.6 system, if memory > serves me correctly, but gads how I hated EDIT!!! Luckily, it was somewhat > easy to change all of the default numbering schemes, but there was ABSOLUTELY > no way to defeat the line numbering scheme while in the editor, and every so > often you would find yourself forcibly thrown out of line input mode back into > command mode, where the only thing you could really do is a command to cause > all of the lines in the file to be renumbered....) Boy, I'm glad you were fair about it!!! Damn, I always wondered what VMS was like in the STONE AGE. I was talikng about a later, much later version than 1.6. Like, somewhere close to the present. Maybe one should look at the present before hollering about how hard it was in the past. -- +===================================================================+ | Linwood D. Johnson | linwood@ihlpf.att.com | +-------------------------------------------------------------------+ | Disclaimer: Opinions expressed here are mine and mine only. |
theune@aplcen.apl.jhu.edu (Peter Theune) (10/31/90)
terryl@sail.LABS.TEK.COM writes: Stuff deleted.... Whining about Vax EDIT deleted... > (To be fair, this was MANY, MANY moons ago on a VMS 1.6 system, if memory ^^^^^^^^^^^^^^ Come on , give us a break, VMS 1.6 was updated in 1979. Want to discuss some of the early versions on u*ix ? If you are going to compare, at least talk about reasonably current versions.. sheesh. There is a place for both, neither is "better". Peter Theune ( a VMS hacker & U*ix wannabe) (I'm working on it.)
kehoe@scotty.dccs.upenn.edu (Brendan Kehoe) (10/31/90)
In <1990Oct31.011215.23303@cbnewsk.att.com>, linwood@cbnewsk.att.com writes: > Boy, > I'm glad you were fair about it!!! Damn, I always wondered what VMS >was like in the STONE AGE. I was talikng about a later, much later >version than 1.6. Like, somewhere close to the present. Maybe one >should look at the present before hollering about how hard it was in the >past. I have to agree with terry about the line editing -- even in 5.4. It SUCKS. (And it's exactly how he described it .. do set term/dev=unknown and try doing edit foo.bar). TPU is still great though -- I've learned to love Emacs, though TPU still has a really good feel to it. Brendan Kehoe | Soon: brendan@cs.widener.edu [ Well, in 1990 I hope. ] For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu "It's a distinctly non-trivial task to decompile a stripped, encrypted binary into something that can be understood." - Keith Bostic, on the Internet worm
darcy@druid.uucp (D'Arcy J.M. Cain) (10/31/90)
In article <1089@dg.dg.com> uunet!dg!lewine writes: > [...] > In UNIX it is not possible to support anything but flat ASCII > files without special code in the application. That is why > most UNIX systems have only flat ASCII files. This may be fine > for software engineering but it is not what the Data Processing > world wants. > I can't speak for everyone who programs in Unix but in my case I started programming using fixed length records in C. By that I mean to get record 'rec_num' I would do something like this: #define ASSUME_APPROPRIATE_ERROR_CHECKING typedef { int something; char something_else[32]; ... } S_TYPE; S_TYPE s_buf; ... fseek(fp, rec_num * sizeof(S_TYPE), SEEK_SET); fread(s_buf, sizeof(S_TYPE), 1, fp); This worked very well. It was quick and relatively simple to program. As I moved to Unix however I started to move away from this model and started using the flat ASCII line delimited model. The reason for this was data portability. Sed, awk, grep etc. can now work on my files. It is no longer necessary for every program that works on a data file to know the internals of the program that created it. I guess what I am saying is that you may have the cart before the horse here. Unix programmers like the flat ASCII model because the nature of the file system promotes this sort of data sharing. If somehow files could only be read by programs written specifically for them I think you would see much different, and perhaps more efficient, ways of storing data under Unix. >These are only my humble opinions. Me too. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
cs@cci632.UUCP (Craig Schmackpfeffer) (10/31/90)
Enough already! This request for information has degenerated into a name-calling waste of bandwidth. I vote we redirect this chatter to alt.your.os.sucks. Editor preferences are just that -- preferences. If the people who are going to work on the project in question come from a VMS background, then it would probably serve them best to stay with what they know for a major project. They can play with other operating systems on small projects. I have found it is NOT intuitive to move directly from one to the other. Craig = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Me: Craig Schmackpfeffer (another damn yankee) Disclaimer: Disclaim'er? I don't even know her! Address: ccird1!cs@cci632.UUCP Go Bills! = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) (11/01/90)
Note: I apologize for leaving large portions of the previous messages in this text, but I felt that they were needed to form the context for my replies. In article <8355@tekgvs.LABS.TEK.COM>, terryl@sail.LABS.TEK.COM writes: > In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes: > +Drivers: > +-------- > + > +Because the OS's are considerably different, driver writing is as well. A > +driver is, by definition, a three-way bridge between the operating system, > +a device, and the application program. If you are writing a device driver, > +there are several significant differences to be aware of. My general > +impression is that the Unix environment for a driver is much simpler and > +therefore easier to write to, whereas the VMS environment is more > +complicated, but provides better tools. > + > +1. VMS has the concept of allocatable virtual memory, which may be obtained > + by calling system routines; most VMS device drivers use this technique > + for buffering data, etc. > + > + Unix (usually) also has the concept of allocatable virtual memory (implying > + non-pageable, kernel space), but few Unix drivers actually use this > + technique. The Unix drivers (that I've seen) usually pre-allocate a large > + chunk of memory at compile time and use that memory as needed. > + > + The problem arises in that, while VMS returns an error indicating when > + no memory is available, Unix simply "sleeps". This is effectively a > + suspending of the current process until memory becomes available. > + Unfortunately, the VMS driver does not depend on process context to > + execute, which brings us to point 2: > + > +2. In Unix, when an application issues a driver request, the PC is transferred > + to the appropriate driver routine in kernel and remains there, in execution, > + until the request completes, at which time the routine exits and the user > + level code resumes. There is no Unix implementation of "no-wait", > + "asynchronous", or "background" IO. > + > + In VMS, the application issues a driver request. That process is then > + placed in a wait state after a VMS structure is initialized to describe > + the request. That structure is then passed through several parts of the > + device driver in several stages and interrupt levels to accomplish the > + request. Each intermediary routine is free to do its work and then exit > + which returns to the OS. When the user's request is finally completed, > + a specific "wakeup" is issued to the process with an output status. > > Actually, no, the Unix driver does NOT "remain in execution" in the driver > until the request completes. For disk drivers, as an example, what happens is > that a request for a transfer is queued, and then the higher level OS code > will wait for the transfer to complete, thus giving up the processor to another > process so it may run. While it is true that some device drivers may do a busy > wait, waiting for some command to complete while in the driver, these are usu- > ally commands that are known to complete in a very short amount of time, but > they are usually the exeception, and not the rule (like clearing error condi- > tions). > > As for the "no-wait", "asynchronous", or "background" IO, at the user > level, yes, that is true, but at the kernel level, it is possible to do this. > Actually, I should have clarified my point a little better. I did not intend to imply that the *host processer* continues to execute the driver code for that request until the request completes, but that the *process's code thread* does so. This means that, as Terry stated, the process makes a request, the driver pre-processes that request, the driver signals the device, and then the driver tells Unix to suspend the current process and go handle someone else until the device interrupt routine issues a wakeup, at which time the requesting process is restarted from its suspended state and continues at the next instruction to do post-processing and exit. The difference between this scheme and VMS is that under Unix, the driver routine must be very careful not to exit via a return statement until the I/O request has been completely handled; if it needs to wait for the device then it issues the "sleep" request to suspend the current process until the device interrupts and restarts this process. Under VMS, the OS automatically suspends the process (assuming wait I/O) after the descriptive structure is generated. When driver code needs to wait for something, it tells VMS where to resume when the event occurs and then simply exits -- back to the VMS OS. When the specified event occurs, the specified routines are activated to resume processing the I/O; the user process is not restarted until a driver routine explicitly tells VMS that the I/O has been completed. > +3. Everything except interrupt handlers in Unix are written in "user" > + context, whereas only the preliminary portion of a VMS driver (the > + FDT routines) are in user context. > + > + This means that all buffer validation and copying from the user space > + must be done from the FDT routines in VMS; copyout of data after the > + request completes is done by VMS based on addresses and flags in the > + structure describing the request. > + > + This also means that, whereas a Unix driver has a relatively straight- > + forward code flow, with perhaps a sleep to await later rescheduling, > + the VMS environment is more versatile at the cost of a much more > + complex code flow. > + > + Care must be taken in a VMS driver not to access user level data and > + such from most of the driver, whereas a Unix driver must insure user > + context for kernel memory allocation, sleep requests, and much more. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I'm a little confused here on what you call "user" context. To me, a > "user" context consists of a transfer direction (eg a read or a write), a > transfer count, a starting block number, and a buffer address (to use my > previous disk analogy). That's it; nothing more, nothing less. Also, your > comment about Unix "must insure user context for kernel memory allocation, > sleep requests, and much more" is a little cryptic. All the driver has to > do is validate the user's buffer address, and that the transfer is valid > with respect to the disk geometry. Now Unix does provide both direct-from- > user-space I/O, and also from the internal kernel buffers into the user- > provided buffer address, but I'm still not sure what you mean by the above > quoted remarks. For transfers into/out of the internal kernel buffers men- > tioned above, the user context doesn't even come into play. It is taken care > of at a higher level. For transfers directly into/out of the user's buffer > address, again, most of that is taken care of at a higher level. By the time > it gets down to the driver level, all the driver sees is a transfer direction, > a transfer count, a starting block, and a buffer address. As far as the driver > is concerned, there isn't much of a distinction between a kernel buffer address > and a user buffer address. More clarification: "User" context, as I've used it, is intended to mean that you are not executing on the interrupt stack, and that the user process that made the I/O request is the "current" process as far as the scheduler (and the pager, etc.) are concerned. The better Unix driver documentation will warn you not to use the kernel memory allocation routines from interrupt level, since these routines usually "sleep" the current process if no memory is available at that time; when you are in interrupt context, who knows what process is currently scheduled that you may be suspending with this sleep function, or better yet, you're interrupt level is above that of the scheduler, so your sleep hangs the system because it can't pass control to the scheduler to activate the next process in the run queue! Also, and for similar reasons, you should never be copying data to or from the user's memory region at interrupt level (unless you have previously, in user context, locked that memory into the physical working set, and are accessing that physical location in your interrupt routine) since you don't know what process is current, and what that process is keeping in that memory location. The reason I have compared this to VMS, is that all parts of a VMS driver except the FDT routines may be considered to be in "interrupt context", since they have been asynchronously scheduled independent of what the current process on the system is, and therefore may not access "user" space or other user data structures. All of the above is doubly important when writing an asynchronous multiplexed driver which can handle multiple user requests simultaneously; one user's request may need to wait for some event, but unless you use "sleep" for this scheduling, how can you tell which user context that code is in after the event has occurred? -- -- Kevin Quick, Simpact Associates, Inc., San Diego, CA. Internet: simpact!kquick@crash.cts.com
rhl@astro.Princeton.EDU (Robert Lupton (the Good)) (11/01/90)
Before you all move over to VMS, happy in the knowledge that it supports stream linefeed (unix-style) files, beware that the C rtl implementation of read/write/open/close that works with them is glacially slow. Too slow to be used (at least for the sort of image processing that I was doing). I'm supposed to say that this is my humble opinion, which it is. But my hatred of the VaxMonSter isn't just an opinion, it's the way I am. Sorry. Robert
pena@fuug.fi (Olli-Matti Penttinen) (11/01/90)
In article <3749@idunno.Princeton.EDU> rhl@astro.Princeton.EDU (Robert Lupton (the Good)) writes: >Before you all move over to VMS, happy in the knowledge that it supports >stream linefeed (unix-style) files, beware that the C rtl implementation >of read/write/open/close that works with them is glacially slow. Too slow >to be used (at least for the sort of image processing that I was doing). The best thing about RMS is it's ability to support DBMS's which generally run circles 'round a similar one under Ultrix/BSD. Besides, it's a little bit simpler to implement a database using a filesystem w/ built in ISAM instead of opening a Unix partition and seeking here and there. The worst thing is that (at least under VMS 4.x) you really had to know the exact file type of a *TEXT FILE* to be able to do anything usefull with it. For example: you could not fseek into the middle of a line (i.e. record) of a variable-lenght-record file, or whatchamacallit, which happens to be the default for all FORTRAN and EDIT output. You had to convert it to stream type before processing. One other point: when was the last you looked at the source of MicroEmacs? I'm not saying that it's optimally (or even sensibly) coded for each OS, but it sure strikes odd to find all that VMS only code in it. MicroEmacs 3.10: ibmpc.c: 11928 bytes os2.c: 11389 bytes unix.c: 14470 bytes vms.c: 32526 bytes Unfortunately (for VMS), there even are missing features ... ==pena -- Olli-Matti Penttinen <pena@fuug.innopoli.fi> Brainware Oy "When in doubt, use brute force." Tekniikantie 17 --Ken Thompson 02150 ESPOO, Finland Tel. +358 0 4375 320 Fax. +358 0 4553 117
peter@ficc.ferranti.com (Peter da Silva) (11/02/90)
Yes, the classic UNIX kernel model is rather freaky. It does have the virtue of being simple to implement, but it's not a very friendly place for deiver writing. *BUT* UNIX is not defined by the UNIX kernel model. It is defined by the user and programmer interfaces (the UNIX programmer's manual, SVID, POSIX, what have you). You can have whatever kernel you want and if I can compile "make" and it runs it's UNIX. And that's the most important advantage UNIX has over other operating systems. It's not the portability that's important so much as the relatively high level of the programmer interface. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
sweh@tharr.UUCP (Stephen Harris) (11/02/90)
How in VMS do you have filters and pipelines?
eg, what would be the VMS (DCL?) equivalent of
getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file
Is there an equivalent, or would it need a lot of temporary files?
--
Stephen Harris
Disclaimer: me have an opinion? | Email: ..!ukc!axion!tharr!sweh
What an idea! | sweh%tharr.uucp@uk.co.bt.axion
Wanted: humour transplant | tharr!sweh@uk.ac.ukc
<-- tharr *free* public access to Usenet in the UK 0234 261804 -->hughes@copper.ucs.indiana.edu (larry hughes) (11/05/90)
In article <1380@tharr.UUCP> sweh@tharr.UUCP (Stephen Harris) writes: >How in VMS do you have filters and pipelines? >eg, what would be the VMS (DCL?) equivalent of > getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file > >Is there an equivalent, or would it need a lot of temporary files? Yes, you would need a lot of temporary files. The output of each step would have to redirected to a file (ala $ DEFINE/USER SYS$OUTPUT filename) and then the temp file would have to be redirected as input to the next step (ala $ DEFINE/USER SYS$INPUT filename). And, don't forget to delete the temp files! (Yes, this is slightly worse that the way that MS-DOS does it...at least DOS makes the temp file usage transparent.) //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (11/06/90)
In article <69986@iuvax.cs.indiana.edu> hughes@copper.ucs.indiana.edu (larry hughes) writes: >In article <1380@tharr.UUCP> sweh@tharr.UUCP (Stephen Harris) writes: >>How in VMS do you have filters and pipelines? >>eg, what would be the VMS (DCL?) equivalent of >> getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file >> >>Is there an equivalent, or would it need a lot of temporary files? > >Yes, you would need a lot of temporary files. Would a POSIX-compliant VMS fix this? --Blair "You know what comes next."
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (11/06/90)
In article <803@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >Would a POSIX-compliant VMS fix this? ------------------- Uhm, Blair...could VMS be hacked up into POSIX compliance? If so, then it's a looser standard than it should be... -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "With design like this, who needs bugs?" - Boyd Roberts
hughes@copper.ucs.indiana.edu (larry hughes) (11/06/90)
In article <4283@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: >In article <803@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >>Would a POSIX-compliant VMS fix this? > ------------------- >Uhm, Blair...could VMS be hacked up into POSIX compliance? If so, then it's >a looser standard than it should be... VMS is scheduled for POSIX-compliance (though I cannot remember the timeframes). It's called VIP (VMS Integrated POSIX). To answer the first question, a POSIX-complaint VMS would not fix this, to my understanding. POSIX defines the calling standard (interface) to the operating system. However, I don't have a deep understanding of this, so don't take my word for it. Any POSIX gurus out there that can give a brief comment? //=========================================================================\\ || Larry J. Hughes, Jr. || hughes@ucs.indiana.edu || || Indiana University || || || University Computing Services || "The person who knows everything || || 750 N. State Road 46 Bypass || has a lot to learn." || || Bloomington, IN 47405 || || || (812) 855-9255 || Disclaimer: Same as my quote... || \\==========================================================================//
rja7m@chaos.cs.Virginia.EDU (Ran Atkinson) (11/06/90)
In article <803@inews.intel.com>, bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >>Would a POSIX-compliant VMS fix this? In article <4283@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: > Uhm, Blair...could VMS be hacked up into POSIX compliance? > If so, then it's a looser standard than it should be... DEC have publically stated that they intend to make VMS a POSIX compliant system eventually. There participation in the various POSIX committees bears this out. BTW, I agree with Jay that the POSIX standard is looser than it should be -- especially in the Shell & Tools area. The fact that DEC plans a POSIX compliant VMS without a major overhaul is an excellent existence proof that the standard is too loose. Followups to alt.religion or comp.std.unix as appropriate...
emery@linus.mitre.org (David Emery) (11/06/90)
There are two parts of POSIX you'd need to do
>> getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file
First, you need the pipe facilities provided by P1003.1. No problem,
that will have to be in the VIP release.
The second thing you need is the shell. I'm not a P1003.2 shell
expert, but I don't see why this isn't a legal POSIX shell command.
The question is: will VIP come with a P1003.2-conformant shell? If
so, then this should work just fine...
dave emery
emery@aries.mitre.orgmjr@hussar.dco.dec.com (Marcus J. Ranum) (11/06/90)
In article <EMERY.90Nov5145850@aries.linus.mitre.org> emery@linus.mitre.org (David Emery) writes: >[...] will VIP come with a P1003.2-conformant shell? I'd expect that's "by definition". I don't know how it'll be done, though - starting up processes on VMS is more expensive than UNIX - long pipelines will probably not be a great deal of fun. It'll be nice to finally be able to pass parameters to a program in a reasonable manner... (unless P1003.2 has enough holes in it that you get hit with "CAT /VERBOSE=TRUE/PACK=WHITSPACE/INPUT=FILE.TXT") mjr. -- "I defy anyone to trick me. Men would have to be exceptional rascals to be as bad as I assume them to be." - Emperor Napoleon I [conversation, 1816]
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (11/06/90)
I told you you knew what was coming! :-) In article <1990Nov5.191934.19739@murdoch.acc.Virginia.EDU> Ran Atkinson <randall@Virginia.EDU> writes: >BTW, I agree with Jay that the POSIX standard is looser than it >should be -- especially in the Shell & Tools area. The fact >that DEC plans a POSIX compliant VMS without a major overhaul >is an excellent existence proof that the standard is too loose. Did they say it wasn't a major overhaul? EE Times article on page 1 ("Digital to take RISC/Unix road", Oct. 29, '90) (the title isn't actually descriptive; DEC's still clinging to this dead baby (i.e., VMS) and hoping someone will want to buy it; they claim tens thousand of applications (most of them of course options to SET :-)) nd half a million installed systems) indicates little about the actual effort. DEC may have 20,000 or 2 people working on it, for all anyone knows. They call it an "open VMS". What's that mean? Beats me. The time-frame is apparently _next_quarter_ (that's BEFORE April of 1991, kids) for POSIX.1, .2, and .3 compliance. The rest of it is supposed to be out by "mid-1991." As to whether it will handle pipes, I dare say it should! But there I dare pretty far, not having read the system-services section of POSIX (or any other section, for that matter), but would it be Unix without pipes? Heck, no! --Blair "THIS, I gotta SEE!" P.S. to Randall: leave the cute 'Followup-to:' crap in alt.flame. Some of us are serious about this discussion.
rang@cs.wisc.edu (Anton Rang) (11/06/90)
In article <PENA.90Nov1164830@fuug.fi> pena@fuug.fi (Olli-Matti Penttinen) writes: > The worst thing is that (at least under VMS 4.x) you really had to >know the exact file type of a *TEXT FILE* to be able to do anything >useful with it. This is an argument which comes up fairly often. It's only partly true. The C I/O model (a file is a stream of bytes) works well for an awful lot of applications. The problem is that if you have a more complex file structure, mapping it into the stream-of-bytes framework in a way that makes sense is difficult. The way that most languages under VMS do their I/O is by using the high-level RMS calls. You can $OPEN a file, and then read through it, one record at a time, using $GET. This will let you sequentially scan through file with a record structure--whether it's a variable-length record file, a stream file, a 'relative' (numbered-record) file, or an ISAM file. You can use $PUT and/or $UPDATE to change files, one record at a time. It's difficult to map this directly into a read/write/fseek model, except with stream files (which are basically identical to UNIX text files). For instance, each record in a (sequential) variable-length record file has a two-byte length field, and may include a byte of padding. If you want to treet fseek() as taking an offset which is a character count, in this file type, you don't know where to position the 'file pointer' without scanning from the start of the file. (That's why it's a "sequential file"--it's designed for sequential access, and shouldn't be used [under VMS] for random access.) An ISAM file type is even worse...if you have records with keys of 'abc', 'def', and 'ghi', they may have that logical order, but be stored physically in a different order, different parts of the record may be in different areas of the disk, and the record itself may be stored in compressed form. How could fseek() deal rationally with this? If you want an easy port of a program using the UNIX I/O facilities, it will have to deal with stream files, since that's what UNIX provides. (Unfortunately, the VMS C RTL still had some rather odd quirks last time I looked, but the latest release was supposed to improve it--I haven't used it since then.) Hopefully this isn't really controversial, but I've directed followups to alt.religion.computers just in case.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
tp@mccall.com (Terry Poot) (11/07/90)
In article <803@inews.intel.com>, bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >In article <69986@iuvax.cs.indiana.edu> hughes@copper.ucs.indiana.edu (larry hughes) writes: >>In article <1380@tharr.UUCP> sweh@tharr.UUCP (Stephen Harris) writes: >>>How in VMS do you have filters and pipelines? >>>eg, what would be the VMS (DCL?) equivalent of >>> getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file >>> >>>Is there an equivalent, or would it need a lot of temporary files? >> >>Yes, you would need a lot of temporary files. VMS already has a mechanism similar to pipes, called mailboxes. The major difference is that mailboxes are record rather than character oriented. "Fixing" this would only require a new device driver to implement a character oriented mailbox (aka pipe). Note that the record oriented nature is not an insurmountable problem, even now. You just have to make sure your buffers are properly flushed. I ported the PBMPLUS utilities to VMS and can pipe them all together just fine. The code that does the pipes has been floating around the net for a long time, and is widely available. I made a very simple mod to handle binary data. Thus this is possible, just not commonly done on VMS. One of the reasons for that is that VMS is slower at creating subprocesses than unix, another is just a cultural issue. >Would a POSIX-compliant VMS fix this? In answer to the various responses to this comment: Jay Maynard: >Uhm, Blair...could VMS be hacked up into POSIX compliance? If so, then it's >a looser standard than it should be... Why, because VMS can comply with it? :-) Yes, VMS will be made POSIX compatible. This will be delivered in '91. It will also be made XPG/3 compatible (not sure about the time frame). This is not a small project, DEC has been talking about it for over a year at DECUS sessions. Larry Hughes: >To answer the first question, a POSIX-compliant VMS would not >fix this, to my understanding. POSIX defines the calling standard >(interface) to the operating system. However, I don't have a deep >understanding of this, so don't take my word for it. As I said, VMS can already do this. If pipes are part of the POSIX standard, then it will be able to do it with even less work. Whether the standard VMS utilities are modified to work as filters is a whole 'nother question. Ran Atkinson: BTW, I agree with Jay that the POSIX standard is looser than it >should be -- especially in the Shell & Tools area. The fact >that DEC plans a POSIX compliant VMS without a major overhaul >is an excellent existence proof that the standard is too loose. Who said it wasn't a major overhaul? At the presentation I attended, they said that the POSIX system calls would be added to the VMS kernal, equal in status to the existing VMS system services. Supporting unix-style links will require major changes to the file system. This is a major, long-term project that DEC has been working on for years. They have announced their intention to support future POSIX standards as they stabilize (they are currently only talking about 3 of them, I forget which). They will have VMS branded by X/OPEN as XPG/3 compatible. They are going to add much if not most of the OSF technology (they already have Motif), especially the DCE (distributed computing environment), with the eventual goal of being completely compatible with the OSF specs. They fully intend to make VMS a proper superset of "standard" unix, as such a thing comes into existance. As far back as the founding of OSF, before they decided they were going to license code and not just write specs, Ken Olsen boasted that VMS would be the first OSF compliant operating system (which created a furor among unix vendors who think that open systems must be unix by definition, which would be a cute oxymoron). Who knows, if all the unix vendors had to implement OSF from scratch, they might have made it (especially since significant parts of Motif and the DCE come from DEC in the first place). Disclaimer: I am not affiliated with DEC except as a customer. The above information all comes from articles published in various DEC-oriented magazines, and presentations given by DEC employees that I have attended at various DECUS symposia. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
boyd@necisa.ho.necisa.oz (Boyd Roberts) (11/07/90)
In article <1380@tharr.UUCP> sweh@tharr.UUCP (Stephen Harris) writes: >How in VMS do you have filters and pipelines? >eg, what would be the VMS (DCL?) equivalent of > getso - | tbl | pic | eqn | rof | col | sqps | lpr -Ppost < file > >>Is there an equivalent, or would it need a lot of temporary files? > It would be a lot of temporary files. But look at it this way, you could set up a file `stdout.dat' manipulated by a DCL script that ran all the commands in sequence such that: process n's stdout.dat;N == process n+1's standard input process n+1's stdout.dat;N+1 == process n+2's standard input etc... It'd be marvellous, a different version of stdout for each output stage of the pipeline. All individually named by version number and _all_ of them left lying around after the completion of the `pipeline' The possibilities are endless! :-) Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
dnb@meshugge.media.mit.edu (David N. Blank) (11/08/90)
I actually have a C program which allowed VMS users to do things like
redirection to/from files and do piping (it handled the mailbox setups
for you). However, this brings up another problem with this scenario:
the standard VMS programs don't seem to be written with pipelining in mind.
They're not careful to use the stdin and stdout type models. As a
result, the program I used for pipelines only had limited
functionality.
Peace,
dNbguy@auspex.auspex.com (Guy Harris) (11/10/90)
(Dunno if "alt.religion.computers" is the right place, but it's probably better than "comp.unix.programmer" at this point....) > The best thing about RMS is it's ability to support DBMS's which >generally run circles 'round a similar one under Ultrix/BSD. Besides, >it's a little bit simpler to implement a database using a filesystem >w/ built in ISAM instead of opening a Unix partition and seeking here >and there. Does a UNIX system with, say, an XPG3-compliant ISAM library have "a filesystem w/ built in ISAM"? If not, why not? If the answer is "because that's implemented atop the file system rather than built into the file system", how is this different from VMS, which as I remember implements ISAM, just as it implements the various text file types, atop QIOs that just read and write blocks of files? If the answer is "well, RMS runs in *executive* mode rather than *user* mode", how much does this really matter? If the answer is "well, Files-11 lets you store all sorts of attributes in the file header that the low-level QIO interface doesn't interpret, but that RMS does", again, how much does this really matter?