Difference: PUSHPOPILFStatements (1 vs. 21)

Revision 212012-02-16 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

PUSH & POP ILF Statements

Line: 95 to 95
 Here are a couple of ideas for additional related statements:
  • POP ALL - Empty the stack for the specified field or record
  • POP FIFO - POP the specified field or record from the bottom of the stack - FIFO (first in, first out) manner, rather than LIFO
Added:
>
>
-- SteveFrizzell - 01 Oct 2008
 
Changed:
<
<
-- SteveFrizzell - 01 Oct 2008
<--/commentPlugin-->
>
>
Note that while PUSH/POP are similar to STORE/RESTORE, there are some significant differences. The obvious one is that multiple sequential values can be PUSHed and POPped, while STORE allows only one. There is also a difference in how Group Header fields are handled. With STORE/RESTORE, you can STORE a group header and then RESTORE individual values from within it. But because PUSH/POP recognizes different field names, that approach will not work the same way.

Example: Assume ORDER2 KEY is the key to the ORDER2 file, and is made up of ORDER2 ORDER NO and ORDER2 LINE NO. If you STORE ORDER2 KEY, then doing a RESTORE ORDER2 LINE NO will retrieve that portion of the key that was stored. But if you PUSH ORDER2 KEY and try to POP ORDER2 LINE NO, you'll see that the individual value was not retrieved.

-- AlKalter - 2012-02-16

<--/commentPlugin-->
  -- AlKalter - 04 Apr 2008

Revision 202011-09-22 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

PUSH & POP ILF Statements

Line: 84 to 84
  POP TOE ORDER1 SALESPERSON 002 FIELD
Changed:
<
<
One 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.
>
>
One 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 for an example of this usage.
 

Issues:

  1. The Data Item Type specification of the POP statement should only allow two options, FIELD and RECORD. The current implementation of the statement also allows DEFAULT FIELD and ORIGINAL FIELD to be specified. Both are treated the same as if FIELD was specified. DEFAULT RECORD and ORIGINAL RECORD are also allowed and are treated as if RECORD was specified. Application designers should always specifiy either FIELD or RECORD on a POP statement. Do not specify DEFAULT FIELD, ORIGINAL FIELD, DEFAULT RECORD, or ORIGINAL RECORD on the POP statement. These options may not be supported in a future release.

Comments:

Revision 192010-11-10 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"
Added:
>
>

PUSH & POP ILF Statements

 
Deleted:
<
<

PUSH & POP ILF Statements

 Release 5.0.0 of APPX implements the PUSH and POP ILF statements.

Line: 10 to 10
 

PUSH Statement

Changed:
<
<
The PUSH statement saves a field or record value on an internally maintained stack for the indicated field or record. The structure of the statement is:
>
>
The PUSH statement saves a field or record value on an internally maintained stack for the indicated field or record. The structure of the statement is:
 
Changed:
<
<

***** PUSH *** ********************** *** *************** (1) (2) (3) (4) (5)

(1) T/F execution conditions 

>
>

***** PUSH *** ********************** *** *************** (1) (2) (3) (4) (5)

(1) T/F execution conditions

 (2) Application ID (3) File Name, field name, or predefined field (4) Occurrence (constant/index)
Changed:
<
<
(5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)
>
>
(5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)

 

A distinct stack is associated with each field name and with each file name.

Changed:
<
<
The PUSH statement is used to add  field and record values to a stack.
>
>
The PUSH statement is used to add field and record values to a stack.
  The POP statement is used to retrieve field and record values from a stack.
Changed:
<
<
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
>
>
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
  The value of the source field or record is not changed when a PUSH statement is executed.
Changed:
<
<
You may execute a PUSH statement for a specific field or file more than once before you execute a POP statement to retrieve a value from the stack.  Each time that you execute a PUSH statement, the value of the referenced field or record is "pushed" onto the top of the stack associated with that field or file. Each time that you execute a POP statement, the next value is retrieved from the stack of the referenced field or record, stored as the current value of the referenced field or record, and removed from the top of the stack.
>
>
You may execute a PUSH statement for a specific field or file more than once before you execute a POP statement to retrieve a value from the stack. Each time that you execute a PUSH statement, the value of the referenced field or record is "pushed" onto the top of the stack associated with that field or file. Each time that you execute a POP statement, the next value is retrieved from the stack of the referenced field or record, stored as the current value of the referenced field or record, and removed from the top of the stack.
 
Changed:
<
<
The contents of predefined fields can also be saved using the PUSH statement. However, it is invalid to use the PUSH statement for predefined fields that are non-modifiable, since the POP command is invalid for those fields.
>
>
The contents of predefined fields can also be saved using the PUSH statement. However, it is invalid to use the PUSH statement for predefined fields that are non-modifiable, since the POP command is invalid for those fields.
 
Changed:
<
<
The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.
>
>
The scope of a stack is the same as the scope of the associated field or file. For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.
 
