Adding, Deleting, and Changing Elements
Now let's take on a major localization step. Let's redefine the customer
dataset, expanding the size of cust-no from 4 to 6 digits long, deleting
the zipcode field and adding a new field called area. The following
Figures illustrate what must be done to accomplish all of this. The
important point for Transact is that we only need to recompile the
program to incorporate the new structure.
First we modify the form file, changing all the forms that reference the
customer data.
custupdatemm is changed to reflect the 6-digit customer number.
________________________________________________________________________________________
| |
| custupdatemm customer update main menu |
| |
| |
| enter customer number [ ] |
| |
| |
| f1 - marketing (custupdate1) |
| |
| f2 - finance (custupdate2) |
| |
| f3 - accounts payable (custupdate3) |
| |
| *********************************************** |
| or |
| |
| enter screen name [ ] |
| |
| |
| market- finance accounts exit |
| ing payable |
________________________________________________________________________________________
Figure 9-12. Customer main menu, change size of cust-no
custupdate1 is changed to reflect the 6-digit customer number.
______________________________________________________________________
| |
| custupdate1 marketing customer update |
| |
| |
| |
| customer number [ ] |
| |
| name [ ]|
______________________________________________________________________
Figure 9-13. Marketing customer update, change size of cust-no
custupdate2 is changed to reflect the 6-digit customer number, delete of
zipcode, and addition of area, because finance needs to be able to update
this new code.
____________________________________________________________
| |
| custupdate2 finance customer update |
| |
| |
| customer number [ ]|
| |
| area [ ]|
____________________________________________________________
Figure 9-14. Finance customer update, add, change, delete elements
custupdate3 is changed to reflect the 6-digit customer number, delete of
zipcode, and addition or area, because accounts payable needs to be able
to update all fields.
_________________________________________________________________________
| |
| custupdate3 accounts payable customer update |
| |
| customer number [ ] |
| |
| name [ ]|
| |
| address [ ]|
| |
| city,state [ ]|
| |
| area [ ] |
| |
_________________________________________________________________________
Figure 9-15. AP customer update, add, change, delete elements
These changes, as well as the database changes, are recorded in the
dictionary using DICTDBM.
________________________________________________________________________________
| |
| :run dictdbm.pub.sys |
| |
| |
| DICTIONARY/3000 HP32244A.02.01 - (C) Hewlett-Packard Co. 1984 |
| |
| PASSWORD FOR DICT.PUB> |
| |
| FORMS ENTRY(Y/N)?> |
| |
| > modify element |
| ELEMENT cust-no |
| EDIT DESCRIPTION(Y/N)?> n |
| |
| ELEMENT TYPE: SIZE: DEC: LENGTH: COUNT: RESPONSIBILITY:|
| CUST-NO i+ 4 0 4 1 |
| LONG NAME: |
| HEADING TEXT: |
| ENTRY TEXT: |
| EDIT MASK: |
| MEASUREMENT UNITS: |
| BLANK WHEN ZERO: NO |
| |
| TYPE i+ |
| SIZE 6 |
| DECIMAL ! |
________________________________________________________________________________
Figure 9-16. Changing dictionary definitions, add, change, delete elemen
_________________________________________________________________________________
| |
| > create element |
| ELEMENT area |
| LONG NAME |
| TYPE x |
| SIZE 6 |
| STORAGE LENGTH(6) ! |
| |
| > delete file |
| FILE custupdate3 |
| |
| ELEMENT zipcode |
| ENTRY DELETED |
| |
| ELEMENT |
| |
| > add file |
| FILE custupdate3 |
| |
| ELEMENT area |
| ELEMENT ALIAS |
| FIELD NUMBER |
| DESCRIPTION |
| |
| ELEMENT |
| |
| > delete file |
| FILE custupdate2 |
| |
| ELEMENT zipcode |
| ENTRY DELETED |
| |
| ELEMENT |
| |
| > add file |
| FILE custupdate2 |
| |
| ELEMENT area |
| ELEMENT ALIAS |
| FIELD NUMBER |
| DESCRIPTION |
| |
| ELEMENT |
_________________________________________________________________________________
Figure 9-16. Changing dictionary definitions (cont.)
___________________________________________________
| |
| > delete file |
| FILE customer |
| |
| ELEMENT zipcode |
| ENTRY DELETED |
| |
| ELEMENT |
| |
| > add file |
| FILE customer |
| |
| ELEMENT area |
| ELEMENT ALIAS |
| DESCRIPTION |
| ELEMENT |
| |
| > exit |
| |
| END OF PROGRAM |
| : |
___________________________________________________
Figure 9-16. Changing dictionary definitions (cont.)
Next the database is unloaded using DICTDBU.
______________________________________________________________________________________
| |
| :run dictdbu.pub.sys |
| DICTIONARY/3000 DB UNLOADER HP32244A.02.01 - (C) Hewlett-Packard Co. 1984|
| STORE FILE> mpestore |
| LIST FILE> |
| BASE> orders |
| BASE PASSWORD> |
| MODE> 1 |
| UNLOAD AUTOMATIC MASTER SETS(N/Y)?> |
| UNLOAD DETAIL SETS BY CHAIN(Y/N)?> |
| UNLOAD EDIT(N/Y)?> |
| PROCESSING SETS |
| CUSTOMER M:2/100 |
| 2 ENTRIES UNLOADED IN <1 CPU-SEC |
| PARTS M:2/100 |
| 2 ENTRIES UNLOADED IN <1 CPU-SEC |
| ORDER A:2/100 |
| AUTO NOT UNLOADED |
| INVENTORY D:3/108 |
| 3 ENTRIES UNLOADED IN <1 CPU-SEC |
| ORDERHEAD D:2/112 |
| 2 ENTRIES UNLOADED IN <1 CPU-SEC |
| ORDERLINE D:3/100 |
| 3 ENTRIES UNLOADED IN <1 CPU-SEC |
| UNLOAD COMPLETED |
| END OF PROGRAM |
| : |
______________________________________________________________________________________
Figure 9-17. Unloading the database with DICTDBU
Then the current database is purged using DBUTIL.
_____________________________________________________________________________________
| |
| :run dbutil.pub.sys |
| |
| HP32215B.04.61 IMAGE/3000: DBUTIL (C) COPYRIGHT HEWLETT-PACKARD COMPANY 1978|
| >>pur orders |
| Data base has been PURGED. |
| >>exit |
| |
| END OF PROGRAM |
| : |
_____________________________________________________________________________________
Figure 9-18. Purging the database with DBUTIL
Then the new database root file is created using DICTDBC.
______________________________________________________________________________________
| |
| :run dictdbc.pub.sys |
| DICTIONARY/3000 DB CREATOR HP32244A.02.01 - (C) Hewlett-Packard Co. 1984|
| DICTIONARY PASSWORD> |
| BASE> orders |
| CONTROL LINE> |
| SCHEMA FILE> |
| LISTING FILE> |
| APPLY SECURITY JUST TO SET LEVEL(N/Y)?> |
| SCHEMA GENERATION |
| DBSCHEMA PROCESSOR |
| PAGE 1 HEWLETT-PACKARD 32215B.04.50 IMAGE/3000: DBSCHEMA |
| TUE, MAY 14, 1985, 9:21 AM (C) HEWLETT-PACKARD CO. 1978 |
| |
| BEGIN DATA BASE ORDERS; |
| PASSWORDS: |
| ITEMS: |
| AREA, X6 ; |
| CITY-STATE, X20 ; |
| CUST-NO, I2 ; |
| DESCRIPTION, X20 ; |
| LINE-NO, X2 ; |
| LOCATION, X4 ; |
| NAME, X20 ; |
| ORDER-DATE, X6 ; |
| ORDER-NO, X8 ; |
| ORDER-STATUS, X2 ; |
| PART-NUMBER, X8 ; |
| QUANTITY, I2 ; |
| STREET-ADDR, X20 ; |
______________________________________________________________________________________
Figure 9-19. Creating the database with DICTDBC
__________________________________________________________________________
| |
| SETS: |
| NAME: CUSTOMER, MANUAL ; |
| ENTRY: CUST-NO (1), |
| NAME, |
| STREET-ADDR, |
| CITY-STATE, |
| AREA; |
| CAPACITY: 100; |
| NAME: PARTS, MANUAL ; |
| ENTRY: PART-NUMBER (2), |
| DESCRIPTION; |
| CAPACITY: 100; |
| NAME: ORDER, AUTOMATIC ; |
| ENTRY: ORDER-NO (2); |
| CAPACITY: 100; |
| NAME: INVENTORY, DETAIL ; |
| ENTRY: PART-NUMBER ( PARTS ), |
| LOCATION, |
| QUANTITY; |
| CAPACITY: 100; |
| NAME: ORDERHEAD, DETAIL ; |
| ENTRY: ORDER-NO ( ORDER ), |
| CUST-NO ( CUSTOMER ), |
| ORDER-STATUS, |
| ORDER-DATE; |
| CAPACITY: 100; |
| NAME: ORDERLINE, DETAIL ; |
| ENTRY: ORDER-NO ( ORDER ), |
| LINE-NO, |
| PART-NUMBER ( PARTS ), |
| QUANTITY; |
| CAPACITY: 100; |
| END. |
| DATA SET TYPE FLD PT ENTR MED CAPACITY BLK BLK DISC |
| NAME CNT CT LGTH REC FAC LGTH SPACE|
| |
| CUSTOMER M 5 1 36 46 100 11 507 44 |
| PARTS M 2 2 14 29 100 13 378 27 |
| ORDER A 1 2 4 19 100 20 382 18 |
| INVENTORY D 3 1 8 12 120 40 483 16 |
| ORDERHEAD D 4 2 11 19 100 20 382 18 |
| ORDERLINE D 4 2 11 19 100 20 382 18 |
| TOTAL DISC SECTORS INCLUDING ROOT: 152 |
| NUMBER OF ERROR MESSAGES: 0 |
| ITEM NAME COUNT: 13 DATA SET COUNT: 6 |
| ROOT LENGTH: 587 BUFFER LENGTH: 507 TRAILER LENGTH: 256 |
| ROOT FILE ORDERS CREATED. |
| END OF PROGRAM |
| : |
__________________________________________________________________________
Figure 9-19. Creating the database with DICTDBC (cont.)
The new database is created using DBUTIL.
_____________________________________________________________________________________
| |
| run dbutil.pub.sys |
| HP32215B.04.61 IMAGE/3000: DBUTIL (C) COPYRIGHT HEWLETT-PACKARD COMPANY 1978|
| >>cre orders |
| Data base ORDERS has been CREATED. |
| >>exit |
| END OF PROGRAM |
| : |
_____________________________________________________________________________________
Figure 9-20. Creating the new database with DBUTIL
The database is reloaded using DICTDBL.
______________________________________________________________________________________
| |
| run dictdbl.pub.sys |
| DICTIONARY/3000 DB LOADER HP32244A.02.01 - (C) Hewlett-Packard Co. 1984|
| STORE FILE> mpestore |
| LIST FILE> |
| BASE: ORDERS.CUSTOMIZ.MILLER |
| RUN MODE(LOAD/EDIT/SHOW/EXIT)> |
| NEW BASE NAME> |
| BASE PASSWORD> |
| MODE> |
| FAST I/O(Y/N)?> |
| CUSTOMER M 2/100 |
| ZIPCODE ITEM NOT FOUND, NEW ITEM NAME> <cr> = not reloaded |
| 2 ENTRIES LOADED IN <1 CPU-SEC |
| PARTS M 2/100 |
| 2 ENTRIES LOADED IN <1 CPU-SEC |
| INVENTORY D 3/120 |
| 3 ENTRIES LOADED IN <1 CPU-SEC |
| ORDERHEAD D 2/100 |
| 2 ENTRIES LOADED IN <1 CPU-SEC |
| ORDERLINE D 3/100 |
| 3 ENTRIES LOADED IN <1 CPU-SEC |
| LOAD COMPLETED |
| END OF PROGRAM |
| : |
______________________________________________________________________________________
Figure 9-21. Reloading the database with DICTDBL
Finally, we recompile the Transact program and implement the new
application.
________________________________________________________________________________
| |
| run trancomp.pub.sys |
| TRANSACT/3000 COMPILER HP32247A.02.02 - (C) Hewlett-Packard Co. 1984 |
| SOURCE FILE> custup |
| LIST FILE> |
| CONTROL> dBlist |
| TRANSACT/3000 COMPILER A.02.02 : TUE, MAY 14, 1985, 9:32 AM COMPILED|
| LISTING OF FILE CUSTUP.CUSTOMIZ.MILLER PAGE 1 |
| COMPILING WITH OPTIONS: CODE,DICT,ERRS |
| CODE FILE STATUS: REPLACED |
| 0 COMPILATION ERRORS |
| PROCESSOR TIME=00:00:08 |
| END OF PROGRAM |
| : |
________________________________________________________________________________
Figure 9-22. Compiling Transact program to resolve data changes
DICTDBU and DICTDBL cannot handle all types of element changes. For
example, cust-no was changed from a 9(4) definition to an I+(4)
definition in this example because these utilities will not convert a
numeric ASCII element properly. This is because Image does not have a
data type corresponding to numeric ASCII. DICTDBC creates an element
defined as numeric ASCII as an alphanumeric element of type X. Thus, if
cust-no were being changed from 9(4) to 9(6), DICTDBU would unload it as
X(4). DICTDBL would reload it as X(6) causing the new field to be left
justified with two spaces inserted on the right. Transact would no
longer be able to interpret the field as numeric.
Thus, when writing a custom application, avoid using data type 9 or write
a utility to convert data after DICTDBU has run and before DICTDBL has
run.