Activation groups and threads

All programs and service programs are activated within a substructure of a job that is called an activation group. This substructure contains the resources necessary to run the programs, including static and heap storage, and temporary data management resources.

In a job capable of multithreaded operation, two or more threads can share an activation group. A thread can run programs that were activated in different activation groups. The system does not keep a list of threads that run in an activation group or a list of activation groups in a thread. Ending an activation group while other threads are active in it can produce unpredictable results including abnormal end of the process. To avoid these problems, any action that ends an activation group in a secondary thread causes the system to end the job in an orderly fashion. In other words, the system ends all threads in the job, calls exit routines and C++ destructors in the initial thread, and finally closes the files.

When working with activation groups, consider the following items:
  • Return from activation groups:

    Programs created with ACTGRP(*NEW) get a new activation group every time it is called. When the program returns, the new activation group ends. In jobs capable of multithreaded operation, returning from programs that were created with ACTGRP(*NEW) will end the job.

    Both default and named activation groups are persistent. The Default activation group is created when a job starts and is destroyed only when the job ends. Named activation groups are created when they are first needed in a job. A normal return from the named activation group leaves the activation group in last-used state, but does not delete the activation group. Hence, in a job capable of multithreaded operations, a normal return from the default or named activation group does not cause the job to end.

    Using exit() or abort() in any activation group in a secondary thread always ends the job.

  • Unhandled exceptions:

    If an exception has not been handled by the time it has percolated to the control boundary and the control boundary is a program entry procedure (PEP or main entry point), the multithread-capable job is ended.

  • Reclaim activation group (RCLACTGRP):

    Jobs capable of multithreaded operation allow this command to be called only in the initial thread on the job. If secondary user threads are present in the job, this command sends a CPF180B escape message to the caller of the command.

Related concepts
Thread safety