Re: zIIP simulation

[Scott Fagen]

And you can hear Chris and the IDMS team speak about this:

CA IDMS gets even zIIP-ier.  

Want more CPU without buying more MIPS?  Join the CA IDMS team and customers 
Chris Hoelscher and Iain Robertson for a live webcast and quick tour of the new 
CA IDMS zIIP expansion in 18.0 and 18.5.  

Tuesday, November 19, 2013 10:30 am, Eastern Standard Time (New York, GMT-05:00)
Event number: 740 118 779
Event password: This event does not require a password.
Event address for attendees: 
https://catechnologies.webex.com/catechnologies/onstage/g.php?d=740118779&t=a


On Mon, 11 Nov 2013 04:32:31 +, Chris Hoelscher  
wrote:

(CA-)IDMS recently published a enhancement that allows ALL eligible workload to 
be sent to zIIP processors - in our busiest systems (100million+ tasks/week) - 
we saw a 97% reduction in TCB cpu  IDMS is certainly alive and well at our 
shop! 

Chris hoelscher
Technology Architect | Database Infrastructure Services
Technology Solution Services

123 East Main Street |Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 476-2538 – office
(502) 714-8615 - blackberry
Keeping CAS and Metavance safe for all HUMANAty

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

Re: zIIP simulation

[Chris Hoelscher]

(CA-)IDMS recently published a enhancement that allows ALL eligible workload to 
be sent to zIIP processors - in our busiest systems (100million+ tasks/week) - 
we saw a 97% reduction in TCB cpu  IDMS is certainly alive and well at our 
shop! 

Chris hoelscher
Technology Architect | Database Infrastructure Services
Technology Solution Services

123 East Main Street |Louisville, KY 40202
choelsc...@humana.com
Humana.com
(502) 476-2538 – office
(502) 714-8615 - blackberry
Keeping CAS and Metavance safe for all HUMANAty

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Wednesday, October 30, 2013 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] zIIP simulation

On 10/30/2013 5:37 AM, Shane Ginnane wrote:
> Anyone ever figured out why IBM (still) doesn't allow all of the 
> eligible workload to be dispatched on the zIIP ?

$$

-- 
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


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

Re: Security exposure of zXXP was Re: zIIP simulation

[Timothy Sipples]

IBM has done some recent work improving SMF efficiency, for example via SMF
exploitation of the new zEnterprise Data Compression (zEDC) feature. If you
have moderate to heavy SMF activity then I would advise taking a close look
at the zEDC feature. (There are other reasons to consider zEDC, too.)


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Security exposure of zXXP was Re: zIIP simulation

[Blaicher, Christopher Y.]

Timothy,

I think you are confusing operational costs with software costs.

Having worked for several ISV's, we were often looking at ways to make running 
our products less expensive.  We charged just as much for them as before and it 
did not stop the 'normal' price increases.  Note: I twiddle the bits, not the 
cents, so pricing is way outside my comfort zone and I pass no judgments on 
that, other than to say if there was no ROI then no one would buy the product.  
And, yes, my degree is in economics.

The specialty engines that you refer to (and the GP processor) are actually all 
the same chip, they are just re-taskings as to what can run on it.  That is why 
another ISV was able to do a little magic and have regular jobs run on a z/IIP 
engine.

IBM is coming up with new specialty add-on cards which is what CryptoExpress 
and others actually are.  These are not in the same category as a GP or z/IIP, 
etc.

Back to your original thought.  Decreasing the operational cost of monitoring 
frees up resources for functions that actually make money, so that is a good 
thing.  The one area that I wish could be improved on is the processing of SMF 
data.  At one shop I worked in, our biggest single application was processing 
the daily SMF data.  The software we used to process it was inexpensive, MXG 
and SAS, but the operational cost was high.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260  |  M: 512-627-3803
E: cblaic...@syncsort.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Wednesday, November 06, 2013 12:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Security exposure of zXXP was Re: zIIP simulation



If, on the other hand, you're asking IBM (and other vendors) to spend some of 
their precious engineering talents and efforts on new price discrimination 
features specifically for monitoring, does that really make sense? Let's 
suppose for sake of argument that such new facilities existed, and consequently 
the "price" to run monitoring decreases. OK, then what happens to the prices of 
everything else? And, for that matter, what happens to the prices of monitoring 
tools? These vendors still have payroll to meet, still have R&D to do, still 
have support to deliver, etc.

Will you actually end up with more and better monitoring? Or will the most 
likely outcome be that you run exactly the same (or even less!) monitoring than 
you do today, and your total IT expenditures barely budge (ceteris
paribus) as the various vendors quickly re-establish market equilibrium?

Did anyone else ever study economics? :-)

I rather like the current situation, which is that there are these nifty things 
called zIIPs which vendors can choose to use as much or as little as they wish 
according to their particular individual business models (and with an IBM 
agreement). That is, there are already *plenty* of ways tools vendors can price 
discriminate if/as they wish and if/as competitive markets require. zEnterprise 
already has the most sophisticated, widest variety of metrics for vendors to 
price their wares compared to any other platform. And 1,000+ flowers have 
bloomed. Name any pricing design you want, and there's probably a zEnterprise 
vendor that offers it. Do we really need *more* such technical facilities(*) -- 
and do we need any more so badly that we can cancel something wonderful that 
IBM's engineers could be working on instead? I'd vote no(*) based on currently 
available information, though I try to keep an open mind. Along those lines, 
IBM has a Statement of Direction that zAAPs will no longer be available on 
future zEnterprise models, so IBM is trying to simplify things at least a bit 
since having four types of specialty z/OS engines probably isn't "enough 
better" than having three. (For those keeping score, the four types are SAPs, 
ICFs, zAAPs, and zIIPs. Four isn't necessarily the correct number -- zEDC, 
CryptoExpress, etc. also count -- but those are the four I was referring to.)

Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN



ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other  confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared 

Re: Security exposure of zXXP was Re: zIIP simulation

[Timothy Sipples]

Ed Jaffe wrote:
>Agreed. For example, it would be good if monitors such a RMF and
>others did not use costly machine cycles.

Leaving aside "costly machine cycles" (compared to what?), it would be
technically impossible, wouldn't it? It's at least very technically
difficult to monitor something without, well, monitoring. Instrumentation
always comes with a cost, though we can often get that cost down very low.
(I would posit that's already true today on zEnterprise compared to
anything else, but we're never completely satisfied.)

Sometimes I use the phrase "Be careful what you wish for," and this is one
of those occasions. If your request is that IBM (and other vendors)
continue working to make monitoring more efficient, I'd agree that's a
great idea. Efficiency promotes scalability and performance, making
previously impossible (or at least difficult) business computing problems
possible to solve and solve well. That's all good.

If, on the other hand, you're asking IBM (and other vendors) to spend some
of their precious engineering talents and efforts on new price
discrimination features specifically for monitoring, does that really make
sense? Let's suppose for sake of argument that such new facilities existed,
and consequently the "price" to run monitoring decreases. OK, then what
happens to the prices of everything else? And, for that matter, what
happens to the prices of monitoring tools? These vendors still have payroll
to meet, still have R&D to do, still have support to deliver, etc.

Will you actually end up with more and better monitoring? Or will the most
likely outcome be that you run exactly the same (or even less!) monitoring
than you do today, and your total IT expenditures barely budge (ceteris
paribus) as the various vendors quickly re-establish market equilibrium?

Did anyone else ever study economics? :-)

I rather like the current situation, which is that there are these nifty
things called zIIPs which vendors can choose to use as much or as little as
they wish according to their particular individual business models (and
with an IBM agreement). That is, there are already *plenty* of ways tools
vendors can price discriminate if/as they wish and if/as competitive
markets require. zEnterprise already has the most sophisticated, widest
variety of metrics for vendors to price their wares compared to any other
platform. And 1,000+ flowers have bloomed. Name any pricing design you
want, and there's probably a zEnterprise vendor that offers it. Do we
really need *more* such technical facilities(*) -- and do we need any more
so badly that we can cancel something wonderful that IBM's engineers could
be working on instead? I'd vote no(*) based on currently available
information, though I try to keep an open mind. Along those lines, IBM has
a Statement of Direction that zAAPs will no longer be available on future
zEnterprise models, so IBM is trying to simplify things at least a bit
since having four types of specialty z/OS engines probably isn't "enough
better" than having three. (For those keeping score, the four types are
SAPs, ICFs, zAAPs, and zIIPs. Four isn't necessarily the correct number --
zEDC, CryptoExpress, etc. also count -- but those are the four I was
referring to.)

Look, I can tell you that it makes little sense to "push the balloon." If
you want a lower cost of computing, great, but this sort of approach won't
do it. We learned that some years ago. I won't bore you with all the sordid
details -- maybe 10 years from now -- but the bottom line is if you want to
tackle cost you must tackle, well, cost. And to do that you have to do
pretty much what IBM is doing: drive growth, invest in innovations to keep
the business #1, and share at least some of the fruits of that growth with
our loyal customers to drive down their total costs for entire solution(s).
That's the "virtuous cycle." Rearranging the deck chairs, metaphorically
speaking, doesn't accomplish much.

(*) OK, there's one(**) technical enhancement in this area I'd personally
like to see IBM deliver. "Talk to your IBM Representative" if you agree,
and take a coffee break if you don't. :-) It'd be that SCRT would also
collect and tally SMF Type 89 records for anybody's product that cares to
generate such records. This enhancement wouldn't be so exciting for, say, a
random DB2 tool. The MSUs reported for DB2 serve pretty well in that case.
But it could still be interesting for other software products. I think the
ideas behind SCRT are really sound, and it'd be nice if every vendor who
wishes could more easily plug into that particular ecosystem if/as they
wish.

