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
>
