Re: X86 server

[McKown, John]

Yes, it would. And apparently there is something in z/OS which is similar, but 
not as complete.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Monday, August 27, 2012 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> On Aug 27, 2012, at 07:03, McKown, John wrote:
> >
> > ... Oh, there is also "icron" to schedule background tasks based on
> creation, update, or deletion of files. At least on Linux. I don't know
> if other systems have the "inotify" interface.
> >
> Would this solve the "file monitor" requirement currently
> discussed on MVS-OE.  But z/OS likely lacks the interface.
> 
> -- gil
> 
> --
> 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

Re: X86 server

[Paul Gilmartin]

On Aug 27, 2012, at 07:03, McKown, John wrote:
>  
> ... Oh, there is also "icron" to schedule background tasks based on creation, 
> update, or deletion of files. At least on Linux. I don't know if other 
> systems have the "inotify" interface.
>  
Would this solve the "file monitor" requirement currently
discussed on MVS-OE.  But z/OS likely lacks the interface.

-- gil

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

Re: X86 server

[Anne & Lynn Wheeler]

john.mck...@healthmarkets.com (McKown, John) writes:
> CA-7 has a similar function to run "cross platform" work. It requires
> a "daemon" be running on the remote side. I like
> Co:Z Launcher from Dovetailed Technologies to do this. It only
> requires a standard SSH server on the remote end. And I can afford it
> (it is zero cost.) 

part of the issue is the MVS evolved from a paradigm where people
submitted card decks and the actual execution occured at much later
period ... with at most an operator present ... the responsible person
was no where around. the unix & desktop platforms evolved from the exact
opposite paradigm ... the computer was directly interacting with the
person executing the application. those platforms have had to do quite a
bit of evolution to handle server&unattended operation.

however, there has some interesting evolution on their server side
... the megadatacenters with hundreds of thousands of blades (and
millions of processors) with provisioning for on-demand use is quite
remarkable ... I doubt if anybody is claiming current mainframe
operating systems are prepared to run several hundred thousand blades in
a megadatacenter ... including allowing an entity to do on-demand,
dynamically provision 17,000 cores for 240TFLOPs (for a "batch"
supercomputer) @ $1,2479/hr. recent posts mentioning somebody doing just
that with Amazon cloud:
http://www.garlic.com/~lynn/2012.html#78 Has anyone successfully migrated off 
mainframes?
http://www.garlic.com/~lynn/2012.html#80 Article on IBM's z196 Mainframe 
Architecture
http://www.garlic.com/~lynn/2012.html#82 Has anyone successfully migrated off 
mainframes?
http://www.garlic.com/~lynn/2012b.html#28 New IBM mainframe instructions
http://www.garlic.com/~lynn/2012b.html#30 New IBM mainframe instructions

for one thing, a single mega-datacenter is estimated to be more
processing power than the aggregate of all mainframes in the world
today.

This article from last year
http://news.cnet.com/8301-13846_3-57349321-62/amazon-takes-supercomputing-to-the-cloud/

The dynamic, on-demand amazon cloud "supercomputer" is compared to the
Fujitsu K Computer ... that operates at 10 petaflops (10,000tflops), has
864 racks, 88,128 interconnected processors and estimated total
provisioned cost of $20M (less than maxed out 80 processor z196 @ $28M,
rated at 50BIPS); $23,148/rack, $227/processor, $2000/TFLOP, $2/BFLOP,
113BFLOP/processor, 11,576TFLOP/rack ... 102processors/rack

By comparison, 80 processor z196 @28M and 50BIPS works out to
$350,000/processor, $560,000/BIPS, and 624MIPS/processor.

more recent article about on-demand, dynamic, amazon supercomputer
http://arstechnica.com/business/2012/04/4829-per-hour-supercomputer-built-on-amazon-cloud-to-fuel-cancer-research/

from above:

It ran for three hours on the night of March 30, at a cost of $4,828.85
per hour. Getting up to 51,132 cores required spinning up 6,742 Amazon
EC2 instances running CentOS Linux. This virtual supercomputer spanned
the globe, tapping data centers in four continents and every available
Amazon region, from Tokyo, Singapore, and Sao Paolo, to Ireland,
Virginia, Oregon, and California. As impressive as it sounds, such a
cluster can be spun up by anyone with the proper expertise, without
talking to a single employee of Amazon.

... snip ...

Not sure what an EC2 instance is made of for this (&/or if they are all
the same), an e5-2600 would have 16 cores and 6742 instances would be
aggregate of 107,872 cores (aka processors).

past posts in thread:
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server
http://www.garlic.com/~lynn/2012l.html#19 X86 server
http://www.garlic.com/~lynn/2012l.html#20 X86 server
http://www.garlic.com/~lynn/2012l.html#25 X86 server
http://www.garlic.com/~lynn/2012l.html#28 X86 server
http://www.garlic.com/~lynn/2012l.html#29 X86 server
http://www.garlic.com/~lynn/2012l.html#30 X86 server
http://www.garlic.com/~lynn/2012l.html#31 X86 server

--
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Paul Gilmartin]

Batch on other systems:

(can Darren or someone please report to L-SOFT problems
replying via the web interface to plies such as Rex's
that have:
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"
They can be read clearly.  When replying, quoted text
appears as unrendered base64.

I'd do it myself, but IIRC, L-Soft requires customer ID.
Thanks.)

On Aug 27, 2012, at 07:18, Pommier, Rex R. wrote:
> 
>  ...  Unless you specifically "background" a task, when you run a script it 
> ties up your terminal session, whether it be for a transaction or a task that 
> updates millions of rows in a database. ...
>  
But the *NIXen let the programmer "background" a process
with a single keystroke and later to wait for its completion
and sense its exit status; something extraordinarily (PoV)
difficult in TSO.

command-name &  # "&" indicates background
PID=$!  # Save process-ID; repeat if desired
... # do whatever you want in meantime
wait $PID   # Wait for completion
echo "command-name completed with status $?"

What would be necessary to do this with CLIST or Rexx
with e.g. IEFBR14 as command-name?  Please enumerate any
additional files (JCL) or nonstandard (ISV, CBBTAPE)
commands that would be needed.

And the command language for *NIX batch is identical to
the foreground scripting language; newcomers may devote
that part of their learning resouce to more productive
areas.

-- gil

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

Re: X86 server

[Kirk Wolf]

