| |
| META TOPICPARENT |
name="APPX43Features" |
New ILF Statements |
| | The TYPE field is used to specify either FIELD or RECORD, and load/retrieve accordingly. Scanning on the TYPE field displays six possible values (FIELD, DEFAULT FIELD, ORIGINAL FIELD, RECORD, DEFAULT RECORD, ORIGINAL RECORD), apparently because the structure of the statement was taken from the STORE/RESTORE statements. However, it is important to note that there is only one stack for each FIELD, and one for each RECORD; therefore specifying DEFAULT FIELD or ORIGINAL FIELD is no different than specifying FIELD. Note, though, that an error will occur if you specify ORIGINAL FIELD on something other than the Process Control File.
The POP statement retrieves values in the reverse order that they were PUSHED, i.e. a LIFO function, and returns a TRUE flag if a value was successfully POPped, and a FALSE flag if the stack was empty. There is no automatic way to empty a stack, other than to repeat the POP statement in a loop until it returns a FALSE. |
|
<
< |
Note that PUSHing a field after PUSHing a record containing that field will not cause the field value on the PUSHed record to change. The stack for the RECORD is independent from that of the field. This is a different behavior than designers may be used to from the STORE/RESTORE statements.
It appears that fields with multiple occurrences ARE NOT supported by multiple stacks. For example, PUSH value 1 into field occurrence 1, then PUSH value 2 into field occurrence 2. If you then execute a POP on the field occurrence 1, it will retrieve the last value PUSHED into the field stack, ignoring occurrence, thus returning the value 2. However, that POP statement will place that value of 2 into occurrence 1. So the occurrence value is relevant for the source field and the destination field, but a single field name will support only one merged stack. |
| | An ideal use for PUSH and POP is to load virtual keystrokes (user options) into a stack, and have them executed automatically and sequentially. See the section on SELECT below for an example of this usage. |
|
<
< | Some enhanced functionality that might be considered for down the road would be the following statements:
- POPCLEAR - Empty the stack for the specified field or record
- POPFIFO - Have the specified field or record get POPped in a FIFO (first in, first out) manner, rather than LIFO
- POPLIFO - Reverse the above, and return to standard defined behavior
|
| | SELECT
The SELECT statement allows the access path of in input process to be changed dynamically. The structure of the statement is: |
| |
Also related to this new statement is a new Pre-Defined Field called --- ACCESS PATH. As one might assume, the field contains the value of the current access path for the Process Control File. The field may be viewed, but not changed via ILF code (that is to say, an ILF statement to SET --- ACCESS PATH to a specified value will be ignored). |
|
>
> | Open Issues, Bugs, Suggestions
Note that PUSHing a field after PUSHing a record containing that field
will not cause the field value on the PUSHed record to change. The
stack for the RECORD is independent from that of the field. This is a
different behavior than designers may be used to from the STORE/RESTORE
statements.
It appears that fields with multiple occurrences ARE NOT
supported by multiple stacks. For example, PUSH value 1 into field
occurrence 1, then PUSH value 2 into field occurrence 2. If you then
execute a POP on the field occurrence 1, it will retrieve the last
value PUSHED into the field stack, ignoring occurrence, thus returning
the value 2. However, that POP statement will place that value of 2
into occurrence 1. So the occurrence value is relevant for the source
field and the destination field, but a single field name will support
only one merged stack.
Some enhanced functionality that might be considered for down the road would be the following statements:
- POPCLEAR - Empty the stack for the specified field or record
- POPFIFO - Have the specified field or record get POPped in a FIFO (first in, first out) manner, rather than LIFO
- POPLIFO - Reverse the above, and return to standard defined behavior
|
| | Comments:
Read what other users have said about this page or add your own comments.
|
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.