Changed:
<
<
The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the  current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the  default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the referenced field is a field in the PCF or if the referenced file is the PCF of the currently executing process.
>
>
The Data item type specification identifies which field value or record is to be pushed onto the stack. If FIELD or RECORD is specified, then the current value of the field or record is pushed onto the stack. If DEFAULT FIELD or DEFAULT RECORD is specified, then the default value of the field or record is pushed onto the stack. If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack. ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the referenced field is a field in the PCF or if the referenced file is the PCF of the currently executing process.
 
Changed:
<
<
Since there is only one stack for each field name and one stack for each file name, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated value onto a common (shared) stack for the specified field name and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffer onto a common (shared) stack for the specified record (file) name.
>
>
Since there is only one stack for each field name and one stack for each file name, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated value onto a common (shared) stack for the specified field name and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffer onto a common (shared) stack for the specified record (file) name.
 
Changed:
<
<
Multiple occurrences of a field also share a common stack.
>
>
Multiple occurrences of a field also share a common stack.
  A sub-string field and a synonym field each have their own stack since they have field names that are distinct from the field that they are derived from.

Changed:
<
<

POP Statement 

>
>

POP Statement

 
Changed:
<
<
The POP statement pops a field or record value from an internally maintained stack and sets it as the current value of the indicated field or record. The structure of the statement is:
>
>
The POP statement pops a field or record value from an internally maintained stack and sets it as the current value of the indicated field or record. The structure of the statement is:
 
Changed:
<
<

***** POP *** ********************** *** *************** (1) (2) (3) (4) (5)

(1) T/F execution conditions 

>
>

***** POP *** ********************** *** *************** (1) (2) (3) (4) (5)

(1) T/F execution conditions

 (2) Application ID (3) File Name, field name, or predefined field (4) Occurrence (constant/index)
Changed:
<
<
(5) Data item type (FIELD, RECORD)
>
>
(5) Data item type (FIELD, RECORD)

 

The POP statement is used to pop (retrieve) a value that was saved with a PUSH statement.

A distinct stack is associated with each field name and with each file name.

Changed:
<
<
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
>
>
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
 
Changed:
<
<
You may execute a POP statement for a specific field or file more than once.  Each time that you execute a POP statement, the value from the "top" of the stack of the referenced field or record is saved as the current value of the referenced field or record and the value is removed from the stack.  The POP statement also sets the True/False indicator.  If the stack for the referenced field or file contains a value, then the stack is popped and the next level of the true/false statsu indicator is set to T (true).  If the stack is empty, then the referenced field is set to its default value and the next level of the true/false indicator is set to F (false).
>
>
You may execute a POP statement for a specific field or file more than once. Each time that you execute a POP statement, the value from the "top" of the stack of the referenced field or record is saved as the current value of the referenced field or record and the value is removed from the stack. The POP statement also sets the True/False indicator. If the stack for the referenced field or file contains a value, then the stack is popped and the next level of the true/false status indicator is set to T (true). If the stack is empty, then the referenced field is set to its default value and the next level of the true/false indicator is set to F (false).
 
Changed:
<
<
Predefined fields may be referenced by a PUSH or POP statement. However, it is invalid to use the PUSH or POP statement for predefined fields that are non-modifiable.
>
>
Predefined fields may be referenced by a PUSH or POP statement. However, it is invalid to use the PUSH or POP statement for predefined fields that are non-modifiable.
 
Changed:
<
<
The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.
>
>
The scope of a stack is the same as the scope of the associated field or file. For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.
  When a POP statement references a field with an occurrence, the next value from the stack is popped into the specified occurrence of the reference field.
Line: 80 to 78
 

Examples

The following example shows how PUSH and POP can be used to swap the values of occurrences 1 and 2 of a field.

Changed:
<
<
      PUSH     TOE ORDER1 SALESPERSON     001 FIELD

>
>
      PUSH     TOE ORDER1 SALESPERSON     001 FIELD

  PUSH TOE ORDER1 SALESPERSON 002 FIELD POP TOE ORDER1 SALESPERSON 001 FIELD POP TOE ORDER1 SALESPERSON 002 FIELD
Changed:
<
<
One 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.
>
>
One 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.
 

Issues:

Changed:
<
<
  1. The Data Item Type specification of the POP statement should only allow two options,  FIELD and RECORD.  The currently implementation of the statement also allows DEFAULT FIELD and ORIGINAL FIELD to be specified.  Both are treated the same as if FIELD was specified.  DEFAULT RECORD and ORIGINAL RECORD are also allowed and are treated as if RECORD was specified.  Application designers should always specifiy either FIELD or RECORD on a POP statement.  Do not specify DEFAULT FIELD, ORIGINAL FIELD, DEFAULT RECORD, or ORIGINAL RECORD on the POP statement.   These options may not be supported in a future release.
