How the Remote Build server processes build requests

The Remote Build server performs the following tasks:
  • Receives build requests and files from the client
  • Performs character conversions
  • Runs builds within its environment
  • (Optional) Collects and returns results to the client
You can choose not to install the Remote Build feature on z/OS® UNIX® System Services.
Note: A Remote Build server of one version can support Remote Build requests from Remote Build clients of that release or one release prior. However, if the request is from the prior version's client, new features of the current release are not available.

On a z/OS MVS™ server

In z/OS MVS, the server load module RCCBLDS receives client build requests. RCCBLDS triggers the JCL member RCCMVS, which runs the RCCBLDW module. RCCBLDW processes your build scripts.

Figure 1: Processing a z/OS MVS build request

Figure 1 is a diagram depicting the flow of control when a remote build client issues a z/OS MVS build request.

On a z/OS UNIX System Services server

For z/OS UNIX System Services operations, the server load modules RCCINIT and RCCBLDS run in z/OS. RCCBLDS triggers the JCL member RCCUSS, which starts the z/OS UNIX System Services shell script rccbldw.sh. This script starts the executable rccbldw, which processes build requests.

Figure 2: Processing a z/OS UNIX System Services build request

Figure 2 is a diagram depicting the flow of control when a Remote Build client issues a build request to z/OS UNIX System Services.

Processing multiple build requests

The server is multithreaded. Each build request starts a new process to handle the build transaction. You can specify the number of concurrent jobs by using the –n runtime option in the RCCRUNM (for z/OS MVS) or RCCRUNU (for z/OS UNIX System Services) JCL or by setting the MAXBUILD= variable in the RSERVER PROC of this JCL member. Concurrency is limited by system resources (such as JES initiators) and workload policies.

If you chose not to install the Remote Build feature on z/OS UNIX System Services, then neither modify nor attempt to run RCCRUNU.

The following figure illustrates the spawning process for multiple z/OS MVS build requests.
Figure 3: Handling multiple z/OS MVS build requests

Figure 3 is a diagram depicting the spawning process for multiple z/OS MVS build requests
The following figure illustrates the spawning process for multiple z/OS UNIX System Services build requests.
Figure 4: Handling multiple z/OS UNIX System Services build requests

Figure 4 is a diagram depicting the spawning process for multiple z/OS UNIX System Services build requests.

Queuing requests

When the concurrency limit is reached, the server queues any additional requests and submits them on a first in, first out basis. Each queued request uses a TCP/IP socket in a finite pool. The default queue size is 10. You control the queue size with the –q runtime option in the RCCRUNM (or RCCRUNU) JCL.

When the queue is full, the client waits 10 seconds and retries indefinitely. Retries are recorded in the client log file (rccbuild.log).
Note: The queue size must not exceed the pool size.

Setting queue size

The sum of the queue size and the number of concurrent builds should be less than the number of sockets that the server can keep active at a time. Use the following formula to calculate the number of active sockets.

queue_size + concurrent_builds < number_sockets