CICS/CM must support downward compatible operation in the TSO interface code.

Groundwork.
CM requires, for the TSO side of the interface, that the contents of the *.SCCVAUTH and *.SCCVAENU datasets be made available to TSO session in one of: LNKLST, STEPLIB, or LPA and also be APF authorized. This requirement comes from the fact that it's the TSO/ISPF side that performs the initial security checking via SAF PASSTICKETS. The requirement is accurately spelled out in CM doc, and also here:
http://www-01.ibm.com/support/docview.wss?uid=swg21259632


Next, couple this with the fact that CM servers cannot share information with other CM servers (other than through the export/import process) which means that for all practical purposes of doing any meaningful work, everything has to take place within the confines of one and only one CM server, regardless of whether it's running inside a WUI or some other CICS region.

So far so good.

Now, consider Fidelity. We're a large shop with multiple sysplexes that are geographically dispersed, each with multiple lpars. We have a regimented, controlled process for rolling out new products and maintenance to existing products that has been honed over many years and works well for us. Part of the paradigm is that we never make sysplex-wide changes to software. We implement changes an lpar at a time gradually across each sysplex in order to mitigate both risk and exposure.

In the context of CM, we find ourselves in a very difficult situation because there is no downward compatibility between the CM server and the TSO/ISPF interface. For example, after a CM server has been updated to 5.2, TSO/ISPF sessions that are still running the 5.1 code can no longer connect or communicate with the server. We do not use STEPLIB in any TSO sessions because of the well-known negative impact that practice has on performance (STEPLIB is always searched first and incurs I/O BLDL overhead, even before LNKLST (with LLA lookaside) or LPA are searched). So that leaves us with the option of putting the required CM modules in either LNKLST or in LPA. However, since we never perform sysplex-wide changes, now we're forced into a situation where, for a period of time while a new level of CM is rolling out, at least some of the lpars in the sysplex will be non-functional as far as CM is concerned because they have not yet been upgraded to the new CM code and therefore will be unable to work with the upgraded CM server.

The CM server-side code should be downward compatible for at least one full version/release with the APF code that is used on the TSO/ISPF interface. Additionally, the product should allow deploying the TSO/ISPF code using mechanisms that do not require the exclusive use of STEPLIB/LNKLST/LPA . Even if the product were to provide and employ an SVC routine to gain sufficient authorization to perform the needed security processing, it would be less onerous than the present implementation. I'm assuming here of course that the SVC would be compatible across multiple product versions/releases.