>
>
  1. The Data Item Type specification of the POP statement should only allow two options, FIELD and RECORD. The current implementation of the statement also allows DEFAULT FIELD and ORIGINAL FIELD to be specified. Both are treated the same as if FIELD was specified. DEFAULT RECORD and ORIGINAL RECORD are also allowed and are treated as if RECORD was specified. Application designers should always specifiy either FIELD or RECORD on a POP statement. Do not specify DEFAULT FIELD, ORIGINAL FIELD, DEFAULT RECORD, or ORIGINAL RECORD on the POP statement. These options may not be supported in a future release.

 

Comments:

Added:
>
>
 Read what other users have said about this page or add your own comments.
Line: 96 to 94
  Here are a couple of ideas for additional related statements:
  • POP ALL - Empty the stack for the specified field or record
Changed:
<
<
  • POP FIFO - POP the specified field or record from the bottom of the stack - FIFO (first in, first out) manner, rather than LIFO
>
>
  • POP FIFO - POP the specified field or record from the bottom of the stack - FIFO (first in, first out) manner, rather than LIFO
  -- SteveFrizzell - 01 Oct 2008
<--/commentPlugin-->

Revision 182008-10-06 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

PUSH & POP ILF Statements

Line: 58 to 58
 (2) Application ID (3) File Name, field name, or predefined field (4) Occurrence (constant/index)
Changed:
<
<
(5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)
>
>
(5) Data item type (FIELD, RECORD)
 

The POP statement is used to pop (retrieve) a value that was saved with a PUSH statement.

Line: 67 to 67
  The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
Changed:
<
<
You may execute a POP statement for a specific field or file more than once.  Each time that you execute a POP statement, the value from the "top" of the stack of the referenced field or record is saved as the current value of the referenced field or record, the value is removed from the stack, and the True/False indicator is set.

The POP statement sets the True/False indicator.  If the stack for the referenced field or file contains a value, then the stack is popped and the next level of the true/false statsu indicator is set to T (true).  If the stack is empty, then the referenced field is set to its default value and the next level of the true/false indicator is set to F (false).

>
>
You may execute a POP statement for a specific field or file more than once.  Each time that you execute a POP statement, the value from the "top" of the stack of the referenced field or record is saved as the current value of the referenced field or record and the value is removed from the stack.  The POP statement also sets the True/False indicator.  If the stack for the referenced field or file contains a value, then the stack is popped and the next level of the true/false statsu indicator is set to T (true).  If the stack is empty, then the referenced field is set to its default value and the next level of the true/false indicator is set to F (false).
  Predefined fields may be referenced by a PUSH or POP statement. However, it is invalid to use the PUSH or POP statement for predefined fields that are non-modifiable.

The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.

Deleted:
<
<
The Data Item Type specification 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.

 When a POP statement references a field with an occurrence, the next value from the stack is popped into the specified occurrence of the reference field.

A sub-string field and a synonym field will each have their own stack since they have field names that are distinct from the field that they are derived from.

Line: 94 to 88
 

One 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.

Added:
>
>

Issues:

  1. The Data Item Type specification of the POP statement should only allow two options,  FIELD and RECORD.  The currently implementation of the statement also allows DEFAULT FIELD and ORIGINAL FIELD to be specified.  Both are treated the same as if FIELD was specified.  DEFAULT RECORD and ORIGINAL RECORD are also allowed and are treated as if RECORD was specified.  Application designers should always specifiy either FIELD or RECORD on a POP statement.  Do not specify DEFAULT FIELD, ORIGINAL FIELD, DEFAULT RECORD, or ORIGINAL RECORD on the POP statement.   These options may not be supported in a future release.
 

Comments:

Read what other users have said about this page or add your own comments.

Revision 172008-10-06 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

PUSH & POP ILF Statements

Line: 38 to 38
  The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.
Changed:
<
<
The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the  current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the  default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the process being executed has a PCF.
>
>
The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the  current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the  default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the referenced field is a field in the PCF or if the referenced file is the PCF of the currently executing process.
 
Changed:
<
<
Since there is only one stack for each field name and one stack for each file name, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated values onto a common (shared) stack for the specified field name and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffers onto a common (shared) stack for the specified record (file) name.
>
>
Since there is only one stack for each field name and one stack for each file name, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated value onto a common (shared) stack for the specified field name and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffer onto a common (shared) stack for the specified record (file) name.
  Multiple occurrences of a field also share a common stack.
Line: 61 to 61
 (5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)
Changed:
<
<
A distinct stack is associated with each field name and with each file name.

The PUSH statement is used to add  field and record values to a stack.

>
>
The POP statement is used to pop (retrieve) a value that was saved with a PUSH statement.
 
Changed:
<
<
The POP statement is used to retrieve field and record values from a stack.
>
>
A distinct stack is associated with each field name and with each file name.
  The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
Line: 73 to 71
  The POP statement sets the True/False indicator.  If the stack for the referenced field or file contains a value, then the stack is popped and the next level of the true/false statsu indicator is set to T (true).  If the stack is empty, then the referenced field is set to its default value and the next level of the true/false indicator is set to F (false).
