>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
