Platform/Application DB2 Schema

This RFE is satisfied by CICS TS 5.3 which is generally available from December 11th 2015.

The new private resource PACKAGESET makes the handling of DB2® data in a cloud environment easier and more flexible by enabling you to specify different DB2 collections across different environments. Using PACKAGESET, CICS can now issue the EXEC SQL SET CURRENT PACKAGESET command on behalf of the application. The PACKAGESET resource is optional, and existing mechanisms to manage different collections across different environments remain available, for example, multiple plans, dynamic plan exits, or setting the package set yourself in the application.

This RFE is satisfied by CICS TS 5.3 which was announced on October 5th 2015 with a planned general availability date of December 11th 2015.
For more information see the announcement letter http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS215-363

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

This is something we would like to address. The RFE is being moved into 'Planned for Future release' status. Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

For the short term, one of the two approaches documented in the previous comment should be used, but longer term a declarative approach would seem appropriate.

There are two ways the setting of the schema name could be achieved. The Schema name is the collection identifier which governs the set of packages that are searched and ultimately the tables that are referenced.

A new version of an application will be compiled into a PDS that is uniquely referenced by an application specific library definition. The DBRM is bound into a unique package for that version of the application.

The first way this could be achieved would be to bind the package into a unique plan per version of an application. CICS could then be configured so that a dynamic plan exit is used. The dynamic plan exit could use an EXEC CICS ASSIGN command to find the application context, ie platform name, application name, major version, minor version and micro version. Based on the application context the dynamic plan exit sets the relevant plan name to be used.

This first method has the drawback that there are multiple plans to maintained, and also you get less thread reuse because you can only reuse a thread for the same plan.

A second way of doing it would be to have collection id per version of the application containing the versioned package, and bind all the collections into the same plan. Now because you are using the same plan, you can reuse the thread. Now instead of using a dynamic plan exit, you statically use the same plan name. This time it would be the application itself that issued the EXEC CICS ASSIGN command to obtain the application context, then the application would issue an EXEC SQL SET CURRENT PACKAGE SET which sets the schema name, ie the collection identifier to be used.