|
|
Developers should be aware that information stored in FMLI variables via the set utility or the argument passing mechanism ($ARGn) may not be valid at the time it is used even if it was validated at the time it was set. This can occur when variables set from data in one frame are used in the processing activity of another frame. If the use of a variable containing invalid data could seriously corrupt or compromise the system, it must be re-validated at the time it is used.
Developer-set variables are known to all frames in an FMLI session--there is no ``frame scoping'' of variables, no way to make a variable known only to the frame it is set in. This results in the classic programming issues around global variables.
Here are two scenarios that can result in the value of a variable no longer being valid.
The done descriptor of Form.1 sets a variable set -l FOO=$F1, the value of field one, and opens Form.1a. The user enters data in Form.1 and presses the <SAVE> SLK; Form.1a opens and becomes the current frame. The user now has a change of mind, navigates back to Form.1, and enters a new value in field one. If, instead of pressing the <SAVE> SLK for Form.1 again, the user navigates to Form.1a, when the user saves Form.1a it will not know the value in Form.1 has changed and any action in Form.1a based on the value of FOO will be different from what the user expects. The user's error of not pressing <SAVE> after changing Form.1 will not be detected.
The done descriptor of Form.1 opens Form.1a passing the value of $F1 as the first argument (as in open Form.1a $F1). Assume this value is a user ID that Form.1 validated. Now the user navigates to another menu and deletes the user, then navigates back to Form.1a. Now the value of ARG1 is not a valid user ID even though Form.1 validated it. Form.1a must re-validate the value before doing anything based on it.