LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous (more recent) messageNext (less recent) messagePrevious (more recent) in topicNext (less recent) in topicPrevious (more recent) by same authorNext (less recent) by same authorPrevious page (July 2007, week 4)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Thu, 26 Jul 2007 09:18:38 +1000
Reply-To:     d@dkvj.biz
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         David Johnson <d@DKVJ.BIZ>
Subject:      Re: SAS Product Selection
In-Reply-To:  <74227316AFB87C4687325EB8007D225A0EC2CF@mq-sbs.mq.local>
Content-Type: text/plain; charset="us-ascii"

Now that's interesting and reminds me of the Unix box, possibly Sun, that I read about some three or four years ago. It had been running uninterrupted for an extraordinary number of years and the manufacturer wanted it back to do a post mortem and find out how they got it right. It seems all the manufacturers have expectations on the long term performance of their hardware and software. I suspect the uptime calculation was limited by some designer who couldn't conceive that 2**32 would be reached in expected use of the hardware.

I pulled a Windows box out of the "to be repaired" pile two days ago to deal with some flaky hardware and found it had been out of service for 652 days. That gave me a problem updating the antivirus solution, but it also meant I loaded almost sixty updates from M$ Update, which took three sessions because some wanted to be run in isolation and some required reboots, one group just failed and had to be run again and after I had completed the list the list was populated with new updates on two more passes. Reboots during update seems to be a requirement around 1 in 10 to 1 in 5 M$ updates, and I'm curious to know how you can keep an SBS server up that long, and keep it patched without going through the reboot process. Or perhaps that is a proprietary question you'd rather not address publicly.

The UPS is essential, but with battery life around 3 years, unless you can hot swap the batteries, that is likely to take down your other hardware anyway.

27 months is a respectable period, and generally I'd be happy if all hardware only required a major spring clean planned every two years.

Kind regards

David

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of Phil Rack Sent: Tuesday, 24 July 2007 11:31 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: SAS Product Selection

I had an MS SBS box (Small Business Server) running non-stop for 27 months. After I got the server configured and hooked up to the internet, it ran like a charm. The only reason I took it down was I that I replaced the hardware and server software and used the existing hardware as a Network Attached Server.

By my calculations that's over 19,000 hours. As a matter of fact, the software that ran on the taskbar that displayed uptime was screwed up because it would start over calculating uptime after 49 days. It couldn't handle integers larger than 2^32 I suppose.

That SBS box handled file and print services, Exchange, SQL Server, IIS, Remote computing services and ISA. The other thing that really helps is having a huge UPS on the box.

Phil Rack MineQuest, LLC SAS Consulting and Contract Programming Services

Web: www.MineQuest.com Tel: (614) 457-3714 Web Conference: SightSpeed

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of David Johnson Sent: Tuesday, July 24, 2007 9:10 AM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: SAS Product Selection

It's ten years on Michael, Solaris has seen something like five or six iterations since then. Back then I sat and wondered why some of the Unix gurus were pushing their OS so hard when it clearly was behind the 8-ball in performance for the average business.

HP-UX in 1999-2000 didn't change my mind, but Solaris 8 a year or so later did. Now I think it is a realistic challenge, but the problem is having the crew to handle its care and feeding in the same way Z/OS and its variants were and are baby sat. I'm still not convinced that we really have the trained sysops to handle the Unices in the same way yet, but the Sysops for mainframes are a retiring and job-changing breed and that puts some writing on the wall for mainframes.

When the day comes that Windows servers can be up for 30 years without a reboot and without a problem, I'll show the same respect for them that I have for the alternatives. In the meantime, this migration to Windows platforms seems to me to be dependent on a quick prayer every so often, or the deployment of 150% more capacity in load shared servers than you need so that the weekly trials of one or two don't kill your business.

I recognise that they are fighting words, but I have yet to see any of my Windows servers exceed 5000 CPU hours without intervention.

Kind regards

David

-----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of Michael Raithel Sent: Tuesday, 24 July 2007 10:42 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: SAS Product Selection

Dear SAS-L-ers,

David Johnson posted, in part, the following:

<<David's entire posting can be found beneath the Sig line>>

