Extend Dynamic Library Support to Cataloged, Non-SMS Datasets (SHARE Requirement SSCICS08009)

DESCRIPT : We would like to use CICS/TS's dynamic library support but most of production load libraries are not SMS managed. This means we would have to leave them in the CICS JCL and using ranks less than 10 for the other load libraries. First, IBM recommends not using a rank less than 10 for any extended time. Second, it may make it impossible for us to use dynamic library support for the load library concatenations we need.

*********** This is the requested clarification from the Author *********** - This requirement is for CICS/TS dynamic DFHRPL library support. - We would be more likely to use dynamic libraries in test rather than production for these reasons: 1. JCL with the controls and audit trails we already have in place is more appropriate for specifying the production DFHRPL concatenation 2. Production DFHRPL concatenations don't change that often, nor should they. We will add an override library to the JCL in the rare instance when we need to. 3. We constantly change test DFHRPL concatenations at the developers' request. - We have quite a few duplicate modules in our test DFHRPL's. The idea is to put new code in libraries at the top of DFHRPL and copies of the production libraries at the bottom. That way, programmers can test the new modules and not have to worry about every other module (application and corporate utility) in the application. We often find ourselves looking through the DFHRPL concatenations to see which version of a module CICS is loading. In these circumstances, ranking is very important. - In production and ADM we have a mixture of SMS managed and non-SMS managed libraries. The non-SMS managed libraries tend to be the very old ones we've been using for years. Yes, we could convert them to SMS, but, that could mean a full outage and I'm not sure I could convince all the concerned parties it would be worthwhile for dynamic libraries. - Again, the SMS management requirement seems to be an artificial and unnecessary roadblock. While I don't know what exactly went into the code, it seems to me the developer actually had to put extra logic into CICS to check load libraries for SMS management. A PTF removing this restriction would be rather small and consist of removing or no-op'ing the check. I might understand requiring SMS management if it had some direct bearing on the dataset or how CICS uses it. But, previous releases don't make this distinction and I don't think it should make a difference to CICS/TS 3.2 either.