(**) OK, maybe two. I think additional sub-LPAR capping controls might be
interesting if technically doable, though there's already been some work
done there with IBM's Integrated Workload Pricing (IWP). Resistance to
provisioning an LPAR is way overblown in many organizations (compared to
what alternatives? again), but nonetheless I think there might be some room
for 

Re: Security exposure of zXXP was Re: zIIP simulation

[Tony Harminc]

FWIW, the UNIX services for file I/O are callable in SRB mode. But if
you are in SRB mode you own the world in any case.

Tony H.

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

Re: Security exposure of zXXP was Re: zIIP simulation

[DASDBILL2]

In the z/OS world, bare metal means SSCH and TSCH.  These are not for the 
faint-hearted, or even the heavy-duty. 
Bill Fairchild 
Franklin, TN 

- Original Message -

From: "Shmuel Metz (Seymour J.)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, November 5, 2013 3:04:01 PM 
Subject: Re: Security exposure of zXXP was Re: zIIP simulation 

In <8610219510148556.wa.paulgboulderaim@listserv.ua.edu>, on 
11/04/2013 
   at 06:00 PM, Paul Gilmartin  said: 

>Is it GUPI? 

No, but STARTIO is also not bare metal. 
  
-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT 
     ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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 


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

Re: Security exposure of zXXP was Re: zIIP simulation

[DASDBILL2]

No.  I was thinking that if one wanted to one could design an unnecessary ECB 
into the communication path somewhere just so one would feel at home with the 
ancient access method artifacts.  Having an ECB does not require than any code 
ever WAIT on it, of course.  It's just another place to have a flag bit that 
means I/O is finished. 
  
Bill Fairchild 
Franklin, TN 

- Original Message -

From: "Shmuel Metz (Seymour J.)"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, November 5, 2013 9:39:34 AM 
Subject: Re: Security exposure of zXXP was Re: zIIP simulation 

In <2048766999.1432321.1383584199930.javamail.r...@comcast.net>, on 
11/04/2013 
   at 04:56 PM, DASDBILL2  said: 

>SRBs can do I/O.  They can't do SVC instructions, however.  You 
>can start an I/O request without an SVC if you use the STARTIO 
>macro, which requires your code's being authorized.  You can know 
>when the I/O is complete by testing an ECB's 

ECB? We don't need no stinking ECB. Were you thinking of EXCP[VR}, 
which does use an ECB? 
  
-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT 
     ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
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 


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

Re: Security exposure of zXXP was Re: zIIP simulation

[Shmuel Metz (Seymour J.)]

In <8610219510148556.wa.paulgboulderaim@listserv.ua.edu>, on
11/04/2013
   at 06:00 PM, Paul Gilmartin  said:

>Is it GUPI?

No, but STARTIO is also not bare metal.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Security exposure of zXXP was Re: zIIP simulation

[Shmuel Metz (Seymour J.)]

In <2048766999.1432321.1383584199930.javamail.r...@comcast.net>, on
11/04/2013
   at 04:56 PM, DASDBILL2  said:

>SRBs can do I/O.  They can't do SVC instructions, however.  You 
>can start an I/O request without an SVC if you use the STARTIO 
>macro, which requires your code's being authorized.  You can know 
>when the I/O is complete by testing an ECB's 

ECB? We don't need no stinking ECB. Were you thinking of EXCP[VR},
which does use an ECB?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Security exposure of zXXP was Re: zIIP simulation

[Bob Rutledge]

Farley, Peter x23353 wrote:

PMFJI here Ed, but PSPI and DMTI aren't acronyms that I recognize.  
Translations please?

Peter


Product-Sensitive Programming Interface (The underlying software can change and 
this interface can change or disappear.)


Diagnosis, Modification and Tuning Information (Look, but don't touch.)

Bob

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Mark Jacobs]

On 11/04/13 19:00, Ed Jaffe wrote:

On 11/4/2013 9:23 AM, Russ Teubner wrote:
I don't think customers mind using (and paying for) high-value MIPS 
for high-value apps. However, everything else (e.g., integration and 
"plumbing") should be run on specialty engines (within the bounds of 
IBM's rules).


Agreed. For example, it would be good if monitors such a RMF and 
others did not use costly machine cycles.




The Tivoli Omegamon suite for one 

--
Mark Jacobs
Time Customer Service
Tampa, FL


The quiet ones are the ones that change the universe...
The loud ones only take the credit.

Londo Mollari - Babylon 5

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Farley, Peter x23353]

PMFJI here Ed, but PSPI and DMTI aren't acronyms that I recognize.  
Translations please?

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, November 04, 2013 7:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Security exposure of zXXP was Re: zIIP simulation

On 11/4/2013 4:00 PM, Paul Gilmartin wrote:
> On Mon, 4 Nov 2013 15:46:47 -0800, Ed Jaffe wrote:
>
>> I'm not sure I would call the venerable STARTIO interface the "metal"
>> level. It probably seems that way to most developers since it's so
>> poorly documented...
>>
> Is it GUPI?  I understand that IBM had intended that it not be GUPI.
> However it leaked into the lore in pre-OCO times.

STARTIO existed long before the notions of GUPI, PSPI and DMTI. AFAIK, 
IECDIOSB became classified DMTI long after the fact: as of MVS V5 I 
believe. Before that it was in the logic manuals, microfiche, etc. and 
still appears in the source-maintained portions of products like JES3 
and IMS.

--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Security exposure of zXXP was Re: zIIP simulation

[Ed Jaffe]

On 11/4/2013 4:00 PM, Paul Gilmartin wrote:

On Mon, 4 Nov 2013 15:46:47 -0800, Ed Jaffe wrote:


I'm not sure I would call the venerable STARTIO interface the "metal"
level. It probably seems that way to most developers since it's so
poorly documented...


Is it GUPI?  I understand that IBM had intended that it not be GUPI.
However it leaked into the lore in pre-OCO times.


STARTIO existed long before the notions of GUPI, PSPI and DMTI. AFAIK, 
IECDIOSB became classified DMTI long after the fact: as of MVS V5 I 
believe. Before that it was in the logic manuals, microfiche, etc. and 
still appears in the source-maintained portions of products like JES3 
and IMS.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: Security exposure of zXXP was Re: zIIP simulation

[Ed Jaffe]

On 11/4/2013 9:23 AM, Russ Teubner wrote:

I don't think customers mind using (and paying for) high-value MIPS for high-value apps. 
However, everything else (e.g., integration and "plumbing") should be run on 
specialty engines (within the bounds of IBM's rules).


Agreed. For example, it would be good if monitors such a RMF and others 
did not use costly machine cycles.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: Security exposure of zXXP was Re: zIIP simulation

[Paul Gilmartin]

On Mon, 4 Nov 2013 15:46:47 -0800, Ed Jaffe wrote:

>On 11/4/2013 5:01 AM, Binyamin Dissen wrote:
>> SRB's certainly can do I/O - they just need to do it at the metal level.
>
>I'm not sure I would call the venerable STARTIO interface the "metal"
>level. It probably seems that way to most developers since it's so
>poorly documented...
> 
Is it GUPI?  I understand that IBM had intended that it not be GUPI.
However it leaked into the lore in pre-OCO times.

-- gil

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Ed Jaffe]

On 11/4/2013 5:01 AM, Binyamin Dissen wrote:

SRB's certainly can do I/O - they just need to do it at the metal level.


I'm not sure I would call the venerable STARTIO interface the "metal" 
level. It probably seems that way to most developers since it's so 
poorly documented...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

What rhetoric? It's a fact that if any vendor other than IBM moved JAVA to 
zIIP, it would have been done with SRB's and JAVA would run authorized. It's a 
fact that IBM moved JAVA to zAAP because of $$ and customer demand. Why would 
vendors be any different with that desire for their end user programming 
languages.

Jon Perryman.



>
> From: John Gilmore 
>
>
>
>His riposte---It is not responsive---to my  last post employs a
>rhetorical device that was familiar to the Alexandrian Greeks.
>

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Russ Teubner]

zAAP's are indeed used by Java code running on a TCB.  However, to my 
knowledge, it does not follow that:  "With zAAP on zIIP, they must be using 
SRB's."  IBM determines the rules in this regard.

To me (as both an ISV and System z developer), IBM allowing more code to run on 
specialty engines is a VERY good thing.  It continues the controlled reduction 
in the cost of System z ownership.  As a side benefit, it has also promoted 
innovation within the ISV community.  For example, by zIIP enabling our 
integration products, some of our customers were able to deploy very cost 
effective solutions that would not have been possible otherwise.  This has 
allowed them to expand their System z workload.  

