5.3.3 Modifying the Simple Inquiry to Do Maintenance
Modify the previous inquiry function to also maintain records in the file.
Files Involved
Physical file CUSMST (customer master file)
RDML Program
GROUP_BY NAME(#CUSTOMER) FIELDS((#CUSTNO *NOCHG)
#NAME #ADDL1 #ADDL2 #ADDL3)
BEGIN_LOOP
REQUEST FIELD(#CUSTNO)
FETCH FIELDS(#CUSTOMER) FROM_FILE(CUSMST)
WITH_KEY(#CUSTNO)
IF_STATUS IS(*OKAY)
SET_MODE TO(*DISPLAY)
DISPLAY FIELDS(#CUSTOMER) CHANGE_KEY(*YES)
IF_MODE IS(*CHANGE)
UPDATE FIELDS(#CUSTOMER) IN_FILE(CUSMST)
VAL_ERROR(*LASTDIS)
ENDIF
ELSE
MESSAGE MSGTXT('No customer exists with this number')
ENDIF
END_LOOP
Points to Note:
- The function now supports customer inquiries and maintenance.
- Program keeps doing inquire/maintain until the EXIT or MENU function key is used (BEGIN_LOOP and END_LOOP commands).
- The EXIT and MENU function keys are enabled on the REQUEST, DISPLAY and POP_UP screens by default. If either key is used the function will end.
- In addition the CHANGE function key is enabled on the DISPLAY screen. If the CHANGE function key is used, the mode will be altered to *CHANGE, and the screen re-presented with all fields (except #CUSTNO) input capable. The reason that #CUSTNO does not become input capable is that it has the *NOCHG attribute in the GROUP_BY command.
- After the DISPLAY has finished the mode is tested. If it is *CHANGE then the user has used the CHANGE function key and altered the customer details. In this case the UPDATE is executed to update the customer master file. If the UPDATE command detects a validation error (file or dictionary level) the DISPLAY screen will be re-displayed with error details. This is because of the VAL_ERROR(*LASTDIS) parameter.
- Note that the UPDATE command does not specify a WITH_KEY parameter to nominate the file record that is to be updated. This tells LANSA that the last record that was read from the file should be updated. Thus the record read by the FETCH command will be updated.
- LANSA does NOT lock the file record between the FETCH and the UPDATE command (although it could if the LOCK(*YES) parameter was used).
So the possibility arises that another user could update the record in the interval between the FETCH and the UPDATE. This interval could be 30 minutes if the user decided to go to lunch.
If file CUSMST is created and maintained by LANSA this will not be a problem because the UPDATE command automatically checks for a change to the record in the interval between reading it and updating it. If another user has changed the record in the interval ..... the UPDATE command will act exactly as if a validation error had occurred and automatically issue a message indicating that the update was rejected. This will cause the DISPLAY screen to be re-displayed with an error message.