For those interested in cross-platform batch (which we refer to as "z/OS
Hybrid Batch"), you may be interested in the following case studies:

"z/OS Hybrid Batch Processing: Generating a multi-page PDF document with
Co:Z"
http://dovetail.com/products/casestudyitext.html

"z/OS Hybrid Batch Processing: Running SAS Programs with Co:Z"
http://dovetail.com/products/casestudysas.html

(Sample JCL and programs are freely available.)

We recently announced the "Co:Z Load Balancer", which allows you to
distribute z/OS Hybrid Batch jobs to a pool of zBX blade servers, based on
workload information provided by zURM.
http://dovetail.com/products/loadbalancer.html

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

The Co:Z Toolkit is free to use; license and support agreements are also
available.
http://dovetail.com/support.html

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

Re: X86 server

[McKown, John]

CA-7 has a similar function to run "cross platform" work. It requires a 
"daemon" be running on the remote side. I like Co:Z 
Launcher from Dovetailed Technologies to do this. It only requires a standard 
SSH server on the remote end. And I can afford it (it is zero cost.) 

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Pommier, Rex R.
> Sent: Monday, August 27, 2012 8:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> As far as "no batch" on non-mainframe platforms, I agree with you that
> it is pretty much a matter of verbiage and available toolset.  Having
> worked with both AIX and HP-UX over the past 10 years, they don't have
> the initiator concept.  As coming out of the box, *NIX systems simply
> throw work at the box until it is buried.  Unless you specifically
> "background" a task, when you run a script it ties up your terminal
> session, whether it be for a transaction or a task that updates
> millions of rows in a database.  That is why many of the software
> product vendors have their own schedulers built in.  In addition, some
> of the scheduler vendors run just fine in *NIX/Windows.  BMC's Control-
> M (I'm not endorsing it, just saying it has this capability) can run
> schedules across the environment, with a job on the mainframe
> triggering a  job on another platform, then pass control back to a
> mainframe job once the work is done on the other platform.
> 
> Rex
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of McKown, John
> Sent: Monday, August 27, 2012 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> The confusion about "no batch" may be because of a lack of something
> akin to the "initiator" and SPOOL. Well, I guess the output part of the
> "SPOOL" concept could be something like the files in /var/spool/lpq (in
> my Linux) subdirectory. I'm not really UNIX literate about AIX,
> Solaris, HP-UX, et al. On most Linux distros, there is definitely no
> "initiator". There is "crontab" and "at" to schedule background tasks.
> The only "job scheduling" software that I've ever heard of is "The
> Portable Batch System"
> http://en.wikipedia.org/wiki/Portable_Batch_System
> I have no idea how this compares to something like CA-7 or Tivoli. Oh,
> there is also "icron" to schedule background tasks based on creation,
> update, or deletion of files. At least on Linux. I don't know if other
> systems have the "inotify" interface.
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets®
> 
> 9151 Boulevard 26 • N. Richland Hills • TX 76010
> (817) 255-3225 phone •
> john.mck...@healthmarkets.com • www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or
> proprietary information. If you are not the intended recipient, please
> contact the sender by reply e-mail and destroy all copies of the
> original message. HealthMarkets® is the brand name for products
> underwritten and issued by the insurance subsidiaries of HealthMarkets,
> Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life
> Insurance Company of TennesseeSM and The MEGA Life and Health Insurance
> Company.SM
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Mark van der Eynden
> > Sent: Sunday, August 26, 2012 11:46 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: X86 server
> >
> > > The elimination of batch which seems to be feasible on non-
> mainframe
> > > architectures alone is a killer.
> >
> > There is no elimination of batch, anywhere.
> >
> > It might go by another name, it might be 'hidden', but

Re: X86 server

[Pommier, Rex R.]

As far as "no batch" on non-mainframe platforms, I agree with you that it is 
pretty much a matter of verbiage and available toolset.  Having worked with 
both AIX and HP-UX over the past 10 years, they don't have the initiator 
concept.  As coming out of the box, *NIX systems simply throw work at the box 
until it is buried.  Unless you specifically "background" a task, when you run 
a script it ties up your terminal session, whether it be for a transaction or a 
task that updates millions of rows in a database.  That is why many of the 
software product vendors have their own schedulers built in.  In addition, some 
of the scheduler vendors run just fine in *NIX/Windows.  BMC's Control-M (I'm 
not endorsing it, just saying it has this capability) can run schedules across 
the environment, with a job on the mainframe triggering a  job on another 
platform, then pass control back to a mainframe job once the work is done on 
the other platform.

Rex


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McKown, John
Sent: Monday, August 27, 2012 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

The confusion about "no batch" may be because of a lack of something akin to 
the "initiator" and SPOOL. Well, I guess the output part of the "SPOOL" concept 
could be something like the files in /var/spool/lpq (in my Linux) subdirectory. 
I'm not really UNIX literate about AIX, Solaris, HP-UX, et al. On most Linux 
distros, there is definitely no "initiator". There is "crontab" and "at" to 
schedule background tasks. The only "job scheduling" software that I've ever 
heard of is "The Portable Batch System"
http://en.wikipedia.org/wiki/Portable_Batch_System
I have no idea how this compares to something like CA-7 or Tivoli. Oh, there is 
also "icron" to schedule background tasks based on creation, update, or 
deletion of files. At least on Linux. I don't know if other systems have the 
"inotify" interface.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark van der Eynden
> Sent: Sunday, August 26, 2012 11:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
>
> > The elimination of batch which seems to be feasible on non-mainframe
> > architectures alone is a killer.
>
> There is no elimination of batch, anywhere.
>
> It might go by another name, it might be 'hidden', but there's always
> batch.
>
> Remember to remind the auditors of that next time they come around
> asking batch scheduling questions.
>
> A lot of the 'other platform' people say 'there is no batch' because
> they know what a can of worms it is, or maybe they just do not equate
> 'scheduled tasks' as batch.
>
> One of the nearby SAP experts, with mainframe experience (this SAP is
> running on Unix), says SAP Batch is 'simply' a number of 'initiators'
> that run the next batch entry, there is no prioritization, no classes,
> every thing just runs, causing all the imagined potential havoc. If
> the 'initiators' get 'clogged up' SAP will die within a few hours as
> batch is critical to its overall health.
>
> --
> 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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictl

Re: X86 server

[McKown, John]

The confusion about "no batch" may be because of a lack of something akin to 
the "initiator" and SPOOL. Well, I guess the output part of the "SPOOL" concept 
could be something like the files in /var/spool/lpq (in my Linux) subdirectory. 
I'm not really UNIX literate about AIX, Solaris, HP-UX, et al. On most Linux 
distros, there is definitely no "initiator". There is "crontab" and "at" to 
schedule background tasks. The only "job scheduling" software that I've ever 
heard of is "The Portable Batch System"
http://en.wikipedia.org/wiki/Portable_Batch_System
I have no idea how this compares to something like CA-7 or Tivoli. Oh, there is 
also "icron" to schedule background tasks based on creation, update, or 
deletion of files. At least on Linux. I don't know if other systems have the 
"inotify" interface.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark van der Eynden
> Sent: Sunday, August 26, 2012 11:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> > The elimination of batch which seems
> > to be feasible on non-mainframe architectures alone is a killer.
> 
> There is no elimination of batch, anywhere.
> 
> It might go by another name, it might be 'hidden', but there's always
> batch.
> 
> Remember to remind the auditors of that next time they come around
> asking batch scheduling questions.
> 
> A lot of the 'other platform' people say 'there is no batch' because
> they know what a can of worms it is, or maybe they just do not equate
> 'scheduled tasks' as batch.
> 
> One of the nearby SAP experts, with mainframe experience (this SAP is
> running on Unix), says SAP Batch is 'simply' a number of 'initiators'
> that run the next batch entry, there is no prioritization, no classes,
> every thing just runs, causing all the imagined potential havoc. If the
> 'initiators' get 'clogged up' SAP will die within a few hours as batch
> is critical to its overall health.
> 
> --
> 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

Re: X86 server

[Mark van der Eynden]

> The elimination of batch which seems
> to be feasible on non-mainframe architectures alone is a killer. 

There is no elimination of batch, anywhere.

It might go by another name, it might be 'hidden', but there's always batch.

Remember to remind the auditors of that next time they come around asking batch 
scheduling questions.

A lot of the 'other platform' people say 'there is no batch' because they know 
what a can of worms it is, or maybe they just do not equate 'scheduled tasks' 
as batch.

One of the nearby SAP experts, with mainframe experience (this SAP is running 
on Unix), says SAP Batch is 'simply' a number of 'initiators' that run the next 
batch entry, there is no prioritization, no classes, every thing just runs, 
causing all the imagined potential havoc. If the 'initiators' get 'clogged up' 
SAP will die within a few hours as batch is critical to its overall health.

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

Re: X86 server

[Clark Morris]

On 26 Aug 2012 14:00:54 -0700, in bit.listserv.ibm-main zman wrote:

>Good lord! Can you PLEASE try to post *vaguely* relevant material? This
>makes you look like a troll.

Looking at this material (in the three postings from Lynn) which I
consider highly relevant, I am wondering about the long term viability
of mainframe style processing.  The elimination of batch which seems
to be feasible on non-mainframe architectures alone is a killer.  The
raw performance differences for computing are such that emulation of
the z instruction set on Intel seems cost effective.  The incentives
to move to Java and other platform independent architectures by
charging more for COBOL MIPS will just aggravate the trend. Once an
organization has decided to go with SAP, is there any reason for it to
try running SAP on z/OS? on z/Linux?  

I would be interested in any comparisons of the blade i-o architecture
with that of the z series.

I also note the bean counters refusal to sanction implementing FBA in
MVS because of a 26 million dollar cost probably has resulted in an
ongoing cost in the hundreds of millions of dollars.

Clark Morris  
>
>On Sun, Aug 26, 2012 at 3:46 PM, Anne & Lynn Wheeler wrote:
>
>> scott_j_f...@yahoo.com (Scott Ford) writes:
>> > I saw the same exercise in a pharm. company trying to go from MVS,
>> > multiple Lpars to unix.  Several millions of $$$ and it was a
>> > bustsome applications were difficult to convert
>>
>> in the 90s, one of the biggest efforts was by the financial industry
>> (large concentration in manhatten) to move from overnight batch window
>> to straight-through process ... using large numbers of "killer micros"
>> ... where several billions were dumped down the drain. These efforts
>> contributed to the "mainframe is dead" stories from the period.
>>
>> "real-time" transactions had been added to traditional batch ... but the
>> actual processing was still being down in the overnight batch window.
>> With globalization, there was combination of more work as well as
>> decreasing window size ... that was putting enormous pressure on the
>> paradigm.
>>
>> billions were spent on parallized implementation using large numbers
>> "killer micros" implementing "straight-through" processing
>> ... eliminated most of the work in the overnight batch window. They used
>> some parallelization technology with roll-your-own implementations that
>> looked good in the toy demos. However, they failed to so the
>> speeds&feeds and when it came to production rollout ... the whole thing
>> imploded horribly. The parallelization technology being used introduced
>> an increase in overhead of 100 times (compared to cobol batch)
>> ... totally swamping any anticipated throughput increase from large
>> number of "killer micros"
>>
>> I had done some simple speeds&feeds and pointed out the issue before
>> deployments but was ignored. I also got to work on improving performance
>> of cobol batch that ran everynight batch window on more than 40 maxed
>> out mainframes (40+ needed to handle workload, datacenter took pride in
>> saying no mainframe was older than 18months).
>>
>> At least by the last half of the last decade, most of the major
>> non-mainframe RDBMS vendors (including IBM) had made significant strides
>> in non-mainframe RDBMS cluster-scaleup. I participated in demonstration
>> of straight-through processing implementations that involved translating
>> operations into fine-grain SQL operations that would could be easily
>> parallelized by latest generation of non-mainframe RDBMS cluster
>> implementations (more like factor of 3-5 times compared to cobol batch
>> rather than 100 times). The financial industry standards organizations
>> were interested but there were lots of comments there was still enormous
>> resistance and risk aversion because of the lingering effects of the 90s
>> disastrous failures.
>>
>> these large financial institutions continue to be major mainframe
>> customer market.
>>
>> --
>> virtualization experience starting Jan1968, online at home since Mar1970
>>
>> --
>> 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

Re: X86 server

[zMan]

Good lord! Can you PLEASE try to post *vaguely* relevant material? This
makes you look like a troll.

On Sun, Aug 26, 2012 at 3:46 PM, Anne & Lynn Wheeler wrote:

> scott_j_f...@yahoo.com (Scott Ford) writes:
> > I saw the same exercise in a pharm. company trying to go from MVS,
> > multiple Lpars to unix.  Several millions of $$$ and it was a
> > bustsome applications were difficult to convert
>
> in the 90s, one of the biggest efforts was by the financial industry
> (large concentration in manhatten) to move from overnight batch window
> to straight-through process ... using large numbers of "killer micros"
> ... where several billions were dumped down the drain. These efforts
> contributed to the "mainframe is dead" stories from the period.
>
> "real-time" transactions had been added to traditional batch ... but the
> actual processing was still being down in the overnight batch window.
> With globalization, there was combination of more work as well as
> decreasing window size ... that was putting enormous pressure on the
> paradigm.
>
> billions were spent on parallized implementation using large numbers
> "killer micros" implementing "straight-through" processing
> ... eliminated most of the work in the overnight batch window. They used
> some parallelization technology with roll-your-own implementations that
> looked good in the toy demos. However, they failed to so the
> speeds&feeds and when it came to production rollout ... the whole thing
> imploded horribly. The parallelization technology being used introduced
> an increase in overhead of 100 times (compared to cobol batch)
> ... totally swamping any anticipated throughput increase from large
> number of "killer micros"
>
> I had done some simple speeds&feeds and pointed out the issue before
> deployments but was ignored. I also got to work on improving performance
> of cobol batch that ran everynight batch window on more than 40 maxed
> out mainframes (40+ needed to handle workload, datacenter took pride in
> saying no mainframe was older than 18months).
>
> At least by the last half of the last decade, most of the major
> non-mainframe RDBMS vendors (including IBM) had made significant strides
> in non-mainframe RDBMS cluster-scaleup. I participated in demonstration
> of straight-through processing implementations that involved translating
> operations into fine-grain SQL operations that would could be easily
> parallelized by latest generation of non-mainframe RDBMS cluster
> implementations (more like factor of 3-5 times compared to cobol batch
> rather than 100 times). The financial industry standards organizations
> were interested but there were lots of comments there was still enormous
> resistance and risk aversion because of the lingering effects of the 90s
> disastrous failures.
>
> these large financial institutions continue to be major mainframe
> customer market.
>
> --
> virtualization experience starting Jan1968, online at home since Mar1970
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: X86 server

[Anne & Lynn Wheeler]

scott_j_f...@yahoo.com (Scott Ford) writes:
> I saw the same exercise in a pharm. company trying to go from MVS,
> multiple Lpars to unix.  Several millions of $$$ and it was a
> bustsome applications were difficult to convert

in the 90s, one of the biggest efforts was by the financial industry
(large concentration in manhatten) to move from overnight batch window
to straight-through process ... using large numbers of "killer micros"
... where several billions were dumped down the drain. These efforts
contributed to the "mainframe is dead" stories from the period.

"real-time" transactions had been added to traditional batch ... but the
actual processing was still being down in the overnight batch window.
With globalization, there was combination of more work as well as
decreasing window size ... that was putting enormous pressure on the
paradigm.

billions were spent on parallized implementation using large numbers
"killer micros" implementing "straight-through" processing
... eliminated most of the work in the overnight batch window. They used
some parallelization technology with roll-your-own implementations that
looked good in the toy demos. However, they failed to so the
speeds&feeds and when it came to production rollout ... the whole thing
imploded horribly. The parallelization technology being used introduced
an increase in overhead of 100 times (compared to cobol batch)
... totally swamping any anticipated throughput increase from large
number of "killer micros" 

I had done some simple speeds&feeds and pointed out the issue before
deployments but was ignored. I also got to work on improving performance
of cobol batch that ran everynight batch window on more than 40 maxed
out mainframes (40+ needed to handle workload, datacenter took pride in
saying no mainframe was older than 18months).

At least by the last half of the last decade, most of the major
non-mainframe RDBMS vendors (including IBM) had made significant strides
in non-mainframe RDBMS cluster-scaleup. I participated in demonstration
of straight-through processing implementations that involved translating
operations into fine-grain SQL operations that would could be easily
parallelized by latest generation of non-mainframe RDBMS cluster
implementations (more like factor of 3-5 times compared to cobol batch
rather than 100 times). The financial industry standards organizations
were interested but there were lots of comments there was still enormous
resistance and risk aversion because of the lingering effects of the 90s
disastrous failures.

these large financial institutions continue to be major mainframe
customer market.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Anne & Lynn Wheeler]

