Expected Run Times for Conversion Effort

-
Hint: I tend to expect my conversion effort to run for about 24-36 hours all up (assuming the machine has been spec'ed to suit the customers implementation footprint and standard batch schedule expectations). This tends to include the migration to Prod, and Tidy Balances (including database backups at various stages throughout the process).
As a rule of thumb though I tend to break the processing down to:

~10-20% - Input Transform (ie ConversionCentral)
~25-30% - Object Validation
~ 5-10% - Key Generation
~ 5-10% - Tidy Balances
~10-15% - Production Migration
~15-25% - Reporting

Comments

GoBipUser said…
How can i get a cobol source code from the application Viewer in Text format?.

Thanks for your support.

Gabriel
February 15, 2008 at 1:59 AM
Stuart Ramage said…
Gabriel,

The Application Viewer contains a mix of Oracle Utilities CC&B Base Code and Customer Modifications and is read-only by design. The Oracle Base Code is protected and should NOT be changed under any circumstances. The Customer Modifications should be available to you in the clients source repository. It is also available on the server in the $SPLEBASE\cobol\source\cm directory as a last resort.
February 15, 2008 at 7:15 AM
Post a Comment

Popular posts from this blog

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).
Read more

Bundle Corrections.

-
We have identified an issue with the use of bundling and UI Maps, whereby the resulting Bundle was wrapping the UI Map in a set of CDATA tags, but only after it had already removed all formatting from the source records, resulting in corruption of the UI Map HTML fragments. This has now been corrected by implementing Single Fix 8228025 on FW/CC&B 2.2.0. If you are using the Bundling subsystem in your implementation, I strongly recommend that you implement this patch.
Read more

Threading...

-
A common question that I get asked is.. how do we force multi-threaded conversion jobs to split the key ranges evenly across each thread instance? Unfortunately I don't have an easy answer. The base conversion jobs seem to take a simplistic approach of using the low and high override values (if supplied, otherwise they use values of 0000000000 and 9999999999) and then divide these by the number of threads to determine the ranges for each instance. But.. We have found that we can force a predefined range of values and simulate threading but having separate batch controls defined for each thread, with predefined high/low values and these can then be run concurrently through standard batch submission processes.. e.g.. if we want to run VAL-ACCT in 4 threads and ensure that a known range of source keys between 0000000001 and 0000100000 is split between the 4 threads, we clone the existing batch control into VAL-ACCT1, with OVRD-LOW-ID = 0000000001 and OVRD-HIGH-ID = 0000025000 V
Read more