I'm Back..

-

 It has been far too long between posts, but I am back!!! Still working as a member of the Oracle Utilities Black Belt Team, and still trying to post at a somewhat regular cadence (although some would argue that a gap of about 10 years is not very regular).


Watch this space for more posts on the use of Oracle Utilities products and recommendations on optimising implementations

Comments

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