Stu's Braindump

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 encountered issues where Conversion runs in CC&B 2.2.0 (and possibly previous versions) results in Foreign key characteristics being populated with a value which contains trailing spaces. Whilst CC&B handles these correctly, it appears that the majority of reporting steps defined as part of the reconciliation processes do not do the required trimming of values, resulting in no match being found. I recommend that all reconciliation reporting of foreign Key values includes the necessary 'TRIM' function calls in the selection criteria.

Hint: Whilst the majority of the CC&B Conversion process can be run as a subset of steps dependent on the type of conversion run being executed (ie. Convert on Person will only require that the Validation and Production steps specific to the Person entity be executed) it is important to note that once a project moves onto a conversion run involving a more complete 'V' structure, that the need to run all KeyGen steps becomes mandatory. KeyGen will attempt to allocate a new CC&B key value for each record on the associated parent table, but it also creates a single 'blank' key value which is used by all Production Insert steps to link to optional key values. A prime example of this is the CI_ACCT MAILING_PREM_ID, this field is an optional field on the CI_ACCT records, but unless the associated CI_PREM KeyGen has been executed to create a ' ' entry on the CK_PREM table, none of the CI_ACCT records will be transferred from Staging to Production. As a resu

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

I have been asked why I tend to avoid running the Tidy Balances Conversion process, and the short answer is that 'I have never found a need to..'. The Tidy Balances process has been designed to accept an input file of Accounts and balance 'buckets' and will produce adjustments of a specific type to ensure that the account has aged balances of these values. This could be handy in situations where minimal transaction data is being converted into CC&B via the traditional Extract-transform-and-load means (ie. convert all source data into CC&B Adjustments and Financial Transactions and run the required Validation and Keygen processes), it does not fit well with my experience of bringing 2-5 years of history over (which seems to be a common requirement on CC&B projects) and needing to create an opening balance for the Service agreements which is essentially just a placeholder transaction which is no longer subject to any aging or collection processing . The ef

The attached image provides an overview of how the CC&B Conversion process hangs together. Hopefully this proves useful to you in understanding the various components of the process. For in-depth detail of the Server-side conversion modules, check the CC&B online help.

Hint: One of the questions that I tend to get asked a lot is... how do we speed up conversion? I tend to focus on a number of factors in an attempt to speed things up, but my top 11 is: Are the Staging and Production schemas on the same database/tablespace? Are the disks experiencing hotspots as a result of this shared implementation? If the two schemas are not on the same database, what is the theoretical maximum capacity of the link between the two instances? Is the machine CPU or Memory constrained? Can multithreaded runs be threaded further? Can Indexes be dropped for specific conversion steps? In most instances it it cheaper to drop the indexes before any mass insert steps and rebuild them afterwards than wear the cost of multiple I/Os for each insert. In instances where the indexes cannot be dropped, have these been created on their own database tablespace, with a dedicated I/O channel? For multi-threaded jobs, are the thread ranges reasonable, or can better results b

All, Apologies for not updating this blog on a more regular basis. I am flat out at the moment on project related work, and neck deep in CC&B 2.2 updates, but I will attempt to post more regularly in the future. Once again, if you have any questions, feel free to post them here, or contact me on my email address.

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

Question Received: A customer has asked me if its possible to keep the original account numbers when migrating information across to CC&B. My thoughts are that it could be done by inserting the account numbers into the key tables manually and not letting the migration create the account numbers. Whilst I think this is possible, I am going to steer the customer away from doing this because of the added risk to the migration process. I am however interested in your thoughts on this and if anyone has attempted it before? Answer: Whilst feasible to retain the old key values, it should be noted that the conversion effort would have to do a number of things to ensure that the old values are brought over: 1. All source keys must be unique numeric values. 2. Indentical values must be entered onto the CX_ID and CI_ID fields on tables traditionally populated by the KEYGEN conversion step (ie. all CK_* tables in the Staging Schema) (I recommend adding the same value to INIT_ID for co

Hint: I have noticed that running a single instance of the Conversion validation runs on a Windows box results in massive under-utilisation of CPU, RAM and I/O. My recommendation is that all runs of these jobs be run in threaded mode (I tend to start with 2 threads per CPU and assess the performance from that point). Some work has been done on rewriting the batch submission scripts for both Unix and Windows to support easier multi-thread submission and the auto-processing of batch parameters. Let me know if you would like more info.