PowerHouse was introduced in 1982 and bundled together in a single product Quiz and Quick/QDesign, both of which had been previously available separately, with a new batch processor QTP. In 1983, Quasar changed its name to
Cognos Corporation and began porting their application development tools to other platforms, notably
Digital Equipment Corporation's
VMS,
Data General's
AOS/VS II, and
IBM's
OS/400, along with the
UNIX platforms from these vendors. Cognos also began extending their product line with add-ons to PowerHouse (for example,
Architect) and end-user applications written in PowerHouse (for example,
MultiView). Subsequent development of the product added support for platform-specific relational databases, such as HP's
Allbase/SQL, DEC's
Rdb, and
Microsoft's
SQL Server, as well as cross-platform relational databases such as
Oracle,
Sybase, and
IBM's
DB2. The PowerHouse language represented a considerable achievement. Compared with languages like
COBOL,
Pascal and
PL/1, PowerHouse substantially cut the amount of labour required to produce useful applications on its chosen platforms. It achieved this through the use of a central data-dictionary, a compiled file that extended the attributes of data fields natively available in the DBMS with frequently used programming idioms such as: • display masks • help and message strings • range and pattern checks • help and information texts. In order to support the data dictionary, PowerHouse was tightly coupled to the underlying database management system and/or file system on each of the target platforms. In the case of the HP3000 this was the
IMAGE shallow-network DBMS and
KSAM indexed file system, and the entire PowerHouse language reflected its origins. Once described in the data dictionary, there was no further need to describe the attributes through any of the applications unless there was a need to change them on the fly, for example, to change the size of an item to make it fit within the constraints of a defined item. Simple QUICK screens could be generated in as few as four lines of source code: SCREEN FILE GENERATE GO was the name of the screen that the programmer assigned to the program. was the file name to be accessed in the data dictionary. Whether the items in the file would all fit in the screen would be determined by how many items and the size of them. If they didn't all fit, the program would have to be modified to eliminate unneeded items, change the size of items to some other size, etc. But, for a file with only a couple of items in it, it is quick and easy to generate a screen for data entry, deletion, or to simply look up data by an index. Simple QUIZ reports were almost as easy. A one-file report was as simple as: ACCESS REPORT ALL GO All items in the file would be sent to the screen, maybe not in the most desired fashion, but that simple. Since QTP programs usually involved adding, deleting, or modifying data, there was not much need for simple code programs. More care was exercised because of this potential danger, as a whole file (or files) of data could be wiped out rather easily. Any QUICK, QUIZ, or QTP programs could be run compiled (converted to machine language) or uncompiled (source code). Compiled programs generally ran faster, but there had to be a good method to modifications to the source code so as to not corrupt the object code. QUICK screens were used primarily for data entry, and could call other QUICK screens, QUIZ reports, or QTP applications to update data. Also, there were a few things that had to be done to the source code in order to generate compiled code. For example, the GO command to run the source code was equivalent to the BUILD command to generate the compiled code. Commands could be abbreviated to the first three characters when writing source code. ACCESS could be abbreviated to ACC, as well as DEFine, REPort, SCReen, etc. QUIZ reports could be routed to a printer, screen, or ASCII text files with the SET REPORT DEVICE command. Given the right access and commands, a novice could write simple report programs. Just as dangerous, though, the same novice could easily destroy the data as there was no security to whether one can call up any of the interpreters. If you had access to QUIZ, you also had access to QTP and QUICK. Like all
virtual machine languages, PowerHouse is CPU intensive. This sometimes produced a visibly negative impact on overall transaction performance necessitating hardware upgrades.
Cognos practice of tying license fees to hardware performance metrics resulted in high licensing costs for PowerHouse users. == Migration to the PC ==