Transactions Across Multiple Datasets [ Getting Started With TRANSACT V ] MPE/iX 5.0 Documentation
Getting Started With TRANSACT V
Transactions Across Multiple Datasets
All of the above concepts are still valid even if the transaction affects
multiple datasets. The following program illustrates a way to write
generic code that accesses more than one dataset. This code could be
expanded to include the topics previously discussed to provide form
independence, user exits, etc.
__________________________________________________
| |
| 1 system addprt,base=orders |
| 2 ,vpls=formfile; |
| 3 list(auto) addpart-global; |
| 4 level; |
| 5 list(auto) partvendors; |
| 6 level; |
| 7 list(auto) inventory; |
| 8 level; |
| 9 list(auto) parts; |
| 10 get(form) addpart,init; |
| 11 put parts,list=(@); |
| 12 move (global-part) = (part-number);|
| 13 end(level); |
| 14 move (part-number) = (global-part);|
| 15 put inventory,list=(@); |
| 16 end(level); |
| 17 move (part-number) = (global-part);|
| 18 put partvendors,list=(@); |
| 19 end; |
__________________________________________________
Figure 9-29. One screen, multiple dataset generic transaction
The generic transaction adds a new record to the parts dataset, which is
the master dataset. It then adds a record to each of two detail sets,
inventory and partvendors. Part-number is a critical element and is
common to all three sets.
The dictionary description of the lists used by the program are as
follows:
_________________________________________________________________________________
| |
| FILE TYPE: RESPONSIBILITY: |
| ADDPART FORM |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| PART-NUMBER X (8,0,8) PART-NUMBER |
| DESCRIPTION X (20,0,20) DESCRIPTION |
| LOCATION X (4,0,4) LOCATION |
| QUANTITY I (6,0,4) QUANTITY |
| VENDOR-CODE X (6,0,6) VENDOR-CODE |
| VENDOR-NAME X (20,0,20) VENDOR-NAME |
| |
| FILE TYPE: RESPONSIBILITY: |
| ADDPART-GLOBAL FORM |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| GLOBAL-PART X (8,0,8) GLOBAL-PART |
| |
| FILE TYPE: RESPONSIBILITY: |
| INVENTORY DETL |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| PART-NUMBER * X (8,0,8) PART-NUMBER |
| CHAIN MASTER SET: PARTS |
| LOCATION X (4,0,4) LOCATION |
| QUANTITY I (6,0,4) QUANTITY |
| |
| FILE TYPE: RESPONSIBILITY: |
| PARTS MAST |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| PART-NUMBER * X (8,0,8) PART-NUMBER |
| DESCRIPTION X (20,0,20) DESCRIPTION |
| |
| FILE TYPE: RESPONSIBILITY: |
| PARTVENDORS DETL |
| |
| ELEMENT(ALIAS): PROPERTIES: ELEMENT(PRIMARY):|
| PART-NUMBER * X (8,0,8) PART-NUMBER |
| CHAIN MASTER SET: PARTS |
| VENDOR-CODE X (6,0,6) VENDOR-CODE |
| VENDOR-NAME X (20,0,20) VENDOR-NAME |
_________________________________________________________________________________
Figure 9-30. Dictionary definitions for one screen, multi dataset transa
Note that the global definitions for this transaction include an element
called global-part. This element is used to store the value of
part-number between dataset updates as explained below.
The form addpart looks like this:
_______________________________________________________
| |
| addpart add a part |
| |
| |
| part number [ ] |
| |
| description [ ]|
| |
| location [ ] |
| |
| quantity [ ] |
| |
| vendor code [ ] |
| |
| vendor name [ ]|
| |
_______________________________________________________
Figure 9-31. Multiple dataset screen
The key to understanding how to write generic code is to understand how
the VPLUS and Image interface work with the list register.
The first thing to understand is that the list register can have as many
definitions of an element on it as you want. However, Transact always
references the latest definition. Thus when we do a LIST(AUTO) for each
dataset that the transaction is to access, we are putting three
definitions of part-number in the list register.
The VPLUS interface with the dictionary does not require us to use the
LIST= option. If this is left off, Transact matches the elements that
are a part of the form with the current contents of the list register.
These elements can occur anywhere physically in the list register.
Elements are resolved by starting at the end (most recent change) of the
list register, and working back until the element definition is found
(line 10).
The Image interface through LIST=(@) requires the element list to be
contiguous. We cannot list the individual elements, since this would
defeat the idea of creating custom code. Thus after updating the parts
dataset (line 11), we need to save the value of part-number (line 12) and
then remove all of the parts dataset elements (line 13), then restore
part-number which now will be the part-number defined for dataset
inventory (line 14). A record is then added to the inventory dataset.
Since part-number has already been saved, we do not need to save it
again, but can now remove the elements that belong to the inventory set
from the LIST and then restore part-number which now becomes the
part-number for the partvendors set.
This same logic can be repeated any number of times. Similar logic also
handles data retrieval from different sets.
MPE/iX 5.0 Documentation