A 64 way z10. Don't laugh. That may seriously be under consideration -
as soon as someone solves the problems encountered by TPF when
attempting to use more that 12 (or 16 or whatever the current number is
- there is a definite point of diminishing return) engines. Sixty four
may not even be enough. And storage measured by the TB may not be too
far away, either.
 
As far as using z/VM, our need to do performance testing of changes to
the TPF environment somewhat limits that as a solution. We need LPARs
for that. We do use z/VM quite heavily, as I am sure you know.  Maybe
that 64-way z10 is a good fit, too. After all, we will get one for VM
before it goes into production on one of the TPF systems.
 

Regards, 
Richard Schuh 

 

 


________________________________

        From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter
        Sent: Tuesday, August 05, 2008 12:55 PM
        To: IBMVM@LISTSERV.UARK.EDU
        Subject: Re: Some IBM Announcements for z/OS, z/VM, z/VSE (Aug
5, 2008)
        
        

        To add to Mark's comment, as well as others: your need
(certainly a valid one) is more encompassing than most sites.  Alan
already said that when polled, to paraphrase) customers did not want to
wait for a whole loaf, needing sooner a half loaf.  The long term need
for the other half, allowing customers to slice their own bread, *may*
(no inside knowledge on my part) still be on the table. 
        
        That said, if you need to move memory around between systems,
there's this thingy called z/VM which has been doing it for years
without bringing the whole system down to do it.  It shares its toys and
plays well with others.  But then, you already knew that.  Your business
need may not permit you to move everything into the same CEC.  Wanna buy
a 64-way z10?  ;-) 
        

        Mike Walter 
        Hewitt Associates 
        Any opinions expressed herein are mine alone and do not
necessarily represent the opinions or policies of Hewitt Associates. 
        
        
        
"Mark Post" <[EMAIL PROTECTED]> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 

08/05/2008 02:28 PM 
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU 
cc
Subject
Re: Some IBM Announcements for z/OS, z/VM, z/VSE (Aug 5, 2008)

        




        >>> On 8/5/2008 at  2:53 PM, in message
        <[EMAIL PROTECTED]>,
"Schuh,
        Richard" <[EMAIL PROTECTED]> wrote: 
        -snip-
        > Thus the ferrous solution
        > because there is no way to borrow memory and give it back
without
        > disruption. 
        
        Which is the whole point.  This capability isn't about borrowing
memory and giving it back.  It was never intended for that, nor
portrayed as that.  It is simply the ability to buy more hardware, and
add it to z/VM without a disruption.  Period, end of story.  This can be
done today, with z/VM 5.4.  At some point in the future, it _may_ become
possible to go the other way.  Looking at the industry as a whole, I see
far less value in being able to do that than simply being able to add
real storage.  (Oh, and by the way, this is for real storage only, not
expanded storage.)  Not too many people are looking to remove real
storage.  So, holding up this very valuable feature until the far less
valuable feature could be done, was soundly rejected by just about
everyone that was asked, me included.
        
        
        Mark Post
        
        
        

        
        
________________________________

        
        
        The information contained in this e-mail and any accompanying
documents may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient of this
message, or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this
message, including any attachments. Any dissemination, distribution or
other use of the contents of this message by anyone other than the
intended recipient is strictly prohibited. All messages sent to and from
this e-mail address may be monitored as permitted by applicable law and
regulations to ensure compliance with our internal policies and to
protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you
communicate with us by e-mail. 
        

        

Reply via email to