Only one application can allocate and access the CICS BAC control file at a time, and access is serialized by means of an exclusive systems-level enqueue. In this context, the application could be one of the following:
When the CICS BAC startup procedure runs in the CICS region, it starts the CICS BAC subtask, which obtains the enqueue and holds it until the CICS region is shut down, either normally or abnormally. If the CICS BAC batch request utility cannot obtain a systems-level enqueue using the same resource name (the region applid) used by the CICS BAC request server, it knows that the subtask is active and that its batch request utility input commands must be processed by EXCI requests passed to the CICS region. If it succeeds in obtaining the enqueue, it means that the CICS BAC request server subtask is not active and the batch request utility can allocate and open the control file itself and process itself those input commands that can be applied to the control file. This could be any of the SET commands but not the DEFAULT command, which is applicable, and local, only to the CICS BAC batch request utility.
By means of this enqueue technique, the requested status of a CICS resource can be set directly in the control file without the CICS region being active. Also, by ensuring that the CICS BAC startup procedure runs before any CICS resource can be opened, you make sure that the status specified in the control file is honored by the CICS region, because the CICS BAC startup processor checks all the resources in the control file and issues the necessary CICS SPI commands to enforce the required status in the CICS region.