Database Upgrades and their impact on Conversion
Hint: It appears that the current strategy in relation to application of Single Fixes and Service Packs no longer supports application of these scripts against a staging schema (at least as part of CC&B 2.x.x). As a result it is recommended that you drop and rebuild the Conversion schema from the Production instance once this has been upgraded with the latest patch-sets.
We have also noted that application of these single fixes may require a redelivery of all custom java code from the development environment, since the java compilation is not performed as part of the patch install process (unlike the Cobol implementation process).
We have also noted that application of these single fixes may require a redelivery of all custom java code from the development environment, since the java compilation is not performed as part of the patch install process (unlike the Cobol implementation process).
Comments
I have a query regarding database upgrade from 1.5 to 2.2. I have got a document from metalink (743031.1) that describes steps involved in the database upgrade from 1.5 to 2.2. Do you think there could be issues while upgrading the production schema? Any idea about the convesion time for a database of size 10 GB with 50,000 customers.
All up I do not anticipate this taking more than a couple of hours to run though (assuming your hardware is sized appropriately to your customer base).
Ensure that full DB backups are taken after execution of version upgrade.
the customisations tend to be the most complex part of any CC&B version upgrade, mainly due to the fact that:
1. This functionality may actually be covered as part of base product - requires re-analysis of the business need and project direction in terms of which one to use going forward.
2. The underlying base routines may have had changes to their parameter areas - A simple recompile of all custom code should realign the parameter areas, although any enhancements to the areas, in regards to new fields, may require updates to the custom code.
3. The code may not compile due to the fact that the supported cobol compiler version is different between various versions of CC&B - minimal risk unless your custom code is using some really exotic functions.
It should be noted that a full assessment of all functionality included in each new release needs to be undertaken as part of the upgrade effort to ensure that the business is aware of the strengths of each version, and to size the effort to meet the new business requirements.
Your biggest issue with moving from 1.5.x to 2.x is the fact that the product is moving towards a Java wrapped approach to running COBOL and this can lead to some differences in terms of how the code should be structured. Have a look at the 2.x SDK documentation for a better understanding of what these changes encompass.