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.
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 2005, 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
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,
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:
Expected Pricing The expected pricing of the new version of QueryCalc is as follows:
5 simultaneous users $7,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.
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 few 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.
Where We're Going Killing the HP3000 was a little bit like hitting a drop of mercury with a hammer; it caused 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 have been 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 home page