1. Reusable Code For Your Appx Processes Presented By: Gary Rogers

2. Creating Reusable Code in Appx  What is Reusable Code in Appx?  How Do You Access Reusable Code?  Scope of Shared Fields  Sharing Fields Between Processes Session Topics:

3. Creating Reusable Code in Appx What is reusable code in Appx? Reusable Code are libraries that can be used by multiple processes. In Appx these are usually subroutine processes. With the use of the pass and receive statements almost any process can be made reusable.

4. Creating Reusable Code in Appx How is reusable code used in Appx? Reusable Code is accessed mainly by the use of three commands in ILF: COPY GOSUB SUBR Each command has a unique way of inserting the code into your process.

5. Creating Reusable Code in Appx The COPY Command: The COPY command inserts the code from the subroutine process inline with your ILF code. It is compiled into the EM as part of your process. Code included by the COPY command inherits the true/false indicators of your code. All fields within your process are accessible to the called routine.

6. Creating Reusable Code in Appx The GOSUB Command: The GOSUB command inserts the code from the subroutine at the end of your process and wraps it within a label and return statement. It is also compiled into the EM as part of your process. Code executed by the GOSUB command receives its own set of true/false indicators. All fields within your process can be updated by the called routine.

7. Creating Reusable Code in Appx The SUBR Command: The SUBR command does not insert code into your process. It is compiled as its own EM and is executed as a separate process at run time. Fields in your process may or may not be accessible to the routine depending on the invocation level of the routine and the share class of your variables.

8. Creating Reusable Code in Appx Your subroutine looks like this:

9. Creating Reusable Code in Appx If your ILF looks like this:

10. Creating Reusable Code in Appx Appx treats it like this:

11. Creating Reusable Code in Appx And if your ILF is like this:

12. Creating Reusable Code in Appx Appx treats it like this:

13. Creating Reusable Code in Appx Sharing Variables Between Routines: Variables are shared by inclusion using the COPY or GOSUB commands. Variables are generally shared between processes two ways:  Setting the share class

14. Creating Reusable Code in Appx Share Class: Share class sets the level at which a variable is exposed to change within a process. There are three levels of Share Class:  Detached  Related  Subprocess

15. Creating Reusable Code in Appx Detached Share Class: This is the highest level of sharing. Variables with this class are accessible until the current session of Appx ends. Any process at any share class can modify the variables value and all other processes will see the change.

16. Creating Reusable Code in Appx Related Share Class: Variables with a related class are accessible to the current process and any related or subprocess tasks of the parent. The variable’s value is not accessible to child processes that are invokes detached. The variable remains accessible until the process tree returns back to a detached process parent.

17. Creating Reusable Code in Appx Sharing Variables Between Routines: Variables are shared by inclusion using the COPY or GOSUB commands. Variables are generally shared between processes two ways:  Setting the share class  Using PASS and RECEIVE

18. Creating Reusable Code in Appx The Pass Statement: The PASS statement is used to make a variable available to another process, either internal or external to Appx. When used with the RECEIVE statement you can set a flag to indicate if the PASSed value can be modified or not.

19. Creating Reusable Code in Appx The PASS statement causes the indicated area to be passed to the next subroutine, process, or external program that is executed via a GOSUB, CALL, RUN, or process-type statement (i.e., INPUT, INQUIRY, JOB, MENU, OUTPUT, QUERY, STATUS, SUBR, UPDATE), or to the next automatic or optional child process that is run. See the next section, PASS Lists, for a discussion of how PASS lists are maintained and cleared.GOSUB CALLRUNINPUTINQUIRYJOB MENUOUTPUTQUERYSTATUSSUBRUPDATEPASS Lists PASS SHARE? (1) (2) (3) (4) (5) (6) (1) T/F execution conditions(2) Application ID(3) Field name or predefined field(4) Occurrence (constant/index)(5) Area type (FIELD)(6) Share? (Y/N)T/F execution conditionsApplication IDField name or predefined fieldOccurrenceindex From the Designer Reference Manual:

20. Creating Reusable Code in Appx The Pass Stack: As each PASS statement is executed the values are written to the end of a stack. When a statement that receives a value is executed the next value is taken from the top of the stack.

21. Creating Reusable Code in Appx The Pass Stack: Each PASS statement adds to a single list until the execution of a GOSUB, CALL, RUN, or process- type statement, or the invocation of an automatic or optional child process. Upon such execution, only the values in the current PASS list are passed.

22. Creating Reusable Code in Appx The Pass Stack: The called process can in turn execute PASS statements. These statements then build another PASS list which is maintained until that process terminated in the same manner. Each PASS list is cleared when execution returns to the routine or level which established it.

23. Creating Reusable Code in Appx The Receive Statement: The RECEIVE statement is used to make a variable available from another process. Depending on the settings of the PASS statement, the variable may modified by the routine and returned to the calling process or used internally within the routine without affecting the calling process.

24. Creating Reusable Code in Appx The RECEIVE keyword can be used for different purposes. The RECEIVE statement works with the PASS statement to implement true subroutines. Or, it works without the PASS statement to essentially declare a local variable (a field that is automatically restored to its initial value when the subroutine, event point, or process ends).PASS RECEIVE (1) (2) (3) (4) (1)T/F execution conditions(2) Application ID(3) Field name or predefined field(4) Occurrence (constant/index)T/F execution conditionsApplication IDField name or predefined field Occurrenceindex Sets True/False Status Indicator The RECEIVE statement sets the next status indicator to T if a matching PASS statement was found and to F if not. If you RECEIVE without a PASS statement, you are simply declaring a local variable that is restored to its initial value when the subroutine, event point, or process ends.PASS

25. Creating Reusable Code in Appx The RECEIVE statement can be used in subroutines internal to an event point or in the Start of Process event point of a process. This usage extends the creation of reusable code to processes as well. A generic input can be created to accept values through the receive statement to process and display information to the user.

26. Creating Reusable Code in Appx The RECEIVE statement originally required that the PASSed and RECEIVEd field types be the same. Appx now supports passing and receiving unlike field types. The equivalent of a SET is performed. Receive will also now allow constant values.

27. Creating Reusable Code in Appx A RECEIVE statement without a corresponding PASS statement has the effect of creating a variable local to the routine. This variable can be manipulated in the routine without affecting the value in the calling process. This would be the equivalent of a STORE/RESTORE in your code.

28. Creating Reusable Code in Appx The RECEIVE statement sets the next True/False condition. If there is a value in the pass stack for the RECEIVE the true flag is set. If no value is available then false is set. You can set the RECEIVE in a loop and continue receiving until a false condition in order to create a process with a variable amount of arguments.

29. Creating Reusable Code in Appx It is not safe to assume that a PASS with a Shared flag of N will protect your variable. If the share class of the variable and the process allow it, the variable may still be affected. To create a truly local variable for that “Black Box” type of routine you can RECEIVE each variable. In Release 4.2 a LOCAL command will be added to accomplish this.