Interprocess Communication


In APPX, you develop applications by defining and connecting processes. When a user runs an application, information may need to be shared among the processes that form the application. Interprocess Communication, or IPC, refers to the set of specifications and statements by which you control how data is communicated among processes.

Consider an application in which the user is asked to enter the CURRENT ACCOUNTING MONTH on the first screen that is presented. You want this information to be available to any process in the application. You can use the IPC facilities within APPX to communicate the CURRENT ACCOUNTING MONTH to all the processes within the application.

Now consider an order entry function that consists of an input process to enter sales order information, and a subsidiary input process to enter individual line items for each order. In this case, the order information entered in the first process must be communicated to the line item process. For example, line item pricing may depend on information about the customer entered for the order. Again, you can use the IPC facilities within APPX to communicate between these two processes.

Interprocess Communication is specified implicitly based on the following:

·    Invocation type specification in the Automatic/Optional Child processes

·    File Type of data dictionary record structures

·    Share Class of Work Fields

Any process can be invoked as DETACHED or RELATED, or as a SUBPROCESS. When working with temporary files, it is important to know how the file type and the process invocation are related and interact. Child process invocations are defined at the following points in process specifications:

·    Menu item specifications are optional child processes. The default invocation for menu items is DETACHED.

·    Job/step item specifications are automatic child processes. The default invocation for job steps is RELATED.

·    Input frames can invoke automatic child processes, and input images can invoke optional child processes. The default invocation for input child processes is SUBPROCESS.

·    Output, update, and inquiry frames can invoke automatic child processes. The default invocation for these child processes is SUBPROCESS.

·    ILF statements can invoke any process. The default invocation when entering ILF statements is DETACHED.

Any temporary file is available only to the user who creates it. When a user creates a DETACHED temporary file, it remains available until the user exits APPX.

When a RELATED temporary file is created, it remains available until a DETACHED process is invoked, or until the process stream returns to the parent that called it with a DETACHED invocation (for example, a menu). It is important to note that, although a DETACHED child process cannot access a RELATED temporary file, that file remains available to the parent that created it until the parent itself is ended. If the DETACHED child process attempts to access that file, a new, empty copy of the file will be created.

When a SUBPROCESS temporary file is created, it remains available until a DETACHED or RELATED process is invoked, or until the process stream returns to a parent that called it with a DETACHED or related invocation (for example, a job step or a menu). As with RELATED temporary files, it is important to note that, although DETACHED or related child processes cannot access a SUBPROCESS temporary file, that file remains available to the parent that created it until the parent itself is ended. If a DETACHED or related child process attempts to access that file, a new, empty copy of the file will be created.

Current record buffers, field contents, and file pointers are all available transparently through a SUBPROCESS invocation. They are not maintained for related or DETACHED process invocations.

Whether or not a job step is invoked as a “separate task” also affects the availability of a RELATED or DETACHED temporary file. If the designer allows a job step to be invoked as a separate task (i.e., submitted to background), APPX makes a copy of the RELATED or DETACHED temporary file and passes it to the child process being invoked as a separate task. The file is then available to the child process but, if the child process updates the file, those updates will never be available to the parent process.

APPX automatically scratches temporary files based on their interprocess communication characteristics. For example:

·    DISK/SUBPROCESS and MEMORY/SUBPROCESS files are local temporary files. These temporary files are only accessible by a single process family, and exist only for the duration of that process family. Each time a process is run that references a SUBPROCESS temporary file, a separate copy is maintained and, when that process ends, APPX automatically scratches the temporary file.

·    DISK/RELATED and MEMORY/RELATED files are normal temporary files. They are passed and shared to non-detached processes (to SUBPROCESS processes and related processes). APPX automatically scratches a RELATED temporary file when the non-detached process family ends.

·    At the other extreme, DISK/DETACHED and MEMORY/DETACHED files are global temporary files. All processes that reference a global temporary file use the same temporary file. APPX automatically scratches a global temporary file only when the APPX session ends.

·    The exception to these DETACHED/RELATED/SUBPROCESS (also called "Scoping", "Inheritance", or "Sharing") rules, occurs with QUERY processes. Please see the description under the predefined field PROCESS CODE, in Chapter 4-7: Predefined Fields and Processes for a more detailed explanation of the special inheritance rules with respect to QUERY processes.