I don't think customers mind using (and paying for) high-value MIPS for 
high-value apps. However, everything else (e.g., integration and "plumbing") 
should be run on specialty engines (within the bounds of IBM's rules).  

Russ

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

Re: Security exposure of zXXP was Re: zIIP simulation

[DASDBILL2]

SRBs can do I/O.  They can't do SVC instructions, however.  You can start an 
I/O request without an SVC if you use the STARTIO macro, which requires your 
code's being authorized.  You can know when the I/O is complete by testing an 
ECB's completion code byte but not doing a WAIT on it.  It's more difficult to 
design an application that is heavily I/O bound using only SRBs, but it can be 
done.  A STARTIO can also be used to get the next I/O started even if your code 
is disabled for I/O interrupts and holds locks.  An SRB can run in all these 
modes. 
Bill Fairchild 
Franklin, TN 

- Original Message -

From: "Itschak Mugzach"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Monday, November 4, 2013 12:35:13 AM 
Subject: Re: Security exposure of zXXP was Re: zIIP simulation 

That's true. You can't infect files/load modulesqetc. 

ITschak 


On Mon, Nov 4, 2013 at 2:15 AM, Jon Perryman  wrote: 

> I think Itschak is saying that SRB's can't do I/O, therefore they can't 
> write files to embed a virus or read confidential data. I think he's under 
> the impression that SRB's can't get access to everything they desire. 
> 
> Jon Perryman. 
> 
> 
> 
> > 
> > From: Ed Jaffe  
> > 
> > 
> >On 11/3/2013 10:25 AM, Itschak Mugzach wrote: 
> >> SRB mode is also disabled for IO, so you can't infect other libraries / 
> files like a virus. 
> > 
> >Not sure what you're driving at here. It's true that zIIPs are disabled 
> for I/O interrupts, but so are most CPs unless you have a "boat load" of 
> I/O activity. How is that relevant? 
> > 
> 
> -- 
> 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 


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

Re: Security exposure of zXXP was Re: zIIP simulation

[Clark Morris]

On 4 Nov 2013 06:30:46 -0800, in bit.listserv.ibm-main you wrote:

>It is worth recalling Mr Perryman's name for this thread, viz.,
>
>Security exposure of zXXP.
>
>His riposte---It is not responsive---to my  last post employs a
>rhetorical device that was familiar to the Alexandrian Greeks.
>
>In answer to my contention that position 1457 and position 1458 in a
>Kama Sutra of programming tactics have the same orthopedic risks his
>rebuttal was that position 1457 aggravates scoliosis.
>
>My point---I made it in deliberately bald language---was that the
>security 'exposures' associated with the availability of SRBs are not
>worse for zIIPs and zAAPs than they are for unspecialized CPs.
>
>As Shane Ginnane noted in another context, auditors, however limited
>their technical grasp, can and do read.  I foresee yet another
>addition to their standard queries:

Is the code that can be made zIIP and zAAP eligible, code that must
run under an SRB anyway?  Is there is code that is currently running
unauthorized, problem state under a TCB that would be eligible if it
were running under an SRB?  For those vendors that have done zIIP /
zAAP enablement, did this involve move code from being unauthorized
under a TCB to authorized under an SRB?

Clark Morris
>
>o Does your z/OS or z/VM installation have
>   zIIPs, zAAPs, IFLs, . . . installed?
>
>o If so list the uses that are made of them,
>   identifying each application and each ISV
>   involved.
>
>John Gilmore, Ashland, MA 01721 - USA
>
>--
>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: Security exposure of zXXP was Re: zIIP simulation

[John Gilmore]

It is worth recalling Mr Perryman's name for this thread, viz.,

Security exposure of zXXP.

His riposte---It is not responsive---to my  last post employs a
rhetorical device that was familiar to the Alexandrian Greeks.

In answer to my contention that position 1457 and position 1458 in a
Kama Sutra of programming tactics have the same orthopedic risks his
rebuttal was that position 1457 aggravates scoliosis.

My point---I made it in deliberately bald language---was that the
security 'exposures' associated with the availability of SRBs are not
worse for zIIPs and zAAPs than they are for unspecialized CPs.

As Shane Ginnane noted in another context, auditors, however limited
their technical grasp, can and do read.  I foresee yet another
addition to their standard queries:

o Does your z/OS or z/VM installation have
   zIIPs, zAAPs, IFLs, . . . installed?

o If so list the uses that are made of them,
   identifying each application and each ISV
   involved.

John Gilmore, Ashland, MA 01721 - USA

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

Re: zIIP simulation

[Peter Relson]

I'm curious.

Some of the posters have indicated that their products avoid requesting 
zIIP services if there are no zIIPs.

If any care to share, is that a decision made at the time they start? Is 
that decision revisited? When the decision is made, by what fields is it 
made?
- number of currently online zIIPs > 0 (CSD_Number_Online_zIIPs, a 
programming interface)
- is a zIIP currently installed (SVT_ByLPAR_zIIP_NowInstalled, a 
programming interface, within SVT_zIIPzAAP_Flags)
- is a zIIP currently installed or could be installed later by dynamic CPU 
addition (SVT_ByLPAR_zIIPInConfiguration, not a programming interface but 
could be made one)
- a reason code from IWM4EOCT (to get that you'd have had to go at least 
somewhat down the enclave path already)

In the general case, even if there are currently no installed (or online) 
zIIPs there could be later.

We do intend to make SVT_CpuProjection a programming interface (and its 
containing byte when used with that bit name only). The update to the data 
areas book and to the SVT mapping macro to confirm that likely will not be 
made in service. But in practice I suggest that that not inhibit you from 
checking that bit in all supported releasesif it would benefit you to do 
so.

Peter Relson
z/OS Core Technology Design

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Kenneth Wilkerson]

Since an SRB can do a SCHEDIRB it can do whatever it likes. SRBs were
designed for authorized code to overcome restrictions. If you're authorized,
the gates open.

Kenneth

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Monday, November 04, 2013 7:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Security exposure of zXXP was Re: zIIP simulation

On Sun, 3 Nov 2013 16:15:56 -0800 Jon Perryman  wrote:

:>I think Itschak is saying that SRB's can't do I/O, therefore they can't
write files to embed a virus or read confidential data. I think he's under
the impression that SRB's can't get access to everything they desire.

SRB's certainly can do I/O - they just need to do it at the metal level.

--
Binyamin Dissen  http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me, you
should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems, especially
those from irresponsible companies.

--
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: Security exposure of zXXP was Re: zIIP simulation

[Binyamin Dissen]

On Sun, 3 Nov 2013 16:15:56 -0800 Jon Perryman  wrote:

:>I think Itschak is saying that SRB's can't do I/O, therefore they can't write 
files to embed a virus or read confidential data. I think he's under the 
impression that SRB's can't get access to everything they desire.

SRB's certainly can do I/O - they just need to do it at the metal level.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Shmuel Metz (Seymour J.)]

In
,
on 11/03/2013
   at 02:42 PM, John Gilmore  said:

>I will limit myself to noting that 1) an SRB cannot attach a subtask

It can, however, create and schedule an IRB, which in turn can attach
a subtask.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Security exposure of zXXP was Re: zIIP simulation

[Itschak Mugzach]

That's true. You can't infect files/load modulesqetc.

ITschak


On Mon, Nov 4, 2013 at 2:15 AM, Jon Perryman  wrote:

> I think Itschak is saying that SRB's can't do I/O, therefore they can't
> write files to embed a virus or read confidential data. I think he's under
> the impression that SRB's can't get access to everything they desire.
>
> Jon Perryman.
>
>
>
> >
> > From: Ed Jaffe 
> >
> >
> >On 11/3/2013 10:25 AM, Itschak Mugzach wrote:
> >> SRB mode is also disabled for IO, so you can't infect other libraries /
> files like a virus.
> >
> >Not sure what you're driving at here. It's true that zIIPs are disabled
> for I/O interrupts, but so are most CPs unless you have a "boat load" of
> I/O activity. How is that relevant?
> >
>
> --
> 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: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

I think Itschak is saying that SRB's can't do I/O, therefore they can't write 
files to embed a virus or read confidential data. I think he's under the 
impression that SRB's can't get access to everything they desire.

Jon Perryman.   



>
> From: Ed Jaffe 
>
>
>On 11/3/2013 10:25 AM, Itschak Mugzach wrote:
>> SRB mode is also disabled for IO, so you can't infect other libraries / 
>> files like a virus.
>
>Not sure what you're driving at here. It's true that zIIPs are disabled for 
>I/O interrupts, but so are most CPs unless you have a "boat load" of I/O 
>activity. How is that relevant?
>

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

Re: Security exposure of zXXP was Re: zIIP simulation

[John Gilmore]

I agree that the pool of talent is being diminished by deaths, low
recruitment because of poor perceived economic prospects, out
migration for the same reason, and---among the young---a perception
that the excitement is elsewhere.

This issue is, however, separable from that of competence to work in
the bowels of the operating system.

I do now a little regret the use of the adjective 'unwashed'.  I meant
it metaphorically not  literally.  As a practical matter I should be
entirely willing to work with [and downwind of] a competent but
malodorous sysprog.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Shane Ginnane]

On Sun, 3 Nov 2013 14:42:18 -0500, John Gilmore  wrote:

>The use of these facilities by the unwashed certainly has great
>potential for bringing down z/OS.

Your implied faith in your coterie transcends mine I'm afraid - the pool of 
talent seems to be diminishing.

Shane ...

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

No one was asking for details on how to attach a task but since Mr. Gilmore 
requires a full explanation, the SRB schedules an IRB that does the attach. My 
point was that you can do anything with an SRB. Some of the hacks on Windows 
and Unix are far more complicated than this but someone always seems to abuse 
them. What makes this any different.


Peter's comments are about inherent risk in a single SRB. Risk is assessed 
through probability which is more than a single occurrence. With zIIP, we must 
be running in thousands of times the workload to achieve the payback that 
customers see. Much more code executing under an SRB. Product support staff's 
that never looked at an SRB because it was easier just to pass it on to 
development. Training staff on code that should never be moved to an SRB 
because of security exposure (e.g. end user programming languages implemented 
within a product). Vendor products that never used an SRB will start using 
SRB's. 

Most of these SRB's will be running key 8 and will never issue modeset. 
Inadvertant errors are not a problem. In the past, we would never have end user 
code run in an SRB. With zIIP, a large portion of our code is now being 
consider SRB eligible. Some of that code run's under TCB's that never had 
authorization where end users could never abuse it will now be a potential 
exposure. 

Proverbial saying: can't see the forest for the tree's.

Jon Perryman



