Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrpcd!wright!jsloan From: jsloan@wright.EDU (John Sloan) Newsgroups: comp.unix.wizards Subject: Re: Help us defend against VMS! Message-ID: <284@wright.EDU> Date: 1 Mar 88 12:43:44 GMT References: <1636@tulum.UUCP> Organization: Wright State University, Dayton OH, 45435 Lines: 105 in article <1636@tulum.UUCP>, hirai@swatsun.uucp (Eiji "A.G." Hirai) says: > Please help shed the light for us! Please tell us what you think would be > reasons why you wouldn't buy VMS! (or why you would). We need the help > of all you wizards out there. Any examples you can think of will help! I am not a wizard. I manage a laboratory with (as of last week) twenty Unix systems ranging in size from a SUN-3/280S (our principal timesharing system), a cluster (in the generic sense) of SUN-3 workstations with a 3/180S server, a VAX 785, a VAX 750, some NCR Tower 32/600s, and some smaller machines. Most of the engines are ethernetted together, and the VAXen and SUNs are all integrated using NFS and YP to provide a computing environment where CPUs are considered merely peripherals: if you need a bigger one, put it online on the net and use it, and don't worry too much what it is or where it came from. Our of four computer centers on campus (i.e. organizations which have some degree of centralized computing in terms of geographical location and management), we are the only Unix shop, the rest being VMS with one IBM mainframe for administrative work. I am fighting the same fight you are, arguing with the computer center Directors and a Vice President. I object to the term wizard, and if you're smart, you'll drop it too. I am not a wizard, and none of the 2.7 FTE people that work for me supporting our environment are wizards either. Unix _must_ shake the reputation of needing a wizard to maintain it if it is going to be accepted in organizations where skilled labor is expensive and hard to find. I am incredible fortunate, and I know that. I have highly skilled, motivated, educated (most with a M.S. in C.S.), and _experienced_ people working for me, but your typical campus computer center is usually not that fortunate. Our center tried to hire one of my people away (I think I would have gladly let him go, if only to improve conditions at center), and he was seriously considering it until they discovered that he would have to take a pay cut. So much for competitiveness in salary, even within the University, and I can't pay what the people just across the street will pay for the same person. Don't say wizard. Don't say guru. "Systems manager" might be okay. But don't give anyone the idea that you need a wizard to maintain a Unix system because [A] it just isn't true anymore, if it ever was, and [B] it will discourage any migration to Unix. Why Unix? I sit on a committee that reports to our VP for Computing (a CIO in corporate parlance) that is supposed to advise our Computer Center Directors on purchases, policy, procedure, etc. DEC has delivered a proposal for a 6MIPS VAX for $1.2M. Six months ago I purchased, received, and deployed our Sun-3/280S, a 4MIPS engine for under $100K. Question: which is the better deal? Answer: The $1.2M VAX. Because it runs VMS. Never mind that for CPU intensive applications (which is predominantly what we're talking about here) the VAX is _eight_ times more expensive (with comparable amounts of disk space and memory) than the Sun. The Sun doesn't run VMS. The time has come for us to realize the _true_ cost of proprietary technologies. When you run VMS you have _one_ name in your rolodex card file, and it says "Digital". It is no longer a question of getting the most for your money; it is a matter of finding out from your sales rep how many zeros to write on the check. There is another issue than capital investment: intellectual investment. Unix has a reputation as being user hostile or having a steep learning curve, and yet once that learning curve has been achieved, your intellectual investment is protected across an incredible number of machines and models for many many vendors. Sure, there are differences between the system calls or management from system to system, but at least I can sit down and immediately begin editing, manipulating files, using tools, helping me while I learn those differences. And for many users, there _is_ no difference. When we moved our faculty off our 750 onto the 3/280S, the only difference (besides vastly improved response time) that they noticed was that the role or "R" and "r" in the mail command was reversed... which lasted until we figured out how to change it. These two machines are from different vendors, and have different architectures, but they had one thing in common: both had common roots in Unix. There are financial considerations here too, in terms of productivity and training costs. I spent five years as a systems programmer in an IBM mainframe environment, and when I left I was the senior technical resource in my shop. I spend two years in a PDP-11 environment, two years in a VAX/VMS environment, and the past two years in our current Unix environment. I can say without reservation that Unix is the most useful, most productive, and most (dare I say it?) _friendly_ environment that I, as a professional programmer and manager, have ever had the pleasure of using. Subjective opinion? Hmmmmm.... perhaps. But I'm not so sure. In the end, you will have to find your own justification, your own strategy. On my end, I am confident that the University will continue to fritter away the taxpayers money on proprietary technologies, while I work hard on providing the best, most cost effective computing environment for the money. I apologize for the length of this. I know, few hard facts, mostly just soapboxing. Perhaps it will prompt some discussion. I wish you luck. -- John -- John Sloan Wright State University Research Center CSNET: jsloan@SPOTS.Wright.Edu 3171 Research Blvd., Kettering, OH 45420 UUCP: ...!cbosgd!wright!jsloan (513) 259-1384 (513) 873-2491 Logical Disclaimer: belong(opinions,jsloan). belong(opinions,_):-!,fail.