Difference: PUSHPOPILFStatements (13 vs. 14)

Revision 142008-10-01 - SteveFrizzell

 			 META TOPICPARENT 
			 name="APPX500Features"
- META TOPICPARENT
+ name="APPX500Features"
-<
<
+ 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.
   PUSH & POP ILF Statements 
  PUSH Statement
   POP Statement
   Examples
   Issues:
   Comments:
-<
<
+ 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
-<
<
+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:
-<
<
+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)
-<
<
+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.
-<
<
+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.
-<
<
+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.
-<
<
+ 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.
-<
<
+      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.
-<
<
+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
-<
<
+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:
-<
<
+     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)
-<
<
+Finally, just add one line of code to Pre-Display:
->
>
-<
<
+      POP     --- OPTION                    FIELD
->
>
+      POP      AAA FILE OR FIELD NAME   OCC      TYPE
-<
<
->
>
+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.)
-<
<
+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: 
 
 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.
 -- SteveFrizzell - 01 Oct 2008  
  (Edit - Preview)
 
<--/commentPlugin--> 

-- AlKalter - 04 Apr 2008
->
>
+			 META TOPICMOVED 
			 by="SteveFrizzell" date="1222880268" from="Main.NewILFStatements" to="Main.PUSHPOPILFStatements"
- META TOPICMOVED
+ by="SteveFrizzell" date="1222880268" from="Main.NewILFStatements" to="Main.PUSHPOPILFStatements"

View topic | History: r21 < r20 < r19 < r18 | More topic actions...