HP 3000 Manuals HP 3000 Manuals
Chapter 9 Creating Custom Applications
In this section, we look at coding techniques that use the power of
Transact and Dictionary/V. One of the most time-consuming functions of an
application system's programming team is program maintenance. Quite
often this time is related to the kinds of activity that can be greatly
reduced or even eliminated by taking full advantage of the integration of
Transact and the dictionary.
Some of these time-consuming activities are: adding new input forms,
changing or deleting existing input forms, adding new data elements,
deleting existing elements, or changing existing elements in size.
We will follow through examples of localizing a program, that is, making
it independent of the form name and of the number of forms that execute
the same code, independent of the form contents, and provide user exits
for additional processing. The changes we make always apply to the
dictionary. The changes become effective in the program when the program
is recompiled in order to pull in the new dictionary definitions.
An application system can be divided into at least two parts. The first
part is made up of the data that is needed by the system processing
logic. This data or these data elements are critical to the proper
functioning of the system. For example, a manufacturing system no doubt
has an element called part-number which is a critical part of practically
all system transactions.
A typical application may have several critical data elements. It is
fair to say that a localizable application cannot allow critical fields
to be deleted from the application. Application programs rely upon these
fields to be present in transactions.
However, a localizable application should allow these elements to be
changed in size. It should also allow the physical placement of these
elements within an input form to be changed.
The other part of an application is made up of noncritical elements.
Many of these elements may be supplied as a part of the original
application, if for no other reason than the typical generic application
has these data elements. Other noncritical elements may be added by the
particular user of the application.
A localizable application should allow noncritical elements to be added,
deleted, changed in size, and changed in physical placement within an
input form.
Also, generic transactions should be localizable. A generic transaction
is defined here to be a transaction that provides a basic function such
as adding a customer or updating a customer. For example, one
organization may be responsible for adding new customers to the database,
but several organizations need to be able to update portions of the
customer data. Each organization should be provided with a form which
only accesses the data they need. The same program logic that provides
customer update capability should be able to handle any number of these
variations.
Finally, a localizable application should allow logic to be added to
handle such things as: special field edits for any of the transaction's
data elements, data calculations, etc.
With this brief background, let's look at how Transact can achieve this
level of localization. Our objective is to write an application program
such that if we choose to change the application as described above, we
need not modify the program. We only need to record the changes in the
dictionary, recompile the program to make the changes known to it, modify
our VPLUS forms file to reflect the changes, and possibly unload and
reload the database, if its structure has been modified.
We will start with a simple transaction that only applies to one dataset.
This will demonstrate all of the concepts we want to achieve through
localization. Later we will extend this example to include a transaction
that applies to several datasets, in order to demonstrate the general
case of how to write generic code.
Let's use the customer dataset of our example database for illustration.
Our generic transaction provides the capability to update information for
a customer. Breaking this application into the two parts discussed
above, the critical element in this transaction is cust-no. The
noncritical elements are: name, street-addr, city-state, and zip-code.
The VPLUS form used for each of these functions is vcustomer.
_____________________________________________________________
| |
| vcustomer customer data |
| |
| |
| number [ ] |
| |
| name [ ]|
| |
| address [ ]|
| |
| city,state [ ]|
| |
| zipcode [ ] |
_____________________________________________________________
Figure 9-1. VPLUS form to maintain a dataset
The dataset definition looks like this:
_________________________________________________________________________________
| |
| FILE customer |
| |
| FILE TYPE: RESPONSIBILITY: |
| CUSTOMER MAST |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| CUST-NO * I+(4,0,2) CUST-NO |
| NAME X (20,0,20) NAME |
| STREET-ADDR X (20,0,20) STREET-ADDR |
| CITY-STATE X (20,0,20) CITY-STATE |
| ZIPCODE X (6,0,6) ZIPCODE |
_________________________________________________________________________________
Figure 9-2. Dictionary definitions for customer VPLUS form
The following program illustrates how a transaction to update a customer
might be written without allowing for any localization. We will expand
this program to illustrate most of the localization concepts.
________________________________________________________________________
| |
| 1 system custfm,base=orders,vpls=formfile; |
| 2 list(auto) customer; |
| 3 |
| 4 level; |
| 5 get(form) vcustomer,init; |
| 6 |
| 7 set(key) list (cust-no); |
| 8 get customer,list=(@); |
| 9 put(form) vcustomer,window=("update? - f1=yes, f2=no");|
| 10 get(form) vcustomer,f1(autoread)=modify-f1 |
| 11 ,f2=modify-f2; |
| 12 |
| 13 modify-f1: |
| 14 |
| 15 update customer,list=(@); |
| 16 |
| 17 modify-f2: |
| 18 |
| 19 end; |
| 20 |
| 21 |
| 22 exit: |
| 23 |
| 24 exit; |
________________________________________________________________________
Figure 9-3. Basic program to maintain customers (VPLUS)
The program uses the same form to initially input the customer to be
updated (line 5), display the current data for the customer (line 9), and
input the new data for the customer (line 10).