>
> From: John Gilmore 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Sunday, November 3, 2013 11:42 AM
>Subject: Re: Security exposure of zXXP was Re: zIIP simulation
> 
>
>I will not comment on Mr. Perryman's suspicions, which are not arguments.
>
>I will limit myself to noting that 1) an SRB cannot attach a subtask
>and 2) a [different] SRB that it scheduled into another address space
>would also disabled for I/O.
>
>Peter Relson's point is the important one here.
>
>The use of these facilities by the unwashed certainly has great
>potential for bringing
>down z/OS.  The security threat posed by an SRB executed on a cheap
>zIIP, zAAP, or the like is not, however, any greater in any way than
>the security threat of an SRB executed on an expensive standard CP.
>
>As Lewis Carroll put it in THOTS:
>
>Just the place for a Snark! I have said it twice:
>That alone should encourage the crew.
>Just the place for a Snark! I have said it thrice:
>What I tell you three times is true.
>

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Ed Jaffe]

On 11/3/2013 10:25 AM, Itschak Mugzach wrote:

THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are
running in the same address space, so it minimize the risk.


Not always.


SRB mode is
also disabled for IO, so you can't infect other libraries / files like a
virus.


Not sure what you're driving at here. It's true that zIIPs are disabled 
for I/O interrupts, but so are most CPs unless you have a "boat load" of 
I/O activity. How is that relevant?


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: Security exposure of zXXP was Re: zIIP simulation

[John Gilmore]

On 11/3/13, John Gilmore  wrote:
> I will not comment on Mr. Perryman's suspicions, which are not arguments.
>
> I will limit myself to noting that 1) an SRB cannot attach a subtask
> and 2) a [different] SRB that it scheduled into another address space
> would also disabled for I/O.
>
> Peter Relson's point is the important one here.
>
> The use of these facilities by the unwashed certainly has great
> potential for bringing
> down z/OS.  The security threat posed by an SRB executed on a cheap
> zIIP, zAAP, or the like is not, however, any greater in any way than
> the security threat of an SRB executed on an expensive standard CP.
>
> As Lewis Carroll put it in THOTS:
>
> Just the place for a Snark! I have said it twice:
> That alone should encourage the crew.
> Just the place for a Snark! I have said it thrice:
> What I tell you three times is true.
>
> --John Gilmore, Ashland, MA 01721 - USA
>


-- 
John Gilmore, Ashland, MA 01721 - USA

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

Re: Security exposure of zXXP was Re: zIIP simulation

[John Gilmore]

I will not comment on Mr. Perryman's suspicions, which are not arguments.

I will limit myself to noting that 1) an SRB cannot attach a subtask
and 2) a [different] SRB that it scheduled into another address space
would also disabled for I/O.

Peter Relson's point is the important one here.

The use of these facilities by the unwashed certainly has great
potential for bringing
down z/OS.  The security threat posed by an SRB executed on a cheap
zIIP, zAAP, or the like is not, however, any greater in any way than
the security threat of an SRB executed on an expensive standard CP.

As Lewis Carroll put it in THOTS:

Just the place for a Snark! I have said it twice:
That alone should encourage the crew.
Just the place for a Snark! I have said it thrice:
What I tell you three times is true.

--John Gilmore, Ashland, MA 01721 - USA

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

Do vendor's have access to the WLM implementation that allows TCB's to run on a 
zIIP? Since JAVA was implemented starting with z/OS 1.11, I suspect they may 
use SRB's otherwise they could have easily retrofitted it to earlier versions. 

As for the risk, an SRB can use cross memory facilities. It can schedule an SRB 
to another address space and attach a subtask. These are all well documented, 
known and used. These alone would let you do file I/O and mimic any active 
user. Lesser know would be some of the key system addresses which can easily be 
replaced while running in key 0. This is exactly where a hacker would want to 
be in order to hide their tracks and do devious things without getting caught.

Jon Perryman.


>
> From: Itschak Mugzach 
>
>
>SRB mode is only needed if you use IBM's supplied API to zIIP. WLM is the
>part of z/os that schedules the TCB/SRB to the a proccessor and there is a
>know-how to do this, and indead requires deep knowledge of mvs interfaces
>and assembler coding.
>THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are
>running in the same address space, so it minimize the risk. SRB mode is
>also disabled for IO, so you can't infect other libraries / files like a
>virus.
>
>ITschak
>
>
>On Sun, Nov 3, 2013 at 7:41 PM, Jon Perryman  wrote:
>
>> I suspect we need an SRB that is non-authorized and can never get into an
>> authorized state. I hate giving auditors information with which they can
>> abuse us but this probably needs to be discussed. By making zIIP so cheap,
>> IBM and customers are strongly encouraging us to offload as much work as
>> possible onto zIIP. Products that never needed APF authorization may be
>> forced to become APF authorized.  Some of our code that we ran in
>> unauthorized tasks will probably move to SRB's.
>>
>> JAVA is a good example. IBM created "zAAP on zIIP" in z/OS 1.11. I believe
>> that zAAP is accessed through a TCB which is not running authorized. With
>> zAAP on zIIP, they must be using SRB's. Some of that JAVA program must be
>> running in SRB mode (unless only interpretation occurs on the zIIP and
>> execution is in the TCB).. A hacker can potentially create JAVA code that
>> runs in SRB mode to take advantage of the authorized state. Something as
>> simple as overlaying storage could create a security exposure and give them
>> access to the authorized state.
>>
>> Jon Perryman.
>>
>>
>>
>> - Original Message -
>> > From: Peter Relson 
>> >
>> >> SRB's are a big security exposure so customers are unlikely to open them
>> >> to their programmers.
>> >
>> > SRBs are the same level of security exposure that APF-authorized tasks
>> > are. So if an application is already APF-authorized, switching to enclave
>> > SRBs is not intrinsically more of a security exposure than already
>> > existed. It is true that SRBs are more likely to tend to be key 0 than
>> > authorized tasks, but that is not a security exposure. That is a "greater
>> > potential for screwing up a system due to overlay of something critical"
>> > exposure.
>> >
>> >> Is the code that runs under the ZIP and ZAP
>> >> process code that normally run without any privileges in a problem
>> >> state?
>> >
>> > Only if the perpetrator is irresponsible. It is far from unheard of to
>> > have to take an application written to be unauthorized and make it
>> > authorized. But if anyone thinks it is as simple as changing the linkedit
>> > characteristic to AC=1 and placing it in an APF-authorized library, then
>> > they need to be re-educated (and quickly if they're the one responsible
>> > for the implementation).
>>
>>
>> --
>> 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
>
>
>

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Itschak Mugzach]

SRB mode is only needed if you use IBM's supplied API to zIIP. WLM is the
part of z/os that schedules the TCB/SRB to the a proccessor and there is a
know-how to do this, and indead requires deep knowledge of mvs interfaces
and assembler coding.
THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are
running in the same address space, so it minimize the risk. SRB mode is
also disabled for IO, so you can't infect other libraries / files like a
virus.

ITschak


On Sun, Nov 3, 2013 at 7:41 PM, Jon Perryman  wrote:

> I suspect we need an SRB that is non-authorized and can never get into an
> authorized state. I hate giving auditors information with which they can
> abuse us but this probably needs to be discussed. By making zIIP so cheap,
> IBM and customers are strongly encouraging us to offload as much work as
> possible onto zIIP. Products that never needed APF authorization may be
> forced to become APF authorized.  Some of our code that we ran in
> unauthorized tasks will probably move to SRB's.
>
> JAVA is a good example. IBM created "zAAP on zIIP" in z/OS 1.11. I believe
> that zAAP is accessed through a TCB which is not running authorized. With
> zAAP on zIIP, they must be using SRB's. Some of that JAVA program must be
> running in SRB mode (unless only interpretation occurs on the zIIP and
> execution is in the TCB).. A hacker can potentially create JAVA code that
> runs in SRB mode to take advantage of the authorized state. Something as
> simple as overlaying storage could create a security exposure and give them
> access to the authorized state.
>
> Jon Perryman.
>
>
>
> - Original Message -
> > From: Peter Relson 
> >
> >> SRB's are a big security exposure so customers are unlikely to open them
> >> to their programmers.
> >
> > SRBs are the same level of security exposure that APF-authorized tasks
> > are. So if an application is already APF-authorized, switching to enclave
> > SRBs is not intrinsically more of a security exposure than already
> > existed. It is true that SRBs are more likely to tend to be key 0 than
> > authorized tasks, but that is not a security exposure. That is a "greater
> > potential for screwing up a system due to overlay of something critical"
> > exposure.
> >
> >> Is the code that runs under the ZIP and ZAP
> >> process code that normally run without any privileges in a problem
> >> state?
> >
> > Only if the perpetrator is irresponsible. It is far from unheard of to
> > have to take an application written to be unauthorized and make it
> > authorized. But if anyone thinks it is as simple as changing the linkedit
> > characteristic to AC=1 and placing it in an APF-authorized library, then
> > they need to be re-educated (and quickly if they're the one responsible
> > for the implementation).
>
>
> --
> 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: Security exposure of zXXP was Re: zIIP simulation

[John Gilmore]

I could almost wish that Mr. Perryman's conjectures were correct.
They would greatly widen the market for strong assembly-language
programming skills, which is much shrunken from what it once was; and
that would be good for the platform.

Alas, however, . . .

John Gilmore, Ashland, MA 01721 - USA

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

I suspect we need an SRB that is non-authorized and can never get into an 
authorized state. I hate giving auditors information with which they can abuse 
us but this probably needs to be discussed. By making zIIP so cheap, IBM and 
customers are strongly encouraging us to offload as much work as possible onto 
zIIP. Products that never needed APF authorization may be forced to become APF 
authorized.  Some of our code that we ran in unauthorized tasks will probably 
move to SRB's. 

JAVA is a good example. IBM created "zAAP on zIIP" in z/OS 1.11. I believe that 
zAAP is accessed through a TCB which is not running authorized. With zAAP on 
zIIP, they must be using SRB's. Some of that JAVA program must be running in 
SRB mode (unless only interpretation occurs on the zIIP and execution is in the 
TCB).. A hacker can potentially create JAVA code that runs in SRB mode to take 
advantage of the authorized state. Something as simple as overlaying storage 
could create a security exposure and give them access to the authorized state. 

