Source code for PGM3

 

Here is the source code for PGM3. Figure 1. Source code for PGM3

    …
     EXEC SQL        INSERT INTO TAB VALUES(:st1);
     EXEC SQL COMMIT;
    ....

Commands to create program and SQL package for PGM3:

CRTSQLCI OBJ(PGM3) COMMIT(*CHG) RDB(SYSD) OBJTYPE(*MODULE)
CRTPGM PGM(PGM3) ACTGRP(APPGRP)
CRTSQLPKG PGM(PGM3) RDB(SYSD)

REQTEXT

In this example, PGM1 is a non-ILE program created using the CRTSQLCBL command. This program runs in the default activation group. PGM2 is created using the CRTSQLCI command, and it runs in a system-named activation group. PGM3 is also created using the CRTSQLCI command, but it runs in the activation group named APPGRP. Because APPGRP is not the default value for the ACTGRP parameter, the CRTPGM command is issued separately. The CRTPGM command is followed by a CRTSQLPKG command that creates the SQL package object on the SYSD relational database. In this example, the user has not explicitly started the job level commitment definition. SQL implicitly starts commitment control.

  1. PGM1 is called and runs in the default activation group.

  2. PGM1 connects to relational database SYSB and runs a SELECT statement.

  3. PGM1 then calls PGM2, which runs in a system-named activation group.

  4. PGM2 does a connect to relational database SYSC. Because PGM1 and PGM2 are in different activation groups, the connection started by PGM2 in the system-named activation group does not disconnect the connection started by PGM1 in the default activation group. Both connections are active. PGM2 opens the cursor and fetches and updates a row. PGM2 is running under commitment control, is in the middle of a unit of work, and is not at a connectable state.

  5. PGM2 calls PGM3, which runs in activation group APPGRP.

  6. The INSERT statement is the first statement run in activation group APPGRP. The first SQL statement causes an implicit connect to relational database SYSD. A row is inserted into table TAB located at relational database SYSD. The insert is then committed. The pending changes in the system-named activation group are not committed, because commitment control was started by SQL with a commit scope of activation group.

  7. PGM3 is then exited and control returns to PGM2. PGM2 fetches and updates another row.

  8. PGM3 is called again to insert the row. An implicit connect was done on the first call to PGM3. It is not done on subsequent calls because the activation group did not end between calls to PGM3. Finally, all the rows are processed by PGM2 and the unit of work associated with the system-named activation group is committed.

 

Parent topic:

Connection management and activation groups