Deleted:
<
<
The PUSH statement is used to PUSH the value of a field or record onto an internally maintained stack in memory.  The POP statement is used to POP (retrieve) a previously pushed value.
 Predefined fields may be referenced by a PUSH or POP statement. However, it is invalid to use the PUSH or POP statement for predefined fields that are non-modifiable.

The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.

Revision 162008-10-03 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

PUSH & POP ILF Statements

Line: 6 to 6
 
Added:
>
>
 

PUSH Statement

The PUSH statement saves a field or record value on an internally maintained stack for the indicated field or record. The structure of the statement is:

Line: 22 to 24
  A distinct stack is associated with each field name and with each file name.
Changed:
<
<
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field is the first value popped from the stack.
>
>
The PUSH statement is used to add  field and record values to a stack.

The POP statement is used to retrieve field and record values from a stack.

The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.

The value of the source field or record is not changed when a PUSH statement is executed.

You may execute a PUSH statement for a specific field or file more than once before you execute a POP statement to retrieve a value from the stack.  Each time that you execute a PUSH statement, the value of the referenced field or record is "pushed" onto the top of the stack associated with that field or file. Each time that you execute a POP statement, the next value is retrieved from the stack of the referenced field or record, stored as the current value of the referenced field or record, and removed from the top of the stack.

  The contents of predefined fields can also be saved using the PUSH statement. However, it is invalid to use the PUSH statement for predefined fields that are non-modifiable, since the POP command is invalid for those fields.
Changed:
<
<
The scope of a stack is the same as the scope of the associated field or file. 
>
>
The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.
  The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the  current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the  default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the process being executed has a PCF.
Line: 34 to 44
  Multiple occurrences of a field also share a common stack.
Changed:
<
<
A sub-string field and a synonym field will each have their own stack since they have field names that are distinct from the field that they are derived from.
>
>
A sub-string field and a synonym field each have their own stack since they have field names that are distinct from the field that they are derived from.

 

POP Statement 

Changed:
<
<
The POP statement pops a field or record value from an internally maintained stack and sets it into the indicated field or record. The structure of the statement is:
>
>
The POP statement pops a field or record value from an internally maintained stack and sets it as the current value of the indicated field or record. The structure of the statement is:
 

***** POP *** ********************** *** ***************

Line: 49 to 61
 (5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)
Changed:
<
<
 
      POP      AAA FILE OR FIELD NAME   OCC      TYPE
>
>
A distinct stack is associated with each field name and with each file name.
 
Changed:
<
<
The new PUSH and POP statements allow designers to load (PUSH) field or record data onto an internally maintained stack, and then retrieve (POP) them for use later. The structure of the statement is: (AAA is the application ID, OCC is the [optional] occurrence number.)
>
>
The PUSH statement is used to add  field and record values to a stack.
 
Changed:
<
<
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 is used to retrieve field and record values from a stack.
 
Changed:
<
<
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.
>
>
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field or record is the first value popped from the stack. There is no predefined limit as to how many field or record values may be pushed onto a stack.
 
Changed:
<
<
A sub-string field and a synonym field will each have their own stack since they have distinct field names. A field with multiple occurrences will have one stack. For example, a field named MYFILE FLD is defined with 2 occurrences. If you pushed MYFILE FLD (001) then pushed MYFILE FLD (002) the data will be saved in the stack named MYFILE FLD. To retrieve the saved values you would POP MYFILE FLD twice. The first POP would return MYFILE FLD (002), the second POP would return MYFILE FLD (001) as described above.
>
>
You may execute a POP statement for a specific field or file more than once.  Each time that you execute a POP statement, the value from the "top" of the stack of the referenced field or record is saved as the current value of the referenced field or record, the value is removed from the stack, and the True/False indicator is set.
 
Changed:
<
<
The stack inherites the scope (subprocess, related, or detached) from the field that is PUSH'ed.
>
>
The POP statement sets the True/False indicator.  If the stack for the referenced field or file contains a value, then the stack is popped and the next level of the true/false statsu indicator is set to T (true).  If the stack is empty, then the referenced field is set to its default value and the next level of the true/false indicator is set to F (false).
 
Changed:
<
<
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.
>
>
The PUSH statement is used to PUSH the value of a field or record onto an internally maintained stack in memory.  The POP statement is used to POP (retrieve) a previously pushed value.

Predefined fields may be referenced by a PUSH or POP statement. However, it is invalid to use the PUSH or POP statement for predefined fields that are non-modifiable.

The scope of a stack is the same as the scope of the associated field or file.  For example, if the scope of the referenced field is RELATED, then the scope of the associated stack will also be RELATED.

The Data Item Type specification 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.

When a POP statement references a field with an occurrence, the next value from the stack is popped into the specified occurrence of the reference field.

A sub-string field and a synonym field will each have their own stack since they have field names that are distinct from the field that they are derived from.

 

Examples

Revision 152008-10-03 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"

