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