SQL in COBOL ist wirklich denkbar einfach:

Dateityp SQLCBL oder SQLCBLLE (ich bevorzuge letzteres).
Alle SQL-Anweisungen beginnen mit EXEC SQL und enden mit END-EXEC und werden erst ab Bereich B Spalte 12 bis Spalte 71 akzeptiert.
Im Gegensatz zu RPG muss ich SQL-Hostvariablen explizit deklarieren, also:

WORKING STORAGE SECTION.
: die üblichen Definitionen
:
:
EXEC SQL SET OPTION ....
END-EXEC.
EXEC SQL INCLUDE SQLCA <= Wie Birgitta schon sagte, muss explizit eingebunden werden.
END-EXEC.

EXEC SQL BEGIN DECLARE SECTION
END-EXEC.
77 ...
01 ....
EXEC SQL END DECLARE SECTION
END-EXEC.

Alles zwischen BEGIN und END kann als SQL-Hostvariablen verwendet werden.
DECLARE-Sections kann es durchaus mehrfach geben (WORKING-STORAGE, LINKAGE).

In der PROCEDURE DIVISION kannst du dann ganz normales SQL überall einbetten.

EXEC SQL DECLARE GETDATA CURSOR FOR
SELECT ...
WHERE FELD = : MYHOSTVAR OF STRUKTUR
AND FELD2 = "ABCD"
END-EXEC

Einzige Einschränkung die ich bisher gefunden habe:
Da COBOL per Default nur 18-Stellig dezimal kann (PROCESS EXTEND31 / EXTEND63) akzeptiert der SQL-Precompiler keine Hostvariablen größer 18 Stellen.
Sollten diese benötigt werden kann man diese nur als z.B. PIC X(31) und als CAST-Funktion verwenden.

COBOL akzeptiert Konstanten wahlweise in Hochkommata (Warnmeldung 10 oder PROZESS APOST) oder Anführungsstrichen.
COBOL-Embedded SQL akzeptiert Konstanten ausschließlich in Anführungsstrichen!
Werte in Hochkommata wird als casesensitiver Feldname interpretiert.

Merken tut man das fast ausschließlich zur Laufzeit!
Vor Einführung der Globalen Variablen meckerte der Compiler das Fehlen von Variablen an (in Tabelle nicht gefunden).
Seit Einführung dieser Variablen (V7R1?) geht der Precompiler nun davon aus, dass das ja später globale Variablen sein könnten. Tippfehler werden also erst zur Laufzeit bestraft.

Und der Rest ist dann halt einfach SQL.