As Mario notes in the original posting, STCKE has been around for two decades. I have a high confidence that it's not going away ... unlike, the TX facility which Charles mentions (I can't begin to say how annoyed I am about that).
If you're not sure whether STCKE is always available, the I agree with Binyamin: If you REALLY need the performance of STCKF, then coding it in a separate module that gets loaded if the facility is present is the way to go. Even if you use STFLE just once to test for the presence of the facility and store its results where you subsequently test a bit, having to test/branch for each execution of STCKE could make its benefits negligible. As to Charles' statement that "STCKF is potentially so much faster ...", well, that depends. STCK and STCKE are required to produce monitonically-advancing results. That is, they will never produce the same results in an MP environment, and the results will always increase (at least until the STCK results wrap around in around 2042). To do this, the CPU may delay the results of the execution of a STCK until it can produce an advancing value. This could be a longer delay in a configuration with lots of CPUs; not so long a delay in a configuration with fewer CPUs. CAVEAT PROGRAMMATOR: Using STCKF can produce results that do not necessarily follow the path of least astonishment. Check out Figure 4-13 on p. 4-52 of the latest PoO (SA22-7832-13) to see cases where using STCKF could produce results that appear to make time stand still or run backwards. If you don't care about such STCK/STCKE/STCKF interdependencies, or if you're running in a single thread and don't care about MP effects, then STCKF may be a good option. But beware of the possible surprises in its use.
