HP 3000 Manuals HP 3000 Manuals
User Exits
In general, there are two types of application development environments.
First there are application software companies who build application
solutions to sell to other companies. Second, there are companies who
build application solutions for use internally. Localization is
attractive to both environments. Ignoring the fact that the software is
sold in one case, both types of environments have a similar structure.
There is a central group responsible for maintaining and enhancing the
core system. There are one or more user organizations who accept the
basic system functionality, but who have unique needs from the other
users. Until these needs become the common needs of the majority of the
system users, the central group typically resists adding the
functionality to the core system.
If, however, the central group provides ways in which the individual
users can modify the system to include the functionality they need
without destroying the functionality of the core system, then both groups
become winners.
The concepts discussed earlier, plus the concept of user exits provide
this capability.
It is probably much easier for the software engineers developing software
for sale to build in user exits, since they are acutely aware of the many
unique demands their customers make.
It is no doubt much more difficult for a software engineer building
internal software to distinguish between capabilities that should be a
part of the core system versus capabilities that should be extensions or
localization of the core system, since his users are also internal.
Providing the capability for user exits and deciding on the timing of
this capability are up to the designer of the core system. For example,
a designer may only want to allow user intervention after data has been
entered. Another designer may want to allow user intervention before and
after data entry, as well as before and after database update.
Naturally, the more a designer provides this capability, the better the
possibility that the user can solve his unique problem outside of the
core system.
The example below illustrates one way to implement user exits within
Transact. It implements a structure that allows the user to do some
processing just after data has been entered.
____________________________________________________________________________________
| |
| 1 system custex,base=orders |
| 2 ,vpls=formfile |
| 3 ,file=formxref,exitxref; |
| 4 define(item) menuname x(16): |
| 5 fkey 9(2): |
| 6 screen x(16): |
| 7 lastkey i(4): |
| 8 userexit-prog x(6): |
| 9 userexit-marker @; |
| 10 list menuname: |
| 11 lastkey: |
| 12 userexit-prog; |
| 13 |
| 14 data menuname; <<to simulate transfer of control to this subroutine>>|
| 15 |
| 16 << |
| 17 ************************************************************* |
| 18 Subroutine: to update customer information |
| 19 |
| 20 input: menuname - contains the name of the screen to be displayed |
| 21 |
| 22 output: none |
| 23 ************************************************************* |
| 24 >> |
| 25 list fkey: |
| 26 screen; |
| 27 list userexit-marker; |
| 28 list(auto) custupd-global; |
| 29 let (yes) = 1; |
| 30 let (no) = 0; |
| 31 let (error) = (no); |
____________________________________________________________________________________
Figure 9-23. Providing user exits
_______________________________________________________________________
| |
| 32 level; |
| 33 list(auto) customer; |
| 34 if (error) = (no) |
| 35 then |
| 36 get(form) (menuname),init |
| 37 ,window=(" ") |
| 38 ,fkey=lastkey |
| 39 ,autoread |
| 40 else |
| 41 get(form) (menuname) |
| 42 ,fkey=lastkey |
| 43 ,autoread; |
| 44 if (lastkey) = 8 |
| 45 then exit; |
| 46 set(match) list (menuname); |
| 47 get(serial) exitxref,list=(menuname,userexit-prog); |
| 48 call (userexit-prog),data=userexit-marker; |
| 49 if (error) = (yes) |
| 50 then end; |
| 51 if (lastkey) = 0 |
| 52 then perform modify |
| 53 else |
| 54 do |
| 55 set(match) list (menuname); |
| 56 let (fkey) = (lastkey); |
| 57 set(match) list (fkey); |
| 58 get(serial) formxref,list=(menuname,fkey,screen); |
| 59 reset(option) match; |
| 60 perform modify; |
| 61 doend; |
| 62 end; |
| 63 |
| 64 modify: |
| 65 |
| 66 set(key) list (cust-no); |
| 67 get customer,list=(@); |
| 68 put(form) (screen),window=("update? - f1=yes, f2=no");|
| 69 get(form) (screen),f1(autoread)=modify-f1 |
| 70 ,f2=modify-f2; |
| 71 |
| 72 modify-f1: |
| 73 |
| 74 update customer,list=(@); |
| 75 |
| 76 modify-f2: |
| 77 |
| 78 end; |
_______________________________________________________________________
Figure 9-23. Providing user exits (cont.)
The user exit is established in a way similar to that used to achieve
form independence. A cross reference file is set up to contain the name
of the subprogram to be called based upon the name of the form that the
program is currently processing.
The content of this cross-reference file is:
_______________________________________
| |
| MENUNAME: USEREXIT-PROG:|
| -------------------------------|
| CUSTUPDATEMM CU1 |
_______________________________________
Figure 9-24. User exit cross reference table
MENUNAME is the index into the program specifying the current menu or
form. USEREXIT-PROG contains the name of the Transact subprogram to be
called.
As this program illustrates, there can be some data defined within the
program for its own use (lines 10 through 26). This data could also be
defined in the dictionary. There can also be global data that is of
importance to both the program and the user exit program (lines 28
through 31). This data should be defined in the dictionary in order to
make coding of the user exit program easier. Included in this data are
elements for handling form data input errors (validation) and the data
the user wants to add to the transaction. Finally, there is the dataset
definition needed specifically for this generic transaction, also
defined in the dictionary (line 33). The dictionary description of
custupd-global and customer is as follows:
_________________________________________________________________________________
| |
| FILE custupd-global |
| |
| FILE TYPE: RESPONSIBILITY: |
| CUSTUPD-GLOBAL FORM |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| PASSWORD X (8,0,8) PASSWORD |
| ERROR I (4,0,2) ERROR |
| YES I (4,0,2) YES |
| NO I (4,0,2) NO |
| |
| FILE customer |
| |
| FILE TYPE: RESPONSIBILITY: |
| CUSTOMER MAST |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| CUST-NO * I+(6,0,4) CUST-NO |
| NAME X (20,0,20) NAME |
| STREET-ADDR X (20,0,20) STREET-ADDR |
| CITY-STATE X (20,0,20) CITY-STATE |
| AREA X (6,0,6) AREA |
_________________________________________________________________________________
Figure 9-25. Setting up transaction-specific data in the dictionary
Note that the user of the system has added the element password to the
custupd-global list. This element is not a part of the core application.
The program depends upon the existence of error, yes, and no as the way
in which the subprogram indicates to the main program that an error has
been detected. The main program initializes these variables in lines 29
to 31.
The program sets up a marker element which it uses to denote the point in
the list register that the subprogram has access to (line 27 and 48).
The form is displayed without erasing the information, if the user exit
program detected an error. Otherwise an initialized form is displayed.
Lines 34 to 45 handle this.
Lines 46 to 48 implement the user exit by searching for a match on form
name in the cross-reference file. This code and file could be expanded
to provide for multiple user exits during the same transaction and to
make a user exit optional.
The user exit program follows. The user has decided to add a password to
the customer update menu and has added the logic to his subprogram to
validate the password.
____________________________________________________________________
| |
| 1 system cu1,vpls=formfile; |
| 2 list(auto) custupd-global; |
| 3 list(auto) customer; |
| 4 let (error) = (no); |
| 5 if (password) <> "OKAY" |
| 6 then |
| 7 do |
| 8 set(form) *,window=(password,"invalid password");|
| 9 let (error) = (yes); |
| 10 doend; |
| 11 exit; |
____________________________________________________________________
Figure 9-26. User exit subprogram for data validation
Note that the user exit program must contain the LIST definition
corresponding to the main program definition that occurs after the marker
item. Standardized procedures for communicating error conditions, etc.
must also exist.
The modified user version of the form custupdatemm and the dictionary
description of this form follows:
________________________________________________________________________________________
| |
| custupdatemm customer update main menu |
| |
| |
| enter customer number [ ] |
| |
| |
| f1 - marketing (custupdate1) |
| |
| f2 - finance (custupdate2) |
| |
| f3 - accounts payable (custupdate3) |
| |
| *********************************************** |
| or |
| |
| enter screen name [ ] |
| |
| |
| |
| password [ ] |
| |
| |
| |
| market- finance accounts exit |
| ing payable |
________________________________________________________________________________________
Figure 9-27. User-modified customer main menu, adding an element
_________________________________________________________________________________
| |
| FILE TYPE: RESPONSIBILITY: |
| CUSTUPDATEMM FORM |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| CUST-NO I+(6,0,4) CUST-NO |
| SCREEN X (16,0,16) SCREEN |
| PASSWORD X (8,0,8) PASSWORD |
_________________________________________________________________________________
Figure 9-28. Dictionary definitions of modified customer main menu