PUSH & POP ILF Statements

Line: 8 to 8
 

PUSH Statement

Changed:
<
<
The PUSH statement pushes a field or record value onto an internally maintained stack for the indicated field or record. The structure of the statement is:
>
>
The PUSH statement saves a field or record value on an internally maintained stack for the indicated field or record. The structure of the statement is:
 

***** PUSH *** ********************** *** ***************

Line: 20 to 20
 (5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)
Changed:
<
<
The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the process being executed has a PCF.
>
>
A distinct stack is associated with each field name and with each file name.
 
Changed:
<
<
Each field and each record has its own stack.
>
>
The stack has the internal structure of a LIFO list, i.e. the last value pushed onto the stack for a field is the first value popped from the stack.
 
Changed:
<
<
There is only one stack for each field name and one stack for each file name.  Consequently, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated values onto a common (shared) stack for the specified field and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffers onto a common (shared) stack for the specified record.
>
>
The contents of predefined fields can also be saved using the PUSH statement. However, it is invalid to use the PUSH statement for predefined fields that are non-modifiable, since the POP command is invalid for those fields.
 
Changed:
<
<
A sub-string field and a synonym field will each have their own stack since they have field names that are distinct from the field that they are derived from.
>
>
The scope of a stack is the same as the scope of the associated field or file. 

The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the  current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the  default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the process being executed has a PCF.

Since there is only one stack for each field name and one stack for each file name, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated values onto a common (shared) stack for the specified field name and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffers onto a common (shared) stack for the specified record (file) name.

 
Changed:
<
<
Multiple occurrences of a field share a common stack.
>
>
Multiple occurrences of a field also share a common stack.
 
Changed:
<
<
The stack for a field or record has the same scope (none, subprocess, related, or detached) as the field or record associated with it.
>
>
A sub-string field and a synonym field will each have their own stack since they have field names that are distinct from the field that they are derived from.
 

POP Statement 

The POP statement pops a field or record value from an internally maintained stack and sets it into the indicated field or record. The structure of the statement is:

Revision 142008-10-01 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"
Changed:
<
<

New ILF Statements

Application designers gain more control through these new ILF statements.
>
>

PUSH & POP ILF Statements

Release 5.0.0 of APPX implements the PUSH and POP ILF statements.
 
Changed:
<
<

PUSH and POP

The new PUSH and POP statements allow designers to load (PUSH) field or record data onto an internally maintained stack, and then retrieve (POP) them for use later. The structure of the statement is:
      PUSH     AAA FILE OR FIELD NAME   OCC      TYPE
and
      POP      AAA FILE OR FIELD NAME   OCC      TYPE
(AAA is the application ID, OCC is the [optional] occurrence number.)
>
>

PUSH Statement

 
Changed:
<
<
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 PUSH statement pushes a field or record value onto an internally maintained stack for the indicated field or record. The structure of the statement is:
 
Changed:
<
<
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.
>
>

***** PUSH *** ********************** *** *************** (1) (2) (3) (4) (5)

(1) T/F execution conditions  (2) Application ID (3) File Name, field name, or predefined field (4) Occurrence (constant/index) (5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)

 
Changed:
<
<
A sub-string field and a synonym field will each have their own stack. This is because the field names in the data dictionary are unique. A field with multiple occurrences will have one stack. For example, a field named MYFILE FLD is defined with 2 occurrences. If you pushed MYFILE FLD (001) then pushed MYFILE FLD (002) the data will be saved in the stack named MYFILE FLD. To retrieve the saved values you would POP MYFILE FLD twice. The first POP would return MYFILE FLD (002), the second POP would return MYFILE FLD (001) as described above.
>
>
The Data item type specification identifies which field value or record is to be pushed onto the stack.  If FIELD or RECORD is specified, then the current value of the field or record is pushed onto the stack.  If DEFAULT FIELD or DEFAULT RECORD is specified, then the default value of the field or record is pushed onto the stack.  If ORIGINAL FIELD or ORIGINAL RECORD is specified, then the original value of the field or record is pushed onto the stack.  ORIGINAL FIELD and ORIGINAL RECORD may only be specified if the process being executed has a PCF.
 
Changed:
<
<
The stack inherites the scope (subprocess, related, or detached) from the field that is PUSH'ed.
>
>
Each field and each record has its own stack.
 
Changed:
<
<
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.
>
>
There is only one stack for each field name and one stack for each file name.  Consequently, FIELD, DEFAULT FIELD, and ORIGINAL FIELD all push the indicated values onto a common (shared) stack for the specified field and RECORD, DEFAULT RECORD, and ORIGINAL RECORD all push the indicated record buffers onto a common (shared) stack for the specified record.
 
Changed:
<
<

SELECT

The SELECT statement allows the access path of in input process to be changed dynamically. The structure of the statement is:
>
>
A sub-string field and a synonym field will each have their own stack since they have field names that are distinct from the field that they are derived from.
 
