zAAP was supported beginning with z/OS V1R6.
You are absolutely correct that there is no difference at all between the
engines; they are simply Processor Units (PUs) that are defined as Central
Processors or Special Processors. You are slightly out of sync with the
comment that an engine is defined at IML time. Actually, it is PR/SM that
defines the characteristics of the engine when PR/SM dispatches an LPAR's
logical processor to a Special Processor.
Shared Central Processors are managed by PR/SM as a collection of Processor
Units in the "Pool 1" pool of processors. IFL, ICF, and IFA (zAAP)
Processor Units are defined as special processors. What is important is
how these special processors are managed by PR/SM.
Until z9 109, all shared special processors were managed collectively by
PR/SM in the "Pool 2" pool of processors. There is absolutely nothing
different among the individual physical special processors in the "Pool 2"
pool. When PR/SM dispatches an LPAR logical processor to one of the
special processors, it issues the SIE instruction pointing to the HSA
associated with the logical processor assigned to the LPAR. After the SIE
instruction has completed, the physical special processor "thinks" it is an
ICF, IFL, or IFA running the logical processor for the LPAR. In case of
an IFA (zAAP), the special processor cannot IPL, handle I/O interrupts,
etc. because of settings in the HSA.
One advantage or disadvantage (depending on your view) of this "Pool 2"
approach with z890 and z990 is that multiple special processors could be
purchased in a CPC. If these special processors were shared, they would be
shared as a composite resource regardless of what processor type was
purchased. The LPAR weights would be summed for LPARs using the "Pool 2"
special processors, and the distribution of the composite resource would be
based on standard PR/SM rules. This means that an IFL and IFA could be
purchased, defined as shared, and the two special processors could be used
collectively based on weights assigned to multiple LPARs. That is, you
could define multiple LPARs to use collectively more than 100% of an IFA
(for example) and you could actually use more than the single IFA that was
purchased if a shared IFL was defined to PR/SM. Alternatively, you could
encounter the situation where multiple LPARs could be defined using a
shared IFL and the Linux LPARs could use the IFA. My view is that this
provides a tremendous opportunity for users who know how to take advantage
of this situation.
Sadly, IBM "corrected" this opportunity with z9 109 by changing PR/SM to
manage each special processor type in its own pool (i.e., "ICF Pool," "IFL
Pool," and "IFA Pool").
Regards,
Don
******
Don Deese, Computer Management Sciences, Inc.
Voice: (703) 922-7027 Fax: (703) 922-7305
http://www.cpexpert.org
******
At 05:12 PM 1/18/2006, you wrote:
|
> Depends on what you mean by a "real" difference. z/OS uses at least
one
> instruction which is not implemented on an IFL as it is on a GP
> processor. That's why you will get a "check stop" condition if you IPL
> z/OS in an LPAR which is defined as using an IFL.
> But I will admit that I don't know exactly how different a zAAP is
from
> a GCP. I just remember that some things will NOT work on a zAAP. I
> thought it was supervisory instructions and some types of interrupts.
Let's be clear - there is no difference AT ALL between the engines.
Every engine on the die can execute any instruction defined in the
architecture.
However, they each have a particular "personality" which is set at IML
time and that limits the set of instructions the engine is willing to
execute.
z/OS can't IPL on an IFL because the IFL knows "I'm an IFL today". In
other respects it's just another engine as you would expect, given you
can run another full function operating system (Linux) on it.
zAAP engines are a slightly different specialization. They are not
visible in the normal scheme of things and they can't field (I/O)
interrupts.
> I agree that a problem program should see no differences.
A problem program can't even "see" the zAAP. A supervisor state program
can discover information about the zAAP, but it can't legally run
anything on it. I doubt there's anyone lunatic enough out there to try
it.
> I was always curious if I could figure out a way to "cheat" to run
COBOL on a zAAP somehow. But I don't
> have a zAAP to mess around with.
Nope. The only way a zAAP gets to do any work at all is that the z/OS
dispatcher knows a zAAP is there. The dispatcher recognizes JVM work
and, if a zAAP is available, automatically dispatches that work on the
zAAP. But getting it going on the zAAP isn't exactly "free". That's
considered ok because JAVA work is typically going to crank for a
(relatively) long time.
> And I don't run z/OS 1.7 either (isn't that were zAAPs are first
supported?)
No. They have been around for a while. At least since 1.6, and maybe
even earlier. I don't remember for sure. Someone else will no doubt
chime in.
On your question of whether you could run an SRB on a zAAP;
SRBs are intended to be for very short running work that is in and out
and gone. They have been perverted into more long running things (e.g.
DB2) over the years, but the overhead of getting dispatched on a zAAP
would tend to limit the value of running a normal SRB on a zAAP - unless
the system knew ahead of time that the SRB was going to run for a while
- which of course it doesn't.
In theory if the dispatcher was willing to do it there is no reason SRB
work could not be dispatched on a zAAP, but it would be subject to the
same limitations as the JVM. In practice, the current JVM couldn't run
in SRB mode without some major surgery and there would not be any good
reason to do that. So you won't see an SRB running on a zAAP any time
soon.
CC
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.375 / Virus Database: 267.14.20/233 - Release Date: 1/18/2006
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
