Is VMS Dying?
Craig Dedo
This week a software engineer told me that VMS is a dying operating
system. I would like to know what the readers of this forum think. I have
some thoughts on this issue, but first I would like to see what other
people think. Some of the following questions involve business rather than
technical issues. Some people may feel that discussing business issues is
inappropriate in a technical forum. However, the future of a technical
product like VMS depends heavily on BOTH.
Please consider the following questions, as well as any related matters.
1. Does VMS have much of a future?
2. Is VMS losing out to Unix? If so, why? If not, what evidence is
there that this is not the case?
3. Does VMS provide enough bang for the buck? How does it compare to
the competition in this area?
4. What do you think are the strengths of VMS that would make it an
attractive alternative to someone who is used to Unix? To MS-DOS?
5. If the big objection to VMS is that it is proprietary, why don't we
hear such complaints about MS-DOS and Windows?
6. Should DEC consider franchising VMS to independent software
developers (ISVs) who could add their own enhancements, the way Microsoft
has done with MS-DOS or McDonald's has done with their restaurants? Would
this answer the objection that VMS is proprietary while Unix is not?
7. How can DEC make VMS attractive to the nation's computer science
departments?
8. How can DEC make VMS attractive to software developers?
9. Does VMS have features that are not found or are not nearly as well
developed in competing operating systems? If so, what are they?
10. Are these features (which are better developed in VMS) very much
appreciated by the people who actually make the operating system selection
decisions? If not, why not?
11. What market should VMS serve?
12. Should DEC develop a standard GUI interface to VMS, such as
Microsoft Windows or X-Windows?
Sincerely,
--
Craig T. Dedo Craig...@mixcom.com
17130 W. Burleigh Place (414) 783-5869
Brookfield, WI 53005
Chris Higgins - System Administrator
> February 26, 1994
>
> This week a software engineer told me that VMS is a dying operating
>system. I would like to know what the readers of this forum think. I have
>some thoughts on this issue, but first I would like to see what other
>people think. Some of the following questions involve business rather than
>technical issues. Some people may feel that discussing business issues is
>inappropriate in a technical forum. However, the future of a technical
>product like VMS depends heavily on BOTH.
>
> Please consider the following questions, as well as any related matters.
> 1. Does VMS have much of a future?
>
> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
>there that this is not the case?
On the other hand, most of the businesses that I know that want a reliable
system go VMS, and VMS only.
>
> 3. Does VMS provide enough bang for the buck? How does it compare to
>the competition in this area?
(and several Unix system so I'm not biased :-). Over the last couple of months
I've witnessed numerous occasions where other local admins (Unix machines) have
proclaimed that feature X should be part of Unix, and why don't all Unix
machines come fitted with feature Y, and I've taken great pleasure in pointing
out that those features are part of VMS, and have been for a long time.
>
> 4. What do you think are the strengths of VMS that would make it an
>attractive alternative to someone who is used to Unix? To MS-DOS?
People on Unix who want to get more out of the machine than just compliation,
people who want security and control over their systems should realise that VMS
has all the controls necessary.
>
> 5. If the big objection to VMS is that it is proprietary, why don't we
>hear such complaints about MS-DOS and Windows?
To get a VMS machine you need to admin it.. so you need to know computers...
so you'll know if something is wrong... whereas with Windoze you can give it to
any business man, throw some jargon about "standards", "user-interface",
"progressive-technology", etc etc etc
You should talk to people 'in the know' about Windoze... the amount of hardware
that you need to throw at windoze to get reasonable response time is criminal.
If you threw equivalent hardware at any other system then you'd need Cray level
power in an average Alpha.
>
> 6. Should DEC consider franchising VMS to independent software
>developers (ISVs) who could add their own enhancements, the way Microsoft
>has done with MS-DOS or McDonald's has done with their restaurants? Would
>this answer the objection that VMS is proprietary while Unix is not?
Unix is *** NON *** STANDARD ***. How many versions of Unix exist, how big is
the source code to various packages because they have to support hundreds of
variations of Unix.
>
> 7. How can DEC make VMS attractive to the nation's computer science
>departments?
Provide shells other than DCL, so that people can have the flexibility to do as
they wish.... (I love DCL, but TCSH straight on the OS (no posix) would be
nice.
>
> 8. How can DEC make VMS attractive to software developers?
Shells.
>
> 9. Does VMS have features that are not found or are not nearly as well
>developed in competing operating systems? If so, what are they?
File ACLs, Accounting, Resource control......
>
> 10. Are these features (which are better developed in VMS) very much
>appreciated by the people who actually make the operating system selection
>decisions? If not, why not?
Only if the people making the decision 'know' what they are looking for, and
where they may expand.
>
> 11. What market should VMS serve?
All of them, why not :-)
>
> 12. Should DEC develop a standard GUI interface to VMS, such as
>Microsoft Windows or X-Windows?
Haven't you heard of DECwindows ???
>
>Sincerely,
>--
>Craig T. Dedo Craig...@mixcom.com
>17130 W. Burleigh Place (414) 783-5869
>Brookfield, WI 53005
Disclaimer:
1/ All comments are my own.
2/ None of my comments may be printed/ published without my explicit agreement.
3/ I run VMS machines, Linux machines, OSF/AXP machines, SUN-OS machines,
Ultrix machines, and avoid DOS/Windows machines :-)
4/ I lecture Unix courses, but still think that VMS is a 'better' operating
system, esp from a sys admin point of view.
Chris.
+ J.C. Higgins, + Ch...@csvax1.ucc.ie + If you love something, set it +
+ VMS Sys. Admin, + Ch...@cs.ucc.ie + free. If it doesn't come back +
+ Comp.Sc.Dept. + Ch...@odyssey.ucc.ie + to you, hunt it down and +
+ UCC, Ireland + C.Hi...@bureau.ucc.ie + KILL it. +
Jerry Leichter
system. I would like to know what the readers of this forum think. I
have some thoughts on this issue, but first I would like to see what
other people think. Some of the following questions involve business
rather than technical issues. Some people may feel that discussing
business issues is inappropriate in a technical forum. However, the
future of a technical product like VMS depends heavily on BOTH.
Please consider the following questions, as well as any related
matters.
1. Does VMS have much of a future?
Who can say? DEC is hurting these days, and VMS is hurting along with it (or
put the causality the other way if you prefer; I don't think it would actually
make much of a difference). DEC has managed to hurt VMS both with too much
love, and with too little. For years, DEC acted as if "VMS is the answer;
what was the question?" DEC also acted as if its exclusive control on the VMS
market would guarantee high margins forever. In both of these, DEC learned
too well from the IBM business model. That was a fantastic money-maker for
quite a while, but you can see where both DEC and IBM are now.
Today, DEC seems completely uncertain of where it is going, and specifically
where VMS is going. Whatever their commitment to VMS - and it seems to still
be substantial in terms of resources, no surprise given that some numbers I've
seen in the trade press indicate that well over half of DEC's revenues are
still "VMS related" - in their attempt to appear "open" they've only managed
to make it look like they are abandoning VMS, while simultaneously appearing
not to endorse anything new. The announcement that support for "desktop VMS"
- or was it "VMS on the desktop"? *Very* different things - was a case in
point.
In a recent Digital News and Review editorial, Jack Fegreus that DEC rename
its two premier AXP products as OpenUnix/VMS and OpenUnix/OSF, relying on
the fact that VMS is Posix compliant and has XGP "branding". He says it as
a bit of a joke, but the *idea* behind it is one DEC could make a run off of,
if they could get their act together.
2. Is VMS losing out to Unix? If so, why? If not, what evidence is
there that this is not the case?
No. Unix's time is passing. For at least the last five years, we've been
told that "this is the year of Unix". It's never come to be. The Unix world
still hasn't even managed to agree on a standard, and there's no sign they
will any time soon. Meanwhile DOS and DOS-inspired systems (OS/2, NT, newer
versions of Windows) have taken over the desktop and are spreading from there.
Unix faces the same threat that it posed to the traditional mainframe/mini
systems. The world seems still to be partitioned into systems seen as
PC's, systems seen as workstations, and systems seen as minis/mainframes (now
re-christened "servers"), and Unix will keep its hold on workstations and
some minis; but if it ever had a chance to make it in PC's, that's long gone.
In the meanwhile, more and more "workstation" jobs are being taken over by
PC's.
3. Does VMS provide enough bang for the buck? How does it compare to
the competition in this area?
On AXP's, absolutely. There are a number of areas in which it really has
little effective competition. Unix is catching up - in fact, some of DEC's
OSF efforts are a big contributor here - but you have to wonder (a) just how
many back-end systems there will be; (b) given the relatively small numbers,
why people would bother to switch from current practice if their current
systems can be upgraded cost-competitively; (c) if they *do* decide to switch,
why they'd go to Unix when their organizations have huge numbers of PC's
running Windows.
4. What do you think are the strengths of VMS that would make it an
attractive alternative to someone who is used to Unix? To MS-DOS?
VMS looks and is "industrial strength". Unix tries to be (and is in some
areas), but it still retains a heritage that had the original versions respond
to any hardware fault by calling panic, which crashed the system. (The theory
was that if the hardware was broken, you really couldn't do much anyway, so
why bother?) There are tons of large and small examples of "small non-
critical system" thinking in Unix, and despite years of effort, they still
haven't all been extirpated.
As to MS/DOS - anyone who's used even Unix finds the MS/DOS world at once
very attractive and very repulsive. Attractive because some of the develop-
ment environments are impressive. (I've yet to see a symbolic debugger on
Unix worthy of the name - gdb, from the Gnu project, is the only one that's
even worth any time playing with, and it's limited. The VMS Debugger, on the
other hand, is an excellent product. But it has difficulty competing with
PC environments developed from the ground up on the assumption that a whole
3-MIP-or-faster CPU and a fast display are dedicated to a single user.) But
MS/DOS is also repulsive because if anything goes wrong, you are left totally
at sea. This is still a system whose users *expect* to reboot regularly to
unjam their systems. The great breakthrough of Windows 3.1: For the first
time, a Microsoft OS *checks the parameters passed to it for validity before
attempting to at on them*! What a breakthrough!
5. If the big objection to VMS is that it is proprietary, why don't we
hear such complaints about MS-DOS and Windows?
God knows. The market acts in strange ways. Why was Ultrix consistently seen
and described as "DEC's proprietary Unix implementation", while SunOS an HPUX
and all the rest were seen as "Unix"? (This by the same people who complained
that Ultrix was too much a "plain vanilla" version of BSD.) Why did a recent
industry survey card ask me to list hardware I had - and include separate
boxes for "Alpha" and "RISC" (no other RISC processors got their own box).
Sun got where it is today partly on the strength of excellent marketing. They
managed to convince everyone that *they* were "open" and "non-proprietary",
while DEC, who they got much of their market share from, was "closed" and
"proprietary". DEC was too busy going after IBM at the time to bother to
respond, and the labels have stuck.
6. Should DEC consider franchising VMS to independent software
developers (ISVs) who could add their own enhancements, the way
Microsoft has done with MS-DOS or McDonald's has done with their
restaurants? Would this answer the objection that VMS is proprietary
while Unix is not?
Actually, DEC has announced that you *can* license VMS in order to port it to
your own hardware. I don't think anyone's taken them up on it, and I expect
that they've never really seriously expected that anyone would - so I doubt
they've ever worked out the mechanisms. Anyone think there'd be a market for
VMS on 486's and Pentium's? There's a *lot* of such hardware out there; even
a .1% share could make you rich. The question of implementability has been
discussed here; I'm pretty sure it could be done, though it would take some
work. Anyone interested in forming a company to do it?
7. How can DEC make VMS attractive to the nation's computer science
departments?
8. How can DEC make VMS attractive to software developers?
9. Does VMS have features that are not found or are not nearly as well
developed in competing operating systems? If so, what are they?
10. Are these features (which are better developed in VMS) very much
appreciated by the people who actually make the operating system
selection decisions? If not, why not?
11. What market should VMS serve?
Too many questions; I've skipped over the above.
12. Should DEC develop a standard GUI interface to VMS, such as
Microsoft Windows or X-Windows?
Eh? Ever hear of DECwindows?
-- Jerry
HALLAM-BAKER Phillip
|> February 26, 1994
|>
|> This week a software engineer told me that VMS is a dying operating
|>system. I would like to know what the readers of this forum think. I have
|>some thoughts on this issue, but first I would like to see what other
|>people think. Some of the following questions involve business rather than
|>technical issues. Some people may feel that discussing business issues is
|>inappropriate in a technical forum. However, the future of a technical
|>product like VMS depends heavily on BOTH.
|>
|> Please consider the following questions, as well as any related matters.
|> 1. Does VMS have much of a future?
No more than UNIX does,
|> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
|>there that this is not the case?
They are both headed for the scrap heap. UNIX is too complex and too
chaotic to sell to any but comp sci professionals. It can never gain
a mass market in the way Windows has.
VMS is tied to proprietary hardware. Removing that limitation might
have been profitable ten years ago but not today. A more likely result
is DEC take RMS and other nice bits from VMS and stick them on top of
MACH to produce a 64 bit successor.
|> 3. Does VMS provide enough bang for the buck? How does it compare to
|>the competition in this area?
It is designed to run datasbases efficiently and does. UNIX is not designed.
|> 7. How can DEC make VMS attractive to the nation's computer science
|>departments?
Call it UNIX.
Unfortunately the nations conmputer science departments would prefer to
stay as close to what they see as received wisdom as possible. Teaching
only one operating system is a bit like only teaching one language. The
students come out with some very fixed ideas.
|> 9. Does VMS have features that are not found or are not nearly as well
|>developed in competing operating systems? If so, what are they?
Transaction processing. True support for asynchronous I/O and better
real time support than any UNIX system.
|> 12. Should DEC develop a standard GUI interface to VMS, such as
|>Microsoft Windows or X-Windows?
They have. It used to be called XUI but today tends to be called Motif.
--
Phillip M. Hallam-Baker
Not Speaking for anyone else.
David L. Cathey
> In article <1994Feb26....@mixcom.mixcom.com>, Craig Dedo <Craig...@mixcom.mixcom.com> writes:
>> February 26, 1994
>>
>> This week a software engineer told me that VMS is a dying operating
>>system. I would like to know what the readers of this forum think. I have
>>some thoughts on this issue, but first I would like to see what other
>>people think. Some of the following questions involve business rather than
>>technical issues. Some people may feel that discussing business issues is
>>inappropriate in a technical forum. However, the future of a technical
>>product like VMS depends heavily on BOTH.
>>
>> Please consider the following questions, as well as any related matters.
>> 1. Does VMS have much of a future?
> Yes. Lots.
Yes it does. I feel that the AXP has put the price/performance
back into VMS.
>> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
>>there that this is not the case?
> Unix seems to be the choice of universities, so graduates don't know "VMS".
> On the other hand, most of the businesses that I know that want a reliable
> system go VMS, and VMS only.
The UNIX people would have you to believe that, and in some cases
that may be true. However, I saw an article in a mag (not one of the normal
"DEC-centric" ones) that VMS is still a growing part of Digitals revenues.
It seems that they are seen as the choice for down-sized mainframes.
>> 3. Does VMS provide enough bang for the buck? How does it compare to
>>the competition in this area?
> As an Operating system, VMS drives Unix into the ground. I run a VMS system
> (and several Unix system so I'm not biased :-).
Despite the previous response, your "bang for the buck" will vary.
Not all systems are suited for all purposes. However, given the flexibility
of VMS, it provide excellent price/performance. And for some performance,
it AXP or a Cray. :-)
>> 4. What do you think are the strengths of VMS that would make it an
>>attractive alternative to someone who is used to Unix? To MS-DOS?
Security. Internetworking (TCP/IP, OSI, LanMan, Novell, XNS, X.25
and all CONCURRENTLY!). Robust O/S (doesn't "panic" often (UNIX) or have odd
memory lockups (MS-DOS); have known systems to run over a year without
rebooting!).
>> 5. If the big objection to VMS is that it is proprietary, why don't we
>>hear such complaints about MS-DOS and Windows?
Here's a hint: Except for a very few (like Linux), all O/S's are
propriatary. Why else are they trademarked??? AIX, HP-UX, Solaris, Sun-OS,
Ultrix, MVS, OpenVMS, MS-DOS, MS-Windows, WNT, ... all are proprietary.
You cannot buy vendor A's hardware and run vendor B's O/S on it. Oh, but
the UNIX crowd says that the your more portable. Really? Did you know that
the only operating system to meet the toughest UNIX standard (FIPS 151-2)
is OpenVMS??? I've ported many applications from the net to VMS (including
network and X-window stuff) with little to trouble. And the code is usually
sprinkled with #ifdef's for various UNIX O/S's. If UNIX is so standard, then
why do you need "#ifdef BSD", ... ???
> To get a VMS machine you need to admin it.. so you need to know computers...
Not so fast! You need to "admin" any system.
> If you threw equivalent hardware at any other system then you'd need Cray level
> power in an average Alpha.
True. I can run a VMS system with Motif with 16Mb and have better
performance than a 16Mb PC with WNT... :-) Though I'd still want more memory..
>> 6. Should DEC consider franchising VMS to independent software
>>developers (ISVs) who could add their own enhancements, the way Microsoft
>>has done with MS-DOS or McDonald's has done with their restaurants? Would
>>this answer the objection that VMS is proprietary while Unix is not?
>
> Unix is *** NON *** STANDARD ***. How many versions of Unix exist, how big is
> the source code to various packages because they have to support hundreds of
> variations of Unix.
True. This would create more confusion than VMS -> OpenVMS did.
>> 7. How can DEC make VMS attractive to the nation's computer science
>>departments?
>
> Provide shells other than DCL, so that people can have the flexibility to do as
> they wish.... (I love DCL, but TCSH straight on the OS (no posix) would be
> nice.
(So compile tcsh on POSIX!) DEC needs to do what AT&T did with UNIX:
(Listen DEC, this is important) GIVE UNIVERSITIES LICENSES AND HARDWARE.
DEC has TONS of hardware that they throw away in Arizona because it is still
on the books. Give this stuff and Campus-Wide-Software-Licenses to Colleges,
High Schools, Universities, ...
Here's why: UNIX is big because AT&T and Berkley got students used
to using it 10 years ago. Guess what - Those same people are NOW making
purchasing decisions about what they know: UNIX. Kids come out of college
knowing only what: UNIX. C. C++. Why? Because that's *all* they learned to
use, and it because the "standard". Put VMS boxes in there with lots of fun
software, and when they graduate, they will want to put VMS in there.
>> 8. How can DEC make VMS attractive to software developers?
> Shells.
Actually, DEC does do a good job on this, but it might be one of their
better kept secrets. DEC's Independent Software Vendor program has been
invaluable to me.
>> 9. Does VMS have features that are not found or are not nearly as well
>>developed in competing operating systems? If so, what are they?
> File ACLs, Accounting, Resource control......
ACL's on everything, Process Class scheduling (V6.0), file structures,
I/O through the command language, VMSclusters, locking ($ENQ), logicals
names, ...
>> 10. Are these features (which are better developed in VMS) very much
>>appreciated by the people who actually make the operating system selection
>>decisions? If not, why not?
> Only if the people making the decision 'know' what they are looking for, and
> where they may expand.
In short: NO. Typically, the people making the purchase don't know
squat about the things they are buying. Managment hears "Open Systems", and
somewhere they read that means "UNIX". VMS provides just as open of an
environment as any UNIX, and provides a lot more for those that want it.
Me, yes I appreciate all the features.
>> 11. What market should VMS serve?
> All of them, why not :-)
I've seen VMS systems control shop floors, point-of-sale for
Blockbuster Video, number crunching/simulations. DEC's AXP systems are
even used to produce "Beavis and Butthead"!
>> 12. Should DEC develop a standard GUI interface to VMS, such as
>>Microsoft Windows or X-Windows?
>
> Haven't you heard of DECwindows ???
Actually, it's "Motif" - which is already on VMS. Motif is a toolkit
that sits on top of X-windows.
>>Craig T. Dedo Craig...@mixcom.com
> + J.C. Higgins, + Ch...@csvax1.ucc.ie + If you love something, set it +
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey |INET: dav...@montagar.com
Montagar Software Concepts |UUCP: ...!montagar!davidc
P. O. Box 260772, Plano TX 75026-0772 |Fone: (214)-618-2117
Kevin Luster
Craig Dedo <Craig...@mixcom.mixcom.com> wrote:
> This week a software engineer told me that VMS is a dying operating
>system.
Naw. Once it gets it's X/Open 1170 Certification Stamp (tm) it'll then
be Unix!
-K
Colin Simpson
> February 26, 1994
>
> This week a software engineer told me that VMS is a dying operating
> system. I would like to know what the readers of this forum think. I have
> some thoughts on this issue, but first I would like to see what other
> people think. Some of the following questions involve business rather than
> technical issues. Some people may feel that discussing business issues is
> inappropriate in a technical forum. However, the future of a technical
> product like VMS depends heavily on BOTH.
>
> Please consider the following questions, as well as any related matters.
> 1. Does VMS have much of a future?
Most people I have spoken to say that in there opinion VMS has about 5 years.
>
> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
> there that this is not the case?
Yes, and the general trend of using PCs where people may have used minis
or mainframes.
>
> 3. Does VMS provide enough bang for the buck? How does it compare to
> the competition in this area?
>
I am told that in certain areas VMS is better than UNIX for giving raw
machine performance.
> 4. What do you think are the strengths of VMS that would make it an
> attractive alternative to someone who is used to Unix? To MS-DOS?
Don't know.
>
> 5. If the big objection to VMS is that it is proprietary, why don't we
> hear such complaints about MS-DOS and Windows?
>
The big complaint is that it is proprietary but it is more than that,
it only runs on machines made by DEC as far as I know. This is not
true of DOS or Windows.
> 6. Should DEC consider franchising VMS to independent software
> developers (ISVs) who could add their own enhancements, the way Microsoft
> has done with MS-DOS or McDonald's has done with their restaurants? Would
> this answer the objection that VMS is proprietary while Unix is not?
I don't think anyone is interested in franchising VMS. Anyway DEC appears
to be moving towards NT as their future. They probably acknowledge that
VMS on its last legs or getting there.
>
> 7. How can DEC make VMS attractive to the nation's computer science
> departments?
>
Its too late. It's not UNIX or PC compatible I don't think there would be much in it
for them. Any increased interest in VMS would only be possible if it ran on
a wide variety of hardware.
> 8. How can DEC make VMS attractive to software developers?
Its that endless circle of having to get more people to use it before
developers feel like porting software to it. And more people will
not use it until there is more software.
>
> 9. Does VMS have features that are not found or are not nearly as well
> developed in competing operating systems? If so, what are they?
It has a built in Batch Scheduler, it has the working set model of memory
etc etc . Its all pros and cons like most comparisons of this sort.
>
> 10. Are these features (which are better developed in VMS) very much
> appreciated by the people who actually make the operating system selection
> decisions? If not, why not?
Don't know.
>
> 11. What market should VMS serve?
The UNIX market but it seems to be failing there.
>
> 12. Should DEC develop a standard GUI interface to VMS, such as
> Microsoft Windows or X-Windows?
>
I am told its not uncommon to see VMS running X.
> Sincerely,
> --
> Craig T. Dedo Craig...@mixcom.com
> 17130 W. Burleigh Place (414) 783-5869
> Brookfield, WI 53005
--
Colin Simpson - c...@dcs.ed.ac.uk
*=============================================================================*
* "....it has been observed that the size of one's sig block is *
* usually inversely proportional to one's level of prestige on the net." *
* *
* --- The New Hackers Dictionary *
*=============================================================================*
Chris Kalisiak
I've heard something about this... When is this branding supposed to
happen?
chris
--
Chris Kalisiak |"Pound for pound, lame puns are your best entertainment
kali...@cs.buffalo.edu | value." -- Gogo Dodo, Tiny Toon Adventures
Tel/Fax:(716)692-5128/695-8481 |"Cocaine is God's way of telling you you have
I'm a student; I don't speak for UB.| way too much money." -- Sting, The Police
iv...@cc.usu.edu
> 5. If the big objection to VMS is that it is proprietary, why don't we
> hear such complaints about MS-DOS and Windows?
Because they're cheap and run on cheap machines...
>
> 7. How can DEC make VMS attractive to the nation's computer science
> departments?
>
> 8. How can DEC make VMS attractive to software developers?
Ship source listings with the machines. I still have the 3.0 microfiche
that I got with our /730...
>
> 9. Does VMS have features that are not found or are not nearly as well
> developed in competing operating systems? If so, what are they?
Good asynchronous I/O and a decent device driver interface.
--
----------------+------------------------------------------------------
Roger Ivie | Don't think of it as a 'new' computer, think of it as
iv...@cc.usu.edu | 'obsolete-ready'
Raul Deluth Miller
>J.C. Higgins:
David L. Cathey:
Security. Internetworking (TCP/IP, OSI, LanMan, Novell,
XNS, X.25 and all CONCURRENTLY!). Robust O/S (doesn't "panic"
often (UNIX) or have odd memory lockups (MS-DOS); have known
systems to run over a year without rebooting!).
Interesting. UMUC moved me off of the VMS platform I was on, and onto
Unix, because of problems I was having with the TCP/IP implementation.
[Of course, these problems have probably been fixed, since then. I've
not found any compelling reason to go back.]
>> 5. If the big objection to VMS is that it is proprietary, why
>>don't we hear such complaints about MS-DOS and Windows?
Here's a hint: Except for a very few (like Linux), all
O/S's are propriatary. Why else are they trademarked??? AIX,
HP-UX, Solaris, Sun-OS, Ultrix, MVS, OpenVMS, MS-DOS, MS-Windows,
WNT, ... all are proprietary. You cannot buy vendor A's hardware
and run vendor B's O/S on it. Oh, but the UNIX crowd says that the
your more portable. Really?
Yeah, runs on more machines.
(So compile tcsh on POSIX!) DEC needs to do what AT&T did
with UNIX: (Listen DEC, this is important) GIVE UNIVERSITIES
LICENSES AND HARDWARE. DEC has TONS of hardware that they throw
away in Arizona because it is still on the books. Give this stuff
and Campus-Wide-Software-Licenses to Colleges, High Schools,
Universities, ...
I don't know what this would solve. Every college I've been to has
had both vms and unix [and some ibm os, such as cms] available for
student use [and dos and macintoshes and nexts]. For some reason, the
unix systems have been more pleasant to use [you can have a larger
storage quota, you can run more processes, etc...].
Which may be why I've never invested the time to master dcl.
>> 8. How can DEC make VMS attractive to software developers?
> Shells.
Actually, DEC does do a good job on this, but it might be
one of their better kept secrets. DEC's Independent Software
Vendor program has been invaluable to me.
Bleah. The vms systems I've been on have had a variety of packages
that LOOK neat -- but when I try to use them, I find only superficial
documentation on little things like "why is this system fundamentally
different other things like it, on other machines?"
Without widely available information/examples, it's slow going on any
machine. "Better kept secrets" aren't going to make things easier for
the people who have to use the machine.
[That, and all to often I run into parts of the help system that are
unable to send information a screen at a time. Which can be
inconvenient, or crippling, depending on my situation at the time.]
>> 9. Does VMS have features that are not found or are not nearly
>>as well developed in competing operating systems? If so, what
>>are they?
> File ACLs, Accounting, Resource control......
ACL's on everything, Process Class scheduling (V6.0), file
structures, I/O through the command language, VMSclusters,
locking ($ENQ), logicals names, ...
Which might be why VMS systems are so hard for a person to use --
there's all this administrative bullshit you have to go through to get
permission to use the system. Better to use a system that relies on
social mechanisms than one which relies on red tape.
Micro-management is not necessarily better management. And armor
plating is not always the best approach to security.
Raul D. Miller
<rock...@nova.umd.edu>
Bruce Salem
>In article <1994Feb26....@mixcom.mixcom.com>, Craig Dedo <Craig...@mixcom.mixcom.com> writes:
>> February 26, 1994
>>
>> This week a software engineer told me that VMS is a dying operating
>>system. I would like to know what the readers of this forum think. I have
>>some thoughts on this issue, but first I would like to see what other
>>people think. Some of the following questions involve business rather than
>>technical issues. Some people may feel that discussing business issues is
>>inappropriate in a technical forum. However, the future of a technical
>>product like VMS depends heavily on BOTH.
>>
>> Please consider the following questions, as well as any related matters.
>> 1. Does VMS have much of a future?
>Yes. Lots.
I remember when DEC wouldn't acknowledge UNIX. People would go out
and buy RSX-11M, or VMS, because it come with the machine, or was mandated
by the support contract, and then install and run UNIX. Of course, now the
situation is reversed. DEC had to be drug kicking and screaming into UNIX
support long about 1980, and we have Ultrix and Posix compatability as a
result. The future of VMS depends on marketing realities; how many people
want to run VMS.
>> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
>>there that this is not the case?
>Unix seems to be the choice of universities, so graduates don't know "VMS".
>On the other hand, most of the businesses that I know that want a reliable
>system go VMS, and VMS only.
Why is that? When you buy a propriety OS, the upside is support. The
success of companies like IBM and DEC isn't really in how cutting edge their
HW & SW is, but in how fast the CE and Tech Support can get a downed system
back up and how well they can answer all the other questions. The technical
merit of an OS may not matter to business people, and the developers and
maintainers of applications in businesses, especially large conservatively
run businesses, may not have very much input into what machines are bought.
DEC can still sell lots of systems if they maintain influiential accounts
and have a good reputation in the niche with the MIS and CFOs.
>>
>> 3. Does VMS provide enough bang for the buck? How does it compare to
>>the competition in this area?
>As an Operating system, VMS drives Unix into the ground. I run a VMS system
>(and several Unix system so I'm not biased :-). Over the last couple of months
>I've witnessed numerous occasions where other local admins (Unix machines) have
>proclaimed that feature X should be part of Unix, and why don't all Unix
>machines come fitted with feature Y, and I've taken great pleasure in pointing
>out that those features are part of VMS, and have been for a long time.
>
But how fast does DEC add a bug fix or a requested feature? ON a
UNIX system, a system programmer could write a new feature, and many can
be implemented in shell scripts. Maybe the problem is that many Sys Admins
are too busy putting out fires than having the time to sitdown and write
code for a solution, and how many of them really can write applications
in the first place? VMS does have some better performance and robustness
features than UNIX; it is also not a portable OS and it has been taylored
to DEC's HW and a few OEMs. UNIX has to run on amny more systems and can't
always be a design which takes advantage of the HW.
>> 4. What do you think are the strengths of VMS that would make it an
>>attractive alternative to someone who is used to Unix? To MS-DOS?
>People on Unix who want to get more out of the machine than just compliation,
>people who want security and control over their systems should realise that VMS
>has all the controls necessary.
I have never administered VMS, but as a user in 1986-7, I was
under the impression that its compilers were top-notch, its filesystem
was more robust, and some of the system admin utilities were better than
UNIX, at that time. Backup is more flexible than dump/restore, and you
didn't have the danger of corrupting a dump by trying to save an open
file whose length is changing. That can make a UNIX restore fail, which
is why it is best to take a system down to single user, unmount the
filesystem, and then do a full dump. Backup wouldn't dump open files,
and it was more like tar in its handling of files.
>> 7. How can DEC make VMS attractive to the nation's computer science
>>departments?
>
>Provide shells other than DCL, so that people can have the flexibility to do as
>they wish.... (I love DCL, but TCSH straight on the OS (no posix) would be
>nice.
Yes, I'll agree with that. One solution I saw beck in 1985 was Eunice,
a UNIX system on top of VMS. You got UNIX shells and commands on the VMS
filesystem. Subsequently, DEC offered DECshell, which I recall was csh.
Many of the VMS commands are brain dead. Compare set-default with cd, or
search with grep. Beside the fact that you would need an awk program to
strip out all the boiler plate from search output, it dodn't handle
limited regular expressions. If DEC wanted to keep its foot in both
markets it should affer UNIX commands as part of VMS, legal issues asside.
>> 8. How can DEC make VMS attractive to software developers?
>Shells.
DEC's compilers are very good, and well documented. For a long
time people bought VMS, even for scientific work, because FORTRAN-77
was vastly superior to f77, and DEC has a good C, and now a good C++
compiler.
>> 9. Does VMS have features that are not found or are not nearly as well
>>developed in competing operating systems? If so, what are they?
>File ACLs, Accounting, Resource control......
I thought ACLs were part of Sys V.
--
!! Just my opinions, maybe not those of my sponsor. !!
Pat Thomas
> February 26, 1994
>
> This week a software engineer told me that VMS is a dying operating
>system. I would like to know what the readers of this forum think. I have
I'd be happy to add my $0.02... Just as some background, I'm a Computer
Science student, with little if any experience with unix or VMS in the
real world (tm) of work/deadlines. That might bias some of my replies. ;-)
BTW, I also own, operate, and maintain both a VAX and a unix workstation.
> Please consider the following questions, as well as any related matters.
> 1. Does VMS have much of a future?
Only as much of one as minicomputers have, IMO. VMS is a terrific OS,
but I doubt that it's the kind of thing a microcomputer owner wants
(or needs) ... barring the microcomputer owner who wants multiple users
on their system...
> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
>there that this is not the case?
I believe so, personally. The fact of the matter is that VMS only runs
on VAX machines. Unix, though devoid of a real standard, runs on just
about anything with a CPU and a C compiler (and adequate hardware, of
course). On the other hand, VMS is not "losing out" to unix per se, from
the point of view that it's still used almost exclusively for VAX machines,
it's (VMS's) intended platform.
> 3. Does VMS provide enough bang for the buck? How does it compare to
>the competition in this area?
I don't think so. Bang, yes. But notice that there are free versions
of unix out there now (not that Linux is anywhere near as glitch-free
as VMS). As far as the "bang per buck," though--and again, this from
somebody who doesn't use computers in a soley-business setting--I'm
afraid that VMS just isn't all that cost-effective.
> 4. What do you think are the strengths of VMS that would make it an
>attractive alternative to someone who is used to Unix? To MS-DOS?
IMO, people who use DOS (or Windows, or Macs) are almost never going
to dispense of the availablility of cheap software and user-friendliness
they now enjoy. Why appreciate the "innards" of a computer system, and
how they function (vital for administrating a unix or VMS system) when you
can simply point at an icon, click, and just reset the machine if anything
goes wrong. As command lines are phased out for mainstream users, the
fact that powerful command-line commands for unix and VMS will become
less relevant. I suppose the best way to get people to use VAX systems
more would be to make a few good GUI-based, high-quality word-processing
programs or something.
> 5. If the big objection to VMS is that it is proprietary, why don't we
>hear such complaints about MS-DOS and Windows?
We should! :-) I hear quite a number of complaints from people who
are a bit better-educated in the computing realm. I personally think the
only reason is because many people don't know any better. Nothing negative,
just the side-effect of a growing computer-using populace.
> ......
> 7. How can DEC make VMS attractive to the nation's computer science
>departments?
Of the three colleges I've been exposed to, all of them used VAX machines
for classes. Lansing Community College uses a VAX for their CPS-100 class,
and Central Mich uses an 8530 for their CPS-210, a low-level programming
class required as a prerequisite to almost everything. Univ of Dayton used
theirs for FORTRAN classes.
> .......
> 11. What market should VMS serve?
Personally, I think they should continue with the open systems
mini/workstation arena, and maybe consider doing something more
with high end PC-compatibles... that seems to be where the market is
headed. If only they made VMS for PCs... ;-) (heck, I'd buy it!)
Hope that didn't take *too* long to read ;-)
-- Patrick
Bruce Salem
some administrativia that I recall about opening data files under DEC-
FORTRAN, which was/is a very good F77 with extensions, data structures.
It was that you had to open files with some modes from some package called
RMS. It was a royal pain to have to plead with the OS to open an ascii
file under some rules for dealing with the format of the data in the
file. I think that UNIX's notion is vastly superior than dealing with
files with physical blocksizes that you had to obey when you open and
read and then write files. This must be a throwback to OS/JCL which I
also once had exposure to. It is brain-dead.
Bruce Salem
Mark Hittinger
>In article <1994Feb26....@mixcom.mixcom.com>,
>Craig Dedo <Craig...@mixcom.mixcom.com> wrote:
>> This week a software engineer told me that VMS is a dying operating
>>system.
I said live it or live with it! :-)
Once you loose credibility you cannot regain it so easily. Once the market
has decided it doesn't like your strategy you are in trouble. VMS is in
trouble. IBM is in trouble. Unix is in trouble. Everybody seems to be
waiting for Bill to finally save the day.
The real - true - pentultimate question is "Just how long will the market
wait for Bill?"
---------
I'd like a 250 Mhz 128 bit hybrid processor with 64 meg of 8 way interleaved
memory, a 10 megabyte per second i/o channel, two 3 gig hard disks, two dat
drives with compression, and a large diet coke.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.3a
mQCNAiz4FWMAAAEEALBCb7HZS7V4gbsp9yJ7Yty49jQ9wcgRhkLjNNgdyJbrJZCq
5/sv4Ljy/4AhVhjlJyZS8L3owS8l0ClZVzWw4/kO3KN7MPz4YPPR7+qIlPQVM0yv
gWpJ43EZZ8b8cvAkE9HATCKWktY2ReRSX5DLnScDH/n5jivw+MD/UO8fURCVAAUR
tCBNYXJrIEhpdHRpbmdlciA8YnVnc0BuZXRzeXMuY29tPg==
=VbKi
-----END PGP PUBLIC KEY BLOCK-----
Carl J Lydick
=> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
=> there that this is not the case?
=
=Yes, and the general trend of using PCs where people may have used minis
=or mainframes.
Actually, according to an article in the Business section of the _Los Angeles
Times_ about two weeks ago, minis are making a comeback.
=> 9. Does VMS have features that are not found or are not nearly as well
=> developed in competing operating systems? If so, what are they?
=
=It has a built in Batch Scheduler, it has the working set model of memory
=etc etc . Its all pros and cons like most comparisons of this sort.
That's the most pathetic attempt to sound "deep" while saying absolutely
nothing that I've heard from anybody except a politician or Scott Erb in the
last decade.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My
understanding of astronomy is purely at the amateur level (or below). So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it. If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Carl J Lydick
= 6. Should DEC consider franchising VMS to independent software
= developers (ISVs) who could add their own enhancements, the way
= Microsoft has done with MS-DOS or McDonald's has done with their
= restaurants? Would this answer the objection that VMS is proprietary
= while Unix is not?
=
=Actually, DEC has announced that you *can* license VMS in order to port it to
=your own hardware. I don't think anyone's taken them up on it, and I expect
=that they've never really seriously expected that anyone would - so I doubt
=they've ever worked out the mechanisms. Anyone think there'd be a market for
=VMS on 486's and Pentium's?
I personally know half a dozen people who'd be interested in buying such a
system (OK, I'm one of them, so in the interest of objectivity, make that 5).
Carl J Lydick
=>>Craig T. Dedo
=>J.C. Higgins:
=David L. Cathey:
= Security. Internetworking (TCP/IP, OSI, LanMan, Novell,
= XNS, X.25 and all CONCURRENTLY!). Robust O/S (doesn't "panic"
= often (UNIX) or have odd memory lockups (MS-DOS); have known
= systems to run over a year without rebooting!).
=
=Interesting. UMUC moved me off of the VMS platform I was on, and onto
=Unix, because of problems I was having with the TCP/IP implementation.
Which implentation was that? UCX, at a guess? Or equally bad, WIN? If it was
either of those, you could've saved yourself some money and switched to CMUIP,
which is free, and better than either of the above.
=
=I don't know what this would solve. Every college I've been to has
=had both vms and unix [and some ibm os, such as cms] available for
=student use [and dos and macintoshes and nexts]. For some reason, the
=unix systems have been more pleasant to use [you can have a larger
=storage quota, you can run more processes, etc...].
Have you ever encountered the term "circular argument"? I didn't think so;
otherwise you'd've realized that that what you made above.
= >> 9. Does VMS have features that are not found or are not nearly
= >>as well developed in competing operating systems? If so, what
= >>are they?
= > File ACLs, Accounting, Resource control......
= ACL's on everything, Process Class scheduling (V6.0), file
= structures, I/O through the command language, VMSclusters,
= locking ($ENQ), logicals names, ...
=
=Which might be why VMS systems are so hard for a person to use --
=there's all this administrative bullshit you have to go through to get
=permission to use the system. Better to use a system that relies on
=social mechanisms than one which relies on red tape.
VMS does *NOT* rely on red tape. If the folks who own the system want to do it
that way, they can; if they don't, they don't have to. You're blaming the O/S
for local political problems. Of course, the other idiocies you've committed
make it unsurprising that you'd fuck up on this, too.
=Micro-management is not necessarily better management.
No, it's not. And VMS doesn't require it. However, NO management is not
necessarily good management. And many Unix implementations *DO* require that.
Your claim amounts to: Flexibility is evil. Of course, I don't expect you to
understand that.
Carl J Lydick
=>> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
=>>there that this is not the case?
=>Unix seems to be the choice of universities, so graduates don't know "VMS".
=>On the other hand, most of the businesses that I know that want a reliable
=>system go VMS, and VMS only.
=
= Why is that?
As to the former: Because at one poin AT&T's Bell Labs gave away the sources
to Unix to any university at no charge. Can you say "loss leader"? I knew you
could. As to the latter: Because Unix has an architecture that makes any sort
of security nearly impossible to implement.
=When you buy a propriety OS, the upside is support.
Give me a break. When you buy ANY OS that somebody asks you to pay money for,
you get support. Or you're as much an idiot as Bruce Salem.
= But how fast does DEC add a bug fix or a requested feature? ON a
=UNIX system, a system programmer could write a new feature, and many can
=be implemented in shell scripts.
The same is true of VMS. You'd be a lot more convincing if you had even a clue
as to what you were talking about.
=Maybe the problem is that many Sys Admins
=are too busy putting out fires than having the time to sitdown and write
=code for a solution, and how many of them really can write applications
=in the first place? VMS does have some better performance and robustness
=features than UNIX;
Yeah. It has easily configurable security; fewer security bugs than Solaris by
a couple of orders of magnitude, lots fewer panics than your average Unix
system...
=>> 4. What do you think are the strengths of VMS that would make it an
=>>attractive alternative to someone who is used to Unix? To MS-DOS?
=>People on Unix who want to get more out of the machine than just compliation,
=>people who want security and control over their systems should realise that VMS
=>has all the controls necessary.
=
= I have never administered VMS, but as a user
Ah! That explains why you confuse limitations of the OS and local policies.
Hey shit-for-brains: VMS has a lot of flexibility. That means that your local
system manager can make things extremely difficult for you, if he so chooses;
it also means that he can tailor the system security to meet your needs.
=Many of the VMS commands are brain dead. Compare set-default with cd,
OK. I compsred them. SET DEFAULT comes out a clear winner, in my opinion.
Perhaps, rather than simply spouting bullshit, you'd care to substantiate your
claims? What do you think everybody's going to agree is wrong with SET
DEFAULT?
=or search with grep.
Hmmm. The jackass never heard of DECUS, it seems. Hey, shit-for-brains:
There are versions of grep available for VMS. Free. I guess you're such an
expert you didn't know that, right?
=Beside the fact that you would need an awk program to
=strip out all the boiler plate from search output, it dodn't handle
=limited regular expressions.
Hey, moron: AWK is also available for VMS. Next time you post, try to post
on some subject with which you have even a minimal clue!
=If DEC wanted to keep its foot in both
=markets it should affer UNIX commands as part of VMS, legal issues asside.
Legal issues play no part: The commands ARE available; they're not a part of
VMS as shipped, but you can get them at no extra charge. Unless you're a
totally clueless jackass. Before you complain about the tone of my post,
please remember, many people consider it to be a major breach of etiquette to
represent yourself as an authority when you're as clueless as is Bruce.
Carl J Lydick
Salem) demonstrates the depths of his cluelessness:
= One follow on to my earlier remarks about VMS was that there was
=some administrativia that I recall about opening data files under DEC-
=FORTRAN, which was/is a very good F77 with extensions, data structures.
=It was that you had to open files with some modes from some package called
=RMS.
Package? It's a part of the OS.
=It was a royal pain to have to plead with the OS to open an ascii
=file under some rules for dealing with the format of the data in the
=file.
Examples? I didn't think so. You're engaging in a variation of Argumentum ad
Ignorantiam: Since you're clueless, you're right, right?
=I think that UNIX's notion is vastly superior
OK, shit-for-brains. Let's examine your claim. Suppose you've got a binary
file that's got records of varying length. I.e., ANY character can appear in
ANY record. Not all records are the same length. How do you tell, under UNIX,
where a record ends? Answer: You write your own version of a subset of RMS to
run under Unix. Second question: If you want a file that obeys Unix'
deficient semantics, how do you do it under VMS? Answer: Ask RMS to create a
stream file.
Hmmm. You can get Unix behavior under VMS, but you can't get VMS behavior
under Unix without writing your own I/O library. Which is superior?
=than dealing with
=files with physical blocksizes that you had to obey when you open and
=read and then write files. This must be a throwback to OS/JCL which I
=also once had exposure to. It is brain-dead.
No, it's a feature that isn't supported by Unix.
Benjamin Ketcham
Carl J Lydick <ca...@SOL1.GPS.CALTECH.EDU> wrote:
[a bunch of stuff that made him look like a drunken fool, and made VMS
look worse, not better, for all his effort]
Congratulations on becoming my first killfile entry for this
newsgroup (comp.unix.advocacy, that is). Unfortunate, because
for all I know, VMS probably does really have some merits worth
considering. Oh, well. Doesn't run on anything I can afford,
anyway.
*plonk*
--ben
Raul Deluth Miller
. Which implentation was that? UCX, at a guess? Or equally bad,
. WIN? If it was either of those, you could've saved yourself some
. money and switched to CMUIP, which is free, and better than either
. of the above.
I haven't a clue what those stand for. Nor could I have saved myself
any money -- I was a *user*, not an *administrator*.
I think one implementation was from Wollogong [sp?]. [There was an
upgrade before I moved to another system.]
. =I don't know what this would solve. Every college I've been to
. =has had both vms and unix [and some ibm os, such as cms] available
. =for student use [and dos and macintoshes and nexts]. For some
. =reason, the unix systems have been more pleasant to use [you can
. =have a larger storage quota, you can run more processes, etc...].
. Have you ever encountered the term "circular argument"? I didn't
. think so; otherwise you'd've realized that that what you made
. above.
Really? At one school there were a lot of vms resources lying around
unused [several idle machines, even].
. = >> 9. Does VMS have features that are not found or are not
. = >>nearly as well developed in competing operating systems? If
. = >>so, what are they?
. = > File ACLs, Accounting, Resource control......
. = ACL's on everything, Process Class scheduling (V6.0), file
. = structures, I/O through the command language, VMSclusters,
. = locking ($ENQ), logicals names, ...
. =
. =Which might be why VMS systems are so hard for a person to use --
. =there's all this administrative bullshit you have to go through to
. =get permission to use the system. Better to use a system that
. =relies on social mechanisms than one which relies on red tape.
. VMS does *NOT* rely on red tape. If the folks who own the system
. want to do it that way, they can; if they don't, they don't have
. to. You're blaming the O/S for local political problems. Of
. course, the other idiocies you've committed make it unsurprising
. that you'd fuck up on this, too.
I've run across hostile system administrators on both vms and unix
systems. They seem to have a more pervasive effect on vms systems.
. =Micro-management is not necessarily better management.
. No, it's not. And VMS doesn't require it. However, NO management
. is not necessarily good management. And many Unix implementations
. *DO* require that. Your claim amounts to: Flexibility is evil. Of
. course, I don't expect you to understand that.
You mean you're not trying to communicate with me, you're just trying
to make me look bad?
Raul D. Miller
<rock...@nova.umd.edu>
John Macallister
Look at the facts and make up your own mind!
VMS is available from only one manufacturer.
The hardware (VAX and Alpha) on which VMS runs is available from only one
manufacturer.
VMS doesn't run on PCs.
It's fairly clear that the future lies with personal computers. It's
also clear the people will want to be able to shop around for software
and hardware.
John
+-------------------+
| ( ) ( ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name : John B. Macallister |
| Postal address : Nuclear Physics Laboratory, Keble Road, Oxford OX1 3RH, UK.|
| Telephone : +44-865-273388 (direct) +44-865-273333 (tel reception) |
| Telex/Fax : Telex: 83295 NUCLOX G Fax: +44-865-273418 |
| INTERNET : J.Macal...@physics.oxford.ac.uk (GUEN) !
! : GUEN = Guaranteed Unique E-mail Name !
| INTERNET (alt) : maca...@v1.ph.ox.ac.uk ( 129.67.1.100 ) !
| HEPNET/SPAN : OXPHV1::MACALLSTR (Node 19.151) !
| UK JANET : MACA...@UK.AC.OX.PH.V1 (DTE:000050250050, |
| : IXI:204334505210) |
| UUCP/USENET : MACALLSTR@oxphv1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kent Covert
> February 26, 1994
>
> This week a software engineer told me that VMS is a dying operating
> system. I would like to know what the readers of this forum think. I have
> some thoughts on this issue, but first I would like to see what other
> people think. Some of the following questions involve business rather than
> technical issues. Some people may feel that discussing business issues is
> inappropriate in a technical forum. However, the future of a technical
> product like VMS depends heavily on BOTH.
>
> Please consider the following questions, as well as any related matters.
> there that this is not the case?
At DECUS, DEC announced that $500M of their 1992-93 OpenVMS revenue was from
companies who had never puchased OpenVMS in the past.
> 3. Does VMS provide enough bang for the buck? How does it compare to
> the competition in this area?
It depends on what you're doing, but if you check out the SpecFPs for
OpenVMS, you'll find that it out performs OSF/1 (just slightly, though).
It definitely outperforms OSF/1 when it comes to SMP since (last time I
checked) it isn't available yet.
> 5. If the big objection to VMS is that it is proprietary, why don't we
>hear such complaints about MS-DOS and Windows?
The term "proprietary" is the most overused and useless complaint I've
ever heard about an operating system. I like proprietary OSs. That's why
I use a Mac and why I use OpenVMS. They have a definite direction. Sure
you can get the source code for Unix, but why? If you start writing code
that depends on the code within the operating system you lose the ability
to alter the OS later. I know lots of people who have written code that
depends on the structures with in Unix. When asked what they'll do if that
structure changes in a future release, they'll don't have a good response.
An example of this is with OSI. Who is going to implement OSI in Unix if
it catches on? DEC, IBM, Sun, HP, etc. Are any of the implementations
going to work together? Probably not since there is no guiding direction.
I'd say as long as an OS is well-documented and is flexible in it's APIs,
that the proprietary nature is a benefit, not a hinderance.
> 9. Does VMS have features that are not found or are not nearly as well
> developed in competing operating systems? If so, what are they?
Clusters! Indexed files (not available in standard Unix, and a really bad
hack in VM/CMS). Standard calling interface (I can call any API from any
language). One, and only one, debugger.
> 12. Should DEC develop a standard GUI interface to VMS, such as
> Microsoft Windows or X-Windows?
They have. It's called DecWindows Motif and is based on X-Windows (which
was/is jointed developed by DEC and MIT).
--
Kent Covert, Software Coordinator
Miami Computing and Information Services
Miami University, Oxford, OH
kaco...@miavx1.acs.muohio.edu (internet)
kacovert@miavx1 (bitnet)
Carlie Coats
> February 26, 1994
>
> This week a software engineer told me that VMS is a dying operating
>system. I would like to know what the readers of this forum think. I have
>some thoughts on this issue, but first I would like to see what other
>people think. Some of the following questions involve business rather than
>technical issues. Some people may feel that discussing business issues is
>inappropriate in a technical forum. However, the future of a technical
>product like VMS depends heavily on BOTH.
>
> Please consider the following questions, as well as any related matters.
> 9. Does VMS have features that are not found or are not nearly as well
>developed in competing operating systems? If so, what are they?
>
VMS is systematic in its interpretation of the environment (i.e., logical
names); under UN*X it is the responsibility of the application program to
interpret the environment; as a consequence, the apps don't. By the way,
since each VMS logical can be a complete path, VMS logicals are *much* more
powerful than UN*X environment variables. (On the other hand, UN*X apps
expect the system to have interpreted wild cards already, whereas VMS apps
have to do it for themselves.) (What is the status of NT on this issue??)
(This one is astounding, considering how UN*X file systems work:) VMS
(and most VMS apps) provides stream semantics for the keyboard and screen,
while UN*X (or, more precisely, the apps) has the Berzerkeleyism that apps
flush stdin after every change in state, and *only then* will accept input.
The consequence is that users have to supervise apps in real time, on the
basis of (frequently incomplete, due to network and system delays) what shows
up on-screen. For a typical example, suppose that "foo.dat" is a large text
file. The sequence
eve foo.dat <ret>
<"bottom" key><ret>
<"previous screen" key><ret>
<"previous screen" key><ret>
does exactly what you wish: the machine understands the stream of commands,
and does them in sequence as desired. If one attempts the "vi" equivalent,
in the process of executing the first line, the system destroys the second,
third, and fourth because it insists upon flushing stdin after a change of
state. The VMS downside is that I wish the designers had put in larger
typeahead buffers than the current 512 bytes (say, 4K, at least).
(This one is opinion:) IMHO, VMS documentation is both more complete and
more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
the other hand, it *does* cost an arm and a leg.
(This one is opinion:) IMHO, VMS handles recursive directory tree traversals
(e.g., "dir [foo...]bar.*") cleanly, whereas in UN*X one must invoke some
arcane something or other built using the "find" command. On the other hand,
VMS device-directory-file syntax is less regular than the UN*X equivalent.
(This one is opinion :-):) EVE/TPU are a nicer customizable editing system
than either vi or emacs. For that matter, the stuff I've built on top of
EVE is nicer for what I need to do (environmental modeling: mixed Fortran/C
development and maintenance) than LSE, either (with which it is difficult to
integrate one's own customizations because of the inadequate documentation.)
[...more stuff omitted, in the interests of net.bandwidth]
>Sincerely,
>--
>Craig T. Dedo Craig...@mixcom.com
>17130 W. Burleigh Place (414) 783-5869
>Brookfield, WI 53005
Carlie J. Coats, Jr. co...@cardinal.ncsc.org
Environmental Programs phone: (919)248-9241
North Carolina Supercomputing Center fax: (919)248-9245
3021 Cornwallis Road P. O. Box 12889
Research Triangle Park, N. C. 27709-2889 USA
"My opinions are my own, and I've got *lots* of them!"
DARRYL T. VICKERS - SCSI
> Is VMS on the way out?
> Look at the facts and make up your own mind!
>
> VMS is available from only one manufacturer.
> The hardware (VAX and Alpha) on which VMS runs is available from only one
> manufacturer.
> VMS doesn't run on PCs.
Windows NT. what more could you want?
>
> It's fairly clear that the future lies with personal computers. It's
many large mainframe systems (IBM, Amdal) we are also rightsizing
many poorly planed downsizing efforts using VAX/VMS systems as a key
part of the solutions(lets face it PC's are great in some areas but
fall short in many real world bussiness implementations).
> also clear the people will want to be able to shop around for software
> and hardware.
and thats what keeps us in business. people makeing the actual
buying decisions dont allways know or care much about OS or hardware
they just want a final product that meets thier requirments and can
be counted on to provide reliable service.
>
> John
>
>
Darryl Vickers | dvic...@sadis05.kelly.af.mil
Systems Software Specialist | dvic...@kellymdss.af.mil
Metrica Inc. S A, Tx | tpd...@prodigy.com
All opinions expressed are my own and do not reflect those of my
employer or clients of my employer.....
Casper H.S. Dik
> eve foo.dat <ret>
> <"bottom" key><ret>
> <"previous screen" key><ret>
> <"previous screen" key><ret>
>does exactly what you wish: the machine understands the stream of commands,
>and does them in sequence as desired. If one attempts the "vi" equivalent,
>in the process of executing the first line, the system destroys the second,
>third, and fourth because it insists upon flushing stdin after a change of
>state. The VMS downside is that I wish the designers had put in larger
>typeahead buffers than the current 512 bytes (say, 4K, at least).
It works this way on Unix systems too. What broken Unix system have
you been using?
>(This one is opinion:) IMHO, VMS documentation is both more complete and
>more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
>the other hand, it *does* cost an arm and a leg.
And shelve space. Unix documentation is getting much better and is
delivered in hypertext browsable format on an increasing number of
systems. You can't do that with documentation on a shelve.
>(This one is opinion:) IMHO, VMS handles recursive directory tree traversals
>(e.g., "dir [foo...]bar.*") cleanly, whereas in UN*X one must invoke some
>arcane something or other built using the "find" command. On the other hand,
>VMS device-directory-file syntax is less regular than the UN*X equivalent.
This is not so much a VMS vs UNIX thing, but a shell thing.
Some shells can expand constructs like this. But the big difference
between VMS and Unix here is the fact that in Unix the wildcards are
expanded by the shell. In Unix you need enough memory to hold
all files matched. In VMS the program only needs to store one filename
at the time. That's probably why Unix shells don't like to do this,
though some do.
>(This one is opinion :-):) EVE/TPU are a nicer customizable editing system
>than either vi or emacs. For that matter, the stuff I've built on top of
>EVE is nicer for what I need to do (environmental modeling: mixed Fortran/C
>development and maintenance) than LSE, either (with which it is difficult to
>integrate one's own customizations because of the inadequate documentation.)
Except that it only works on DEC vtxxx termninals.
Casper
Johnny Billquist
>co...@cardinal.ncsc.org (Carlie Coats) writes:
>> eve foo.dat <ret>
>> <"bottom" key><ret>
>> <"previous screen" key><ret>
>> <"previous screen" key><ret>
>>does exactly what you wish: the machine understands the stream of commands,
>>and does them in sequence as desired. If one attempts the "vi" equivalent,
>>in the process of executing the first line, the system destroys the second,
>>third, and fourth because it insists upon flushing stdin after a change of
>>state. The VMS downside is that I wish the designers had put in larger
>>typeahead buffers than the current 512 bytes (say, 4K, at least).
>It works this way on Unix systems too. What broken Unix system have
>you been using?
Actually, it don't work in all cases under Unix.
If you change mode of your tty your typeahead gets flushed.
So, before doing it, you better preserve the typeahead buffer
yourself, or you'll loose it.
That's the way the tty driver works, so unless you want to
dig real deep, you'll have to live with that behaviour.
>>(This one is opinion:) IMHO, VMS documentation is both more complete and
>>more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
>>the other hand, it *does* cost an arm and a leg.
>And shelve space. Unix documentation is getting much better and is
>delivered in hypertext browsable format on an increasing number of
>systems. You can't do that with documentation on a shelve.
Undeniably, it takes shelf space.
But in my optinion, paper documentation is still the best there is.
I can put small clips where I want to, have several manuals opened
at the same time, and work with my project on the screen.
It takes physical space, but if I have that, it's much better
than online stuff.
(Good manuals have good indexes...)
>>(This one is opinion:) IMHO, VMS handles recursive directory tree traversals
>>(e.g., "dir [foo...]bar.*") cleanly, whereas in UN*X one must invoke some
>>arcane something or other built using the "find" command. On the other hand,
>>VMS device-directory-file syntax is less regular than the UN*X equivalent.
>This is not so much a VMS vs UNIX thing, but a shell thing.
Actually, it *is* a VMS vs. Unix thing.
VMS provides support for filename wildcarding, Unix don't.
Some Unix shells have a workaround for the lack of the feature in
Unix by expanding wildcards themself, before calling the program.
However, this is not a good solution. It can be lived with, but
it isn't very good.
>Some shells can expand constructs like this. But the big difference
>between VMS and Unix here is the fact that in Unix the wildcards are
>expanded by the shell. In Unix you need enough memory to hold
>all files matched. In VMS the program only needs to store one filename
>at the time. That's probably why Unix shells don't like to do this,
>though some do.
Unix have no idea what a wildcard filename is, while VMS do.
That's the difference. Since many want to use wildcards in
filenames, shells have been developed which provides you with this
sort of.
>>(This one is opinion :-):) EVE/TPU are a nicer customizable editing system
>>than either vi or emacs. For that matter, the stuff I've built on top of
>>EVE is nicer for what I need to do (environmental modeling: mixed Fortran/C
>>development and maintenance) than LSE, either (with which it is difficult to
>>integrate one's own customizations because of the inadequate documentation.)
>Except that it only works on DEC vtxxx termninals.
Don't EVE/TPU use SMG$? (Or has SMG$ been obsoleted?)
Johnny
--
Johnny Billquist || "I'm on a bus
CS student at Uppsala University || on a psychedelic trip
email: b...@minsk.docs.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
David Gay
In article <2kt229$e...@Krille.Update.UU.SE> b...@Krille.Update.UU.SE (Johnny Billquist) writes:
In <2ksvt2$g...@mail.fwi.uva.nl> cas...@fwi.uva.nl (Casper H.S. Dik) writes:
VMS provides support for filename wildcarding, Unix don't.
Some Unix shells have a workaround for the lack of the feature in
Unix by expanding wildcards themself, before calling the program.
However, this is not a good solution. It can be lived with, but
it isn't very good.
>[...]
Unix have no idea what a wildcard filename is, while VMS do.
That's the difference. Since many want to use wildcards in
filenames, shells have been developed which provides you with this
sort of.
Strange, I was under the impression that /bin/sh had been around for a
rather long time... It must also be a complete coincidence that most
(99%?) of Unix utilities will operate on a list of filenames separated
by spaces and that all shells expand wildcards by replacing them by a
list of space separated filenames ?
David Gay
dg...@di.epfl.ch
Steve McKinty - SunConnect ICNC
f
> >state. The VMS downside is that I wish the designers had put in larger
> >typeahead buffers than the current 512 bytes (say, 4K, at least).
Minor point. Set your terminal to use the alternate typeahead buffer,
its somewhere around 8K by default, and you can make it (and the main
one) pretty much as large as you want.
> >(This one is opinion:) IMHO, VMS documentation is both more complete and
> >more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
> >the other hand, it *does* cost an arm and a leg.
>
> And shelve space. Unix documentation is getting much better and is
> delivered in hypertext browsable format on an increasing number of
> systems. You can't do that with documentation on a shelve.
VMS docs have been available on CD for a long time. I'm pretty sure I
saw a CD of VMS docs before I saw a Sun answerbook (OK, it was also
before I started to work for Sun :-) )
Steve
--
Steve McKinty
Sun Microsystems ICNC
38240 Meylan, France
email: smck...@france.sun.com
Michael Meissner
| In article <2kriu4$3...@morrow.stanford.edu>, sa...@pangea.Stanford.EDU (Bruce Salem) writes:
| =>> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
| =>>there that this is not the case?
| =>Unix seems to be the choice of universities, so graduates don't know "VMS".
| =>On the other hand, most of the businesses that I know that want a reliable
| =>system go VMS, and VMS only.
| =
| = Why is that?
|
| As to the former: Because at one poin AT&T's Bell Labs gave away the sources
| to Unix to any university at no charge. Can you say "loss leader"? I knew you
| could. As to the latter: Because Unix has an architecture that makes any sort
| of security nearly impossible to implement.
Actually, to be more correct, can you say "consent decree". Until Judge Green
signed the order breaking apart AT&T into the regional bell operating companies
(RBOC's) and the long distance company (AT&T), AT&T was forbidden from entering
the computer market by a consent decree that they had signed in the 1960's.
Because of that, what was released had to be pretty much at cost. Since UNIX
was released in the late sixties, it fell under these terms. Snobol also fell
under similar constraints and terms.
--
Michael Meissner email: meis...@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Old hackers never die, their bugs just increase.
Ramon L. Tate
>Is VMS on the way out?
>Look at the facts and make up your own mind!
>
>VMS is available from only one manufacturer.
>The hardware (VAX and Alpha) on which VMS runs is available from only one
> manufacturer.
>VMS doesn't run on PCs.
>
>It's fairly clear that the future lies with personal computers. It's
> also clear the people will want to be able to shop around for software
> and hardware.
It seems to me there are several issues here that need addressed:
(1) The "personal computer" is just that ONLY for those individuals who rise
to the challenge of mastery of its hardware and software to the
point that their reliance on other supporting parties is minimal. This
is usually NOT the case, especially in corporate environments, hence the
existence of "Support Groups" or what have you to install, update, fix, etc.
the hardware and software for the user. Such *usage* IS personal (for my
exclusive use) but it takes a lot of other people to make it useful to me.
(2) The physical differences between "mainframe" and "personal" computers have
all but vanished. Is my DEC 3000-400 a mainframe (it certainly performs
like one!) or a personal computer (it's a nice one-seat workstation package
with a 2-user license)?
(3) It's the COMBINATION of hardware and software that define the functionality
of ANY computer. For example, the PDP-11 runs UN*X, but who really wants
to live with those hardware limitations anymore? The basic principle that
*I* learned about this was that BOTH have to support the intended use. Sure,
I can run Linux on my 386SX-16, but it wouldn't be fun nor would it be
suitable for an on-line transaction processing system or for the control
of a rolling mill in a steel plant.
The original IBM Personal Computer, which has defined the present state of
"personal computing", was a very limited scope, even crippled hardware
platform that used a simplistic, limited software design. Consequently, an
enormous amount of effort has been necessary to expand the utility of
successor systems beyond this original scope, and even then we are still stuck
with the limitations dictated by backwards compatibility issues.
So what about VMS in all this? Reminds me of a recent discussion about I/O
performance, etc. on comp.arch.storage in which the contributor made the
point that they had yet to see a truly mainframe-class implementation of
UN*X come down the pike, one that could go head-to-head with ALL of the
requisite functionality of current mainframe systems (and he set forth a
long list of these requirements). The same thing can be said - at the moment -
about WinNT, I believe, although there is more hope in that direction. VMS
was *designed* to a standard of functionality that supports a much broader
range of computing activities that UN*X, mostly because the development of
UN*X wasn't carried out on the same scale and with the coherent vision that
VMS was. Consequently, VMS will be more suited to areas of functionality that
could only be achieved by a total redesign of DOS, MSWindows, or UN*X. The
jury is still out on NT - there, at least, there seems to have been a better
vision of current and future functional needs active in the design process.
>
>John
>
>
> +-------------------+
> | ( ) ( ) |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>| Name : John B. Macallister |
>| Postal address : Nuclear Physics Laboratory, Keble Road, Oxford OX1 3RH, UK.|
>| Telephone : +44-865-273388 (direct) +44-865-273333 (tel reception) |
>| Telex/Fax : Telex: 83295 NUCLOX G Fax: +44-865-273418 |
>| INTERNET : J.Macal...@physics.oxford.ac.uk (GUEN) !
>! : GUEN = Guaranteed Unique E-mail Name !
>| INTERNET (alt) : maca...@v1.ph.ox.ac.uk ( 129.67.1.100 ) !
>| HEPNET/SPAN : OXPHV1::MACALLSTR (Node 19.151) !
>| UK JANET : MACA...@UK.AC.OX.PH.V1 (DTE:000050250050, |
>| : IXI:204334505210) |
>| UUCP/USENET : MACALLSTR@oxphv1 |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
---------------------------------------------------------------------------
Ramon L. Tate (ta...@faxcsl.dcrt.nih.gov) | "But no, I was out for stars:
Division of Computer | I would not come in.
Research and Technology | I meant not even if asked,
National Institutes of Health | And I hadn't been."
Bethesda, MD 20892 | - Robert Frost
xmd...@fs2.dp7up.com
<Craig...@mixcom.mixcom.com> writes:
> February 26, 1994
>
> This week a software engineer told me that VMS is a dying operating
>system. I would like to know what the readers of this forum think. I
have
>some thoughts on this issue, but first I would like to see what other
>people think. Some of the following questions involve business rather
than
>technical issues. Some people may feel that discussing business issues
is
>inappropriate in a technical forum. However, the future of a technical
>product like VMS depends heavily on BOTH.
>
> Please consider the following questions, as well as any related
matters.
This is my opinion only...
> 1. Does VMS have much of a future?
>
Unknown -- we're a bit worried. DEC seems to be pushing it a bit less
these days.
> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
>there that this is not the case?
>
That and (in the future, probably) Windows NT (and to some degree Windows
itself).
> 3. Does VMS provide enough bang for the buck? How does it compare to
>the competition in this area?
>
With Alpha -- yes. VMS provides more functionality within the operating
systemthan does Unix (for example RMS) so while it has more overhead
than, say, Unix, applications have to handle less (or intermediate
software). Unix's big success came from being able to run on RISC
processors, and now VMS can say the same.
> 4. What do you think are the strengths of VMS that would make it an
>attractive alternative to someone who is used to Unix? To MS-DOS?
>
I think that VMS' strength is in its handling of large *production*
systems. We, in fact, are moving our smaller systems to Unix and
Windows. VMS is still one of the best for managing large systems.
> 5. If the big objection to VMS is that it isproprietary, why don't we
>hear such complaints about MS-DOS and Windows?
>
Better marketing...
> 6. Should DEC consider franchising VMS to independent software
>developers (ISVs) who could add their own enhancements, the way Microsoft
>has done with MS-DOS or McDonald's has done with their restaurants?
Would
>this answer the objection that VMS is proprietary while Unixis not?
>
I have heard rumors that DEC will do exactly this. Don't know if it will
help. Unix supporters will always finda reason to hate VMS it seems.
Take one away and they'll make up another.
> 7. How can DEC make VMS attractive to the nation's computer science
>departments?
>
They used to do this by giving *hugh* discounts for academic use. I
don't know if theystill do. Their reasoning was that as students
entered the business world they would stick with what they know.
> 8. How can DEC make VMS attractive to software developers?
>
> 9. Does VMS have features that are not found or are not nearly as well
>developed in competing operating systems? If so, what are they?
>
Yes, clusters are still very new to other vendors. Those that claim to
have it don't have all of the functionality. Many operating systems
don't provide advanced file functions atthe operating system level (like
RMS indexed files). VMS includes alot of 'extras' that other vendors
would charge for (like Rdb runtime, monitor, etc.). VMS has a pretty
good batch subsystem. There are many system management packages
available from both DEC and third parties (like SLS) making it well
suited for large data centers. Some operating systems don't even come
with a sort utility (vms does).
> 10. Are these features (which are better developed in VMS) very much
>appreciated by the people who actually make the operating system
selection
>decisions? If not, why not?
>
It depends on who is making the decision -- is it an executive or people
who actually develope on the system (different companies would have
different answers to this).
> 11. What market should VMS serve?
>
I think it's forte is production business systems. Scientific systems
are probably better suited to Unix.
> 12. Should DEC develop a standard GUI interface to VMS, such as
>Microsoft Windows or X-Windows?
>
Motif -- already there (or did I misunderstand).
Alan Greig
> state. The VMS downside is that I wish the designers had put in larger
> typeahead buffers than the current 512 bytes (say, 4K, at least).
This is controlled by sysgen params TTY_TYPAHDSZ and TTY_ALTYPAHD.
>
> (This one is opinion:) IMHO, VMS documentation is both more complete and
> more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
> the other hand, it *does* cost an arm and a leg.
Not if you get it on CD :-)
--
Alan Greig Janet: A.G...@uk.ac.dct
Dundee Institute of Technology Internet: A.G...@dct.ac.uk
Tel: (0382) 308810 Int +44 382 308810
-- Pavlov's dog: the runt of the litter? --
Tim Llewellyn
|>
|>co...@cardinal.ncsc.org (Carlie Coats) writes:
I have been trying REAL hard to stay out of this thread, but... :-)
[snip]
|>>(This one is opinion:) IMHO, VMS documentation is both more complete and
|>>more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
|>>the other hand, it *does* cost an arm and a leg.
|>
|>And shelve space. Unix documentation is getting much better and is
|>delivered in hypertext browsable format on an increasing number of
|>systems. You can't do that with documentation on a shelve.
|>
When was the last time you used VMS? DEC provide documentation in online
readable format. (I suspect we'll never be able to afford the VMS 6 white
wall except on CDRom). OK the format is DEC specific but they are moving to
Interleaf I believe. And now that VTBOOK
the online docs without an X-windows device. I use the Bookreader a lot.
It may be OTT to search several gigabytes of docs, but it can prove a
quicker route to the desired info than hanging around in the TOC's and
index's of a very large doc set. It is generally cheaper to get s/w and
docs on CD than other media too.
Hey I like VMS help and loathe man (havn't seen that one chewed over
this week yet)!
|>Casper
|>
--
-----------------------------------------------------+------------------+
Tim Llewellyn - OpenVMS, Soukous and Cricket Addict |Hey, and get wise |
Physicist Programmer, Bristol Uni Particle Physics. | to the sounds of |
HEPNET/SPAN 19716::TJL Internet t...@siva.bris.ac.uk | Africa,seen. |
I speak for me and noone else OK (and I might even | Soukous Makossa |
change my mind sometimes!-) | N'Dagga Mbalax..|
-----------------------------------------------------+------------------+
Daniel G. Pouzzner
this is a religious war. why don't you guys flame via personal email.
i imagine you'll find you just enjoyed seizing the (still
inappropriate) opportunity to flame eachother in view of the
whole-wide-world and compare the lengths of your- well, i don't intend
to shock :-).
so, relegate it to comp.unix.advocacy por favor?
--
-daniel (dou...@athena.mit.edu) i've been here and i've been there and
key 0B 99 0D 4F E8 55 9A 95 i've been inbetween. i talk to the wind,
print 43 C1 7F B5 DF 8F E3 33 my words are all carried away.
key: finger dou...@ai.mit.edu the wind cannot hear.
Johnny Billquist
VMS commands can also take a list of filenames.
My point was that UNIX have no idea what a wildcard is.
If you give an asterisk as a filename to Unix, it will say
thank you and yes ma'm.
/bin/sh has been around for quite some time yes. I never said
that the workaround was invented last year. But it still is
a workaround because Unix still don't support wildcards in
filenames.
There are no conincidents here, the workaround has been very
explicitly developed over a long time.
In some places, however, you will not get what you thought,
if you come from a DEC OS to unix.
Consider that you want to rename a bunch of files from
<something>.foo to <something>.bar
In VMS you say RENAME *.foo *.bar
If you try mv *.foo *.bar in unix, you'll get a nasty surprise.
mv thinks that all arguments up until the last one is a source
specification, and the last one is always a destination.
So, if you don't have any files named <something>.bar, the
last file named <something>.foo will get clobbered, otherwise
the last file named <something>.bar, which already exists
will get clobbered.
Hmm, sorry about this. Just that I can get a little excited
when I think about the lousy solution Unix offers to people
who want wildcards.
Scott Cokely
For this newsgroup? Hell, for all newsgroups. People like Carl are just
looking for fights. Who needs it?
For the nonce, VMS <-> Unix reminds me of the old PC <-> Apple war, which
was also a religious one. It comes down to what you want to do, and the
environment in which you want to do it. Some propeller-heads like DCL,
and having a million qualifiers for every command. Some propeller-heads
like to have a million little commands that we can chain together to make
a million other commands.
There will always be a Yin and a Yang. Live with it.
>*plonk*
*kerplunk* as Carl J Lydick goes *shloorp* into KILL.....
>--ben
--
| Scott Cokely | These opinions are mine, and do |
| Silicon Systems, Inc. | not represent those of SSi or TDK.|
| (714) 579-6624 | "What does the good Lord have to |
| scott....@tus.ssi1.com | say about that, eh?" -- Crooow |
Arne Henrik Juul
> . No, it's not. And VMS doesn't require it. However, NO management
> . is not necessarily good management. And many Unix implementations
> . *DO* require that. Your claim amounts to: Flexibility is evil. Of
> . course, I don't expect you to understand that.
>
> You mean you're not trying to communicate with me, you're just trying
> to make me look bad?
>
> Raul D. Miller
> <rock...@nova.umd.edu>
With friends like Carl J Lydick, VMS doesn't need enemies.
- Arne H. Juul
Gregory R. TRAVIS
In <2ksbn0$r...@gap.cco.caltech.edu> ca...@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
[About RMS]
>Package? It's a part of the OS.
Software stands between the user and the machine, Carl.
>OK, shit-for-brains. Let's examine your claim. Suppose you've got a binary
>file that's got records of varying length. I.e., ANY character can appear in
>ANY record. Not all records are the same length. How do you tell, under UNIX,
>where a record ends? Answer: You write your own version of a subset of RMS to
>run under Unix. Second question: If you want a file that obeys Unix'
>deficient semantics, how do you do it under VMS? Answer: Ask RMS to create a
>stream file.
Carl, can you post an example of this? Let's assume that the record
separator is ETX and that you're trying to fill a C structure
from each record. Please post examples in both UNIX and VMS of how
to do this.
greg
Christophe Muller
> I would like to know what the readers of this forum think. I have
> some thoughts on this issue, but first I would like to see what other
> people think. Some of the following questions involve business rather than
> technical issues.
The main interest of VMS for Digital is that they earn much more money by
solding a VMS machine than a Unix one! But unfortunately for them, this is not
what the market wants..
Is VMS dying? I don't know..
- On Alpha machines there are 9 new Unix application for 1 VMS application
- very recently Digital has sold more Unix Workstations than VMS Workstations
- OSF/1 is the best OS after SunOS 4.1.x that I have seen.. Many Berkeley
extensions, even the "ps aux" is working, good libs, good C compiler, no
strict System V hassle like in AIX, HP-UX, or (grrrr Solaris :-( ).
- There is a wonderful "SunOS to DEC OSF/1 Porting Guide" (don't forget that
1) Sun owns 60% of the workstations market, and 2) people who bought big
multi-user machines yesterday are buying workstations (200Mips..) today.)
- OSF/1 on Alpha is 64 bits, Open VMS is 32 bits.
And..
- Ultrix has not been ported to Alpha.
Conclusions? Ultrix is dead. This is for sure.. two or three more years of
maintenance and bye bye.. VMS? maybe ten more years.. it depends on the
market, not on Digital. They are ready for the future.
Windows NT? Next time.. :-)
Cheers,
Christophe.
PS: I put a Followup to a noisy group: comp.unix.advocacy, so people can have
a good time flaming me.. :-D
= NT: Not Today, Not Tomorrow! =
Steven Woodford
>In <2ksfnu$q...@news.u.washington.edu> bket...@u.washington.edu (Benjamin Ketcham) writes:
>>In article <2ksbn0$r...@gap.cco.caltech.edu>,
>>Carl J Lydick <ca...@SOL1.GPS.CALTECH.EDU> wrote:
>>[a bunch of stuff that made him look like a drunken fool, and made VMS
>>look worse, not better, for all his effort]
Agreed.
>>Congratulations on becoming my first killfile entry for this
>>newsgroup (comp.unix.advocacy, that is). Unfortunate, because
>>for all I know, VMS probably does really have some merits worth
>>considering. Oh, well. Doesn't run on anything I can afford,
>>anyway.
>For this newsgroup? Hell, for all newsgroups. People like Carl are just
>looking for fights. Who needs it?
He has the dubious honour of becoming my first _ever_ killfile entry.
Steve
Bruce Salem
>In article <2kriu4$3...@morrow.stanford.edu>, sa...@pangea.Stanford.EDU (Bruce Salem) writes:
>Or you're as much an idiot as Bruce Salem.
>Hey shit-for-brains:
[...]
>Hmmm. The jackass never heard of DECUS, it seems. Hey, shit-for-brains:
As I doubt that you would speak to me in this manner face to face,
what gives you thr right to do so here, in public? I expect your apology.
Then, if you have anything enlightening to say, I might consider answering
you. Continue with the potty mouth, child, and I will contact someone on
you domain with some power to teach you some manners.
Bruce Salem
--
!! Just my opinions, maybe not those of my sponsor. !!
Jamie Hanrahan, Kernel Mode Systems
> In article <2ksvt2$g...@mail.fwi.uva.nl>, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
> f
>> >state. The VMS downside is that I wish the designers had put in larger
>> >typeahead buffers than the current 512 bytes (say, 4K, at least).
>
> Minor point. Set your terminal to use the alternate typeahead buffer,
> its somewhere around 8K by default, and you can make it (and the main
> one) pretty much as large as you want.
Minor corrections: The standard typeahead buffer defaults to 78 bytes (not
512), and the alternate defaults to 200 (not 8K), and the system manager has to
change these. (in other words, maybe YOU can change them, Steve, but the
average user can't.)
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
uucp protocol weenie and release coordinator, VMSnet (DECUS uucp) Working Group
(and I've done a LOT of terminal driver programming as a part of that...!)
Matthew Crosby
Johnny Billquist <b...@Krille.Update.UU.SE> wrote:
>
>VMS commands can also take a list of filenames.
>My point was that UNIX have no idea what a wildcard is.
>If you give an asterisk as a filename to Unix, it will say
>thank you and yes ma'm.
>/bin/sh has been around for quite some time yes. I never said
>that the workaround was invented last year. But it still is
>a workaround because Unix still don't support wildcards in
>filenames.
>There are no conincidents here, the workaround has been very
>explicitly developed over a long time.
Its not a workaround. It was a concious design decision.
>
>In some places, however, you will not get what you thought,
>if you come from a DEC OS to unix.
>
>Consider that you want to rename a bunch of files from
><something>.foo to <something>.bar
>In VMS you say RENAME *.foo *.bar
>
>If you try mv *.foo *.bar in unix, you'll get a nasty surprise.
>mv thinks that all arguments up until the last one is a source
>specification, and the last one is always a destination.
>So, if you don't have any files named <something>.bar, the
>last file named <something>.foo will get clobbered, otherwise
>the last file named <something>.bar, which already exists
>will get clobbered.
>
>Hmm, sorry about this. Just that I can get a little excited
>when I think about the lousy solution Unix offers to people
>who want wildcards.
>
You may think its lousy. I for one think it definately is the right way
to go. The idea of Unix is that if you leave it to the shell, that lets
users decide how their wildcarding works. Say I wanted my wildcarding to
work differently--I would simply rewrite my shell. No one else would notice
anything else. IMHO, putting wildcarding in the shell is one of the best
ideas Unix came up with.
Paul Schmoelz
Is VMS dying ? Hell no, but ageing gracefully, I guess...
(Expect it to retire a few years hence, when modern & RELIABLE
operating systems are finally available)
Is Unix Dying ?
Depends on your the point of view:
unix V is definitely dead, but many look-alikes are coming forward,
having the same face, but a totally different internal structure:
(1) Novell's new unix is going to be Chorus/MiX
(2) The OSF-unixes are going to be Mach3
Same holds for Windows: Win32 is coming, and it has absolutely nothing in
common with its progenitor with the (possible) exception of its interfaces.
And look at NeXT and you will find what is very likely going to
happen to unix after being raped by those Objects ...
Looking forward to lots of flames ;-)
Servus
Paul
--
-------------------------------------------------------------------------------
So long, and thank you for the Fish ...
-------------------------------------------------------------------------------
The NeXT step calls for Spice ...
-------------------------------------------------------------------------------
Paul Schmoelz
Institut fuer Allgemeine Physik
Technische Universitaet Wien, Austria
e-mail: schm...@eapv38.tuwien.ac.at
Colin Simpson
> In article <CLwDw...@dcs.ed.ac.uk>, c...@dcs.ed.ac.uk (Colin Simpson) writes:
> => 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
> => there that this is not the case?
> =
> =Yes, and the general trend of using PCs where people may have used minis
> =or mainframes.
>
> Actually, according to an article in the Business section of the _Los Angeles
> Times_ about two weeks ago, minis are making a comeback.
>
> => 9. Does VMS have features that are not found or are not nearly as well
> => developed in competing operating systems? If so, what are they?
> =
> =It has a built in Batch Scheduler, it has the working set model of memory
> =etc etc . Its all pros and cons like most comparisons of this sort.
>
> That's the most pathetic attempt to sound "deep" while saying absolutely
> nothing that I've heard from anybody except a politician or Scott Erb in the
> last decade.
I am not some sort of self proclaimed OS philosopher that needs to
sound "deep" on an issue. I was mearly stating that as with most things
in Computing there are pros and cons to VMS compared to UNIX and
going through a list of features did not seem a valuable use of my
time. In addition, I did not see the point of starting a thread along
the lines of my system does this, oh but my system does that. That would
just be a waste of bandwidth.
So go and fix your broken telescope and leave the amateur
psychology elsewhere :)
--
Colin Simpson - c...@dcs.ed.ac.uk
*=============================================================================*
* "....it has been observed that the size of one's sig block is *
* usually inversely proportional to one's level of prestige on the net." *
* *
* --- The New Hackers Dictionary *
*=============================================================================*
Steve McKinty - SunConnect ICNC
> Minor corrections: The standard typeahead buffer defaults to 78 bytes (not
> 512), and the alternate defaults to 200 (not 8K), and the system manager
> has to
> change these. (in other words, maybe YOU can change them, Steve, but the
> average user can't.)
Thanks for the correction, its been too long. Is the alternate really
only 200? Looks like I ran with my systems set larger than that for
so long I'd forgotten!
Cheers
David L. Cathey
> Carl J Lydick:
> . WIN? If it was either of those, you could've saved yourself some
> . money and switched to CMUIP, which is free, and better than either
> . of the above.
>
> I haven't a clue what those stand for. Nor could I have saved myself
> any money -- I was a *user*, not an *administrator*.
UCX is the product name for Digital's TCP/IP offering. WIN is the
acronym for Wollogong, CMUIP is for Carnegie-Mellon University IP and is
available from the DECUS libraries for free.
> . =I don't know what this would solve. Every college I've been to
> . =has had both vms and unix [and some ibm os, such as cms] available
> . =for student use [and dos and macintoshes and nexts]. For some
> . =reason, the unix systems have been more pleasant to use [you can
> . =have a larger storage quota, you can run more processes, etc...].
This is not the fault of the O/S, but the system administration.
Where I went to school, it was the opposite. The Unix system was so
overloaded, a 100 line FORTRAN compile could take 2 hours. The larger system
was reserved for faculty and staff use, and not for students.
> Really? At one school there were a lot of vms resources lying around
> unused [several idle machines, even].
Then go for it. If you really like UNIX that much, type POSIX and
go. At least you'll have an entire machine to yourself and get your work
done in less time!
> . = >> 9. Does VMS have features that are not found or are not
> . = >>nearly as well developed in competing operating systems? If
> . = >>so, what are they?
> . = > File ACLs, Accounting, Resource control......
> . = ACL's on everything, Process Class scheduling (V6.0), file
> . = structures, I/O through the command language, VMSclusters,
> . = locking ($ENQ), logicals names, ...
> . =
> . =Which might be why VMS systems are so hard for a person to use --
> . =there's all this administrative bullshit you have to go through to
> . =get permission to use the system. Better to use a system that
> . =relies on social mechanisms than one which relies on red tape.
Get permission? Red tape? Again that sounds like system administration and
not the fault of the O/S. Besides, try to do a similar operation on a Unix
system and see how easy it is to get root access.
> I've run across hostile system administrators on both vms and unix
> systems. They seem to have a more pervasive effect on vms systems.
Again, not the fault of the O/S. What "hostility" you may see in
many cases is awareness of making the system vulnerable to outside attack.
Unix systems are generally broken into more often than VMS systems (VMS systems
when broken into are usually social-engineered or done from the inside).
> . No, it's not. And VMS doesn't require it. However, NO management
> . is not necessarily good management. And many Unix implementations
> . *DO* require that. Your claim amounts to: Flexibility is evil. Of
> . course, I don't expect you to understand that.
>
> You mean you're not trying to communicate with me, you're just trying
> to make me look bad?
Well, that's just Carl... and appearently the system admins you've
had dealings with...
> Raul D. Miller
> <rock...@nova.umd.edu>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey |INET: dav...@montagar.com
Montagar Software Concepts |UUCP: ...!montagar!davidc
P. O. Box 260772, Plano TX 75026-0772 |Fone: (214)-618-2117
Arne Vajhoej
> some thoughts on this issue, but first I would like to see what other
> people think. Some of the following questions involve business rather than
> inappropriate in a technical forum. However, the future of a technical
> product like VMS depends heavily on BOTH.
>
> Please consider the following questions, as well as any related matters.
There are a pretty large base of VMS users out there and they will not
abondon VMS this year of next year. The base itself will make sure that
VMS will continue to be used in large scale the next 5-10 years !
I doubt that VMS will have future on the desktop and that is where the
money is today. VMS would still be an excellent choice for f.ex. server.
> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
> there that this is not the case?
No. UNIX has the same problem as VMS. The desktop market is dominated by
DOS/MS-WINDOWS and the most obvious OS's replacoing them are still
WINDOWS NT and OS/2.
> 3. Does VMS provide enough bang for the buck? How does it compare to
> the competition in this area?
VMS on an AXP box gives reasonable performance/price. You can not expect
a quality product to be as cheap as a discount product.
> 4. What do you think are the strengths of VMS that would make it an
> attractive alternative to someone who is used to Unix? To MS-DOS?
The system-managers would love VMS because it is much easier to manage,
has much more features. The programmers will over time learn to love
VMS because the programming features are complex but powerfull and
systematic organized and well documented ! The users do not care
what OS they use as long they can startup WordPerfect :-(
> 5. If the big objection to VMS is that it is proprietary, why don't we
> hear such complaints about MS-DOS and Windows?
That is more a question about marketing and image, than about facts.
BTW, MS-DOS and WINDOWS is propriety, but since most private users do not
buy them but get them illegal from a friend and therefore not paying
for them, then people do not care much !
> 6. Should DEC consider franchising VMS to independent software
> developers (ISVs) who could add their own enhancements, the way Microsoft
> has done with MS-DOS or McDonald's has done with their restaurants? Would
> this answer the objection that VMS is proprietary while Unix is not?
I do not think the interest would be so great for franchising VMS !
> 7. How can DEC make VMS attractive to the nation's computer science
> departments?
Good question !
> 8. How can DEC make VMS attractive to software developers?
VMS is attractive to the software developers because of f.ex. good
compilers. The problem is, that the developers bosses prefer to
develop where the market is biggest, and that is not always VMS !
> 9. Does VMS have features that are not found or are not nearly as well
> developed in competing operating systems? If so, what are they?
The only competing OS for VMS is UNIX, since DOS etc. are targetted at
another market.
VMS is somehow a designed OS, while UNIX is more a developed OS, which
gives VMS some distinct advantages in f.ex. the security area.
What VMS misses are some of all the utilities that the end-users
often miss (unless their VMS system-managers get some of the
free software available from the net or DECUS).
> 10. Are these features (which are better developed in VMS) very much
> appreciated by the people who actually make the operating system selection
> decisions? If not, why not?
No. Decision makers often only reads fancy colour-full brochures with
commercial slogans !
> 11. What market should VMS serve?
The future is PC's and servers. I do believe VMS is suited for the
desktop, but VMS is a good choice for a server.
> 12. Should DEC develop a standard GUI interface to VMS, such as
> Microsoft Windows or X-Windows?
They have. DECWindows is X-Windows !
Arne
Arne Vajhøj local DECNET: KO::ARNE
Computer Department PSI: PSI%238310013040::ARNE
Business School of Southern Denmark Internet: AR...@KO.HHS.DK
Arne Vajhoej
> that LOOK neat -- but when I try to use them, I find only superficial
> documentation on little things like "why is this system fundamentally
> different other things like it, on other machines?"
>
> Without widely available information/examples, it's slow going on any
> machine. "Better kept secrets" aren't going to make things easier for
> the people who have to use the machine.
>
> [That, and all to often I run into parts of the help system that are
> unable to send information a screen at a time. Which can be
> inconvenient, or crippling, depending on my situation at the time.]
????
I think we can consider it a well-established fact, that VMS and
VMS-applications in general are much better documented than almost
any other OS (UNIX,DOS etc. - I have never worked with MVS or the like !).
> Which might be why VMS systems are so hard for a person to use --
> there's all this administrative bullshit you have to go through to get
> permission to use the system. Better to use a system that relies on
> social mechanisms than one which relies on red tape.
This is a decision by your system-manager. VMS systems can be very
loose or very restricted, because VMS is very flexible, but you can
not blaim the OS for your system-manger using the flexibility to
setup a restricted system.
xmd...@fs2.dp7up.com
In article <MEISSNER.94...@pasta.osf.org>, meis...@osf.org
(Michael Meissner) writes:
>In article <2ksb82$r...@gap.cco.caltech.edu> ca...@SOL1.GPS.CALTECH.EDU
(Carl J Lydick) writes:
>
>| In article <2kriu4$3...@morrow.stanford.edu>, sa...@pangea.Stanford.EDU
(Bruce Salem) writes:
is
>| =>>therethat this is not the case?
>| =>Unix seems to be the choice of universities, so graduates don't know
"VMS".
reliable
>| =>system go VMS, and VMS only.
>| =
>| = Why is that?
>|
>| As to the former: Because at one poin AT&T's Bell Labs gave away the
sources
knew you
>| could. As to the latter: Because Unix has an architecture that makes
any sort
>|of security nearly impossible to implement.
>
>Actually, to be more correct, can you say "consent decree". Until Judge
Green
>signed the order breaking apart AT&T into the regional bell operating
companies
>(RBOC's) and the long distance company (AT&T), AT&T was forbidden from
entering
>the computer market by a consent decree that they had signed in the
>Because ofthat, what was released had to be pretty much at cost. Since
UNIX
>was released in the late sixties, it fell under these terms. Snobol
also fell
>under similar constraints and terms.
I can see how much good it did Snobol....
Arne Vajhoej
>
> OK, shit-for-brains. Let's examine your claim. Suppose you've got a binary
> file that's got records of varying length. I.e., ANY character can appear in
> ANY record. Not all records are the same length. How do you tell, under UNIX,
> where a record ends? Answer: You write your own version of a subset of RMS to
> run under Unix. Second question: If you want a file that obeys Unix'
> deficient semantics, how do you do it under VMS? Answer: Ask RMS to create a
> stream file.
>
> under Unix without writing your own I/O library. Which is superior?
Even though I agree mostly with the substance in Carls arguments (but not
with the form - Carl why do you need to use that tone ?), then things
are a little more complex !
UNIX/DOS has a very simple record-structure, while RMS supports several
record-structures. This is a feature that saves time for the programmer
on VMS. But you know as well as I do, that there are certain restrictions
on line-length, access-methods etc. that tends to confuse even the medium
experienced VMS programmer. And the biggest problem is all those poorly
written UNIX / DOS C programs, that makes some real hard assumptions about the
file-format. They do not work with anything but STREAM_LF / STREAM files !
Poor programming practice - yes ! But there are lots of that kind of
code out there !
Eric Mercer
(Keep It Simple, Stupid). It was an experiment in which the absolute
bare minimum of an operating system was provided. The idea being that
if you wanted a feature, you would simply add it to the operating system.
This explains the extremely modular nature of the unix commands. It
also explains why there is so much variation in the way that the same
commands work on different machines. Perhaps if AT&T had made an effort
to define one standard UNIX, it would be a better system today. Of course
there was no real reason for AT&T to do anything about UNIX, since they
were not making a profit from it.
VMS is better because Digital set out to make a complete operating
system. There is no way for UNIX-lovers to deny this, just as there is
no way for VMS-lovers to deny that Digital screwed up the marketing.
I like UNIX because I like the IDEA behind the operating system.
I like VMS because it is a much better system. They may both be on the
way out. In a world where people buy a car because they like the name,
no one can expect something to survive just because it is the best.
If I get my wish, Digital will build a version of UNIX as complete
as VMS. Of course, they will probably be beaten by whatever operating
system knows how to push the right buttons :(
Arne Vajhoej
>
> Hmmm. The jackass never heard of DECUS, it seems. Hey, shit-for-brains:
> expert you didn't know that, right?
Hmffff....
It must still be an advantage for an OS to come with all the necesarry
utilities instead of getting them from other sources (free or not).
VMS could use some extra utilities, but that is not major problem.
> =Beside the fact that you would need an awk program to
> =strip out all the boiler plate from search output, it dodn't handle
> =limited regular expressions.
>
> Hey, moron: AWK is also available for VMS. Next time you post, try to post
> on some subject with which you have even a minimal clue!
Carl - your tone ! It is better to be both knowledgable AND polite than
just polite !
Hugh Evans
|>And shelve space. Unix documentation is getting much better and is
|>delivered in hypertext browsable format on an increasing number of
|>systems. You can't do that with documentation on a shelve.
|>
DEC has offered its documentation for over two years in hypertext browsable
format on CD ROM. And it works on all the flavours of VMS :-).
--
Hugh Evans
European Space Research and Technology Centre - Noorwijk, Netherlands
Internet: hev...@wm.estec.esa.nl SPAN: ESTWM2::hevans
To know recursion, you must first know recursion.
Arne Vajhoej
> Look at the facts and make up your own mind!
>
> VMS is available from only one manufacturer.
This is only a problem if the monopoly results in higher prices !
> The hardware (VAX and Alpha) on which VMS runs is available from only one
> manufacturer.
Even though Intel has not strict monopoly on x86 processors, then they
certainly have a very strong position. And that do not seem to bother
the users.
> VMS doesn't run on PCs.
Strange I thougth VMS ran just fine on a ALPHA PC !
> It's fairly clear that the future lies with personal computers. It's
> also clear the people will want to be able to shop around for software
> and hardware.
The basic point is that even though VMS is a very good OS, then the OS
for the desktop-market (the OS used to start up word-processors) do not
need to be so complicated. VMS is simply too good !
Arne Vajhoej
> . =there's all this administrative bullshit you have to go through to
> . =get permission to use the system. Better to use a system that
> . =relies on social mechanisms than one which relies on red tape.
>
> . VMS does *NOT* rely on red tape. If the folks who own the system
> . want to do it that way, they can; if they don't, they don't have
> . to. You're blaming the O/S for local political problems. Of
> . course, the other idiocies you've committed make it unsurprising
> . that you'd fuck up on this, too.
>
> I've run across hostile system administrators on both vms and unix
> systems. They seem to have a more pervasive effect on vms systems.
You are absolutely rigth. On a VMS system a system-manager has much
better means of controlling the users. He do not have to use
those means, but he has the possibility of doing it. This is called a feature
in common terminology.
xmd...@fs2.dp7up.com
gr...@bronze.ucs.indiana.edu (Gregory R. TRAVIS) writes:
>Not that I feel good about responding to Carl's knee-jerk
vindictiveness..
>
Lydick) writes:
>
>[About RMS]
>
>>Package? It's a part of the OS.
>
>Software stands between the user and the machine, Carl.
>
binary
>>file that's got records of varying length. I.e., ANY character can
appear in
>>ANY record. Not all records are the same length. How do you tell,
under UNIX,
>>where a record ends? Answer: You write your own version of a subset
of RMS to
>>run under Unix. Second question: If you want a file that obeys Unix'
>>deficient semantics, how do you do it under VMS? Answer: Ask RMS to
create a
>>stream file.
>
>separator is ETX and that you're trying to fill a C structure
>from each record. Please post examples in both UNIX and VMS of how
>to do this.
>
>greg
(not defending Carl's posts)
I think that his point is that under VMS files have a structure that is
independant of the applications involved. For example, if you are given
a file with no other information about it you can (with no other
information) view the file as a groupof records (you wouldn't need to
know that ETX is the record separator). VMS offers a number of different
file formats to suit different needs. VMS also supports non-structured
(Unix-like) files that are simply a stream of bytes -- it is then up to
the application to deal with the data.
VMS also offers different types of files, including indexed (without
additional software). This is significant, the indexes are supported
directly by VMS -- if I move the file to another VMS machine it will
still work, if I don't have the application I can still do something with
it, etc. In addition all utilities and applications will support the
indexed file (if they open it sequentially they will just get the records
back in the pre-defined order).
I find itinteresting that the industry has 2 opposite trends. The
relational group that insists that data should be independant of program
(more like the VMS approach) and the Unix group that says that operating
systems should stay out of the data business, that's an application issue.
Arne Vajhoej
> >>more clear than the UN*X documentation I've seen (Sun, SGI, AIX, SCO). On
> >>the other hand, it *does* cost an arm and a leg.
>
> >delivered in hypertext browsable format on an increasing number of
> >systems. You can't do that with documentation on a shelve.
>
> But in my optinion, paper documentation is still the best there is.
> I can put small clips where I want to, have several manuals opened
> at the same time, and work with my project on the screen.
> It takes physical space, but if I have that, it's much better
> than online stuff.
> (Good manuals have good indexes...)
And VMS manuals also comes on CD's !
> >>(This one is opinion :-):) EVE/TPU are a nicer customizable editing system
> >>than either vi or emacs. For that matter, the stuff I've built on top of
> >>EVE is nicer for what I need to do (environmental modeling: mixed Fortran/C
> >>development and maintenance) than LSE, either (with which it is difficult to
> >>integrate one's own customizations because of the inadequate documentation.)
>
> >Except that it only works on DEC vtxxx termninals.
>
> Don't EVE/TPU use SMG$? (Or has SMG$ been obsoleted?)
1) No - neither EDT or TPU uses SMG$-routines !
2) I also consider EVE/TPU the best editor ever seen !
Alan Dekok
Carl J Lydick <ca...@SOL1.GPS.CALTECH.EDU> wrote:
===== Summary of Carl's arguments ======
>[...]
>Give me a break. [...] Or you're as much an idiot as Bruce Salem.
>[...]
> You'd be a lot more convincing if you had even
>a clue as to what you were talking about.
>[...]
>Ah! That explains why you confuse limitations of the OS and local policies.
>Hey shit-for-brains: [...]
>[...]
>Perhaps, rather than simply spouting bullshit, you'd care to substantiate your
>claims?
>[...]
>Hmmm. The jackass never heard of DECUS, it seems. Hey, shit-for-brains:
>[...]
>Hey, moron: AWK is also available for VMS. Next time you post, try to post
>on some subject with which you have even a minimal clue!
>Unless you're a
>totally clueless jackass. Before you complain about the tone of my post,
>please remember, many people consider it to be a major breach of etiquette to
>represent yourself as an authority when you're as clueless as is Bruce.
Some other people also consider it a major breach of netiquette when
half of your 'argument' consists of reviling the other person. You really
remind me of my three year old brother... "Oh yeah? Well... well... you
STINK! And you're UGLY too!"
Try arguing rationally, Carl. And try and rebut other peoples arguments
rather than spitting on them, and proudly crowing your own views are so
much better (without giving proofs or examples).
Alan DeKok.
Alan Dekok
>That's the most pathetic attempt to sound "deep" while saying absolutely
>last decade.
That's the most pathetic attempt to sound "intelligent" while saying
absolutely nothing that I've heard from anybody except a politician or
Ludwig Plutonium in the last decade. ( Or Riley G., or A. Abian... Gee
Carl, welcome to the club!)
Alan DeKok.
look out, here he comes again
>For this newsgroup? Hell, for all newsgroups. People like Carl are just
>looking for fights. Who needs it?
Not true. People like Carl just get pissed at people who argue without using
logic and attempt to make authoritive statements of fact about something they
are only vaguely aware of. There's plenty of disinformation about computers
some of it deliberately spread, some of it just spread from ingorance and an
"I'm an expert on everything" mentality
>
>>*plonk*
>
>*kerplunk* as Carl J Lydick goes *shloorp* into KILL.....
gosh-i'm-hip-on-usenet-word-delimited-with-asterisks
Tom O'Toole - ecf_...@jhuvms.hcf.jhu.edu - JHUVMS system programmer
Homewood Computing Facilities - Johns Hopkins University, Balto. Md. 21218
Disco music makes it possible to have 'disco entertainment centers',
where dull, boring people can meet, and reproduce. - Frank
Larry Mulcahy
(Craig...@mixcom.mixcom.com) retched up these words:
: 1. Does VMS have much of a future?
No.
: 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
: there that this is not the case?
Yes. The writing is on the wall for proprietary operating systems like
VMS. One after another the companies who used this strategy have been
forced to let go of their proprietary OSes or go out of business. Only
the large installed base of VMS has allowed it to cling to life until
now.
: 3. Does VMS provide enough bang for the buck? How does it compare to
: the competition in this area?
VMS tries to do too much with its layer after layer of needless
complexity. The designers of VMS just didn't have the gift for spotting
the key abstraction to make their design powerful yet simple.
: 4. What do you think are the strengths of VMS that would make it an
: attractive alternative to someone who is used to Unix? To MS-DOS?
I suppose the multitasking and virtual memory make VMS look good
compared to MS-DOS, but Unix is light-years ahead of VMS in every way.
: 5. If the big objection to VMS is that it is proprietary, why don't we
: hear such complaints about MS-DOS and Windows?
MS-DOS and Windows are bad too. Until recently, PC hardware wasn't
powerful enough to run Unix, so proprietary OSes are more entrenched in
the personal computer market. As personal computer users become more
sophisticated, they will follow in the footsteps of the business world
and reject proprietary OSes.
: 6. Should DEC consider franchising VMS to independent software
: developers (ISVs) who could add their own enhancements, the way Microsoft
: has done with MS-DOS or McDonald's has done with their restaurants? Would
: this answer the objection that VMS is proprietary while Unix is not?
The only thing that could possibly save VMS would be to make it free
software. Then VMS and Unix would be competing head to head on their
technical merits without the crippling handicap of VMS' proprietary
status.
: 7. How can DEC make VMS attractive to the nation's computer science
: departments?
: 8. How can DEC make VMS attractive to software developers?
DEC should just give up trying to foist VMS off on its clients.
Granted, many are stuck with VMS for the present and DEC should support
these unfortunates, but DEC would have to lie to make VMS appear
attractive to anyone who has a choice.
: 9. Does VMS have features that are not found or are not nearly as well
: developed in competing operating systems? If so, what are they?
VMS has endless features in the operating system which should be
considered applications. For example, VMS gives you RMS. Some might
consider this an advantage of VMS over Unix which only has flat files.
However, since in Unix the ISAM/database component is an application,
any number of implementations are available instead of just the one.
: 10. Are these features (which are better developed in VMS) very much
: appreciated by the people who actually make the operating system selection
: decisions? If not, why not?
No, because control of what features are available remains in the hands
of DEC rather than in the hands of the client.
: 11. What market should VMS serve?
Those who find it more economical to continue running their existing
applications on VMS rather than port to Unix.
: 12. Should DEC develop a standard GUI interface to VMS, such as
: Microsoft Windows or X-Windows?
The last thing we need is another one of these. I thought VMS already
had X/Motif.
--
Larry Mulcahy lmu...@lookout.ecte.uswc.uswest.com
la...@ambient.uucp ambient!la...@mnemosyne.cs.du.edu
GCS d- p--- c++ l++ u+ e++ m n- h+ f? s !g w+++ t r !y
The Failed Clinton Presidency: day 406, 1053 days to go
Chris Kalisiak
>In article <2ksb82$r...@gap.cco.caltech.edu> ca...@SOL1.GPS.CALTECH.EDU writes:
>>In article <2kriu4$3...@morrow.stanford.edu>, sa...@pangea.Stanford.EDU (Bruce Salem) writes:
>>Or you're as much an idiot as Bruce Salem.
>[...]
>>Hey shit-for-brains:
>[...]
>>Hmmm. The jackass never heard of DECUS, it seems. Hey, shit-for-brains:
>[...]
> As I doubt that you would speak to me in this manner face to face,
>what gives you thr right to do so here, in public?
Somehow, I don't doubt that Carl would do this in public.
>I expect your apology.
Not from Carl, you won't.
>Then, if you have anything enlightening to say, I might consider answering
>you. Continue with the potty mouth, child, and I will contact someone on
>you domain with some power to teach you some manners.
Ha. That's a good one.
Chris
--
Chris Kalisiak |"Pound for pound, lame puns are your best entertainment
kali...@cs.buffalo.edu | value." -- Gogo Dodo, Tiny Toon Adventures
Tel/Fax:(716)692-5128/695-8481 |"Cocaine is God's way of telling you you have
I'm a student; I don't speak for UB.| way too much money." -- Sting, The Police
Johnny Billquist
>In article <2ktkr2$n...@krille.update.uu.se>,
>Johnny Billquist <b...@Krille.Update.UU.SE> wrote:
>>
>>VMS commands can also take a list of filenames.
>>My point was that UNIX have no idea what a wildcard is.
>>If you give an asterisk as a filename to Unix, it will say
>>thank you and yes ma'm.
>>/bin/sh has been around for quite some time yes. I never said
>>that the workaround was invented last year. But it still is
>>a workaround because Unix still don't support wildcards in
>>filenames.
>>There are no conincidents here, the workaround has been very
>>explicitly developed over a long time.
>Its not a workaround. It was a concious design decision.
The decision not to support wildcards was a concious design decision,
it had to do with the type of resources available at the time
Unix was written I suppose.
I still consider the wildcarding solution in Unix to be a workaround.
>>In some places, however, you will not get what you thought,
>>if you come from a DEC OS to unix.
>>
>>Consider that you want to rename a bunch of files from
>><something>.foo to <something>.bar
>>In VMS you say RENAME *.foo *.bar
>>
>>If you try mv *.foo *.bar in unix, you'll get a nasty surprise.
>>mv thinks that all arguments up until the last one is a source
>>specification, and the last one is always a destination.
>>So, if you don't have any files named <something>.bar, the
>>last file named <something>.foo will get clobbered, otherwise
>>the last file named <something>.bar, which already exists
>>will get clobbered.
(Which was a shortcircuit on my part. It won't get clobbered, but
you won't get the action done either. Just an error.)
>>Hmm, sorry about this. Just that I can get a little excited
>>when I think about the lousy solution Unix offers to people
>>who want wildcards.
>>
>You may think its lousy. I for one think it definately is the right way
>to go. The idea of Unix is that if you leave it to the shell, that lets
>users decide how their wildcarding works. Say I wanted my wildcarding to
>work differently--I would simply rewrite my shell. No one else would notice
>anything else. IMHO, putting wildcarding in the shell is one of the best
>ideas Unix came up with.
Well, I prefer the VMS way here. If you want wildcarding to work
differently, you write another library. VMS have had dynamic libraries
since ages, so no need to recompile anything, and it also works
inside the program.
In Unix, you either only have wildcards at the shell, or you need
to write your own wildcard expansion routines inside your program,
which won't change if you change the shell behaviour.
Is there not other people who gets irritated at Unix for not
expanding anything on its own? Try specifying your home directory
in a Unix program with tilde. Sometimes it works, sometimes not.
All depending on what that specific programmer felt like fixing.
Same for environment variables, and anything else you can think of.
Johnny
--
Johnny Billquist || "I'm on a bus
CS student at Uppsala University || on a psychedelic trip
email: b...@minsk.docs.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
James Hall
: state. The VMS downside is that I wish the designers had put in larger
: typeahead buffers than the current 512 bytes (say, 4K, at least).
The typeahead buffer sizes are SYSGEN parameters. Note that there are two
distinct sizes (I think one is called the "alternate" size. You can set your
terminal to have the alternate buffer size with a SET TERM command.
: (This one is opinion :-):) EVE/TPU are a nicer customizable editing system
: than either vi or emacs. For that matter, the stuff I've built on top of
: EVE is nicer for what I need to do (environmental modeling: mixed Fortran/C
: development and maintenance) than LSE, either (with which it is difficult to
: integrate one's own customizations because of the inadequate documentation.)
Agree, but EDT is better that all of 'em :-)
: Carlie J. Coats, Jr. co...@cardinal.ncsc.org
: Environmental Programs phone: (919)248-9241
: North Carolina Supercomputing Center fax: (919)248-9245
: 3021 Cornwallis Road P. O. Box 12889
: Research Triangle Park, N. C. 27709-2889 USA
: "My opinions are my own, and I've got *lots* of them!"
James
Mike McCurdy
> you get support. Or you're as much an idiot as Bruce Salem.
> Hey shit-for-brains: VMS has a lot of flexibility. That means that your local
> Perhaps, rather than simply spouting bullshit, you'd care to substantiate your
--
Mike McCurdy Email: mcc...@ucssun1.sdsu.edu
Computer Systems Administration
San Diego State University Disclaimer:
San Diego, CA. "Everything I say may be wrong."
Bruce Salem
>In article <2kriu4$3...@morrow.stanford.edu>, sa...@pangea.Stanford.EDU (Bruce Salem) writes:
>VMS as shipped, but you can get them at no extra charge. Unless you're a
>totally clueless jackass. Before you complain about the tone of my post,
>represent yourself as an authority when you're as clueless as is Bruce.
Look, Carl, just take whatever is said anywhere on the Internet
as just someone's opinion. Leave it up to people reading the content of
a post to decide for themselves whether the person is knoledgable or not.
I made it clear in my post that I was speaking from user experience dating
from about 1985, and that I had never administrated a VMS system. I also
made it clear that I had written FORTRAN (F77) using RNS, and had to use
DCL. I also made it clear that I had seen VMS systems with UNIX commands.
I did not express or imply that I was a VMS expert, I am not, and I'm sure
that everyone who read my post could tell that. They didn't need you calling
me names or you to tell them what I know or don't. Carl, you have been
represented to me as someone who is knowledgable about VMS. I take that
as a given. What I cannot accept is your tone in reply. Grow up, Carl.
Bruce Salem
!!! These views are not sanctioned by my employer !!!
Bruce Salem
>(not defending Carl's posts)
>
>I think that his point is that under VMS files have a structure that is
>independant of the applications involved. For example, if you are given
>a file with no other information about it you can (with no other
>information) view the file as a groupof records (you wouldn't need to
>know that ETX is the record separator). VMS offers a number of different
>file formats to suit different needs. VMS also supports non-structured
>(Unix-like) files that are simply a stream of bytes -- it is then up to
>the application to deal with the data.
My experience was in writing a F77 (DEC-FORTRAN) application
in 1987 that I had to know the modes of the file to get it to open,
that RMS was a layer of administration between me and my file, or a
file some other program had created. I don't mind displaying my
ignorance here, for your point about the different approaches to
files illustrates the tradeoffs well, you trade security for flexibility.
My gripe was that I had to determine the modes before I could open
the file, not let some utility tell me the modes.
>VMS also offers different types of files, including indexed (without
>additional software). This is significant, the indexes are supported
>directly by VMS -- if I move the file to another VMS machine it will
>still work, if I don't have the application I can still do something with
>it, etc. In addition all utilities and applications will support the
>indexed file (if they open it sequentially they will just get the records
>back in the pre-defined order).
What if I want to look at the file as a stream of bits? If
I move the file to a non-VMS system I am stuck. I still have to od
or dump it in hex to begin to figure out how it is structured and to
write an application which can treat it as an indexed file. I hope
that somewhere there is some code that I can install on my foreign
system just to read RMS indexed files, if I need to do this quickly.
>I find itinteresting that the industry has 2 opposite trends. The
>relational group that insists that data should be independant of program
>(more like the VMS approach) and the Unix group that says that operating
>systems should stay out of the data business, that's an application issue.
People like to complain that UNIX files are just streams of
bytes and that files have no internal structure imposed by the OS, leaving
too much up to the application. I am no filesystem expert, but large
database applications can have their own specially constructed filesystems
under UNIX to get the performance of indexed file structures, B+ trees and
the like.
There is a parallel in the terseness of UNIX commands. But which
is easier, to strip something the OS puts in or to add something when
you want it? It is true, I can install awk on VMS, but why should I need
it in order to strip boilerplate out of the search command put there
by DEC to keep MIS types warm and fuzzy? I think that the UNIX approach
is better: it is up to the application to add boilerplate, not the
OS. Better, run grep on VMS.
Bruce Salem
Laurel Edgecomb
Yes, but its end is now in sight. Not final extinction but the
RSXification/RSTSification of VMS where only sites that need not
or can not change will still have VMS.
> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
> there that this is not the case?
Yes. Everything seems to be pointing towards U*X like OS's or to
a new OS. There are more U*X sites, applications, and
programmers. The net and US schools are mostly a U*X world. Rumors
from from DEC sales indicate that they are being instructed to
market OSF/1 to new sites...VMS is just not competitive.
Developer after developer is dumping VMS support and many new
applications (even from DEC) are not being developed for VMS.
For example FUSION is DEC's software development system for U*X.
It is one generation better than DECSET (at least). The DEC
developers would love to move it to VMS but there is no market.
VMS sites doing software development already have DECSET or
homebrew and don't need to change, and there are not enough new
sites doing VMS software development to be worth porting FUSION.
There is on U*X.
It is yet to be seen if Windows/NT will be a major player, but
unless they screw up badly it looks very good for NT. Windows/NT
promises (but has not yet delivered by a very long shot) all the
advantages that VMS delivers and more. A huge _potential_
application and programmer base, an even cleaner programmer
interface to the OS, security, reliability, support, and it is
truly multi-platform (2 is not multi).
For VMS (no matter how good it is) to remain viable must continue
to have a critical mass of sites running VMS and constant flow of
new sites. I believe that VMS has already crossed over the border
to below the critical mass for viability, and will, inevitably,
follow that long, slow, spiral to OS oblivion.
> 3. Does VMS provide enough bang for the buck? How does it compare to
> the competition in this area?
Yes if you need what VMS gives. VMS gives Security, Reliability,
Support, and A Clean (but a bit slow) Calling Standard. If you
don't need these features (and many don't or don't want to pay
for them) VMS is not the best bang for the buck.
> 4. What do you think are the strengths of VMS that would make it an
> attractive alternative to someone who is used to Unix? To MS-DOS?
It depends on the application. The application requirements drive the
hardware and OS selection.
> 5. If the big objection to VMS is that it is proprietary, why don't we
> hear such complaints about MS-DOS and Windows?
That is _not_ the big objection to VMS. The objection to VMS is
cost and "openness". By "openness" is meant the ability to run
applications written for U*X. The problem for VMS is there is
more U*X out there than VMS, more sites, more seats, more
developers, more applications (remember BETA vs VHS...some people
still have Beta).
There are plenty of complaints about MS-DOS and Windows. The
difference is only $ and the sophistication of the users. DOS
and Windows users are mostly application end users. They use a
package from some vendor. If the package does not work they tell
the vendor and the vendor fixes it. The software developers for
DOS and windows know that the OS is a _very_ simple OS. They
don't expect much and it did not cost big bucks. So they can't
yell very loud. When there is a new version they are happy.
VMS users expect, and pay for, a robust and sophisticated OS and
ask a lot. Businesses depend on the OS working as expected. If
it doesn't, they want a workaround or patch _now_. Under U*X the
source is often available and a systems programmer can make the
changes. There is often little support from the OS vender. Under
VMS the sources are available only for a price and most sites
don't have source. Most sites running VMS need the security of
VMS or its reliability and also have a DEC service contract.
Many modifications programmers would like to make to VMS seem to
cause problems later with getting good service from DEC (they
want to see the problem happen with your changes out). Of course
if you have VMS sources and don't care about DEC service, then
nothing stops one from modifying VMS.
> 6. Should DEC consider franchising VMS to independent software
> developers (ISVs) who could add their own enhancements, the way Microsoft
> has done with MS-DOS or McDonald's has done with their restaurants? Would
> this answer the objection that VMS is proprietary while Unix is not?
They should consider it, even try it. They have nothing to lose.
But that won't help. It is too late.
> 7. How can DEC make VMS attractive to the nation's computer science
> departments?
Give it away free along with all layered products, support it,
and sell hardware at a good discount.
It would have been a very good investment -- too late now though.
> 8. How can DEC make VMS attractive to software developers?
Sell VMS to more sites. ya, right.
> 9. Does VMS have features that are not found or are not nearly as well
> developed in competing operating systems? If so, what are they?
Yes.
RMS
Robust Security Features
Good Multi-Language Calling Standards
Relatively consistent API to system (compared to U*X & DOS)
Clusters
Relatively bug free and moderately powerful tools
(DOS tools are not powerful but relatively bug free
U*X tools are powerful but buggy and inconsistent)
> 10. Are these features (which are better developed in VMS) very much
> appreciated by the people who actually make the operating system selection
> decisions? If not, why not?
Yes.
> 11. What market should VMS serve?
VMS seems to make sense for applications that require large
amounts of custom programming in a secure, reliable environment
which is evolving, and thus requiring constant software updates.
> 12. Should DEC develop a standard GUI interface to VMS, such as
> Microsoft Windows or X-Windows?
It is being developed, but far from complete. (DECWindows/Motif
itself is not an O/S interface). It will be complete when a
system manager/programmer never needs to click in a decterm.
Should it be developed? I don't think so. VMS is not likely to
expand greatly into new sites, and existing sites seem happy with
the ASCII based tools. Nobody uses the GUI interfaces for most of
the tools that are in place now.
REGARDING COMMENTS ABOUT CARL LYDICK:
I have seen a few comments in this thread about people adding
Lydick to their kill file. Just so you know, that would be a
mistake (unless you just can't take being called, or seeing others
called, shit-heads). Except about religious or preference issues
Lydick is usually right. This is not because he is smarter or
knows more about VMS than anyone else on the net, but that he
knows enough to try a solution before spouting it to the net.
He, quite justifiably, acts pissed when someone spends the time to
ask a question but does not take the time to include what they
are trying to do, what they really did, and exactly what the
problem really is (including error messages, examples, and/or
logs). Given that those who fail to do this really are not
shit-heads, they are inconsiderate to those who are spending time
reading these posts to help them. I don't know why Lydick
chooses to use colorful, aggressive, personal attacks. I don't
really care why. I am more amused at the people that reply by,
first, indicating how childish Lydick is for doing such things,
then throw in a childish jab of their own. Lydick is, at least,
consistent (consistently useful and consistently acerbic). So if
he flames you - ignore the shit - get the message - or go crawl
under a rock somewhere and add him to you kill file.
Tim Llewellyn in Bristol. (0272) 303030 ext 3691.
>In article <2ksb82$r...@gap.cco.caltech.edu>,
>Carl J Lydick <ca...@SOL1.GPS.CALTECH.EDU> wrote:
>
> ===== Summary of Carl's arguments ======
>
latest VMS/Unix slanging match deleted]
>
>
> Some other people also consider it a major breach of netiquette when
>half of your 'argument' consists of reviling the other person. You really
>remind me of my three year old brother... "Oh yeah? Well... well... you
>STINK! And you're UGLY too!"
>
> Try arguing rationally, Carl. And try and rebut other peoples arguments
>rather than spitting on them, and proudly crowing your own views are so
>much better (without giving proofs or examples).
>
> Alan DeKok.
Yeah and its easy to make someone look stupid by quoting them out of
context! The gutter press do it all the time. Maybe you know little
about VMS, it certainly seems so or you would have appreciated that
Carl generally makes very sound technical sense, and certainly did
so in the postings you quoted. For Carl to react like that, usually
someone has to make it clear they think they are talking about something
they blatantly know little about. Which I think was the case. Carl
DOES solve a large percentage of the problems to comp.os.vms etc,
and if the question is asked sensibly will reply civilly (usually).
Oh and by the way, when I was a kid they taught me a little ditty.
How did it go now. Ah yes, "Sticks and stones will break my bones, but
words will never hurt me" :-)
PS Carl flamed me just this week.
-----------------------------------------------------+------------------+
Tim Llewellyn - OpenVMS, Soukous and Cricket Addict |Hey, and get wise |
Physicist Programmer, Bristol Uni Particle Physics. | to the sounds of |
HEPNET/SPAN 19716::TJL Internet t...@siva.bris.ac.uk | Africa,seen. |
I speak for me and noone else OK (and I might even | Soukous Makossa |
change my mind sometimes!-) | N'Dagga Mbalax..|
-----------------------------------------------------+------------------+
Aritomo Shinozaki
...Deleted Quotes from Carl Lydick post...
>
> As I doubt that you would speak to me in this manner face to face,
...
Note that this is the usual "Carl Lydick" discourse.
It is so prevalent in his writing, that I assume he might
actually talk to people this way.
Perhaps a vulnerable psyche can be corroded by prolonged contact with DEC, VMS
and related entities :)
It hasn't changed much from this example:
...Header Deleted...
>Message-ID: <29i49...@gap.caltech.edu>
>Date: 13 Oct 93 23:50:57 GMT
...Text Deleted...
>
>Gee. From your response above, it shouldn't surprise me that you're too
>goddamned lazy to actually READ the stuff that's been posted in this thread.
>Someone posted a pointer to a program called LIBSEARCH that does what you want.
>Get off your ass and review the thread to find the article in question.
>--------------------------------------------------------------------------
>Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
--
Aritomo Shinozaki Office: (412)-624-9016
Department of Physics and Astronomy a...@minerva.phyast.pitt.edu
University of Pittsburgh
Pittsburgh, PA 15260
Steven Woodford
bsa...@pyrtech.mis.pyramid.com (Bruce Salem) writes:
>In article <CLzsA...@dp7up.com> xmd...@fs2.dp7up.com writes:
>>(not defending Carl's posts)
Who could, except perhaps Carl himself...
>>I think that his point is that under VMS files have a structure that is
>>independant of the applications involved. For example, if you are given
[snip]
> My experience was in writing a F77 (DEC-FORTRAN) application
>in 1987 that I had to know the modes of the file to get it to open,
>that RMS was a layer of administration between me and my file, or a
>file some other program had created. I don't mind displaying my
[snip]
>My gripe was that I had to determine the modes before I could open
>the file, not let some utility tell me the modes.
>>VMS also offers different types of files, including indexed (without
>>additional software). This is significant, the indexes are supported
>>directly by VMS -- if I move the file to another VMS machine it will
>>still work, if I don't have the application I can still do something with
Moving files from one VMS box to another is fine. These days, though,
we (application designers) are forced, by current trends, to aim for
the lowest common denominator in terms of what we expect the host OS
to do for us, for better or for worse. AFAIK VMS may be the last of
the 'big' OSes to support something other than stream based files.
>>I find itinteresting that the industry has 2 opposite trends. The
>>relational group that insists that data should be independant of program
>>(more like the VMS approach) and the Unix group that says that operating
>>systems should stay out of the data business, that's an application issue.
I have to admit to being in the latter category. ;-)
At the moment, I'm porting an application subsystem (the coding of which
I wasn't involved in) from VMS to AIX and, to quote an earlier posting,
"it's a royal pain" due almost entirely on RMS assumptions in the code;
_even though_ the app. was intended to be portable!
Anyway, it interesting to see how this thread 'mutates' !!!
Cheers, Steve
Jim Robinson
>logic and attempt to make authoritive statements of fact about something they
>are only vaguely aware of. There's plenty of disinformation about computers
>some of it deliberately spread, some of it just spread from ingorance and an
>"I'm an expert on everything" mentality
>gosh-i'm-hip-on-usenet-word-delimited-with-asterisks
People like Carl ought to learn some manners. Perhaps he has a
"right" to get mad, but simply swearing at the world isn't going to
get people to read what he says in an unbiased manner. People will
react unfavorably and put him in their kill file. :)
Steve Gregson
> Message-ID: <1994Feb28.1...@alw.nih.gov>
> Newsgroup: comp.os.vms
> Organization: DCRT, NIH, Bethesda, MD
> In article <9402281217...@v1.ph.ox.ac.uk>, John Macallister
> <MACA...@v1.ph.ox.ac.uk> writes:
>Is VMS on the way out?
If so you will have join the bandwaggon of GUI os(windows/os2/next) or find
a real OS that you like. I suggest tha you take a look at TSXLite a shareware
product available on most BBS. If you honestly need VMS power and like its
"feel" you owe it to yourself to take a look at this product.
>Look at the facts and make up your own mind!
>
>VMS is available from only one manufacturer.
>The hardware (VAX and Alpha) on which VMS runs is available from only one
> manufacturer.
>VMS doesn't run on PCs.
>
>It's fairly clear that the future lies with personal computers. It's
> also clear the people will want to be able to shop around for software
> and hardware.
The great thing about TSX is that it runs on any 386/486 product. This
allows you to by your hardware from any vendor. It also will let you
run off the shelf DOS "16bit" software. This allows you to shop around
for the best price on hardware and software.
> It seems to me there are several issues here that need addressed:
> (1) The "personal computer" is just that ONLY for those individuals
> who rise to the challenge of mastery of its hardware and software
> to the point that their reliance on other supporting parties is
> minimal. This is usually NOT the case, especially in corporate
> environments, hence the existence of "Support Groups" or what have
> you to install, update, fix, etc.
> the hardware and software for the user. Such *usage* IS personal
> (for my exclusive use) but it takes a lot of other people to make
> it useful to me.
I totaly agree
-- Text deleted about The physical differences between "mainframe" and the "PC"
> (3) It's the COMBINATION of hardware and software that define the
> functionality of ANY computer. For example, the PDP-11 runs UN*X,
> but who really wants to live with those hardware limitations
> anymore? The basic principle that *I* learned about this was that
> BOTH have to support the intended use. Sure,
> I can run Linux on my 386SX-16, but it wouldn't be fun nor would
> it be suitable for an on-line transaction processing system or for
> the control of a rolling mill in a steel plant.
I gather that Linux is not a real time OS
> The original IBM Personal Computer, which has defined the present
> state of "personal computing", was a very limited scope, even crippled
> hardware platform that used a simplistic, limited software design.
> Consequently, an enormous amount of effort has been necessary to expand
> the utility of successor systems beyond this original scope, and even
> then we are still stuck with the limitations dictated by backwards
> compatibility issues.
-------------------more text deleted-----------
VMS will be more suited to areas of
> functionality that could only be achieved by a total redesign of DOS,
> MSWindows, or UN*X. The jury is still out on NT - there, at least,
> there seems to have been a better vision of current and future
> functional needs active in the design process. >
>John
So John let me tell you about The TSX family
TSX-32 is a full multi-user, multi-tasking, realtime operating system for
386 and 486 computers that runs in 32-bit protected mode. Most DOS 16-bit
applications run with TSX including popular DOS programs such as WordPerfect,
Foxpro, Lotus, dBase, etc. You can even run Windows 3.1 as a task under
TSX-32. TSX also supports newer 32-bit, protected mode DPMI applications.
Unlike Unix, TSX is very DOS oriented and has the commands you are used to
using (COPY, DIR,PRINT, TYPE, etc.) It also supports VMS style command
notation such as symbols,logical names,lexical functions,mailboxes,cl lines,
detatch and batch processing to name a few.
TSX uses the same file structure as DOS so you can install it on your
computer without repartitioning your disk and files produced by TSX and DOS
can be read by each other. TSX does not support disk compressions schemes
such as Stacker and DoubleSpace.
TSX-32 supports both directly connected and dial-in terminals. We have
sites running 486 systems with over 150 connected terminals. TSX has a
multi-session capability that allows each user to control up to 10
simultaneous sessions. Using a terminal emulator program or the TSXTERM
program that comes with TSX you can dial into a TSX site and execute all
commands and run DOS programs.
TSX-32 also offers peer-to-peer TCP/IP networking. By peer-to-peer I mean
that any user on any computer in the network can access any file on any
computer. Record locking is supported through the network for shared
database applications. You can also use the "SET HOST" command to log into
any computer. This is especially nice for dial-in situations where you can
call into any node that has a modem and then SET HOST to any other node.
Telnet, FTP, and NFS are also available for TSX.
A shareware version of TSX-32 called TSX-Lite is available. It is
restricted to running 2 simultaneous users but each user can control up to
10 sessions. TSX-Lite is available from many major BBS, look the files
TSX411A.ZIP, TSX411B.ZIP, TSX411C.ZIP, and TSX411D.ZIP. One BBS from which
you can definitely download TSX-Lite is The Nashville Exchange which can
be reached at 615-383-0119 (14.4k baud). You can log onto The Nashville
Exchange as a guest and then select "Product Support" followed by "TSX".
If you would like additional information you are welcome to send e-mail or
call Richard Dohrmann, our VP of marketing, at 615-327-3670.
Steve Gregson
steveg...@nashville.com
... The next best thing to VMS is TSX-32
.... My other computer is a VAX.
___ Blue Wave/QWK v2.12
vax...@chclu.chemie.uni-konstanz.de
A MicroVAX II, a VAXstation 3200, a VAXstation 3100 and
a DEC-3000-300-AXP runs as a VMScluster. All users are
authorized on all machines and they can use identical
commands. It took one month until the AXP-machine was a
production machine and all the important stuff was
recompiled and running.
The MicroVAX now is 5 years old, but the x-display comes
from the AXP-machine. This is called a save investment
and I'm pretty sure that the same is true for the
AXP-equipment. So, ask other people if they are using 5
year old machines ...
Eberhard Heuser-Hofmann
Fak.f.Chemie
Univ.Konstanz
Germany
Amish Dave
>Salem) demonstrates the depths of his cluelessness:
>=It was a royal pain to have to plead with the OS to open an ascii
>=file under some rules for dealing with the format of the data in the
>=file.
>
>Examples? I didn't think so. You're engaging in a variation of Argumentum
>ad Ignorantiam: Since you're clueless, you're right, right?
>
>=I think that UNIX's notion is vastly superior
>
>a binary file that's got records of varying length. I.e., ANY
>character can appear in ANY record. Not all records are the same
>length. How do you tell, under UNIX, where a record ends? Answer:
>You write your own version of a subset of RMS to run under Unix.
>Second question: If you want a file that obeys Unix' deficient
>semantics, how do you do it under VMS? Answer: Ask RMS to create a
>stream file.
You know... You're a real prick. I've never heard of men having
menstrual flow problems before, but you might consider telling a doctor
about it. The poster you replied to described HIS impression of HIS
experience with VMS; calling people clueless for forming their own
opinions (different from your own) demonstrates nothing but that you've
got shit in your pants and nowhere to dump it...
In my opinion, VMS file I/O has good and bad points. The bad point is
that it seems slow and is a pain to program compared to what I'm used
to on other computers. Also, while RMS may be great when you learn how
to use it and when you need it, IMHO, many people (certainly myself)
prefer the simpler, faster Unix file I/O. Maybe I've just become used
to it, and things would be different if I'd started out with VMS. Note
that there are things that I like about VMS: real time scheduling, the
QIO interface (although I admit I have little experience programming
Unix device drivers), and better security. But there's no way I'd give
up Unix to get these, and for the most part, I don't have to.
--
Amish S. Dave University of Chicago
am...@data.uchicago.edu Biology Grad. Student
David Marra
> Microsoft Windows or X-Windows?
In all actuallity, a look at history will reveal that DEC developed a
great deal of the X Window System, and much of Motif. XUI (as mentioned)
is what became Motif. X was co-developed between MIT and DEC.
The only reason VMS isn't on everybodys machine is because it doesn't
cost $75 per copy. Because MS Windows and DOS are so cheap, they are
a standard.
--
+---------------------------------------------------------------------+
| Dave Marra | Tmf Engineering |
| Object Oriented Test Interface | 35 Carriage Lane |
| (OOTI) Technology & QA Partner | Milford, NH 03055-3502 |
+---------------------------------------------------------------------+
| Currently working at Progress Software Corporation |
| ma...@bedford.progress.com 14 Oak Park |
| (617)280-4885 Bedford, Mass. 01730 |
+---------------------------------------------------------------------+
Arne Vajhoej
> > =Beside the fact that you would need an awk program to
> > =strip out all the boiler plate from search output, it dodn't handle
> > =limited regular expressions.
> >
> > Hey, moron: AWK is also available for VMS. Next time you post, try to post
> > on some subject with which you have even a minimal clue!
>
> Carl - your tone ! It is better to be both knowledgable AND polite than
> just polite !
Even though the statement above is true, then it should have been:
"It is better to be both knowledgable AND polite than just knowledgable !"
(it should be rather obvious from the context, but ....)
Brainwave Surfer
>> This week a software engineer told me that VMS is a dying operating
>> system. I would like to know what the readers of this forum think. I have
>> some thoughts on this issue, but first I would like to see what other
>> people think. Some of the following questions involve business rather than
>> technical issues. Some people may feel that discussing business issues is
>> inappropriate in a technical forum. However, the future of a technical
>> product like VMS depends heavily on BOTH.
>>
Lots of stuff deleted...
>> 5. If the big objection to VMS is that it is proprietary, why don't we
>> hear such complaints about MS-DOS and Windows?
>
I have it on *very* good authority that MS-DOS, Windows, and so forth
are developed on VMS under emulators for the hardware. Microsoft has one of
the biggest DEC Vax installations anywhere, all churning out s/w for the
peecees. Know who else has a similar setup? Apple.
To me, that says a lot. However, who makes the bucks? The PeeCees.
Why? Numbers...
Ah Well.. I'm learning C and SQL now, and finally abandoning good ole FORTRAN.
It's still the best for numbers, but Numbers speakee dollars..
Jim
/^^^\ \ / Jim Agnew | AG...@RUBY.VCU.EDU (Internet)
/ > || Neurosurgery, | AGNEW@VCUVAX (Bitnet)
/\_/ ' \ / MCV-VCU | This disc will self destruct in
/________________> Richmond, VA, USA | five seconds. Good luck, Jim..."
Carlie Coats
>In article <2ksvt2$g...@mail.fwi.uva.nl>, cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>
>|>And shelve space. Unix documentation is getting much better and is
>|>delivered in hypertext browsable format on an increasing number of
>|>systems. You can't do that with documentation on a shelve.
>|>
>
>format on CD ROM. And it works on all the flavours of VMS :-).
>
>--
>Hugh Evans
>European Space Research and Technology Centre - Noorwijk, Netherlands
>Internet: hev...@wm.estec.esa.nl SPAN: ESTWM2::hevans
>
>To know recursion, you must first know recursion.
IMHO, these hypertext documentation systems will be a lot more useful
when we have the *real* desktop metaphor instead of the porthole metaphor.
What I want to use them on is a 30-inch-by-72-inch 100 dpi touchscreen
desk-top. Maybe by the turn of the century...:-) Till then, paper is
friendlier.
Brian Bowman
look out, here he comes again
> My experience was in writing a F77 (DEC-FORTRAN) application
>in 1987 that I had to know the modes of the file to get it to open,
Sorry, but what are you talking about? What are the modes of a file? Is that
like the ioctl of the subdirectory? Your comments indicate to me that you have
hardly ever used this system, and used it so long ago your memory is dim.
Someone who never used VMS might believe your assertions, therefore you are
spreading disinformation. You are speaking with an air of authority about
something you know little about (aka 'BSing'). I can't really say you are
'wrong' because you haven't even formulated a statement that makes sense, so
truth value of it cannot be evaluated.
Michael Lemke
Matthew Crosby <cro...@rintintin.Colorado.EDU> wrote:
>>
>>Hmm, sorry about this. Just that I can get a little excited
>>when I think about the lousy solution Unix offers to people
>>who want wildcards.
>>
>
>You may think its lousy. I for one think it definately is the right way
>to go. The idea of Unix is that if you leave it to the shell, that lets
>users decide how their wildcarding works. Say I wanted my wildcarding to
>work differently--I would simply rewrite my shell. No one else would notice
>anything else. IMHO, putting wildcarding in the shell is one of the best
>ideas Unix came up with.
>
Like in:
character*255 file_name
write( 6, '(a,$)' ) 'Enter file name: '
read( 5, '(a)' ) file_name
open( 1, file = file_name )
...
Interesting shell you'll have to write for this. Note, calling getarg
is not accepted!
Michael
--
Michael Lemke
Institute of Astronomy, Cambridge UK
(mic...@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])
Alan Dekok
Tim Llewellyn in Bristol. (0272) 303030 ext 3691. <t...@siva.bris.ac.uk> wrote:
>In article <CLztp...@cunews.carleton.ca>, al...@frey.physics.carleton.ca (Alan Dekok) writes:
>[out of context quotes of Carl's "offensive to some" postings in the
>latest VMS/Unix slanging match deleted]
>> Some other people also consider it a major breach of netiquette when
>>half of your 'argument' consists of reviling the other person. You really
^^^^
>>remind me of my three year old brother... "Oh yeah? Well... well... you
>>STINK! And you're UGLY too!"
>Yeah and its easy to make someone look stupid by quoting them out of
>context!
I asume that most people who've been reading this thread know the
context of Carl's original quote. I was just looking to point out the
more inflammatory parts of his message.
>The gutter press do it all the time. Maybe you know little
>about VMS, it certainly seems so or you would have appreciated that
>Carl generally makes very sound technical sense, and certainly did
>so in the postings you quoted.
Note that I said _half_ of his argument contains invective. And yes,
much of what he says does make technical sense.
>For Carl to react like that, usually
>someone has to make it clear they think they are talking about something
>they blatantly know little about. Which I think was the case. Carl
>DOES solve a large percentage of the problems to comp.os.vms etc,
>and if the question is asked sensibly will reply civilly (usually).
So? Even over on Sci.Skeptic and Sci.math where there are endless
quacks posting stupid messages, almost no one resorts to childish
arguments to rebut them. Being confronted with what you think is stupidity is
not an automatic license to become stupid yourself.
>Oh and by the way, when I was a kid they taught me a little ditty.
>How did it go now. Ah yes, "Sticks and stones will break my bones, but
>words will never hurt me" :-)
yes... and my mother taught me to be polite in all situations. What was
that quote from Malcom X (he didn't say it tho) "People swear because
they don't have the words to properly express their feelings".
>PS Carl flamed me just this week.
I've flamed people too, and later regretted it. I've found it to be
generally unproductive and pointless. It's much easier to stay polite, or
barring that, ignore comments I disagree with.
Alan DeKok.
xmd...@fs2.dp7up.com
bsa...@pyrtech.mis.pyramid.com (Bruce Salem) writes:
>In article <CLzsA...@dp7up.com> xmd...@fs2.dp7up.com writes:
>>(not defending Carl's posts)
>>
>>independant of the applications involved. For example, if you are given
>>information) view the file as a groupof records (you wouldn't need to
>>know that ETX is the record separator). VMS offers a number of
different
>>file formats to suit different needs. VMS also supports non-structured
>>(Unix-like) files that are simply a stream of bytes -- it is then up to
>>the application to deal with the data.
>
>in 1987 that I had to know the modes of the file to get it toopen,
>file some other program had created. I don't mind displaying my
>files illustrates the tradeoffs well, you trade security for flexibility.
>the file, not let some utilitytell me the modes.
>
I'm not sure what you're referring to here. I did VAX Fortran for a
number of years. When you open afile, you can specify the access type
(indexed, relative, sequential, etc), but this is the program's view not
necessarily thephysical file's attributes (you can open an indexed file
as sequential just fine -- the same program will run weather the file is
indexed, relative, or sequential). You can also specify record
characteristics (such as fixed length or variable), but these are only
needed if you are creating new files (and you get a default if you don't
specify). If you open an existing file, the program will get this
information at OPEN time from RMS. I'm not disputing your arguement, but
I would like more info on what you view as the problem.
>>VMS also offers different types of files, including indexed (without
>>additional software). This is significant, the indexes are supported
>>directly by VMS -- if I move the file to another VMS machine it will
>>still work, if I don't have the application I can still do something
with
>>it, etc. In addition all utilities and applications will support the
>>indexed file (if they open it sequentially they will just get the
records
>>back in the pre-defined order).
>
> What if I want to look at the file as a stream of bits? If
>I move the file to a non-VMS system I am stuck. I still have tood
>or dump it in hex to begin to figure out how it is structured and to
>write an application which can treat it as an indexed file. I hope
>that somewhere there is some code that I can install on my foreign
>system just to read RMS indexed files, if Ineed to do this quickly.
>
It depends on how you move it. I use a the convert utility to move it
and I get a sequential file with line-feeds (in sorted order). If you
are trying to process the file in-place (without moving it) with, say,
NFS, you are right, you will have problems. Is the answer to go to the
lowest common denominator, thus eliminating the use of features?
>>I find itinteresting that the industry has 2 opposite trends. The
>>relational group that insists that data should be independant of program
>>(more like the VMS approach) and the Unix group that says that operating
>>systems should stay out of the data business, that's an application
issue.
>
> People like to complain that UNIX files are just streams of
>bytes and that files have no internal structure imposed by the OS,
leaving
>too much up to the application. I am no filesystem expert, but large
>database applications can have their own specially constructed
filesystems
>under UNIX to get the performance of indexed file structures, B+ trees
and
>the like.
>
No complaints, just an observation of trends. Different operating
systems are better suited for different things.
Mark A. Buda
In article <2l0k63$5...@pyrtech.mis.pyramid.com>, bsa...@pyrtech.mis.pyramid.com (Bruce Salem) writes:
> My experience was in writing a F77 (DEC-FORTRAN) application
>in 1987 that I had to know the modes of the file to get it to open,
>that RMS was a layer of administration between me and my file, or a
>file some other program had created. I don't mind displaying my
>ignorance here, for your point about the different approaches to
>files illustrates the tradeoffs well, you trade security for flexibility.
Security for flexibility??? How does security get involved here???
>My gripe was that I had to determine the modes before I could open
>the file, not let some utility tell me the modes.
You do not have to determine modes I fyou plan on reading a file, just SYS$GET.
Your example also fails on Unix. Try to have a 'vanilla' program that will
read a B-tree file that it does not have knowledge of. If you do not
have the library routines available, you are not able to access the file in
a knowledgeable way.
> What if I want to look at the file as a stream of bits? If
>I move the file to a non-VMS system I am stuck. I still have to od
>or dump it in hex to begin to figure out how it is structured and to
>write an application which can treat it as an indexed file. I hope
>that somewhere there is some code that I can install on my foreign
>system just to read RMS indexed files, if I need to do this quickly.
Quite easy... Open the file in block mode...
Why would you want to open an indexed file as such to read the bits does not
make sense whether on VMS or Unix (unless patching something). If you
wish to have a file with a stream of bits, then go for it...
Your argument about having to dump a file is logically flawed. A B-tree file
on Unix has the SAME problem... In fact it is worse because you have no
idea how it is formatted and how to access it. With RMS indexed files you
can extract the records and put them into any file type you wish. Try that
with Unix, without a lot of extra work.
Moving a file from OpenVMS to unix is easy, but moving some B-tree file to
OpenVMS can be very hard unless the tools are provided.
I suggest you read some of the manuals and learn more about the subject before
trying to stand up for Unix. So far you have shown why OpenVMS is
far superios to Unix...
Enjoy,
- mark
Daniel Packman
>...
>The basic point is that even though VMS is a very good OS, then the OS
>for the desktop-market (the OS used to start up word-processors) do not
>need to be so complicated. VMS is simply too good !
This was clearly true, but may not be in the future. Back in the days
of trivial user applications (spreadsheets, desktop publishing, drawing,
and the like) that were used sequentially, a very simple operating system
such as DOS or MAC OS made sense.
Applications emerging now involve multi-media which, since they involve
both video and audio, are intrisically multi-threaded applications. The
standard $2000 or so price point of a personal machine can now include the
memory, processor speed, and storage space that will support an advanced
OS with such applications. Aside from marketing (which is perhaps all
important), VMS would be a fine OS for development of such an environment.
Whatever base system one uses, it would have to be set up in such a way
that system management tasks would occur automatically.
--
Dan Packman NCAR INTERNET: pa...@ncar.UCAR.EDU
(303) 497-1427 P.O. Box 3000
Boulder, CO 80307-3000 NSI/DECNET: 9583::PACK
Carl J Lydick
=Yes, clusters are still very new to other vendors. Those that claim to
=have it don't have all of the functionality.
That's not really a good way of putting it. VAXclusters don't, for example,
have all the functionality of AIX, either, since AIX allows you to migrate a
process to a different machine, while VAXclusters don't allow that.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My
understanding of astronomy is purely at the amateur level (or below). So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it. If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Mike Marler
>VMS is available from only one manufacturer.
Would think that is true of the OS's on a few of IBM's machines as well.
>The hardware (VAX and Alpha) on which VMS runs is available from only one
> manufacturer.
Ditto the above statement. Does that mean that the particular OS is
obsolete or the hardware platform no longer of use?
>VMS doesn't run on PCs.
Doesn't mean that it could not. Don't see any reason to burden the x86
processors with it - probably not the "Power PC" either.
>It's fairly clear that the future lies with personal computers. It's
HEY FRED!! Get on the phone to Equifax, EDS, and all the other
"transaction handling" DP shops and tell them that we can manage
those multi-gigabyte databases on a network of PCs that they can
share with all of the company secretaries. :-) The bus speeds on a
PC are just not acceptable for all applications. (I see that you
work in a physics lab, have you ever thought about trying to do
finite element analysis on a large model on a PC? Ever wanted to
manage a database containing information on your 5000-10000 employee
company and all of its business?)
> also clear the people will want to be able to shop around for software
> and hardware.
Huh? People have been shopping third parties for both since the early
70's with regularity. I don't see what you are saying here. Do you
mean go to Comp USA (well there might not be too many of those in Oxford
but they are "computer department stores" here in the states)? Any person
"worth their salt" will explore trade rags, user groups, computer shows
and "sale weasels" to find multiple possible solutions no matter the
hardware or OS bing used.
cheers, mike
--
Information Technology
Mike Marler Georgia Institute of Technology
mike....@oit.gatech.edu Atlanta, Georgia 30332-0715
David L. Cathey
>>There are no conincidents here, the workaround has been very
>>explicitly developed over a long time.
>
> Its not a workaround. It was a concious design decision.
I'd agree with that sentiment - but for who was the design decision
made???
> You may think its lousy. I for one think it definately is the right way
> to go. The idea of Unix is that if you leave it to the shell, that lets
> users decide how their wildcarding works. Say I wanted my wildcarding to
> work differently--I would simply rewrite my shell. No one else would notice
> anything else. IMHO, putting wildcarding in the shell is one of the best
> ideas Unix came up with.
But you're a programmer. You know how to write your own shell.
Most people, or users, do not know how to write their own shell, and don't
*WANT* to have to write their own shell. Why do you think MS-Windows has
done so well in the marketplace? So they can do work with less knowledge
of how to implement the intricate details of the system, and just simply
get their work done. They want the system to do at least what they expect
rather than an environment that they can program to do what they'd like.
Your sentiment just confirms to me that Unix is a system designed
by programmers for programmers to write programs for other programmers
(hence all the talk about why pipes and filters are so great).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
David L. Cathey |INET: dav...@montagar.com
Montagar Software Concepts |UUCP: ...!montagar!davidc
P. O. Box 260772, Plano TX 75026-0772 |Fone: (214)-618-2117
Larry Mulcahy
xmd...@fs2.dp7up.com retched up these words:
: > 6. Should DEC consider franchising VMS to independent software
: >developers (ISVs) who could add their own enhancements, the way Microsoft
: >has done with MS-DOS or McDonald's has done with their restaurants?
: Would
: >this answer the objection that VMS is proprietary while Unixis not?
: I have heard rumors that DEC will do exactly this. Don't know if it will
: help. Unix supporters will always finda reason to hate VMS it seems.
: Take one away and they'll make up another.
As DEC corrects bugs and design errors, VMS becomes more and more like
Unix. When the last difference between VMS and Unix has been removed
from VMS, VMS will be OK.
--
Larry Mulcahy lmu...@lookout.ecte.uswc.uswest.com
la...@ambient.uucp ambient!la...@mnemosyne.cs.du.edu
GCS d- p--- c++ l++ u+ e++ m n- h+ f? s !g w+++ t r !y
The Failed Clinton Presidency: day 407, 1052 days to go
Larry Mulcahy
(t...@siva.bris.ac.uk) retched up these words:
: Hey I like VMS help and loathe man (havn't seen that one chewed over
: this week yet)!
The thing that used to drive me nuts about VMS help was, it didn't have
all the same details as the printed manual. Like, if you looked at the
on-line help for, say, LIB$TRNLOG it would only give the minimal
information about the parameters needed to construct a call correctly
without the paragraphs of text explaining everything as in the paper
manuals. This was about 4 or 5 years ago, so maybe this has been fixed.
In traditional Unix, the same nroff files are used for the on-line and
printed man pages, though these days there are all kinds of other
options.
Yet another reason why VMS must bow down and do groveling obeisance to
Unix.
Irianto Sukaton
o...@jhuvms.hcf.jhu.
> logic and attempt to make authoritive statements of fact about something they
> are only vaguely aware of. There's plenty of disinformation about computers
> some of it deliberately spread, some of it just spread from ingorance and an
> "I'm an expert on everything" mentality
>
opinions on the subject; experts as well as general and
special interest users. Each person is ultimately the expert
of his/her own system/configuration/workload. Their perception
of how good VMS has served them is the bottom line.
One person's authorative statements is another person's
disinformation. In VMS I think a large part of this is due
to the low-graded learning curve afforded to new users;
who bitch because:
1. They are really computer illiterates who can barely
function in VMS (dead in the water in that other O/S).
2. They have outgrown the low-graded learning curve but
can't put in the time/effort to continue on the
'expert' curve to uncover all the expert features.
Regardless, I don't think they deserve public ridicule; especially
in this case where their comments were invited.
Rouli
is...@andrew.cmu.edu
Standard Discalimer: The views and opinions stated above are mine only
and do not reflect the views of CMU.
Mark A Harrison
> >
> > 7. How can DEC make VMS attractive to the nation's computer science
> >departments?
> Provide shells other than DCL, so that people can have the flexibility to do as
> they wish.... (I love DCL, but TCSH straight on the OS (no posix) would be
> nice.
They already tried. When *I* was in school (the first time) , it was
ALL VMS and Pascal. "Mark," they said, "Don't waste your time on this
Unix stuff. Use a PROFESSIONAL operating system. Don't be like those
smelly hippies. And what's with the C business? You know you can't
build REAL systems with it...."
--
Mark Harrison
mhar...@utdallas.edu
mhar...@spd.dsccc.com
David L. Cathey
> : (This one is opinion :-):) EVE/TPU are a nicer customizable editing system
> : than either vi or emacs. For that matter, the stuff I've built on top of
> : EVE is nicer for what I need to do (environmental modeling: mixed Fortran/C
> : development and maintenance) than LSE, either (with which it is difficult to
> : integrate one's own customizations because of the inadequate documentation.)
>
> Agree, but EDT is better that all of 'em :-)
TECO! TECO! TECO!
(Sorry, couldn't resist!)
David L. Cathey
>> 2. Is VMS losing out to Unix? If so, why? If not, what evidence is
>> there that this is not the case?
>
> Yes. Everything seems to be pointing towards U*X like OS's or to
> a new OS. There are more U*X sites, applications, and
> programmers. The net and US schools are mostly a U*X world. Rumors
> from from DEC sales indicate that they are being instructed to
> market OSF/1 to new sites...VMS is just not competitive.
> Developer after developer is dumping VMS support and many new
> applications (even from DEC) are not being developed for VMS.
Not always. There are some shops that switched to Unix are now
wanting to go back to VMS - Unix just didn't give them what they needed.
> For VMS (no matter how good it is) to remain viable must continue
> to have a critical mass of sites running VMS and constant flow of
> new sites. I believe that VMS has already crossed over the border
> to below the critical mass for viability, and will, inevitably,
> follow that long, slow, spiral to OS oblivion.
I forget the magazine, but VMS is still a growing revenue for
DEC. People are still buying more of it, and there is still new business.
>> 7. How can DEC make VMS attractive to the nation's computer science
>> departments?
>
> Give it away free along with all layered products, support it,
> and sell hardware at a good discount.
I have also posted something along those lines. DEC, are your
listening?
>> 8. How can DEC make VMS attractive to software developers?
>
> Sell VMS to more sites. ya, right.
Some of the are. However, the message from DEC-salespeople is that
VMS is dying - not something that VMS Engineering has been told.
Larry Mulcahy
(b...@Krille.Update.UU.SE) retched up these words:
: VMS commands can also take a list of filenames.
: My point was that UNIX have no idea what a wildcard is.
: If you give an asterisk as a filename to Unix, it will say
: thank you and yes ma'm.
: /bin/sh has been around for quite some time yes. I never said
: that the workaround was invented last year. But it still is
: a workaround because Unix still don't support wildcards in
: filenames.
: In some places, however, you will not get what you thought,
: if you come from a DEC OS to unix.
: Consider that you want to rename a bunch of files from
: <something>.foo to <something>.bar
: In VMS you say RENAME *.foo *.bar
: If you try mv *.foo *.bar in unix, you'll get a nasty surprise.
: mv thinks that all arguments up until the last one is a source
: specification, and the last one is always a destination.
: So, if you don't have any files named <something>.bar, the
: last file named <something>.foo will get clobbered, otherwise
: the last file named <something>.bar, which already exists
: will get clobbered.
: Hmm, sorry about this. Just that I can get a little excited
: when I think about the lousy solution Unix offers to people
: who want wildcards.
Those of you arguing in favor of VMS wildcards are desperately wrong.
There are a couple of issues here so let me take them one at a time.
(1) The shell. In VMS you get DCL. With Unix your vendor probably
gives you sh, csh and ksh, and if you aren't satisfied there's bash,
tcsh and others. So we have the VMS way (bondage) vs. the Unix way
(freedom). In VMS, if you aren't satisfied with what the shell does
with respect to wildcards, grit your teeth and live with what the wise
fathers of DEC have bestowed on you. In Unix, you can take your pick of
the available shells, and source code is available for the free software
ones so you can get what you want one way or another.
(2) Wildcards. It's true that you could get a Unix shell to do it the
way DCL does, but this would be a mistake. The VMS solution is for any
program that needs to be able to handle wildcards on the command line to
be written that way. Some programs are written that way, other's
aren't. So generally, the effects of
$ program *.*
(once you've gone through that burdensome business of defining a foreign
command) are unpredictable. One program will read every file in the
current directory, another will just think you're trying to do something
to a file named `*.*'. It makes good sense to have the
wildcard-expanding code in one place (the shell) rather than in every
single program, or worse, haphazardly there in one program and missing
in another.
(3) Subprocesses. VMS makes a big deal out of creating a subprocess and
redirecting its standard input, output and error; these things are
trivial in any Unix shell. What Unix can accomplish with a simple pipe
or pair of backquotes requires the painful and hamfisted /input=
/output= /error= syntax in DCL. When you combine regular expression
syntax with the find command, Unix leaves VMS in the dust with its
ability to search a directory heirarchy and generate the exact list of
file names you want and either put it on the command line or feed it as
input to another command.
Some operating systems, for example MS-DOS and OS/2, could never do it
the Unix way because they have crippling restrictions on the length of a
command line. I think in MS-DOS it's 128 bytes and in OS/2 256. If
these OSes did it the Unix way they'd get buffer overflows from a
command *
in even a medium-sized directory. In most versions of Unix it's
something like 32K bytes. I wouldn't be surprised if something like
this is going on in VMS, because once you understand the advantages of
having wildcard expansion in the shell, nothing else makes sense.
Carl Fogelin
both entertaining and informative. Now, as to the subject at hand:
being flamed by Carl.
Everyone gets flamed by Carl at one time or another. I wouldn't be
surprised if he did it to Steve Lionel. ;) My butt's been toasted
a couple of times, but you know what? I got my answer, or pointed
where I could get the answer.
So, will he ever be put into my killfile? Nope. I just put up
filters and selectively pull the info out. And, the next time I
post a question, I try to be more technically correct. After all,
most of the stuff he picks on are just the poster being lazy.
---------------------------------------------------------------------------
Carl Fogelin (foge...@pt.cyanamid.com) "All opinions are strictly mine"
Up the long ladder and down the short rope,
To Hell with King Billy and God bless the Pope. -- traditional
Carl J Lydick
=Everyone gets flamed by Carl at one time or another. I wouldn't be
=surprised if he did it to Steve Lionel. ;)
That was just a mild flame, and had to do with an odd interaction between RMS
and FORTRAN.