Creating a user-defined server subsystem

A server can use the default subsystem, one of the subsystems that are shipped with the system, a user-defined server subsystem or a combination of one or more of these different types of subsystems. This section explains how to create your own server subsystem.

To create a user-defined server subsystem, follow these steps:

  1. Create a library to store your subsystem configuration objects in.
    CRTLIB SBSLIB TEXT('Library to hold subsystem configuration objects')
  2. Create a class. The class defines certain performance characteristics for your subsystem including run priority, time slice, and default wait times.
    CRTCLS SBSLIB/MYSBS RUNPTY(20) TIMESLICE(2000) DFTWAIT(30) 
           TEXT('Custom Subsystem Class')
  3. Create the subsystem description. You can either use the Create Subsystem Description (CRTSBSD) command to create a new subsystem description or the Create Duplicate Object (CRTDUPOBJ) command to make a copy of an existing subsystem description. For example, to create a new subsystem description:
    CRTSBSD SBSD(SBSLIB/MYSBS) POOLS((1 *BASE)) 
            TEXT('Custom Server Subsystem')

    To create a duplicate of the QUSRWRK subsystem description:

    CRTDUPOBJ OBJ(QUSRWRK) FROMLIB(QSYS) OBJTYPE(*SBSD) TOLIB(SBSLIB)
    Note: Create duplicate object will also copy job queue entries, routing entries, and prestart job entries from the subsystem description being copied from. Depending on the requirements for your subsystem, these values may have to be changed.
  4. Create a job queue for the subsystem, using the same name as the subsystem name and add a job queue entry to the subsystem description. In general, a job queue for the subsystem will be required. Having a job queue allows server jobs to be submitted to the subsystem when needed. Server jobs on the job queue will then be processed. Also, if you will be using the Transfer Job (TFRJOB) command to transfer jobs into your custom subsystem, you will want a job queue.
    CRTJOBQ JOBQ(SBSLIB/MYSBS)
    ADDJOBQE SBSD(SBSLIB/MYSBS) JOBQ(SBSLIB/MYSBS) MAXACT(*NOMAX)
    Note: A job queue can only be allocated by one active subsystem. If you used CRTDUPOBJ to create your subsystem description in step 3, remove the JOBQ entries that were copied, using the Remove Job Queue Entry (RMVJOBQE) command, to prevent your subsystem from trying to allocate a JOBQ that is needed by the subsystem the entry was copied from.
  5. Add a routing entry to the subsystem. The following is an example of adding a routing entry that is designed to be a generic entry to catch all requests that do not match a specific routing entry. The routing entries added to any user-defined subsystem can vary from this example and will depend on the specific requirements for the subsystem. A good basis for setting up routing entries for a user-defined subsystem is to make them identical to the routing entries used by QUSRWRK.
    ADDRTGE SBSD(SBSLIB/MYSBS) SEQNBR(9999) CMPVAL(*ANY) 
            PGM(QSYS/QCMD) CLS(SBSLIB/MYSBS)

    If you look at the routing entries shipped on the system for QUSRWRK, you will see there are several additional routing entries. If you need those functions, add those routing entries to your customized subsystem descriptions as well. It is recommended to copy the routing entries from QUSRWRK into the new user-defined subsystem.

    Note: The maximum activity level (MAXACT) refers to the maximum number of routing steps that can be active through this routing entry. It is highly recommend to use the default value of *NOMAX. The ADDRTGE command specifies which pool identifier to use and the default on the command is 1. If you had set up your subsystem description with dedicated pools, be sure to specify the appropriate pool identifier on the routing entry. If the name of your class is different from the name of your subsystem description, you will need to specify the class on the ADDDRTGE command.
  6. Add prestart job entries to the subsystem. A prestart job is a job that is started and waits for work to be dispatched to it. It is particularly useful for subsystems to have a number of prestart jobs available to handle requests that are submitted to the subsystem. The following is an example of adding a prestart job entry. The prestart job entries added to any user-defined subsystem can vary from this example and will depend on the specific requirements for the subsystem. It is recommended that the prestart job entries for a user-defined subsystem be identical to the prestart job entries used by QUSRWRK.
    ADDPJE SBSD(SBSLIB/MYSBS) PGM(QSYS/QZSOSIGN) INLJOBS(50) THRESHOLD(4) 
           JOB(QZSOSIGN) JOBD(QSYS/QZBSJOBD) CLS(QGPL/QCASERVR) STRJOBS(*YES)
    Note: By initializing the job before work arrives, the overhead and time of doing initialization is avoided, allowing for a much higher throughput of work. It is very important that the prestart job entries be configured correctly to be able to handle the expected amount of work and the expected amount of requests sent to them. If not done correctly, jobs may end up taking an alternative action or a degradation in performance will be seen as additional prestart jobs are created if the current pool of prestart jobs is exhausted.