Re: zEC12, and previous generations, why? type question - GPU computing.

2012-09-05 Thread Conlin, Pete
With IBM's acquisition of SPSS several years ago  the recent acquisition of 
Netezza (for use as an attached processor for computational workloads on 
zSeries), IBM's z/Series intentions seem to have changed.  After the AS 
(Application System) disaster (early eighties, great demo, not scalable, ADRS 
based if I recall), I hope the performance concerns are addressed.  Even the 
DB2 folk no longer accept a performance hit with a new release (more code  
features take more resources was a mantra at IDUG for years, finally falling 
flat with V8.)

In particular, with the minimization of locking, data above the bar, 
increased use of zIIP  general performance improvements, analytics with DB2 on 
zSeries might be cost effective for big data in a shared workload environment.

See (unfortunately marketing oriented):  

http://www.clabbyanalytics.com/uploads/zBAfinalfinalfinal.pdf
and   
http://berniespang.com/2012/06/08/clients-chose-ibm-system-z-for-analytics-over-teradata-and-oracle-exadata/

It would have been interesting if they had put something like this together for 
the 2010 census data in the way SAS did
for the 1980 data, but there's plenty more data sources against which these 
marketing claims will soon be tested.
  --Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Mark Post
Sent: Wednesday, September 05, 2012 1:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEC12, and previous generations, why? type question - GPU 
computing.
 On 9/5/2012 at 12:45 PM, McKown, John john.mck...@healthmarkets.com 
 wrote:
 I guess that I should preface this with another question. Does anybody 
 use a z for heavy numeric computation anymore? Or has that all gone to 
 Intel and Power boxes? Why is that? If it is because the z architecture is 
 not good
 at numeric computation, I have a question.
As has been pointed out in another thread here, the dollar cost per 
instruction is much higher on System z than other architectures.  So for 
purely computational workloads, although System z may have a faster CPU than 
the other architectures, it costs more for the same amount of computation.  A 
lot of high performance computing is restartable in that if a computation 
node fails, starting that piece of work over from the beginning isn't hard.  
Most of the qualities that are built into System z aren't needed for that 
type of work, so no need to spend the big bucks for it.
Mark Post

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Auditors Don't Know Squat!

2012-08-02 Thread Conlin, Pete
Hi Greg,

Invite the auditor to approve a presentation at a professional conference to 
show the steps and consequences of such a policy.   

Should this be a problem, assign the auditors full responsibility for problems 
due to PE'd PTFs that would otherwise have been caught using your current 
maintenance scheme (the 30-day requirement problems verified/tracked by the PE 
date), then full speed ahead.  SMP/E provides us a very good audit trail.

There are also those poor folks who use the system.  There will probably be 
substantially increased downtime, sysprog/dba/app/qa (perhaps even 
audit/security) time for all action+ items in a 30 day cycle versus your 
current scheme.  The 2 metrics of increased downtime  personnel costs could be 
evaluated 

Application level risk, simply due to change, is another (albeit intertwined) 
metric, but receives little coverage, save for the disastrous examples, such as 
the recent BoS fiasco). 

Good Luck,
Peter
P.S. Is this a rolling 30 days?  If so, the real period for installing service 
is less.  
/
Our auditors (Feds) say we need to apply all new PTF's within 30 days of 
availability. I'm speechless. Does anyone have the patience to form a cogent 
argument without laughing, crying, or tying one on?
/  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: Shopz

2012-07-03 Thread Conlin, Pete
I agree with your sentiments.  

Perhaps the five 9's availability is in a base other than 10?

Happy Independence Day (England-Magna Carta/Runnymede June 15, Canada July 1, 
U.S. July 4, Venezuela July 5) to all!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bobbie Justice
Sent: Tuesday, July 03, 2012 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Shopz

must be some more of that five 9's availability. 

SR is giving me An unexpected error has occurred when trying to update a pmr. 

I will however congratulate them on reducing their total number of pmrs, since 
no one wants to deal with this stupid SR system.  

Bobbie Jo Justice


On Tue, 3 Jul 2012 08:44:46 -0400, Knutson, Sam sknut...@geico.com wrote:

SR is throwing HTTP 500 Internal Server Error this morning trying to open new 
PMR's though.
Gives you that talk to the hand feeling.  It's not worth the time to deal 
with phone support for a SEV3 PMR better to wait and retry later it may work 
better.

Best Regards,

Sam Knutson, GEICO 
System z Team Leader 
mailto:sknut...@geico.com (office)  
301.986.3574 (cell) 301.996.1318  

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN