Peter,
I think the point you are missing is:
When a z/VM guest issues the STFLE command, z/VM intercepts it and
returns the lowest-common-denominator value for all processors available
for LGR. In other words, if there is a z/10 and a z/12 available, and
z/OS is running as a guest on the z/12, the STFLE will return the values
for the z/10, not the values for the z/12.
So, your statement:
Any code that ran prior to the relocation could have done things relying
on the capabilities of the original machine that might not be available
upon relocation and that might be expected to be available later.
Is not correct because z/OS will not have been told that those
capabilities were available on the original machine.
Tony Thigpen
Peter Relson wrote on 3/26/19 1:11 AM:
We are getting conflicting reports on this;
I'm not sure what conflict you see.
z/VM would indeed reflect the limitation in the output from STFLE.
So imagine if a z/OS image was "moved" after it had IPLed. The IPL time
STFLE input would indicate "original machine" but a subsequent STFLE (and
the processing itself) would reflect the capabilities of the relocation
target. You could relocate a dead (not-IPLed) guest z/OS (which would not
make much sense) but not a live guest z/OS.
Any code that ran prior to the relocation could have done things relying
on the capabilities of the original machine that might not be available
upon relocation and that might be expected to be available later.
I really don't know anything about LGR. It seems to be a problematic
concept for almost anyone, depending on when the relocation could occur.
It seems like it better not be after some code has just tested for
availability of a facility and before it started to use that facility
based on that test, if relocation was to a machine without that facility.
Perhaps there are limitations to what can be going on in the guest when
LGR occurs.
Peter Relson
z/OS Core Technology Design