cfmpub...@ns.sympatico.ca (Clark Morris) writes:
> Are there any benchmarks available comparing a z series against a
> blade configuration doing the same work and comparing the cost per
> benchmark unit?  Given the complexity of instruction sets for both
> Intel and the z series and the different nature of them, I agree with
> others that straight instruction speed comparisons may be meaningless.
> For example how much of the work for an i-o is done by the main
> processor on a blade versus on the z series?  What is the MP effect on
> the blades versus the z series?

re:
http://www.garlic.com/~lynn/2012l.html#28 X86 server
http://www.garlic.com/~lynn/2012l.html#29 X86 server

both refer to TPC benchmarks ... which have benchmarks that are RDBMS
transaction oriented with heavy disk i/o (as mentioned looking
at number of transactions/thruput, cost of transactions/thruput, and
power consumption of transactions/thruput)

Note that the e5-2600 blade is two socket-chip multiprocessor ... eight
cores (or processors) per chip for total of 16 processors (simulating 32
processor with hyperthreading) ... benchmark at 527BIPS (compared to
50BIPS for 80processor z196). e5-4600 blade are out there (four
sockets-chip multiprocessor, aggregate 32 processors, simulating 64
processors with hyperthreading) ... but having seen the dhrystone/bips
benchmarks ... but expecting over 1TIP for e5-4600. This post mentions
that mainframe sales of $5B last years translates into 180 $28m
max. configured z196 ... which at 50BIPS represents aggregate of 9TIPS.
http://www.garlic.com/~lynn/2012l.html#20 X86 server

this has some e5-4600 benchmarks
http://www.intel.com/content/www/us/en/benchmarks/server/xeon-e5-4600.html

this has SPEC benchmarks for 64chip, 512 core-processor (no hyperthread)
http://www.sgi.com/company_info/newsroom/press_releases/2012/may/intel.html

Another part of the issue is that mainframe CKD disks haven't been
manufactured for decades ... CKD being an extra layer of simulation
(delay and overhead) on top of the same disks all the other platforms
are using.

these recent posts reference the appearance of Harrier (morphs into SSA)
and fiber-channel (mainframe ficon is built on fibre channel standard)
in the late 80s and early 90s that were packetized serial technology
(other variations on serial i/o technology would come along later).
http://www.garlic.com/~lynn/2012i.html#47 IBM, Lawrence Livermore aim to meld 
supercomputing, industries
http://www.garlic.com/~lynn/2012i.html#54 IBM, Lawrence Livermore aim to meld 
supercomputing, industries
http://www.garlic.com/~lynn/2012i.html#95 Can anybody give me a clear idea 
about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#13 Can anybody give me a clear idea 
about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012k.html#69 ESCON
http://www.garlic.com/~lynn/2012k.html#77 ESCON
http://www.garlic.com/~lynn/2012k.html#80 360/20, was 1132 printer history

a growing bottleneck for mainframe was the half-duplex channel
architecture requiring synchronized end-to-end operation on every
channel command and data transfer. the serialized i/o architecture that
started to appear in the late 80s had dedicated outbound and inbound
serial i/o data paths. The equivalent of a channel program was packaged
as data and transmitted down the outbound channel. This would be
followed by data-being written (on the same outbound channel as well as
other packetized channel programs) and asynchronously with data being
read flowing on the (dedicated) inbound channel.

Harrier was dual serial copper (out of Hursley from early 90s) ... that
packetized SCSI commands and operated at 80mbits/sec concurrent in both
directions. I mention here that I tried to evolved Harrier into
interoperate with fibre-channel ... old post discussing meeting in
Ellison's conference room early Jan1992
http://www.garlic.com/~lynn/95.html#13

However, instead it involved into proprietary SSA operating at
160mits/sec concurrent in both directions, fibre channel wiki
http://en.wikipedia.org/wiki/Fibre_Channel

from above:

When Fibre Channel started to compete for the mass storage market its
primary competitor was IBM's proprietary Serial Storage Architecture
(SSA) interface. Eventually the market chose Fibre Channel over SSA,
depriving IBM of control over the next generation of mid- to high-end
storage technology.

... snip ...

There were lots of discussion on the fibre channel standards mailing
list about pok/mainframe channel engineers trying to do unnatural acts
layering ficon ontop of the base fibre channel standard

The current fibre channel standard web site:
http://www.fibrechannel.org/

fiber channel standard wiki page ... lists earliest standard from 1994
http://en.wikipedia.org/wiki/List_of_Fibre_Channel_standards

I had been working off&on with LLNL on a number of things ... fibre
channel standard work comes from 1988 time-frame with LLNL looking to
standardized a serial technolog

Re: X86 server

[Anne & Lynn Wheeler]

shmuel+...@patriot.net (Shmuel Metz  , Seymour J.) writes:
> Only if you're talking about the same instruction mix. When one system
> has instructions like MVCL and the other doesn't, MIPS truly means
> "meaningless indication of processor speed". A comparison of FLOPS
> ratings might be more meaningful, since the spread between the slowest
> and the fastest operation isn't as large.

note that x86 BIPS ratings are number of iterations executing dhrystone
benchmark compared to vax 780 assumed to be 1mip ... have no idea *real*
instruction execution rate. past discussion in this thread
http://www.garlic.com/~lynn/2012d.html#41 Layer 8: NASA unplugs last mainframe

above also mentions i7-3960x is single socket/chip with approx. four
times the BIPS rating of 80processor z196

max. configured 64processor z10 was claimed to be 30BIPS ... and that
increased by 2/3rds to 50BIPS for 80processor z196.

increase in processors from 64 to 80 can account for increase of 25%.
tech articles claim the introduction of out-of-order execution for z196
accounts for another 20-25%. other misc. would then account for the
remainder of the increase.

note that out-of-order execution, branch prediction, speculative
execution, etc have all been part of risc technology for decades.  the
recent generations of i86 processors have negated much of the risc
performance advantage by moving to risc processors with hardware layer
that translates i86 instructions to risc micro-ops.

part of the issue is that cache miss delays (aka access to memory)
counted in processor cycles are now compareable to 360-era disk access
delays. multiprogramming/multitasking was introduced to give processors
something to do while waiting for disk access. out-of-order execution
and hyperthreading are comparable for modern technologies (keeping the
processor units busy while waiting for stalled instruction access to
memory).

370/195 allowed out-of-order execution with pipeline ... but stalled at
conditional branch (having to wait to determine execution path that
branch would take). normal codes ran about half peak rate on 370/195
(because of branch stalls) and there was proposal to do simulated
multiprocessor (similar to modern hyperthread); two instruction streams,
pair of PSWs, two sets of registers ... etc. ... trying to maintain to
keep 370/195 running at peak processing rate.

modern branch prediction and speculative execution ... will do
out-of-order execution along one path (before branch condition is
determined). If the branch prediction is wrong, the incorrectly executed
instructions are undone ... and processing resumes along the correct
path.

recent post in this thread:
http://www.garlic.com/~lynn/2012l.html#28 X86 server

there was reference to older mainframe TPC benchmark ... there was some
published work for z10 which was then prorated by 50/30 to give estimate
for z196 ... as a means of making other thruput comparisons.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Clark Morris]

On 26 Aug 2012 07:59:31 -0700, in bit.listserv.ibm-main you wrote:

>paulgboul...@aim.com (Paul Gilmartin) writes:
>> What's impressive here is that they don't buy off-the-shelf hardware
>> systems; they design their own.
>
>at hundreds of thousands blades in a megadatacenter and multiple
>megadatacenters spread around the world ... they claim that they can
>build their own for 1/3rd the price of brand name blades. they also have
>done quite a bit of research into reliability of different commodity
>components and buy in quantity for total cost of ownship. They also tend
>to have some leverage over vendors that sell into the megadatacenter
>server market.
>
>with the enormous reduction in cost of hardware that they've been able
>to achieve (if IBM has base price of $1815 for e5-2600 blade or
>approx. $3.44/BIPS ... and megadatacenter may be able to achieve 1/3rd
>that ... compared to $560,000/BIPS for z196) ... other costs start to
>play an increasing role. The megadatacenters have also pioneered much of
>the green datacenter efforts ... radically reducing power and cooling
>costs ... establishing power&cooling cost measures per unit of computing
>... somewhat analogous to the TPC council ... total cost per transaction
>(gives results sorted by performance, price/performance and
>watts/performance). A few recent posts mentioning mainframes
>and TPC benchmarks:

Are there any benchmarks available comparing a z series against a
blade configuration doing the same work and comparing the cost per
benchmark unit?  Given the complexity of instruction sets for both
Intel and the z series and the different nature of them, I agree with
others that straight instruction speed comparisons may be meaningless.
For example how much of the work for an i-o is done by the main
processor on a blade versus on the z series?  What is the MP effect on
the blades versus the z series?

