Newcopy feature for CICS Application Bundles(OSGI) needed

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

The new PHASEIN support for the SET BUNDLE command enables the registration of a new version of an OSGi bundle with the OSGi framework, to replace the previous version contained within the CICS bundle. The new version of any OSGi services that are implemented by the new version of an OSGi bundle are then used by any new invocation of a Java program that is defined to use this OSGi service. Existing requests will continue to use the old version until the request completes. For Java programs running in an OSGI JVM server, this provides a similar capability to phasein for non Java programs. In particular it does not require the disable, discard and re-install of the CICS bundle for the new OSGI bundle to become active.

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
Support has been added to phasein Java programs running in an OSGI JVM Server.

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.

Comment 8: replacing a single bundle is not generally supported by the OSGi framework unless the application is using Blueprint or Declarative Services whose programming models support this kind of dynamic behaviour. This is because of the Java references that CICS does not control. However, I believe Liberty does offer a "pickup directory" for application developers.

Comment 6: When deploying a CICS Application we already determine whether a previous instance is already installed and prevent deployment. I would be a short step to actually DISABLE-DISCARD before deploy then INSTALL-ENABLE the new instance. This capability will require further investigation because there is currently no information in the CICS bundle concerning the name of the BUNDDEF to be used to install it and this may vary from environment to environment.

I fully support this RFE !
The complexity of the underline OSGi refresh should be hidden from the developper's.
I understand that the fact a CICS Bundle is "multi-faced" does not help implementing a generic "refresh" function.
The scope here is limited to a simple OSGi Bundle Bundles ( not to the full CICS Bundle Bundle) and the magic of the Explorer should add value to the CICS developer interface. I don't mind not having the complete set of SPI/Exits/etc...and not to have a 3270 equivalent I need to simplify the life of the developer and this is what the Explorer is about.
This is a concrete requirement from a French customer..

Sorry I was reading the wrong content. I still believe that this process needs to be made eaiser for the developer. I have been going through and making changes to my Java test applications and it is a pain to have to go disable, discard and the re-install everytime. We plan on setting up an Endevor process where the developer will upload thier OSGI bundle to a ZFS user filesystem and then the processs will move the bundle to the correct region filesystem and do the disable discard and install. I would still be nice if this process could be streamlined as I still believe it should be a one button on the eclipse that would do the update for the developer. What happens under the covers should not matter, but the process should be simple not a multi-step process and most of the time it will most likely be developers making changes, deploying, testing, making more changes, deploying, testing, ect.

Yes, What we want a one step process to disable, discard and install-enable the OSGI bundle. We plan on having an Endevor processor that would do this process so we don't have to give the application developers the install security.

Thanks, Jeff

Such a feature would most likely comprise an ordered sequence of existing SPI commands. A single new command would not suffice as in general a re-deploy of the CICS bundle(s) is required but only after the existing BUNDLE resource(s) have been discarded. Another problem with a new command with similar semantics to NEWCOPY is that it assumes the user is simply replacing like-for-like which in general is unlikely with a CICS bundle as opposed to a PROGRAM. It also assumes the application is already installed and doesn’t allow a user to switch between two different versions, a core capability going forward.

Would the single new Application resource fit the bill WRT security?

I am not against giving the users install authority at the unit test level, but the continual disable, discard, and then install everytime you make a code change being made into a single comand is exactly what I am looking for to streamline this process and also be able to use when the source management team moves the code up to other levels. Security to only do this streamlined command would also be an important part of this feature. Thanks, Jeff

Unfortunately Java is not like COBOL, you cannot simply replace classes that are in use. In the current 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. This process could be streamlined from a user perspective while respecting the required lifecycle by combining all the manual steps into a single reliable action. However, this would still require INSTALL authority for application developers.

Would such an implementation meet (at least some of) your requirements?