Update of bundles via phasein (like programs) and NOT via CEDA

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

Unfortunately Java is not like COBOL, you cannot simply replace classes that are in use. In the JVM server/OSGi implementation the only safe and guaranteed way to update a Java application is to ensure the OSGi service, defined in the CICS PROGRAM and in the CICS-MainClass manifest header, is deregistered. To achieve this we must drive the OSGi bundle lifecycle i.e. STOP-UNINSTALL which in turn requires us to drive the CICS bundle lifecycle i.e. DISABLE-DISCARD. Furthermore the CICS bundle itself may contain other CICS resources that cannot simply be replaced and in V5.1 or later that CICS bundle may be part of a larger CICS Application.

Right now a Java application developer must manually DISABLE-DISCARD their existing CICS bundle(s) then redeploy to zFS from CICS Explorer and INSTALL-ENABLE. We are looking at ways to streamline this, so for the developer we may be able to  have a single button in CICS Explorer that will drive the required lifecycle under the covers. But fundamentally it will still drive disable, discard, install enable.

To go alongside this, we are looking into application versioning support. One of the things this would provide is the ability to have more than one version of an application available and to easily rollback to an earlier version should problems be encountered. This is superior to newcopy because newcopy doesn't give you the ability to roll forward or backward a set of changes across multiple programs in one atomic operation. 

So in summary the ability to update bundle defined resources in a more useable way is being looked at, but on the specific point of not requiring install authority, that is not something we will be addressing,  so for that reason the RFE is being rejected.

Hello John, I hope so. Thank you for the fast answer. Regards, Claus Reis

Hi Claus,

The wording of Uncommitted Candidate is very explicit....will not be delivered within the release currently under development....

So no, this will not be in the next release delivered after CICS TS 4.2.

Hello John,
„candidate for the next release after that” would mean CTS 5.1. We are currently working with 4.2.

"Update" on the CSD - file, as in the moment, cannot be accepted. This contradicts the reliability for the CICS. Therefore, we need a solution for 4.2 and really ASAP.

Thanks in advance.

Regards, Claus Reis

Hi Claus,
The states are RFE go through are:
Submitted - when you submit it to IBM
Under Consideration - when we are evaluating it.

At this point it may then be rejected, or Planned for Future Release or Uncommitted candidate. If you click on the status field you will get a screen showing the definition of the states. For example:

Planned for Future Release: This request is a candidate for a future generally available (GA) release. IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. IBM will update this request to reflect any changes.

Uncommitted Candidate: This request will not be delivered within the release currently under development, but the theme is aligned with our multi-year strategy. IBM is soliciting RFE Community feedback for this request through activities such as voting. IBM will update this request in the future.


This RFE is in Uncommitted candidate state because it was too late to be considered for inclusion in the release currently under development, but is a candidate for the next release after that.

Regards,
John Tilling

Hello IBM,
question: Why has this RFE with "Uncommitted Candidate" now a lower level than before with "submitted" or even higher?
Regards, Claus Reis