Migrating QueryCalc

The announcement of the death of the HP3000 came as a great shock to us, just as it did to everyone else. It was completely unexpected, and in our opinion, wholly unnecessary.

Nonetheless, given the announcement, the question that faced every QueryCalc user almost immediately was, "What is AICS Research going to do now to protect the users' investment?" For a few months after the announcement, that wasn't clear, even to us.

In the months following the November, 2001 announcement, we exhaustively explored a number of design alternatives. In the end, we were quite tickled with the design we adopted, and we believe that you will be too. But it's also important to note that although this document emphasizes migration, that migration is not mandatory. We will continue to support QueryCalc on the HP3000 until the last machine is unplugged.


No Steep Cliff Face Above,
No Cactus Patch Below

In the new design, QueryCalc will become signficantly less platform-dependent than it has been in the past. What happened with the HP3000 won't matter nearly as much should it happen again with a new platform. But most importantly of all, the new design completely protects your prior investment. Your reports will move to the new version of QueryCalc seamlessly, regardless of which server and which database you choose, with almost no effort on your part.

In the past, we've always argued that you wanted to do everything on the HP3000. That's where the data, the scheduler and the spooler were. The combination of the four, the data, the scheduler and QueryCalc, along with the system's printers, all residing on the HP3000 made for an enormously powerful and easy-to-use system for automated data extraction and reporting.

With the abandonment of the HP3000, we've changed our minds. Two trends have become apparent in the last decade, and they're only likely to accelerate. Servers are becoming increasingly less capable, little more than file servers, stacked one on top of the other in racks. The mainframe machines that the HP3000 was patterned after are rapidly disappearing from the commercial landscape, at least in the midrange. The second trend is even more obvious: desktop PCs have become exceptionally powerful machines in the last few years. They've actually become more like the HP3000 than the racks of file servers that are being installed in the HP3000's place.

As a consequence of this shift, we're fundamentally changing the design of QueryCalc. With the release of the new version of QueryCalc, sometime in 2003, we will move 95% of QueryCalc's behavior to the PC and keep only 5% on the server, next to the central database. If you're familiar with QueryCalc, it only takes a moment's thought to realize that much of what you do in QueryCalc can be done on the PC. Cells that contain text labels, text equations and numeric equations can all be calculated in a PC-based version of QueryCalc without ever actually having to touch the databases. These cell types don't need to be on the central host. The same is especially true for drawing graphical objects, only more so. Graphical objects can be drawn in a true WYSIWYG manner on a PC, something that was never really possible on the HP3000.

Only the query questions will continue to reside on the host, just as they did in the original QueryCalc, but this is where data extractions can be performed with great efficiency and great speed. Only the results of the queries will be transferred back to the PC, not long lists of extracted records.

QueryCalc was designed in 1985, specifically for the HP3000, and used an HP terminal
interface. It was actually more successful than you might think if you are only familiar
with PC's and GUI interfaces.


The New Face of QueryCalc

The screen images above and below are of the same QueryCalc report, but the one above is the one that you're familiar with, run on an HP3000, using the traditional HP terminal interface. The one below is new and was downloaded from a server (in this instance, a Linux device) and executed on the user's PC.

Although the reports are exactly the same, the file structures have been completely redesigned in the new version of QueryCalc in order to make them more compatible with Windows. To make this reformatting virtually invisible to you, an HP3000 program will be provided to convert all of your existing reports into the new format. The program will automatically scan all of the files in whatever group it's run and convert the QueryCalc files it finds into the new format, writing them into a new group, NEWFILES, in the account you're currently in. If, for example, you have a file called MYREPORT.REPORTS.MYACCOUNT, the file conversion routine will write the converted file into the new group as MYREPORT.NEWFILES.MYACCOUNT. Once that's been accomplished, you will be able to transfer all of the new NEWFILES reports to your new server using bulk FTP.

On the HP3000, QueryCalc files were stored as doubly-compressed BASIC data files (type: BASD). In the coming version, the files will be stored as flat ASCII files, which have the ".txt" designation on both Windows and UNIX-like devices.

