STFLE instruction.
patmolhant
Dec 9, 2009
Hello, I tried the Store facility list extended (STFLE) instruction to see
what
features we get reported by Hercules compared to what we get when running on a
Z10 engine and saw that whatever CPU type we define in the Hercules config file,
we always get the following data :
F160FEFB F0700000
This indicates that bit 44 is off.
The Principle of operations tells that bit 44 matches feature :
The PFPO instruction is installed in the z/Architecture architectural mode.
Do Hercules support this instruction ?
.
A second question ... The Prefetch data instruction (PFD X'E3....36' results in
an operation exception. Is there a plan to support this type of instruction ?
Regards,
Pat
1:52 pm
Re: STFLE instruction.
dekel35
Dec 9, 2009
see Message #58655, #58658. I believe this instruction is not correctly
implemented in Hercules.
When in S390 mode it does not report any capability of z10 features. On a real
machine this is different (i.e., the fact that we are in s390 mode does not make
the machine incapable of turning into a full Z).
Jacob.
http://www.mvsdasd.org
--- In hercules-390@yahoogroups.com, "patmolhant" <patmolhant@...> wrote:
>
> Hello, I tried the Store facility list extended (STFLE) instruction to see
what features we get reported by Hercules compared to what we get when running
on a Z10 engine and saw that whatever CPU type we define in the Hercules config
file, we always get the following data :
> F160FEFB F0700000
> This indicates that bit 44 is off.
> The Principle of operations tells that bit 44 matches feature :
> The PFPO instruction is installed in the z/Architecture architectural mode.
> Do Hercules support this instruction ?
> .
> A second question ... The Prefetch data instruction (PFD X'E3....36' results
in an operation exception. Is there a plan to support this type of instruction ?
> Regards,
> Pat
>
2:38 pm
Re: STFLE instruction.
Martin Trbner
Dec 9, 2009
Jacob,
How can I get these message numbers you are using... I like to read the
cited messages.
anyway...
> When in S390 mode it does not report any capability of z10 features.
When it gets realy close to the iron, it sometimes is confusing- I am
running a z/box that claims that it is a 4361 (all because the op-sys I
am running on it, handles this box a little bit different: makes
automation in my environment easier).
I would experiment with model-numbers. Maybe you get a different
behaviour with different models.
> On a real machine this is different.
Define real machine. A real z800 may be totaly different to a z10.
> (i.e., the fact that we are in s390 mode does not make the machine
> incapable of turning into a full Z)
Not true for a FLEX (and maybe others).
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
3:09 pm
Re: STFLE instruction.
dekel35
Dec 9, 2009
--- In hercules-390@yahoogroups.com, Martin Trbner <Martin@...> wrote:
>
> Jacob,
>
> How can I get these message numbers you are using... I like to read the
> cited messages.
See dan's reply above.
> Define real machine. A real z800 may be totaly different to a z10.
A machine created by IBM or one that attempts to be 100% compatible. If it is an
emulation of a z10 it should do what a z10 does (including stfle). In this case
Hercules is emulating a z10, but when run in s390 mode it claims to have no z10
capabilities (not even z800!). This is not what a "real" z10 does.
Jacob.
4:00 pm
Re: STFLE instruction.
Ivan Warren
Dec 9, 2009
dekel35 wrote:
>
>
> A machine created by IBM or one that attempts to be 100% compatible. If it is
an emulation of a z10 it should do what a z10 does (including stfle). In this
case Hercules is emulating a z10, but when run in s390 mode it claims to have no
z10 capabilities (not even z800!). This is not what a "real" z10 does.
>
Actually, the z/POP book is specific : (Page 4.66 :)
A bit is set to one regardless of the current architectural
mode if its meaning is true. A meaning applies
to the current architectural mode unless it is said to
apply to a specific architectural mode.
This slightly cryptic note is two fold and a bit misleading because it
MAY seem contradictory - since it all revolves around how you interpret
the words "meaning applies" in the second sentence! but I believe the
meaning is :
- That the feature is either installed (sentence 1 applies)
- That the feature is available (sentence 2 applies)
My "interpretation" is :
Those bits which indicate that a facility is "installed" should be set
to 1 regardless of the current architecture mode.
Those bits which indicate a facility is available should be set only if
the facility is available in the current architecture mode (basically
like byte 0 bit 2 which indicates z/Arch mode is active!).
I believe you are therefore perfectly correct in your assumption since
we are obviously contradictory to the very 1st sentence of the note.
Implementing this should actually be quite trivial !
An another question :
To PAT : PREFETCH DATA and PREFETCH DATA RELATIVE LONG are already
implemented. (E3XXXXXXXX36) and (C6X2XXXXXXXX). The General Instruction
Extension Facility has been implemented since March/April 2008.
--Ivan
[Non-text portions of this message have been removed]
5:19 pm
Re: STFLE instruction.
Roger Bowler
Dec 9, 2009
dekel35 wrote:
> A machine created by IBM or one that attempts to be 100% compatible. If
> it is an emulation of a z10 it should do what a z10 does (including
> stfle). In this case Hercules is emulating a z10, but when run in s390
> mode it claims to have no z10 capabilities (not even z800!). This is not
> what a "real" z10 does.
Jacob,
While I see the point you are making, my view is that Hercules does not and
should not attempt to clone, emulate, or mimic any particular IBM machine.
The definition of Hercules is "a low-cost platform capable of running
mainframe software". So long as Hercules conforms to the principles of
operation manual, it is free to decide what optional features it supports
in each architectural mode.
A case could be made that an instance of Hercules started with ARCHMODE
ESA/390 in the configuration file is a different machine from a Hercules
with ARCHMODE ESAME. So to me it's OK for an ARCHMODE ESA/390 instance
(which cannot be switched into ESAME mode) to present different features
from an ARCHMODE ESAME instance which is currently running in ESA/390 mode.
Regards,
Roger Bowler
http://perso.wanadoo.fr/rbowler
Hercules "the people's mainframe"
6:08 pm
Re: STFLE instruction.
dekel35
Dec 9, 2009
--- In hercules-390@yahoogroups.com, Roger Bowler <rogerbowler@...> wrote:
>
> A case could be made that an instance of Hercules started with ARCHMODE
> ESA/390 in the configuration file is a different machine from a Hercules
> with ARCHMODE ESAME. So to me it's OK for an ARCHMODE ESA/390 instance
> (which cannot be switched into ESAME mode) to present different features
> from an ARCHMODE ESAME instance which is currently running in ESA/390 mode.
Exactly. What seems to happen is that during compilation time, at least two
store_facility_list_extended routines are created (as they should):
1. s390_store_facility_list_extended
2. z900_store_facility_list_extended
If Hercules is emulating an ESAME machine in s390 mode, one might think it
should call the second routine. Currently it calls the first.
I agree that it might be an IBM/Linux bug. I remember at least one case where
there was an OS bug which in turn relied on a hardware bug (Hercules was
actually a "reference machine" in that case !).
It would be interesting to watch how this develops.
Jacob.
7:50 pm
Re: STFLE instruction.
Roger Bowler
Dec 9, 2009
dekel35 wrote:
> What seems to happen is that during compilation time, at least two
> store_facility_list_extended routines are created (as they should):
> 1. s390_store_facility_list_extended
> 2. z900_store_facility_list_extended
>
> If Hercules is emulating an ESAME machine in s390 mode, one might
> think it should call the second routine. Currently it calls the first.
I tend to agree with you, except that bit 2 must be zero when operating in
ESA/390 mode. ISTR there is some wording in the z/Arch POP manual which
supports this theory. Here it is:
"A bit is set to one regardless of the current architectural mode if its
meaning is true. A meaning applies to the current architectural mode unless
it is said to apply to a specific architectural mode."
Is this actually causing a problem for some zLinux distributions?
--
Cordialement,
Roger Bowler
http://perso.wanadoo.fr/rbowler
Hercules "the people's mainframe"
9:44 pm
Re: STFLE instruction.
Harold Grovesteen
Dec 11, 2009
Ivan Warren wrote:
<snip>
>I believe you are therefore perfectly correct in your assumption since
>we are obviously contradictory to the very 1st sentence of the note.
>
>Implementing this should actually be quite trivial !
>
Ivan, I have time today and on the weekend, I will fix it. You are
right, it is trivial. Let me know, if you are already pursuing this. No
need for clashes.
>
>
>
11:37 am
Re: STFLE instruction.
Dan Hork
Dec 11, 2009
Harold Grovesteen píše v Pá 11. 12. 2009 v 05:37 -0600:
>
> Ivan Warren wrote:
>
> <snip>
>
> >I believe you are therefore perfectly correct in your assumption since
> >we are obviously contradictory to the very 1st sentence of the note.
> >
> >Implementing this should actually be quite trivial !
> >
> Ivan, I have time today and on the weekend, I will fix it. You are
> right, it is trivial. Let me know, if you are already pursuing this. No
> need for clashes.
and if any of you will have the fix, please let me know and I will test
the Linux kernel ASAP
Dan
2:51 pm
Re: STFLE instruction.
Harold Grovesteen
Dec 11, 2009
Dan Horák wrote:
>Harold Grovesteen píše v Pá 11. 12. 2009 v 05:37 -0600:
>
>
>>Ivan Warren wrote:
>>
>><snip>
>>
>>
>>
>>>I believe you are therefore perfectly correct in your assumption since
>>>we are obviously contradictory to the very 1st sentence of the note.
>>>
>>>Implementing this should actually be quite trivial !
>>>
>>>
>>>
>>Ivan, I have time today and on the weekend, I will fix it. You are
>>right, it is trivial. Let me know, if you are already pursuing this. No
>>need for clashes.
>>
>>
>
>and if any of you will have the fix, please let me know and I will test
>the Linux kernel ASAP
>
Dan, I have the coding changes done and am now starting to test. When I
have the testing completed and the change committed to the SVN
repository I will let you know here. Trivial in concept, but it turned
out to be a bit less trivial in practice. Don't they always?
>
>
>Dan
>
>
>
>
>
>
4:37 pm
Re: STFLE instruction.
Harold Grovesteen
Dec 12, 2009
Harold Grovesteen wrote:
>Dan Horák wrote:
>
>
>
>>Harold Grovesteen píše v Pá 11. 12. 2009 v 05:37 -0600:
>>
>>
>>
>>
>>>Ivan Warren wrote:
>>>
>>><snip>
>>>
>>>
>>>
>>>
>>>
>>>>I believe you are therefore perfectly correct in your assumption since
>>>>we are obviously contradictory to the very 1st sentence of the note.
>>>>
>>>>Implementing this should actually be quite trivial !
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Ivan, I have time today and on the weekend, I will fix it. You are
>>>right, it is trivial. Let me know, if you are already pursuing this. No
>>>need for clashes.
>>>
>>>
>>>
>>>
>>and if any of you will have the fix, please let me know and I will test
>>the Linux kernel ASAP
>>
>>
>>
>Dan, I have the coding changes done and am now starting to test. When I
>have the testing completed and the change committed to the SVN
>repository I will let you know here. Trivial in concept, but it turned
>out to be a bit less trivial in practice. Don't they always?
>
>
>
>>Dan
>>
>>
>>
I have completed what I think are the changes needed to resolve this
with rev 5542.
Dan, please test and let me know the results.
Thanks,
Harold Grovesteen
7:16 pm
Re: STFLE instruction.
Dan Hork
Dec 12, 2009
Harold Grovesteen píše v So 12. 12. 2009 v 13:16 -0600:
>
> Harold Grovesteen wrote:
>
> >Dan Horák wrote:
> >
> >
> >
> >>Harold Grovesteen píše v Pá 11. 12. 2009 v 05:37 -0600:
> >>
> >>
> >>
> >>
> >>>Ivan Warren wrote:
> >>>
> >>><snip>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>I believe you are therefore perfectly correct in your assumption since
> >>>>we are obviously contradictory to the very 1st sentence of the note.
> >>>>
> >>>>Implementing this should actually be quite trivial !
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Ivan, I have time today and on the weekend, I will fix it. You are
> >>>right, it is trivial. Let me know, if you are already pursuing this. No
> >>>need for clashes.
> >>>
> >>>
> >>>
> >>>
> >>and if any of you will have the fix, please let me know and I will test
> >>the Linux kernel ASAP
> >>
> >>
> >>
> >Dan, I have the coding changes done and am now starting to test. When I
> >have the testing completed and the change committed to the SVN
> >repository I will let you know here. Trivial in concept, but it turned
> >out to be a bit less trivial in practice. Don't they always?
> >
> >
> >
> >>Dan
> >>
> >>
> >>
> I have completed what I think are the changes needed to resolve this
> with rev 5542.
>
> Dan, please test and let me know the results.
I can confirm that the STFLE implementation now works as on real
hardware. Harold, many thanks to you.
This little change below by dekel35 is required to fool the hardware
level detection code in the Linux kernel, but it doesn't affect running
Linux as far as I know.
--- a/esame.c
+++ b/esame.c
@@ -5202,6 +5202,9 @@ BYTE *stfl_data; /* -> STFL data being modified.
Depends upon */
stfl_data[0] |= STFL_0_ESAME_INSTALLED;
+ // forcefully report this extension
+ stfl_data[2] |= STFL_2_HFP_UNNORM_EXT;
+
/* Set whether z/Arch is active based upon CPU mode */
if (regs->arch_mode == ARCH_900)
stfl_data[0] |= STFL_0_ESAME_ACTIVE;
Dan
9:53 pm
Re: STFLE instruction.
Roger Bowler
Dec 13, 2009
Dan Horák wrote:
> This little change below by dekel35 is required to fool the hardware
> level detection code in the Linux kernel, but it doesn't affect running
> Linux as far as I know.
>
> --- a/esame.c
> +++ b/esame.c
> @@ -5202,6 +5202,9 @@ BYTE *stfl_data; /* -> STFL data being modified.
Depends upon */
>
> stfl_data[0] |= STFL_0_ESAME_INSTALLED;
>
> + // forcefully report this extension
> + stfl_data[2] |= STFL_2_HFP_UNNORM_EXT;
> +
> /* Set whether z/Arch is active based upon CPU mode */
> if (regs->arch_mode == ARCH_900)
> stfl_data[0] |= STFL_0_ESAME_ACTIVE;
>
Dan,
A good bypass, but it should not become part of Hercules. If Linux is
testing bits for features it does not use (and I'd be surprised if Linux
uses HFP) then this is a bug in Linux. The purpose of STFL(E) is so that
the operating system can test for the features it needs, independent of
a specific machine type. If Linux is testing for specific bit patterns
which it recognizes as characteristic of z9 or z10, and is then basing
its actions on features it knows are in z9 or z10, then this is a bug.
Since Hercules properly implements z/Architecture, it must return an
STFL(E) bit string which accurately reflects the features that it
implements. Hercules is an independent implementation of z/Architecture,
it does not mimic an IBM machine. We do not want to fake the STFL(E)
bits in an attempt to fool Linux that it is running on an IBM machine.
Does the hardware level detection code in the Linux kernel come from
IBM? If IBM are putting code into Linux which causes it to fail when run
on a non-IBM machine, then this is a matter which raises some rather
serious questions, which I think would interest a wider audience than
just the Hercules group.
I shall be following this story with interest :-)
Regards,
Roger Bowler
Hercules "you don't need a mainframe to run mainframe software"
8:08 pm
Re: STFLE instruction.
Dan Hork
Dec 13, 2009
Roger Bowler píše v Ne 13. 12. 2009 v 21:08 +0100:
> Dan Horák wrote:
> > This little change below by dekel35 is required to fool the hardware
> > level detection code in the Linux kernel, but it doesn't affect running
> > Linux as far as I know.
> >
> > --- a/esame.c
> > +++ b/esame.c
> > @@ -5202,6 +5202,9 @@ BYTE *stfl_data; /* -> STFL data being modified.
Depends upon */
> >
> > stfl_data[0] |= STFL_0_ESAME_INSTALLED;
> >
> > + // forcefully report this extension
> > + stfl_data[2] |= STFL_2_HFP_UNNORM_EXT;
> > +
> > /* Set whether z/Arch is active based upon CPU mode */
> > if (regs->arch_mode == ARCH_900)
> > stfl_data[0] |= STFL_0_ESAME_ACTIVE;
> >
>
> Dan,
>
> A good bypass, but it should not become part of Hercules. If Linux is
> testing bits for features it does not use (and I'd be surprised if Linux
> uses HFP) then this is a bug in Linux. The purpose of STFL(E) is so that
> the operating system can test for the features it needs, independent of
> a specific machine type. If Linux is testing for specific bit patterns
> which it recognizes as characteristic of z9 or z10, and is then basing
> its actions on features it knows are in z9 or z10, then this is a bug.
>
> Since Hercules properly implements z/Architecture, it must return an
> STFL(E) bit string which accurately reflects the features that it
> implements. Hercules is an independent implementation of z/Architecture,
> it does not mimic an IBM machine. We do not want to fake the STFL(E)
> bits in an attempt to fool Linux that it is running on an IBM machine.
> Does the hardware level detection code in the Linux kernel come from
> IBM? If IBM are putting code into Linux which causes it to fail when run
> on a non-IBM machine, then this is a matter which raises some rather
> serious questions, which I think would interest a wider audience than
> just the Hercules group.
I completely understand and the patch above is meant purely as a
temporary workaround for running our Linux kernels while Harold is
looking on the implementation of the missing feature. And we can also
chose to loosen the check in the Linux kernel with Fedora-specific patch
to allow running in Hercules, because Hercules is important for building
the community.
As I've already said in some previous mail the Linux kernel still runs
everywhere (G5 and better and I don't think it can easily change, maybe
in distant future when some post-G5 feature becomes vital), but can be
configured to run on a selected subset of hardware [1].
Dan
[1] see line 470 and later in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/s\
390/kernel/head.S;h=c52b4f7742fa64cb4a82da9d5a68b8cf0ee051e2;hb=HEAD
8:55 pm
Re: STFLE instruction.
Roger Bowler
Dec 13, 2009
Dan Horák wrote:
>
> I completely understand and the patch above is meant purely as a
> temporary workaround for running our Linux kernels while Harold is
> looking on the implementation of the missing feature. And we can also
> chose to loosen the check in the Linux kernel with Fedora-specific patch
> to allow running in Hercules, because Hercules is important for building
> the community.
>
>
I think the patch to the Linux kernel is the better solution. The
workaround will not be a permanent feature of Hercules.
> As I've already said in some previous mail the Linux kernel still runs
> everywhere (G5 and better and I don't think it can easily change, maybe
> in distant future when some post-G5 feature becomes vital), but can be
> configured to run on a selected subset of hardware [1].
>
> [1] see line 470 and later in
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/s\
390/kernel/head.S;h=c52b4f7742fa64cb4a82da9d5a68b8cf0ee051e2;hb=HEAD
>
>
Thanks for the link. This is a bit of an eye-opener! I did not know that
you can configure the Linux kernel to require a specific IBM machine.
That is not good. It rather knocks a hole into IBM's open-source
credentials. This is something I think should be brought to the
attention of the wider Linux community.
It would be useful to know what functionality does Fedora use that
forces it to require a z9?
Regards,
Roger Bowler
Hercules "you don't need a mainframe to run mainframe software"
9:29 pm
Re: STFLE instruction.
Frans Pop
Dec 13, 2009
On Sunday 13 December 2009, Roger Bowler wrote:
> I did not know that
> you can configure the Linux kernel to require a specific IBM machine.
> That is not good. It rather knocks a hole into IBM's open-source
> credentials. This is something I think should be brought to the
> attention of the wider Linux community.
Hmmm?
What exactly is not good about it? And what does it have to do with IBM?
The Linux kernel allows to select specific hardware compatibility for
*all* architectures in order to optimize the kernel for a specific
machine/processor/chipset (and all later machines that are compatible with
that machine/etc.). It's a feature which allows it to run on such a
totally amazing range of hardware while still being able to perform well
on the newest hardware.
You're not selecting a "specific IBM machine", but a compatibility level.
Below is the actual configuration dialog for "processor type".
IIUC the real problem here is that the distro people who configured this
particular kernel decided to do so for a (possibly too) limited range of
systems. But that is *their* choice and has nothing to do with IBM.
Distros often have different "kernel flavors" to support different
hardware, but even so they also drop compatibility with too old hardware
at some point in order to be able to make use of optimizations in
userland.
Example. For x86 Debian has two architectures: 32-bit and 64-bit. The
32-bit arch has two kernel flavors: generic 486 and generic Pentium
(support for 386 processors has been dropped a few years ago). The 64-bit
arch has only one (generic) kernel flavor that supports all 64-bit Intel
and AMD processors.
But if someone wants to compile a kernel optimized for specifically an AMD
Athlon processor, he can do so too.
Commercial distros will often choose to optimize their releases for more
recent hardware earlier than non-commercial distros. Why? Because they
have to *sell* their product, and thus have to make sure they perform well
on current hardware.
Cheers,
FJP
”Œ”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€ Processor type
”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
”‚ Use the arrow keys to navigate this window or press the hotkey of ”‚
”‚ the item you wish to select followed by the <SPACE BAR>. Press ”‚
”‚ <?> for additional information about this option. ”‚
”‚
”Œ”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€” ”‚
”‚ ”‚ (X) S/390 model G5 and G6 ”‚ ”‚
”‚ ”‚ ( ) IBM eServer zSeries model z800 and z900 ”‚ ”‚
”‚ ”‚ ( ) IBM eServer zSeries model z890 and z990 ”‚ ”‚
”‚ ”‚ ( ) IBM System z9 ”‚ ”‚
”‚ ”‚ ( ) IBM System z10 ”‚ ”‚
”‚ ”‚ ”‚ ”‚
”‚
”””€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€”˜ ”‚
”œ”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”
”‚ <Select> < Help > ”‚
”””€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”˜
10:17 pm
Re: STFLE instruction.
Roger Bowler
Dec 13, 2009
Frans Pop wrote:
> What exactly is not good about it? And what does it have to do with IBM?
>
>
>
What's not good about it is that it is that Linux is making decisions
based on specific IBM machine types rather than the features they
support. So if for example you select z9 then the kernel won't boot on
anything that doesn't return the exact combination of features that a z9
indicates. As we have seen this has the effect of excluding
IBM-compatible hardware.
What it has to do with IBM is that the code is written and supported by
IBM Boeblingen, who effectively are the only people who can maintain
much of the arch code for s390x. The parts of the kernel that deal with
features such as PAV, QDIO, diag308, and 3590 might as well be closed
source, because IBM does not make the necessary technical documentation
available to the general developer community.
>
”Œ”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€ Processor type
”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
> ”‚ Use the arrow keys to navigate this window or press the hotkey of ”‚
> ”‚ the item you wish to select followed by the <SPACE BAR>. Press ”‚
> ”‚ <?> for additional information about this option. ”‚
> ”‚
”Œ”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€” ”‚
> ”‚ ”‚ (X) S/390 model G5 and G6 ”‚ ”‚
> ”‚ ”‚ ( ) IBM eServer zSeries model z800 and z900 ”‚ ”‚
> ”‚ ”‚ ( ) IBM eServer zSeries model z890 and z990 ”‚ ”‚
> ”‚ ”‚ ( ) IBM System z9 ”‚ ”‚
> ”‚ ”‚ ( ) IBM System z10 ”‚ ”‚
> ”‚ ”‚ ”‚ ”‚
> ”‚
”””€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€”˜ ”‚
>
”œ”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”
> ”‚ <Select> < Help > ”‚
>
”””€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”\
€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€\
”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”€”˜
>
>
Regards,
Roger Bowler
Hercules "you don't need a mainframe to run mainframe software"
10:44 pm
Copyright 2009