In SCLM, you can have applications that support DB2® processing. Before SCLM can correctly interact with DB2, the DB2 system must be installed and fully operational.

DB2 support in SCLM can be split into two areas:

• Creation of the DBRM (Database Request Module)
• Binding the package or plans

The creation of the DBRM is handled in the language translator you have used to compile your program. Generally there will be a DSNHPC step that interprets the SQL and creates the DBRM and passes the modified source through to the compiler. The DBRM type will be an SCLM defined type. This means that the build map for the source member will contain outputs for DBRM as well as OBJ and LIST.

The key to the SCLM processing is how to let SCLM know that a DB2 bind is required when a module containing DB2 statements is built. This is handled through the DB2CLIST and DB2OUT language translators, which are shipped with SCLM. They are discussed in more detail in Generating a project environment.

To create the link between the compilable program, the load module, and the plan or package, we must create a DB2CLIST for each bindable object. The term "DB2CLIST" is used for historical reasons but this member is now more likely to be written as a REXX exec than a CLIST. This DB2CLIST member specifies the names of the DBRMs that will be bound. For example, if your site uses plans, the DB2CLIST would contain entries for all the DBRMs in the plan. If your site uses packages, the DB2CLIST will just contain one DBRM entry for the package DBRM. These scenarios are discussed with examples in Create DB2 CLIST.

The DB2CLIST is a REXX exec or CLIST. It sets up any variables required for the bind and then either performs the bind or calls an external bind processor to take the parameters and perform the bind. Because the DB2CLIST is controlled by SCLM, it contains accounting information and can be built. The DB2CLIST can be referenced from architecture definitions. By using High Level (HL) architecture definitions you can link the LEC archdefs that control the compilation and link to the generic archdef that controls the bind. See Getting started for some examples.

The processing of a DB2CLIST in SCLM has the following stages. Assume at this time that you have a program containing SQL and a LEC archdef to build that program:

1. During the Editing stage, you must create a DB2CLIST as described in Create DB2 CLIST. When parsed, the DBRMs to be bound are identified by the %INCLUDE statement in the comment block and an entry is placed in the accounting information for the DB2CLIST. SCLM will then know that when that particular DBRM is recreated during compilation, it will need to rebuild the DB2CLIST member.
2. During the BUILD stage, the DB2CLIST member is executed to perform the appropriate BIND or FREE DB2 operation. An identical copy of the DB2CLIST, called a DB2OUT, is created and placed in the type that is used during the PROMOTE stage. The DB2OUT is an SCLM output generated by the DB2CLIST translator and as such is non-editable.

   The only difference between the original DB2CLIST and the new DB2OUT is the language value. The language for the original DB2CLIST is associated with a language definition that contains the parsing and build translators. This language definition is DB2CLIST. It can be found in the SCLM sample library (member FLM@BD2). The language for the new DB2OUT is associated with a language definition that contains the copy and purge translators. This language definition is DB2OUT. It can be found in the SCLM sample library (member FLM@BDO).

3. On promote, SCLM will not execute the DB2CLIST but only promote it. However, on promote the COPY and PURGE phases of the translators are executed and as such will run the contents of the DB2OUT member. This is why the DB2 translator creates a DB2OUT. The DB2OUT will be processed in exactly the same way that BUILD processed the DB2CLIST. On the COPY phase the DB2OUT will be executed with the BIND option and on the PURGE phase the DB2OUT will be executed with the FREE option if you wish to free the plan or package at the from-group level.

In your high-level architecture definitions, always refer to the DB2CLIST used during the Build stage. Do not refer to the DB2OUT used during the Promote stage.