Starting a build server on z/OS

where

-p

Specifies the port number (portno) to which the server listens to communicate with the clients.

-V

Specifies the verbosity level of the server. You may specify this parameter up to three times (maximum verbosity).

-a

Specifies authentication mode:

2

Server state: A (authorized). The server code was installed in an APF-authorized library. When you initiate a build by using the remote build client, you must specify the build descriptor option destUserID with a valid TSO user ID and destPassword with a valid TSO password. The server performs the build transaction under the access and authority of this user ID. Mode 2 is the default.

1

Server state: A. You can provide a valid TSO user ID and password. The server performs the build transaction under the access and authority of this user. If you do not provide a user ID and password, the build transaction is performed under the access and authority of the user ID assigned to the build server job.

0

Server state: A or U (unauthorized). If U, APF-authorized build programs will fail. If you specify a TSO user ID and password, the server ignores them and the build transaction is performed under the access and authority of the user ID assigned to the build server job.

You can use modes 1 and 2 only if the server load modules are run from an APF-authorized library.

-n

Specifies the number of concurrent builds. The default is 1. Set n equal to the number of concurrent builds you want to allow. Once there are n number of concurrent builds running, the build server queues any additional requests and submits them on a first come first served basis as builds are completed.

-q

Specifies the size of the queue (q) for clients. The default is 10. Each queued client uses a TCP/IP socket. Therefore setting this too high may require more sockets than are available, causing unpredictable results. If the queue is full, subsequent clients are rejected by the server. However, the build client retries the build in that case.

-t

Starts tracing of this server job and writes output to STDOUT. This parameter is normally used only for debugging.

To start a z/OS build server, complete the following steps with the CCURUN.JCL (for z/OS) or CCURUNU.JCL (for USS):

1. Add a job card.
2. Modify the parameters on the PARM statement of the EXEC card as necessary. (See the parameter list above.)
3. Modify the STEPLIB DD statement to point to the data set that contains the build server load modules. This library contains all the load modules that make up the remote build server.
4. Modify the CCUWJCL DD statement to point to the data set that contains the JCL to run an individual build job. This should be a modified version of the CCUMVS.JCL (for z/OS builds) or CCUUSS.JCL (for USS builds).
5. Specify CCUBLOG as a sequential data set. This is where the log of the build server is written.
6. Modify the parameter (PARM=) statement as appropriate for your job (see example below).
7. Submit the job.

Following is an example of JCL that starts the build server as a batch program for z/OS builds:

//jobcard
//*------------------------------------------------------
//RUNPGM  EXEC PGM=CCUMAIN,DYNAMNBR=30,REGION=7400K,TIME=NOLIMIT,
// PARM='-p 2604 -a 2 -n 3 -q 20'
//STEPLIB  DD DSN=CCUBLD.LOADLIB,DISP=SHR
//CCUWJCL  DD DISP=SHR,DSN=CCUBLD.JCL(CCUMVS)  for z/OS builds
//*CCUWJCL DD DISP=SHR,DSN=CCUBLD.JCL(CCUUSS)  for USS builds
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//CCUBLOG  DD SYSOUT=*

To modify the JCL for USS builds, move the comment indicator (* in //*CCUWJCL) after // on the previous line.

Also, the components that invoke the build server may need to issue messages if communication with the build server fails. To return those messages in a language other than English, change the setting of the environment variable CCU_CATALOG on the client machine. The value of CCU_CATALOG is a string like the following (on a single line):

  shared_resources\eclipse\plugins
  \com.ibm.etools.egl.distributedbuild_version\executables\ccu.cat.xxx

shared_resources

The shared resources directory for your product, such as C:\Program Files\IBM\SDP70Shared on a Windows system or /opt/IBM/SDP70Shared on a Linux system. If you installed and kept a previous version of an IBM® product containing EGL before installing your current product, you may need to specify the shared resources directory that was set up in the earlier installation.

version

The installed version of the plugin. If more than one is present, use the one with the most recent version number, unless you have a reason to use an older version.

xxx

The code for the language of interest; one of the codes listed in the previous table

To set the USS shell script ccubldw.sh to a specific language, add a statement like the following (on a single line):

  export CCU_CATALOG=
    /installationDir/usr/lpp/EnterpriseDeveloper
    /BuildServer/ccu.cat.xxx

installationDir

Directory in which the USS build-server component is installed

xxx

The code for the language that is supported by the script; one of the lower-case codes listed in the previous table