Jon Perryman.



- Original Message -
> From: Peter Relson 
> 
>> SRB's are a big security exposure so customers are unlikely to open them 
>> to their programmers. 
> 
> SRBs are the same level of security exposure that APF-authorized tasks 
> are. So if an application is already APF-authorized, switching to enclave 
> SRBs is not intrinsically more of a security exposure than already 
> existed. It is true that SRBs are more likely to tend to be key 0 than 
> authorized tasks, but that is not a security exposure. That is a "greater 
> potential for screwing up a system due to overlay of something critical" 
> exposure.
> 
>> Is the code that runs under the ZIP and ZAP
>> process code that normally run without any privileges in a problem
>> state?
> 
> Only if the perpetrator is irresponsible. It is far from unheard of to 
> have to take an application written to be unauthorized and make it 
> authorized. But if anyone thinks it is as simple as changing the linkedit 
> characteristic to AC=1 and placing it in an APF-authorized library, then 
> they need to be re-educated (and quickly if they're the one responsible 
> for the implementation).


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

Re: Security exposure of zXXP was Re: zIIP simulation

[Ed Jaffe]

On 11/2/2013 7:34 PM, Peter Relson wrote:
SRBs are the same level of security exposure that APF-authorized tasks 
are. So if an application is already APF-authorized, switching to 
enclave SRBs is not intrinsically more of a security exposure than 
already existed. It is true that SRBs are more likely to tend to be 
key 0 than authorized tasks, but that is not a security exposure. That 
is a "greater potential for screwing up a system due to overlay of 
something critical" exposure. 


And, the good ol' SPKA instruction helps tremendously here...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: Security exposure of zXXP was Re: zIIP simulation

[Peter Relson]

>SRB's are a big security exposure so customers are unlikely to open them 
to their programmers. 

SRBs are the same level of security exposure that APF-authorized tasks 
are. So if an application is already APF-authorized, switching to enclave 
SRBs is not intrinsically more of a security exposure than already 
existed. It is true that SRBs are more likely to tend to be key 0 than 
authorized tasks, but that is not a security exposure. That is a "greater 
potential for screwing up a system due to overlay of something critical" 
exposure.

>Is the code that runs under the ZIP and ZAP
>process code that normally run without any privileges in a problem
>state?

Only if the perpetrator is irresponsible. It is far from unheard of to 
have to take an application written to be unauthorized and make it 
authorized. But if anyone thinks it is as simple as changing the linkedit 
characteristic to AC=1 and placing it in an APF-authorized library, then 
they need to be re-educated (and quickly if they're the one responsible 
for the implementation).

Peter Relson
z/OS Core Technology Design

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

Re: zIIP simulation

[Mark Post]

>>> On 11/1/2013 at 03:37 PM, Jon Perryman  wrote: 
> Since zVM supports zLinux, it makes sense that it allows IFL. Is there a 
> userid option that allows the usage of IFL processors? Or do they use some 
> other method?

That option only applies to so-called "VM Mode" LPARs, where all types of 
specialty engines and CPs can co-exist.  Linux can run on any type of 
processor, but if it's in an LPAR with z/OS, you wouldn't want Linux adding to 
your z/OS software charges, so the z/VM USER DIRECT file was enhanced so that 
you can specify just what types of processors a guest can use.  In a z/VM and 
Linux only LPAR, it's not necessary, since there's only one type of processor 
to dispatch work on.


Mark Post

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

I think zAAP are somehow for Java but I'm not sure. I don't know how they 
restrict their usage. I doubt it is thru an SRB. 

zIIP is supposed to run vendor software. Most are APF authorized anyways so the 
exposure is not any greater. My point was if a customer discovered how to do 
this, they are discouraged from allowing it because their employee's could 
easily write programs to access anything they wanted.  

Jon Perryman.



>
> From: Clark Morris 
>
>
>
>>6. zIIP is first restricted by requiring programs run under an SRB. SRB's are 
>>a big security exposure so customers are unlikely to open them to their 
>>programmers. 
>
>In the process of saving money are z ZIP and ZAP users introducing a
>security exposure?  Is the code that runs under the ZIP and ZAP
>process code that normally run without any privileges in a problem
>state?
>

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

Security exposure of zXXP was Re: zIIP simulation

[Clark Morris]

On 1 Nov 2013 08:44:42 -0700, in bit.listserv.ibm-main you wrote:

>Your code may be the best design possible but it still uses CPU. Redesigning 
>and rewriting code to be more efficient is not the point of zIIP processors. 
>They are simply an IBM sales tool to make the price if z hardware more price 
>competitive. Running code in zIIP is less efficient (code must be run in a 
>special SRB) but it much cheaper to use than the standard CPU.
>
>1. Specialty processors (zIIP, zAAP, IFL and others that IBM may implement) 
>are general CP's. They physically do the same things as a GCP.
>2. Prices for specialty processors are significantly cheaper than a GCP. IBM 
>does not want customers to run everything on them.
>3. To restrict customer usage of specialty processors, IBM must implement some 
>method for restricting the use of a specialty processor.
>4. For IFL (Linux processors), IBM disabled some instructions that are 
>critical to z/OS, zVSE and zVM but never used by zLinux. This keeps customers 
>from assigning IFL's to z/OS because it will fail.
>5. IBM intends zIIP to be used for system related workload (system overhead). 
>From their viewpoint, customers can easily justify paying for application CPU 
>usage. Its far more difficult to justify and portion out system overhead. 
>Customer charge various departments for their CPU usage. System overhead is 
>difficult to portion because of it's nature. Long ago when I was involved in 
>chargeback, we simply portioned database workload because we could not 
>attribute specific amounts to a specific group. With zIIP, this workload 
>becomes far less significant.
>
>6. zIIP is first restricted by requiring programs run under an SRB. SRB's are 
>a big security exposure so customers are unlikely to open them to their 
>programmers. 

In the process of saving money are z ZIP and ZAP users introducing a
security exposure?  Is the code that runs under the ZIP and ZAP
process code that normally run without any privileges in a problem
state?

Clark Morris
>7. To restrict software vendors, the SRB must run in a special enclave. 
>Vendors must sign a non-disclosure agreement about this special enclave. I 
>suspect that IBM includes some sort of usage clause in that agreement.
>
>Jon Perryman  
>
>
>
>>
>> From: Scott Ford 
>>
>>
>>After reading this thread, I understand the need for zIIP processors for 
>>heavy CPU processes, but what about resigning and rewriting these 
>>applications ? For us, who learned assembler or BAL ...we had less to use , 
>>cycle wise and storage, but still managed to develop good code.
>>
>>
>
>--
>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: zIIP simulation

[Wayne Driscoll]

Jon,
CMS and z/VM are fully supported on IFL's.  This is required in order to
run Linux on System z under z/VM, since originally you could not define an
LPAR that had both GCP's and IFL's defined to it.
==
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(at)us(dot)ibm(dot)com
All opinions are mine, and do not represent
IBM Corporation.
==


IBM Mainframe Discussion List  wrote on
11/01/2013 02:37:25 PM:

> From: Jon Perryman 
> To: IBM-MAIN@listserv.ua.edu,
> Date: 11/01/2013 02:37 PM
> Subject: Re: [IBM-MAIN] zIIP simulation
> Sent by: IBM Mainframe Discussion List 
>
> Since zVM supports zLinux, it makes sense that it allows IFL. Is
> there a userid option that allows the usage of IFL processors? Or do
> they use some other method?
>
> Does CMS also use that instruction to ensure it runs on a CP?
>
> Jon Perryman.
>
>
> >
> > From: Mark Post 
> >
> >
> >>>> On 11/1/2013 at 11:44 AM, Jon Perryman  wrote:

> >> 4. For IFL (Linux processors), IBM disabled some instructions that are

> >> critical to z/OS, zVSE and zVM but never used by zLinux.
> >
> >To be precise, IBM disabled a single instruction that they ensured
> z/OS, z/VSE and z/TPF use.  z/VM does not use that instruction, and
> so can run on an IFL without any problems, as well as on a CP.
> >
>
> --
> 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: zIIP simulation

[Jon Perryman]

Since zVM supports zLinux, it makes sense that it allows IFL. Is there a userid 
option that allows the usage of IFL processors? Or do they use some other 
method?

Does CMS also use that instruction to ensure it runs on a CP?

Jon Perryman.


>
> From: Mark Post 
>
>
 On 11/1/2013 at 11:44 AM, Jon Perryman  wrote: 
>> 4. For IFL (Linux processors), IBM disabled some instructions that are 
>> critical to z/OS, zVSE and zVM but never used by zLinux.
>
>To be precise, IBM disabled a single instruction that they ensured z/OS, z/VSE 
>and z/TPF use.  z/VM does not use that instruction, and so can run on an IFL 
>without any problems, as well as on a CP.
>

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

Re: zIIP simulation

[Mark Post]

>>> On 11/1/2013 at 11:44 AM, Jon Perryman  wrote: 
> 4. For IFL (Linux processors), IBM disabled some instructions that are 
> critical to z/OS, zVSE and zVM but never used by zLinux.

To be precise, IBM disabled a single instruction that they ensured z/OS, z/VSE 
and z/TPF use.  z/VM does not use that instruction, and so can run on an IFL 
without any problems, as well as on a CP.


Mark Post

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

Re: zIIP simulation

[Jon Perryman]

Peter is correct.

SRB's are standard. Enclaves are standard. So workload that will run on zIIP 
will also run on a GCP without any change. There is not a requirement to 
execute the code in a TCB. It's up to the vendor.

For customers without zIIP, the SRB/enclave overhead will make the product more 
expensive to run. If this overhead makes the software significantly more 
expensive, then vendors will allow both methods. For other vendors, this may be 
insignificant (e.g. using a single SRB for the life of the product may be 
possible which would eliminate a lot of the overhead).