> I'm waiting for the day that Gartner or another reputable > source finally publishes a study on the real costs of this > type of move. Mainframes are often seen as arcane or > expensive, and there are a number of organisations trying to > cut costs by moving to mid range server deliveries. However, > mainframe costs are for what they deliver, and I have yet to > see a real cost comparison where delivering full > like-for-like functionality has been honestly factored in. > David, the Gartner Group actually _DID_ such a study in the late nine-tees, which turned out to be very favorable to mainframes. It compared the costs of implementing and running job scheduling packages, security packages, and applications software; and the costs of systems staff and programming staff on mainframes v.s. midrange (Unix, Windows servers) systems. The study found that, overall, it was cheaper to run such things on the mainframe than on the midrange systems.

We did not purchase the report at the time, but only saw the teaser abstract. I remember the incident, because I ran around yelling "told you so" to any number of mainframe-hating colleagues. I was so much older then, I'm younger than that now.

I only offer this as a "the report is out there; somebody who really wants to can go an find it", as I have no intention of being an advocate one way or another if the idiot mainframe v.s. other platform wars reignites on the 'L

Best of luck to everybody in their SAS endeavors... on all platforms!

I hope that this suggestion proves helpful now, and in the future!

Of course, all of these opinions and insights are my own, and do not reflect those of my organization or my associates. All SAS code and/or methodologies specified in this posting are for illustrative purposes only and no warranty is stated or implied as to their accuracy or applicability. People deciding to use information in this posting do so at their own risk.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Michael A. Raithel "The man who wrote the book on performance" E-mail: MichaelRaithel@westat.com

Author: Tuning SAS Applications in the MVS Environment

Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second Edition http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172

Author: The Complete Guide to SAS Indexes http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Until you've lost your reputation, you never realize what a burden it was. - Margaret Mitchell +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

<<David's entire original posting>>

> I'm waiting for the day that Gartner or another reputable > source finally publishes a study on the real costs of this > type of move. Mainframes are often seen as arcane or > expensive, and there are a number of organisations trying to > cut costs by moving to mid range server deliveries. However, > mainframe costs are for what they deliver, and I have yet to > see a real cost comparison where delivering full > like-for-like functionality has been honestly factored in. > > Unless they are badly administered, most mainframe > installations will not allow one or two people to start lots > of jobs and hog resources. Out of the box, mid range systems > need some work before quotas are properly applied for storage > and job submission queues. That work is not cheap because it > requires reasonably high skill levels from the designers. > Indeed, since the machines almost work "out of the box", it > seems that configuration sometimes isn't done. > > The upshot is that the steady, acceptable performance users > may have come to expect from the mainframe is replaced with > poor performance on the mid range replacement. It's not that > I'm against mid range machines, I have a real liking for > certain hardware that "sheds light" in my comms room. But > that particular hardware is not cheap, and can disappoint if > it isn't set up correctly through an iterative process > examining the real loading and delivery times that the > business requires. > > > So, I'm not in favour of the move from the mainframe, I'm > probably less in favour of the move to individual licences on > machines. The cost of that effort is something your SAS > representative will negotiate with you, and changes from site > to site and the product mix required and offered. But that > isn't the only cost. In this day of the SAS Management > Console and Enterprise SAS, I would seriously consider the > server solution over the individual solution for these > reasons among others: > > . Central licence management saving issues every 12 months. > . Central deployment of libraries permitting code to be > shared unchanged between users. . Enhanced support for > technologies like Enterprise Miner server and Enterprise > Guide. . Consolidation and consistency of metadata to users: > the "one version of the truth". . Potential to deploy a high > end server to perform resource hungry jobs more efficiently. > . Development and sharing of code that will work unchanged > for any user in the group. > > I would be cautious about the solution if there were not in > place a robust and reliable back-up and recovery process for > data, if there were not a skilled sys admin to set up and > maintain the OS on the machine, if there were not a skilled > SAS admin to maintain the software and so on. Fixing these > issues first will add substantially to the cost, and while > they may not be seen as project costs, and perhaps hidden, > they are vital to the delivery. > > Kind regards > > David > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On > Behalf Of Brian > Sent: Friday, 20 July 2007 11:40 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: SAS Product Selection > > > The new environment that I was speaking of is a hosted > database. We will be leaving the mainframe (never to > return). The number of total users will probably be around > 10. We are considering a dedicated SAS server. With that > said, is it cheaper just to buy the license for the server, > instead of individual licenses per user/CPU? > > Thank you all for your respsonses. > > Brian >


Back to: Top of message | Previous page | Main SAS-L page