Clark Morris
>http://www.garlic.com/~lynn/2012.html#23 21st Century Migrates Mainframe with 
>Clerity
>http://www.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
>http://www.garlic.com/~lynn/2012i.html#16 Think You Know The Mainframe?
>http://www.garlic.com/~lynn/2012i.html#89 Can anybody give me a clear idea 
>about Cloud Computing in MAINFRAME ?
>http://www.garlic.com/~lynn/2012j.html#1 Can anybody give me a clear idea 
>about Cloud Computing in MAINFRAME ?
>
>One of the issues is they have done significant excess provisioning for
>"on-demand" requirements and so have pressured vendors for
>implementations that drastically cut power use when idle ... but able to
>instantaneously come up to full-speed.
>
>They've also openly published their findings ... hoping to encourage the
>component vendors to compete & improve their products. However, their
>findings have also tended to influence blade component selection and
>assembly by others.
>
>recent posts in this thread
>http://www.garlic.com/~lynn/2012l.html#16 X86 server
>http://www.garlic.com/~lynn/2012l.html#18 X86 server
>http://www.garlic.com/~lynn/2012l.html#19 X86 server
>http://www.garlic.com/~lynn/2012l.html#20 X86 server
>http://www.garlic.com/~lynn/2012l.html#25 X86 server

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

Re: X86 server

[Shmuel Metz (Seymour J.)]

In <2174580136452535.wa.paulgboulderaim@listserv.ua.edu>, on
08/24/2012
   at 10:31 PM, Paul Gilmartin  said:

>On Thu, 23 Aug 2012 22:13:49 -0400, Anne & Lynn Wheeler wrote: >
>> ...
>>max configured z196 with 80 processors is rated for 50BIPS and goes for
>>$28M (about $560,000/BIPS) ...
>> 
>>ibm has base price of $1815 for e5-2600 blade ... which have ratings at
>>527BIPS (about $3.44/BIPS), ...
>>
>A factor of 160,000. 

Only if you're talking about the same instruction mix. When one system
has instructions like MVCL and the other doesn't, MIPS truly means
"meaningless indication of processor speed". A comparison of FLOPS
ratings might be more meaningful, since the spread between the slowest
and the fastest operation isn't as large.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: X86 server

[Anne & Lynn Wheeler]

paulgboul...@aim.com (Paul Gilmartin) writes:
> What's impressive here is that they don't buy off-the-shelf hardware
> systems; they design their own.

at hundreds of thousands blades in a megadatacenter and multiple
megadatacenters spread around the world ... they claim that they can
build their own for 1/3rd the price of brand name blades. they also have
done quite a bit of research into reliability of different commodity
components and buy in quantity for total cost of ownship. They also tend
to have some leverage over vendors that sell into the megadatacenter
server market.

with the enormous reduction in cost of hardware that they've been able
to achieve (if IBM has base price of $1815 for e5-2600 blade or
approx. $3.44/BIPS ... and megadatacenter may be able to achieve 1/3rd
that ... compared to $560,000/BIPS for z196) ... other costs start to
play an increasing role. The megadatacenters have also pioneered much of
the green datacenter efforts ... radically reducing power and cooling
costs ... establishing power&cooling cost measures per unit of computing
... somewhat analogous to the TPC council ... total cost per transaction
(gives results sorted by performance, price/performance and
watts/performance). A few recent posts mentioning mainframes
and TPC benchmarks:
http://www.garlic.com/~lynn/2012.html#23 21st Century Migrates Mainframe with 
Clerity
http://www.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
http://www.garlic.com/~lynn/2012i.html#16 Think You Know The Mainframe?
http://www.garlic.com/~lynn/2012i.html#89 Can anybody give me a clear idea 
about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#1 Can anybody give me a clear idea about 
Cloud Computing in MAINFRAME ?

One of the issues is they have done significant excess provisioning for
"on-demand" requirements and so have pressured vendors for
implementations that drastically cut power use when idle ... but able to
instantaneously come up to full-speed.

They've also openly published their findings ... hoping to encourage the
component vendors to compete & improve their products. However, their
findings have also tended to influence blade component selection and
assembly by others.

recent posts in this thread
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server
http://www.garlic.com/~lynn/2012l.html#19 X86 server
http://www.garlic.com/~lynn/2012l.html#20 X86 server
http://www.garlic.com/~lynn/2012l.html#25 X86 server

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Paul Gilmartin]

On Thu, 23 Aug 2012 22:13:49 -0400, Anne & Lynn Wheeler wrote:
>
> ...
>max configured z196 with 80 processors is rated for 50BIPS and goes for
>$28M (about $560,000/BIPS) ...
> 
>ibm has base price of $1815 for e5-2600 blade ... which have ratings at
>527BIPS (about $3.44/BIPS), ...
>
A factor of 160,000.  The mind boggles.

-- gil

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

Re: X86 server

[zMan]

What does this have to do with this thread???

On Fri, Aug 24, 2012 at 4:13 PM, Anne & Lynn Wheeler wrote:

> scott_j_f...@yahoo.com (Scott Ford) writes:
> > Just for my 2 cents worth, ran P390s in one environment attached to two
> T1s.
> > Attached to them we're 3800 laser printers and some 3274s we couldnt
> replace.
> > The mainframes were an hour plus away in NJ, and our printed output
> queued up to the P390s.
> > Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel
> > i7', everything s good, but are also only doing development.
> >
> > Scott ford
> > www.identityforge.com
>
> re:
> http://www.garlic.com/~lynn/2012l.html#16 X86 server
> http://www.garlic.com/~lynn/2012l.html#18 X86 server
> http://www.garlic.com/~lynn/2012l.html#19 X86 server
> http://www.garlic.com/~lynn/2012l.html#20 X86 server
>
> 1980 STL is bursting at the seams and they are moving 300 people from
> IMS group to off-site bldg. the group tries remote 3270 support and find
> it intolerable. I get con'ed into writing HYPERChannel support for use
> as channel extender ... allowing them to put local channel-attached 3270
> controllers at the remote site. Runs over T1 channel on the *campus*
> collins digital radio T3 microwave. They don't notice any change from
> cms local 3270 controllers in STL (maintaining their subsecond response
> ... back when mvs/tso people were claiming noody needed subsecond
> response). System thruput actually improves ... issue is the
> HYPERChannel A220s sitting on real channel have significantly lower
> channel busy (for the same operation) than 3270 controllers ... total
> system throughput improves 10-15% (the 3270 controller channel busy is
> masked at the remote site).
>
> I try to get approval to release the software to customers ... which a
> group in POK manages to block. That group was playing with some fiber
> stuff (that eventually gets out as ESCON), and they are afraid if my
> HYPERChannel support is released to customers ... it would interfer with
> someday being able to get their fiber stuff out. As a result NSC has to
> re-do my implementation from scratch.
>
> Roll forward several years, the 3090 product administrator tracks me
> down.  the 3090 channels were designed to have 3-5 channel checks
> annually aggregate across the whole customer base. the industry service
> that collects erep data shows that there have been an aggregate of 20
> channel checks the first year.
>
> Turns out they are at customers running 3800 over HYERPChannel channel
> extender. In my original implementation ... if I had an unrecoverable
> transmission error ... I would simulate channel check in the CSW ... for
> the host software to go through its retry operation ... and the NSC
> faithfully reproduced that in their implementation. After some amount of
> toiling through error recovery code ... i determined that simulating
> IFCC would have effectively the same result as channel check and got NSC
> to update their implementation.
>
> as an aside, long ago and far away somebody in Boulder does build a
> hardware channel emulator for ibm/pc which is used for 3800 testing.
>
> --
> virtualization experience starting Jan1968, online at home since Mar1970
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: X86 server

[Anne & Lynn Wheeler]

scott_j_f...@yahoo.com (Scott Ford) writes:
> Just for my 2 cents worth, ran P390s in one environment attached to two T1s.
> Attached to them we're 3800 laser printers and some 3274s we couldnt replace.
> The mainframes were an hour plus away in NJ, and our printed output queued up 
> to the P390s.
> Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel
> i7', everything s good, but are also only doing development.
>
> Scott ford
> www.identityforge.com

re:
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server
http://www.garlic.com/~lynn/2012l.html#19 X86 server
http://www.garlic.com/~lynn/2012l.html#20 X86 server

1980 STL is bursting at the seams and they are moving 300 people from
IMS group to off-site bldg. the group tries remote 3270 support and find
it intolerable. I get con'ed into writing HYPERChannel support for use
as channel extender ... allowing them to put local channel-attached 3270
controllers at the remote site. Runs over T1 channel on the *campus*
collins digital radio T3 microwave. They don't notice any change from
cms local 3270 controllers in STL (maintaining their subsecond response
... back when mvs/tso people were claiming noody needed subsecond
response). System thruput actually improves ... issue is the
HYPERChannel A220s sitting on real channel have significantly lower
channel busy (for the same operation) than 3270 controllers ... total
system throughput improves 10-15% (the 3270 controller channel busy is
masked at the remote site).

I try to get approval to release the software to customers ... which a
group in POK manages to block. That group was playing with some fiber
stuff (that eventually gets out as ESCON), and they are afraid if my
HYPERChannel support is released to customers ... it would interfer with
someday being able to get their fiber stuff out. As a result NSC has to
re-do my implementation from scratch.

Roll forward several years, the 3090 product administrator tracks me
down.  the 3090 channels were designed to have 3-5 channel checks
annually aggregate across the whole customer base. the industry service
that collects erep data shows that there have been an aggregate of 20
channel checks the first year.

Turns out they are at customers running 3800 over HYERPChannel channel
extender. In my original implementation ... if I had an unrecoverable
transmission error ... I would simulate channel check in the CSW ... for
the host software to go through its retry operation ... and the NSC
faithfully reproduced that in their implementation. After some amount of
toiling through error recovery code ... i determined that simulating
IFCC would have effectively the same result as channel check and got NSC
to update their implementation.

as an aside, long ago and far away somebody in Boulder does build a
hardware channel emulator for ibm/pc which is used for 3800 testing.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Scott Ford]

Just for my 2 cents worth, ran P390s in one environment attached to two T1s.
Attached to them we're 3800 laser printers and some 3274s we couldnt replace.
The mainframes were an hour plus away in NJ, and our printed output queued up 
to the P390s.
Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel i7', 
everything s good, but are also only doing development.

Scott ford
www.identityforge.com

On Aug 23, 2012, at 12:11 PM, Anne & Lynn Wheeler  wrote:

