dropping VAX in favor of UNIX :-(
gg...@cctr.umkc.edu
in favor of their Computer Scienc dept's request that the mainframe switch
to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
if this potential change goes through.
Are there any knockdown-dragout arguments against this, arguments that a
University administrator would understand? And perhaps, some arguments that
he WOULDN'T understand, but would drive the folks from Comp. Sci. up the
wall when they couldn't make the administrator understand the rebuttal,
either?
My friend and I know that the move is a serious error. But we'd like to
be able to convince the administrator of this, too.
You know, put his job on the line... that sort of thing.
George Gale
Prof.
UMKC
Barry Treahy
positions because you can get quality hardware and software that runs,
without interruption, for months on end for practically nothing (eg. FREE
software licenses). VMS, unlike UNIX, offers robustness that is uncompared.
I started with VMS 1.6. If I could justify the expense structure in my
shops, and win the arguments, I'd still be running it. The problem is that
DEC kills everyone with the HIGH pricing in the commercial arena (both the
licensing and maintenance). When I compare the cost to setup and run a VMS
machine vs. a UNIX machine, the VMS is much more expensive. Granted that it
takes less time to setup and maintain a VMS box, the financial aspect weighs
very heavy.
The problems in the commercial arena could be a very strong argument to drop
it in the educational arena. It was utterly useless for me to learn how to
key-punch cards on a old IBM (at SDSU 15 years ago) when computer shops
where using CRT's and interactive systems. Why should universities teach on
VMS when the 'industry' is shifting to MS Windows & NT & UNIX!
I frankly hate MS WindowsXXX and still feel that VMS is hands-down a better
OS than UNIX will every dream to be.
Brendan Welch, W1LPG
> A friend of mine tells me that her Univ. admin is thinking of dropping VMS
> in favor of their Computer Scienc dept's request that the mainframe switch
> to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
> if this potential change goes through.
We too are going through this.
Certainly you cannot argue with success; Unix has succeeded; even I
accept that begrudgingly.
My boss says that the higher-ups think we have become too aligned with
DEC. (And I have been chagrined to see that DEC's PC's have not been
as highly rated as I would have thought, in magazine reviews.)
Part of the problem is, IMHO, the rapid growth of the Internet.
When I pointed out a recent Byte review that top-rated an Alpha Server
(higher in the product line than the one we just got), at least my boss
had me make a photocopy for his records.
Even VMS is difficult for lots of students. But a great percentage of
what they want to do nowadays can be done on PC's. I still cannot
see a command-line-oriented Unix as being the basis of anything
for the masses.
--
Brendan Welch, system analyst, UMass/Lowell, W1LPG, wel...@woods.uml.edu
fair...@sldb4.slac.stanford.edu
> A friend of mine tells me that her Univ. admin is thinking of dropping VMS
> in favor of their Computer Scienc dept's request that the mainframe switch
> to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
> if this potential change goes through.
>
> University administrator would understand? And perhaps, some arguments that
> he WOULDN'T understand, but would drive the folks from Comp. Sci. up the
> wall when they couldn't make the administrator understand the rebuttal,
> either?
>
> My friend and I know that the move is a serious error. But we'd like to
> be able to convince the administrator of this, too.
> You know, put his job on the line... that sort of thing.
With a great deal of hesitancy, I'll throw in my 2 cents...
Most university administrators understand cost, cost and cost.
So here are a few cost arguments (with a seasoning of reasons behind
those costs).
The cost of administering it, i.e., people's salaries.
When SLAC's "central computing strategy" targeted the move to
unix, there were numbers of committee meetings and "outside
reviews", etc. (as is the norm in a government funded laboratory...
spreads the guilt I suppose). I was amazed that the outside
reviewers feelings, and these are unix advocates/experts, that it
takes at least twice and more like three times as many people to
administer a unix system as we know it takes to administer a VMS
system. That get increased as you add support for different
vendor's unices. The reviewers were surprised at "how well" we were
doing in our move to unix with the numbers of people involved. From
the users' perspective, that move was not (is not?) going so well...
Next, all your campus users will have to be totally retrained.
They will see this as a withdrawal of services, a lowering of their
standard of living if you will, having to deal with tcsh, emacs, no
version numbers on files, etc. I won't say more on that front
because it really depends on what compilers and editors your campus
users use. It is clear to me that if you're participating in CSLG,
your software costs will increase, possibly enormously, and if you
can't justify a demand for a certain product, you'll lose it on
unix. Figure to spend a fair penny purchasing and licensing Frame,
for example, as the "standard" word processor. Forget LSE. Forget
a common interface to most commands (DCL), every "command" is
independently "crafted" to use its own set of switches. Forget any
sort of consistency or easy-to-remember set of command names, or
automatic truncation of verb names, etc.
So, your help desk staff will need to be expanded and retrained.
More salary costs.
Lastly, you're going to lose reliability.
Does your university depend on these machines for personnel or
payroll? Oooooo, there can be BIG costs if those systems are
unavailable.
Now I know that there are unix shops that keep their systems up
and secure. But I sure haven't seen that here (on the unix side).
For starters, forget about VMS BACKUP. You'll have to roll-your-own
with tar or some such. The result here is that the unix systems
aren't backed up as frequently as the VMS systems, and the maximum
retention of unix backups is less than on VMS systems (I don't fully
understand why, philosophy?).
You'll need unix gurus to constantly patch security holes, holes
that unix vendors continue to ship standard with their products
(think sendmail).
Your unix "mainframe" will be down much more often than your VMS
systems, for a variety of reasons (some server systems here are now
rebooted every weekend, or every other weekend, to clear "problems"
that I can't fathom...but rebooting is the "solution").
No clustering. All systems must be upgraded independently.
There are some improvements from some vendors that allow remote
upgrades, but forget the VMS way: upgrade one node in the cluster,
reboot the cluster, your're done.
Maybe that wasn't the last thing. Make sure your higher-ups
know that OpenVMS/Alpha is the same price as DEC UNIX/Alpha, and
that the Alphas are right on the mark in cost/performance ratio
against other vendors. Anyone tells you that unix software, for
example, is cheaper is full of it as most unix vendors do not ship
their good C or Fortran compilers with the O/S, etc. Unix layered
products will either be free, GNU, etc., but unsupported (so that's
more salaries), or it's commercial and just as expensive or more
than the equivalent on VMS (especially if you've got CSLG).
One question: what does your Comp.Sci. department need with a
"unix mainframe" and why are they trying to dictate campus policy?
Are they responsible for administering it? What's wrong with their
Sun workstations? They want an Alpha 8400 Model 5/333 running DEC
UNIX for what?! :-)
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Chris Olive
>A friend of mine tells me that her Univ. admin is thinking of dropping VMS
>in favor of their Computer Scienc dept's request that the mainframe switch
>to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
>if this potential change goes through.
>
>Are there any knockdown-dragout arguments against this, arguments that a
>University administrator would understand? And perhaps, some arguments that
>he WOULDN'T understand, but would drive the folks from Comp. Sci. up the
>wall when they couldn't make the administrator understand the rebuttal,
>either?
>
>My friend and I know that the move is a serious error. But we'd like to
>be able to convince the administrator of this, too.
>You know, put his job on the line... that sort of thing.
My experience has been that these sorts of decisions are *seldom* made
(nor even first advanced) based on technical merit alone, but rather have
a political mix that is difficult if not almost impossible to overcome
depending on your level of position and involvement in the decision making
process. One nearly sure fire way of determining this is going ahead and
doing your homework. Based on side-by-side comparisions (platform
stablity and viability, support dollars, training, transition
requirements, ease-of-use, power, etc), if it's clear the VMS box "wins,"
but you end up losing anyway, you can bet the decision was NOT based on
technical and sensible-dollars merit. It may even lead you to believe the
decision was already made, and the "committee" mock-up was just to fulfil
the "democratic requirements" (hardly the first time that has happened).
Depending on your culture and political environment your mileage may vary.
I would think you would have to have a very open-minded and somewhat
(though not thoroughly) technically-minded administrator to over come the
evident tidal-wide of media which thwarts true technical prowness in favor
of the continuous output from the Microsoft marketing department and the
various Unix camps.
My advice (assuming you are going to go ahead and do your homework) is to
remember that your battle will not be fought, more than likely, on the
technical front alone, and to go into "your fight" with that in mind.
BTW, one of my worst VMS setbacks ever came at the hands of a fickle and
over-policitally inclined university Asst. Vice President.
Good luck.
Chris
--
Chris Olive
...VMS is *still* BLISS...
Oli...@usaor.net
Ashley Shepherd
>In article <009A0664.7...@CCTR.UMKC.EDU>, gg...@CCTR.UMKC.EDU writes:
>> A friend of mine tells me that her Univ. admin is thinking of dropping VMS
>> in favor of their Computer Scienc dept's request that the mainframe switch
>> to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
>> if this potential change goes through.
>We too are going through this.
>Certainly you cannot argue with success; Unix has succeeded; even I
>accept that begrudgingly.
I am in the fortunate position of having "played", over the last 14
years, with every major operating system (VMS, UNIX, MVS, VME, OS/400,
Netware, NT (Client & Server), DOS, Windows, PICK etc.) and I can
appreciate the dilema you all have. There is no doubt that UNIX is
here to stay, which is unfortunate because apart from MVS it is the
most unusable Operating System I've had the misfortune to use.
The areas you need to concentrate on in your arguements are :-
1) SECURITY, unless you spend a lot of money on third-party
security products, and even more money in terms of man-hours to set up
and administer these products, UNIX's security is very poor. The
problem is that as UNIX is a "standard"? manufacturers have to be
careful about what extras they put in, and at present security is not
a strong point of UNIX. In an educational establishment where you are
likely to have lots of potential hackers the last thing you need are
students hacking in to view exam papers or alter their grades.
Believe me, it is easier to hack a UNIX system these days than it is
to sit and study for your exams. Does your head of dept. really want
someone posting that confidential memo to the principal posted on
everyone's terminal? Admittedly these can also happen under VMS, but
it is much less likely than under a UNIX based system.
2) USABILITY, UNIX is a real sod to learn, admittedly, its
command line can be quite powerful if you manage to remember all those
obscure commands and switches, but I've only found a couple of really
committed technical staff who can get the best out of the UNIX command
line. To get your users to move from VMS to UNIX will be a real
nightmare, I hope you can afford to hire all the extra support staff
you'll need. Under VMS most commands are quite clear, if you want to
print a document you use the PRINT command, or at worst you type HELP
PRINT and you get a very intelligent and useful response. Under UNIX
the command is LPR and to get help you type MAN.
3) COST, to move to UNIX you will need to buy more hardware and
software, this will mean downtime, extra training costs for the
systems admin staff. A real bag of worms in which the costs will keep
on spiralling. As a rule of thumb, whatever you estimate the cost of
moving from VMS to UNIX to be, you must at least DOUBLE it in hidden
costs.
4) WHY MOVE, I find companies and all manner of other
organisations VERY frustrating, they are throwing out perfectly good
systems in favour of UNIX, just because UNIX was the latest craze, at
the moment it happens to be Windows NT. I'm not saying don't ever
change, I'm saying THINK about WHY. If you have new business needs
that require new applications, go out and find the best application
first, only then should you think about changing the hardware. You
should never change because of the latest craze, this is a recipe for
disaster.
I hope this helps
Ashley
>*****************************************************
>Ashley Shepherd
>Integrated Business Support Services Ltd
>email to 10044...@compuserve.com
>*****************************************************
Chris Olive
fair...@sldb4.slac.stanford.edu wrote:
> Most university administrators understand cost, cost and cost.
> So here are a few cost arguments (with a seasoning of reasons behind
> those costs).
>
> The cost of administering it, i.e., people's salaries.
>
> Next, all your campus users will have to be totally retrained.
>
> So, your help desk staff will need to be expanded and retrained.
> More salary costs.
>
> Lastly, you're going to lose reliability.
>
> Does your university depend on these machines for personnel or
> payroll? Oooooo, there can be BIG costs if those systems are
> unavailable.
>
> with tar or some such. The result here is that the unix systems
> aren't backed up as frequently as the VMS systems, and the maximum
> retention of unix backups is less than on VMS systems (I don't fully
> understand why, philosophy?).
>
> You'll need unix gurus to constantly patch security holes, holes
>
> Your unix "mainframe" will be down much more often than your VMS
>
> [selected snipped throughout quoted text]
Why people never count some of the things Ken mentions here is beyond me.
You've *got* to count all these things -- retraining, support,
*maintenance* (not just with the vendor, but all around), the cost added
*unreliability* brings (sometimes tremendous depending on what your
current systems are supporting -- and you*will* have more down-time with
Unix than VMS GAURANTEED), transition dollars, ADDED SALARIES, sometimes a
salary restructuring (Unix gurus aren't cheap), etc.
I am in a commercial environment that is making the change from VMS to
Unix. The problems are *unbelievable*. But the higher ups are bent bound
and determined to see it through. Downtime is every other day ON A GOOD
WEEK (vs. I have seen heavily loaded VMS systems up for 6 months straight
or longer), backups are a headache and unreliable (if you have to recover
something you can count on about 20% of what you want being unrecoverable
-- why? I don't know...), commands are terse and non-conforming (as Ken
mentions). You name the area, and there are problems gallore.
I remember one evening when a large processing site (we have 7 in major US
cities) went down with the new Unix imaging system in beta on 2 or 3
customers, all other customers were still running on the "legacy" VMS
platforms. Bam! The power goes out. Oh, talk about problems on the Unix
side. You shutdown a Unix system cold and you're looking at some *major*
file system problems. And now remember those unreliable backups? Now
what do you do? It took over 8 hours (and I don't know how much money we
lost -- could have been hundreds of thousands or in the millions) to get
the Unix system breathing again and we were *still* on the operating table
for a while after that. The VMS systems? Up and running in 30
minutes... You figure it out.
Ohhhh! But we *have* do Unix. Things will be better when we're done and
we'll save LOTS of money on "open systems." Really now?
And before some Unix advocate chimes in with "you must not have true Unix
people who know what they are doing," the 8-hour long Unix revivial was
being handled by people from a partnered development corporation who cut
their teeth on Unix. It's all they know, and I admit, for Unix people,
are very knowledgable. But it still took them over eight hours, whereas
the VMS systems were brought up by simple VMS operators -- no systems
admin. required!
Jerry Leslie
[ snip ]
: I remember one evening when a large processing site (we have 7 in major US
: cities) went down with the new Unix imaging system in beta on 2 or 3
: customers, all other customers were still running on the "legacy" VMS
: platforms. Bam! The power goes out. Oh, talk about problems on the Unix
: side. You shutdown a Unix system cold and you're looking at some *major*
: file system problems. And now remember those unreliable backups? Now
: what do you do? It took over 8 hours (and I don't know how much money we
: lost -- could have been hundreds of thousands or in the millions) to get
: the Unix system breathing again and we were *still* on the operating table
: for a while after that. The VMS systems? Up and running in 30
: minutes... You figure it out.
: Ohhhh! But we *have* do Unix. Things will be better when we're done and
: we'll save LOTS of money on "open systems." Really now?
: And before some Unix advocate chimes in with "you must not have true Unix
: people who know what they are doing," the 8-hour long Unix revivial was
: being handled by people from a partnered development corporation who cut
: their teeth on Unix. It's all they know, and I admit, for Unix people,
: are very knowledgable. But it still took them over eight hours, whereas
: the VMS systems were brought up by simple VMS operators -- no systems
: admin. required!
Prediction time:
Sometime in the next 5-10 years, a Fortune 1000 company will go out
of business, because loss of financial data on a unix system, due
to incomplete, or faulty backups.
--Jerry,
Gerald (Jerry) R. Leslie Aspen Technology, Inc. (my opinions are my own)
jerry....@aspentech.com jle...@dmccorp.com gle...@isvsrv.enet.dec.com
`Open Systems' means they want your wallet to open' -- G. Collyer
Arne Vajhoej
> in favor of their Computer Scienc dept's request that the mainframe switch
> to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
> if this potential change goes through.
>
> University administrator would understand? And perhaps, some arguments that
> he WOULDN'T understand, but would drive the folks from Comp. Sci. up the
> wall when they couldn't make the administrator understand the rebuttal,
> either?
>
> My friend and I know that the move is a serious error. But we'd like to
> be able to convince the administrator of this, too.
> You know, put his job on the line... that sort of thing.
It will cost a large sum of money during the change:
- new software licenses
- training of support staff
- training of users
- downtime
It is doubtfull that it will save money after the change:
- cost of CPU power is the same for Unix and VMS
- disks/memory may be more expensive on VMS, if you are not using third party
products which is much cheaper than Digital
- the basic software is much cheaper on VMS (because you can get CSLG, it
is probably the other way around for commercial sites)
- third-party software will probably cost the same
- expenses for support will increase (VMS is simply easy to manage)
Regarding functionality after the change:
- you will get more software to choose from (especially for Internet
stuff will you find more software bot commercially and free
for Unix than for VMS)
- you will get more downtime and more problems (VMS is rock-solid)
Basicly I can not see the change appears especially attractive !
Arne
Arne Vajhøj local DECNET: KOPC::ARNE
Computer Department PSI: PSI%23831001354030::ARNE
Southern Denmark Business School Internet: AR...@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
Charles Onstott
> wel...@woods.uml.edu (Brendan Welch, W1LPG) wrote:
>
> I am in the fortunate position of having "played", over the last 14
> years, with every major operating system (VMS, UNIX, MVS, VME, OS/400,
> Netware, NT (Client & Server), DOS, Windows, PICK etc.) and I can
> appreciate the dilema you all have. There is no doubt that UNIX is
> here to stay, which is unfortunate because apart from MVS it is the
> most unusable Operating System I've had the misfortune to use.
I'm going to take the unpopular (for this list) view and
defend UNIX. My intention is not to start an OS holy war
on the VMS list, but to suggest that the change isn't
all that bad.
First, the statement that "UNIX is one of the
most unusable operating systems" is simply false. Considering
the fact that UNIX has been ported to nearly every known
architecture from x86's, Alpha's, and even Cray's, you gain
a high degree of portability as well as freedom in selecting
hardware that you simply do not have in the VMS world. In
addition, the sheer number of applications available for UNIX
makes it a good candidate in terms of flexibility.
UNIX's primary strengths are: true symbolic linking (much
better than VMS' implementation), highly integrated internet
TCP/IP protocols, the fact that it treats almost everything
as a file and has the ability to have filesystems of
any type written (as for how radical this can get,
check out the proc filesystem ala SunOS or Linux), peformance, and
portability. It's primary weaknesses are security and initial ease of use.
You'll find that UNIX is every bit as stable as VMS, so you
won't need to worry about additional downtime.
>
> The areas you need to concentrate on in your arguements are :-
>
> 1) SECURITY, unless you spend a lot of money on third-party
> security products, and even more money in terms of man-hours to set up
> and administer these products, UNIX's security is very poor. The
> problem is that as UNIX is a "standard"? manufacturers have to be
> careful about what extras they put in, and at present security is not
> a strong point of UNIX. In an educational establishment where you are
> likely to have lots of potential hackers the last thing you need are
> students hacking in to view exam papers or alter their grades.
> Believe me, it is easier to hack a UNIX system these days than it is
> to sit and study for your exams. Does your head of dept. really want
> someone posting that confidential memo to the principal posted on
> everyone's terminal? Admittedly these can also happen under VMS, but
> it is much less likely than under a UNIX based system.
This is good advise. UNIX security isn't tremendous, but I also
want to suggest that it isn't that bad either. A good UNIX
system administrator knows the key areas to concentrate on
UNIX security. Primarily, ensure that any UNIX system you
install uses C2 security with some form of a Trusted Computing
Base. This hides password files and allows automatic lockups
of terminal devices in the case of hacking (much in the
manner of VMS). The primary other security problem with
UNIX has to do with its internet capabilities. Any machine which
supports routable protocols and is connected to a large internetwork
(such as the Internet) is subject to the same style of hacking.
VMS is included in this category and it is a mistake to think
it is much better at handling these kinds of security issues.
I would disagree that it is easier for students to hack
a UNIX system than it is to study for a final. Any properly
configured and managed UNIX system is quite secure.
>
> 2) USABILITY, UNIX is a real sod to learn, admittedly, its
> command line can be quite powerful if you manage to remember all those
> obscure commands and switches, but I've only found a couple of really
> committed technical staff who can get the best out of the UNIX command
> line. To get your users to move from VMS to UNIX will be a real
> nightmare, I hope you can afford to hire all the extra support staff
> you'll need. Under VMS most commands are quite clear, if you want to
> print a document you use the PRINT command, or at worst you type HELP
> PRINT and you get a very intelligent and useful response. Under UNIX
> the command is LPR and to get help you type MAN.
While it is true that UNIX has obscure commands, it is more useful to
realize that UNIX is highly configurable. Instead of thinking of it as a
nightmare, it is better to realize that its power is precisely in its
flexibility. For example, if the print command is very important, why not
just create a symbolic link from a command called 'print' in someone's path
to the actual LPR? Or create a script file that emulates VMS style print
commands? It turns out that this kind of scripting is also very useful
when dealing with security issues. Again, an experienced UNIX
administrator knows this and is likely to implement these kinds of
solutions. It may require some re-training to learn the basics of UNIX,
but you are free to customize the system to whatever need you have.
I would also like to point out that new students who
aren't familiar with any kind of command line driven
OS won't find UNIX much harder to learn than VMS. My
experience has been that students using UNIX came from
the DOS world where at least many of the file accessing
concepts still apply. I think you'll find more effort in learning
will be applied on the administrator's end than on the students.
How 'easy to use' the system is has a lot to do with how
the administrator sets things up. A poor or mischevious
administrator can make UNIX a living nightmare, but a good
and devoted adminstrator can make it very easy and appealing.
If you enter into using UNIX with the idea that you don't
like it or don't want it to work (as with anything) it won't
work right and you won't like it. However, if you honestly
approach UNIX, you'll find in the end that it is a rather
impressive system.
Finally, in terms of system administration, things in the UNIX
world have come a long way over the last 10 years. Most
UNIX servers have administration menus and X (graphical) interfaces.
This makes doing what used to be fairly long and drawn out
tasks much quicker to perform.
I would like to point out here that my workstation is a piece
of junk 486/25 with 8 megs of RAM running Linux with X windows
installed. My average uptime is about 14 days with reboots
only occuring whenever I need to boot DOS to use Microsoft
Word. I haven't had Linux (once stabilized) outright
crash on me once. Additionally, my administration time
for my workstation runs at about 1 hour per month which
is primarily checking the postmaster account for bad mail,
reviewing and purging system logging files, and
double checking security parameters. 1 hour a month
is not very much time and, of course, I'm basically the
only user so that in a multi-user environment, this
time would increase considerably. My point here is that
UNIX isn't all that bad in terms of usability.
>
> 3) COST, to move to UNIX you will need to buy more hardware and
> software, this will mean downtime, extra training costs for the
> systems admin staff. A real bag of worms in which the costs will keep
> on spiralling. As a rule of thumb, whatever you estimate the cost of
> moving from VMS to UNIX to be, you must at least DOUBLE it in hidden
> costs.
This is true of any operating system change. At least with UNIX
you aren't tied to a particular vendor, so that you have the freedom
to choose among several different kinds of platforms specific
to various kinds of applications. A well thought out plan
of integration will not result in "spiraling costs" unless
the person making the plan doesn't know what they are doing.
One has to realize that one isn't forced into a particular
product line of either the UNIX implementation or the hardware on which it
runs. This alone can mean considerable cost savings if
the research is done properly.
>
> 4) WHY MOVE, I find companies and all manner of other
> organisations VERY frustrating, they are throwing out perfectly good
> systems in favour of UNIX, just because UNIX was the latest craze, at
> the moment it happens to be Windows NT. I'm not saying don't ever
> change, I'm saying THINK about WHY. If you have new business needs
> that require new applications, go out and find the best application
> first, only then should you think about changing the hardware. You
> should never change because of the latest craze, this is a recipe for
> disaster.
This, too, is good advise. But as you mentioned above, UNIX
is very successful and it may be that the kinds of applications
that are desired are not available under VMS. I'm still
not sure why Windows NT is billed as a craze (you aren't
the first to say this). It hardly has any applications that
run natively on it, its networking protocol isn't impressive,
its administrative utilities aren't terribly powerful, and
the OS is essentially a file server and nothing more. For
an OS that has been around for years and hardly has a user
base, I'm always surprised to see how its the 'latest and
greatest' thing going. I wonder why.
I hope this helps.
Charles
----------
"Wonder is the foundation of all philosophy, inquiry the
progress, ignorance the end." (Montaigne)
John Nunnally
> A friend of mine tells me that her Univ. admin is thinking of dropping VMS
> in favor of their Computer Scienc dept's request that the mainframe switch
> to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
> if this potential change goes through.
>
> Are there any knockdown-dragout arguments against this, arguments that a
> University administrator would understand? And perhaps, some arguments that
> he WOULDN'T understand, but would drive the folks from Comp. Sci. up the
> wall when they couldn't make the administrator understand the rebuttal,
> either?
>
> My friend and I know that the move is a serious error. But we'd like to
> be able to convince the administrator of this, too.
> You know, put his job on the line... that sort of thing.
Add to the other reasons that security is an issue. VMS is much more
secure by design and also because it is not as well known.
But we didn't try to argue this. We took another route - we purchased
a separate machine and gave it to Computer Science for them to run
UNIX. They support it and maintain it. We agreed that they needed to
be teaching UNIX, but we were not willing to move the administrative
systems off VMS for that reason. It has worked out pretty well.
Buying a separate machine was MUCH, MUCH cheaper than the transition
from VMS to UNIX would have been for the rest of the campus.
IMHO, VMS and UNIX will both die of the same disease - old age. If I
can just skip UNIX and move from VMS to whatever replaces them both, I
will be very happy!
John Nunnally
Nunn...@Harding.Edu
John E. Davis
started working with computers as a graduate student in the mid 1980s, the
only computer systems that I had access to were VMS and MVS systems. There
were simply no Unix machines in our department to choose from. Now the
situation is totally reversed. I nolonger have access to VMS. Unix has
totally replaced VMS everywhere I work. Is this a general trend? Are there
any numbers which indicate that my experience is not an isolated one?
Finally,
On 6 Apr 1996 22:09:01 GMT, Chris Olive <Oli...@usaor.net>
wrote:
: I am in a commercial environment that is making the change from VMS to
: Unix. The problems are *unbelievable*. But the higher ups are bent bound
: and determined to see it through. Downtime is every other day ON A GOOD
: WEEK (vs. I have seen heavily loaded VMS systems up for 6 months straight
For me, this is almost unbelievable. For the unix machine that I am logged
onto now (a network fileserver running SunOS), `w' reports:
8:48pm up 127 days, 4:49, 1 user, load average: 1.02, 1.00, 1.00
and on the main server (also running SunOS) doing everything else (network
time daemon, file server, anonymous ftp, httpd,...):
8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
--
John E. Davis Center for Space Research/AXAF Science Center
617-258-8119 MIT 37-662c, Cambridge, MA 02139
http://space.mit.edu/~davis
Tack-K...@ubs.com
I came across your reply meant for someone else. I really appre=
ciate =
the time and effort you spent for these explanations and to share w=
ith
all of us.
I share your exact sentiments about Unix and VMS.
I'm a fresh graduate and back in my school days, we used DEC Ult=
rix =
running on Vaxstations. Now they have switched to HP UX and Sun So=
laris.
I can remember those problematic days trying to port C programs dev=
eloped =
on PC to Ultrix and getting all sort of problem, esp. the Core Dump=
error.
And it's a nightmare just to edit a few lines using VI editor.
Now I'm a 6-month old DEC systems administrator in a bank and I =
really
fell in love with OpenVMS. It's very sad that it is dying a slow =
=
death. As for migration, fortunately, the top guys recently change=
d their
plan of migrating to Unix. Now, the path is OpenVMS Alpha and then=
to =
Cairo Windows NT 2-4 years later.
regards,
peter :)
UBS-Singapore
______________________________ Reply Separator _________________________=
________
Subject: Re: dropping VAX in favor of UNIX :-(
Author: 100440.1227 (10044...@compuserve.com) at zhuxsh
Date: 7/4/96 3:16 AM
wel...@woods.uml.edu (Brendan Welch, W1LPG) wrote:
=
>In article <009A0664.7...@CCTR.UMKC.EDU>, gg...@CCTR.UMKC.EDU wr=
ites: =
>> A friend of mine tells me that her Univ. admin is thinking of droppin=
g VMS =
>> in favor of their Computer Scienc dept's request that the mainframe s=
witch =
>> to UNIX. The whole campus now uses the VAX, and will have to switch t=
o UNIX =
>> if this potential change goes through.
=
>We too are going through this.
=
>Certainly you cannot argue with success; Unix has succeeded; even I =
>accept that begrudgingly.
=
=
=
I am in the fortunate position of having "played", over the last 14 =
years, with every major operating system (VMS, UNIX, MVS, VME, OS/400, =
Netware, NT (Client & Server), DOS, Windows, PICK etc.) and I can =
appreciate the dilema you all have. There is no doubt that UNIX is =
here to stay, which is unfortunate because apart from MVS it is the =
most unusable Operating System I've had the misfortune to use.
=
The areas you need to concentrate on in your arguements are :-
=
1) SECURITY, unless you spend a lot of money on third-party =
security products, and even more money in terms of man-hours to set up =
and administer these products, UNIX's security is very poor. The =
problem is that as UNIX is a "standard"? manufacturers have to be =
careful about what extras they put in, and at present security is not =
a strong point of UNIX. In an educational establishment where you are =
likely to have lots of potential hackers the last thing you need are =
students hacking in to view exam papers or alter their grades.
Believe me, it is easier to hack a UNIX system these days than it is =
to sit and study for your exams. Does your head of dept. really want =
someone posting that confidential memo to the principal posted on =
everyone's terminal? Admittedly these can also happen under VMS, but =
it is much less likely than under a UNIX based system.
=
2) USABILITY, UNIX is a real sod to learn, admittedly, its =
command line can be quite powerful if you manage to remember all those =
obscure commands and switches, but I've only found a couple of really =
committed technical staff who can get the best out of the UNIX command =
line. To get your users to move from VMS to UNIX will be a real =
nightmare, I hope you can afford to hire all the extra support staff =
you'll need. Under VMS most commands are quite clear, if you want to =
print a document you use the PRINT command, or at worst you type HELP =
PRINT and you get a very intelligent and useful response. Under UNIX =
the command is LPR and to get help you type MAN.
=
3) COST, to move to UNIX you will need to buy more hardware and =
software, this will mean downtime, extra training costs for the =
systems admin staff. A real bag of worms in which the costs will keep =
on spiralling. As a rule of thumb, whatever you estimate the cost of =
moving from VMS to UNIX to be, you must at least DOUBLE it in hidden =
costs.
=
4) WHY MOVE, I find companies and all manner of other =
organisations VERY frustrating, they are throwing out perfectly good =
systems in favour of UNIX, just because UNIX was the latest craze, at =
the moment it happens to be Windows NT. I'm not saying don't ever =
change, I'm saying THINK about WHY. If you have new business needs =
that require new applications, go out and find the best application =
first, only then should you think about changing the hardware. You =
should never change because of the latest craze, this is a recipe for =
disaster.
=
I hope this helps
=
Ashley
>***************************************************** =
>Ashley Shepherd =
>Integrated Business Support Services Ltd =
>email to 10044...@compuserve.com
>*****************************************************
=
Christian Knapmeyer
In article <01I39Q6YD...@kopc.hhs.dk> Arne Vajhoej <AR...@ko.hhs.dk> writes:
> It will cost a large sum of money during the change:
> - new software licenses
> - training of support staff
> - training of users
> - downtime
No doubt, that's the normal price you pay when changing your
environment, whether you switch from VMS to Unix, or vice versa.
For the downtime: Of course the system _will_ be down more often while
it is established and configured. But once it is stable you won't have
much more problems than under VMS. ("stable" means of course having a
trained sysadm - I doubt that this differs from VMS)
Believe me, Unix is quite reliable. Another poster just showed the
uptimes for his SunOS fileservers, being up for more than 100 days - I can
confirm these numbers.
>
> It is doubtfull that it will save money after the change:
> - cost of CPU power is the same for Unix and VMS
> - disks/memory may be more expensive on VMS, if you are not using third party
> products which is much cheaper than Digital
> - the basic software is much cheaper on VMS (because you can get CSLG, it
> is probably the other way around for commercial sites)
> - third-party software will probably cost the same
Third-party vendors are more and more dropping the VMS side.
Remember the discussion about Oracle's support policies?
Or about Netscape...?
Same holds for many more companies, bigger and smaller ones.
> Regarding functionality after the change:
> - you will get more software to choose from (especially for Internet
> stuff will you find more software bot commercially and free
> for Unix than for VMS)
> - you will get more downtime and more problems (VMS is rock-solid)
Rock-solid? Hmm... I remember some events here when everybody was
twiddling thumbs cause our VAX fileserver had crashed again due to
overload. ;-) VMS also has its bugs and weaknesses...
>
> Basicly I can not see the change appears especially attractive !
>
I agree, I also won't drop a working system just out of fashion.
The original poster didn't mention the causes that lead to the
intention of doing so. One could argue better if we had these.
> Arne
>
> Arne Vajhøj local DECNET: KOPC::ARNE
> Computer Department PSI: PSI%23831001354030::ARNE
> Southern Denmark Business School Internet: AR...@KO.HHS.DK
> WWW URL: http://www.hhs.dk/~arne/arne.html
>
Greetings,
Christian
--
----------------------------------------------------------------------------
Dipl.-Inform. Christian Knapmeyer Email: kna...@tecmath.de
TecMath GmbH Voice: 06301/606-0 Fax: 06301/606-66
Sauerwiesen 2 Face : Room 115
67661 Kaiserslautern, Germany Disclaimer: as usual
---------- press any key to continue. press any other key to quit.----------
Ron
=>On 6 Apr 1996 22:09:01 GMT, Chris Olive <Oli...@usaor.net>
=>wrote:
=> : I am in a commercial environment that is making the change from VMS to
=> : Unix. The problems are *unbelievable*. But the higher ups are bent bound
=> : and determined to see it through. Downtime is every other day ON A GOOD
=> : WEEK (vs. I have seen heavily loaded VMS systems up for 6 months straight
=>
=>
(snip)
=>and on the main server (also running SunOS) doing everything else (network
=>time daemon, file server, anonymous ftp, httpd,...):
=>--
=>John E. Davis Center for Space Research/AXAF Science Center
=>617-258-8119 MIT 37-662c, Cambridge, MA 02139
=>http://space.mit.edu/~davis
all that this proves, is that, as stated elsewhere in this
thread, a unix system cannot be compared to another unix system, nor
can administrators be compared with oranges.
=>For me, this is almost unbelievable. For the unix machine that I am logged
=>onto now (a network fileserver running SunOS), `w' reports:
=> 8:48pm up 127 days, 4:49, 1 user, load average: 1.02, 1.00, 1.00
=> 8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
hey! 8^) Not bad for a 8 user cluster! 8^) but we casually have
about 200 or 300 people on at a time on our cluster each day....
using LAT, DECNET, and TCP/IP transports, submitting 4-day batch jobs,
OpenVMS V6.2 on node AXP25 8-APR-1996 07:28:50.27 Uptime 126 23:01:03
Pid Process Name State Pri I/O CPU Page flts Pages
2280029F BATCH_1039 CUR 1 1 1025591 0 16:00:23.62 8485516 2734 B
writing their own programs in any of 18 languages, (infinite loops included),
Rlogging in and running X-session screen savers from other hosts
across campus, forgetting to logout, surfing the net, staying up all night
on the muds, and we get INCOMING connection statistics like:
This report covers the period from 1-MAR-1996 00:06:03 to 1-APR-1996 00:04:48.
Total Connections: 293357
Total Locations: 5918
Connections breakdown:
CCTR connections: 3939 1.34%
Campus connections: 223869 76.31%
Internet connections: 65549 22.34%
(Thank the good lord for TGVMultinet) How can you compare operating systems
running in a Non-Academic environment, (like the original question posed)
to those that are? (Not to say that "space" is non-academic, but i happen
to know that the origin of the original questioner's cluster is very
similar to ours, being a central academic hub with several thousand
university student users.)
*************************************************************************
BUT all of THAT noise is from a SYSTEMs point of view.
*************************************************************************
now i have a linux machine at home myself, which runs X, and i work on a
heterogenous VAX/Alpha cluster here at work (academic environment) which
also runs X. And have accounts on several Unix hosts here at the University.
Here are a few of my personal comparisons, from a USER's point of view:
MAN/?/Errors .vs. Bookreader/HELP/Errors
hmmmm, Well with bookreader you start with shelves. Each Shelf is listed
for you by subject matter, may contain other shelves, but it is arranged
in a heirarchical fashion so that one may easily find subject matter in
a matter of minutes, if one had never known the path to the subject matter
before hand. Bookreader is hypertext capable, and is text as well as X
capable. (VTBOOK/MGBOOK).
Man is also text capable as well as X capable, but is not hypertext, and
requires that one either initially know the command that one is looking
for, or the filename (and hence subdirectory) in which the file is kept.
One must play the guessing game to find the subject matter if one does
not already know the path to the subject matter. Fortunately, there is
so little information in MAN (one or two pages per command, and perhaps
500 commands or so, maybe more, i never counted) that one usually bumps
into something that one was looking for days earlier, when looking for
something else.
VMS also has a command called "help", which is a bit similar to MAN, except
that it is also arranged in a heirarchical fashion. There is no similar
program in Unix, or at least, if there is, i have not been able to find
it yet for lack of good documentation. (havent finished reading
all of MAN yet, it could still be in there somewhere) 8^) When a user
types HELP, a screen FULL of commands, and an explanation on how to
use the HELP system appears on the terminal, when a user type MAN however,
they get sumpn like this:
aurora{/users/r/rockwell/unix}42 % man
Usage: man [-] [-M | -P pathname] [-t] [section] title ...
man [-] [-M | -P pathname] [-t] [section title ...]...
man [-M | -P pathname] -f title ...
man [-M | -P pathname] -k keyword ...
Now i remember the old argument that i gave my father 30 years ago about
not being able to look it up in a dictionary because i didnt know how
to spell it, but on a computer, that argument can be taken literally,
and my father's answer, "take a guess", would end up costing me
the usual 30 to 45 minutes that it usually takes, IF i get my answer
at all.
And then there are the error messages. Hmmmmm, on the Unix side, the
standard error message is supplied by the program, so they are all
different in style, but usually they give sumpn like:
aurora{/users/r/rockwell/unix}42 % cp
usage: cp [-fhip] [--] source_file destination_file
or: cp [-fhip] [--] source_file ... destination_directory
or: cp [-fhip] [-R | -r] [--]
[source_file | source_directory] ... destination_directory
now assuming i knew at least the command, and that i am a programmer,
and have read scads of documentation, i am pretty comfortable with the
above, (more or less) but i will still have to resort to MAN to figure out
what -fhip is all about.... on the VMS side:
AXP25 USER:[RROCKWELL] copy
_From: ?
%DCL-W-NULFIL, missing or invalid file specification - respecify
well, its nice enough to ask anyway, and the error is clear. The point is, i
am NOT a newbie, like the 2000 new student accounts i put on every
year. Which would you prefer your 2000 Newbies had to "enjoy"?
...and then there is the graceful commandline, i.e. i can backspace
in a password prompt on a VMS machine, but not on a Unix machine, but
the one i find the most irritating and probably the worst security
hole from a NEW USER's perspective is trying to abort a program:
In VMS, (assuming a non-captive account) i hit Ctrl-Y, and no matter
what it was i was running (interactively) brings me to the command
prompt. But on the Unix host, if i hit Ctrl-Z or Ctrl-C, or Ctrl-D
(it depends on the program.... and thats another real irritating
topic), yes, it indeed brings me back to a command prompt, however,
i am no longer able to log out.
aurora{/users/r/rockwell/unix}51 % logout
There are stopped jobs.
aurora{/users/r/rockwell/unix}52 % grrrrr....
grrrrr....: Command not found.
aurora{/users/r/rockwell/unix}53 % vi
This is usually caused by Ctrl-Z me thinx, which all "trained" VMS
users have burnt into their habitual fingers as a way to get out of
an editor.
~
~
~
~^Z
Stopped
aurora{/users/r/rockwell/unix}55 % bummer...
bummer...: Command not found.
aurora{/users/r/rockwell/unix}56 % logout
There are stopped jobs.
aurora{/users/r/rockwell/unix}56 % goto 52
The fact that the Unix online documentation is so poor, only tells
me that the problems will be perpetuated to no certain end. Now if
Unix had good documentation, then it would probably not be that bad.
But i actually read that kind of thing, unlike my 2000 new users
each year.
Now this may not seem like an important issue, compared to the other
issues raised in this thread, like money, downtime, porting, and the like.
However, my point is, that there will be 6 to 8000 people or more that will
be faced with these problems. Students of Biology, and Chemistry, and
Econ majors, etc... The original question stated that it was the computer
Science department, i believe, that was making the "push" to unix, but
at least on our campus, we try to make it EASY for our users to get their
work done, and do not have the opinion that they should all learn to
have to become programmers by the time they graduate (assuming they were
able to get their work done in the first place). it would make ZERO sense
to actually have to PAY a lot of money to make things hard on our users
and support staff, just to say that we were "groovy" and in the "trend",
as someone else in this thread had suggested....or were perhaps running
the "latest" OS, (...still has major bugs, eh?)... i still have not heard
one GOOD reason to switch.... face it. if it aint broke. dont fix it.
go ahead and flame me, i give up. 8^) But, since there are only 8 users
on your "cluster" you can probably ask eachother questions when it comes
time to figure out how to logout, and probably all trust eachother if
you cannot.... gotta go now, have to make a call to the sysop on aurora
to have her stop my stopped processes... 8^)
R_Rockwell, UMKC/ACS;
Ron
=> > It is doubtfull that it will save money after the change:
=> > - cost of CPU power is the same for Unix and VMS
=> > - disks/memory may be more expensive on VMS, if you are not using third party
=> > products which is much cheaper than Digital
=> > - the basic software is much cheaper on VMS (because you can get CSLG, it
=> > is probably the other way around for commercial sites)
=> > - third-party software will probably cost the same
=>
=>Third-party vendors are more and more dropping the VMS side.
=>Remember the discussion about Oracle's support policies?
=>Or about Netscape...?
=>Same holds for many more companies, bigger and smaller ones.
=>
> Arne
>
> Arne Vajh�j local DECNET: KOPC::ARNE
> Computer Department PSI: PSI%23831001354030::ARNE
> Southern Denmark Business School Internet: AR...@KO.HHS.DK
> WWW URL: http://www.hhs.dk/‾arne/arne.html
>
Greetings,
Christian
--
----------------------------------------------------------------------------
Dipl.-Inform. Christian Knapmeyer Email: kna...@tecmath.de
TecMath GmbH Voice: 06301/606-0 Fax: 06301/606-66
Sauerwiesen 2 Face : Room 115
67661 Kaiserslautern, Germany Disclaimer: as usual
---------- press any key to continue. press any other key to quit.----------
if one had to choose an operating system based on how many other
people were writing third party software for it, one may as well
become a lemming. case in point: there is an awful lot of third
party software for DOS, just ask Bill Gates.
Bear in mind this IS NOT a thread about "VMS is better than Unix is
better than DOS", it is a thread about whether or not to take an already
functioning VMS Cluster, with several thousand already productive users,
in a working academic environment, offline, and replace it with a not yet
existent, "what may perhaps look okay on paper" system running unix.
for what point? Third party software? By the time everyone was retrained
on how to use the unix system, one could have already written their own
software on the VMS side. (heh heh, read my comments on how long it
will take to "learn" unix for the type of users we are discussing) 8^)
in analogy, i have an old car, it will die someday, but i doubt that
i will be trading it in for a bicycle anytime soon. i dont know how
to ride one, even though everyone on the block owns a bicycle, and
in the interim, if my wife or kids need to go anywhere, they dont
need to learn how to ride a bike, when they can still borrow my car,
as they are accustomed to doing.
imho, the idea about giving the Computer Science department its own
Unix boxes, above and beyond the already functioning system was the
best reply to the question yet. Adding Unix boxes to an already functioning
VMS Cluster would only enhance the cluster. The user account space could be
NFS mounted, from VMS to the Unix systems, allowing the VMS system to
handle diskquota and closing security holes on the Unix boxes. The
local filesystem on the Unix boxes being untouchable. And the user
would be able to share his data between the two systems (same directory).
easy maintenence, easy accounting, the only retraining would be the
users who "wanted" to move over to the Unix side. Why force the issue?
R_Rockwell, UMKC/ACS;
Videoman
>In article <009A0664.7...@CCTR.UMKC.EDU>, gg...@CCTR.UMKC.EDU writes:
>> A friend of mine tells me that her Univ. admin is thinking of dropping VMS
>> in favor of their Computer Scienc dept's request that the mainframe switch
>> to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
>> if this potential change goes through.
>We too are going through this.
<...>
>--
>Brendan Welch, system analyst, UMass/Lowell, W1LPG, wel...@woods.uml.edu
If UML does get rid of their VAXen, what will they do with them? If
they're just going to dump them, then would they consider donating
them to someone that might be able to use one? Like me, perhaps? (I
grew up hacking VAXen in HS, so I've grown somewhat attached to them.)
+---GAMES---ARCADE---CONSOLE---IBM-PC---PROGRAMMING---HACKS---LINKS---+
| Videoman's World - The Grand Opening countdown has begun! (30) |
+-----> http://www.tiac.net/users/videoman/ <-----+
Arne Vajhoej
> > - new software licenses
> > - training of support staff
> > - training of users
> > - downtime
>
> No doubt, that's the normal price you pay when changing your
> environment, whether you switch from VMS to Unix, or vice versa.
True. This was also what I wrote.
> For the downtime: Of course the system _will_ be down more often while
> it is established and configured. But once it is stable you won't have
> much more problems than under VMS. ("stable" means of course having a
> trained sysadm - I doubt that this differs from VMS)
>
> Believe me, Unix is quite reliable. Another poster just showed the
> uptimes for his SunOS fileservers, being up for more than 100 days - I can
> confirm these numbers.
A few examples prove nothing. Consider it analytical. OS writers try
to write the OS as the users want it (I sure hope so). There is
rarely "free" improvements. Often it is a choice between reliability/robustness
and performance/ressource-usage. VMS systems are dominated by multi-user
systems and server systems. Those system-managers gives absolute
priority to reliability. Most UNIX variants has work-stations as the
largest user-group. And those people will often give priority to
performance. Ofcourse then VMS developers is more concerned about
reliability than the typical UNIX developer.
The PC environment is less concerned with reliability than UNIX people
(look at a program like DOUBLESPACE for a good example). The classic
mainframe environment is even more concerned with reliability than VMS
people. It is a matter of what the customers want.
> > It is doubtfull that it will save money after the change:
> > - cost of CPU power is the same for Unix and VMS
> > - disks/memory may be more expensive on VMS, if you are not using third party
> > products which is much cheaper than Digital
> > - the basic software is much cheaper on VMS (because you can get CSLG, it
> > is probably the other way around for commercial sites)
> > - third-party software will probably cost the same
>
> Third-party vendors are more and more dropping the VMS side.
> Remember the discussion about Oracle's support policies?
> Or about Netscape...?
> Same holds for many more companies, bigger and smaller ones.
I am comparing price here. Availability is dealt with later. Actually
a few lines below.
> > Regarding functionality after the change:
> > - you will get more software to choose from (especially for Internet
> > stuff will you find more software bot commercially and free
> > for Unix than for VMS)
> > - you will get more downtime and more problems (VMS is rock-solid)
>
> Rock-solid? Hmm... I remember some events here when everybody was
> twiddling thumbs cause our VAX fileserver had crashed again due to
> overload. ;-) VMS also has its bugs and weaknesses...
I have never heard of a VAX chrash due to overload !
It can chrash though - and for some reason more than half of theese
happends with UCX ! :-(
Arne
Arne Vajhøj local DECNET: KOPC::ARNE
Computer Department PSI: PSI%23831001354030::ARNE
Southern Denmark Business School Internet: AR...@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
mat...@seqaxp.bio.caltech.edu
>A friend of mine tells me that her Univ. admin is thinking of dropping VMS
>in favor of their Computer Scienc dept's request that the mainframe switch
>to UNIX. The whole campus now uses the VAX, and will have to switch to UNIX
>if this potential change goes through.
Our campus computing organization recently did the same thing. In my
opinion, it was a silly thing to do, not because of any Unix vs. VMS
reasons, but because 99% of the system usage on either OS is just mail and
news reading. Since PC/Mac mail and news clients are a dime a dozen, and
all the users access the central system from PCs and Macs anyway, we could
very well have trimmed the center down to a single departmental size core
server, the OS of which would have been of no importance for the users,
since they would never have had to log into it directly.
That this did not happen is, as others have pointed out, largely due to
political rather than to technical analysis. For instance, one of the
rationales for the VMS cluster shutdown was that they did not have enough
personnel to maintain both the Unix and VMS systems. That is fair enough
as far as it goes, but how many people would it have taken to maintain a 3
node OpenVMS cluster running as a MAIL and NEWS server? I estimate one
person half time - and most of that would just be account and newsgroup
scut work. In terms of reliability and cost, well, no point preaching to
the choir.
The computer science division at the University in question may have very
good reasons for wanting to have access to Unix machines (besides the
obvious one - most of them probably don't know how to use anything else :-(
). However, that is no reason to drive such a key decision off on a
tangent. Suggest to your friend that they do a real analysis of how the
central machines are used and a cost/benefit analysis on any proposed
changes.
Regards,
David Mathog
mat...@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
Jim Becker
>[snip]
> imho, the idea about giving the Computer Science department its own
>Unix boxes, above and beyond the already functioning system was the
>best reply to the question yet. Adding Unix boxes to an already functioning
>VMS Cluster would only enhance the cluster. The user account space could be
>NFS mounted, from VMS to the Unix systems, allowing the VMS system to
>handle diskquota and closing security holes on the Unix boxes. The
>local filesystem on the Unix boxes being untouchable. And the user
>would be able to share his data between the two systems (same directory).
>easy maintenence, easy accounting, the only retraining would be the
>users who "wanted" to move over to the Unix side. Why force the issue?
>
>R_Rockwell, UMKC/ACS;
This can be a fine idea, but it's not necessarily as seamless as you
might be thinking. For example, check out your NFS implementation
carefully. There is not a one-to-one mapping between the VMS and Unix
worlds when it comes to file systems (ownership, security, etc.). Find
out what the VMS NFS server does about ACLs, directories owned by rights
identifiers, and Unix users who are members of multiple groups. Find out
how easy it is to set up UID-to-UIC mappings. Find out what happens to
users for whom there is no mapping. Find out what happens to file
attributes -- even plain text files might not have the attributes you
expect. Find out what happens to Unix users and applications if they've
exceeded their disk quota on the VMS side. If you have software that
needs to read data created by software on the "other side," test it. Find
out what happens to Unix file names that are invalid in VMS.
In short, as with any mixed environment, you might sacrifice some
capabilities, add some system management headaches, or complicate the
user's environment. This is part of the cost assessment that goes into
choosing your computing environment. Unfortunately, these costs can be
hard to articulate for non-technical decision-makers.
Jim Becker
System Solutions, Incorporated
jbe...@ssi-hq.syssol.com
Christian Knapmeyer
In article <009A08B6....@CCTR.UMKC.EDU> Ron <rroc...@CCTR.UMKC.EDU> writes:
[ really enjoyed your posting, but - snip :-) ]
>
> AXP25 USER:[RROCKWELL] copy
> _From: ?
> %DCL-W-NULFIL, missing or invalid file specification - respecify
>
> well, its nice enough to ask anyway, and the error is clear. The point is, i
> am NOT a newbie, like the 2000 new student accounts i put on every
> year. Which would you prefer your 2000 Newbies had to "enjoy"?
I'd prefer to let them "enjoy" Windoze or Macs, they'll deal with them
later anyway. ;-) Unix is IMHO not for beginners who dislike reading
docs, and VMS isn't either. How do your Newbies enjoy this:
$ cd foobar
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\CD\
$ help
.... rummage in help ....
$ set default foobar
%RMS-F-DIR, error in directory name
$ help
.... rummage even longer in help ....
$ set default [foobar]
... hoorray ...
$ dir
%DIRECT-E-OPENIN, error opening USERS:[FOOBAR]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
.... argh...but it is there!!!... asking the neighbour...calling support....
$ set default [.foobar]
$ dir
... phew...sheesh! does it really have to be like this....
(It does. It's the philosophy of VMS to type "SET DEFAULT [.FOOBAR]"
instead of "cd foobar". It's a concise and well-defined syntax
dealing with verbs and nouns. It is intuitive and clear.
Learn to type quick and a lot.)
>
> ...and then there is the graceful commandline, i.e. i can backspace
> in a password prompt on a VMS machine,
Hmm... I prefer the style of commandline editing that tcsh offers.
I seldomly need to backspace in my password, but often in a 150 characters
long command...
> In VMS, (assuming a non-captive account) i hit Ctrl-Y, and no matter
> what it was i was running (interactively) brings me to the command
> prompt. But on the Unix host, if i hit Ctrl-Z or Ctrl-C, or Ctrl-D
> (it depends on the program.... and thats another real irritating
> topic), yes, it indeed brings me back to a command prompt, however,
> i am no longer able to log out.
>
> aurora{/users/r/rockwell/unix}51 % logout
> There are stopped jobs.
> aurora{/users/r/rockwell/unix}52 % grrrrr....
> grrrrr....: Command not found.
> aurora{/users/r/rockwell/unix}53 % vi
Well, just type "logout" again, it will kill your jobs then...
Ctrl-Z is for suspending a job, Ctrl-C is for killing it, Ctrl-D is EOF
for commands that read from stdin.
(e.g. "cat >file
blah blah
blah blah
<ctrl-D>")
>
> This is usually caused by Ctrl-Z me thinx, which all "trained" VMS
> users have burnt into their habitual fingers as a way to get out of
> an editor.
Indeed, different OS's use different keys. Ctrl-Z is meant to send
a job in background, not to kill it.
If you're a trained VMS-user you'll have problems with this.
If you're one of your Newbies, you are more likely to use Ctrl-C anyway
to kill a program, like on your PC. This works BTW for all programs that
do not intentionally catch it - like under VMS where one can catch ctrl-Z.
>
> The fact that the Unix online documentation is so poor, only tells
> me that the problems will be perpetuated to no certain end. Now if
> Unix had good documentation, then it would probably not be that bad.
> But i actually read that kind of thing, unlike my 2000 new users
> each year.
Unix man pages are _NOT_ meant as a tutorial for beginners. Definitely not.
Read a book instead, or hand a 'beginners guide' to Newbies. The man
pages are for reference. They are sometimes difficult to read, cause
they're complete and exact. That's what I need as soon as I'm an
experienced user.
>
> R_Rockwell, UMKC/ACS;
Uwe Leinberger GSI Darmstadt
In article <slrn4mgp4p...@wiwaxia.mit.edu>, da...@space.mit.edu (John E. Davis) writes:
>I just want to make a few statements about my own experience. When I
>started working with computers as a graduate student in the mid 1980s, the
>only computer systems that I had access to were VMS and MVS systems. There
>were simply no Unix machines in our department to choose from. Now the
>situation is totally reversed. I nolonger have access to VMS. Unix has
>totally replaced VMS everywhere I work. Is this a general trend? Are there
>any numbers which indicate that my experience is not an isolated one?
>
>Finally,
>
> : I am in a commercial environment that is making the change from VMS to
>
>
>
>
>
>
>
Oh, but please, look at the load average: These boxes are just IDLE most of the time
and have <10 users!!!!!
Even my old 286 PC running DOS 3.41, just sitting there somewhere as my private
FTP server, only crashes if I use it with 2 sessions at the same time.....
Uwe
Michael Lemke, Sternwarte Bamberg, Phone: +49-951-9522216
Christian Knapmeyer <kna...@tecmath.de> wrote to Info...@Mvb.Saic.Com
Ages ago I put this in my .login (works for tcsh and csh):
stty susp ^D
stty eof ^Z
stty quit ^Y
For tcsh I also defined the keypad to do EDT line editing. Beats the
hell out of DCL's editing (but the latter works everywhere).
Michael
--
Michael Lemke
Sternwarte Bamberg, University of Erlangen-Nürnberg, Germany
(mic...@io.as.utexas.edu or ai...@a400.sternwarte.uni-erlangen.de)
John Selph
have used Linux for 2 years. I had one problem with a bad kernel
from Linux and that's it. No crashes ever with either. And I've
seen a VMS system act crazy before, coming to it's knees because
of odd mail quirks. And I've seen VMS lose files because of corruption
after a crash before. I like both systems very much. But folks, what
system looks best depends on your experience. We use an AS/400 here
for the critical stuff, and it's rock solid. I say, don't change
just because "Unix is the in thing". But if it makes good sense for
your situation, then do it. Always investigate viable options.
In article
<Pine.LNX.3.91.960407...@auden.psc.saic.com>,
ons...@auden.psc.saic.com says...
vax...@axp.calumet.purdue.edu
won't allow execution of VMS files under UNIX, nor will
it allow execution of UNIX files under VMS. UCX NFS gives
only read/write privilege to a file.
So what's the point of having links to VMS diskspace unless
it's used to store data?
We learned NFS is an over-rated hassle. We'll probably find
out the same thing when we try to implement OSF/DCE across
a multivendor VMS/UNIX client/server environment.
paul white
purdue university calumet
Unknown
exposure is limited, and is (mostly) hearsay, esp the u**x bits.
to those of you who've worked w/ both OpenVMS && u**x, what features
did you find most often implemented DIFFERENTLY from one u**x platform
to the next?
items that 1st come to mind, (and perhaps it's not so..?)
+ support for near-RT task switching (ie, @prio 15-31)
+ asynch i/o
+ sharable images/image-libraries/sections
+ exception handling
+ error messaging
+ cmd line facilities (say analogous to CLI$, cld)
+ indexed/isam files, and journalling
+ s/a backup
+ loadable drivers
+ clustering/distributed lock manager
+ execution/print scheduling/queueing systems
+ class scheduling
+ accounting
+ ACL's
+ hdw error reporting
+ system/process dumps
Craig Paul
>Third-party vendors are more and more dropping the VMS side.
>Remember the discussion about Oracle's support policies?
That's why Oracle is touting huge databases with VMS right now at
trade shows.
>Or about Netscape...?
Will be bundled with all Digital operating systems.
>Same holds for many more companies, bigger and smaller ones.
With VMS allied with NT and supporting NT system calls VMS will be
around for quite some time.
Christian Knapmeyer
In article <4kd984$n...@rs18.hrz.th-darmstadt.de> leinb...@axp621.gsi.de (Uwe Leinberger GSI Darmstadt) writes:
> >For me, this is almost unbelievable. For the unix machine that I am logged
> >onto now (a network fileserver running SunOS), `w' reports:
> >
> > 8:48pm up 127 days, 4:49, 1 user, load average: 1.02, 1.00, 1.00
> >
> >and on the main server (also running SunOS) doing everything else (network
> >time daemon, file server, anonymous ftp, httpd,...):
> >
> > 8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
> >
> Oh, but please, look at the load average: These boxes are just IDLE most of the time
> and have <10 users!!!!!
>
> Even my old 286 PC running DOS 3.41, just sitting there somewhere as my private
> FTP server, only crashes if I use it with 2 sessions at the same time.....
>
>
> Uwe
Oh, and please look also at the wallclock times: when he took these
numbers it was already 8:50 pm. Even I do not expect very much active users
and a high load at late evening time.
He just wanted to show us that their fileserver (!) doesn't need to be
rebooted every once a week, only because it is a Unix box.
Daniel Packman
>Ron <rroc...@CCTR.UMKC.EDU> wrote:
>>[snip]
>> imho, the idea about giving the Computer Science department its own
>>Unix boxes, above and beyond the already functioning system was the
>
>This can be a fine idea, but it's not necessarily as seamless as you
Indeed, NFS does get the job done for many people, but it has deep design
limitations, particularly related to stateless machines and error recovery.
Before junking a working system, it would be best to analyze short term
needs, long term needs, and then arrive at both short-term and long-term
plans.
In the short term, one might find adding workstations running the operating
system of choice (unix, VMS, NT, Mac, Windows, etc...) is the way to allow
users the freedom they wish. Couple this with support requirements. Perhaps,
you could say that if you run unix from these vendors or VMS, you will get
this level of support. If you run NT or MAC or windows, you are on your own.
Make the policy clear. Allow as much freedom as possible since users have
different tastes. Make clear exactly how much responsibility they will have.
In the long term, one might find adoption of network standards to be more
important than operating systems. In our projects, we have adopted DCE
(Distributed Computing Environment) from OSF as the unifying force. We
expect to run DFS as the follow-on to NFS. If machines will work within
this environment (and are able to be DFS clients and servers), then they
can be considered possible network nodes.
Arne Vajhoej
> have used Linux for 2 years. I had one problem with a bad kernel
> from Linux and that's it. No crashes ever with either.
What is good for a personal work-station is not necesarrily good for
large system.
> We use an AS/400 here
> for the critical stuff, and it's rock solid.
Well due to what AS/400 systems are used for I would expect them to be.
If an AS/400 does not work it is likely that some people are not getting
their monthly pay-check !
> I say, don't change
> just because "Unix is the in thing". But if it makes good sense for
> your situation, then do it. Always investigate viable options.
Noone can disagree with that.
Chris Olive
>For me, this is almost unbelievable. For the unix machine that I am logged
>onto now (a network fileserver running SunOS), `w' reports:
>
> 8:48pm up 127 days, 4:49, 1 user, load average: 1.02, 1.00, 1.00
>
>and on the main server (also running SunOS) doing everything else (network
>time daemon, file server, anonymous ftp, httpd,...):
>
> 8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
I'm glad to see you are getting such great mileage, but I've never had the
fortune of seeing such lines in what work with Unix I have done (granted,
I have not been a heavy-duty, 10 year user of it). That includes HP,
AT&T/NCR (to whom I was mainly referring -- AT&T has left a big big mess
for NCR to clean up in my opinion), Linux, and Sun (though not so much
experience with Sun and not as bad at that).
Even if the Unix box stayed up forever, VMS still wins in the overall
category of robustness, stability and ease of use in my book.
Charles Onstott
> You will also quickly learn that UCX NFS, for example,
> won't allow execution of VMS files under UNIX, nor will
> it allow execution of UNIX files under VMS. UCX NFS gives
> only read/write privilege to a file.
I assume you mean UCX NFS will not allow you to run
VMS files stored on a NFS mounted UNIX directory,
since you certainly shouldn't expect to be able to
run VMS programs under UNIX and visa versa.
If this is the case, UCX NFS is a broken implementation of
NFS.
Charles
> We learned NFS is an over-rated hassle. We'll probably find
> out the same thing when we try to implement OSF/DCE across
> a multivendor VMS/UNIX client/server environment.
I haven't had any experience with VMS<->UNIX NFS implementations,
but I haven't had any problems with multivendor UNIX NSF
implementations. The primary problem with going between UNIX
and VMS (or DOS or OS/2) is going to be that the security
methods on the filesystems are different (or nonexistent).
r...@polaris.east.dialog.com
kna...@tecmath.de writes:
[cut]
The creators of VMS have allowed us to solve above difficulties.
The creators of UNIX have allowed the users to cobble together
a backup facility among other tricks (or shell out bucks).
Overcoming the above problem you have, I do things similar to this:
$
$ cd foobar
ROB> md foobar
%CREATE-I-CREATED, DKA100:[ROB.FOOBAR] created
ROB> cd foobar
ROB.FOOBAR> pwd :== show default
ROB.FOOBAR> pwd
DKA100:[ROB.FOOBAR]
ROB.FOOBAR> bye
md is better than mkdir as I save a couple of keystrokes. One
less keystroke to carpal tunnel. E-mail if interested for the
best VMS cd.com around IMHO.
Rob
"UNIX will be preempted by NT and its new partners. UNIX doesn't know it yet
-- it won't notice until it's too late, because UNIX is the Yugoslavia of
software, at war with itself -- but it's all over. I have IS manager sources
who refer to UNIX as legacy systems." -- Paul Cubbage, Dataquest
Andreas Fassl
> 8:48pm up 127 days, 4:49, 1 user, load average: 1.02, 1.00, 1.00
>and on the main server (also running SunOS) doing everything else (network
>time daemon, file server, anonymous ftp, httpd,...):
> 8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
^
Thats the point! +------- 1 to 7 users.
Guess what happens when running with 200 users?
2000 users? Should be interesting?
Regards
andreas
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ proGIS Softwareentwicklung, Simulationssysteme, Beratung +
+ E-Mail: and...@progis.ac-net.de VOICE:(49) 241 470 67 -0 +
+ FAX: (49) 241 470 67 -29 +
Marshall Abrams
Charles Onstott <ons...@auden.psc.saic.com> wrote:
>UNIX's primary strengths are: true symbolic linking (much
>better than VMS' implementation), highly integrated internet
>TCP/IP protocols, the fact that it treats almost everything
>as a file and has the ability to have filesystems of
>any type written (as for how radical this can get,
>check out the proc filesystem ala SunOS or Linux), peformance, and
>portability. It's primary weaknesses are security and initial ease of use.
>You'll find that UNIX is every bit as stable as VMS, so you
>won't need to worry about additional downtime.
>While it is true that UNIX has obscure commands, it is more useful to
>realize that UNIX is highly configurable. Instead of thinking of it as a
>nightmare, it is better to realize that its power is precisely in its
Yes, I want to make this more explicit. There are lots of nice
things about VMS, but doing just about anything slightly complex
is easier in a Unix shell than in DCL. The Unix Bourne shell
makes you do somersaults once in a while; DCL makes me do it
constantly. For starters, many things that require writing a DCL
procedure with output to temporary files, etc., can be done on
the fly in one line in Unix. More complex scripts are generally
simpler and more elegant in the Bourne shell than in DCL (which
is not to say that Bourne shell scripts are paradigms of
elegance). (You might say that in the area of command
interpreters, VMS makes it much easier to do easy things (since
it's more friendly about things you don't know much about), but
Unix makes it much easier to do things that aren't so easy.)
(I love VMS, but I love Unix more....)
Marshall Abrams ab...@midway.uchicago.edu
I will not buy anything advertised in an inappropriate newsgroup
(or advertised with more than one '!' or '*' in its subject line).
--
Marshall Abrams ab...@midway.uchicago.edu
I will not buy anything advertised in an inappropriate newsgroup
(or advertised with more than one '!' or '*' in its subject line).
Uwe Leinberger GSI Darmstadt
>
> > >onto now (a network fileserver running SunOS), `w' reports:
> > >
> > >
> > >and on the main server (also running SunOS) doing everything else (network
> > >time daemon, file server, anonymous ftp, httpd,...):
> > >
> > > 8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
> > >
> > and have <10 users!!!!!
> >
> > Even my old 286 PC running DOS 3.41, just sitting there somewhere as my private
> > FTP server, only crashes if I use it with 2 sessions at the same time.....
> >
> >
> > Uwe
>
>
>Oh, and please look also at the wallclock times: when he took these
>numbers it was already 8:50 pm. Even I do not expect very much active users
>and a high load at late evening time.
>
>He just wanted to show us that their fileserver (!) doesn't need to be
>rebooted every once a week, only because it is a Unix box.
>
>Greetings,
> Christian
>--
> ----------------------------------------------------------------------------
> Dipl.-Inform. Christian Knapmeyer Email: kna...@tecmath.de
> TecMath GmbH Voice: 06301/606-0 Fax: 06301/606-66
> Sauerwiesen 2 Face : Room 115
> 67661 Kaiserslautern, Germany Disclaimer: as usual
> ---------- press any key to continue. press any other key to quit.----------
>
jobs running, sturating the servers. Except the fileservers, of course:
A IBM 590 AIX machine with 512MB memory seems to be saturated with NFS
serving 40GB raid alone.....at least they loced everybody out with this argument.
When we were using these machines also as compute servers and for interactive
work at the same time, they got hung and even crashed frequently.
It seems that they could not even fix this with IBM support on-site, as
(unconfirmed!!!) ruomors say.....
Uwe
Uwe Leinberger GSI Darmstadt
[snip]
>Well due to what AS/400 systems are used for I would expect them to be.
>If an AS/400 does not work it is likely that some people are not getting
>their monthly pay-check !
>
>> I say, don't change
>> just because "Unix is the in thing". But if it makes good sense for
>> your situation, then do it. Always investigate viable options.
>
>Noone can disagree with that.
>
> Arne
>
>Arne Vajhøj local DECNET: KOPC::ARNE
>Computer Department PSI: PSI%23831001354030::ARNE
>Southern Denmark Business School Internet: AR...@KO.HHS.DK
> WWW URL: http://www.hhs.dk/~arne/arne.html
>
>
You have a couple of standard apps, large number of people just hacking
some numbers/keywords/... into a few fields in a fixed mask on the screen
and maybe doing some little database operations. This might even work on a
unix for quite some time. And you hardly do any development/SW testing,
compilation or huge IO on such systems
Start to let people develop their own code (hundreds of them), shuffling
around 100's of GB of data to be analyzed as a matter of course, develop
and run CPU hogs (simulation poackages) using 100s MB memory and so on,
most of these not very well educated in SW engineering, but in the fields
they want to get results (here physics) and all of the stuff so specialized
that everybody really has to make own code, at least in part.
Then you always get to the limits, saturating networks, SCSIs memory, CPU....
THIS is a good test bed for a OS: If it does survive HERE, it should in
"normal" cases also. And VMS does pretty well.....
Uwe
vax...@axp.calumet.purdue.edu
That's right. Security is an issue, but so are the file types.
UNIX has stream file types, and VMS has RMS-indexed, sequential
and directory structures, too. VMS supports file version numbers,
which UNIX interprets as something else. Proxy mappings between
UNIX/VMS file owners have to be one-to-one. Several VMS/UCX NFS
mount/ qualifiers have to be mentioned, including /CONVERSION
and /SERVER=UNIX to specify VMS/UNIX conversion for a VMS NFS client.
The reason VMS files won't execute on a UNIX NFS mount is obvious.
DCL commands are found in UNIX verb tables and vice-versa.
NFS is no good for backups either, since ownership is lost. That
would be another excellent implementation for the VMS BACKUP utility.
We're using UNIX rdump to VMS rmt server, triggered by TCP sockets.
So, UNIX/VMS NFS applications are limited to sequential file storage
IMHO.
paul white
==============================================================
John E. Davis
wrote:
: Even if the Unix box stayed up forever, VMS still wins in the overall
: category of robustness, stability and ease of use in my book.
I do not think that anyone is debating the technical merits of VMS. It
seems to me that VMS is dying faster than Unix; at least, that has been my
experience. If this is true (does anyone have statistics), then when should
one consider ``jumping ship'' to something with a greater lifetime? What is
DEC's comittment to VMS? to WNT? to OSF?
Robert Stine
comparing the technical merits of Unix vs. VMS or the cost to migrate
from VMS to Unix?
Rob.
Martin Vorlaender
: Yes, I want to make this more explicit. There are lots of nice
: things about VMS, but doing just about anything slightly complex
: is easier in a Unix shell than in DCL.
: For starters, many things that require writing a DCL
: procedure with output to temporary files, etc., can be done on
: the fly in one line in Unix. More complex scripts are generally
: simpler and more elegant in the Bourne shell than in DCL
All of the above advantages (that I won't deny) are due to the pipe
concept (which is one of the few things I miss in VMS), not to the
Bourne shell (or any other shell, for that matter).
Besides that, *ix scripts may be elegant, but I find scripts doing
complex things extremely hard to read (but then, I never could find
any elegance in awk and sed - I just plain find them cryptic...)
Just my $0.02,
Martin
--
| Martin Vorlaender | VMS programmer
"UNIX is user friendly. | work: m...@pdv-systeme.de
It's just selective about | home: mar...@radiogaga.harz.de
who its friends are." | http://www.harz.de/~martin/
-------------------------------- HAM Radio: dk9ah@db0dni.#nds.deu.eu
Andreas Fassl
>> I have to agree with this fellow. I used Unixware for a while, and
>> have used Linux for 2 years. I had one problem with a bad kernel
>> from Linux and that's it. No crashes ever with either.
>What is good for a personal work-station is not necesarrily good for
>large system.
Ok,
next round:
A good story about "The kernel" - linux
Task:
Your boss ordered three generic 4.3 GB SCSI-hard disks and wants to put them
on
- a PC system
- Unix system
- openVMS system.
PC:
Hardware installation steps are identical for all systems
- Jumpering
- Build in
- Powering system
After this:
running FDISK to partition the hard disk (danger: You can destroy the entries
of other disks) and after reboot format the disk. Thats it.
Unix:
hardware (see above)
branch depending on UNIX (like it is in the world of UNIX: Unix is always
different to other UNIX)
make a entry in the mysterious /etc/fstab and reboot. Probably you need to
rebuild the kernel. Probably you will know now that this Unix or Version
level doesn't support disks of this size (Free BSD). Or the file system
doesn't work stable with this disk size (Linux 1.2x).
openVMS:
Hardware (see above)
AXP 6.2 $ mc sysman
SYSMAN> io auto
SYSMAN> exit
AXP 6.2 $ Init dka500: label
AXP 6.2 $ Mount/system dka500: label
Thats it. No reboot or down time (if using an external drive).
Ok, I forgot an entry (mount/system) in the startup-files for automatic mounting
every time while booting.
For example I connected my SCSI-IOMEGA-ZIP drive inner 3 minutes to our
Alpha system:
AXP 6.2 $ mc sysman
SYSMAN> io auto
SYSMAN> exit
AXP 6.2 $ show dev dka500/full
Disk BLADE$DKA500:, device type IOMEGA ZIP 100, is online, file-oriented device,
shareable, available to cluster, error logging is enabled.
Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 512
Host name "BLADE" Host type, avail DEC 2000 Model 300S, ye
s
Thats easy.
And we not started talking about VMS-Clusters. I wish every UNIX admin would
have experienced the easy configuration of a VMS-Cluster. Look in the unix
groups about the thousands of articles regarding NFS, configuring etc.
Look at the vms-groups. All questions you may have are answered in the
system managers manual over 2-3 pages. Thats it. Use @CLUSTERCONFIG
Dale Lobb
For example: if you use UCX as your TCP/IP package on the VMS platforms, you
forego any sort of locking mechanism. After a recent talk with Digital Customer
Support, I that NFS under UCX does not support any sort of locking on the
network side of the connection, and ignores any outstanding locks on the VMS
side. Also, if you check the documentation on UCX NFS, you will find that the
only files which are updatable from the NFS side are those which are RMS
stream_lf format. All other VMS file types are marked as read-only. This may
put a damper on plans to integrate using NFS. I have no experience with the TGV
TCP/IP product; maybe it does not have these limitations.
Another problem would probably be reading the file formats themselves. Simple
RMS formats would be easy to read on the NFS (UNIX) side, but, I doubt if you
will find any mechanism for reading RMS indexed files from the NFS (UNIX) side
of the system. In addition, binary data formats would also be incompatible, so,
some translation code would have to written to accommodate this as well.
All, in all, I don't think the integration would be at all seamless.
====================================
Dale T. Lobb
Programmer Analyst
Bryan Memorial Hospital
DL...@Bryan.Org
Personal Email: Lord...@inetnebr.com
====================================
Received: from mvb.SAIC.com by heimdall.bryan.org; (5.65v3.2/1.1.8.2/07Sep95-1110AM)
id AA28407; Mon, 8 Apr 1996 12:26:19 -0500
From: Jim Becker <jbe...@ssi-hq.syssol.com>
X-Newsgroups: comp.os.vms
Subject: NFS between VMS & Unix (was Re: dropping VAX in favor of UNIX :-()
Date: 8 Apr 1996 10:18:22 GMT
Organization: System Solutions Incorporated
Lines: 39
Message-Id: <4kap5e$7...@news6.erols.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.22KIT (Windows; U; 16bit)
To: Info...@Mvb.Saic.Com
X-Gateway-Source-Info: USENET
Ron <rroc...@CCTR.UMKC.EDU> wrote:
>[snip]
> imho, the idea about giving the Computer Science department its own
>Unix boxes, above and beyond the already functioning system was the
>best reply to the question yet. Adding Unix boxes to an already functioning
>VMS Cluster would only enhance the cluster. The user account space could be
>NFS mounted, from VMS to the Unix systems, allowing the VMS system to
>handle diskquota and closing security holes on the Unix boxes. The
>local filesystem on the Unix boxes being untouchable. And the user
>would be able to share his data between the two systems (same directory).
>easy maintenence, easy accounting, the only retraining would be the
>users who "wanted" to move over to the Unix side. Why force the issue?
>
>R_Rockwell, UMKC/ACS;
This can be a fine idea, but it's not necessarily as seamless as you
Carl J Lydick
=openVMS:
=Hardware (see above)
=AXP 6.2 $ mc sysman
=SYSMAN> io auto
=SYSMAN> exit
=AXP 6.2 $ Init dka500: label
=AXP 6.2 $ Mount/system dka500: label
=Thats it.
If you're lucky. However, SYSMAN's IO AUTOCONFIGURE routine will not
recognize, e.g., an HP C1716T magneto-optical disk drive. Instead, you have to
manually configure the disk drive into the system, every time you boot. And
since SYSMAN's IO stuff seems to lack the SHOW/CONFIGURATION/COMMAND ability
from the old SYSGEN, you can't even use that to get some hints about what
values you'd have tp specify when manually configuring in the device.
--------------------------------------------------------------------------------
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.
CCIT jonathan d woytek
: Your boss ordered three generic 4.3 GB SCSI-hard disks and wants to put them
: on
: - a PC system
: - Unix system
: - openVMS system.
: PC:
: Hardware installation steps are identical for all systems
: - Jumpering
: - Build in
: - Powering system
: After this:
: running FDISK to partition the hard disk (danger: You can destroy the entries
: of other disks) and after reboot format the disk. Thats it.
: Unix:
: hardware (see above)
: branch depending on UNIX (like it is in the world of UNIX: Unix is always
: different to other UNIX)
: make a entry in the mysterious /etc/fstab and reboot. Probably you need to
: rebuild the kernel. Probably you will know now that this Unix or Version
: level doesn't support disks of this size (Free BSD). Or the file system
: doesn't work stable with this disk size (Linux 1.2x).
I think it is important to mention first that I have done
many large-disk installs on various Unix systems. Many of the systems
available now have hot-swappable/pluggable disks, which means no downtime
for the initial connection. The disk-setup and partitioning utility
generally changes between unices, so for example purposes I will use the
bsd/os 'disksetup' utility. disksetup -i sd5 will bring up an
interactive partition editor on the drive on scsi id #5. Three steps
later (assigning a size in megabytes to a partition and writing the data
to the disk), a newfs /dev/rsd5z may be issued, where z is hte letter of
the partition. Then a simple 'mkdir' and 'mount /dev/rsd5z /mnt', where
mnt is the directory where you would like to access to the new drive.
then you are finished. If desireable, the drive may be added to the
/etc/fstab file, simply using existing entries as a template. A kernel
rebuild is hardly necessary unless adding a new interface, like an IDE or
a new SCSI card. Adding a new drive does not necessitate a kernel
rebuild. Lastly, linux really is not a good example of a unix, since it
is not really a unix (yeah, I know, this could be a point of war for
some), and as such does not have many of the features and abilities
available in a 'real' unix.
: openVMS:
: Hardware (see above)
: AXP 6.2 $ mc sysman
: SYSMAN> io auto
: SYSMAN> exit
: AXP 6.2 $ Init dka500: label
: AXP 6.2 $ Mount/system dka500: label
: Thats it. No reboot or down time (if using an external drive).
: Ok, I forgot an entry (mount/system) in the startup-files for automatic mounting
: every time while booting.
: For example I connected my SCSI-IOMEGA-ZIP drive inner 3 minutes to our
: Alpha system:
: AXP 6.2 $ mc sysman
: SYSMAN> io auto
: SYSMAN> exit
: AXP 6.2 $ show dev dka500/full
: Disk BLADE$DKA500:, device type IOMEGA ZIP 100, is online, file-oriented device,
: shareable, available to cluster, error logging is enabled.
: Error count 0 Operations completed 0
: Owner process "" Owner UIC [SYSTEM]
: Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
: Reference count 0 Default buffer size 512
: Host name "BLADE" Host type, avail DEC 2000 Model 300S, ye
: s
: Thats easy.
: And we not started talking about VMS-Clusters. I wish every UNIX admin would
: have experienced the easy configuration of a VMS-Cluster. Look in the unix
: groups about the thousands of articles regarding NFS, configuring etc.
: Look at the vms-groups. All questions you may have are answered in the
: system managers manual over 2-3 pages. Thats it. Use @CLUSTERCONFIG
: andreas
Please realize that this is not a flame at you of any sort. I am
merely relating my experiences and knowledge of unix systems.
Admittedly, unix does have a great deal of documentation available, but
for third-party applications, setup documentation can be sparse. Please
also consider in your above comment that many unices are available to
people who really have no clue about what they are doing, or network
systems in general. Most of the sysadmins I speak with, both unix and
vms, have very little need to post questions to their respective
newsgroups. It is unfortunate that some people have taken to posting
every single problem they have instead of referring to the quite helpful
'man' or 'help' first, and then asking a more specific question based on
the information they were able to get from their respective commands.
Having done work on both types of systems, but starting out with unix, I
still prefer unix. However, that in no way diminishes my respect for vms
and some of the features it has that unix lacks in one way or another.
Farewell for now...
jdw
Jonathan Woytek
personal mail to: woy...@cmu.edu
work-related to: woy...@next.duq.edu
G. Ruth Hammond
Install the POSIX shell and tell everyone that you've made the switch!
--
~GuyRuthHammond () {}
// Machinery and Mayhem at UCL Dept Mech Eng
// mailto:hamm...@meng.ucl.ac.uk http://www.ucl.ac.uk/~zcemm23
// Clear the DECs, it's time for action!
G. Ruth Hammond
In article <4kd984$n...@rs18.hrz.th-darmstadt.de>, leinb...@axp621.gsi.de
(Uwe Leinberger GSI Darmstadt) writes:
|>>For me, this is almost unbelievable. For the unix machine that I am logged
|>>onto now (a network fileserver running SunOS), `w' reports:
|>>
|>> 8:48pm up 127 days, 4:49, 1 user, load average: 1.02, 1.00, 1.00
|>>
|>>and on the main server (also running SunOS) doing everything else (network
|>>time daemon, file server, anonymous ftp, httpd,...):
|>>
|>> 8:50pm up 97 days, 18:19, 7 users, load average: 0.31, 0.16, 0.01
|>>
|>Oh, but please, look at the load average: These boxes are just IDLE most of
|>the time
|>and have <10 users!!!!!
at the risk of sounding treacherous, on the AIX machine:
10 % w
12:51PM up 126 days, 3:09, 21 users, load average: 9.23, 9.08, 9.12
and on node DREDD::
$ sh sys/node=dredd
OpenVMS V6.1-1H1 on node DREDD 11-APR-1996 12:58:31.75 Uptime 22 19:08:48
statistics never speak for themselves, though. I think the cluster may have
been
deliberately rebooted recently.
--
~GuyRuthHammond () {}10 % w
Anthony C. McCracken
>> A friend of mine tells me that her Univ. admin is thinking of dropping VMS
>> in favor of their Computer Scienc dept's request that the mainframe switch
>
>Regarding functionality after the change:
> - you will get more software to choose from (especially for Internet
> stuff will you find more software bot commercially and free
> for Unix than for VMS)
> - you will get more downtime and more problems (VMS is rock-solid)
One more thing, if security is a concern at this site then there's a big
consideration moving from VMS to UNIX. It's like a house in the tropics, you
just can't keep the roaches out.
At my previous job the UNIX sysadmins spent almost half of their time
working to keep the machines secure and usable. They were also always fighting
the latest attacks. Us VMSers haven't hat to worry about anything since the
circa 4.7 - 5.3 ANAL/PROCESS_DUMP problem. Seems that every week there's a
CERT on UNIX sendmail or portmapper or some other silly vulnerability that
VMS by nature is immune to.
Like it or not, under UNIX eventually all of your users will have root
access. Under VMS you need privs to get privs. The backdoors (holes) just
aren't there to be exploited.
My nickels worth,
Tony McCracken
Formerly of Northern Arizona University
+----------------------------------------+-----------------------------------+
| Anthony C. McCracken | |
| SunQuest Information Systems | Boom boom boom,,, Still going ! |
| Tucson, Arizona | |
| | VMS just keeps going and going and|
| | going. Nothing outlasts VAX/VMS. |
| a...@Alpha.Sunquest.COM Internet | |
| 520.400.3454.us.west Noise net | |
+----------------------------------------+-----------------------------------+
Kent Covert
> Marshall Abrams (ab...@midway.uchicago.edu) wrote:
> : Yes, I want to make this more explicit. There are lots of nice
> : things about VMS, but doing just about anything slightly complex
> : is easier in a Unix shell than in DCL.
> [...]
> : For starters, many things that require writing a DCL
> : procedure with output to temporary files, etc., can be done on
> : the fly in one line in Unix. More complex scripts are generally
> : simpler and more elegant in the Bourne shell than in DCL
> [...]
>
> All of the above advantages (that I won't deny) are due to the pipe
> concept (which is one of the few things I miss in VMS), not to the
> Bourne shell (or any other shell, for that matter).
It's also rumored that the next version of VMS will have an implementation
of PIPES. Unfortunately, I don't know whether it'll be just an
implementation of the PIPES program that's been floating around here for
years if it'll be done intelligently with threads or some other light
weight process. Does anyone who knows wish to comment?
--
Kent Covert, Software Coordinator
Miami Computing and Information Services
Miami University, Oxford, OH
cove...@muohio.edu
Alan Flancman
>> on-site, as (unconfirmed!!!) ruomors say.....
IBM support????? The only support I *know* IBM knows how to do is
to help you hold your wallet open as they hold you upside down
and shake you.
Alan
dae...@winternet.com
mailing lists around the world in a denial of service attack at the
end of December, 1995.
I have tried, unsuccessfully, many times to unsubscribe from these
mailing lists and have resorted to responding back to the list
enmasse.
I apologize for having to resort to this tactic.
Admins of these lists, please remove ro...@winternet.com from your list
subscriptions.
--
Mike Horwath IRC: Drechsau LIFE: Lover drec...@winternet.com
Winternet: in...@winternet.com drec...@Geeks.ORG
Twin Cities area Internet Access: 612-941-9177 for more info
Founding member of Minnesota Coalition for Internet Accessibility
Glenn C. Everhart
To configure an HP C1716T (when set as magneto optical), I just use
the command
$ sysman io connect dkb400:/noada/driver=sys$dkdriver
(The older dkdrivers won't do this, but newer ones coming will. I use it
for files-11 or spiralog data. Works fine.
However, in general one uses /noada to connect SCSI class driver
devices; the adapter is in the port driver. There basically ARE no
values to configure by hand, apart from knowing the SCSI address.
Autoconfig doesn't work on these devices when set as optical disks
because it doesn't realize that SCSI type 7 means something that
should be hooked up via dkdriver. That may be fixed on some newer
machines...depends on whether a new console can be supplied. On the
3000 series, you're stuck...though the thing DOES have a "disk mode"
switch someplace to make it a type 0 device that can be recognized, I think.
I just use it in optical mode tho...
DKdriver has for ages recognized type 0 and 5 devices (disk and CD) but
dkdriver in some versions (try yours, Carl!) can be connected to other
types.It is somewhat tolerant these days.
Glenn
Marshall Abrams
Martin Vorlaender <MAR...@RADIOGAGA.HARZ.DE> wrote:
>Marshall Abrams (ab...@midway.uchicago.edu) wrote:
>: Yes, I want to make this more explicit. There are lots of nice
>: things about VMS, but doing just about anything slightly complex
>: is easier in a Unix shell than in DCL.
>[...]
>: For starters, many things that require writing a DCL
>: procedure with output to temporary files, etc., can be done on
>: the fly in one line in Unix. More complex scripts are generally
>: simpler and more elegant in the Bourne shell than in DCL
>[...]
>
>All of the above advantages (that I won't deny) are due to the pipe
>concept (which is one of the few things I miss in VMS), not to the
>Bourne shell (or any other shell, for that matter).
Yes, pipes are a huge part of it, plus the fact that (a) UNIX
always comes with a host of little utilities for text
manipulation via pipes, and (b) UNIX config files, logs, etc. are often
organized to make it easy to apply those utilities to them
(reading through pages of output from ANALYZE/ERROR looking for
one kind of error sort of makes me wish for UNIX text tools and
pipes--but applying them to something formatted like that would
be a monstrous task). But I mentioned the Bourne shell because
there are a couple of other things I like about it, like easy
redirection of standard error and standard output.
What I most want added to DCL are functions that return values.
I suppose user-defined lexicals would be a natural interface.
(Of course pipes would be even better (hopefully including
something like UNIX's backquote substituition of one program's
standard output into another's command line).)
Arrays would be nice, too, although there is the variable variable-name
kludge for this. (The Bourne shell requires the same trick,
though I think the Korn shell has arrays.)
Marshall Abrams ab...@midway.uchicago.edu
--
Marshall Abrams ab...@midway.uchicago.edu
"WWW" means "Wait... Wait... Wait... " (upside down: "More, Modem, More!")
Mark Iline - Info-VAX account
>
> $ sh sys/node=dredd
> OpenVMS V6.1-1H1 on node DREDD 11-APR-1996 12:58:31.75 Uptime 22 19:08:48
>
> statistics never speak for themselves, though. I think the cluster may have
> been
> deliberately rebooted recently.
We tend to instal a fair amount of software. We also run UCX...
There was also that time that we were playing with the DEC Hub 900s, and
discovered that RECNXINTERVAL was set rather shorter than we thought...
Mark
Mark Iline sys...@meng.ucl.ac.uk
Dept Mech Eng, University College, London. UK
dae...@winternet.com
dae...@winternet.com
Alan Greig
>
> We tend to instal a fair amount of software. We also run UCX...
Two years ago UCX crashed our alphas almost daily. Now we see
a UCX related crash maybe once every few months. However Pathworks
still crashes our systems at least once a week which is admittedly
better than the several times a day it used to. Microsoft Word 7.0
at least tries to spell-check Pathworks to "Patchworks" which in
our case is true. Certainly in my experience the fastest current
way to ruin the reliability reputation of VMS is to make heavy
use of Pathworks 5.
It doesn't help matters that the CSC keep closing open calls on
us (presumably to prevent them being auto-shunted up the chain?).
>
> There was also that time that we were playing with the DEC Hub 900s, and
> discovered that RECNXINTERVAL was set rather shorter than we thought...
If you have a UPS you can have fun wheeling nodes around buildings
to a new location before RECNXINTERVAL expires. Puff, pant :-)
--
Alan Greig Tel: (01382) 308802
University of Abertay Dundee Email: A.G...@tay.ac.uk
** Never underestimate the power of human stupidity **
Carl J Lydick
=However, in general one uses /noada to connect SCSI class driver
=devices; the adapter is in the port driver. There basically ARE no
=values to configure by hand, apart from knowing the SCSI address.
One might wish that the folks who write the on-line help knew that:
$ SYSMAN HELP IO CONNECT Examples
IO
CONNECT
Examples
1.SYSMAN> IO CONNECT DKA0:/DRIVER_NAME=SYS$DKDRIVER/CSR=%X80AD00-
/ADAPTER=4/NUM_VEC=3/VECTOR_SPACING=%X10/VECTOR=%XA20/LOG
%SYSMAN-I-IOADDRESS, the CRB is located at address 805AEC40
%SYSMAN-I-IOADDRESS, the DDB is located at address 805AA740
%SYSMAN-I-IOADDRESS, the DPT is located at address 80D2A000
%SYSMAN-I-IOADDRESS, the IDB is located at address 805AEE80
%SYSMAN-I-IOADDRESS, the SB is located at address 80417F80
%SYSMAN-I-IOADDRESS, the UCB is located at address 805B68C0
This command example connects device DKA0, loads driver
SYS$DKDRIVER, and specifies the following:
Physical CSR address
Adapter number
Number of vectors
Spacing between vectors
Interrupt vector address
The /LOG qualifier displays the addresses of all control
blocks, as shown.
2.SYSMAN> IO CONNECT DKA0:/DRIVER_NAME=SYS$DKDRIVER/CSR=%X80AD00-
/ADAPTER=4/VECTOR=(%XA20,%XA30,%XA40)/LOG=(CRB,DPT,UCB)
%SYSMAN-I-IOADDRESS, the CRB is located at address 805AEC40
%SYSMAN-I-IOADDRESS, the DPT is located at address 80D2A000
%SYSMAN-I-IOADDRESS, the UCB is located at address 805B68C0
This command example connects device DKA0, loads driver
SYS$DKDRIVER, and specifies the following:
Physical CSR address
Adapter number
Addresses for interrupt vectors
The /LOG qualifier displays the addresses of the channel
request block (CRB), the driver prologue table (DPT), and the
unit control block (UCB).
OK, their examples don't say flat-out that you've got to provide a CSR and
vectors, but both of them do, and they don't give an example in which you DON'T
provide CSR and vectors.
Wayne Scott
Just like Rock 'N Roll, I think they're ALL Here To Stay!!!
Wayne
Wayne Scott
Hi Folks:
I'm not sure of all the issues being debated here,
but I'll briefly discuss my experiences over the past 2 years.
We started with a mature VMS system on which we had to build new
graphical user interfaces that would compile and run on both VMS & Solaris.
All the source is under CMS on VMS. We use TGV MultiNet to make the VMS files
available on the SUN. We have both VMS MMS files and UNIX makefiles stored
in CMS. Typical development goes like this: from my SUN, I open an xterm
window for the VMS side and one for the UNIX side. I "set default" to whatever
directory on VMS, and cd to the same on UNIX. Here's what df & an ls -l shows:
[wws@cayley] df
Wayne Scott
Oh crap, most of what I tried to post got truncated.
I'll try to reconstruct it...
...
/disk34/wws (cp0104:/disk34/wws): 399884 blocks -1 files
[wws@cayley] ls -l
total 674
-rwxr-xr-x 1 wws staff 567 Mar 27 16:51 id.c
-rw-r--r-- 1 wws staff 1368 Mar 28 23:34 id.o
-rwxr-xr-x 1 wws staff 594 Mar 27 16:51 id.obj
-rwxr-xr-x 1 wws staff 2379 Mar 28 23:31 makefile
-rwxr-xr-x 1 wws staff 12794 Mar 27 16:46 makesigs.c
-rwxr-xr-x 1 wws staff 6144 Mar 27 16:49 makesigs.exe
-rwxr-xr-x 1 wws staff 7208 Mar 27 16:49 makesigs.obj
-rwxr-xr-x 1 wws staff 742 Mar 27 16:10 makesigs_build.com
-rwxr-xr-x 1 wws staff 158 Mar 27 16:47 old_scsc_alarm_disp.sl
-rwxr-xr-x 1 wws staff 75432 Mar 28 23:34 scsc_alarm_disp
-rwxr-xr-x 1 wws staff 2408 Mar 27 09:36 scsc_alarm_disp.bf
-rwxr-xr-x 1 wws staff 55573 Mar 27 09:36 scsc_alarm_disp.c
-rwxr-xr-x 1 wws staff 45056 Mar 27 16:51 scsc_alarm_disp.exe
-rw-r--r-- 1 wws staff 34504 Mar 28 23:34 scsc_alarm_disp.o
-rwxr-xr-x 1 wws staff 35004 Mar 27 16:50 scsc_alarm_disp.obj
-rwxr-xr-x 1 wws staff 195 Mar 27 16:48 scsc_alarm_disp.sl
-rwxr-xr-x 1 wws staff 33897 Mar 27 09:39 scsc_alarm_disp.vr
-rwxr-xr-x 1 wws staff 7197 Mar 27 16:46 scsc_ich_alarm_recv.c
-rw-r--r-- 1 wws staff 4756 Mar 28 23:34 scsc_ich_alarm_recv.o
-rwxr-xr-x 1 wws staff 6280 Mar 27 16:49 scsc_ich_alarm_recv.obj
[wws@cayley]
On VMS it looks like this:
CP0104: sho def
DISK$SCPDISK34:[WWS.8-0.SCSC_ALARM_DISP]
CP0104:
CP0104: dir/date *;0
Directory DISK$SCPDISK34:[WWS.8-0.SCSC_ALARM_DISP]
ID.C;1 27-MAR-1996 16:51:05.19
ID.O;1 28-MAR-1996 23:34:13.21
ID.OBJ;1 27-MAR-1996 16:51:06.07
MAKEFILE.;1 27-MAR-1996 09:36:00.65
MAKESIGS.C;1 27-MAR-1996 16:46:00.20
MAKESIGS.EXE;14 27-MAR-1996 16:49:36.20
MAKESIGS.OBJ;11 27-MAR-1996 16:49:01.49
MAKESIGS_BUILD.COM;1
27-MAR-1996 10:34:18.53
OLD_SCSC_ALARM_DISP.SL;1
22-MAR-1996 12:44:40.07
SCSC_ALARM_DISP.;1 28-MAR-1996 23:31:32.74
SCSC_ALARM_DISP.BF;1
27-MAR-1996 09:36:03.42
SCSC_ALARM_DISP.C;1
27-MAR-1996 09:36:05.29
SCSC_ALARM_DISP.EXE;2
27-MAR-1996 16:51:10.98
SCSC_ALARM_DISP.O;1
28-MAR-1996 23:34:02.52
SCSC_ALARM_DISP.OBJ;2
27-MAR-1996 16:49:15.41
SCSC_ALARM_DISP.SL;1
27-MAR-1996 16:48:13.46
SCSC_ALARM_DISP.VR;1
27-MAR-1996 09:39:12.39
SCSC_ICH_ALARM_RECV.C;1
27-MAR-1996 16:46:07.84
SCSC_ICH_ALARM_RECV.O;1
28-MAR-1996 23:34:11.74
SCSC_ICH_ALARM_RECV.OBJ;3
27-MAR-1996 16:48:44.59
Total of 20 files.
CP0104:
In the UNIX session I do a make, and on VMS, a "build", which is a
symbol that invokes a local tool to use MMS on the SCSC_ALARM_DISP.BF file.
After it's compiled (you can see .OBJ from VMS and .O from UNIX), I can run
the .EXE on VMS and the one with no extension on UNIX. I've had no problems
whatsoever getting the SUN binary served up, loaded and run on Solaris.
Hoping this helps,
Wayne
----------------------------------------------
w...@cc.bellcore.com
I'm just a soul whose intentions are good,
Oh Lord, please don't let me be misunderstood.
Glenn C. Everhart
Carl writes:
==================== begin quote of prev. article ==========
CONNECT
Examples
========================== end quote ====================
These look like examples of connecting an RK05, which those of us with long
experience will remember is a Unibus disk, 4800 blocks, and one generally
might have known CSR and vector for it.
Lord knows why the examples still use this sort of thing. The current DKDRIVER
is a SCSI class driver that is TOTALLY UNABLE to handle CSRs or vectors;
the port drivers must do this. You connect DK units to this driver with the
/noadapter switch. The port drivers know how to talk to their controller
and the actual hardware.
The problem is likely to be an inadequate number of tech writers to review
this stuff. Looks like they took the old VAX text, did a global replacement
of "SYSGEN" by "SYSMAN IO" and shipped it to me. At least they could have
picked some driver name that was obviously fake...connect FUBARA0:, for
example, to SYS$FUBARDRIVER. (There'd at least be some room to take a
device named FUBAR with a grain of salt... :-) ).
Glenn Everhart
DLSheets
(Alan Greig) writes:
>
>If you have a UPS you can have fun wheeling nodes around buildings
>to a new location before RECNXINTERVAL expires. Puff, pant :-)
>
This reminds me of a discussion I heard at DECUS a couple of years ago.
An Alpha laptop prototype was on display, when someone came up with the
idea of clustering it using a wireless LAN adapter. It was noted that a
new connection manager message would be needed for such a configuration:
CLUEXIT - Node has voluntarily left the building.
Dan
Carl J Lydick
===================== begin quote of prev. article ==========
==However, in general one uses /noada to connect SCSI class driver
==devices; the adapter is in the port driver. There basically ARE no
==values to configure by hand, apart from knowing the SCSI address.
=
=One might wish that the folks who write the on-line help knew that:
=
=$ SYSMAN HELP IO CONNECT Examples
=IO
=
= CONNECT
=
= Examples
=
=
= 1.SYSMAN> IO CONNECT DKA0:/DRIVER_NAME=SYS$DKDRIVER/CSR=%X80AD00-
= /ADAPTER=4/NUM_VEC=3/VECTOR_SPACING=%X10/VECTOR=%XA20/LOG
=
= %SYSMAN-I-IOADDRESS, the CRB is located at address 805AEC40
= %SYSMAN-I-IOADDRESS, the DDB is located at address 805AA740
= %SYSMAN-I-IOADDRESS, the DPT is located at address 80D2A000
= %SYSMAN-I-IOADDRESS, the IDB is located at address 805AEE80
= %SYSMAN-I-IOADDRESS, the SB is located at address 80417F80
= %SYSMAN-I-IOADDRESS, the UCB is located at address 805B68C0
=
= This command example connects device DKA0, loads driver
= SYS$DKDRIVER, and specifies the following:
=
= Physical CSR address
= Adapter number
= Number of vectors
= Spacing between vectors
= Interrupt vector address
=
= The /LOG qualifier displays the addresses of all control
= blocks, as shown.
=
=========================== end quote ====================
=
=These look like examples of connecting an RK05, which those of us with long
=experience will remember is a Unibus disk, 4800 blocks, and one generally
=might have known CSR and vector for it.
Er, since when does an RK05 use SYS$DKDRIVER, which is the SCSI disk driver?
=Lord knows why the examples still use this sort of thing. The current DKDRIVER
=is a SCSI class driver that is TOTALLY UNABLE to handle CSRs or vectors;
Execpt that it's *NOT* DKDRIVER, it's SYS$DKDRIVER.
=the port drivers must do this. You connect DK units to this driver with the
=/noadapter switch. The port drivers know how to talk to their controller
=and the actual hardware.
=
=The problem is likely to be an inadequate number of tech writers to review
=this stuff. Looks like they took the old VAX text, did a global replacement
=of "SYSGEN" by "SYSMAN IO" and shipped it to me.
The SYS$ prefix is a recent addition, so if the documentation is just an edited
version of old documentation, somebody must have edited this as well.
=At least they could have
=picked some driver name that was obviously fake...connect FUBARA0:, for
=example, to SYS$FUBARDRIVER. (There'd at least be some room to take a
=device named FUBAR with a grain of salt... :-) ).
Ah, but as yet, that sounds like a perfect name for an HPC1716T connected to an
Alpha running VMS v6.2. At least it describes the state in which the disk very
quickly finds itself.
A. B. HUNT
the OpenVMS V7.0 New Features Manual.
To implement it Digital has added the DCL command PIPE. The pipe syntax is
otherwise the same as UNIX with some restrictions (i.e. the ; must have
spaces around it since it could be part of a file spec). Some examples they gave at DECUS were:
$ PIPE SHOW USER/FULL | SEARCH SYS$INPUT SMITH
$ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
$ PIPE CC FOO && LINK FOO
$ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
$ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
Keep in mind I may have typoed something here but I think you get the jest of
it.
Christian Knapmeyer
I think they've avoided pipes and multiple commands per line so far
because of the OS overhead when spawning subprocesses. If the
creation of subprocesses won't get faster too, you'll only loose
performance when using pipes. This will be a lot slower than the
"old way" with temp. files.
Or don't they do it with subprocesses?
Greetings,
Christian
--
----------------------------------------------------------------------------
Dipl.-Inform. Christian Knapmeyer Email: kna...@tecmath.de
TecMath GmbH Voice: 06301/606-0 Fax: 06301/606-66
Sauerwiesen 2 Face : Room 115
67661 Kaiserslautern, Germany Disclaimer: as usual
---------- press any key to continue. press any other key to quit.----------
Robert Koehler
: In article <4lgvjr$k...@eccdb1.pms.ford.com> A. B. HUNT (K3531) <HUNT@pt9116> writes:
[...]
: > $ PIPE SHOW USER/FULL | SEARCH SYS$INPUT SMITH
: > $ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
: > $ PIPE CC FOO && LINK FOO
: > $ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
: > $ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
: >
: I think they've avoided pipes and multiple commands per line so far
: because of the OS overhead when spawning subprocesses. If the
: creation of subprocesses won't get faster too, you'll only loose
: performance when using pipes. This will be a lot slower than the
: "old way" with temp. files.
Gee, so far it looks an awfull lot like the PIPE utility I got off the net
which does it with files. IMHO, it aught to be done by managing reuseable
suprocesses much like FileView does, and without a prefix.
------------------------------------------------------------------------------
Bob Koehler | CSC/SSD/MITG
rkoe...@csc.com |
Michael Lemke, Sternwarte Bamberg, Phone: +49-951-9522216
Robert Koehler <rkoe...@csc.com> wrote to Info...@Mvb.Saic.Com
>Christian Knapmeyer (kna...@tecmath.de) wrote:
>
>: In article <4lgvjr$k...@eccdb1.pms.ford.com> A. B. HUNT (K3531) <HUNT@pt9116> writes:
>[...]
>: > $ PIPE SHOW USER/FULL | SEARCH SYS$INPUT SMITH
>: > $ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
>: > $ PIPE CC FOO && LINK FOO
>: > $ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
>: > $ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
>: >
>
>: I think they've avoided pipes and multiple commands per line so far
>: because of the OS overhead when spawning subprocesses. If the
>: creation of subprocesses won't get faster too, you'll only loose
>: performance when using pipes. This will be a lot slower than the
>: "old way" with temp. files.
>
>Gee, so far it looks an awfull lot like the PIPE utility I got off the net
>which does it with files. IMHO, it aught to be done by managing reuseable
>suprocesses much like FileView does, and without a prefix.
>
Absolutely. Hope this isn't PIPE repackaged.
Michael
--
Michael Lemke
Sternwarte Bamberg, University of Erlangen-Nürnberg, Germany
(mic...@io.as.utexas.edu or ai...@a400.sternwarte.uni-erlangen.de)
Arne Vajhoej
> : > $ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
> : > $ PIPE CC FOO && LINK FOO
> : > $ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
> : > $ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
> : >
>
> : I think they've avoided pipes and multiple commands per line so far
> : because of the OS overhead when spawning subprocesses. If the
> : creation of subprocesses won't get faster too, you'll only loose
> : performance when using pipes. This will be a lot slower than the
> : "old way" with temp. files.
>
> Gee, so far it looks an awfull lot like the PIPE utility I got off the net
> which does it with files. IMHO, it aught to be done by managing reuseable
> suprocesses much like FileView does, and without a prefix.
Reusable sub-processes: YES
No prefix: NO (it would break a lot of existing code, backwards
compatibility is always very importaant)
Arne
Arne Vajhøj local DECNET: KOPC::ARNE
Computer Department PSI: PSI%23831001354030::ARNE
Southern Denmark Business School Internet: AR...@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
r...@polaris.east.dialog.com
rkoe...@csc.com (Bob Koehler) writes:
>
>Gee, so far it looks an awfull lot like the PIPE utility I got off the net
>which does it with files. IMHO, it aught to be done by managing reuseable
>suprocesses much like FileView does, and without a prefix.
>
Funny, thinking about this a long time ago I thought it would
be slick using re-usable subprocesses. Me a guy that knows
little about internals. Surely the heavyweights thought the
same (only clearer and better :-) ??
Rob
Carl Perkins
}Christian Knapmeyer (kna...@tecmath.de) wrote:
}: In article <4lgvjr$k...@eccdb1.pms.ford.com> A. B. HUNT (K3531) <HUNT@pt9116> writes:
}[...]
}: > $ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
}: > $ PIPE CC FOO && LINK FOO
}: > $ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
}: > $ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
}: >
}
}: I think they've avoided pipes and multiple commands per line so far
}: because of the OS overhead when spawning subprocesses. If the
}: creation of subprocesses won't get faster too, you'll only loose
}: performance when using pipes. This will be a lot slower than the
}: "old way" with temp. files.
}
}which does it with files. IMHO, it aught to be done by managing reuseable
}suprocesses much like FileView does, and without a prefix.
As long as we are opinionating on how it outg to be done, I think it ought to
be done with the spiffy new kernel threads and mailboxes. Why? Well, why not?
--- Carl
Robert Koehler
: No prefix: NO (it would break a lot of existing code, backwards
: compatibility is always very importaant)
You have existing code that depends on | , < , and > in DCL?
I have gnu utilities that parse these as part of their own command line
when compiled on VMS and I'm not even sure they'd be broken if they
only saw what they'd see on UNIX. Perhaps I'll take a look. Since they also
run on UNIX I'm sure they'll be easy to fix if they are broken.
IMHO if a prefix is required, all my UNIX "friends" will think it a PITA.
Larry D Bohan
>
> Funny, thinking about this a long time ago I thought it would
> be slick using re-usable subprocesses. Me a guy that knows
> little about internals. Surely the heavyweights thought the
> same (only clearer and better :-) ??
>
> Rob
could hope that the intro of kernel threads and this pipe
implementation in the same release, would not be a coincidence.
w/ what little i know about how DCL implements process
permanent files (sys$error, sys$output, etc.), it seems like
it would be difficult to "truly" implement piping without breaking
some existing functionality.
i wish DEC had kept the demo alphas going;
(ie, axpvms.pa.dec.com, et.al); i would've liked to check it out.
fair...@sldb4.slac.stanford.edu
> Arne Vajhoej (AR...@ko.hhs.dk) wrote:
>
> : No prefix: NO (it would break a lot of existing code, backwards
> : compatibility is always very importaant)
>
> You have existing code that depends on | , < , and > in DCL?
Well, the angle brackets could be part of a directory
specification, you know, like DKA1:<FOOBAR>? But the earlier post
already implied that the semi-colon is being used, and "must be
surrounded by spaces" (my paraphrase), so I would think similar
caveats could be applied here...
One guess: it's a lot easier to get pipes into DCL if PIPE is a
verb in DCLTABLES than if the whole manner of parsing DCL commands
must look for these special characters first before actually
handling the verb recognition. Maybe it was an engineering trade:
you can get this one (the PIPE verb) done in a hurry fairly easily,
the other one would probably involve getting into the bowels of DCL
pretty deeply...
[...]
> IMHO if a prefix is required, all my UNIX "friends" will think it a PITA.
Ah, what the heck..."stuff" your unix "friends". They have
enough trouble with typing SET DEF instead of CD, so now they're
going to complain about having to type PI. So what?! :-)
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
John_Da...@cup.portal.com
>>> $ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
>>> $ PIPE CC FOO && LINK FOO
>>> $ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
>>> $ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
> No prefix: NO (it would break a lot of existing code, backwards
> compatibility is always very importaant)
Excuse me? I have been doing DCL (and fixing bad DCL written by users) for a
long time, and I have never seen a piece of working DCL code that looks like
any of the above with the word "PIPE" omitted. It may be technically possible,
but the code would have to be very weird if not totally contrived. What
existing code do you have that it would break?
(MMS makefiles are a different story, but there's no reason that the same new
VMS release couldn't include a revised MMS if it's really needed.)
John David Galt
r...@polaris.east.dialog.com
rkoe...@csc.com (Bob Koehler) writes:
>
>Arne Vajhoej (AR...@ko.hhs.dk) wrote:
>
>: No prefix: NO (it would break a lot of existing code, backwards
>: compatibility is always very importaant)
>
>You have existing code that depends on | , < , and > in DCL?
>
Yes, several things would break. I actually "like" several
UNIX utilities. Here are two lines that would get hammered (sans
PIPE):
$ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
$ sed -n "/^''p1' /p" map.file >'mypid'.tmp
The PIPE prefix is a good idea. Wondered how they would implement
pipes when they showed up. With PIPE you can be assured you can
take existing DCL and "add value" knowing it won't break.
Rob
Phillip Helbig
>Arne Vajhoej (AR...@ko.hhs.dk) wrote:
>You have existing code that depends on | , < , and > in DCL?
Which reminds me: what is the reason for the possibility of using <> instead
of [] as a directory delimiter? (Just do a SET DEFAULT <> and see what
happens:) Is this just historical baggage? If so, why do we now have []
instead of <>? If not, what is <> good for? (The brackets just reminded me;
this of course has nothing to do with what Arne was talking about.)
--
Phillip Helbig Email ....................... phe...@hs.uni-hamburg.de
Hamburger Sternwarte Tel. ................................. +49 40 7252 4110
Gojenbergsweg 112 Fax .................................. +49 40 7252 4198
D-21029 Hamburg http://www.hs.uni-hamburg.de/english/persons/helbig.html
I don't speak for the Hamburg Observatory; the Observatory doesn't speak for me
Uwe Leinberger GSI Darmstadt
IBM with 3270 terminals, there is NO [] there as far as I can remember....
BUT of course <> ;-))
(Or was it {} ?? Anyway, we always needed a hack to write TeX-files on
the IBM, where both [] and {} are used frequently....)
UWe
Carl J Lydick
=of [] as a directory delimiter? (Just do a SET DEFAULT <> and see what
=happens:) Is this just historical baggage? If so, why do we now have []
=instead of <>? If not, what is <> good for? (The brackets just reminded me;
=this of course has nothing to do with what Arne was talking about.)
Once upon a time, not all terminals had both <> and [], but all of them (or
virtually all of them) had one or the other of the pairs.
Carl J Lydick
=
=In article <4lgvjr$k...@eccdb1.pms.ford.com> A. B. HUNT (K3531) <HUNT@pt9116> writes:
=
= >
= > The next version of OpenVMS (V7.1) will have pipes. It is even documented in
= > the OpenVMS V7.0 New Features Manual.
= >
= > To implement it Digital has added the DCL command PIPE. The pipe syntax is
= > otherwise the same as UNIX with some restrictions (i.e. the ; must have
= > spaces around it since it could be part of a file spec). Some examples they gave at DECUS were:
= >
= > $ PIPE SHOW USER/FULL | SEARCH SYS$INPUT SMITH
= > $ PIPE SET FILE/PROT=(O:D) TEMP.DIR ; DELETE TEMP.DIR;
= > $ PIPE CC FOO && LINK FOO
= > $ PIPE CC FOO1 & CC FOO2 & CC FOO3 &
= > $ PIPE (SET DEF [.SRC] ; MMS) | SEARCH SYS$INPUT "%CC"
Er, just how would the following be parsed, then?
$ PIPE DIRECTORY ; | SEARCH SYS$INPUT ;3
Please note that a ; all by itself is a valid file specification in some cases.
art...@ais.com
> Arne Vajhoej (AR...@ko.hhs.dk) wrote:
>
> : compatibility is always very importaant)
>
in countries where [ and ] are not on the standard keyboard.
>
> I have gnu utilities that parse these as part of their own command line
> when compiled on VMS and I'm not even sure they'd be broken if they
> only saw what they'd see on UNIX. Perhaps I'll take a look. Since they also
> run on UNIX I'm sure they'll be easy to fix if they are broken.
>
> IMHO if a prefix is required, all my UNIX "friends" will think it a PITA.
>
A. B. HUNT
driver. However, I don't know for sure.
Alan B. Hunt
Stephen Hoffman
In article <4ln03t$4...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
:... what is the reason for the possibility of using <> instead
:of [] as a directory delimiter?
The <[> and <]> characters are not available on all keyboards: there
are (were?) a few country keyboards that did not include these keys.
------------------------- pure personal opinion ---------------------------
Stephen Hoffman OpenVMS Engineering hof...@xdelta.enet.dec.com
---------------------------------------------------------------------------
Robert Koehler
r...@polaris.east.dialog.com wrote:
: rkoe...@csc.com (Bob Koehler) writes:
: >
: >You have existing code that depends on | , < , and > in DCL?
: >
: Yes, several things would break. I actually "like" several
: UNIX utilities. Here are two lines that would get hammered (sans
: PIPE):
: $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
: $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
Acutualy sed is one of the gnu utilities I have that parses the "pipes" for
itself. Since it has no #ifdef vms in it, I'm going to try a straight
recompile on a UNIX and see if it breaks.
Robert Koehler
Phillip Helbig (phe...@hs.uni-hamburg.de) wrote:
: >Arne Vajhoej (AR...@ko.hhs.dk) wrote:
: >You have existing code that depends on | , < , and > in DCL?
: Which reminds me: what is the reason for the possibility of using <> instead
: of [] as a directory delimiter? (Just do a SET DEFAULT <> and see what
: happens:) Is this just historical baggage? If so, why do we now have []
: instead of <>? If not, what is <> good for? (The brackets just reminded me;
: this of course has nothing to do with what Arne was talking about.)
It was added to a large extend for TOPS-20 compatability. TOPS-20 used <> for
directory names. Before <> was added to VMS's directory name parsing one had
to quote all TOPS-20 directory names when accessing TOPS-20 directories via
DECnet from the DCL command line
(e.g. $copy node::"<directory>file.name" localfile). After adding it, and
providing long file names one could leave out the quotes.
(e.g. $copy node::<directory>file.name localfile).
t_w...@eurokom.ie
> Yes, several things would break. I actually "like" several
> UNIX utilities. Here are two lines that would get hammered (sans
> PIPE):
>
> $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
> $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
Anything that would break commands like the above is a *good* thing. Unix's
single character case dependent command line arguments is about the worst
feature of its user interface, and it always annoys me to see programs
'ported' to VMS with this syntax intact rather than replacing it with CLI
calls.
------------------------------------------------------------------------------
Tom Wade | Internet: T.W...@vms.eurokom.ie (all domain mailers).
Network Manager | X400: g=tom;s=wade;o=eurokom;p=eurokom;a=eirmail400;c=ie
EuroKom | Tel: +353 (1) 283-0555
UCD Belfield | Fax: +353 (1) 283-8605
Dublin 4 | Disclaimer: This is not a disclaimer
Ireland | "Friends don't let friends do Unix !"
------------------------------------------------------------------------------
r...@polaris.east.dialog.com
t_w...@eurokom.ie (Tom Wade) writes:
>In article <009A15BC.D...@polaris.east.dialog.com>, r...@polaris.east.dialog.com writes:
>
>> Yes, several things would break. I actually "like" several
>> UNIX utilities. Here are two lines that would get hammered (sans
>> PIPE):
>>
>> $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
>> $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
>
>Anything that would break commands like the above is a *good* thing. Unix's
>single character case dependent command line arguments is about the worst
>feature of its user interface, and it always annoys me to see programs
>'ported' to VMS with this syntax intact rather than replacing it with CLI
>calls.
>
To reiterate: I actually "like" several UNIX utilities, sed being
one of them. Given this challenge:
"Find all lines that contain a certain string at the
beginning of a line."
I can then do something like: fa = f$file("''mypid'.tmp","ALQ")
and if 0 know I get no hits and so then can branch past additional
DCL to follow.
Do that without using sed. How many lines of DCL did you use?
Now you see my point. As for the -n /p, etc. yes that is
hokey. Something to get used to I guess.
What kind of CLI call or lexical would you propose to give sed
like capabilities?
Rob
Arne Vajhoej
> > No prefix: NO (it would break a lot of existing code, backwards
> > compatibility is always very importaant)
>
> long time, and I have never seen a piece of working DCL code that looks like
> any of the above with the word "PIPE" omitted. It may be technically possible,
> but the code would have to be very weird if not totally contrived. What
> existing code do you have that it would break?
All the thousands of programs using and interpreting ><| itself (and
using it in a non-transparent way).
Arne Vajhoej
> > Yes, several things would break. I actually "like" several
> > UNIX utilities. Here are two lines that would get hammered (sans
> > PIPE):
> >
> > $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
> > $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
>
> Anything that would break commands like the above is a *good* thing. Unix's
> single character case dependent command line arguments is about the worst
> feature of its user interface, and it always annoys me to see programs
> 'ported' to VMS with this syntax intact rather than replacing it with CLI
> calls.
You do not like this lind of syntax. Neither do I, but it is a fact that
it exist.
And IMHO nothing has higher priority than backwards compatibility, so that
when you upgrade VMS then everything continues to work. Whether the
programs/scripts wa sbadly writte in the first place or it is easy to
fix does not matter. If we have to rewrite code after a VMS upgrade, then
VMS engineering has failed.
OK I know that sometimes it can be necesarry,
but there better be damn good reasons (f.ex. the speed increase of
VAX->Alpha could justify some code-changes !).
r...@polaris.east.dialog.com
SAPS...@UHSFUN.UHSA.UH.EDU (David Bratton) writes:
>
>In article <009A174E....@polaris.east.dialog.com>, r...@polaris.east.dialog.com writes:
>>
>>t_w...@eurokom.ie (Tom Wade) writes:
>>
>>>In article <009A15BC.D...@polaris.east.dialog.com>, r...@polaris.east.dialog.com writes:
>>>
>>>> Yes, several things would break. I actually "like" several
>>>> UNIX utilities. Here are two lines that would get hammered (sans
>>>> PIPE):
>>>>
>>>> $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
>>>> $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
>>>
>>
>> To reiterate: I actually "like" several UNIX utilities, sed being
>> one of them. Given this challenge:
>>
>> "Find all lines that contain a certain string at the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> beginning of a line."
> ^^^^^^^^^^^^^^^^^^^^
>>
>> I can then do something like: fa = f$file("''mypid'.tmp","ALQ")
>> and if 0 know I get no hits and so then can branch past additional
>> DCL to follow.
>>
>> Do that without using sed. How many lines of DCL did you use?
>> Now you see my point. As for the -n /p, etc. yes that is
>> hokey. Something to get used to I guess.
>>
>> What kind of CLI call or lexical would you propose to give sed
>> like capabilities?
>>
>
>There was a thread on this subject not too long ago. I thought we had
>established that as of VMS 6.2 this can be done using the
>/KEY=(POS:###,SIZ:###) qualifier of the SEARCH command.
>
We have an application that is at customer sites across a broad
range of VMS back to 5.1. The challenge is to use a method or
tool that works across all versions of the OS. That is why my
feeling towards PIPE is lukewarm at best.
Rob
David Bratton
In article <009A174E....@polaris.east.dialog.com>, r...@polaris.east.dialog.com writes:
>
>t_w...@eurokom.ie (Tom Wade) writes:
>
>>In article <009A15BC.D...@polaris.east.dialog.com>, r...@polaris.east.dialog.com writes:
>>
>>> Yes, several things would break. I actually "like" several
>>> UNIX utilities. Here are two lines that would get hammered (sans
>>> PIPE):
>>>
>>> $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
>>> $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
>>
>>single character case dependent command line arguments is about the worst
>>feature of its user interface, and it always annoys me to see programs
>>'ported' to VMS with this syntax intact rather than replacing it with CLI
>>calls.
>>
>
> one of them. Given this challenge:
>
> "Find all lines that contain a certain string at the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> beginning of a line."
^^^^^^^^^^^^^^^^^^^^
>
> I can then do something like: fa = f$file("''mypid'.tmp","ALQ")
> and if 0 know I get no hits and so then can branch past additional
> DCL to follow.
>
> Do that without using sed. How many lines of DCL did you use?
> Now you see my point. As for the -n /p, etc. yes that is
> hokey. Something to get used to I guess.
>
> What kind of CLI call or lexical would you propose to give sed
> like capabilities?
>
>
There was a thread on this subject not too long ago. I thought we had
established that as of VMS 6.2 this can be done using the
/KEY=(POS:###,SIZ:###) qualifier of the SEARCH command.
Instead of f$file you can also just use $STATUS after the search.
--
David Bratton
University of Houston System
DBra...@uh.edu
Jan Vorbrueggen
In article <009A17D6....@polaris.east.dialog.com>
r...@polaris.east.dialog.com writes:
We have an application that is at customer sites across a broad
range of VMS back to 5.1. The challenge is to use a method or tool
that works across all versions of the OS. That is why my feeling
towards PIPE is lukewarm at best.
Hey, why stop at 5.1? Why not 4.3? Or 3.2? I'm sure there are still some VMS
sytems outta there running 3.2!
But for the more immediate question: 5.1 contains TPU. There should be no
problem 8-) to write a little TPU that emulates sed in this regard.
Jan
Tim Short
r...@polaris.east.dialog.com wrote:
> To reiterate: I actually "like" several UNIX utilities, sed being
> one of them. Given this challenge:
>
> "Find all lines that contain a certain string at the
> beginning of a line."
>
> I can then do something like: fa = f$file("''mypid'.tmp","ALQ")
> and if 0 know I get no hits and so then can branch past additional
> DCL to follow.
>
> Do that without using sed. How many lines of DCL did you use? Rob
You could also do this using LSE, or the other editors that have a
def key/learn function, as follows:
i). Open the file you are searching, plus temp.tmp.
ii). Def the key to search for the string and write it to temp.tmp.
iii). Def a second key to do the first one n times (this will make it
much faster...) If you want to go to lunch, go through this loop
more times and press one key.
I have done about 10k lines in a minute or so on a midrange
VAXstation in about a minute.
--
r...@polaris.east.dialog.com
am...@tekvx1.mds.com (Alan S. Muir) writes:
>
>
>In Message-ID: <009A174E....@polaris.east.dialog.com>,
>R...@polaris.east.dialog.com writes
>
>>>In article <009A15BC.D...@polaris.east.dialog.com>,
>>>r...@polaris.east.dialog.com writes:
>>>>
>>>> $ sed -n "/^''saveset' /p" map.file >'mypid'.tmp
>>>> $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
>>>
>> To reiterate: I actually "like" several UNIX utilities, sed being
>> one of them. Given this challenge:
>>
>> "Find all lines that contain a certain string at the
>> beginning of a line."
>>
>> I can then do something like: fa = f$file("''mypid'.tmp","ALQ")
>> and if 0 know I get no hits and so then can branch past additional
>> DCL to follow.
>
>> Do that without using sed. How many lines of DCL did you use?
>
>OK, I couldn't resist...
>
> $ KEY = "''p1'" ! String to search for
> $ LEN = F$LENGTH(KEY)
> $ SEARCH/KEY=(POS:1,SIZ:'LEN') MAP.FILE "''KEY'"/OUTPUT='MYPID'.TMP
> $ IF F$FILE("''MYPID'.TMP","ALQ") .EQ. 0 THEN GOTO BRANCH
>
>Note that, if I wanted to reduce lines, I could hard-code the KEY and LEN
>variables, but I thought you might want to see something a little more flexible.
>
>Obviously you haven't looked at the New Features for VMS V6, so why are you
>asking for new features for V8?
>
Lost information on the way. The original scenario was: "why
have the PIPE prefix?" Answer: because existing lines of DCL
would break. I chimed in with my example that would break sans
prefix (the sed example). What you are proposing works nicely.
However, if your application ran or runs under version 5.X the
feature you are highlighting there (/KEY=) does not exist. So,
if a person were to write a DCL script and wish it to run under
various flavors of VMS (we go back to 5.1 and actually support
several 5.3 sites -- why upgrade if you don't need to???) sed
is a very handy tool.
I am not asking for new features for version 8.
Put this another way:
"Suppose you have an application that you support under
numerous flavors of VMS (5.3 on up). Without using
sed, reduce my example to 1 line of DCL."
HA.
Rob
mat...@seqaxp.bio.caltech.edu
In article <1996Apr26.1...@vms.eurokom.ie>, t_w...@eurokom.ie writes:
>In article <009A15BC.D...@polaris.east.dialog.com>, r...@polaris.east.dialog.com writes:
>
>> UNIX utilities. Here are two lines that would get hammered (sans
>> PIPE):
>>
>> $ sed -n "/^''p1' /p" map.file >'mypid'.tmp
>
>single character case dependent command line arguments is about the worst
>feature of its user interface, and it always annoys me to see programs
>'ported' to VMS with this syntax intact rather than replacing it with CLI
>calls.
In an ideal world I would agree with you, however, mitigating against this
extra work are:
1. The need to rewrite the documentation
2. The very high probability that the command line would break at the
next .1 higher release
3. Modifying the command line is often the hardest part. It isn't that
writing the CLD and so forth is such a pain, but rather that the
command line tends to be strewn about in the C code and often cannot
be cleanly #ifdef'd out without a serious rewrite of one or more
modules.
I've thought about this problem rather a lot (having been through many
Unix->VMS ports) and I think there is a solution, but maybe not the one you
had in mind. Imagine that there was a nice function, written in ANSI C,
but containing the appropriate platform dependent pieces for handling
program arguments. Imagine that it was free and so well known that people
actually used it (this is the key to the whole endeavor - as long as
everybody rolls their own command line ports will always be miserable).
Then this problem would go away. The interface would be described in some
language other than CLD (because no Unix/Mac/Windows programmer will ever
use it if he/she thinks that it has anything to do with VMS) but would be
able to incorporate CLD. Conflicting? No, not really, see below.
Here is an example, MGBOOK.CLD (a pretty easy example):
DEFINE VERB MGBOOK
IMAGE MADGOAT_EXE:MGBOOK.EXE
PARAMETER P1, LABEL=FILE, VALUE(TYPE=$FILE)
QUALIFIER BOOK, NONNEGATABLE
QUALIFIER DEBUG
QUALIFIER RESTRICT_WIDTH
QUALIFIER SHELF, NONNEGATABLE
QUALIFIER TAB
DISALLOW BOOK AND SHELF
Here is what the platform independent form might look like, it starts out
as an cli_descrip.h file (for Unix and VMS, but it could also be for
DOS, MVS, etc.).
/*Declare types of all pieces that will be passed in from the outside world*/
char* file;
int book;
int debug;
int restrict_width;
int shelf;
int tab;
/*Declare variables to hold states for all pieces*/
int state_file; /*0 if not specified, 1 if negated, and so forth */
int state_book; /* some standard set of flags */
int state_debug;
int state_restrict_width;
int state_shelf;
int state_tab;
/* BEGIN CLI DESCRIPTION
argument 0:
internal: main
external:
Unix: mgbook
VMS: DEFINE VERB MGBOOK
VMS: IMAGE MADGOAT_EXE:MGBOOK.EXE
argument 1:
internal: file
external:
Unix: -f
VMS: PARAMETER P1, LABEL=<>, VALUE(TYPE=$FILE)
argument 2:
internal: book
external:
Unix: -b
VMS: QUALIFIER <>, NONNEGATABLE
argument 3:
internal: debug
Unix: -g
VMS: QUALIFIER <>
argument 4:
internal: restrict_width
Unix: -r
VMS: QUALIFIER <>
argument 5:
internal: shelf
Unix: -s
VMS: QUALIFIER <>, NONNEGATABLE
argument 6:
internal: tab
Unix: -t
VMS: QUALIFIER <>
POSTPROCESS:
Unix: if(state_shelf == 1 & state_book == 1){
Unix: printf('-s and -b are not allowed together\n');
Unix: exit();
Unix: }
VMS: DISALLOW BOOK AND SHELF
END CLI DESCRIPTION*/
The make/build procedure would preprocess this file as appropriate for
the platform. For the VMS case, you can see that all that happens is that
it strips out all of the VMS: and Internal: lines, substitutes the value
for internal into <> as appropriate, writes that out as a CLD and then
compiles it with SET compile/object. For the Unix side it would set up
some code to search for -b etc and set the appropriate internal
pieces, then run the results through the postprocess code.
Then the command line would be retrieved via:
/*some module that needs info from the command line*/
#include <cli_descrip.h>
etc.
status = get_cli(); /*Fill in the internal variables*/
if(state_file == 1){
if(state_book == 1){
}
if(state_shelf == 1){
}
}
etc.
That is - the command line processing has been totally shunted off to the
get_cli() function, which has been built up from the the cli_descrip.h. What
goes on inside it is largely platform dependent, but the rest of the code
never has to know what the command line looked like.
Ok, it doesn't solve the documentation problem, but it least it would make
the programs look right on each platform. Programmers that used this would
automatically place all platform specific CLI pieces into the one .h file,
which would make doing ports *MUCH* easier than it currently is.
In case it isn't totally obvious, it should also be possible to write
a .CLD to cli_descrip.h converter - so that any existing VMS code could be
automatically converted. It should also be possible to generalize this to
work with window interfaces (albeit, not trivially.)
Anyway, just an idea for any of you with too much time on your hands and a
need to to write some multiplatform command line driven code :-).
Regards,
David Mathog
mat...@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech