Server jobs are jobs that run continuously in the background on
the iSeries™ system.
Work can come from network functions, operating system functions, on behalf
of a user, another system within the network, or from general system services,
such as the clustering server jobs. Server jobs typically run in one of three
basic subsystems that are shipped with the system - QSYSWRK, QSERVER, or QUSRWRK.
Server jobs are most commonly associated with such functions as HTTP, Lotus
Notes
® , and TCP/IP. The iSeries system has three basic models for server
jobs:
- Threaded Job Model
- In the threaded job model the server job is a job with multiple threads.
One thread acts as the distributor of work to the other threads. For example,
when the server receives a client request, the initial thread reads the request
and passes it to another thread to fulfill the request. With this model, the
amount of jobs on the system is greatly reduced because work is handled in
different threads rather than requiring multiple jobs. A few examples of server
jobs that use the threaded job model are Domino®, HTTP server, and WebSphere®.
- Prestart Job Model
- In the prestart job model there is typically a primary job that acts as
a listener for requests that come into the system. This job is typically called
the daemon job. The daemon job handles the initial request and then passes
the request to the appropriate prestart server job. With this job model, using
prestart jobs can reduce the number of jobs that are required because after
a request has been fulfilled the prestart server job waits for the next request.
The server job is reused. Also, from a performance perspective, the prestart
job is already running and waiting to process the request. Some examples of
server jobs that use the prestart job model are SQL server, host servers,
and Simple Mail Transfer Protocol (SMTP).
Note: For jobs that run user code,
typically the job is not reused (like most server jobs). This is because the
user code may have changed anything in the job (such as the remote command
server).
- Multiple Listening Job Model
- In the multiple listening job model, several server jobs are started.
When a request comes in, the job that receives the request handles the job
request, while the next available server job waits for the next request to
come in. Once the server job completes the request, it closes the connection
and ends. A new server job starts and the cycle continues.
With this model,
you do not need to be concerned with prestart job entries. However, sometimes
configuring subsystems unique to your environment is not possible because
this model runs in the default subsystem. One exception is File Transfer Protocol
(FTP). With file transfer protocol you can configure the subsystem in which
the file transfer protocol server runs. There is no ability to have some FTP
work to run in one subsystem and the rest of the work to run in a different
subsystem. Also, from a performance perspective, the cost of job initiation
and job termination cannot be avoided because once a job is run it is ended
and another job starts. However, because jobs end when the connection is complete
and the next job is started, the new job will generally be up and running
when the next request is received, so the job initiation and termination cost
should not affect the time it takes to connect to the server.
Some
examples of server jobs that use the multiple listening job model are FTP
and line printer daemon (LPD).
For more detailed information about the
job names of the server jobs that run on the system, see the server job table.
This table shows you the subsystem and the job name so that you can find the
active job and its job logs. The table also shows the job description each
server job uses. By default most server jobs do not generate a job log when
the job ends (the LOG parameter is set to 4 0 *NOLIST), which means that the
job log is not created. If you want a job log to be generated with all the
messages sent to the job log, the LOG parameter needs to specify 4 0 *SECLVL.