> john.mck...@healthmarkets.com (McKown, John) writes:
>> X64 hardware, as much as it has improved, is still not as reliable or
>> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
>> once. A spare picked up the work, automatically restarting the
>> instruction stream, with no outage of any sort and no software
>> involvement. X86, from what I'm told, would at least require the OS to
>> do the equivalent of a checkpoint restart. Also had an OSA fail. The
>> other OSA did an ARP takeover and no IP sessions were lost. TCPIP was
>> informed, but all it did was put out a message and not start any new
>> sessions on the failing OSA. Our "open" people called me a liar when I
>> told them that.
> 
> big cloud operators do hundreds of thousands of blades in megadatacenter
> with lots of failure/recovery infrastructure to handle individual blade
> failures (usually with lots of power, telco, provisioning provisioning).
> 
> Gray had been studying mix of failures issues (both at IBM and later at
> Tandem) and by '84 published report that hardware failures had become
> minority of failure modes (hardware reliability had increased so other
> kinds of failures were starting to dominating). scan of '84 presentation
> http://www.garlic.com/~lynn/grayft84.pdf
> 
> several of the big cloud operators have published detailed studies of
> different component availability as part of building their own blades
> ... given optimal service life per dollar.
> 
> Cluster & take-over were increasingly being used to mask all kinds of
> outages ... even able to handle geographic operations and handling
> disasters taking out whole datacenter.
> 
> when we were doing ha/cmp ... we did a lot of failure mode study ... and
> part of our marketing was against hardware fault-tolerant systems.  We
> showed availability of ha/cmp clusters was higher than the
> fault-tolerant systems. In competitive situation involving 1-800 number
> server (i.e. maps 1-800 number to "real" number) ... it required
> five-nines availability. hardware fault-tolerant system still required
> scheduled system outage to do software upgrade ... which would blow
> several decades of downtime budget. With cluster operation, we showed at
> least as good hardware availability (with redundant systems) along with
> capability of doing rolling software upgrades with no system outage.
> 
> the hardware fault tolerant vendor eventually came back with suggestion
> that they could come out with redundant, cluster system operation ... to
> handle the software upgrade issue. However, given reliability of
> the underlying hardware operating in redundant, cluster system mode ...
> there was no longer any justification for hardware fault tolerance.
> 
> part of ha/cmp was ip-address take-over ... which according to all the
> standards should time-out mac/ip-address in arp caches. at the time,
> most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip
> stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup
> software. The ARP cache management was correctly timing out the ARP
> cache entries (so if there was ip-address take-over, it would discover
> the new MAC mapping). However, the BSD4.3 IP code had a performance
> optimization where it saved the last ip/mac lookup results ... which
> would only get reset if the client communicated with a different
> ip-address (otherwise that saved ip/mac mapping would exist
> forever). Since the "bug" existed in nearly every vendors implementation
> (all using same BSD4.3 tahoe/reno software), we had to come up with a
> work-around for the saved ip/mac bug. Any time there was ip-address
> take-over, we would quickly saturate the local LAN with dummy traffic
> from a different ip-address ... forcing all the machines on that LAN to
> perform a real ARP cache lookup (resetting the "saved" value). Then the
> next activity from the taken-over ip-address would force the clients to
> do a real ARP cache lookup.
> 
> misc. past posts mentioning ha/cmp
> http://www.garlic.com/~lynn/subtopic.html#hacmp
> 
> -- 
> virtualization experience starting Jan1968, online at home since Mar1970
> 
> --
> 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 lis

Re: X86 server

[Anne & Lynn Wheeler]

mw...@ssfcu.org (Ward, Mike S) writes:
> IBM has always been a hardware company. In the 60's they wrote
> operating systems and gave them away as long as you purchased the
> hardware from them to run it on.

re:
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server
http://www.garlic.com/~lynn/2012l.html#19 X86 server

became much less so after Guerstner resurrected ibm.

recent revenue was 83% software and services with everything else
... including all hardware, 17%.  mainframe, x86, and power hardware
were approx. $5B each

max configured z196 with 80 processors is rated for 50BIPS and goes for
$28M (about $560,000/BIPS) and at $28M, $5B represents approx. 180
max. configured z196 (180*50 or aggregate of 9TIPS processing)

ibm has base price of $1815 for e5-2600 blade ... which have ratings at
527BIPS (about $3.44/BIPS), at $1815, $5B represents approx. 2,754,800
e5-2600 blades (2754800*527 or aggregate of 1,452,000TIPS). Even if you
inflate the base blade price by a factor of ten times, that reduces the
number of blades (you could get for $5B) to 275,480 with aggregate
processing power of 145,000TIPS

On the other hand the major cloud operators have claimed that they
manufacturer blades with optimal components for 1/3rd the cost of brand
name blades ... with a cloud megadatacenter typically containing several
hundred thousand blades.

a couple recent ibm-main references to Guerstner's resurrect of ibm:
http://www.garlic.com/~lynn/2012b.html#74 IBM Doing Some Restructuring?
http://www.garlic.com/~lynn/2012g.html#34 Co-existance of z/OS and z/VM on same 
DASD farm

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Anne & Lynn Wheeler]

uriel.carrasqui...@mail.mcgill.ca (Uriel Carrasquilla) writes:
> When I used to work for the stock exchange (in Vancouver), it was
> always the question about MF versus Tandem/Stratus fault-tolerant
> equipment.
> Yes, most of the problems were not hardware related.
> But one time we were hit by a massive failure in the primary and
> backup components that brought trading down.  It is black swan but can
> happen and the consequences can be nasty.
> When it comes to our mission critical applications, we are still a long way 
> from going to the clouds.
> But for those systems that we can afford the risk, yes, we will go to the 
> cloud.

re:
http://www.garlic.com/~lynn/2012l.html#16 X86 server
http://www.garlic.com/~lynn/2012l.html#18 X86 server

in ha/cmp we spent some amount of time with siac ... ran dataprocessing
for exchange ... they had a carefully selected datacenter in a building
that had lots of diverse routing ... two different water mains on
different sides of the building, different electrical mains on different
sides of the building to different substations, and four different telco
feeds on four sides of the building into four different central
exchanges (this besides UPS and power backup). past posts mentioning
ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

one of their outages was when the transformers in the basement blew-up
contaminanting the building with PCB ... and the building had to be
evacuated. misc. past posts mentioning SIAC
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL 
being used
http://www.garlic.com/~lynn/2007e.html#16 Attractive Alternatives to Mainframes
http://www.garlic.com/~lynn/2007k.html#41 DEC and news groups
http://www.garlic.com/~lynn/2007n.html#31 IBM obsoleting mainframe hardware
http://www.garlic.com/~lynn/2008b.html#36 windows time service
http://www.garlic.com/~lynn/2009g.html#2 Just posted third article about toxic 
assets in a series on the current financial crisis
http://www.garlic.com/~lynn/2009i.html#23 Why are z/OS people reluctant to use 
z/OS UNIX? (Are settlements a good argument for overnight batch COBOL ?)
http://www.garlic.com/~lynn/2009p.html#57 MasPar compiler and simulator
http://www.garlic.com/~lynn/2010q.html#37 Programmer Charged with thieft  
(maybe off topic)

I was out doing geographic separation and had coined the terms disaster
survivability and geographic survivability (to differentiate from
disaster recovery) ... some past posts
http://www.garlic.com/~lynn/submain.html#available

I was then asked to write a section for the corporate continuous
availability strategy document ... but when both rochester and POK
complained that they couldn't meet the requirements ... my section got
pulled.

I was also doing cluster scaleup ... mentioned in this early jan92
meeting in ellison's conference room
http://www.garlic.com/~lynn/95.html#13

and mainframe DB2 compalined if I was allowed to go ahead ... I would be
years ahead of them.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Anne & Lynn Wheeler]

john.mck...@healthmarkets.com (McKown, John) writes:
> "has always been" -> "had always been". As you indicated, at first
> software was written in order to sell the hardware. It was basically
> "overhead". However, when PCMs such as Amdahl came along and simply
> started redistributing IBM software (which they got for free since
> they owned IBM hardware), IBM had to have some other way to recoup
> their costs. Also, they started unbundling when the courts found them
> guilty of a monopoly which included their refusal to distribute
> software to non-IBM customers. At least, as best as I can recall after
> lo these many years.

re:
http://www.garlic.com/~lynn/2012l.html

23jun69 unbundling announcement was result of various litigation,
required starting to charge for application software, SE services,
hardware maint., etc. Company managed to make the case that kernel
software should still be free. misc. past unbundling posts
http://www.garlic.com/~lynn/submain.html#unbundle

FS effort in the early 70s was motivated by competition clone
controllers (it was going to have been radically different from 370),
The rise and fall of IBM
http://www.ecole.org/en/seances/CM07

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead that
the competition would never be able to keep up, and to have such a high
level of integration that it would be impossible for competitors to
follow a compatible niche strategy. However, the project failed because
the objectives were too ambitious for the available technology.  Many of
the ideas that were developed were nevertheless adapted for later
generations. Once IBM had acknowledged this failure, it launched its
'box strategy', which called for competitiveness with all the different
types of compatible sub-systems. But this proved to be difficult because
of IBM's cost structure and its R&D spending, and the strategy only
resulted in a partial narrowing of the price gap between IBM and its
rivals.

... snip ...

misc. other Future System refs:
http://www.jfsowa.com/computer/memo125.htm
http://www.cs.clemson.edu/~mark/fs.html
http://en.wikipedia.org/wiki/IBM_Future_Systems_project
http://gdrean.perso.sfr.fr/papers/promises.html

during Future System period, internal politics killed off and/or
suspended 370 acitivty ... also I continued to work on 360/370 stuff
... and periodically ridiculed FS (which possibly wasn't the greatest
career enhancing activity). The lack of 370 products was credited with
allowing clone processors to gain market foothold.

and misc. past posts mentioning Future System
http://www.garlic.com/~lynn/submain.html#futuresys

In the wake of the FS failure, there was mad rush to get stuff back into
the 370 product pipelines ... this contributed to decisions to release
various pieces of stuff that I was doing all during the FS period ...
old email mentioning 360/370 stuff during FS period (one of my hobbies
was providing production operating systems for internal datacenters):
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

With the rise of the clone processors (made possible by the lack of
products during the FS period) and with effort to get stuff back into
the 370 product pipelines ... there was also a change in the decision to
start charging for kernel software. This was going to be a staged
conversion ... with new kernel add-ons being charged ... leaving base
software free ... at least during transition period. One of my pieces
selected to go out was my resource manager ... and it was selected as
the guinea pig for starting to charge for kernel software (initially
add-on pieces) and I got to spend some amount of time with business
people about kernel charging policies. misc. past posts mentioning
my resource manager and/or scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Uriel Carrasquilla]

