OptApply reformats plastic steps into concrete steps.
Data from a USING Data parcel is set in a parameterized PK request, if present, into the concrete steps. For other parameterized requests, the Parameterized Value Peek subsystem may place USING data into the parse tree prior to the Query Rewrite/Optimizer phases of request processing. If not peeked, parameterized data is attached as part of the concrete step.
Concrete steps are passed to the Dispatcher, which then distributes them to the AMPs via the BYNET.
For more information on the Parameterized Value Peek subsystem, see Parameterized Requests.
Block Diagram of OptApply Activity
The following diagram illustrates OptApply activity:
The OptApply component of the Parser engages in the following processing stages:
- OptApply receives the plastic steps for a request from the request cache or from the Generator.
- The plastic steps are compiled into executable machine code.
- OptApply retrieves any parameterized PK request Data parcels associated with the Request parcel and applies them to the plastic steps, creating concrete steps.
Concrete steps are also referred to as AMP steps.
For any simple data-driven iterative insert request, the system optimizes the operation by processing multiple insert operations in a single AMP step.
Note that the system performs this optimization only for simple iterated insert requests.
- The concrete steps are sent to the Dispatcher, which sends them across the BYNET to the AMPs.
Definition of Concrete Steps
Concrete steps are context- and data-laden AMP directives that contain user- and session-specific information in addition to Data parcels.
Each concrete step is composed of four parts:
|System message header||Contains the message class and kind, length, logical host identifier, session and request number, version number, and character set code.|
|Common step header||Contains account numbers and routing information.
Specifies who is to receive the step, what should be done with the responses generated by the step, how the AMPs signal task completion, and what is the context for the step (for example, a transaction number).
|Step components||A series of operation-dependent fields including step flags and the step mode.|
|Data||Contained in a varying length data area.|