OpenVMS versus HP-UX
Rob Heyes
I'm very new to HP-UX, I went on my basic system admin course last week
starting from scratch.
Your starter for ten is
Who can convince me it's better than OpenVMS...
Jerry Leslie
: OK people, here's one for you.
You may find more job openings for HP-UX than OpenVMS ?
HP is on a campaign to move everything they can overseas:
http://www.forbes.com/home/2002/12/05/cz_qh_1205hp.html
Forbes.com: The New HP Way: World's Cheapest Consultants
"NEW YORK - Tech giant Hewlett-Packard has seen the future of
technology consulting. It's on the other side of the globe and it's
really, really cheap.
"We're trying to move everything we can offshore," HP Services chief
Ann Livermore told Wall Street analysts at a meeting Wednesday. "We're
aggressively realigning our resources." Short term, that means adding
to the software and services personnel HP (nyse: HPQ - news - people )
already has in India. Further out, HP expects China to also turn into
a major consulting center..."
Tandem maintenance seems to be on its way overseas:
http://trav-tech.com/cgi/testwww/config.pl?read=7297
HP moving Tandem maintenance offshore
Perhaps that means HP sees a future for their Tandem offerings ?
--Jerry Leslie (my opinions are strictly my own)
Note: les...@jrlvax.houston.rr.com is invalid for email
No Spam
Rob Heyes wrote:
How would you understand the answer if you don't know
what you are asking?
If you need to run a particular software package which
is available for HP-UX, but not for OpenVMS, it would
be obvious that HP-UX is better for that task. The
same holds true in the other direction.
Comparing desktops, the last time I got a quote to
upgrade the core VMS licenses which shipped with my
workstation by default, they wanted three times what
the machine cost when it was new, making it cheaper
to buy a whole new system. Instead of making thousands
for about $5 worth of materials, they probably made
next to nothing if not taking an outright loss on the
second workstation sale. On the other hand, try to
figure out which version of HP-UX you need, then try
to find the part number and price without manually
configuring a whole workstation on the HP web site.
HP doesn't seem any more interested in selling you $5
worth of materials for the $500-$1,000 they'll make
on them, so I guess the companies are well matched :-/
-Steve
Corné Beerse
I cannot say which one is better. I do know some general things about
the past and I have some expectations about the future.
Unix development started before 1970, VMS came around 10 years later.
One of the development reasons I've been told is that Digital wanted to
create an operating system like unix but then targetted at the
profesional/commercial market, where unix was more in the university and
laboratorium areas in those days. By the way, they both started on
Digital hardware...
Unix has many implementations on many platforms, many vendors and there
is many knowledge around the world. VMS is not that wel know and that
wide supported outside the normal support paths. That's also an
advantage: there are not that much vms-hackers around the world...
Since Digital went into Compaq and Compaq went into HP, I think the
future of VMS is a little dark. I don't expect many new vms custommers.
All I saw around me is migrations from vms to various unix variants
(and, o horror, to M$Windows...)
One advantage of VMS: it is real-time or at least has realtime
capabilities. Unix is NOT real-time (by design) and hence a real-time
unix variant is hard to find.
My advice, if you're a starter on both platforms, learn to know them
both and take your advantage.
CBee
Simon Waters
>
> so I guess the companies are well matched :-/
What I can't figure out is if the smiley is because it is the
same company, or because both sales channels are only interested
in selling big boxes, or big numbers.
This thread was done to death last year or start of this year,
and I don't think either technology has been radically
overhauled since, so if you want a technical shootout in tedious
detail... Google back in this list - Ken Green was a key poster.
I think it is academic, GNU/Linux won the battle, I only expect
to see new HP-UX installs in high availability systems, or where
application vendors still haven't done a GNU/Linux port.
No doubt there is still some life in the Desktop workstations
market for HP-UX from CAD/CAM as these vendors have been slow to
port.
Mark Landin
Nobody. Only you can convince yourself. Can you achieve your business
goals (which in most cases is "maximize profit") better using HP-UX or
OpenVMS?
As a former user of outstanding HP operating system which will remain
unnamed, but for a hint starts with M and ends with E with the letter
P somewhere in the middle, in moving to HP-UX I found some things I
liked better and some things I am definitely disappointed in.
Things I like better:
- LVM
- Fullest suite of networking goodies
- Powerful shell scripting
- Wide range of hardware choices
Things that disappoint me:
- Very weak security model
- No kernel-level file locking
- Poor printer / spooling functionality
- Too sensitive to mistuning
- All files are a string of bits. Any abstratction into fields,
records, etc, is done by an application.
Ralf Hildebrandt
> - Very weak security model
> - No kernel-level file locking
> - Poor printer / spooling functionality
I think you can run CUPS on HP-UX.
Robert Gilster
Not to be too harsh, but why would an administrator ask a question like
that? I mean, come on! You have an application that runs on said OS,
you use said OS. You have said platform, you use said OS. You have
PC's, you get rid of that clunky M$ product and go with something better
- ignoring that upstart Linux. The platform that I use is hardly
relevent, its what my customers want and what I happen to have access to
at the cheapest price. Who cares about the OS, they all pretty much do
the same thing just as well as each other.
--
All these opinions are mine,
and are not necessarily shared
by The Boeing Company.
Robert Gilster
Don't you start with me Simon!!
Corné Beerse
I don't know if OpenVMS is available on an other platform/processor than
the Digital ^H^H^H^H^H^H Compaq ^H^H^H^H^H^H HewlettPackard Alpha
processor but I've read roumors the Alpha processor has an end date in
it's near future. I think that will implicitly kill the future of
OpenVMS, despite the strength of the OS.
For HP-UX future, HP has already ported that to a new processor
platform.
CBee
Jerry Leslie
: Rob Heyes wrote:
: >
: > OK people, here's one for you.
: >
: > I'm very new to HP-UX, I went on my basic system admin course last week
: > starting from scratch.
: >
: > Your starter for ten is
: >
: > Who can convince me it's better than OpenVMS...
:
: I don't know if OpenVMS is available on an other platform/processor than
: the Digital ^H^H^H^H^H^H Compaq ^H^H^H^H^H^H HewlettPackard Alpha
: processor but I've read roumors the Alpha processor has an end date in
: it's near future. I think that will implicitly kill the future of
: OpenVMS, despite the strength of the OS.
OpenVMS is being ported to the Intel Itanium processor.
There is a committment to the U.S. Department of Defense for OpenVMS
to be supported for 20 years:
http://www.openvms.compaq.com/solutions/government/coe/index.html
DII COE
"Commitment to DII COE initiative provides long-term support
and application portability for OpenVMS customers
Renowned for its stability, reliability and scalability, OpenVMS has
been the longtime operating system of choice for defense contractors.
To reinforce and maintain this position in the defense industry,
OpenVMS on AlphaServer systems will comply with a Department of
Defense set of specifications, known as the Defense Information
Infrastructure Common Operating Environment (DII COE).
[snip]
As part of the DII COE initiative, OpenVMS Engineering is enhancing
some OpenVMS interfaces commonly available on UNIX systems. This
improves the ease of porting UNIX applications to OpenVMS. More
importantly, many government bids require an official commitment from
the vendor to support the platform for up to 20 years. In these cases,
HP has made this commitment, thus reassuring OpenVMS customers of the
integrity and long-term viability of their OpenVMS investment."
: For HP-UX future, HP has already ported that to a new processor
: platform.
:
OpenVMS is being ported to the Intel Itanium processor. That and
the information on the Alphas are available at:
http://h18003.www1.hp.com/hps/ipf-enterprise/
Alpha Systems Division
Ken.Green
>
> No Spam wrote:
> >
> > so I guess the companies are well matched :-/
>
> What I can't figure out is if the smiley is because it is the
> same company, or because both sales channels are only interested
> in selling big boxes, or big numbers.
>
> This thread was done to death last year or start of this year,
> and I don't think either technology has been radically
> overhauled since, so if you want a technical shootout in tedious
> detail... Google back in this list - Ken Green was a key poster.
>
We weren't really argueing about which was best, we were discussing
whether you can have a distributed buffer cache and still have
decent latency times
Ken.Green
>
> On Sun, 15 Dec 2002 16:41:04 +0000 (UTC), "Rob Heyes"
> <robert...@btinternet.com> wrote:
>
> >OK people, here's one for you.
> >
> >I'm very new to HP-UX, I went on my basic system admin course last week
> >starting from scratch.
> >
> >Your starter for ten is
> >
> >Who can convince me it's better than OpenVMS...
>
> Nobody. Only you can convince yourself. Can you achieve your business
> goals (which in most cases is "maximize profit") better using HP-UX or
> OpenVMS?
>
> As a former user of outstanding HP operating system which will remain
> unnamed, but for a hint starts with M and ends with E with the letter
> P somewhere in the middle, in moving to HP-UX I found some things I
> liked better and some things I am definitely disappointed in.
>
> Things I like better:
> - LVM
> - Fullest suite of networking goodies
> - Powerful shell scripting
> - Wide range of hardware choices
>
> Things that disappoint me:
> - Very weak security model
> - No kernel-level file locking
What's wrong with Unix's file locking ?
Rob Heyes
"Corné Beerse" <bee...@lycos.nl> wrote in message
news:3dfef066$0$230$4d4e...@read.news.nl.uu.net...
Michael Kraemer
> Mark Landin wrote:
> >
> > Things that disappoint me:
> > - Very weak security model
> > - No kernel-level file locking
>
> What's wrong with Unix's file locking ?
it virtually doesn't exist.
flock() and friends do not implement mandatory locks.
In my experience you can hardly prevent an app to read a file while
it is being modified by, say, vi.
Another experience is that on the various systems the availability
of the lock daemon (rpc.lockd) is at the will of the sysadmin.
I've seen programs freeze on one system (no lockd) which worked
on others flawlessly (w/ lockd).
In addition, I've seen trouble with locks over NFS.
All this makes the use of locks under UNIX a game of luck rather
than reliable programming.
Heck, even a quasi-dead OS like AmigaOS has a better locking mechanism
than UNIX.
Corné Beerse
There is nothing wrong with unix file locking. Most problems in that
area are the file locks in networked file systems. For those I see no
advantage of kernel-level file locking.
>
> > - Poor printer / spooling functionality
Now I'm on it, there are many printer/spooling fascilities to choose
from in the unix area. 2 main-stream variants to start with. Which is
poor? Why are they poor?
Comparing to vms printer spooling: is the vms printer spooling as
powerfull and jet as flexible as the unix variant? Can it coop with the
unix printer spooling? Can it coop with all the printers unix can work
with?
> > - Too sensitive to mistuning
I read that as: more tuning options............
> > - All files are a string of bits. Any abstratction into fields,
> > records, etc, is done by an application.
Not realy, there are blocks ;-)
Then, what's the use of an OS that has to keep track of the type of file
in use? The OS only has to handle the stream of bits, either bit by bit,
byte by byte or block by block.
The unix view on the world has proven it's power:
1) A file is a seqential stream of bytes.
2) everything can be represented as a file.
With this, every tool that can handle a file can hanlde everything. And
since most (if not all) tools can be used on a file, they can be used on
everything.
Have you ever played with filesystems in a file? (like building and
using iso images) Unix can do it since it can handle filesystems. I've
done it in the '80s: create a filesystem in a file (or copy it from a
floppy), mount that filesystem, handle files in there and finaly dump
the file back to disk.
CBee
Robert Gilster
I'd like an example of what you mean. As a VMS administrator and a UNIX
administrator I can't think of anything significantly different about
their two functionalities.
Mark Landin
<beerse@not_read.zonnet.nl> wrote:
>>
>> What's wrong with Unix's file locking ?
>
>There is nothing wrong with unix file locking. Most problems in that
>area are the file locks in networked file systems. For those I see no
>advantage of kernel-level file locking.
You can't see an advantage in having mandatory kernel-level file
locking available? Do you enjoy living in fear that no matter what you
try, you cannot prevent another process from deleting the file you are
currently editing?
Mark Landin
wrote:
>Mark Landin wrote:
>>
>> On Sun, 15 Dec 2002 16:41:04 +0000 (UTC), "Rob Heyes"
>> <robert...@btinternet.com> wrote:
>>
>> >OK people, here's one for you.
>> >
>> >I'm very new to HP-UX, I went on my basic system admin course last week
>> >starting from scratch.
>> >
>> >Your starter for ten is
>> >
>> >Who can convince me it's better than OpenVMS...
>>
>> Nobody. Only you can convince yourself. Can you achieve your business
>> goals (which in most cases is "maximize profit") better using HP-UX or
>> OpenVMS?
>>
>> As a former user of outstanding HP operating system which will remain
>> unnamed, but for a hint starts with M and ends with E with the letter
>> P somewhere in the middle, in moving to HP-UX I found some things I
>> liked better and some things I am definitely disappointed in.
>>
>> Things I like better:
>> - LVM
>> - Fullest suite of networking goodies
>> - Powerful shell scripting
>> - Wide range of hardware choices
>>
>> Things that disappoint me:
>> - Very weak security model
>> - No kernel-level file locking
>
>What's wrong with Unix's file locking ?
It's largely advisory, not mandatory. Like Dopey hanging the key to
the mine next to the door, it only keeps out honest processes.
Mikko Nahkola
Well, duh. Yes, that's how it works indeed.
However, this also means that you don't get the problem with someone
sitting on the mandatory lock for something you'd require ... and the
particularly interesting deadlocks that can happen with that scheme.
--
Mikko Nahkola <mikko....@nokia.com>
My ideas, not my employer's. No warranty. YMMV.
#include <disclaimer.h>
Paul Repacholi
> What's wrong with Unix's file locking ?
What locking? Unix's `locking' is like giving the burglars the keys
and asking them to lock the door when they arive.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Dan Mercer
Are you talking permissions or file locking? Locking prevents
access or modification of file data by one process while it's
being used by another. The burglar remark really doesn't make sense
either way.
--
Dan Mercer
dame...@mmm.com
If responding by email, include the phrase 'from usenet'
in the subject line to avoid spam filtering.
Opinions expressed here are my own and may not represent those of my employer.
Alan D Johnson
Jerry,
Thanks for the response about VMS, I was wondering what HP was going to
do with it I started out many years ago on VMS, before it was "open" and
always liked working on it, unfortunately I had to make a choice many
years ago if I want to be a VAX admin or a UNIX admin. As far as VMS
goes it has always been a stable, robust platform, I used to do work for
a company that did DOD contracts and they loved it because it was so.
But the critical mass is not VMS, it is some form of UNIX. That is were
the real applications are and that is what companies want because it
does have such wide appeal and support. Honestly, IF I could afford it I
would rather work on VMS systems, but economics do not permit it.
Sigh... It would be real nice if we could all do what we really want to
do, wouldnt it?
Jerry Leslie
:
: Jerry,
:
: Thanks for the response about VMS,
You're welcome.
: I was wondering what HP was going to do with it I started out many years
: ago on VMS, before it was "open" and always liked working on it,
The "Open" was added when VMS became available on the Alpha, as
a marketing buzzword prevalent at the time; e.g. OpenMVS/JES 3 and
OpenWallet.
: unfortunately I had to make a choice many years ago if I want to be
: a VAX admin or a UNIX admin.
I was involved in VMS for mission-critical applications such as process
control and scada; e.g.:
http://www.seattleweekly.com/features/0002/tech-scigliano.shtml
Seattle Weekly - tech: A worm in the works
"Could disasters loom as more and more pipeline operators switch
to Windows NT?
"...NTSB spokesman Keith Holloway did confirm last fall that "the
computer virus [sic] is one [potential factor] we're looking into."
But not one that's likely to pan out. That's because, according to
Olympic IT manager Dan Swathman, the pipeline's SCADA system does
not run on Windows, which might have made it vulnerable to the
e-mail-borne Worm.Explore.zip: "Our current SCADA system is on VMS,
from Digital Equipment [now Compaq], running on an Alpha Chip. GMI
makes the system. A couple computers are dedicated to it." And,
Swathman adds, these computers are not connected to the Windows-based
e-mail and office systems through which the worm could have gotten in.
That's reassuring--but the broader picture may not be. Across this
country, and as far away as China, pipeline systems are switching from
VMS and Unix systems to versatile, ubiquitous, user-friendly Windows
NT. "The scada market has been moving towards Windows NT as the
dominant operating system," Oil & Gas Journal reported (3/24/97)..."
The systems in use at the time of the explosion were VAXes not Alphas.
The upgrade to dual-cpu Alphas, a later version of the scada software,
OpenVECTOR, and BEA MessageQ, happened last year. I was a member of
the team that performed the upgrade.
: As far as VMS goes it has always been a stable, robust platform, I used
: to do work for a company that did DOD contracts and they loved it because
: it was so. But the critical mass is not VMS, it is some form of UNIX.
The supercritical mass is a nuclear aircraft carrier at the bottom
of the ocean, thanks to its Windows-based "Smart Ship" system:
http://www.gcn.com/vol19_no27/dod/2868-1.html
Navy carrier to run Win 2000
"September 11, 2000; Vol. 19 No. 27
The Navy's next-generation aircraft carrier will use Microsoft Windows
2000 to run its communications systems, aircraft and weapons
launchers, and other ship electronics.
The CVN 77, one of the Navy's nuclear-powered aircraft carriers, will
run Microsoft Windows 2000 for a variety of communications and weapons
systems..."
http://www.cnn.com/2000/TECH/computing/08/08/carrier.windows.idg/
CNN.com - Technology -
Futuristic Windows version to control aircraft carrier - August 8, 2000
"...The CVN-77 win is a key triumph for Microsoft in the defense
industry, because it sets the stage for the company's participation in
the Navy's long-term, three-phase future carrier design program. "This
is not just the one ship. It will decide the architectures for the
next three ships," Roach said. Microsoft's agreement also includes a
back-fit program for seven other carriers, bringing the total to 10."
: That is were the real applications are and that is what companies want
: because it does have such wide appeal and support.
And almost s good multi-site "share everything" cluster technology
as VMS has:
http://www.openvms.compaq.com/openvms/brochures/commerzbank/
hp Alphaserver technology helps Commerzbank tolerate disaster
on September 11
: Honestly, IF I could afford it I would rather work on VMS systems, but
: economics do not permit it.
: Sigh... It would be real nice if we could all do what we really want to
: do, wouldnt it?
:
It would be real nice if the U.S. IT industry wasn't leading the exodus
of jobs out of the country:
http://www.forbes.com/home/2002/12/05/cz_qh_1205hp.html
Forbes.com: The New HP Way: World's Cheapest Consultants
"NEW YORK - Tech giant Hewlett-Packard has seen the future of
technology consulting. It's on the other side of the globe and it's
really, really cheap.
"We're trying to move everything we can offshore," HP Services chief
Ann Livermore told Wall Street analysts at a meeting Wednesday. "We're
aggressively realigning our resources." Short term, that means adding
to the software and services personnel HP (nyse: HPQ - news - people )
already has in India. Further out, HP expects China to also turn into
a major consulting center..."
HP's not alone in that sentiment:
http://www.siliconvalley.com/mld/siliconvalley/4332783.htm
Mercury News | 10/21/2002 | Slowdown sending tech jobs overseas
"The U.S. economy might be stalling, but at least one niche is hot:
shipping technology jobs offshore.
The economic slowdown is speeding up the export of jobs, experts say.
As executives face smaller budgets and more pressure for profits, they
find it much cheaper to send work to contractors overseas. More U.S.
companies are following Silicon Valley's lead by shifting engineering
and other technology-related jobs to places such as China, Ireland,
India and the Philippines to cut costs.
The drift of jobs is worrying engineering groups, renewing fears that
white-collar tech jobs in the United States are going the way of
blue-collar manufacturing jobs: over the border and across the seas.
[snip]
Labor experts say no one knows how many engineering jobs the United
States has lost because of the recent uptick in offshore outsourcing..."
The last statement is no surprise, since there is NO government agency
mandated to track offshore job relocations and their impact on tax
revenues.
http://www.zdnetindia.com/news/national/stories/70849.html
US to move 3.3 Million jobs offshore by 2015: Forrester
"Altogether 3.3 million US jobs in the services sector and $136 billion
in wages are expected to move offshore to countries like India,
Russia, China and the Philippines by 2015 according to a recent report
of research and consulting firm Forrester Research.
The report adds that the IT industry will lead the initial overseas
exodus..."
Even some medical specialties such as radiologist are being 'globalized';
e.g. American-trained radiologists in Bangalore, India, now interpret the
xrays of patients in Massachusetts General Hospital.
Offshore teledermatology and offshore telepsychiatry aren't far off.
Teaching in the form of offshore distance education or tele-education
is being discussed:
http://pib.nic.in/feature/feyr2000/fapr2000/f180420001.html
INVESTMENT OPPORTUNITIES IN INDIAN TELECOM SECTOR
"...There will be several other opportunities for service providers
in applications like telebanking, telemedicine, teleeducation,
teletrading and e-Commerce..."
Alan D Johnson
Jerry,
Thats real interesting that you were doing SCADA stuff on it, me 2, I
used to work on GE Cimplicity on VMS, HP and Interactive Unix, then they
started doing Windows and I saw the writing on the wall. AFA HP is
concerned I was trying to get my foot in the door, but they don't quite
seem to have it together yet from a Support perspective yet, they have
lots of new support people from the merger but %99.9 of the "new"
service people are Windoze tech's Not the kind of person I would want
coming to work on my Production HP systems " Lets see how do you turn
this on again?, oh just reboot it that will fix the problem! ;-) " I'm
certainly glad I don't have to support the Fleet systems any more....
Jerry Leslie
: started doing Windows and I saw the writing on the wall. AFA HP is
: concerned I was trying to get my foot in the door, but they don't quite
: seem to have it together yet from a Support perspective yet, they have
: lots of new support people from the merger but %99.9 of the "new"
: service people are Windoze tech's Not the kind of person I would want
: coming to work on my Production HP systems " Lets see how do you turn
: this on again?, oh just reboot it that will fix the problem! ;-) " I'm
: certainly glad I don't have to support the Fleet systems any more....
VMS was the third process control platform for Shell Oil. Previously,
Shell used:
o Modcomp minis, running a version of Union Carbide's FLIC software
o Honeywell GE/PAC 4000-series, running a Shell-written process control
package.
One of the GE/PAC 4010s is still in production controlling a coker
at a plant in the Long Beach area now owned by Phillips Petroleum.
This system was installed ~1975, and received a new disk controller
in 1983. Another 4010 is used for parts.
NASA recently cancelled a project to upgrade the Shuttle's launch control
systems which are Modcomps with an IBM-written operating system:
http://www.space.com/missionlaunches/fl_clcs_020918.html
NASA Kills 'Wounded' Launch System Upgrade at KSC
I dug up some background on those Modcomps:
http://www.hq.nasa.gov/office/pao/History/computers/Ch7-3.html
The shuttle launch prosessing system
Before joining Shell in 1967, I worked for TRW Systems on the Apollo
program.
Too bad NASA's spinoffs don't get more publicity:
http://vesuvius.jsc.nasa.gov/er/seh/spinoff.html
THE BEST OF NASA'S SPINOFFS
Laser Angioplasty
Cardiac Imaging System
Advanced Pacemaker
Implantable Heart Aid
Body Imaging
Computer Reader for the Blind
Ocular Screening System
Advanced Wheelchair
Radiation-Blocking lenses
Collision Avoidance System (for aircraft)
Self-Righting life Raft
Weather Information Processing
Corrosion-Resistant Coating
Air/Wastewater Purification Systems
Heat Pipes for the Alaska Pipeline
Cordless Products
Stratch-Resistant Sunglass Coating
Structural Analysis (NASTRAN)
Clean Room Apparel
That doesn't include CorningWare, made from the same material developed
for the Mercury, Gemini, and Apollo capsules' heat shields, or a system
to allow flight control of a plane with NO hydraulics, such as the DC-10
that crashed in Sioux City Iowa:
PCA (Propulsion Controlled Aircraft)
http://www.dfrc.nasa.gov/Projects/PCA/
http://www.dfrc.nasa.gov/Projects/PCA/md11.html
MD-11 PCA Flight Accomplishments
Frank Slootweg
[deleted]
> VMS was the third process control platform for Shell Oil. Previously,
> Shell used:
Please note that "Shell Oil" != "Shell". Shell Oil is 'only' the
(North?) American branch of Shell.
The rest of Shell used CDC and later, guess what? :-), HP1000's, for
which the development was done in Shell's 'home' country, The
Netherlands, by, amongst others, yours truly.
Frank "One and a half years at the real Shell!" :-) Slootweg
Ken Gren
> In article <3DFF6411...@kgcc.co.uk>, "Ken.Green" <Ken....@kgcc.co.uk> writes:
>
>>Mark Landin wrote:
>>
>>>Things that disappoint me:
>>>- Very weak security model
>>>- No kernel-level file locking
>>
>>What's wrong with Unix's file locking ?
>
>
> it virtually doesn't exist.
> flock() and friends do not implement mandatory locks.
Yes they do
the type of lock you get depends on the file permissions
> In my experience you can hardly prevent an app to read a file while
> it is being modified by, say, vi.
Well vi doesn't lock the file... it doesn't even hold it open
it reads the file when you ask it to and it writes in when you
ask it to do that, why would it want to hold a file open when
it's not using it ?
> Another experience is that on the various systems the availability
> of the lock daemon (rpc.lockd) is at the will of the sysadmin.
Argh, now we are out of the realm of Unix and into NFS, NFS does
not and never has passed SVID. Lets face it isn't even coherent.
> I've seen programs freeze on one system (no lockd) which worked
> on others flawlessly (w/ lockd).
> In addition, I've seen trouble with locks over NFS.
> All this makes the use of locks under UNIX a game of luck rather
> than reliable programming.
> Heck, even a quasi-dead OS like AmigaOS has a better locking mechanism
> than UNIX.
Perhaps you read the AmigaOS manual better than you read the Unix
one.
Michael Kraemer
> >
> > it virtually doesn't exist.
> > flock() and friends do not implement mandatory locks.
>
> Yes they do
> the type of lock you get depends on the file permissions
>
>
> > In my experience you can hardly prevent an app to read a file while
> > it is being modified by, say, vi.
>
> Well vi doesn't lock the file... it doesn't even hold it open
> it reads the file when you ask it to and it writes in when you
> ask it to do that, why would it want to hold a file open when
> it's not using it ?
>
Of course there's no need to hold a lock after a file is read.
But what happens during the short time when vi writes back the file contents ?
It should ask for an exclusive write lock, which should be rejected if
somebody else holds a read lock. This is the way it works on most OSes
I know ( Amiga, OS/2, MVS, VMS ), except UNIX.
My problem isn't restricted to vi, it's just the most prominent example:
One app reads data, while another app may trash it.
To prevent that, you need properly working locks, right ?
If you can show me a way how to accomplish that on UNIX
with 100% reliability, I'd be happy.
>
> > Another experience is that on the various systems the availability
> > of the lock daemon (rpc.lockd) is at the will of the sysadmin.
>
> Argh, now we are out of the realm of Unix and into NFS, NFS does
> not and never has passed SVID. Lets face it isn't even coherent.
Oh come on, this is nitpicking. NFS nowadays is as much part of UNIX
as X11, TCP/IP etc. As an app programmer I don't care which part of
an OS causes the trouble.
Apart from that, the locking problem has little to do with NFS
(this makes it only worse, since with NFS you have 2 points of possible
failure).
> > I've seen programs freeze on one system (no lockd) which worked
> > on others flawlessly (w/ lockd).
> > In addition, I've seen trouble with locks over NFS.
> > All this makes the use of locks under UNIX a game of luck rather
> > than reliable programming.
> > Heck, even a quasi-dead OS like AmigaOS has a better locking mechanism
> > than UNIX.
>
> Perhaps you read the AmigaOS manual better than you read the Unix
> one.
>
Well, I'm usually a UNIX advocate rather than an Amiga (let alone VMS) advocate,
but there are a few design flaws (IMHO) that are really braindead (IMHO).
In my experience locking is one of them.
Rick Jones
> Things that disappoint me:
> - Very weak security model
> - No kernel-level file locking
By "kernel-level" do you happen to mean "enforcement-mode?" I noticed
this in the 11.22 (11i 1.6) manpage for lockf(): (actually it seem to
be there in 11i 1.0 - 11.11) as well)
lockf(2) lockf(2)
NAME
lockf - provide semaphores and record locking on files
SYNOPSIS
#include <unistd.h>
int lockf(int fildes, int function, off_t size);
DESCRIPTION
The lockf() function allows regions of a file to be used as
semaphores (advisory locks) or restricts access to only the
locking process (enforcement-mode record locks). Other
processes that attempt to access the locked resource either
return an error or sleep until the resource becomes unlocked.
All locks for a process are released upon the first close of the
file, even if the process still has the file opened, and all
locks held by a process are released when the process
terminates.
...
Regular files with the file mode of S_ENFMT, not having the
group execute bit set, will have an enforcement policy enabled.
With enforcement enabled, reads and writes that would access a
locked region sleep until the entire region is available if
O_NDELAY is clear, but return -1 with errno set if O_NDELAY is
set. File access by other system functions, such as exec(), are
not subject to the enforcement policy. Locks on directories,
pipes, and special files are advisory only; no enforcement
policy is used.
I suspect not as comprehensive as one might like, but it isn't
strictly advisory at least.
rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
Jerry Leslie
The scada software on the VMS systems was a joint project between
Shell Oil (U.S.) and Royal Dutch Shell. Its name was PROSS II.
Frank Slootweg
> Frank Slootweg (fra...@neth.hp.com) wrote:
> : Jerry Leslie <LES...@jrlvax.houston.rr.com> wrote:
> : [deleted]
> : > VMS was the third process control platform for Shell Oil. Previously,
> : > Shell used:
> :
> : Please note that "Shell Oil" != "Shell". Shell Oil is 'only' the
> : (North?) American branch of Shell.
> :
> : The rest of Shell used CDC and later, guess what? :-), HP1000's, for
> : which the development was done in Shell's 'home' country, The
> : Netherlands, by, amongst others, yours truly.
> :
> : Frank "One and a half years at the real Shell!" :-) Slootweg
> :
> The scada software on the VMS systems was a joint project between
> Shell Oil (U.S.) and Royal Dutch Shell. Its name was PROSS II.
Oh, I see. That was after *my* Shell days. I worked on PROSS (no
numerals, i.e. 'PROSS I'). I don't remember the years off-hand, but
probably through 1982.
Ken Gren
> In article <3E01F272...@kgcc.co.uk>, Ken Gren <Ken....@kgcc.co.uk> writes:
>
>>>it virtually doesn't exist.
>>>flock() and friends do not implement mandatory locks.
>>
>>Yes they do
>>the type of lock you get depends on the file permissions
>>
>>
>>
>>>In my experience you can hardly prevent an app to read a file while
>>>it is being modified by, say, vi.
>>
>>Well vi doesn't lock the file... it doesn't even hold it open
>>it reads the file when you ask it to and it writes in when you
>>ask it to do that, why would it want to hold a file open when
>>it's not using it ?
>>
>
>
> Of course there's no need to hold a lock after a file is read.
> But what happens during the short time when vi writes back the file contents ?
> It should ask for an exclusive write lock, which should be rejected if
> somebody else holds a read lock. This is the way it works on most OSes
> I know ( Amiga, OS/2, MVS, VMS ), except UNIX.
> My problem isn't restricted to vi, it's just the most prominent example:
> One app reads data, while another app may trash it.
> To prevent that, you need properly working locks, right ?
> If you can show me a way how to accomplish that on UNIX
> with 100% reliability, I'd be happy.
>
OK, vi wasn't designed for locking, you use something like RCS for that :-)
If you you want mandatory locks rather than advisory ones you set the
SGID permission on the file. You can have read/shared locks or
write/private locks. So whats the problem ?
>
>>>Another experience is that on the various systems the availability
>>>of the lock daemon (rpc.lockd) is at the will of the sysadmin.
>>
>>Argh, now we are out of the realm of Unix and into NFS, NFS does
>>not and never has passed SVID. Lets face it isn't even coherent.
>
>
> Oh come on, this is nitpicking. NFS nowadays is as much part of UNIX
> as X11, TCP/IP etc. As an app programmer I don't care which part of
> an OS causes the trouble.
> Apart from that, the locking problem has little to do with NFS
> (this makes it only worse, since with NFS you have 2 points of possible
> failure).
Well you might expect NFS to be part of Unix, but it doesn't behave like
it. If you want reliability you don't use NFS.
If your using NFS it doesn't matter what operating system you use it
won't give you reliable locking. I don't see how you can have a good
locking system with a stateless design. Locking by it's very nature is a
statefull operation.
>
>
>>>I've seen programs freeze on one system (no lockd) which worked
>>>on others flawlessly (w/ lockd).
>>>In addition, I've seen trouble with locks over NFS.
>>>All this makes the use of locks under UNIX a game of luck rather
>>>than reliable programming.
>>>Heck, even a quasi-dead OS like AmigaOS has a better locking mechanism
>>>than UNIX.
>>
>>Perhaps you read the AmigaOS manual better than you read the Unix
>>one.
>>
>
>
> Well, I'm usually a UNIX advocate rather than an Amiga (let alone VMS) advocate,
> but there are a few design flaws (IMHO) that are really braindead (IMHO).
> In my experience locking is one of them.
I think that there are problems with many implementation of locking on
Unix (including HP-UX's implementation), but I don't think you hit them.
As Richard Stevens pointed out in his book on Unix system call
programming, many implementations actually implement end relative locks
by converting them to start relative locks at the time the lock is
requested rather than at the time they are granted. So if two processes
attempt to lock the end of the file, with the intention of appending
data to the end of the file, one will be granted the lock at the end of
the file, it can then grow the file and release it's lock. The other
process is then granted the lock from where the end of the file used to
be. The real problem here is that there is no guarenteed atomic method
for the process to have discovered where that will have been.
IMHO the only designed problem with the Unix file locking implementation
is that there is no way for a process to find out what locks it has in
a file, short of starting a child to scan the whole file lockking for
them :-(
Cheers
Ken
Michael Kraemer
>
> OK, vi wasn't designed for locking, you use something like RCS for that :-)
>
> If you you want mandatory locks rather than advisory ones you set the
> SGID permission on the file. You can have read/shared locks or
> write/private locks. So whats the problem ?
>
It's not the problem of vi vs other editors.
It's the basic problem of locking a file that should be read
against *any* concurrent write accesses ( be it vi or any other app a user might
come up with).
Changing file permissions by a process that is supposed to only *read*
that file is no good idea IMHO.
Why can't file locking on UNIX work just like on the other OSes ?
(where you don't even need explicit locks: open a file for read
and it's off limits for writes)
>
> Well you might expect NFS to be part of Unix, but it doesn't behave like
> it. If you want reliability you don't use NFS.
so which remote file system do you propose ?
> If your using NFS it doesn't matter what operating system you use it
> won't give you reliable locking. I don't see how you can have a good
> locking system with a stateless design. Locking by it's very nature is a
> statefull operation.
>
My bitching was originally about the mess of local/remote lock daemons,
which might run on one system but not on another.
This makes reliable lock programming a nightmare (in addition to the
troubles mentioned above).
Lock daemons should either run always (as part of the kernel) or never.
Robert Gilster
So fix it. The beauty of UNIX is that you can fix problems that you see
to be a stumbling block. So go on, physician heal thyself.
Jerry Leslie
:
: My bitching was originally about the mess of local/remote lock daemons,
: which might run on one system but not on another.
: This makes reliable lock programming a nightmare (in addition to the
: troubles mentioned above).
: Lock daemons should either run always (as part of the kernel) or never.
VMS has a distributed lock manager, DLM, that handles share-everything
clusters.
Jerry Leslie
: > The scada software on the VMS systems was a joint project between
: > Shell Oil (U.S.) and Royal Dutch Shell. Its name was PROSS II.
:
: Oh, I see. That was after *my* Shell days. I worked on PROSS (no
: numerals, i.e. 'PROSS I'). I don't remember the years off-hand, but
: probably through 1982.
You missed all of the fun.
I missed part of it for a couple of process analyzer projects on
Modcomps, and a project for a new disk controller on the GE/Honeywell
GE/PAC 4000-series process control computers.
Ken Green
> In article <3E02DE8...@kgcc.co.uk>, Ken Gren <Ken....@kgcc.co.uk> writes:
> >
> > OK, vi wasn't designed for locking, you use something like RCS for that :-)
> >
> > If you you want mandatory locks rather than advisory ones you set the
> > SGID permission on the file. You can have read/shared locks or
> > write/private locks. So whats the problem ?
> >
>
> It's not the problem of vi vs other editors.
> It's the basic problem of locking a file that should be read
> against *any* concurrent write accesses ( be it vi or any other app a user might
> come up with).
> Changing file permissions by a process that is supposed to only *read*
> that file is no good idea IMHO.
This design means that the owner of the file decides whether locks
are mandatory or advisory, this is surely a better way to work than to
have the user decide.
>
> Why can't file locking on UNIX work just like on the other OSes ?
>
OK it's been a lot of years but as far as I remember the IBM mainframe
OS's didn't have mandatory locks, at the OS level, they were implemented
at a higher level, and systems programmers could ignore/bypass them
> (where you don't even need explicit locks: open a file for read
> and it's off limits for writes)
>
Now thats just down right suicidal, have you ever heard of a denial
of service attack?
If any user with read permission can stop all other jobs writing to the
file then anyone could easily ... say stop people from changing their
password.
Also if opening a file for reading stopped all writes to the file then
concurrent access programming would not be possible. It implies
that the only level of locking that should be allowed is whole file.
Or are you implying that all concurrent access needs to occur from
files opened read write! that would be worse you'd have to give all the
users write permissions on your files.
Even if the user does have write permission, they should only open
with read permissions if they only intent to read from this file, it
reduces accidental writes.
On HP-UX even the ability to use read only locks is a restictable
privilege to stop users with read access messing things up for others.
>
> >
> > Well you might expect NFS to be part of Unix, but it doesn't behave like
> > it. If you want reliability you don't use NFS.
>
> so which remote file system do you propose ?
>
> > If your using NFS it doesn't matter what operating system you use it
> > won't give you reliable locking. I don't see how you can have a good
> > locking system with a stateless design. Locking by it's very nature is a
> > statefull operation.
> >
>
> My bitching was originally about the mess of local/remote lock daemons,
> which might run on one system but not on another.
>
Well that applies to almost anything
NFS might or might not be there. It's a useful remote file access utility
but anyone who cares about security will avoid it.
Even TCP/IP is optional.
If a certain feature is required for your software to work, make it a pre-req.
> This makes reliable lock programming a nightmare (in addition to the
> troubles mentioned above).
Look if you use NFS you can not do reliable remote concurrent access OK
NFS is not coherent. Different clients can see different data in the same
place in the same file at the same time. It doesn't matter about your locks
it's just part of being a stateless design where caching is allowed, the client
and server don't know what each other are doing, and the clients don't even
know about each other.
(Actually the server doesn't know about the clients either)
>
> Lock daemons should either run always (as part of the kernel) or never.
Much of the implementation of NFS is in user space, not kernel space.
If things should either always be there of never then their would be no options
in the world. SysAdmins configure their systems to meet their (or their companies)
needs.
Matthew Perdue
> <...snip...>
> As a former user of outstanding HP operating system which will remain
> unnamed, but for a hint starts with M and ends with E with the letter
> P somewhere in the middle, in moving to HP-UX I found some things I
> liked better and some things I am definitely disappointed in.
>
> Things I like better:
> - LVM
> - Fullest suite of networking goodies
> - Powerful shell scripting
> - Wide range of hardware choices
>
> - Very weak security model
> - No kernel-level file locking
> records, etc, is done by an application.
And let's not forget an award winning database system integral to the
operating system at no additional cost (TurboImage) or some additional
cost (Image/SQL). Oh, yes, no O/S upgrades that require you to
completely recompile your application(s), application scalability
without recompiling, and on and on and on. Also it was the first
commercial business systems computer HP made.
Greg Cagle
> Oh, yes, no O/S upgrades that require you to
> completely recompile your application(s),
We've had this discussion before - you are evidently still laboring
under the misconception that HP-UX requires an application recompilation for
an OS upgrade. Why do you keep saying this?
--
Greg Cagle
gregc at gregcagle dot com
Mark Landin
<hp...@hillcountry.net> wrote:
>Mark Landin wrote:
>> <...snip...>
>> As a former user of outstanding HP operating system which will remain
>> unnamed, but for a hint starts with M and ends with E with the letter
>> P somewhere in the middle, in moving to HP-UX I found some things I
>> liked better and some things I am definitely disappointed in.
>>
>> Things I like better:
>> - LVM
>> - Fullest suite of networking goodies
>> - Powerful shell scripting
>> - Wide range of hardware choices
>>
>> Things that disappoint me:
>> - Very weak security model
>> - No kernel-level file locking
>> - Poor printer / spooling functionality
>> - Too sensitive to mistuning
>> - All files are a string of bits. Any abstratction into fields,
>> records, etc, is done by an application.
>
>And let's not forget an award winning database system integral to the
>operating system at no additional cost (TurboImage) or some additional
>cost (Image/SQL).
To be fair, TurboImage is far from "no additional cost". You *can*
order a non-TI MPE system, and it is much cheaper. The fact that the
the cost for Image is included in the "usual" configurations on the
CPL doesn't mean it's free.
>Oh, yes, no O/S upgrades that require you to
>completely recompile your application(s), application scalability
>without recompiling, and on and on and on.
This is somewhat bogus. Recompiles are *sometimes* needed, but not
*always*. Agreed, life on MPE is much nicer in that regard, but HP-UX
is not a total loser in this area.
Mark Landin
wrote:
>
>>
>> http://www.cnn.com/2000/TECH/computing/08/08/carrier.windows.idg/
>> CNN.com - Technology -
>> Futuristic Windows version to control aircraft carrier - August 8, 2000
>>
>> "...The CVN-77 win is a key triumph for Microsoft in the defense
>> industry, because it sets the stage for the company's participation in
>> the Navy's long-term, three-phase future carrier design program. "This
>> is not just the one ship. It will decide the architectures for the
>> next three ships," Roach said. Microsoft's agreement also includes a
>> back-fit program for seven other carriers, bringing the total to 10."
"Enemy aircraft is 210 miles out, Sir"
"Launch the Alert 5 aircraft!"
Ensign clicks on Catapult Wizard and selects appropriate catapult,
then select "Next".
"Sir, the CATAPULT.DLL is corrupt. Request permission to load media
and reboot".
Dennis Handly
: > (where you don't even need explicit locks: open a file for read
: > and it's off limits for writes)
: Now thats just down right suicidal, have you ever heard of a denial
: of service attack?
: If any user with read permission can stop all other jobs writing to the
: file then anyone could easily ... say stop people from changing their
: password.
You need to think outside the HP-UX box. The MPE OS, allowed various
types of sharing, with and without locking. Also it allowed exclusive
and read exclusive. Locking and exclusive access needed an extra
capability (lock) on the file. Of course you still could have DoS attacks.