When I used to work for the stock exchange (in Vancouver), it was always the 
question about MF versus Tandem/Stratus fault-tolerant equipment.
Yes, most of the problems were not hardware related.
But one time we were hit by a massive failure in the primary and backup 
components that brought trading down.  It is black swan but can happen and the 
consequences can be nasty.
When it comes to our mission critical applications, we are still a long way 
from going to the clouds.
But for those systems that we can afford the risk, yes, we will go to the cloud.



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Anne & Lynn Wheeler [l...@garlic.com]
Sent: Thursday, August 23, 2012 12:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

john.mck...@healthmarkets.com (McKown, John) writes:
> X64 hardware, as much as it has improved, is still not as reliable or
> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> once. A spare picked up the work, automatically restarting the
> instruction stream, with no outage of any sort and no software
> involvement. X86, from what I'm told, would at least require the OS to
> do the equivalent of a checkpoint restart. Also had an OSA fail. The
> other OSA did an ARP takeover and no IP sessions were lost. TCPIP was
> informed, but all it did was put out a message and not start any new
> sessions on the failing OSA. Our "open" people called me a liar when I
> told them that.

big cloud operators do hundreds of thousands of blades in megadatacenter
with lots of failure/recovery infrastructure to handle individual blade
failures (usually with lots of power, telco, provisioning provisioning).

Gray had been studying mix of failures issues (both at IBM and later at
Tandem) and by '84 published report that hardware failures had become
minority of failure modes (hardware reliability had increased so other
kinds of failures were starting to dominating). scan of '84 presentation
http://www.garlic.com/~lynn/grayft84.pdf

several of the big cloud operators have published detailed studies of
different component availability as part of building their own blades
... given optimal service life per dollar.

Cluster & take-over were increasingly being used to mask all kinds of
outages ... even able to handle geographic operations and handling
disasters taking out whole datacenter.

when we were doing ha/cmp ... we did a lot of failure mode study ... and
part of our marketing was against hardware fault-tolerant systems.  We
showed availability of ha/cmp clusters was higher than the
fault-tolerant systems. In competitive situation involving 1-800 number
server (i.e. maps 1-800 number to "real" number) ... it required
five-nines availability. hardware fault-tolerant system still required
scheduled system outage to do software upgrade ... which would blow
several decades of downtime budget. With cluster operation, we showed at
least as good hardware availability (with redundant systems) along with
capability of doing rolling software upgrades with no system outage.

the hardware fault tolerant vendor eventually came back with suggestion
that they could come out with redundant, cluster system operation ... to
handle the software upgrade issue. However, given reliability of
the underlying hardware operating in redundant, cluster system mode ...
there was no longer any justification for hardware fault tolerance.

part of ha/cmp was ip-address take-over ... which according to all the
standards should time-out mac/ip-address in arp caches. at the time,
most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip
stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup
software. The ARP cache management was correctly timing out the ARP
cache entries (so if there was ip-address take-over, it would discover
the new MAC mapping). However, the BSD4.3 IP code had a performance
optimization where it saved the last ip/mac lookup results ... which
would only get reset if the client communicated with a different
ip-address (otherwise that saved ip/mac mapping would exist
forever). Since the "bug" existed in nearly every vendors implementation
(all using same BSD4.3 tahoe/reno software), we had to come up with a
work-around for the saved ip/mac bug. Any time there was ip-address
take-over, we would quickly saturate the local LAN with dummy traffic
from a different ip-address ... forcing all the machines on that LAN to
perform a real ARP cache lookup (resetting the "saved" value). Then the
next activity from the taken-over ip-address would force the clients to
do a real ARP cache lookup.

misc. past posts mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

--
virtualization experience starting Jan1968, online at home since Mar1970

-

Re: X86 server

[McKown, John]

"has always been" -> "had always been". As you indicated, at first software was 
written in order to sell the hardware. It was basically "overhead". However, 
when PCMs such as Amdahl came along and simply started redistributing IBM 
software (which they got for free since they owned IBM hardware), IBM had to 
have some other way to recoup their costs. Also, they started unbundling when 
the courts found them guilty of a monopoly which included their refusal to 
distribute software to non-IBM customers. At least, as best as I can recall 
after lo these many years.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ward, Mike S
> Sent: Thursday, August 23, 2012 11:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> IBM has always been a hardware company. In the 60's they wrote
> operating systems and gave them away as long as you purchased the
> hardware from them to run it on.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, August 22, 2012 6:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> Which costs less?
> 
> On Wed, 22 Aug 2012 13:40:01 -0700, Edward Jaffe wrote:
> 
> >On 8/13/2012 10:01 PM, Jake anderson wrote:
> >> Does IBM provides support running Z/OS on X86 ?
> >
> >Yes, with its RD&T offering:
> >http://www.ibm.com/software/rational/products/devtest/systemz/
> >
> What's IBM's economic rationale here?  If it's cheaper for them to make
> z/OS available on X86, then much that I read in this forum about the
> economic advantages of zSeries is untrue, and IBM's motive for not
> licensing z/OS for X86 is simply to compel customers to buy the more
> expensive hardware from IBM.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee, you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received
> this message by mistake and delete this e-mail from your system. If you
> are not the intended recipient, you are notified that disclosing,
> copying, distributing or taking any action in reliance on the contents
> of this information is strictly prohibited.
> 
> --
> 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

Re: X86 server

[Ward, Mike S]

IBM has always been a hardware company. In the 60's they wrote operating 
systems and gave them away as long as you purchased the hardware from them to 
run it on. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, August 22, 2012 6:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

Which costs less?

On Wed, 22 Aug 2012 13:40:01 -0700, Edward Jaffe wrote:

>On 8/13/2012 10:01 PM, Jake anderson wrote:
>> Does IBM provides support running Z/OS on X86 ?
>
>Yes, with its RD&T offering:
>http://www.ibm.com/software/rational/products/devtest/systemz/
> 
What's IBM's economic rationale here?  If it's cheaper for them to make z/OS 
available on X86, then much that I read in this forum about the economic 
advantages of zSeries is untrue, and IBM's motive for not licensing z/OS for 
X86 is simply to compel customers to buy the more expensive hardware from IBM.

-- gil

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: X86 server

[Anne & Lynn Wheeler]

john.mck...@healthmarkets.com (McKown, John) writes:
> X64 hardware, as much as it has improved, is still not as reliable or
> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> once. A spare picked up the work, automatically restarting the
> instruction stream, with no outage of any sort and no software
> involvement. X86, from what I'm told, would at least require the OS to
> do the equivalent of a checkpoint restart. Also had an OSA fail. The
> other OSA did an ARP takeover and no IP sessions were lost. TCPIP was
> informed, but all it did was put out a message and not start any new
> sessions on the failing OSA. Our "open" people called me a liar when I
> told them that.

big cloud operators do hundreds of thousands of blades in megadatacenter
with lots of failure/recovery infrastructure to handle individual blade
failures (usually with lots of power, telco, provisioning provisioning).

Gray had been studying mix of failures issues (both at IBM and later at
Tandem) and by '84 published report that hardware failures had become
minority of failure modes (hardware reliability had increased so other
kinds of failures were starting to dominating). scan of '84 presentation
http://www.garlic.com/~lynn/grayft84.pdf

several of the big cloud operators have published detailed studies of
different component availability as part of building their own blades
... given optimal service life per dollar.

Cluster & take-over were increasingly being used to mask all kinds of
outages ... even able to handle geographic operations and handling
disasters taking out whole datacenter.

when we were doing ha/cmp ... we did a lot of failure mode study ... and
part of our marketing was against hardware fault-tolerant systems.  We
showed availability of ha/cmp clusters was higher than the
fault-tolerant systems. In competitive situation involving 1-800 number
server (i.e. maps 1-800 number to "real" number) ... it required
five-nines availability. hardware fault-tolerant system still required
scheduled system outage to do software upgrade ... which would blow
several decades of downtime budget. With cluster operation, we showed at
least as good hardware availability (with redundant systems) along with
capability of doing rolling software upgrades with no system outage.

the hardware fault tolerant vendor eventually came back with suggestion
that they could come out with redundant, cluster system operation ... to
handle the software upgrade issue. However, given reliability of
the underlying hardware operating in redundant, cluster system mode ...
there was no longer any justification for hardware fault tolerance.

part of ha/cmp was ip-address take-over ... which according to all the
standards should time-out mac/ip-address in arp caches. at the time,
most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip
stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup
software. The ARP cache management was correctly timing out the ARP
cache entries (so if there was ip-address take-over, it would discover
the new MAC mapping). However, the BSD4.3 IP code had a performance
optimization where it saved the last ip/mac lookup results ... which
would only get reset if the client communicated with a different
ip-address (otherwise that saved ip/mac mapping would exist
forever). Since the "bug" existed in nearly every vendors implementation
(all using same BSD4.3 tahoe/reno software), we had to come up with a
work-around for the saved ip/mac bug. Any time there was ip-address
take-over, we would quickly saturate the local LAN with dummy traffic
from a different ip-address ... forcing all the machines on that LAN to
perform a real ARP cache lookup (resetting the "saved" value). Then the
next activity from the taken-over ip-address would force the clients to
do a real ARP cache lookup.

misc. past posts mentioning ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: X86 server

[Bill Fairchild]

"We will accept responsibility for ..." to me sounds a lot like "if elected, I 
promise to ...".

Welcome to human reality.  It is part of the normal growth process to uncover 
and discard delusions.  Mencken said that the cynics were right 90 percent of 
the time.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane • Franklin, TN 37069-2526 • USA
t: +1.617.614.4503 •  e: bfairch...@rocketsoftware.com • w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of McKown, John
Sent: Thursday, August 23, 2012 7:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

I now don't believe much of anybody when they say that they will accept any 
responsibility for anything. Given time, they will renege on any agreement that 
they possibly can get away with reneging on. I am getting very cynical and sick 
of people in my old age.

--
John McKown

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

Re: X86 server

[Phil Smith]

John McKown wrote:
>From what I recall from some time ago (my personal memory is like FLASH - the 
>more I write, the more it is "worn out" and the faster it fails), back when 
>PSI(?) had a z emulator on Itanium, IBM sued them. Some of the reasons given 
>were:
>(1) that z/OS had a reputation in the field for extreme reliability;
>(2) much of z/OS's reliability was based on the z hardware's reliability and 
>automatic recovery from errors;
>(3) allowing z/OS to run on non-z hardware would decrease z/OS's reliability 
>due to decreased hardware reliability;
>(4) such reduction in reliability would adversely impact z/OS's reputation in 
>the market place;
>(5) this would negatively impact sales and increase support costs
>(6) therefore, allowing z/OS to run on non-z hardware (at least in a 
>non-development environment) was not in IBM's best interest.

