Building the application control blocks (ACBGEN)
You can create application control blocks (ACBs) for each DBD and each PSB that is used in your system by running either the ACB Maintenance utility or the ACB Generation and Catalog Populate utility (DFS3UACB).
The utilities generate the ACBs from the database definitions (DBDs) and program specification blocks (PSBs) in the IMS.DBDLIB and IMS.PSBLIB data sets that the utility reads as input. Each generated ACB is stored as an ACB library member in the IMS.ACBLIB data set.
Depending on which utility you use to generate the ACBs and whether the IMS catalog is enabled, the IMS catalog can be populated either during the ACB generation process or afterward.
The DFS3UACB utility generates the ACB and populates the IMS catalog in the same job step, which ensures that the IMS catalog stays current with the ACB library. If you use the ACB Maintenance utility, which only generates the ACB members, the IMS catalog can be populated later by using the IMS Catalog Populate utility (DFS3PU00). However, if you populate the IMS catalog later, you risk running IMS with an IMS catalog that is not current to the ACB library.
ACBs are loaded into storage for online use from the IMS.ACBLIB data set either when the IMS control region is initialized or when an application program that requires the ACB is scheduled, depending on whether the ACB is resident or non-resident.
In online storage, the ACBs for PSBs and the ACBs for DBDs are stored separately in a PSB pool and DMB pool, respectively. The storage for these pools must be allocated by using sizes based on the number and size of each type of ACB member.
If the program or database from which an ACB is built is defined as resident during system definition, IMS loads the ACB into 31-bit storage during the initialization of the IMS control region. Resident ACB members persist in storage until IMS is shut down.
If the program or database from which an ACB is built is not defined as resident during system definition, IMS loads the non-resident ACB into 31-bit storage only when an application program that requires it is scheduled. Non-resident ACB members persist in storage only until the storage allocated for the non-resident ACBs is exhausted, at which time IMS frees storage by removing the ACBs that are unused for the longest period.
Non-resident ACB members can also be cached in a 64-bit storage pool to potentially improve the performance of program scheduling and reduce the usage of 31-bit storage. When 64-bit caching is enabled, when a non-resident ACB is first loaded into the 31-bit storage pool, it is also cached in the 64-bit storage pool. Later, if any non-resident ACBs that were removed from online storage are required by a scheduled application program, the ACBs are retrieved from 64-bit storage instead of from the IMS.ACBLIB data set on DASD.
Caching ACBs in the 64-bit storage is enabled by specifying the ACBIN64 parameter on the DFSDFxxx PROCLIB member. You can display information about the ACBs cached in 64-bit storage by using the type-2 command QUERY POOL TYPE(ACBIN64).
The sizes of the PSB pools and DMB pools are determined by the number and size of the ACB library members. Because PSBs and DMBs are stored together in 64-bit storage pools, the size of a 64-bit storage pool must be large enough to contain all of the non-resident PSBs and DMBs combined. The size of an ACB member is reported by the Application Control Blocks (ACB) Maintenance utility when the ACB members are built.
For execution in a batch environment, IMS can build ACBs dynamically or IMS can use prebuilt ACBs. To build ACBs dynamically, DLI must be specified on the PARM parameter of the batch startup procedure. To use prebuilt ACBs, DBB must be specified on the PARM parameter of the batch startup procedure. Prebuilt ACBs are stored in the IMS.ACBLIB data set pointed to by the IMSACBx DD statement in the startup procedure. IMS provides the DLIBATCH procedure to run a batch job that uses dynamically built ACBs and the DBBATCH procedure to run a batch job that uses prebuilt ACBs. For information about these procedures, see IMS Version 13 System Definition.
For batch application programs, IMS does not support 64-bit caching of ACBs.
For online application programs, ACBs must be prebuilt.
For GSAM DBDs, ACBs cannot be prebuilt. However, ACBs can be prebuilt for PSBs that reference GSAM databases.
You can prebuild ACBs for all PSBs in IMS.PSBLIB, for a specific PSB, or for all PSBs that reference a particular DBD. Prebuilt ACBs are kept in the IMS.ACBLIB library. The IMS.ACBLIB library is not used if ACBs are not prebuilt. When ACBs are prebuilt and an application program is scheduled, the application program's ACB is read from IMS.ACBLIB directly into storage. This means that less time is required to schedule an application program. In addition, less storage is used if prebuilt ACBs are used.
When the ACBs are prebuilt by a utility, the utility checks for errors in the names that are used in the PSB and the DBDs that are associated with the PSB. If erroneous cross-references are found, the utility prints appropriate error messages.
IMS.ACBLIB must be used exclusively. Because of this, the utility that generates the ACBs can be run only using an IMS.ACBLIB that is not currently allocated to an active IMS system. Also, because IMS.ACBLIB is modified, it cannot be used for any other purpose during execution of the utility that is generating the ACBs.
You can change ACBs or add ACBs in an inactive
copy of ACBLIB and then
make the changed or new members available to an active IMS
online system by using the online change function.
Additional information about creating and sizing DMB pools, PSB pools, and 64-bit non-resident ACB storage pools can be found in:
- IMS Version 13 System Administration
- IMS Version 13 System Definition