Frequently Asked Questions

Java, .NET, HTML 5, AngularJS, and Oracle WebCenter, at the moment. We can easily support the next great thing when it comes along. And, we deliver an enterprise web architecture, which means NO DESKTOP APPLICATIONS or large, downloadable applets. No client-server Visual Basic, either; you get a true, thin client, web system from us..

Here’s our List of Supported Legacy Languages

Other languages are under development — if you don’t see yours, call!. We also have tools that let us work with the HTML produced by almost any application that runs in a browser window. Additional tools allow us to handle IDEAL, Datacomm, and some other legacy mainframe environments. New languages take a matter of weeks to support. But, we don’t always need to do reverse-engineering, sometimes we can redevelop a legacy application by capturing the screens and reports, or even by working with a user guide.

Yes. We do need some information, of course, but we can do it from screen and report captures if that is what is available.

No, we do not charge a fee, you can use your application as you wish. We deliver full source code, using the .NET framework and ODBC from Microsoft, or open standards off the ‘net (Java, JSP, XML, and SQL). Think of us as giving you a “jump start” on a programming effort — the source code is yours to keep and work with.

No, they usually give you source to your application, but they don’t give you the source to their API that implements the translated legacy language functions. If you don’t have source to the entire application, including these rewritten legacy functions, the next time you update versions of your operating system or frameworks, you’ll have to pay that vendor to update the API also — if the vendor is even still in the market. And, this also means you can’t fix scaling or performance problems in those functions, either.

Again, no, you do not. Quite frankly, ResQSoft™ Engineer can bring you tremendous savings during maintenance. But what we give you is source code, so you can maintain it with whatever development tools you’d like to use.

No, you don’t. Our only concern in this area is that we don’t want ResQSoft™ Engineer to become “shelfware” — we want you to succeed in using it. We offer training and documentation, of course, but the best way to achieve this objective is to do at least one project where our people work alongside your staff to build a real application in your environment. After that, if you want to do everything yourself, you should be set to go.

No, you don’t have to do that, either. If you just ask us to re-develop your application, you pay a fixed price or our normal labor rates and a tool charge, and that’s it. Your job gets done, and you can then maintain your code as you would any other body of source code, if you wish. We bring ResQSoft™ Engineer and our reusable code elements to every job that we do, whether it’s new development or re-development.

Usually, yes. Since our tools are designed to adapt to new languages, it is usually a matter of a few weeks to support a new language. We like doing that! Even if your legacy application is very small, we can just write SDL for it by hand and rapidly develop a modern version.

SDL stands for Screen Definition Language. It’s a very simple way to represent a user interface (screen or report). You can create SDL with a text editor like Notepad, and ResQSoft™ Engineer can turn it into a beautiful, browser-based interface. But we don’t try to charge for SDL or restrict its use, anyone can use it. For even more control, we can use HTML the same way we use SDL.

You typically do not have to hand-modify the code once it is generated. At the start of the project, there is normally some modification of the templates that s done by hand. And, you will write some custom code, because it really isn’t possible to automatically write all of the code for every application. Remember, there is no silver bullet! For simple applications (basically filing and reporting), you might not have to do any hand coding. The amount of hand code you do depends on your application: the more unusual things there are in it, the more hand code you will write. In a normal situation, you might write 5-15% of the total lines of code by hand, but the actual percentage depends on the system you are developing. Programmers are still needed — just not for the routine code!

We can preserve all of it, but you have to think the problem through. If the modification is something structural, you probably should be modifying the templates, not the application. If it is a matter of custom business logic, you can write it as a module, and use ResQSoft™ Engineer to hook it up to the application being created. In that situation, the code is preserved and re-inserted each time generation is performed. In short, if you write the code the way we suggest in our technical documentation, there should not be any lines that are not preserved. This is a lot better than some approaches we’ve seen, where your code is wiped out and where you can’t even re-generate what you had if you made a modification in the “wrong” place. There are no “forbidden” places to make modifications in our architecture; flexibility is one of the main design objectives in ResQSoft™ Engineer.

ResQSoft™ Engineer is written in Java, and is a J2EE compliant application. It is not cost-effective for us to try to secure it and create a downloadable evaluation — that is much harder in this technology than it would be for a desktop tool written in VB or C++. But we’d be happy to work with you to structure some kind of evaluation effort.

Business logic means different things to different people. For example, we routinely create new code to validate fields, manage foreign key lookups, handle required fields, and more — all without having to use legacy logic in any direct sense. But let’s talk about the kind of substantial business logic that might compute a stock quantity or implement a business policy. Our approach to that kind of legacy business logic varies by project and language. In some situations, we extract it from the source code and store it in the ResQSoft™ Engineer repository. This helps developers manage complexity, because they can search, browse, and comment the logic, as well as specify relationships from one module to another. Then, we also have translators for selected languages that the developer can invoke right from the legacy code viewer. These perform a limited automated translation of the legacy modules to Java or C#, not as incomprehensible black-box logic but rather in the way a programmer might rewrite the code. The developer can then “hook up” the translated code to specific events or processing logic in the underlying J2EE or .NET code already written by ResQSoft™ Engineer to support user screens, reports, and database operations. The other option is to write business object code and use these same facilities to incorporate the new business logic into the system.

Because you would also translate the architecture, which would be completely wrong for a modern web-based system that typically requires hundreds or thousands of small files that cooperate to give you good performance rather than big, monolithic programs that talk to a database. If you want your new system to be properly architected, with object-oriented code that is maintainable, we believe that wholesale translation is not a good approach. But, you can translate specific modules, and you can then hook them up in the correct places in the new architecture.

Nope. Think of it this way: you go to a bookcase company, and you want to order a desk. They can take a bookcase apart and make a desk out of it, but the pieces probably don’t fit together that well. When you refactor translated code, the results are not that good because the individual pieces aren’t cut out right to make up a web system. And when you try to MAKE them fit, you start running up the labor cost to the point where you pay what you would have paid for custom code — and you’ve gotten something of much lower quality.

Significantly less than anyone else, for the same quality result! Seriously, we are familiar with situations where other vendors have charged as much for a “pilot” as we would have charged to do the entire job. Give us some basic information, a code sample, or a user guide, and we’ll give you an estimate.

We have 3 alternatives. First, it’s often more efficient, less costly, and gives better performance to just modernize the existing business rules that are built into your legacy application.
A second alternative is for us to implement flexible business rules code that can be applied during forms processing. For example, we have reusable business rules code that we developed for a very complex survey project. That’s not an engine, though. Not really. But, it serves well for some applications.
Third, we are also able to integrate a rules engine with our reusable code. We did that at Freddie Mac and demonstrated it within the context of loan underwriting — and those rules are VERY complex. We’ve worked with I-Log and Jess and a couple of others, so we know how to do it. But, before plunging down this path, we recommend that you pilot the approach and verify that the functionality and performance of your selected business rules engine will meet your needs — and your pocketbook.