You can choose to define resource definitions for CICS BAC using the Windows workstation client (see The CICS BAC workstation administration client ), in which case you need to create one or more communication servers. A CICS BAC communication server, which runs in its own MVS™ address space, provides the functions you need on the mainframe to send and receive requests from the client over a standard TCP/IP connection. The communication server channels requests from the workstation to the appropriate CICS® region to update its CICS BAC control file. If the CICS region is not available, the communication server itself attempts to allocate and open the control file, and process the request. For more information about how the communication server handles requests to update a CICS BAC control file, see CICS BAC workstation administration client.
Note that you need a communication server only if you plan to use the CICS BAC workstation administration client. If you perform all administration tasks by using either the ISPF administration interface or the file maintenance utility, you do not need a CICS BAC communication server.
You can start the communication server as either a started task or batch job, and it runs entirely in problem-program state. It does not need to run as APF-authorized, unless you want it to perform client request-security checking. You can run multiple communication servers on a single MVS image, but each server requires a unique server identifier and TCP/IP port number. The port number (in conjunction with the communication server's TCP/IP address) is used by the workstation client to direct its requests to the appropriate server. There is no tie between a particular communication server and a specific CICS region. Different servers can communicate with the same CICS region and a communication server can communicate with different CICS regions.
You notify the communication server about the CICS regions that support CICS BAC by means of a control file table that you define (see The control file table). The communication server loads the control file table at startup. When it receives a workstation request for a CICS region, it determines whether or not CICS BAC is running in the CICS region by attempting to acquire a systems-level enqueue that is normally held by the CICS region when CICS BAC is running in the region. If the server cannot get the systems-level enqueue (implying that CICS BAC is active in the destination region), it sends the request to CICS for servicing. The server uses the CICS external CICS interface (EXCI) facility to send its requests to the CICS region by means of a distributed program link (DPL) command. This allows the server to communicate with any CICS region in the same sysplex that is running EXCI support
The communication server is not constrained by the 32 KB commarea size limit. If the amount of data on a request to CICS is larger than 32 KB, CICS BAC breaks the single logical request into multiple DPL requests that are processed by the CICS BAC request server when all request data has been sent to the region. A similar technique is used when the length of data being returned to the server as a result of a DPL request is greater than 32 KB.
If CICS BAC is not active in the destination CICS region, the communication server services the request itself, provided the request does not require direct access to CICS resources or information. When servicing the request itself, the server determines the data set name of the CICS BAC control file, for the destination CICS region, by searching its control file table. If found, it dynamically allocates and opens the file, then services the request. If the request requires direct access to CICS resources (for example, a request to return a list of files defined to CICS), and CICS BAC is not active in the CICS region, the server fails the request with the appropriate return code.
For information about setting up and starting a communication server, see Setting up and starting the communication server.