Jon Perryman.



>
> From: Peter Relson 
>
>
>>I suspect that every product that exploits zIIPs already does this. 
>>Vendors cannot count on zIIPs being installed at customer locations. 
>>If no zIIPs are available, the work must run in TCB mode.  Vendor
>>products can't just terminate if zIIPs aren't available.
>>
>
>I suspect the opposite, since it is not true that "if no zIIPs are 
>available, the work must run in TCB mode". Bob must have been thinking of 
>something else.
>
>Thus you are talking about the products having additional code paths to do 
>things in two different ways, when one way will "work".
>If there is sufficient performance justification for having that 
>additional code, then they likely do have it.
>

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

Re: zIIP simulation

[Jon Perryman]

Your code may be the best design possible but it still uses CPU. Redesigning 
and rewriting code to be more efficient is not the point of zIIP processors. 
They are simply an IBM sales tool to make the price if z hardware more price 
competitive. Running code in zIIP is less efficient (code must be run in a 
special SRB) but it much cheaper to use than the standard CPU.

1. Specialty processors (zIIP, zAAP, IFL and others that IBM may implement) are 
general CP's. They physically do the same things as a GCP.
2. Prices for specialty processors are significantly cheaper than a GCP. IBM 
does not want customers to run everything on them.
3. To restrict customer usage of specialty processors, IBM must implement some 
method for restricting the use of a specialty processor.
4. For IFL (Linux processors), IBM disabled some instructions that are critical 
to z/OS, zVSE and zVM but never used by zLinux. This keeps customers from 
assigning IFL's to z/OS because it will fail.
5. IBM intends zIIP to be used for system related workload (system overhead). 
From their viewpoint, customers can easily justify paying for application CPU 
usage. Its far more difficult to justify and portion out system overhead. 
Customer charge various departments for their CPU usage. System overhead is 
difficult to portion because of it's nature. Long ago when I was involved in 
chargeback, we simply portioned database workload because we could not 
attribute specific amounts to a specific group. With zIIP, this workload 
becomes far less significant.

6. zIIP is first restricted by requiring programs run under an SRB. SRB's are a 
big security exposure so customers are unlikely to open them to their 
programmers. 
7. To restrict software vendors, the SRB must run in a special enclave. Vendors 
must sign a non-disclosure agreement about this special enclave. I suspect that 
IBM includes some sort of usage clause in that agreement.

Jon Perryman  



>
> From: Scott Ford 
>
>
>After reading this thread, I understand the need for zIIP processors for heavy 
>CPU processes, but what about resigning and rewriting these applications ? For 
>us, who learned assembler or BAL ...we had less to use , cycle wise and 
>storage, but still managed to develop good code.
>
>

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

Re: zIIP simulation

[Peter Vander Woude]

