Skip to content

Update News for May 2024

Here is a quick run-down on what you will find in this bulletin:

    • We Spoke Too Soon

    • Internet Engine Issue

    • Calculating Modal Premiums
      NOT As Easy As You Think

    • Special Calculations

    • Internet Engines Have To Be Updated

    • Our Current Programming Plans for 2024

These topics will be dealt with in more detail throughout this bulletin.

We Spoke Too Soon
In last month’s bulletin we told you that we had released the new GOWIN.EXE in the U.S., having run with it for a month in Canada. That was the case, but after the bulletin had been written and published, and before we placed the monthly update on the Internet, we had a handful of reports from U.S. subscribers who were having VERY strange printing issues with their Pick 12 spreadsheets.

The problem was that the fonts in the printouts were so TINY that they were barely legible. When we gave those subscribers the older, previous copy of gowin.exe, the problem went away. A quick scramble turned up that if we took the very same programming source code and produced a GOWIN.EXE with the old compiler the problem also went away. The same source code with the new compiler caused the problem all over again. So it’s a bug with the new compiler and Compulife can’t fix that because we didn’t build the compiler.

The worst part of this is that the same program that was causing problems for some subscribers was NOT occurring for the majority of subscribers including us. No compiler is perfect and it is possible for us to make changes to get around problems assuming that we can test and analyze. But we can’t test and analyze IF we are ourselves are not experiencing the same problem. Once again, we could NOT reproduce the problem on our own equipment which means that we have NOTHING “in house” to test what is causing this issue.

And sure enough, in the middle of chasing down that problem we had a Canadian subscriber report the problem. Clearly Canadian subscribers do not use Pick 12 spreadsheet quotes as much as our U.S. subscribers do, and clearly this is a VERY rare problem that the vast majority of subscribers did not have. Has anyone ever watched the old TV show “House” where each episode was a new rare disease that perplexed the medical team?

To ensure that no one else had the issue, we pulled back and did NOT release the newest GOWIN.EXE in the April monthly update. Instead everyone got the latest compiled version of our source code, produced by the old compiler. Fortunately no one is reporting problems with that but we are now stuck working with two compilers. So far we haven’t tried to release the new version of Compulife’s software (CQS.EXE) with the new compiler, and we hope that the problem with the new compiler problem is solved before we release that to everyone.

We then spent time with our compiler manufacturer who freely admitted that they had made changes to their software in the area of printing fonts, but they did not know what was causing our issue. Our programmer has been continuing to work with them to get to the bottom of it. We suspect we cannot be alone in running into this, and at some point the compiler people will find and correct this problem. We’ll keep you posted.

Internet Engine Issue
And just to compound the problems with more problems, about the same time one of our subscribers pointed out that we were producing inaccurate monthly premiums with John Hancock term products. The problem is NOT in our windows software, it was in some of our quotes from the internet software.

The issue is a result of OLD versions of the Internet engine which do NOT have the special routines that we have had to place into our software to just deal with the John Hancock products and their modal premiums.

Calculating Modal Premiums
NOT As Easy As You Think
If you are old enough and can remember the “good old days” of rate books and calculators, you will remember that getting a monthly premium meant you took an annual premium and multiplied it by a “modal factor” to get a monthly premium. In those good old days a common monthly factor was .09 and so if you had an annual premium of $1,200, the monthly premium was $1,200 X .09 which have you a monthly premium of $108. Easy, simple, no problem; and for most companies it remains just that simple and easy today.

With the advent of computers, and with everyone relying upon quotes from those computers, some life insurance company actuaries have come up with some very creative and complex ways to do those calculations. Let’s assume the $1,200 premium example is the result of a $1,000,000 face amount, with a rate of $1.15 and a policy fee of $50. The annual premium is 1.15 X 1,000 = $1,150. You then add the $50 and you get an annual premium of $1,200. Take .09 time the $1,200 and you get a $108 monthly premium. Once again, EASY.

Now, let’s see if we can make that a lot more complicated.

With the advent of computers some actuaries and their programmers decided they would rather apply the factor to the annual rate to get a monthly rate. From the monthly rate they calculate the monthly base premium and then add a monthly policy fee. Suddenly the above “simple” calculation gets more complicated.

The first step is that you take the $1.15 X .09 which gives a result of .1035. If you took .1035 and multiplied it by 1,000, that gives you a basic monthly premium of 103.50. Now you add the monthly policy fee of $4.50 ($50 X .09) which give the same $108. So what’s the difference? In this example there is no difference. Why take the long road when you could just take the short road?

The difference is those companies who want to further change up the calculation. They do the monthly rate calculation because they want you to ROUND the monthly rate to two decimal points before it is then used. In this example, .1035 rounds to .10. .10 X 1000 = $100 Add to that the $4.50 policy fee and you get $104.50 per month which is different from $108 per month.

Now that’s not good enough for some companies. Some companies want you to ROUND UP to two decimal points. .1035 rounds up to .11 and now the monthly premium is 1,000 X .11 which is $110. Add the policy fee of $4.50 and your month premium is now $114.50 instead of $108 or $104.50.