Changed:
<
<
      SELECT  AAA FILENAME                        KEY IS  _____________________________
The application and file name must be specified, even though this statement is relevant only for the Process Control File (PCF). SCAN is available for the key field name, and only defined keys are presented as options.
>
>
Multiple occurrences of a field share a common stack.
 
Changed:
<
<
One reasonable use for the SELECT statement would be to facilitate access path switching by users, without them having to use F3 (SELECT ACCESS PATH), and perhaps in that way limiting which keys they can select. Note that the SELECT statement does not force KEY ENTRY phase, so, without further coding, a user not in KEY ENTRY would see no immediate change in view. It would seem that a valuable use would be to redisplay a scrolling screen using an alternate key, and to do so, the above defined PUSH and POP statements come in very handy. Here's an example:
>
>
The stack for a field or record has the same scope (none, subprocess, related, or detached) as the field or record associated with it.

POP Statement 

 
Changed:
<
<
The file is called TEST42. The primary key is TEST42 ID NO.. Alternate keys are defined as TEST42 CATEGORY and TEST42 REGION. The screen has three buttons defined, linked to User Option 1, 2, and 3. The Option Intercept Event Point contains the following code:
>
>
The POP statement pops a field or record value from an internally maintained stack and sets it into the indicated field or record. The structure of the statement is:
 

Changed:
<
<
    • First, we disable the SELECT ACCESS PATH option (F3) IF --- OPTION EQ SELECT ACCESS PATH
T SET --- OPTION =
    • Next, use the SELECT statement to set the desired path IF --- OPTION EQ USER 1
T SELECT TST TEST42 KEY IS TEST42 CATEGORY F IF --- OPTION EQ USER 2 FT SELECT TST TEST42 KEY IS TEST42 REGION FF IF --- OPTION EQ USER 3 FFT SELECT TST TEST42 KEY IS TEST42 ID NO FFF END
    • Ignore these buttons if pushed in ADD mode IF --- MODE EQ ADD
T END
    • Now, push the options into the stack to switch into KEY ENTRY
    • and redisplay the records (remember, last in, first out) SET --- OPTION = RETURN PUSH --- OPTION FIELD * IF --- MODE EQ DELETE
T SET --- OPTION = DELETE MODE F IF --- MODE EQ CHANGE FT SET --- OPTION = CHANGE MODE FF SET --- OPTION = INQUIRE MODE PUSH --- OPTION FIELD
>
>

***** POP * ******************** * ************* (1) (2) (3) (4) (5)

(1) T/F execution conditions  (2) Application ID (3) File Name, field name, or predefined field (4) Occurrence (constant/index) (5) Data item type (FIELD, RECORD, DEFAULT FIELD, DEFAULT RECORD, ORIGINAL FIELD, ORIGINAL RECORD)

 
Changed:
<
<
Finally, just add one line of code to Pre-Display:
>
>
 
 
Changed:
<
<
POP --- OPTION FIELD
>
>
POP AAA FILE OR FIELD NAME OCC TYPE
 
Changed:
<
<
>
>
The new PUSH and POP statements allow designers to load (PUSH) field or record data onto an internally maintained stack, and then retrieve (POP) them for use later. The structure of the statement is: (AAA is the application ID, OCC is the [optional] occurrence number.)
 
Changed:
<
<
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).

Limitations:

  1. 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.
>
>
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.

A sub-string field and a synonym field will each have their own stack since they have distinct field names. A field with multiple occurrences will have one stack. For example, a field named MYFILE FLD is defined with 2 occurrences. If you pushed MYFILE FLD (001) then pushed MYFILE FLD (002) the data will be saved in the stack named MYFILE FLD. To retrieve the saved values you would POP MYFILE FLD twice. The first POP would return MYFILE FLD (002), the second POP would return MYFILE FLD (001) as described above.

The stack inherites the scope (subprocess, related, or detached) from the field that is PUSH'ed.

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.

Examples

The following example shows how PUSH and POP can be used to swap the values of occurrences 1 and 2 of a field.

      PUSH     TOE ORDER1 SALESPERSON     001 FIELD
      PUSH     TOE ORDER1 SALESPERSON     002 FIELD
      POP      TOE ORDER1 SALESPERSON     001 FIELD
      POP      TOE ORDER1 SALESPERSON     002 FIELD

One 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.

 

Comments:

Read what other users have said about this page or add your own comments.
Line: 88 to 84
 -- SteveFrizzell - 01 Oct 2008
<--/commentPlugin-->

-- AlKalter - 04 Apr 2008

Added:
>
>
META TOPICMOVED by="SteveFrizzell" date="1222880268" from="Main.NewILFStatements" to="Main.PUSHPOPILFStatements"

Revision 132008-10-01 - SteveFrizzell

Line: 1 to 1
 
META TOPICPARENT name="APPX500Features"
Added:
>
>
 

New ILF Statements

Application designers gain more control through these new ILF statements.
Line: 72 to 72
  POP --- OPTION FIELD