I know of at least one of our vendors whose product does not generate the srb's 
that would get dispatched on the zIIP, if it's not there.  However, they will, 
if you ask, take some of the smf data for the sorts and run their analysis of 
those records, and come back with projections based on your sort workload.  At 
least for us, it was very useful.  Unfortunately, we can't get the zIIP on our 
z9 anymore :(

Peter

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

Re: zIIP simulation

[Scott Ford]

After reading this thread, I understand the need for zIIP processors for heavy 
CPU processes, but what about resigning and rewriting these applications ? For 
us, who learned assembler or BAL ...we had less to use , cycle wise and 
storage, but still managed to develop good code.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


> On Nov 1, 2013, at 8:45 AM, David Andrews  wrote:
> 
>> On Fri, 2013-11-01 at 17:00 +1100, Wayne Bickerdike wrote:
>> I believe that CA-Datacom will utilise a zIIP if present.
> 
> As will IDMS.  (We're seeing approximately 50% offload of so-called
> "system mode" time in CV.)
> 
> -- 
> David Andrews
> A. Duda & Sons, Inc.
> david.andr...@duda.com
> 
> --
> 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: zIIP simulation

[Russ Teubner]

I will go on record as being another zIIP-enabled vendor (like those who have 
already opined) for which PROJECTCPU is worthless.  When CICS starts and our 
product initializes, we look to see if a zIIPs are available.  If not, we don't 
worry about marking the enclave SRB as zIIP elidgeble.  If fact, there's an 
option to not even run it under an Enclave SRB.  This approach holds true for 
the following products: HB Base, HB JavaScript Engine, HB Socket Support.  HB 
BPIC (Batch Programs Inside CICS) doesn't exploit zIIP.

Russ Teubner
HostBridge Technology
www.hostbridge.com

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

Re: zIIP simulation

[David Andrews]

On Fri, 2013-11-01 at 17:00 +1100, Wayne Bickerdike wrote:
> I believe that CA-Datacom will utilise a zIIP if present.

As will IDMS.  (We're seeing approximately 50% offload of so-called
"system mode" time in CV.)

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

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

Re: zIIP simulation

[Peter Relson]

>I would expect PROJECTCPU to be pretty accurate as I would expect it to 
>work off when the task is marked zIIP-eligible.

For non-z/OS core code, there is no such thing as a task marked 
zIIP-eligible (ignoring the zAAP on zIIP functionality).

So for products that dual-path "if zIIP available then use them, otherwise 
use tasks", projectCPU will not account for them.
For the purposes of projection accuracy, it would be better if the 
products used "if zIIP available or projectCPU is on then...".
That bit isn't currently a programming interface (SVT_CpuProjection) but 
could be made so.

>For example, time to do 
>"Expensive Work X" reduced by 64% by splitting (using educated 
>"guesstimation") the work up across three dispatchable units, including 
>overhead of startup/takedown of the two additional SRBs 

That would apply whether zIIPs were in use or not (although on a machine 
where offload engines are faster than standard CPs, elapsed time is going 
to be shorter when those faster engines can be used).

Some zIIP protocols leave the SRBs around for future use, so that it's 
less "startup/takedown" than "wakeup/put-to-sleep".

Peter Relson
z/OS Core Technology Design

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

Re: zIIP simulation

[Wayne Bickerdike]

Since it doesn't appear to have been mentioned, IBMs zCP3000 tool is useful
for analyzing if a benefit would derive from using a ZIIP engine.

I ran one for a customer and for a DB2 z/OS workload,the benefit was
apparent on a cost benefit basis.

I believe that CA-Datacom will utilise a zIIP if present.


On Fri, Nov 1, 2013 at 10:47 AM, Al Sherkow  wrote:

> My analysis uses SMF data and is based only on public documentation of the
> SMF data. I have to explain my analysis to customers and clients so
> anything I might know under NDA is not useful in those circumstances.
>
> If some vendor(s), as Ed wrote are using CPU and it is not marked as zXXP
> eligible, then SMF does not show it as eligible either and it is not used
> in my analysis. This could lead to the analysis indicating the zXXP is not
> saving enough $s to make it worthwhile; and this might be the wrong answer,
> but it is the best answer given the data.
>
> The result might be that the analysis shows 1 or more zXXP engines would
> provide value in your environment. Then, if a vendor marks more CPU usage
> as eligible then the zIIP engines may run work not included in the analysis
> and you'll still have eligible work running on GCPs. and as someone wrote
> earlier in this thread not everything eligible runs on the zXXPs, so you'll
> almost always have some eligible work that does not run on zXXPs. In this
> case once the zXXP engine is installed the analysis can be done again, and
> perhaps more adding more zXXPs is still valuable.
>
> My analysis may under-estimate the value of the zXXPs, but so far it has
> not over-estimated the value.
>
> Al
> I/S Management Strategies, Ltd.
> +1 414-332-3062
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: zIIP simulation

[Al Sherkow]

My analysis uses SMF data and is based only on public documentation of the SMF 
data. I have to explain my analysis to customers and clients so anything I 
might know under NDA is not useful in those circumstances. 

If some vendor(s), as Ed wrote are using CPU and it is not marked as zXXP 
eligible, then SMF does not show it as eligible either and it is not used in my 
analysis. This could lead to the analysis indicating the zXXP is not saving 
enough $s to make it worthwhile; and this might be the wrong answer, but it is 
the best answer given the data. 

The result might be that the analysis shows 1 or more zXXP engines would 
provide value in your environment. Then, if a vendor marks more CPU usage as 
eligible then the zIIP engines may run work not included in the analysis and 
you'll still have eligible work running on GCPs. and as someone wrote earlier 
in this thread not everything eligible runs on the zXXPs, so you'll almost 
always have some eligible work that does not run on zXXPs. In this case once 
the zXXP engine is installed the analysis can be done again, and perhaps more 
adding more zXXPs is still valuable. 

My analysis may under-estimate the value of the zXXPs, but so far it has not 
over-estimated the value. 

Al 
I/S Management Strategies, Ltd.
+1 414-332-3062

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

Re: zIIP simulation

[Ed Jaffe]

On 10/31/2013 5:53 AM, Martin Packer wrote:

Ed, do you do some kind of simple "cost to start up vs saving" swag when
deciding whether to do this?


Yes. We are measuring to determine the break even points that work best 
for us and hope they extrapolate to our customers. During ESP, we might 
ask for customer assistance to help optimize these values for bigger 
"iron" than what we own.


The results we have so far are amazing! For example, time to do 
"Expensive Work X" reduced by 64% by splitting (using educated 
"guesstimation") the work up across three dispatchable units, including 
overhead of startup/takedown of the two additional SRBs.


Moore's Law Be Damned!! :)

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: zIIP simulation

[Mike Schwab]

On Thu, Oct 31, 2013 at 8:02 AM, Shane Ginnane  wrote:

> Not denigrating anybodies efforts, merely seeking some clarity in a field 
> left deliberately murky by the major vendor.
>
They will give you the details.  After you sign a non-disclosure
agreement and write a check.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: zIIP simulation

[Martin Packer]

I would expect PROJECTCPU to be pretty accurate as I would expect it to 
work off when the task is marked zIIP-eligible. Certainly the numbers I've 
seen for zIIP- (and zAAP-) eligible CPU have "behaved" reasonably.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Bob Shannon 
To: IBM-MAIN@listserv.ua.edu
Date:   31/10/2013 13:41
Subject:    Re: zIIP simulation
Sent by:IBM Mainframe Discussion List 



>So now we approach the nub of the matter (for us non-illuminated peons).

>how does code indicate it is "zIIP capable" ?
When a pre-emptible SRB is created a "secret handshake"  (an API) is used 
to make it eligible to be dispatched on a zIIP; if the work is not zIIP 
eligible or if there are no zIIPs available the work is dispatched on a 
CP. The documentation to use the API is available to ISVs who sign an NDA. 
It is not publically available.

>what if it is running as a TCB in a non-zIIP enabled machine ?.
I think this question is based on my misstatement. zIIP-eligible work does 
not run in TCB mode when a zIIP isn’t available so as far as zIIP usage is 
concerned this question is a  non sequitur.   Sorry for the confusion.

> how far can we (aforementioned peons) trust the numbers from PROJECTCPU 
and Als offering in such situations ?.
No idea. I'm sure Al can explain.

Bob Shannon
Rocket Software

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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: zIIP simulation

[Shane Ginnane]

Thanks again Bob - the second part of my questioning was aimed at the situation 
Ed mentioned. I was hoping for some indication in the TCB that might assist in 
PROJECTCPU calculations if a TCB was explicitly chosen in a non-zIIP 
environment.
I did check the mapping but didn't find anything overtly useful. But, I don't 
(never had) access to the ISV doco, so was hoping something undocumented might 
be in play.

Al ?.

Shane ...

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

Re: zIIP simulation

[Bob Shannon]

>So now we approach the nub of the matter (for us non-illuminated peons).

>how does code indicate it is "zIIP capable" ?
When a pre-emptible SRB is created a "secret handshake"  (an API) is used to 
make it eligible to be dispatched on a zIIP; if the work is not zIIP eligible 
or if there are no zIIPs available the work is dispatched on a CP. The 
documentation to use the API is available to ISVs who sign an NDA. It is not 
publically available.

>what if it is running as a TCB in a non-zIIP enabled machine ?.
I think this question is based on my misstatement. zIIP-eligible work does not 
run in TCB mode when a zIIP isn’t available so as far as zIIP usage is 
concerned this question is a  non sequitur.   Sorry for the confusion.

> how far can we (aforementioned peons) trust the numbers from PROJECTCPU and 
> Als offering in such situations ?.
No idea. I'm sure Al can explain.

Bob Shannon
Rocket Software

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

Re: zIIP simulation

[Shane Ginnane]

On Thu, 31 Oct 2013 07:41:00 -0400, Peter Relson wrote:

>I suspect the opposite, since it is not true that "if no zIIPs are
>available, the work must run in TCB mode".

So now we approach the nub of the matter (for us non-illuminated peons).
- how does code indicate it is "zIIP capable" ?
- what if it is running as a TCB in a non-zIIP enabled machine ?.
- how far can we (aforementioned peons) trust the numbers from PROJECTCPU and 
Als offering in such situations ?.

Not denigrating anybodies efforts, merely seeking some clarity in a field left 
deliberately murky by the major vendor.

Shane ...

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

Re: zIIP simulation

[Martin Packer]

Ed, do you do some kind of simple "cost to start up vs saving" swag when 
deciding whether to do this?

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Ed Jaffe 
To: IBM-MAIN@listserv.ua.edu
Date:   31/10/2013 05:33
Subject:    Re: zIIP simulation
Sent by:IBM Mainframe Discussion List 



On 10/30/2013 6:55 PM, Al Sherkow wrote:
> Yes, I too have heard of one vendor that checks to see if a zIIP is 
available and if not does not setup for the zIIP. So for this vendor and 
their software that would use a zIIP they are not included in the eligible 
time and hence not in any analysis of the eligible time.

If that vendor is not Phoenix Software, then there are at least two that 
do this... TCBs when no zIIPs are present and Enclave SRBs when at least 
one zIIP is present.

However, we are adding some new highly-parallel, SRB-mode-only 
algorithms to the parts of our code that are the highest CPU consumers 
that might cause us to reconsider this bifurcation.

-- 
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: zIIP simulation

[Bob Shannon]

> I suspect the opposite, since it is not true that "if no zIIPs are available, 
> the work must run in TCB mode". Bob must have been thinking of something else.

That is correct. I zoned out.

Bob

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

Re: zIIP simulation

[Peter Relson]

>I suspect that every product that exploits zIIPs already does this. 
>Vendors cannot count on zIIPs being installed at customer locations. 
>If no zIIPs are available, the work must run in TCB mode.  Vendor
>products can't just terminate if zIIPs aren't available.
>

I suspect the opposite, since it is not true that "if no zIIPs are 
available, the work must run in TCB mode". Bob must have been thinking of 
something else.

Thus you are talking about the products having additional code paths to do 
things in two different ways, when one way will "work".
If there is sufficient performance justification for having that 
additional code, then they likely do have it.

Peter Relson
z/OS Core Technology Design

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

Re: zIIP simulation

[Ed Jaffe]

On 10/30/2013 6:55 PM, Al Sherkow wrote:

Yes, I too have heard of one vendor that checks to see if a zIIP is available 
and if not does not setup for the zIIP. So for this vendor and their software 
that would use a zIIP they are not included in the eligible time and hence not 
in any analysis of the eligible time.


If that vendor is not Phoenix Software, then there are at least two that 
do this... TCBs when no zIIPs are present and Enclave SRBs when at least 
one zIIP is present.


However, we are adding some new highly-parallel, SRB-mode-only 
algorithms to the parts of our code that are the highest CPU consumers 
that might cause us to reconsider this bifurcation.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: zIIP simulation

[Al Sherkow]

Yes, I too have heard of one vendor that checks to see if a zIIP is available 
and if not does not setup for the zIIP. So for this vendor and their software 
that would use a zIIP they are not included in the eligible time and hence not 
in any analysis of the eligible time. 

Since a couple of references have been made to my tools let me jump in. The way 
I tackle this in LCS is to analyze the eligible time and then simulate or model 
moving a portion of it to the zIIP processors. The site controls how much is 
moved via parameters. After the work is moved to the zIIP the maximum 
simultaneous four-hour rolling averages (S4HRA) are recalculated and then the 
software charges are estimated. You could move a lot of work to the zIIP but if 
it does not lower the maximum S4HRA that your IBM MLC charges are based on you 
are not saving money. You cannot analyze just a week, you need to study entire 
months. (The weird months that begin on the 2nd and end on the 1st). 

LCS reporting also includes analysis of what your bill would be without any 
zXXP engines when you do have them. This shows the value the zXXPs are 
providing month after month. 

Al Sherkow, I/S Management Strategies, Ltd.
Consulting Expertise on IBM Workload License Charges (WLC)
+1 414 332-3062

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

Re: zIIP simulation

[Ed Jaffe]

On 10/30/2013 5:37 AM, Shane Ginnane wrote:
Anyone ever figured out why IBM (still) doesn't allow all of the 
eligible workload to be dispatched on the zIIP ?


$$

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
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: zIIP simulation

[Martin Packer]

It's better than that: If there is no zIIP (or zAAP) the work runs just 
fine on a GCP. And RMF reports this as zIIP-eligible (or zAAP-eligible) 
and it comes out of the GCP headline numbers.

I think there's at least one vendor that does check for a specialty engine 
and explicitly takes advantage of it if present - but they'll have to 
speak for themselves. I seem to recall their logic was that setting up for 
a zIIP isn't free so it's worth not trying if it's going to end up on a 
GCP.

(And thanks to Tim for reinforcing my point.)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Bob Shannon 
To: IBM-MAIN@listserv.ua.edu
Date:   30/10/2013 11:40
Subject:Re: zIIP simulation
Sent by:IBM Mainframe Discussion List 



>That's one aspect - another that has been itching me as I also keep an 
eye on these potential savings is:
>"is there any software out there that is smart enough to recognise the 
presence (absence) of zIIP and alter the entity created for dispatch to 
match the environment". So, no zIIP, so we see a TCB/SRB - thus no 
>projected saving. *IF* we had a zIIP, maybe the "smarts" creates an 
interruptible SRB and we get actual savings. Yeah, I know, about as likely 
as

I suspect that every product that exploits zIIPs already does this. 
Vendors cannot count on zIIPs being installed at customer locations.  If 
no zIIPs are available, the work must run in TCB mode.  Vendor products 
can't just terminate if zIIPs aren't available.

Bob Shannon
Rocket Software

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


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: zIIP simulation

[Shane Ginnane]

Bob Shannon wrote:

>  I suspect that every product that exploits zIIPs already does this. Vendors 
> cannot count on zIIPs being installed at customer locations.
>  If no zIIPs are available, the work must run in TCB mode. 
(redacted due to web-mailer issues again)

Thanks Bob.
I have a z114 customer that is *very* marginal on a zIIP purchase. They need 
all the evidence they can get - especially as some of the current DDF workload 
may be going away - along with along with it's (zIIP) justification.
Anyone ever figured out why IBM (still) doesn't allow all of the eligible 
workload to be dispatched on the zIIP ?.

Shane ...

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

Re: zIIP simulation

[John Gilmore]

Bob Shannon wrote:


I suspect that every product that exploits zIIPs already does this.
Vendors cannot count on zIIPs being installed at customer locations.
If no zIIPs are available, the work must run in TCB mode.  Vendor
products can't just terminate if zIIPs aren't available.


and he is clearly right about this.

Shane's point can, however, be turned around.  zIIPs have been with us
for some time now;  and I can think offhand of quite a lot of both IBM
and ISV software that does not use them where it could do so
[licitly], perhaps because two paths are|were deemed too onerous.

John Gilmore, Ashland, MA 01721 - USA

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

Re: zIIP simulation

[Elardus Engelbrecht]

Shane Ginnane wrote:

>Sorry - "TCB/SRB".
>Shouldn't  type whilst watching the World Series game from last night.

With or without beer? ;-)

