This section describes the COBOL code generated by the embedded SQL preprocessor.

COBOL stores string and character data in a machine‑dependent data item (UNIX and Windows) or descriptor (VMS). The embedded SQL runtime routines are written in another language (C) that verifies lengths of strings by the location of a null (LOW‑VALUE) byte. Consequently, COBOL strings must be converted to embedded SQL runtime strings before the call to the runtime routine is made.

In some languages, embedded SQL generates a nested function call that accepts as its argument the character data item (UNIX and Windows) or VAX string descriptor (VMS) and returns the address of the embedded SQL null‑terminated string. COBOL does not have nested function calls, and simulating this would require two expensive COBOL statements. Embedded SQL/COBOL knows the context of the statement, and in most cases will MOVE the COBOL string constant or data item in a known area that has already been null‑terminated. This extra statement is cheaper than the nested function call of other languages, as it generates a single machine instruction. Even though your COBOL‑generated code may look wordier and longer than other embedded SQL‑generated code, it is actually as efficient.

There are some statements that normally generate an IF‑THEN-ELSE construct in other languages that instead generate IF‑GOTO constructs in COBOL. The reason for this is that there is no way to ensure that no embedded SQL‑generated (or programmer‑generated) period will appear in an IF block. Consequently, in order to allow any statement in this scope, embedded SQL generates an IF‑GOTO construct.

The code generated by embedded SQL for this construct is actually very similar to the code generated by any compiler for an IF‑THEN‑ELSE construct and is no less efficient.

COBOL supports function calls with the USING clause (UNIX) or the GIVING clause (VMS). This allows a function to return a value into a declared data item. Embedded SQL generates many of these statements by assigning the return values into internally declared data items, and then checking the result of the function by checking the value of the data item. This is obviously less efficient than other languages that check the return value of a function by means of its implicit value (stored in a register).

COBOL has the overhead of assigning the value to a variable. An embedded SQL/COBOL generated function call that tests the result may look like: