Update News for February 2024

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

• • New GOWIN.EXE Released In Canada

  • We Are Back To Working on CQS.EXE

  • The Litigation Continues

  • Our Current Programming Plans for 2024

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

One immediate problem was the failure of the new GOWIN.EXE to still work on Windows XP computers. It turns out that we now have to tell the compiler to produce the program for older equipment, it was only producing Windows 10 compatible software. It still runs fine on Windows 10, but clearly there are differences and by compiling it the way we have, it works on ALL systems, Windows XP and newer including Windows 11. Our immediate take on this is that the market assumes that we are all using Windows 10 or Windows 11. So if you are using the old Windows operating systems on your equipment, the days are quickly coming when those operating system will no longer be supported by most software vendors.

A common frustration with our “Historical Data” subscription, which is really just access to old copies of monthly updates, is that a lot of the oldest versions are 16 bit (DOS). You can no longer run 16 bit software on newer operating systems. Most operating systems are now 64 bit. We are still providing 32 bit software which will work on 64 bit, but the 32 bit (only) operating system that was available with Windows 10, is NOT available with Windows 11. You can ONLY run Windows 11 as 64 bit. We expect that the day will come (not for a few years) when 32 bit software will no longer run on 64 bit. By the way, we tell those who want to run the old Compulife programs to spend $100 on ebay and buy an old Windows XP laptop.

Back to the new GOWIN.EXE we released in Canada. It is worth noting that our program is now so big, and has so many options and functions, that it is impossible for us to test everything stem to stern. We just can’t and we don’t. Of course we test the major items, and make sure that those functions are not generating error messages or producing weird results, but even some of the obvious things (should be obvious) get missed.

Each one of our subscribers is unique and will use different aspects of the software. No one customer uses ALL the features of the programs routinely. I can guarantee that there are features of our program that I use ALL the time as part of our maintenance of the data, features that are rarely used by our customers. And then there are the “combinations” of use of functions that we really can’t replicate. You do this, then you do that, and then you do something that causes a bug to appear. We can never hope to imitate all those combinations in our own testing.

Therefore, after a big change like this and testing of our own, and with some fear and trepidation, we release the program with some warnings and wait for the reports of issues. We plan the timing of the midmonth release to ensure that all hands are on deck, and that we can respond immediately (one way or another) to anything that turns up. As expected, some bugs we were NOT expecting turned up, and our programmer was able to find and fix them quickly. We then put up another midmonth update with the fix and that was done in a matter of less than 24 hours. Another bug was reported and we repeated that process again. Each time we knew that in a worst case situation, we could revert back to the previous program if we were stuck longer than we could tolerate. Fortunately, that didn’t happen.

The reason our Canadian customers were the first Guinea Pigs on the new GOWIN.EXE was because (unknown to U.S. customers) we have some elements in our software that are specific to Canada. Those Canadian elements are NOT used in the U.S. and most are hidden from the U.S. customers. The opposite is also the case. We have some things we do in the U.S. that have no application in Canada, but there is more of that in Canada.

One problem that we were not expecting was that the province/state selection was messed up. That only turned up when a life company was testing some new UL premium rates in Canada. They wanted to make sure we were properly calculating the different premiums in different provinces which apply different sales taxes to those premiums. It was a good thing they did. It turns out that wasn’t working properly but got missed because most agents sell inside their own province, and that was the province the system was using. The problem was, if you selected a different province, the system was failing to change to that new province. And it’s good that turned up in Canada, because that also meant the state selection function for U.S. subscribers was messed up and that would have been complete mischief if it had been released to our U.S. subscribers. That’s now fixed but we missed that in our testing. Who would have thought it would have been a casualty of switching compilers. The point is that the best way to REALLY test is to release it after we have tested it and see what you folks can break.

The biggest thing, and this prompted the release in Canada first, has to do with Joint Life quotes. We do NOT do joint life quotes in the U.S. and there are a number of reasons for that. In Canada there are some fairly complicated calculation schemes for calculating joint life values that require us to build and imbed those calculation routines into the software program. We do not handle those routines (entirely) with data.

I HATE having to accommodate ANY specific routines like this in the program itself. I prefer that we have a “one size, fits all” program that responds to what we give it by way of data. That way, if a company rolls out a new product, or makes a change in a product, I do NOT have to have our programmer change our program to accommodate it. That takes time and we like to be able to react immediately. When you make changes to a program you are always running the risk that changing one thing in one spot, creates a new problem in another spot. That does NOT happen with our data files. If we change one product in our system, it cannot have ANY impact on any other product in our system.

Anyway, in Canada we have a couple of joint life changes coming up in early February that necessitated changes to the program. We did not want to lump those changes in with issues that might result from the new compiler, and so we decided we would release the new GOWIN.EXE in Canada in January. That way, when February got here, we did not double down on possible problems. There was NO need to expose our U.S. subscribers to those issues, so in the U.S. we are still using the old GOWIN.EXE from the old compiler.

Nevertheless, we do like to keep both countries on the same software and so we expect, when our programmer returns from vacation in February, that we will roll out the new GOWIN.EXE for the U.S. American subscribers can be grateful that their Canadian counterparts found a couple of issues that have now been resolved. Even so, U.S. subscribers will need to still pay attention when we do it, to make sure that they don’t encounter problems with those things that are unique to the U.S., such as Table Ratings. Canadian companies also have table ratings, but neither our Canadian customers or Canadian life companies seem very eager to get us the information necessary to have that feature activated in Canada.

The new compiler is now being used to build the new CQS.EXE. This includes all the changes we have to make to the common elements between GOWIN.EXE and CQS.EXE. We are now moving beyond that and working on the “Settings” feature in the CQS.EXE software. All the program wide options and settings are being moved to ONE “Settings” menu. The new settings menu will be MUCH longer, and have ALL the system wide options. The good news is that all of those settings will be in ONE place.

“Options” for comparisons, single product displays, and Pick 12 will still be in those respective parts of the software, but everything else will be in the new settings menu. For those who routinely use system wide settings, that means a learning curve but we think for new customers who are learning from scratch, it will be much easier. And it will be easier because the concept of “settings” is something most of the big software vendors have embraced in their software and that seems to be consistent in PC and web based software in general. So it will be new and probably frustrating for our existing customers, but much easier to learn for our new customers. And we have to keep finding new customers. After 42 years we realize some subscribers eventually retire, some die or some move on to other businesses. We have to work to have a product that is attractive to the next generation of life insurance people, but one which hopefully does not dissatisfy our longstanding subscribers.

The good news is that the NAAIP website, where our stolen software and information was being used, is no longer working. We are not sure why, but we do know that Mr. Rutstein and his partners faced another lawsuit from another insurance related company subsequent to ours. That lawsuit was decided in the favor of the plaintiff against Mr. Rutstein as was our lawsuit. By the way, if anyone has more information about any of that, I am always eager to hear about it. Mr. Rutstein is operating underground, but pops up in various places. Here’s one of videos recently published to YouTube.

We’ll report more when we have something that we can actually tell you.

• • 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:

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.