Then there are the companies who want a monthly policy fee of $5 instead of $4.50 so you have to add 50 cents to the monthly factor.

Now all of these common variations of calculating monthly premium rates, which are used in the MINORITY of all modal calculation cases, are covered by the standard calculation options we have built into our software in order to produce monthly premiums. Once we find out HOW the company does their calculation, we can accommodate it. The point is that it’s not just as simple as annual premium times modal factor equals modal premium.

And did I mention that some companies do not use the same modal factor for all annual premiums. Yep, that really blew our minds too. To deal with those situation we have the ability to store both annual rates and monthly rates for those products.

Special Calculations
But John Hancock gets the award for the most complicated monthly premium calculation. They have devised the “we didn’t see it coming” method of calculating a monthly premium. In their case the monthly factor has more decimal point. Their factor is .0865. If you multiply that factor times 1.15 you get a monthly rate of .099475 which is 6 decimals long. No problem, we can handle all the decimals and we can round it up, down or nearest to 2 decimal. But that’s where it gets VERY different. At the point John Hancock wants it rounded 4 decimals. Not 2 decimals, not 6 decimals, they want .099475 rounded to .0995. We have no standard routine for that.

So how do we deal with that? At that point we set a flag on the product that says use a “Special Routine” and we go to our programmer and ask him to create a special routine in the program. When the program runs, and if it sees the flag set in the product for “Special Routine” it looks for the special routine for that product code(s) and executes whatever special routine is needed. Great, problem solved. Yes, problem solved if you have the latest program but what if you have an OLD copy of the program which does not have that special routine in it? Or what if you have a newer program which has the special routine, but not the latest version of the program which has some of the other newer codes that we had to add for John Hancock because they have a bunch of new variants of their products that required us creating more new codes?

Internet Engines Have To Be Updated
Unlike the Windows program, where we ship a current program with the current data, internet engines can stagnate on our customers’ computers. They work fine but may not have the latest special routines in them to handle some of the oddball products in our system. Of course if you don’t quote John Hancock, which is one of those oddball routines, no problem. But clearly some Hancock products do not quote monthly premiums correctly if you are using an old engine.

Since the last time we compiled the engine our programmer has made many changes to our software source code, getting it ready to integrate with the new Windows user interface. Those change are compatible with both our old and new Windows compiler, as we told you at the beginning of this bulletin. The problem is that the compiler used to produce the internet engine is NOT the same and there isn’t just one internet engine compiler, there are two. There is one for the Linux version of our engine and another for the Windows server version of our engine, and sure enough the new source code has to be further debugged and changed to make it compatible with both those compilers.

I will give you one guess as to what our programmer has been doing for most of the month of April. All these problems have to be solved to move forward and our programmer has been working steadily on them.

Once the new engines are working, the first job is to update our own servers with those new engines in order to test those engines to ensure they are working properly.

The first engine to be replaced will be the engine on our web quote website server. That is NOT the same website server as our Compulife Mobile or API services. We will NOT be updating those engines until such time as we are satisfied that the new engine is working fine on the web quote sites.

NOTE:  We will have a backup of the old engine for the web quotes so that if a problem emerges, we can flip back to the OLD engine to see if that resolves the issue.

If there is an issue with our new engine then we will track that down and fix the problem. And that won’t be a problem because problems on our own equipment means we can test and diagnose unlike the weird Pick 12 problem we are having with the new Windows compiler which only causes problems on some computers, none of which we happen to have.

Back to the Internet Engine. Once we are certain the engine is working fine for web quotes, we will then update the engine for Compulife Mobile customers and see how that behaves. Assuming there are no problems then we will update the engine for the API service.

And once all that is done, we will let you know and those of you who actually purchase the Internet Engine service can ask for the newest copy of the engine, assuming that you run John Hancock quotes and want it.

And that, by way of explanation, is why it can take so darn long to make changes and upgrades to software and why we can only ask you to be patient and try to understand why progress can be so breathtakingly slow. Personally I have lived this life in software for 42 years and none of this is surprising or particularly frustrating. The pressure I feel is from customer who I know wonder why it takes so long to roll out the new stuff. Hopefully this will give you a clue. We just make it LOOK easy; it’s not.

Our Current Programming Plans for 2024
The following is the current order for new work that we will be doing in 2024:

      • Introduction of New PC Version: CQS.EXE
      • Overhaul Of Current Product Data Files
    • Introduction of Compulife Mobile* Plus (with Pick 12)

Anyone with questions about any of these upcoming projects can call Bob Barney to discuss:

(888) 798-3488

Please don’t email me essay questions, just call. If I’m not in, email me your phone number, I’ll call you.

These planned objectives will easily consume our programming time during the balance of this year and throughout 2024. The good news is that once the product data files have been converted, and we have introduced the new CQS.EXE, and upgraded our internet engine to use the new data files, Compulife will be turning it’s full attention to our web based, Compulife Mobile software. The long term goal is to have a web based product that does everything our PC based software does.

COMPULIFE

Back To Top