Platform Solutions. They were indeed using a firmware layer on Itanium, built 
based on the old Amdahl IP.

Although the points you cite were part of the suit, the real meat of the issue 
was IBM's alleging that PSI had violated intellectual property agreements, as 
well as for encouraging violation of its licensing agreements. IBM finally put 
them out of their misery by buying them in 2008.
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)


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

Re: X86 server

[Uriel Carrasquilla]

When I think about zOS (MVS), I think about a solid reputation where RAS was 
the goal.
When I think Intel, I think about all the problems my company is willing to put 
up with because the applications require Windows (or Linux).
I can see why IBM will want to protect the zOS name and why IBM continues to 
invest in the MF HW business.  It is profitable, yes.  But then again, 
Microsoft is profitable and they did not built a business based on reliability 
but functionality and a GUI.
I subscribe to the idea that IBM must do what they can to protect their 
investment on the MF and that may be a the expense of turning off some 
customers.


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
R.S. [r.skoru...@bremultibank.com.pl]
Sent: Thursday, August 23, 2012 5:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

W dniu 2012-08-23 04:23, McKown, John pisze:
> X64 hardware, as much as it has improved, is still not as reliable or
> have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> once. A spare picked up the work, automatically restarting the
> instruction stream, with no outage of any sort and no software
> involvement. X86, from what I'm told, would at least require the OS
> to do the equivalent of a checkpoint restart. Also had an OSA fail.
> The other OSA did an ARP takeover and no IP sessions were lost. TCPIP
> was informed, but all it did was put out a message and not start any
> new sessions on the failing OSA. Our "open" people called me a liar
> when I told them that.

So ?
We know:
- mainframe HW is more reliable and more "redundant" than pc HW.
- even mainframe HW sometimes do fail.

Now we have the followig choices:
- use one OSA card or more and pay for that
- use single BOOK configuration, or pay for more BOOKs
- use single CPC or multiple sysplexedd CPCs
- etc. etc

So, we have some choice: you may want more reliable equipment and pay
more or less reliable one and pay less.
X64 would be another option to pay less for less reliablity. But it's
not due to decision of IBM. And it has very little to do with
technology, it has a lot of to do with business nd politics.




--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości 
wpłacony) wynosi 168.410.984 złotych.


--
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

Re: X86 server

[McKown, John]

From what I recall from some time ago (my personal memory is like FLASH - the 
more I write, the more it is "worn out" and the faster it fails), back when 
PSI(?) had a z emulator on Itanium, IBM sued them. Some of the reasons given 
were: 
(1) that z/OS had a reputation in the field for extreme reliability; 
(2) much of z/OS's reliability was based on the z hardware's reliability and 
automatic recovery from errors; 
(3) allowing z/OS to run on non-z hardware would decrease z/OS's reliability 
due to decreased hardware reliability; 
(4) such reduction in reliability would adversely impact z/OS's reputation in 
the market place; 
(5) this would negatively impact sales and increase support costs
(6) therefore, allowing z/OS to run on non-z hardware (at least in a 
non-development environment) was not in IBM's best interest.

I know you pointed out that (as we say around here), the user can "risk assess" 
and accept the decreased reliability in return for decreased cost. IMO, that's 
one of the reasons for running MS-Windows servers. But I also know, at least 
from what I've experienced, that despite this "risk acceptance", that end users 
will complain loudly if they don't get what they're used to. I'm going to catch 
hell today for just this reason. I was _forced_ to make an ACS change to our 
STORCLAS SMS routine. We had allocated a special storage group for a specific 
set of data set names, which started with a given HLQ . We did this, with the 
provision that they would not be recovered at Disaster Recovery. This was 
accepted. Back then. However, in our latest D.R. test, we "caught hell" because 
those "production" data sets were not available. We said, "We know. That was 
agreed to when we separated them into their own pool." They said, "Well that's 
not acceptable anymore." Us: "You agreed to back up what you needed yourself." 
Them: "Well, we changed our mind!!" So I had to make an emergency change. Our 
ACS routines are "fragile" and I missed a change. This, after a few hours, 
caused disk space errors. And I got charged with all the problems associated 
with it because I am the one who made the change. I now don't believe much of 
anybody when they say that they will accept any responsibility for anything. 
Given time, they will renege on any agreement that they possibly can get away 
with reneging on. I am getting very cynical and sick of people in my old age.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of R.S.
> Sent: Thursday, August 23, 2012 4:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> W dniu 2012-08-23 04:23, McKown, John pisze:
> > X64 hardware, as much as it has improved, is still not as reliable or
> > have the I/O capacity of the z hardware. E.g.: We had a TCM fail
> > once. A spare picked up the work, automatically restarting the
> > instruction stream, with no outage of any sort and no software
> > involvement. X86, from what I'm told, would at least require the OS
> > to do the equivalent of a checkpoint restart. Also had an OSA fail.
> > The other OSA did an ARP takeover and no IP sessions were lost. TCPIP
> > was informed, but all it did was put out a message and not start any
> > new sessions on the failing OSA. Our "open" people called me a liar
> > when I told them that.
> 
> So ?
> We know:
> - mainframe HW is more reliable and more "redundant" than pc HW.
> - even mainframe HW sometimes do fail.
> 
> Now we have the followig choices:
> - use one OSA card or more and pay for that
> - use single BOOK configuration, or pay for more BOOKs
> - use single CPC or multiple sysplexedd CPCs
> - etc. etc
> 
> So, we have some choice: you may want more reliable equipment and pay
> more or less reliable one and pay less.
> X64 would be another option to pay less for less reliablity. But it's
> not due to decision of IBM. And it has very little to do with
> technology, it

Re: X86 server

[R.S.]

W dniu 2012-08-23 04:23, McKown, John pisze:

X64 hardware, as much as it has improved, is still not as reliable or
have the I/O capacity of the z hardware. E.g.: We had a TCM fail
once. A spare picked up the work, automatically restarting the
instruction stream, with no outage of any sort and no software
involvement. X86, from what I'm told, would at least require the OS
to do the equivalent of a checkpoint restart. Also had an OSA fail.
The other OSA did an ARP takeover and no IP sessions were lost. TCPIP
was informed, but all it did was put out a message and not start any
new sessions on the failing OSA. Our "open" people called me a liar
when I told them that.


So ?
We know:
- mainframe HW is more reliable and more "redundant" than pc HW.
- even mainframe HW sometimes do fail.

Now we have the followig choices:
- use one OSA card or more and pay for that
- use single BOOK configuration, or pay for more BOOKs
- use single CPC or multiple sysplexedd CPCs
- etc. etc

So, we have some choice: you may want more reliable equipment and pay 
more or less reliable one and pay less.
X64 would be another option to pay less for less reliablity. But it's 
not due to decision of IBM. And it has very little to do with 
technology, it has a lot of to do with business nd politics.





--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.



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

Re: X86 server

[McKown, John]

X64 hardware, as much as it has improved, is still not as reliable or have the 
I/O capacity of the z hardware. E.g.: We had a TCM fail once. A spare picked up 
the work, automatically restarting the instruction stream, with no outage of 
any sort and no software involvement. X86, from what I'm told, would at least 
require the OS to do the equivalent of a checkpoint restart. Also had an OSA 
fail. The other OSA did an ARP takeover and no IP sessions were lost. TCPIP was 
informed, but all it did was put out a message and not start any new sessions 
on the failing OSA. Our "open" people called me a liar when I told them that.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, August 22, 2012 6:00 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> Which costs less?
> 
> On Wed, 22 Aug 2012 13:40:01 -0700, Edward Jaffe wrote:
> 
> >On 8/13/2012 10:01 PM, Jake anderson wrote:
> >> Does IBM provides support running Z/OS on X86 ?
> >
> >Yes, with its RD&T offering:
> >http://www.ibm.com/software/rational/products/devtest/systemz/
> >
> What's IBM's economic rationale here?  If it's cheaper for them to
> make z/OS available on X86, then much that I read in this forum
> about the economic advantages of zSeries is untrue, and IBM's
> motive for not licensing z/OS for X86 is simply to compel customers
> to buy the more expensive hardware from IBM.
> 
> -- gil
> 
> --
> 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

Re: X86 server

[Paul Gilmartin]

Which costs less?

On Wed, 22 Aug 2012 13:40:01 -0700, Edward Jaffe wrote:

>On 8/13/2012 10:01 PM, Jake anderson wrote:
>> Does IBM provides support running Z/OS on X86 ?
>
>Yes, with its RD&T offering:
>http://www.ibm.com/software/rational/products/devtest/systemz/
> 
What's IBM's economic rationale here?  If it's cheaper for them to
make z/OS available on X86, then much that I read in this forum
about the economic advantages of zSeries is untrue, and IBM's
motive for not licensing z/OS for X86 is simply to compel customers
to buy the more expensive hardware from IBM.

-- gil

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

Re: X86 server

[Edward Jaffe]

On 8/13/2012 10:01 PM, Jake anderson wrote:

Does IBM provides support running Z/OS on X86 ?


Yes, with its RD&T offering: 
http://www.ibm.com/software/rational/products/devtest/systemz/


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

Re: X86 server

[Shmuel Metz (Seymour J.)]

In ,
on 08/14/2012
   at 08:58 AM, "McKown, John"  said:

