What is CompuSet
and how can we replace it?
Error xxx: Program too old to be serviced
What actually happens when a program is so old that it is no longer being maintained? How do you deal with this as a company? And what does it mean for ongoing operations when good alternatives to this program are still rare?
CompuSet fits this profile exactly. It is an ancient computer program that usually still actually runs smoothly. At least, up to the day when it suddenly stops working.
Let’s start at the beginning, though …
What is CompuSet in fact?
Roughly at the beginning of the computer Stone Age, there was a very successful American company that had a really ingenious idea:
A data-driven, dynamic renderer that creates documents very quickly and flexibly on the basis of style definitions. CompuSet is a program from the 1970s, still in use today, that generates documents (maintenance-free since the mid-2000s – therefore in need of replacement).
So, CompuSet creates documents from data, and does it very successfully. Even back then, it really was ahead of its time. If you use the tool properly, you can do really amazing things with it.
For example, two experts with CompuSet know-how could take on the entire document creation sphere of a large corporation that is active in Germany, Austria, Switzerland, the Benelux countries, Hungary and a few other countries as well. And all that despite the fact that the files being dealt with are not static text files, but highly complex contracts that are legally secure, that comply with corporate identity and have to be tailored to the product and customer in a highly individual way.
However, as the original company was no longer in existence—after being sold, merged and taken over several times—in the early noughties a bridge was set up, enabling maintenance of the product to be continued. This was an attempt to bring what was actually a very successful program into the 21st century.
xPression CompuSet Bridge
A CompuSet extension that creates an interface between the document renderer and modern operating systems. The bridge was an attempt at providing the program with maintenance and service in the future.
The result of this was that a super program—the original version of which was also not being maintained any more—was no longer functioning together with a bridge that was actually not all that good.
However, many companies were reliant on the program continuing to operate.
This has resulted in several companies still using CompuSet today—but with no maintenance.
What pain points have been created by this and what then happens?
Well, usually nothing happens initially … until there is a company-wide system update. However, a great deal can then happen all at once.
For example, entire libraries required by CompuSet are no longer available or only exist as a new version that is therefore the wrong one for this program. This problem may be avoidable with a bit of manual work (e.g. by obtaining and compiling the correct versions of the library source codes and their dependencies). However, it is foreseeable that this option will cease to exist in the near future. In addition, the user is confronted with the complete absence of a service desk.
A non-operational CompuSet could mean, though, that the core processes of a company will no longer function. In a bank or insurance company, this means:
- no more new customer contracts
- no more policies
- no more invoices
- no more payment slips
- no more bank statements
→ no continuation of operations.
In this case the argument that most companies present is that they would surely survive for 48 hours. What would things look like after 7 days, though? In the worst case scenario, CompuSet would no longer be executable at all.
The alternative is no alternative, because no update is also no solution. Ultimately, this creates critical security vulnerabilities, but no debugging takes place.
In addition, there is also the subject of stability when CompuSet is in operation. After all, nobody can guarantee that what functions today will still be functioning tomorrow.
Anyone who takes their job seriously and weighs up the risks properly should therefore take the decision as soon as possible to turn off CompuSet and replace it with a new, well-maintained system.
How do you sustainably migrate a complete communication landscape that took years of hard work to set up, though?
Quite simply and best of all without any losses:
Out with CompuSet and in with the new product. Done.
To do this, you need a product that understands exactly what CompuSet has been performing and starts exactly at the point where you want to remove CompuSet. Best of all, painlessly, quickly and without a great deal of programming work.
In addition, the new product must be just as powerful and easy to maintain. However, it must also meet the requirements of the 21st century in terms of convenience, user support, trends and methods. It must also be able to get the best of both eras and regular maintenance.
docTYPE as solution for the CompuSet problem
docTYPE – a document renderer that works quickly and requires little maintenance. It can completely replace CompuSet 1:1 in just a few steps.
docTYPE is a product that has the ability to seamlessly slip into the gap left by CompuSet. In some projects, it has been possible to perform a complete migration in a matter of just a few hours. Which, in view of the alternative—complete new development—will probably save the company concerned a 7-digit cost in euros.
This makes the old and no-longer maintained product seamlessly and easily replaceable at low cost. In addition, it also provides the following advantages:
- Not only can a renderer with the same philosophy as CompuSet be used, but one that has arrived technologically in the 21st century.
- New formats—such as Unicode documents, bar codes, better graphics, RFID chips in the paper, etc.—are supported and provide new options.
- The user experience is then just the way you would imagine it to be nowadays.
- Document rendering is possible for both digital and analog communication. After all, HTML, email, various messengers, etc. are just as necessary nowadays as the page-based communication in PDF and on printouts used to be with CompuSet.
So, the only right solution to this problem is to replace a program that has no longer been supported for about the past 20 years, and as soon as possible.
For all those who—after having read this information—are still not convinced that they should switch to a new product, it remains to be said that DocuMatrix GmbH will gladly take care of the maintenance and operational workarounds for CompuSet, in addition to providing pain-free and rapid troubleshooting.
You will know exactly what you are doing; after all, the source code for docTYPE was developed in-house and is fully capable of understanding CompuSet files.