Identify SIIS issue before moving to z13 / z14

We have previously investigated this possibility (for example via new reentrancy checking options in HLASM or post-processing ADATA files to detect SIIS cases) but could not find any practical solution. Although certain cases (such as modifying the following instruction) might be easy to detect, we found that any simple method of checking based on the existing information known to HLASM would be likely either to produce too many false positives or to miss most genuine cases, and that was based only a small number of code examples. Also, any method of source analysis is unlikely to be able to distinguish between high-impact cases (where data is modified in a frequently-executed loop which also references the impacted instructions) and low-impact cases (for example where the data area is only modified as part of an initialisation process). It is quite possible that a much more sophisticated approach could give useful results, but we do not feel that the value of the results would be likely to justify the research and development effort.
The original form of SIIS (that is, modifying instructions deliberately, for example to insert a length) has long been deprecated as it has always had a significant performance impact. The impact now tends to be caused not by deliberately modifying instructions but rather by modifying data which is within the same 256-bye cache line as instructions (including target instructions of Execute). This sort of problem can usually be spotted very easily by a reasonably skilled programmer looking at the source, or by running a hot-spot analyzer even on an older system which has less SIIS impact. The problem can often be fixed simply inserting a 256-byte dummy padding field between the instructions and the modified part of the data area. For a collection of programs written using the same local conventions, it may even be possible to systematically fix the whole collection using a similar approach.