A preliminary engineering version of the new PC-based version of QueryCalc,
displaying exactly the same report as above.


Nothing's Changed

The new face of QueryCalc will be attractive, easy-to-use, and instantly familiar to a whole new generation of QueryCalc users. But otherwise, nothing's changed. QueryCalc is still QueryCalc. If your database structures remain the same on the new host as they were on the HP3000, your old reports will be 100% compatible with the new version. Most importantly, the philosophy of QueryCalc remains exactly as it always has.

But just as clearly, some things will also have changed. Although you will still be able to use the traditional commands such as "/J" and "/WIDTH" to jump to specific locations on the spreadsheet or change the width of a column, you will also be able to just "click-and-point" your way to a particular cell or drag open a column's width. What you're going to get in the new version of QueryCalc is a "best of both worlds" solution.

How We're Making This All Work

The Design Criteria

Several rules govern the design of the new QueryCalc. Primary among them are:
  • The new version will be significantly less platform-dependent than the previous one was. This is being accomplished primarily by moving 95% of QueryCalc's behavior onto the PC. For all of the vile comments and jokes that are made about Microsoft, their committment to Windows is absolute, and we believe that that committment works in your favor. We believe that Windows is the only truly stable platform in today's environment and consequently represents the best platform for long-term investment. We don't foresee nearly that same level of stability in either host operating systems or databases, thus only five percent of the code will reside on the host server, with that code optimized for that particular server and database. Because such a smaller proportion of QueryCalc will reside on the host, the overall risk to the user organization is minimized.

  • The license for QueryCalc will reside on the host server, not on the users' PC's. The new version of QueryCalc will again be tiered-priced, just as the old version was. Tiered pricing allows smaller organizations to use software that they otherwise wouldn't be able to afford. But because there will be so many different versions of host hardware, associating the price of the tiers to specific hardware configurations would be impossible. Instead, the new tiers will be centered around the number of simultaneous users that will be allowed. Three tiers are planned: five, twenty, and an unlimited number of users.

  • If the user faithfully replicates the architecture of his databases onto whichever new host he chooses, the PC-based version of QueryCalc will be 100% compatible with existing reports, thus the user will lose none of what may well be a massive investment in the reports that he has constructed over the years on his HP3000's.

  • Because the new QueryCalc will consist of two parts, a freely downloadable PC-based "player" (the 95% portion) and a host-based "server" portion (the 5% part), a primary guiding design criterion has been:
    We want it to be possible for a user to go to a new office anywhere in the world, sit down at a new PC, download the "player" portion of QueryCalc, and once done, be able to log onto his central server -- anywhere in the world -- and download and begin to execute his reports. We want the time to be up and running on a new PC in a new office to be less than 30 minutes.
    The second beneficial attribute of this design will be the obvious sharability of reports. Rather than have to transport spreadsheets and databases by either floppy or email, as you do now with Excel and Access, anyone who can sign onto the central server and who can supply the proper passwords will be able to receive, execute and print the reports stored there.


Expected Pricing

The expected pricing* of the new version of QueryCalc is as follows: 

                  5 simultaneous users      $5,500
                 20 simultaneous users      12,500
          unlimited simultaneous users      18,500
Under this pricing plan, any number of users may download the "player" portion of QueryCalc and have that software available on their local PC's, but no more than the licensed number of users may be running QueryCalc on the host at any one time. Thus, if you opt for a 5-user license, and five users are currently running QueryCalc, the sixth user will be refused access until one or more users sign off.

* Current users of QueryCalc will receive a 20% discount off of the listed prices.



Macros

The manner by which macros will be defined and executed will represent the greatest philosophical change in the nature of the new QueryCalc. Macro execution will be moved to the PC and executed in one of two manners: either by pressing a button, which will be a new cell type, on the spreadsheet, in this manner...

...or through the use of a QueryCalc batch scheduler that will run in background on your PC.