World Series can really gets your attention, so much you can't multitask! ;-)

One way to watch those attention-grabbers during office hours is: some of my 
colleagues obtained a small receiver from a pay TV company. You hook it up to 
your laptop USB port and you can then watch any live sport events on one of 
your laptop's screens. That is multitasking at its best! ;-)

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: zIIP simulation

[Bob Shannon]

>That's one aspect - another that has been itching me as I also keep an eye on 
>these potential savings is:
>"is there any software out there that is smart enough to recognise the 
>presence (absence) of zIIP and alter the entity created for dispatch to match 
>the environment". So, no zIIP, so we see a TCB/SRB - thus no >projected 
>saving. *IF* we had a zIIP, maybe the "smarts" creates an interruptible SRB 
>and we get actual savings. Yeah, I know, about as likely as

I suspect that every product that exploits zIIPs already does this. Vendors 
cannot count on zIIPs being installed at customer locations.  If no zIIPs are 
available, the work must run in TCB mode.  Vendor products can't just terminate 
if zIIPs aren't available.

Bob Shannon
Rocket Software

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

Re: zIIP simulation

[Shane Ginnane]

Erk - I wrote:

> ...so we see a [TS]CB - thus no projected saving.

Sorry - "TCB/SRB".
Shouldn't  type whilst watching the World Series game from last night.

Shane ...

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

Re: zIIP simulation

[Shane Ginnane]

On Tue, 29 Oct 2013 14:00:59 +, Martin Packer wrote:

>The standard caution is "if you're not already running the workload it
>won't show up through PROJECTCPU". A good example of this might be IPSec.

That's one aspect - another that has been itching me as I also keep an eye on 
these potential savings is:
"is there any software out there that is smart enough to recognise the presence 
(absence) of zIIP and alter the entity created for dispatch to match the 
environment". So, no zIIP, so we see a [TS]CB - thus no projected saving.
*IF* we had a zIIP, maybe the "smarts" creates an interruptible SRB and we get 
actual savings. Yeah, I know, about as likely as ...

Shane ...

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

Re: zIIP simulation

[Timothy Sipples]

I want to echo something Martin Packer wrote that's really very important,
and it also applies to the IBM DB2 Analytics Accelerator and many other
technologies.

Yes, you can very accurately project how much of your current z/OS-hosted
workload will benefit from a zIIP. A far more interesting question is what
workloads are you NOT currently running on your z/OS machine that really
ought to be running on z/OS machine (and that could benefit from the zIIP,
IDAA, new Java runtime, etc.) That takes a little more analysis, but it's
very, very important to do it and do it well.

If the totality of your platform selection policy for workloads consists of
something like the two words "MIPS bad," then you're really going to screw
things up, probably very badly.


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: zIIP simulation

[R.S.]

W dniu 2013-10-29 14:32, גדי בן אבי pisze:

Hi everyone,
Does anyone know of a tool that will help us decide if we benefit from adding a 
zIIP engine to our system?



One of the methods not mentione here is to get zIIP for evaluation.
Yes, it is possible to activate zIIP for a period of time - a month.
Of course your IBM sales rep should want it.

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osb trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc 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
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorcw KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: zIIP simulation

[Martin Packer]

The standard caution is "if you're not already running the workload it 
won't show up through PROJECTCPU". A good example of this might be IPSec. 
Not to suggest the benefit is "a partir de" too strongly as a recognised 
IBM marketeer. :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Lizette Koehler 
To: IBM-MAIN@listserv.ua.edu
Date:   29/10/2013 13:54
Subject:Re: zIIP simulation
Sent by:IBM Mainframe Discussion List 



It will depend on your workload.  More and more functions on the Mainframe
are using zIIP engines.  However, they are not always documented.
PROJECTCPU will help you see if a zIIP might be useful.  This Techdoc is
helpful for PROJECTCPU

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103548



Do you use DFSORT
DB2
IMS
JAVA
CICS

And so forth.

I agree that Al Sherkow (a...@sherkow.com) about LCS maybe your best option.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ??? ?? ???
> Sent: Tuesday, October 29, 2013 6:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: zIIP simulation
> 
> Hi everyone,
> Does anyone know of a tool that will help us decide if we benefit from
adding a zIIP
> engine to our system?
> 
> Thanks
> 
> Gadi
> 

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: zIIP simulation

[Lizette Koehler]

It will depend on your workload.  More and more functions on the Mainframe
are using zIIP engines.  However, they are not always documented.
PROJECTCPU will help you see if a zIIP might be useful.  This Techdoc is
helpful for PROJECTCPU

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103548



Do you use DFSORT
DB2
IMS
JAVA
CICS

And so forth.

I agree that Al Sherkow (a...@sherkow.com) about LCS maybe your best option.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of ??? ?? ???
> Sent: Tuesday, October 29, 2013 6:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: zIIP simulation
> 
> Hi everyone,
> Does anyone know of a tool that will help us decide if we benefit from
adding a zIIP
> engine to our system?
> 
> Thanks
> 
> Gadi
> 

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

Re: zIIP simulation

[Richards, Robert B.]

Gadi,

If you are looking for the $$$ savings that would be achieved by acquiring one 
or more zIIPs, then I strongly suggest you contact Al Sherkow 
(a...@sherkow.com) about LCS. I and others have cost-justified both the LCS and 
zIIP acquisition costs due to the savings achieved. As usual, YMMV.

Bob


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, October 29, 2013 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zIIP simulation

Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2w1b0/20.2



The SYS1.PARMLIB member IEAOPTxx provides statement PROJECTCPU. Specifying the 
PROJECTCPU parameter allows you to project *zIIP* (and zAAP) consumptionwhen a
*zIIP* (or zAAP) processor is not yet defined to the configuration. RMF and SMF 
will show the potential calculated *zIIP* time, so that an accurate *
zIIP* projection can be made. The PROJECTCPU option can be used while running 
the target workload, once all software is installed that enables hardware 
sizing data to be produced.

You can use the DISPLAY M=CPU command to show if a *zIIP* processor is defined 
in the configuration. (In the D M=CPU command output zIIPs are represented by 
the letter "I"). A *zIIP* processor is considered to be defined in the offline 
or reserved state, as well as in the online state.

Refer to *MVS* *Initialization* *and* *Tuning* *Reference* for more information 
on the parmlib member IEAOPTxx.

The SMF type 30 record (IFASMFR3) includes *zIIP* consumption fields. Refer to 
*z/OS* *MVS* *System* *Management* *Facilities* *(SMF)* for further information.

The TIMEUSED macro allows *zIIP* execution time to be requested in addition to 
the standard CP consumption.




2013/10/29 גדי בן אבי 

> Hi everyone,
> Does anyone know of a tool that will help us decide if we benefit from 
> adding a zIIP engine to our system?
>
> Thanks
>
> Gadi
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או 
> מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, 
> הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך 
> כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום 
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no 
> offer, agreement, concession or representation is binding on the 
> company, unless accompanied by a duly signed separate document (or a 
> scanned version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
This is clearly another case of too many mad scientists, and not enough 
hunchbacks.

Maranatha! <><
John McKown

--
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: zIIP simulation

[John McKown]

Ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2w1b0/20.2



The SYS1.PARMLIB member IEAOPTxx provides statement PROJECTCPU. Specifying the
PROJECTCPU parameter allows you to project *zIIP* (and zAAP) consumptionwhen a
*zIIP* (or zAAP) processor is not yet defined to the configuration. RMF and
SMF will show the potential calculated *zIIP* time, so that an accurate *
zIIP* projection can be made. The PROJECTCPU option can be used while
running the target workload, once all software is installed that enables
hardware sizing data to be produced.

You can use the DISPLAY M=CPU command to show if a *zIIP* processor is
defined in the configuration. (In the D M=CPU command output zIIPs are
represented by the letter "I"). A *zIIP* processor is considered to be
defined in the offline or reserved state, as well as in the online state.

Refer to *MVS* *Initialization* *and* *Tuning* *Reference* for more
information on the parmlib member IEAOPTxx.

The SMF type 30 record (IFASMFR3) includes *zIIP* consumption fields. Refer
to *z/OS* *MVS* *System* *Management* *Facilities* *(SMF)* for further
information.

The TIMEUSED macro allows *zIIP* execution time to be requested in addition
to the standard CP consumption.




2013/10/29 גדי בן אבי 

> Hi everyone,
> Does anyone know of a tool that will help us decide if we benefit from
> adding a zIIP engine to our system?
>
> Thanks
>
> Gadi
>
> 
> לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג
> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את
> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון,
> ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
>
> Please note that in accordance with Malam's signatory rights, no offer,
> agreement, concession or representation is binding on the company,
> unless accompanied by a duly signed separate document (or a scanned
> version thereof), affixed with the company's seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

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

zIIP simulation

[גדי בן אבי]

Hi everyone,
Does anyone know of a tool that will help us decide if we benefit from adding a 
zIIP engine to our system?

Thanks

Gadi


לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם 
החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו 
החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) 
המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון,
ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


Please note that in accordance with Malam's signatory rights, no offer, 
agreement, concession or representation is binding on the company,
unless accompanied by a duly signed separate document (or a scanned version 
thereof), affixed with the company's seal.

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