>Just a guess on my part, but the OP may know that Linux runs natively
>on many hardware systems: i386, x86_64, Power, i, and z. He may have
>been wondering if z/OS could also run on multiple architectures. Of
>course, on reason that Linux runs on so many architectures is thanks
>to GNU's GCC being ported to so many and the fact that the majority
>of Linux is written in C. I was always wondering if IBM could convert
>z/OS to another architecture by changing the "back end" of PL/S (or
>whatever it's called now, I just don't seem to be able to remember,
>don't flame me, please) along with an HLASM which take z instructions
>and "assembles" then into the equivalent in another architecture.

PL/S includes the GENERATE statement, which allows imbedded assembler
code. As for cross-compiling, there generally is no equivalent to an
instruction in a different architecture. People[1] have written
translation programs, but they involve flow analysis of the entire
program, not just macros handling snippets.

[1] Including me.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: X86 server

[zMan]

On Tue, Aug 14, 2012 at 7:21 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Unrelated question, now we're on this jolly joyride: Is it true that z/VM
> can be run on a Pentium machine? Perhaps as a guest under Linux / Unix or
> Win7 (Virtual machine)?
>

In what way? Under Herc? Sure. Under zPDT? Sure. Under FLEX-ES 64-bit?
Sure. Legal/available? Different answers for the different combinations...
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: X86 server

[Joel C. Ewing]

In-line response.

On 08/14/2012 08:58 AM, McKown, John wrote:

Just a guess on my part, but the OP may know that Linux runs natively on many hardware systems: 
i386, x86_64, Power, i, and z. He may have been wondering if z/OS could also run on multiple 
architectures. Of course, on reason that Linux runs on so many architectures is thanks to GNU's GCC 
being ported to so many and the fact that the majority of Linux is written in C. I was always 
wondering if IBM could convert z/OS to another architecture by changing the "back end" of 
PL/S (or whatever it's called now, I just don't seem to be able to remember, don't flame me, 
please) along with an HLASM which take z instructions and "assembles" then into the 
equivalent in another architecture.


Even assuming that most of z/OS were written in some higher-level 
language, just changing the compiler code generation to do the same data 
structure manipulations using machine instructions on a different 
architecture wouldn't do much for functionality, because so many of 
those data structures manipulated within the guts of the operating 
system (e.g., page/segment tables, Program Call tables, PSWs, Control 
Registers, channel programs, etc.) are intimately related to the z/OS 
architecture and cease to have any meaning outside the context of z/OS 
architecture; not to mention that some of the z architecture hardware 
instructions invoked within z/OS are exceedingly complex and may have no 
simple counterpart in other architectures.


I'm sure parts of Linux having to do with virtual memory, I/O,  hardware 
control, and hardware context switching have to be completely rewritten 
for different hardware architectures as well, but my impression is that 
Linux design philosophy has long included multi-platform support and 
this constrains the design and to what extent and where hardware 
dependences are allowed.


MVS and its successors have never been intended for anything other than 
S/360 and its successor architectures, and there are 50 years of a 
symbiotic relationship between hardware and software where major 
hardware enhancements have been made just to support specific 
functionality more efficiently or more securely in MVS or major MVS 
subsystems like CICS or DB2; and major enhancements have been added to 
MVS just to exploit new hardware features.  Those hardware/software 
interdependences are so thoroughly diffused throughout z/OS and its 
major subsystems that I would suspect attempting to make z/OS run on any 
other architecture is unrealistic.

  J C Ewing


Along these lines, "mainframe" does not always mean "IBM z" system. There are vendors who consider 
an Itanium to be a "mainframe". Personally, I liked whatever it was they ran in Eureka! "If you can't 
crawl around inside it, it's not a mainframe!"

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


-Original Message-
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zMan
Sent: Tuesday, August 14, 2012 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: X86 server

On Mon, Aug 13, 2012 at 10:01 PM, Jake anderson
wrote:


Hi,

Does IBM provides support running Z/OS on X86 ?



Do you mean, "Will IBM provide support for z/OS if you're
running it under
emulation on Intel hardware?", or "Does IBM provide System z
emulation so
you can run z/OS on Intel hardware?" -- those are quite
different, though
the answer turns out to be the same.

If you have legal access to a zPDT, either as a business
partner or via the
Rational offering. then the answer is YES. Otherwise the answer is NO.

Don't take this the wrong way, but with a userid of
"justmainframes", your
questions are pretty ... basic. And lack context. What are you really
trying to do here? What's the goal? You'll get more help if
you explain
yourself a bit more.
--
zMan -- "I've got a mainframe and I'm not afraid to use it"






--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: X86 server

[Elardus Engelbrecht]

McKown, John wrote:

>Just a guess on my part, but the OP may know that Linux runs natively on many 
>hardware systems: i386, x86_64, Power, i, and z. 

True, if you can port the source or the compiled object codes to that platform. 
The C language is very handy for such porting. (disclaimer - I have NO 
experience in such things)


>He may have been wondering if z/OS could also run on multiple architectures.

Hercules for example? But then there is licensing issues. Search the archives.


Unrelated question, now we're on this jolly joyride: Is it true that z/VM can 
be run on a Pentium machine? Perhaps as a guest under Linux / Unix or Win7 
(Virtual machine)?

Just curious of course.

>Along these lines, "mainframe" does not always mean "IBM z" system. There are 
>vendors who consider an Itanium to be a "mainframe". Personally, I liked 
>whatever it was they ran in Eureka! "If you can't crawl around inside it, it's 
>not a mainframe!"

I like this version: if you can't steal it (hardware), it is a mainframe! ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: X86 server

[Elardus Engelbrecht]

Jake anderson wrote:

>Does IBM provides support running Z/OS on X86 ?

Did you ask them?

And please follow zMan's suggestion...

Groete / Greetings
Elardus Engelbrecht

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

Re: X86 server

[McKown, John]

Just a guess on my part, but the OP may know that Linux runs natively on many 
hardware systems: i386, x86_64, Power, i, and z. He may have been wondering if 
z/OS could also run on multiple architectures. Of course, on reason that Linux 
runs on so many architectures is thanks to GNU's GCC being ported to so many 
and the fact that the majority of Linux is written in C. I was always wondering 
if IBM could convert z/OS to another architecture by changing the "back end" of 
PL/S (or whatever it's called now, I just don't seem to be able to remember, 
don't flame me, please) along with an HLASM which take z instructions and 
"assembles" then into the equivalent in another architecture.

Along these lines, "mainframe" does not always mean "IBM z" system. There are 
vendors who consider an Itanium to be a "mainframe". Personally, I liked 
whatever it was they ran in Eureka! "If you can't crawl around inside it, it's 
not a mainframe!"

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zMan
> Sent: Tuesday, August 14, 2012 8:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: X86 server
> 
> On Mon, Aug 13, 2012 at 10:01 PM, Jake anderson 
> wrote:
> 
> > Hi,
> >
> > Does IBM provides support running Z/OS on X86 ?
> 
> 
> Do you mean, "Will IBM provide support for z/OS if you're 
> running it under
> emulation on Intel hardware?", or "Does IBM provide System z 
> emulation so
> you can run z/OS on Intel hardware?" -- those are quite 
> different, though
> the answer turns out to be the same.
> 
> If you have legal access to a zPDT, either as a business 
> partner or via the
> Rational offering. then the answer is YES. Otherwise the answer is NO.
> 
> Don't take this the wrong way, but with a userid of 
> "justmainframes", your
> questions are pretty ... basic. And lack context. What are you really
> trying to do here? What's the goal? You'll get more help if 
> you explain
> yourself a bit more.
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> 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

Re: X86 server

[zMan]

On Mon, Aug 13, 2012 at 10:01 PM, Jake anderson wrote:

> Hi,
>
> Does IBM provides support running Z/OS on X86 ?


Do you mean, "Will IBM provide support for z/OS if you're running it under
emulation on Intel hardware?", or "Does IBM provide System z emulation so
you can run z/OS on Intel hardware?" -- those are quite different, though
the answer turns out to be the same.

If you have legal access to a zPDT, either as a business partner or via the
Rational offering. then the answer is YES. Otherwise the answer is NO.

Don't take this the wrong way, but with a userid of "justmainframes", your
questions are pretty ... basic. And lack context. What are you really
trying to do here? What's the goal? You'll get more help if you explain
yourself a bit more.
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: X86 server

[Jake anderson]

Hi,

Does IBM provides support running Z/OS on X86 ?

Jake

On Tue, Aug 14, 2012 at 1:25 AM, Tony Harminc  wrote:

> On 13 August 2012 11:06, Shmuel Metz (Seymour J.)
>  wrote:
> > In ,
> > on 08/13/2012  at 02:16 PM, Henri Kuiper  said:
> >
> >>If the latter is the case : feel free to contact me. You can take a
> >>sneak peak at http://zdevops.com
> >>We do z/OS virtualizations on x86 hardware :).
> >
> > What about software licensing? What advantage do you have over Hercules,
> which is free?
>
> It sounds as though he is reselling zPDT. Certainly if someone was
> offering yet another zArch emulator commercially, IBM would be on
> their case faster than .
>
> Tony H.
>
> --
> 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

Re: X86 server

[Tony Harminc]

On 13 August 2012 11:06, Shmuel Metz (Seymour J.)
 wrote:
> In ,
> on 08/13/2012  at 02:16 PM, Henri Kuiper  said:
>
>>If the latter is the case : feel free to contact me. You can take a
>>sneak peak at http://zdevops.com
>>We do z/OS virtualizations on x86 hardware :).
>
> What about software licensing? What advantage do you have over Hercules, 
> which is free?

It sounds as though he is reselling zPDT. Certainly if someone was
offering yet another zArch emulator commercially, IBM would be on
their case faster than .

Tony H.

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

Re: X86 server

[Shmuel Metz (Seymour J.)]

In
,
on 08/13/2012
   at 02:16 PM, Henri Kuiper  said:

>If the latter is the case : feel free to contact me. You can take a
>sneak peak at http://zdevops.com
>We do z/OS virtualizations on x86 hardware :).

What about software licensing? What advantage do you have over
Hercules, which is free?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: X86 server

[Mark Post]

>>> On 8/13/2012 at 11:32 AM, Paul Gilmartin  wrote: 
> Would this be more like Platform Solutions Inc., or like Hercules, or
> like Neon ZPrime?

I suspect it's more like (as in "is") zPDT, or it's cousin RDz.


Mark Post

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

Re: X86 server

[Paul Gilmartin]

On Mon, 13 Aug 2012 14:16:14 +0200, Henri Kuiper wrote:
>
>Or are you hinting at running z/OS from x86 hardware?
>
>If the latter is the case : feel free to contact me. You can take a sneak
>peak at http://zdevops.com
>We do z/OS virtualizations on x86 hardware :).
> 
Would this be more like Platform Solutions Inc., or like Hercules, or
like Neon ZPrime?

Or more like Wine or Citrix?  Perhaps it virtualizes only the APIs, but
that itself is a heroic task.

What compilers and other middleware such as data base servers
are available for license?

-- gil

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

Re: X86 server

[Henri Kuiper]

Jake,

What x86 server are you referring to? Are you talking about the x68blades
in a zBX-frame connected to the mainframe?
Or are you hinting at running z/OS from x86 hardware?

If the latter is the case : feel free to contact me. You can take a sneak
peak at http://zdevops.com
We do z/OS virtualizations on x86 hardware :).

Cheers


Henri


On Mon, Aug 13, 2012 at 1:27 PM, Jake anderson wrote:

> Dear All,
>
> Could someone provide more information on X86 server ? I am just curious to
> know if this server is a mimic of Z.OS ? If it is so Migrating from Z/OS to
> X86 will be a good idea ?
>
> Jake
>
> --
> 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