CA ADS Batch Concepts › Application Structure › Accessing Input Files with Multiple Record Layouts

Accessing Input Files with Multiple Record Layouts

Application structures have a special use in CA ADS Batch in enabling applications to access input files with multiple record layouts.

For example, consider an application that reads a file containing two types of records stored together: TYPE1 records and TYPE2 records. Each type of record has its own record layout. Additionally, the first two bytes of each record identify the record type: T1 for TYPE1 records and T2 for TYPE2 records.

You define a map for each record layout and associate each map with a dialog (DIALOG1 and DIALOG2). At runtime, the runtime system must use the proper dialog for each input record. Since the sequence of record layouts on input is not predictable, the runtime system must know ahead of time which dialog to execute for each possible record layout. This is done by defining an application structure using the application compiler.

The diagram below shows the application structure and provides sample input data. Response T1 invokes function FUNCTION1, which executes dialog DIALOG1. Response T2 invokes function FUNCTION2, which executes dialog DIALOG2. Both responses are valid from both functions.

Application Execution

Application execution is described below:

1. FUNCTION1 executes DIALOG1. DIALOG1 performs a mapin operation.
2. The runtime system examines the response field of the first input record; it is a T1 record. Since T1 invokes the current function, the runtime system maps the record into variable storage and selects and executes a response process. The response process processes the record, then issues a READ TRANSACTION command, which terminates the current process and performs another mapin operation.
3. The runtime system examines the response field of the second input record; it, too, is a T1 record. The record is mapped in and the response process is executed. The response process issues a READ TRANSACTION command, which terminates the current process and performs another mapin operation.
4. The runtime system examines the third input record; it is a T2 record. Since T2 invokes FUNCTION2, control passes immediately to FUNCTION2, which executes DIALOG2. The record has not yet been mapped into variable storage. DIALOG2 performs a mapin operation.
5. The runtime system immediately maps the third record into variable storage (its response field was already examined) and selects and executes a response process. The response process issues a WRITE TRANSACTION command, which terminates the current process, maps a record to the dialog's output file, then performs a mapin operation.
6. The runtime system examines the response field of the fourth input record; it is a T1 record. The runtime system immediately invokes FUNCTION1, which executes DIALOG1. DIALOG1 performs a mapin operation.
7. The runtime system immediately maps the fourth record into variable storage, then selects and executes a response process. The response process issues a READ TRANSACTION command, which terminates the current process and performs a mapin operation.
8. The runtime system attempts to examine the response field of a fifth input record, but encounters an end-of-file condition.

   Two ways for the application to handle an end-of-file condition are described below:

   • The application can be defined so that the end-of-file condition selects a function whose dialog handles the condition.
   • A response process in DIALOG1 and DIALOG2 can be associated with the end-of-file condition; the response process would be selected and executed when the condition occurred.