Changed:
<
<
>
>
  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).
Changed:
<
<

Open Issues, Bugs, Suggestions

OPEN - 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.

OPEN - 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
>
>

Limitations:

  1. 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.
 

Comments:

Read what other users have said about this page or add your own comments.
Changed:
<
<
<--/commentPlugin-->
>
>
Here are a couple of ideas for additional related statements:
  • POP ALL - Empty the stack for the specified field or record
  • POP FIFO - POP the specified field or record from the bottom of the stack - FIFO (first in, first out) manner, rather than LIFO

-- SteveFrizzell - 01 Oct 2008

<--/commentPlugin-->
  -- AlKalter - 04 Apr 2008 \ No newline at end of file

Revision 122008-09-15 - SteveFrizzell

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="APPX43Features"
>
>
META TOPICPARENT name="APPX500Features"
 

New ILF Statements

Application designers gain more control through these new ILF statements.

Revision 112008-06-20 - JeffPrentice

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

New ILF Statements

Application designers gain more control through these new ILF statements.
Line: 22 to 22
  A sub-string field and a synonym field will each have their own stack. This is because the field names in the data dictionary are unique. A field with multiple occurrences will have one stack. For example, a field named MYFILE FLD is defined with 2 occurrences. If you pushed MYFILE FLD (001) then pushed MYFILE FLD (002) the data will be saved in the stack named MYFILE FLD. To retrieve the saved values you would POP MYFILE FLD twice. The first POP would return MYFILE FLD (002), the second POP would return MYFILE FLD (001) as described above.

Added:
>
>
The stack inherites the scope (subprocess, related, or detached) from the field that is PUSH'ed.

 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.

SELECT

Revision 102008-06-18 - JeffPrentice

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"
Deleted:
<
<
 

New ILF Statements

Application designers gain more control through these new ILF statements.
Line: 20 to 19
 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.

Added:
>
>
A sub-string field and a synonym field will each have their own stack. This is because the field names in the data dictionary are unique. A field with multiple occurrences will have one stack. For example, a field named MYFILE FLD is defined with 2 occurrences. If you pushed MYFILE FLD (001) then pushed MYFILE FLD (002) the data will be saved in the stack named MYFILE FLD. To retrieve the saved values you would POP MYFILE FLD twice. The first POP would return MYFILE FLD (002), the second POP would return MYFILE FLD (001) as described above.

 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.

SELECT

Revision 92008-06-03 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

New ILF Statements

Revision 82008-05-14 - PeteBrower

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

New ILF Statements

Line: 73 to 73
 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

Added:
>
>
OPEN -
 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.
Changed:
<
<
It appears that fields with multiple occurrences ARE NOT
>
>
OPEN - 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

Revision 72008-05-08 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

New ILF Statements

Line: 20 to 20
 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.

Deleted:
<
<
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.
Deleted:
<
<
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:
Line: 81 to 71
 

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).

Added:
>
>

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.

Revision 62008-05-06 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"
Added:
>
>
 

New ILF Statements

Application designers gain more control through these new ILF statements.
Line: 43 to 44
  The file is called TEST42. The primary key is TEST42 ID NO.. Alternate keys are defined as TEST42 CATEGORY and TEST42 REGION. The screen has three buttons defined, linked to User Option 1, 2, and 3. The Option Intercept Event Point contains the following code:
Changed:
<
<
>
>

 
    • First, we disable the SELECT ACCESS PATH option (F3) IF --- OPTION EQ SELECT ACCESS PATH
T SET --- OPTION =
Line: 70 to 71
 FT SET --- OPTION = CHANGE MODE FF SET --- OPTION = INQUIRE MODE PUSH --- OPTION FIELD
Changed:
<
<
>
>
  Finally, just add one line of code to Pre-Display:
Line: 79 to 80
 
Added:
>
>
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).
 

Comments:

Read what other users have said about this page or add your own comments.

Revision 52008-04-30 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"

New ILF Statements

Application designers gain more control through these new ILF statements.

Changed:
<
<

PUSH

POP

>
>

PUSH and POP

The new PUSH and POP statements allow designers to load (PUSH) field or record data onto an internally maintained stack, and then retrieve (POP) them for use later. The structure of the statement is:
      PUSH     AAA FILE OR FIELD NAME   OCC      TYPE
and
      POP      AAA FILE OR FIELD NAME   OCC      TYPE
(AAA is the application ID, OCC is the [optional] occurrence number.)

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:

Revision 42008-04-29 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"
Deleted:
<
<
 

New ILF Statements

Application designers gain more control through these new ILF statements.
Line: 22 to 21
 
      *     First, we disable the SELECT ACCESS PATH option (F3)
Deleted:
<
<
  IF --- OPTION EQ SELECT ACCESS PATH
Deleted:
<
<
 T SET --- OPTION =
Deleted:
<
<
 
    • Next, use the SELECT statement to set the desired path
