Content deleted Content added
→External links: Stub-sorting. You can help! |
PHProgrammer (talk | contribs) |
||
Line 19:
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 ''[[TurboIMAGE | 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 4 lines of source code:
SCREEN <screenname>
FILE <filename>
GENERATE
GO
<screenname> was the name of the screen that the programmer assigned to the program. <filename> 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 simple look up data by an index.
Simple QUIZ reports were almost as easy. A one file report was a simple as:
ACCESS <filename>
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 it 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 <printer> <screen> <disk> 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 you 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.{{Fact|date=February 2007}} 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.{{Fact|date=February 2007}}
| |||