What happens if your PC is set to run your reports at 3 o'clock in the morning every Wednesday and the concurrent user limit is full at that particular moment? This can't be a problem of course if you're pushing the spreadsheet button yourself. You're already signed on. But it could be a problem for scheduled auto-launch macros. If it is, the scheduler won't simply give up. Rather it will try again and again, every two minutes, until it can successfully sign on and execute the requested reports. And the scheduler will of course automatically log off of the server at the end of the scheduled macro execution.

To execute a spreadsheet macro button, all you need to do is to move the spreadsheet cursor to the cell containing the particular button and press RETURN. Because there will be no limit on how many such buttons may be placed on a spreadsheet, any number of macros may be defined for a single spreadsheet, to perform as many different functions as you like, placed anywhere on the spreadsheet, resident in any cell.

To edit the macro associated with a particular button, you will right-click the button with your mouse. Doing this will bring up a macro editor not unlike the one you're currently familiar with, but one that will be easier to use and constructed more like a standard word processor.



Printing

In the past, QueryCalc supported two printing modes: simple ASCII printing and elaborate PostScript graphics. The requirement for purchasing PostScript graphics printers will disappear in the new QueryCalc simply because of the manner by which Windows is architected. Almost any printer will now do.

Nor will there be a distinction in the new QueryCalc between text-only and graphics printing. Indeed, a text-only mode will no longer exist. While you may not elect to use graphics in your reports, that capability will always be there in the new version.

The printing paradigm is quite different under Windows than it was with the HP3000. Under Windows, an application such as QueryCalc writes into the printer object, using Windows Meta Files graphics. When QueryCalc says that this file is complete, that graphical object file is put into the PC's spooler list. When its turn comes up to be printed, it's translated by the currently selected vendor-supplied printer driver into the appropriate commands for the specific type of printer selected, thus graphical output becomes possible on the cheapest dot-matrix printer (although perhaps not too well done).

QueryCalc will always print to the currently selected printer. The one exception to this statement will occur when your reports are executed under scheduled macro execution. In this circumstance, in order to allow QueryCalc reports to always print reliably, no matter on which PC they're run, when they're executed under the scheduler's macro mode, they will always print to the PC's default printer.

Because there will not necessarily be any correlation between printer names on the various PC's within an organization, the one macro command that we now believe will disappear will be the "/PRINTER" selection command. It simply won't have any value in the new environment, as it did on the HP3000.


Expected Development Schedule

As you might imagine, redeveloping QueryCalc to work on another platform from scratch is a monumental task, but so far we're on schedule. We arrived at the current design plan in February, 2002 after substantial thought. The engineering schedule devised at that time was to have the new PC-based spreadsheet working, at least partially, by August, as well as have query questions successfully being passed to the first host/database combination.

Two teams of engineers were organized to carry out this work. One team is concentrating wholly on the spreadsheet portion of the effort; the other on the query question processing. The intention is to integrate these two efforts sometime in the period November, 2002 to January, 2003, with "smoothing" occurring throughout all of the Spring of 2003, with a first release possible by perhaps as early as June, 2003.

Killing the HP3000 is a little bit like hitting a drop of mercury with a hammer; it will cause the drops to squirt out in every direction, with people migrating every which way to a whole host of new systems and new databases. QueryCalc's single largest group of customers are its 90 Summit Information System (credit union) users. Because this group will migrate as a whole and their migration plans have been well worked out, they will be the first users serviced.

Summit elected to move their application over to HP-UX, using the HP-Eloquence database, a TurboIMAGE work-alike, thus supporting that host/database combination will be our first priority as well. But once that combination is well in hand, we will move to support other host/database combinations (e.g., PostgreSQL on Linux, SQLServer on NT, Oracle on IBM, etc.) based on whatever migration patterns we see in the user community. Ultimately, it is our intention to support every common combination of host operating systems and databases.

If there's any benefit in this forced migration, it will be that QueryCalc will soon serve a vastly expanded audience of users, all the while making QueryCalc more portable between systems and thus providing its users with significantly more protection against vendor abandonment than they've had in the past.

QueryCalc   AICS Research
     Top    Atmar    Hosted by 3kRanger.com    email 3kRanger    Updated