Deleted:
<
<
  IF --- OPTION EQ USER 1
Changed:
<
<
>
>
 T SELECT TST TEST42 KEY IS TEST42 CATEGORY
Deleted:
<
<
 F IF --- OPTION EQ USER 2
Deleted:
<
<
 FT SELECT TST TEST42 KEY IS TEST42 REGION
Deleted:
<
<
 FF IF --- OPTION EQ USER 3
Deleted:
<
<
 FFT SELECT TST TEST42 KEY IS TEST42 ID NO
Deleted:
<
<
 FFF END
Deleted:
<
<
 
    • Ignore these buttons if pushed in ADD mode
Deleted:
<
<
  IF --- MODE EQ ADD
Deleted:
<
<
 T END
Deleted:
<
<
 
    • Now, push the options into the stack to switch into KEY ENTRY
Deleted:
<
<
 
    • and redisplay the records (remember, last in, first out)
Deleted:
<
<
  SET --- OPTION = RETURN
Deleted:
<
<
  PUSH --- OPTION FIELD
Deleted:
<
<
  *
Deleted:
<
<
  IF --- MODE EQ DELETE
Deleted:
<
<
 T SET --- OPTION = DELETE MODE
Deleted:
<
<
 F IF --- MODE EQ CHANGE
Deleted:
<
<
 FT SET --- OPTION = CHANGE MODE
Deleted:
<
<
 FF SET --- OPTION = INQUIRE MODE
Deleted:
<
<
  PUSH --- OPTION FIELD

Revision 32008-04-29 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"
Added:
>
>
 

New ILF Statements

Application designers gain more control through these new ILF statements.
Line: 8 to 9
 

PUSH

POP

SELECT

Added:
>
>
The SELECT statement allows the access path of in input process to be changed dynamically. The structure of the statement is:

      SELECT  AAA FILENAME                        KEY IS  _____________________________
The application and file name must be specified, even though this statement is relevant only for the Process Control File (PCF). SCAN is available for the key field name, and only defined keys are presented as options.

One reasonable use for the SELECT statement would be to facilitate access path switching by users, without them having to use F3 (SELECT ACCESS PATH), and perhaps in that way limiting which keys they can select. Note that the SELECT statement does not force KEY ENTRY phase, so, without further coding, a user not in KEY ENTRY would see no immediate change in view. It would seem that a valuable use would be to redisplay a scrolling screen using an alternate key, and to do so, the above defined PUSH and POP statements come in very handy. Here's an example:

The file is called TEST42. The primary key is TEST42 ID NO.. Alternate keys are defined as TEST42 CATEGORY and TEST42 REGION. The screen has three buttons defined, linked to User Option 1, 2, and 3. The Option Intercept Event Point contains the following code:

      *     First, we disable the SELECT ACCESS PATH option (F3)
      IF      --- OPTION                    EQ     SELECT ACCESS PATH
T     SET     --- OPTION                     =
      *     Next, use the SELECT statement to set the desired path
      IF      --- OPTION                    EQ     USER 1
T     SELECT  TST TEST42                       KEY IS  TEST42 CATEGORY
F     IF      --- OPTION                    EQ     USER 2
FT    SELECT  TST TEST42                       KEY IS  TEST42 REGION
FF    IF      --- OPTION                    EQ     USER 3
FFT   SELECT  TST TEST42                       KEY IS  TEST42 ID NO
FFF   END
      *     Ignore these buttons if pushed in ADD mode
      IF      --- MODE                      EQ     ADD
T     END
      *     Now, push the options into the stack to switch into KEY ENTRY
      *     and redisplay the records (remember, last in, first out)
      SET     --- OPTION                     =     RETURN
      PUSH    --- OPTION                    FIELD
      *
      IF      --- MODE                      EQ     DELETE
T     SET     --- OPTION                    =      DELETE MODE
F     IF      --- MODE                      EQ     CHANGE
FT    SET     --- OPTION                    =      CHANGE MODE
FF    SET     --- OPTION                    =      INQUIRE MODE
      PUSH    --- OPTION                    FIELD

Finally, just add one line of code to Pre-Display:

      POP     --- OPTION                    FIELD

 

Comments:

Read what other users have said about this page or add your own comments.
<--/commentPlugin-->
Deleted:
<
<
-- AlKalter - 04 Apr 2008
 \ No newline at end of file
Added:
>
>
-- AlKalter - 04 Apr 2008

Revision 22008-04-04 - AlKalter

Line: 1 to 1
 
META TOPICPARENT name="APPX43Features"
Added:
>
>

New ILF Statements

Application designers gain more control through these new ILF statements.
 
Added:
>
>
 
Added:
>
>

PUSH

POP

SELECT

Comments:

Read what other users have said about this page or add your own comments.
<--/commentPlugin-->
 

-- AlKalter - 04 Apr 2008 \ No newline at end of file

Revision 12008-04-04 - AlKalter

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="APPX43Features"

-- AlKalter - 04 Apr 2008

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback