Subsystems

pts.
Tags:
AS/400
IBM iSeries
Hi Team, Please give me some information on SUBSYSTEMS in ISeries. Thanks in Advance,
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Create a subsystem description

IBM(R)-supplied subsystem descriptions have been provided as examples and as back up for user-created subsystem descriptions. Therefore, you should not change the subsystem descriptions in libraries QSYS and QGPL. You should make copies of the subsystem descriptions from these libraries and make changes to the copies.
You can create a subsystem description in two ways. You can copy an existing subsystem description and change it or you can create an entirely new description.
To copy an existing subsystem description:
1. On a command line, type CRTDUPOBJ, to create a duplicate object of an existing subsystem description.
2. Change the sign-on display file and the system part of the library list for the secondary language.
To create an entirely new subsystem description:
1. Create a subsystem description (CRTSBSD). Specify a sign-on file from the national language version library and specify the national language version library (QSYSnnnn) as the system-library list entry.
2. Create a job description (CRTJOBD).
3. Add work entries to the subsystem description.
a. ADDWSE (Add work station entry)
b. ADDJOBQE (Add job queue entry)
c. ADDCMNE (Add communications entry)
d. ADDAJE (Add autostart job entry)
e. ADDPJE (Add prestart job entry)
4. Create a class (CRTCLS).
5. Add routing entries to the subsystem description (ADDRTGE
Subsystem attributes
Subsystem attributes provide the overall characteristics of the subsystem. Attributes include the system-library list entry and a text description of the subsystem description.
For example, you can specify subsystem attributes to support secondary language users:
1. Specify the national language version for the subsystem library entry parameter.
By creating a subsystem for each secondary language on your system, you can ensure that secondary language users have access to textual data in their own language. Within each subsystem, you can arrange the order of libraries in the library list so the textual data for the appropriate secondary language is at the top of the system library list. For example, if you have a primary language of Danish, and a secondary language of German, you can add a library at the top of the system library list in the German subsystem. Jobs running in the German subsystem then use the library at the top of the system part of the library list and a search for German textual data is successful.
If you add a subystem-library list entry for a national language version library:
o Do not add the library to the QSYSLIBL system value.
o Be sure that there are no more than 14 libraries in the QSYSLIBL list before adding your additional library entry. (The maximum number of list entries for the system part of the library is 15.)
2. Specify the sign on display using the national language version library.
3. Create or duplicate objects that all users of the secondary national language version need in the national language version library.
4. Add workstation entries for these workstations that are specifically configured for this national language version
Workstation entry
You can specify the following items in a workstation entry. Parameter names are given in parentheses.
• Workstation name or type (WRKSTN or WRKSTNTYPE)
• Job description to be used for jobs started through this workstation entry
• Maximum number of interactive jobs that can be active at the same time through the entry (MAXACT)
• When the work stations are to be allocated, either when the subsystem is started or when an interactive job enters the subsystem through the Transfer Job (TFRJOB) command.
Adding, changing, or removing workstation entries
The following commands allow you to add, change, or remove workstation entries from a subsystem description.
To add a workstation entry to a subsystem description, use the Add Work Station Entry (ADDWSE) command. The following is an example of adding a workstation entry:
ADDWSE SBSD(USERLIB/ABC) WRKSTN(DSP12)
JOBD(USERLIB/WSE)
To specify a different job description for a previously defined workstation entry, use the Change Work Station Entry (CHGWSE) command. The following is an example of changing a workstation entry:
CHGWSE SBSD(USERLIB/ABC) WRKSTN(DSP12)
JOBD(USERLIB/NEWJD)
To remove a workstation entry from a subsystem description, use the Remove Work Station Entry (RMVWSE) command. The following is an example of removing a workstation entry:
RMVWSE SBSD(USERLIB/ABC) WRKSTN(DSP12)
Start a subsystem
Once you have created a subsystem that meets your needs, you need to start the subsystem. To start a subsystem, use the Start Subsystem (STRSBS) command:
STRSBS SBSD(‘library name/subsystem name’)
For example:
STRSBS USERLIB/ABC
Job attributes
Job attributes are set at the time a job starts. Some job attributes are set from the user profile. Other job attributes come from system values, from locales, from a Submit Job (SBMJOB) command, a job description, and the Change Job (CHGJOB) command (from which you can change values for attributes while the job is running). The following attributes are especially useful for globalized environments:.
• Coded character set identifier job attribute (CCSID)
• Job default coded character set identifier (DFTCCSID)
• Job library list

Coded character set identifier job attribute
When an interactive job is started, the job CCSID value is taken from the user profile. When a batch job is started, the current job CCSID is used unless a CCSID is specifically entered on the SBMJOB command.
For every mixed-byte coded character set CCSID, there is a corresponding SBCS CCSID that is valid. If you specify a mixed-byte coded character set CCSID for an SBCS system, the job CCSID is changed to the corresponding SBCS CCSID.
If a job CCSID is specified as an SBCS CCSID, the job cannot handle DBCS data. If a job CCSID is specified as a mixed CCSID, the job can handle DBCS data. You must use a DBCS-capable display device, though, for the DBCS data in a job to display correctly. You can specify a mixed-byte CCSID for a job only if the DBCS system value (QIGC) value is set to 1 (on). A QIGC value of 1 indicates that a DBCS national language version is installed on the system.
Job default coded character set identifier (DFTCCSID)
A job attribute, job default CCSID (DFTCCSID), is created for jobs with a CCSID of 65535. The DFTCCSID value is used by some system code when a CCSID other than 65535 is needed.
The DFTCCSID attribute can only be retrieved or displayed. The value of this attribute is determined as follows:
• If the job CCSID is not 65535, the DFTCCSID equals the job CCSID.
• If the job CCSID is 65535, the DFTCCSID value is based on an appropriate value derived from the job language identifier (LANGID).
Once the job is running, the system determines the default CCSID for a job using the following logic (you can find the corresponding CCSID for LANGID in default CCSID table):
1. If the job CCSID is set to a value, it uses that value.
2. If the job CCSID is set to *USRPRF, then the system checks the user profile for the value.
3. If the user profile is set to a value, it uses that value.
4. If the user profile is set to *SYSVAL, the system checks the system value.
5. If the system value for QCCSID is set to a value, it uses that value.
6. If the system value is set to 65535, the system checks the job’s language ID.
7. If the job’s LANGID is set to a value, the QTQ_DEFAULT_CCSID environment variable is checked for that LANGID value. If the QTQ_DEFAULT_CCSID environment variable contains a value for that LANGID, the CCSID specified in the QTQ_DEFAULT_CCSID environment variable is used. If the QTQ_DEFAULT_CCSID environment variable does not contain a value for the LANGID, the system converts that LANGID to a CCSID.
8. If the job’s LANGID is set to *USRPRF, the system checks the user profile’s language ID.
9. If the user profile’s LANGID is set to a value, the QTQ_DEFAULT_CCSID environment variable is checked for that LANGID value. If the QTQ_DEFAULT_CCSID environment variable contains a value for that LANGID, the CCSID specified in the QTQ_DEFAULT_CCSID environment variable is used. If the QTQ_DEFAULT_CCSID environment variable does not contain a value for the LANGID, the system converts that LANGID to a CCSID.
10. If the user profile’s LANGID is set to *SYSVAL, the QTQ_DEFAULT_CCSID environment variable is checked for that LANGID value. If the QTQ_DEFAULT_CCSID environment variable contains a value for that LANGID, the CCSID specified in the QTQ_DEFAULT_CCSID environment variable is used. If the QTQ_DEFAULT_CCSID environment variable does not contain a value for the LANGID, the system converts that LANGID to a CCSID.
Language identifiers and associated default CCSIDs contains a list of language identifiers and the DFTCCSID values associated with those identifiers.
Job library list
The language used for textual data (displays, messages, printed output, and online help information) is controlled by the library list for the job.
Users can place their national language library before QSYS (the primary language library) and before any other national language libraries in their library lists. In this way, users can customize which national language versions of information are presented to them.
For more information on the national language libraries and proper authority to change these lists, see System Library List (QSYSLIBL) system value.
DBCS system indicator (QIGC) system value
The DBCS system indicator (QIGC) is used to specify whether a DBCS national language version is installed. This value is set when the primary national language version is installed.
If QIGC is set to 0, no DBCS national language version is installed on the system. When QIGC is set to 0, the coded character set system identifier (QCCSID) must be set to an SBCS coded character set identifier.
If QIGC is set to 1, a DBCS national language version is installed as the primary language on the system. When QIGC is set to 1, the coded character set system identifier (QCCSID) system value should be set to a mixed CCSID (such as 05026) or to CCSID 65535.
In i5/OS(TM) V5R3 and future releases, any NLV can support DBCS. Therefore, QIGC is always set to 1 (or on). If you have applications that check this value, update them to use the job level DBCS indicator. You can use Retrieve Job Information (QUSRJOBI) API to get the job’s IGC value.
You cannot change this value.
DBCS font name (QIGCCDEFNT) system value
The DBCS font name (QIGCCDEFNT) is used when transforming SNA character string (SCS) data into an Advanced Function Printing(TM) data stream (AFPDS) spooled file with shift in/shift out (SI/SO) characters present in the data.
QIGCCDEFNT is a 20-character list of up to 2 values. The first 10 characters contain the font name. The last 10 characters contain the library name. The font name can be only 8 characters. The possible values for the DBCS font name are:
*NONE
No font is identified to the system.
Coded font name
The name of the DBCS font.
The possible values for the library are:
*LIBL
The library list is used to locate the font.
*CURLIB
The current library is used to locate the font. If no library is specified, library QGPL is used.
Library name
The library containing the font.
A job’s life: Submit a job
When a job is submitted to the iSeries, it is created and enters the system. At this time, the properties are given to the job. Once the job receives its job description and defines its properties, it moves to the job queue where it waits to enter the subsystem.

Where do you want to go from here?

Submit a job > Job description

When you want to work with jobs, look for the job icon in the Work Management folder of iSeries Navigator. Get more information on jobs from How work gets done.

A job’s life: Job description
The job description holds properties the job will use to go through the work management life cycle. These properties include the user profile the job will start to run under, the request data (which tells the job what it will do), and the initial user portion of the library list, as well as others. The job description also holds information that tells the job which job queue to enter and the routing data. The routing data is later used by the subsystem to find the routing entry that contains information needed for the job to start running. The output queue is also defined within the job description. It tells where printer output (also called spooled files) from a job will go.

Where do you want to go from here?

Submit a job > Job description

When you want to work with jobs, look for the job icon in the Work Management folder of iSeries Navigator. For more information, seejobs.

A job’s life: The job enters a job queue
Job queues are work entry points for batch jobs to enter the system. They can be thought of as “waiting rooms” for a subsystem. A number of factors affect when the job is pulled off the job queue into the subsystem, such as the job priority on the job queue, the sequence number of the job queue, and the maximum active jobs. When all of these factors work together, the job will be pulled off the job queue to start running in the subsystem.

Where do you want to go from here?

The job enters a job queue > Job queue

When you want to work with job queues, look for the job queues icon in the Work Management folder of iSeries Navigator. Get more information on job queues from How work enters the system.

A job’s life: Job queue
When the job enters the job queue, it is available to a subsystem that has the job queue allocated to it. The subsystem looks at the sequence number of the job queue before the job priority of the jobs in the job queues. The subsystem uses the priority on job queue to determine when a job can enter relative to other jobs on the job queue. Because subsystems can have more than one job queue feeding into them (however, job queues cannot feed into more than one subsystem), a sequence number in the subsystem determines when the subsystem processes a job queue. The job priority and the maximum active jobs determine when a job enters the subsystem.

Where do you want to go from here?

The job enters a job queue > Job queue

When you want to work with job queues, look for the job queues icon in the Work Management folder of iSeries Navigator. Get more information from Job queues.

job’s life: The job enters the subsystem
When the job enters the subsystem it becomes active. Until a job gets its activity level and memory from a memory pool, it cannot run. The job uses several pieces of information before it can receive memory to run. The subsystem description, like the job description, carries information, such as the memory pool to use, the routing entry, the maximum active jobs, and the number of active jobs currently in the subsystem.

Where do you want to go from here?

The job enters the subsystem > Subsystem

When you want to work with subsystems, look for the subsystem icon in the Work Management function of iSeries Navigator. Get more information on subsystems from How work gets processed.

A job’s life: Subsystem
Subsystems are operating environments where the system manages the resources jobs use and controls the jobs that run within it. Once jobs are running in the subsystem, the subsystem job carries out user requests on a job such as holding, releasing, and ending a job.
Like jobs, subsystems have descriptions that carry important information needed to complete the work. In the subsystem description is the routing entry. The routing entry references the class object, which contains the properties that control the run-time environment. However, before the job can get its routing entry, the routing data must make a match with a compare value in the routing entry. If this association is not made, the job will not run. Once the association between the routing data and the routing entry is made, the class object the job will use is determined. Some of the properties that control the run-time environment include the run priority, the timeslice, the maximum wait time, the maximum processing time, the maximum temporary storage, and the maximum number of threads. For more information, see class object in Chapter 5 of the V4R5 Work Management (about 2720 KB or 573 pages) manual.
The subsystem description defines the memory pools that will be allocated to the subsystem. The subsystem description also contains the maximum active jobs, which is the maximum number of active jobs at one time in the subsystem.

Where do you want to go from here?

The job enters the subsystem > Subsystem

When you want to work with subsystems, look for the subsystem icon in the Work Management folder of iSeries Navigator. Get more information on subsystems from How work gets processed.

A job’s life: The subsystem uses memory from a memory pool to run the job
Memory is a resource from the memory pool that the subsystem uses to run the job. The amount of memory from a memory pool, as well as how many other jobs are competing for memory, affect how efficiently a job runs. Subsystems use different memory pools to support different types of jobs that run within them. The subsystem gives the memory pool the information it needs to process the order in which jobs are allocated memory, and the memory pool allocates memory for the job to run to completion.

Where do you want to go from here?

The subsystem uses memory from a memory pool to run the job > Memory pool

When you want to work with memory pools, look for the memory pools icon in the Work Management folder of iSeries Navigator. Get more information on memory pools from How work gets processed.

A job’s life: Memory pools
Memory pools provide jobs with memory in which to run. Many factors affect how the job runs in the memory pool, such as the size and the activity level in the memory pool, as well as paging and faulting.
The activity level in memory pools directly relates to the number of threads allowed to run in the memory pool at one time. Remember, every job has at least one active thread, but some can have multiple threads. Threads give a job the ability to do more than one thing at a time. For example, one thread can go out and do calculations while another thread waits for more data to process.
Paging is the movement of data in and out of memory, both synchronously and asynchronously. Pages can be written out to storage or removed from memory without being written if they have not been changed. Faulting causes paging to occur on the iSeries server. Faulting occurs when a referenced page, or piece of data, is not in memory. This causes programs to stop because they must wait for the data to be paged in.
Once the job is finished running, the memory it used is made available for other jobs to use.

Where do you want to go from here?

The subsystem uses memory from the memory pool to run the job > Memory pools

When you want to work with memory pools, look for the memory pools icon > in the Work Management folder of iSeries Navigator. Get more information on Memory pools.

A job’s life: The job finishes and moves to the output queue
A job’s printer output (also called spooled files) is sent to an output queue where it waits to be sent to a printer or file. The output queue is similar to the job queue in that it controls how the output is made available to the printer. The output queue allows the user to control what files are printed first.

Where do you want to go from here?

When you want to work with output queues, look for the output queue icon in the Work Management folder in iSeries Navigator. Get more information on Output queues.

Output queues
Output queues are areas where printer output files (also called spooled files) wait to be processed and sent to the printer. Printer output is created either by the system or by the user using a print file. A print file is similar to a template or a guideline where the default values for the attributes of printer output are set. It is the beginning of the printer output life cycle.
The print file contains the output queue (OUTQ) and print device (DEV)attributes, which dictate how the printer output is to be directed. The default settings are usually *JOB, meaning that the job attributes of the output queue and printer device determine how the printer output is directed. The job attributes of the output queue and printer device settings are based on information obtained when the job is created. This is based on information from the user profile the job is running under, the job description, the workstation device description, and the default printer system value(QPRTDEV).
When the printer output is ready to be created, the system checks the print file and the job attributes (in this order) to see what output queue will process the printer output and which printer device the system will use. You can change the parameters of the output queue (OUTQ) and printer device (DEV) at the time the job is submitted or at job run-time to bypass extended processing. For example, the user can set the print file output queue to a specific queue and set the printer device to their specific printer in the print file at job initiation for the changes to take effect immediately. In doing this, the printer output does not have to go through the job attributes to find the output queue and printer device it will use. If a specified output queue cannot be found, the printer output will be directed to QGPL/QPRINT. For more information on how printer output is created, see Chapter 1 of the Printer Device Programming manual.
Printer output files are files that hold information waiting to be printed or processed. The printer output file holds important attributes that define the position of the printer output on the queue with relation to other printer output. The position is defined by the priority, status, and schedule attributes.
Output queue
An output queue is an object that contains a list of printer output files to be written to an output device. The output queue carries important attributes that determine the order in which printer output is processed and the authority needed to make changes to the printer output file.
Priority
Printer output that is waiting to process is moved to the output queue based on its priority (ranges from 1-9 where 1 is the highest priority).
Status
The current status of printer output. You can view this status from the General page in Output properties.
Schedule
The schedule attribute tells when the file should start physical printing of the output data.
Immediate
Print immediately, even if the printer output file is not closed.
File end (default)
Printing begins as soon as the printer output file is closed.
Job end
Printing begins when the job ends.
Once the printer output file is ready to be printed, a writer job, a job that processes the printer output from the output queue to the printer device, takes data from the printer output file and sends it to the designated printer.
Manage daily work
As a system operator or administrator, one of your tasks is to keep your server running smoothly. This means you monitor, manage, and ensure that your jobs, job queues, subsystems, memory pools, job logs, and output queues function properly.
The topics in this section give you information on the different types of daily work management tasks as well as other tasks you might need to perform on your iSeries server. Each subtopic explains why it is important to do these tasks, as well as how to complete them.
Monitor system activity
Monitoring your system is an important daily activity. You can accomplish this in a variety of ways, such as using iSeries Navigator and iSeries Navigator Management Central. The tasks in these subtopics follow:
• Work with system status
• Monitor system performance
• Work with monitors
Manage jobs and threads
Whether you are asked to report the status of a particular job or thread or to monitor a job or thread’s performance, you can easily find most of the answers you need in iSeries Navigator. The tasks in these subtopics follow:
• Schedule jobs
• Find a job on the iSeries server
• Determine the status of a job
• View performance statistics for a job
• View affinity information
• End a job
• Actions done to a job
• View threads running under a specific job
• View thread properties
• End a thread
Manage job queues
Job queues are an important element in the life cycle of a batch job. Job queues help control the rate at which batch jobs enter a subsystem. The tasks in these subtopics follow:
• View jobs on the job queue
• Change the priority of a job within a job queue
• Move jobs to different job queues
Manage subsystems
Because jobs run in subsystems, you may need to monitor subsystem activity for potential problems that could affect a job’s ability to run. The tasks in these subtopics follow:
• Monitor a subsystem
• View jobs in a subsystem
• Start a subsystem
• End a subsystem
Manage memory pools
Memory pools allocate memory to subsystems so that jobs can run. It is important that when jobs run they get enough memory to complete efficiently. The tasks in these subtopics follow:
• Monitor the number of jobs in a memory pool
• Monitor the number of subsystems in a memory pool
• Check memory use
• Change the size of a memory pool
Manage job logs
Job logs contain information related to requests entered for a job, such as commands in the job, commands in the program, and messages. The tasks in these subtopics follow:
• Access job logs for active jobs, including server jobs
• Access printer output
Manage output queues
Output queues help you manage printer output created when a job ends. It is important to understand how to effectively maintain your output queues so that your printed output processes smoothly. The tasks in these subtopics follow:
• View output queues on the system
• Clear output queues
• Move output between and within output queues
Manage subsystems
The subsystem is the work place for jobs on the iSeries server. All user work is done by jobs running in the subsystem and it is important to monitor this area for slow work performance. In iSeries Navigator, you can view jobs and job queues associated with the subsystems. Also, you have the same functionality with jobs and job queues from any other area that displays jobs and job queues.
To learn more about subsystems, see these topics:
• Monitor a subsystem
• View jobs in a subsystem
• Start a subsystem
• Stop a subsystem
Monitor a subsystem
Because subsystems are important to the daily activity done on your system, it is important that you monitor the activity in your subsystems. Within a subsystem description you can determine the number of jobs that can run at one time in the subsystem by setting the maximum active jobs value. As the amount of work on your system increases you may want to change the maximum active jobs value in your subsystem. The number you input here should be set so that the available resources are properly utilized. By increasing the number of active jobs without increasing the resources available can hurt performance on your system.
To check the maximum active jobs value of your subsystem, do the following:
1. In iSeries Navigator, expand My Connections –> server-name –> Work Management –> Subsystems –> Active Subsystems.
2. Right-click the subsystem which you want to monitor.
3. Select Properties.

Note: Make sure you set this option very carefully. If you set maximum active jobs value too high, you may make your system perform slowly. However, if you set your maximum active jobs too low, your work may start to bottleneck and slow performance. For more information about performance tuning your system, see Performance Tuning (chapter 14) in the V4R5 Work Management (about 2720 KB or 573 pages) manual or see Performance tuning.
View jobs in the subsystem
Subsystems coordinate work flow and the resources that a job uses to run. iSeries Navigator allows you to see what jobs are currently active (but not necessarily running) in the subsystem.
To view jobs in the subsystem, follow these steps:
1. In iSeries Navigator, expand My Connections –> server-name –> Work Management –> Subsystems –> Active Subsystems.
2. Select the subsystem for which you want to display its jobs.
For more information, see Subsystems.
Subsystems
The subsystem is where work is processed on the iSeries(TM) server. All jobs, with the exception of system jobs, run within subsystems.
More technically, a subsystem is a single, predefined operating environment through which the system coordinates work flow and resource use. The system can contain several subsystems, all operating independently of each other. Subsystems manage resources. Each subsystem can run unique operations. For instance, one subsystem may be set up to handle only interactive jobs, while another subsystem handles only batch jobs. Subsystems can also be designed to handle many types of work. The system allows you to decide the number of subsystems and what types of work each subsystem will handle.
A subsystem can be either active or inactive. An active subsystem is one that has been started (see start a subsystem for details). An inactive subsystem is one that either has not yet been started, or has been stopped (see stop a subsystem for details).
The controlling subsystem is the interactive subsystem that starts automatically when the system starts, and it is the subsystem through which the system operator controls the system during system startup.
A subsystem job is a job created by the operating system to manage resources and to start, control, and end jobs.
Note: APIs, such as Retrieve Subsystem Information (QWDRSBSD) and Retrieve System Status (QWCRSSTS), can be called to get information on subsystems. For more information on APIs, see Application programming interfaces (APIs).

See the following for more information on subsystems:
Subsystem description
The run-time characteristics of a subsystem are defined in the subsystem description.
Subsystems shipped with the system
Two complete subsystem configurations are supplied by IBM(R) .
User-defined subsystems
You can create your own subsystem description.
Subsystem properties
The attributes of a subsystem are provided.
Subsystem life cycle
This explains how work is processed on the iSeries server.
Send feedback | Rate this page

Subsystem description
The run-time characteristics of a subsystem are defined in an object called a subsystem description. A subsystem description acts as a set of instructions, telling the subsystem how, where, and how much work enters a subsystem, and which resources the subsystem uses to perform the work. A subsystem is created when a subsystem description is defined or created. An active subsystem takes on the simple name of the subsystem description.
For details on what information is contained in the subsystem description, see the following table:
Information in subsystem description Description Additional information (Work Management manual)
Subsystem attributes Specifies overall system characteristics:
• Operational attributes such as the number of jobs that can be active in the subsystem at the same time, and the sign-on display.
• Memory pools used by the subsystem.
• Authority to the subsystem description.
• Text description of the subsystem description. Changing the sign-on display file, Chapter 4 of the Work Management manual.

Work entries The work entry in a subsystem description specifies the source from which jobs can be accepted for processing in the subsystem. In other words, the location where work can enter the subsystem. Work entries, Chapter 4 of theWork Management manual.

Autostart job entry Identifies the autostart jobs to start as soon as the subsystem starts. Autostart jobs, Chapter 9 of the Work Management manual.

Communications entry Identifies the communications device that another system uses to submit work. Communications jobs, Chapter 10 of the Work Management manual.

Job queue entry Identifies the job queue from which to take work and determine how much work to accept. Batch jobs, Chapter 8 of the Work Management manual.

Prestart job entry Identifies the information used when prestart jobs are started. Prestart jobs, Chapter 11 of the Work Management manual.

Workstation entry Identifies the workstation from which to take work. Interactive jobs, Chapter 6 of the Work Management manual.

Routing entries Identifies the subsystem memory pool to use, the controlling program to run, and run-time information. Routing entries, Chapter 4 of the Work Management manual.

Subsystem Description objects are shipped with every system. Below are the updates to the shipped subsystem descriptions on the iSeries server. For each object, this table provides:
Object Name
Command used to update the object
Command parameters other than the default
This table and Appendix C in the Work Management manual will allow you to see most of the shipped subsystem descriptions on the iSeries.
Object Addition, Deletion, or Update Parameters other than default
QBASE Added a communication entry (ADDCMNE) SBSD (QSYS/QBASE)
DEV (Q1PLOC)
DFTUSR (*NONE)
MODE (Q1PMOD)
MAXACT (0)
QBASE Added a communication entry (ADDCMNE) SBSD (QSYS/QBASE)
REMLOCNAME (Q1PLOC)
DFTUSR (*NONE)
MODE (Q1PMOD)
MAXACT (0)
QBASE Added prestart job entry (ADDPJE) SBSD (QSYS/QBASE)
PGM (QSYS/QZSCSRVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (1)
WAIT (*YES)
POOLID (2)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QBASE Added prestart job entry (ADDPJE) SBSD (QSYS/QBASE)
PGM (QSYS/QNPSERVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QBASE Added prestart job entry (ADDPJE) SBSD (QSYS/QBASE)
PGM (QSYS/QZRCSRVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (1)
WAIT (*YES)
POOLID (2)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QCMN Added a communication entry (ADDCMNE) SBSD (QSYS/QCMN)
REMLOCNAME (Q1PLOC)
DFTUSR (*NONE)
MODE (Q1PMOD)
MAXACT (0)
QCMN Added a communication entry (ADDCMNE) SBSD (QSYS/QCMN)
DEV (Q1PLOC)
DFTUSR (*NONE)
MODE (Q1PMOD)
MAXACT (0)
QCMN Added prestart job entry (ADDPJE) SBSD (QSYS/QCMN)
PGM (QSYS/QZRCSRVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (1)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QCMN Added prestart job entry (ADDPJE) SBSD (QSYS/QCMN)
PGM (QSYS/QZSCSRVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (1)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QCMN Added prestart job entry (ADDPJE) SBSD (QSYS/QCMN)
PGM (QSYS/QNPSERVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QSERVER Added prestart job entry (ADDPJE) SBSD (QSYS/QSERVER)
PGM (QSYS/QZDAINIT)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(3)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (1)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QPWSERVER *CALC *NONE *CALC)
QSERVER Added prestart job entry (ADDPJE) SBSD (QSYS/QSERVER)
PGM (QSYS/QPWFSERVSO)
USER (QUSER)
STRJOBS (*NO)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOBD (*USRPRF)
JOB (*PGM)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QPWFSERVER *CALC *NONE *CALC)
QSYSWRK Added job queue entry (ADDJOBQE) SBSD (QSYS/QSYSWRK)
JOBQ (QSYS/Q1PSCHQ)
MAXACT (1)
SEQNBR (70)
QSYSWRK Added job queue entry (ADDJOBQE) SBSD (QSYS/QSYSWRK)
JOBQ (QSYS/Q1PSCHQ2)
MAXACT (1)
SEQNBR (80)
QSYSWRK Added job queue entry (ADDJOBQE) SBSD (QSYS/QSYSWRK)
JOBQ (QSYS/Q1PSCHQ3)
MAXACT (1)
SEQNBR (90)
QSYSWRK Added an autostart job entry (ADDAJE) SBSD (QSYS/QSYSWRK)
JOB (QGLDPUBA)
JOBD(QSYS/QGLDPUBA)
QSYSWRK Added an autostart job entry (ADDAJE) SBSD (QSYS/QSYSWRK)
JOB (QGLDPUBE)
JOBD(QSYS/QGLDPUBE)
QSYSWRK Added autostart job entry (ADDAJE) SBSD (QSYS/QSYSWRK)
JOB (QPM400)
JOBD (QSYS/Q1PJOBD)
QSYSWRK Added a communication entry (ADDCMNE) SBSD (QSYS/QSYSWRK)
DEV (Q1PDEV)
JOBD (*USRPRF)
DFTUSR (QUSER)
MODE (Q1PMOD)
MAXACT (*NOMAX)
QSYSWRK Added a communication entry (ADDCMNE) SBSD (QSYS/QSYSWRK)
DEV (Q1PLOC)
JOBD (*USRPRF)
DFTUSR (QPM400)
MODE (Q1PMOD)
MAXACT (*NOMAX)
QSYSWRK Added a communication entry (ADDCMNE) SBSD (QSYS/QSYSWRK)
RMTLOCNAME (Q1PLOC)
JOBD (*USRPRF)
DFTUSR (QPM400)
MODE (Q1PMOD)
MAXACT (*NOMAX)
QSYSWRK Added routing entries (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2150)
CMPVAL (TOTNTP)
PGM (QSYS/QTOTSNTP)
CLS (QSYS/QSYSCLS10)
QSYSWRK Added routing entry (ADDRTE) SBSD (QSYSWRK)
SEQNBR (300)
CMPVAL (PGMEVOKE 29)
PGM (*RTGDTA)
CLS (QSYS/QSYSCLS50)
MAXACT (*NOMAX)
POOLID (1)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2536)
CMPVAL (‘QZSCSRVSD’)
PGM (QSYS/QZSCSRVSD)
CLS (QGPL/QCASERVR)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2537)
CMPVAL (‘QZHQSRVD’)
PGM (QSYS/QZHQSRVSD)
CLS (QGPL/QCASERVR)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2538)
CMPVAL (‘QNPSERVD’)
PGM (QSYS/QNPSERVD)
CLS (QGPL/QCASERVR)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2539)
CMPVAL (‘QZRCSRVSD’)
PGM (QSYS/QZRCSRVSD)
CLS (QGPL/QCASERVR)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2540)
CMPVAL (‘QZSOSGND’)
PGM (QSYS/QZSOSGND)
CLS (QGPL/QCASERVR)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2541)
CMPVAL (‘QZSOSMAPD’)
PGM (QSYS/QZSOSMAPD)
CLS (QGPL/QCASERVR)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2170)
CMPVAL (‘QSYEIMMON’)
PGM (QSYS/QSYEIMMON)
CLS (QSYS/QSYSCLS20)
MAXACT (*NOMAX)
POOLID (1)
QSYSWRK Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2200)
CMPVAL (‘QYASPPGM’)
PGM (QSYS/QYASPPGM)
CLS (QSYS/QSYSCLS20)
MAXACT (*NOMAX)
POOLID (1)
QSYSWRK
Added an autostart job entry (ADDAJE) SBSD (QSYS/QSYSWRK)
JOB (QS9AJE)
JOBD(QSYS/QS9AJE)

QSYSWRK
Added an autostart job entry (ADDAJE) SBSD (QSYS/QSYSWRK)
JOB (QCSTSRCD)
JOBD(QSYS/QCSTSRCD)

QSYSWRK
Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2220)
CMPVAL (‘QS9PAL’)
PGM (QSYS/QCMD)
CLS (QSYS/QSYSCLS50)
MAXACT (1)

QSYSWRK
Added routing entry (ADDRTGE) SBSD (QSYS/QSYSWRK)
SEQNBR (2221)
CMPVAL (‘QS9PRB’)
PGM (QSYS/QCMD)
CLS (QSYS/QSYSCLS50)
MAXACT (1)

QSYSWRK
Added job queue entry (ADDJOBQE) SBSD (QSYS/QSYSWRK)
JOBQ (QSYS/QSJINV)
MAXACT (1)
SEQNBR (100)

QSYSWRK
Added routing entry (ADDRTGE) SBSD(QSYS/QSYSWRK)
SEQNBR(2230)
CMPVAL(‘SERVICERMDRVR’)
PGM(QSYS/QSVRMEVJ)
CLS(QSYS/QSYSCLS25)
MAXACT(*NOMAX)

QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QSYSWRK)
PGM (QSYS/QZSOSIGN)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (QSYS/QZBSJOBD)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM (QSYS/QZSCSRVS)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (QSYS/QZBSJOBD)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM (QSYS/QNPSERVS)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (QSYS/QZBSJOBD)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM (QSYS/QZRCSRVS)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (QSYS/QZBSJOBD)
MAXUSE (1)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM (QSYS/QZDASOINIT)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QPWFSERVER *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM (QSYS/QZHQSSRV)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (QSYS/QZBSJOBD)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QGPL/QCASERVR *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM (QSYS/QZDASSINIT)
USER (QUSER)
STRJOBS (*YES)
INLJOBS(1)
THRESHOLD (1)
ADLJOBS(2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (QSYS/*USRPRF)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QSYS/QPWFSERVER *CALC *NONE *CALC)
QUSRWRK Added prestart job entry (ADDPJE) SBSD (QSYS/QUSRWRK)
PGM(QSYS/QRWTSRVR)
USER (QUSER)
STRJOBS (*YES)
INLJOBS (1)
THRESHOLD (1)
ADLJOBS (2)
MAXJOBS (*NOMAX)
JOB (*PGM)
JOBD (*USRPRF)
MAXUSE (200)
WAIT (*YES)
POOLID (1)
CLS (QSYS/QSYSCLS20 *CALC *NONE *CALC)
QUSRWRK
Added routing entry (ADDRTGE) SBSD (QSYS/QUSRWRK)
SEQNBR (2210)
CMPVAL (WATCHEVENT)
PGM (QSYS/QSCWCMON)
CLS (QSYS/QSYSCLS25)
MAXACT (*NOMAX)
POOLID (1)

QUSRWRK
Added routing entry (ADDRTGE) SBSD (QSYS/QUSRWRK)
SEQNBR (2211)
CMPVAL (WATCHLICEVENT)
PGM (QSYS/QSCLICEV)
CLS (QSYS/QSYSCLS25)
MAXACT (*NOMAX)
POOLID (1)

What happens when the subsystem starts
When a subsystem starts, the system allocates several items and starts autostart and prestart jobs before the subsystem is ready for work. The subsystem description is used to determine how items are allocated.
The following list represents the sequence of events that occur when the subsystem starts:
1. Request to start subsystem is issued.
2. Memory pools are allocated.
Memory is allocated to the pools defined in the subsystem description. The memory that is allocated to each defined pool is taken from the Base memory pool. The system does not allocate memory to a pool if the amount of memory available to the Base memory pool would be less than the minimum size specified by the base memory pool minimum size (Qbaspool) system value. If the system cannot allocate all of the requested memory, it allocates as much memory as is available and allocates all the other as memory becomes available.
See Pool Allocation in Chapter 4 of the V4R5 Work Management (about 2720 KB or 573 pages) manual.
3. Display stations are allocated.
– If there are workstation entries and the device is varied on and has not been allocated by any other subsystem, the subsystem can allocate it and display the Sign-On display.
– If the device is varied on and has been allocated by another subsystem and is at the Sign-On display (the Sign-On display was displayed before the second subsystem was started), a second subsystem can allocate the device from the first subsystem and display the Sign-On display.
– If the device is not varied on, the subsystem cannot allocate it. The system arbiter (Qsysarb) and the Qcmnarbxx jobs hold locks on all varied-off devices.
See Workstation Device Allocation in Chapter 4 of the V4R5 Work Management (about 2720 KB or 573 pages) manual.
4. Communications devices are allocated.
Requests are sent to the Qlus (LU services) system job, which handles device allocation for all communications devices.
See Communications Devices and Mode Allocation in the V4R5 Work Management (about 2720 KB or 573 pages) manual.
5. Job queues are allocated.
The subsystem will not be able to allocate a job queue if it is already allocated to another active subsystem.
6. Prestart jobs are started.
7. Autostart jobs are started.
8. Environment is ready for work.
Send feedback | Rate this page

What happens when the subsystem starts
When a subsystem starts, the system allocates several items and starts autostart and prestart jobs before the subsystem is ready for work. The subsystem description is used to determine how items are allocated.
The following list represents the sequence of events that occur when the subsystem starts:
1. Request to start subsystem is issued.
2. Memory pools are allocated.
Memory is allocated to the pools defined in the subsystem description. The memory that is allocated to each defined pool is taken from the Base memory pool. The system does not allocate memory to a pool if the amount of memory available to the Base memory pool would be less than the minimum size specified by the base memory pool minimum size (Qbaspool) system value. If the system cannot allocate all of the requested memory, it allocates as much memory as is available and allocates all the other as memory becomes available.
See Pool Allocation in Chapter 4 of the V4R5 Work Management (about 2720 KB or 573 pages) manual.
3. Display stations are allocated.
– If there are workstation entries and the device is varied on and has not been allocated by any other subsystem, the subsystem can allocate it and display the Sign-On display.
– If the device is varied on and has been allocated by another subsystem and is at the Sign-On display (the Sign-On display was displayed before the second subsystem was started), a second subsystem can allocate the device from the first subsystem and display the Sign-On display.
– If the device is not varied on, the subsystem cannot allocate it. The system arbiter (Qsysarb) and the Qcmnarbxx jobs hold locks on all varied-off devices.
See Workstation Device Allocation in Chapter 4 of the V4R5 Work Management (about 2720 KB or 573 pages) manual.
4. Communications devices are allocated.
Requests are sent to the Qlus (LU services) system job, which handles device allocation for all communications devices.
See Communications Devices and Mode Allocation in the V4R5 Work Management (about 2720 KB or 573 pages) manual.
5. Job queues are allocated.
The subsystem will not be able to allocate a job queue if it is already allocated to another active subsystem.
6. Prestart jobs are started.
7. Autostart jobs are started.
8. Environment is ready for work.
Send feedback | Rate this page

What happens before work enters the system
All jobs, with the exception of system jobs, run within subsystems. For work to start in an active subsystem, memory pools and at least one source of work entry point need to be established. Job queues are an example of a source of work. The iSeries server ships with a default set of job queues, subsystems, and memory pools, which can allow work to begin as soon as the system is powered on.
You can tailor the subsystem and memory pool configurations to optimize your iSeries servers capabilities and performance. For example, if batch jobs are critical to the success of your business, you may want to allocate more memory for them to run. Or, you may determine that the number of jobs running at one time in your Qbatch subsystem should be lower so that those jobs can use the maximum amount of resources to run. Also, you can create job queues, subsystems, and memory pools specifically designed to complete specific types of work. For example, you can create a job queue called Nightreps, where nightly batch reports are sent to a subsystem called Nightrep that allocates memory exclusively for running these batch jobs.
To learn more about job queues, subsystems, and memory pools, see the The structure of your system . For more information on what IBM supports for work management, see Appendix C. IBM-Supplied Object Contents in the V4R5 Work Management (about 2720 KB or 573 pages) manual.
Send feedback | Rate this page

How work enters the system
Work entries identify the sources where jobs enter a subsystem to become available to run. Each type of job on iSeries has different types of work entries it uses.
Most batch jobs use job queues to enter the subsystem. Job queue entries are the mechanism through which a job queue is defined as a source of work to a subsystem.
Work entries are kept in the subsystem description. If a subsystem description does not have a work entry for the type of work being done, the job cannot run in that subsystem. The IBM-shipped subsystems have default work entries in the subsystem descriptions. Keep in mind, some of the default work entries that ship with the subsystems are already allocated to run specific jobs. For example, in the QCMN subsystem one of the communications work entries is set up to run the iSeries Access server.
For more information on how work enters the system, see work entries in Chapter 4 of the V4R5 Work Management (about 2720 KB or 573 pages) manual.
Send feedback | Rate this page

How work gets processed
When the iSeries server is started, a subsystem monitor job begins running. The subsystem monitor job controls the jobs within subsystems. It also starts and ends work, as well as manages the resources for work in the subsystem. Work (or jobs) enters a subsystem through work entries where it becomes active and eligible to run. Work can only be completed when the subsystem is allocated memory to run. Memory is allocated to the subsystem by a memory pool.
How the subsystem description helps process work
Like a job, a subsystem has a description, called a subsystem description. The subsystem description contains important information that tells how, where, how much work can be active in a subsystem at one time, and which resources it can use to perform the work.
Routing entry
A routing entry exists within the subsystem description that tells the subsystem what memory pool to run the job in, what program to run for the job, and which class object to use to run the job. For more information about routing entries, see chapter 4 in the V4R5 Work Management manual.
Class Object
The Class object defines the run priority, default wait time, timeslice, and other attributes. The run priority is important because it determines when a job will get processor time in order to run. The run priority scale goes from 0 to 99, with 0 being the highest priority. (Only system jobs are given priority of 0 because they are the jobs that run the iSeries server.)
When a job enters the subsystem, the subsystem tries to match the routing data with the compare value in the routing entry. If the routing data and the compare value in a routing entry match, the routing entry is assigned to the job. If a match is not made, the job ends.
Another factor that affects when a job runs in the subsystem is the number of jobs allowed to be active in the subsystem at one time (also known as maximum active jobs in the subsystem). When the maximum number of active jobs in a subsystem has been met, no more jobs can enter the subsystem until existing active jobs complete running. Memory has to be allocated to the subsystem for a job to run. Memory pool activity levels tell the iSeries server how many threads can be active within a memory pool. Remember, an active job contains at least one thread. When the memory pool activity level has been reached, the job has to wait for another thread to give up its use of the activity level. A job can be active in a subsystem and not be running.
Note: Do not confuse the subsystem maximum active jobs with the memory pool activity level.

How work leaves the system
The output queue works similarly to a job queue in that it schedules output to be printed. Both the printer output and the output queue carry attributes that are used to print the information.
Printer output holds output data waiting to be processed, such as information waiting to be printed. Printer output also holds important information used to schedule when it will be printed. Printer output attributes include the output queue in which the printer output will reside, the priority, the status and the schedule of the printer output.
The output queue contains attributes of its own that determine the order in which the printer output files are processed. It also contains the authority needed to make changes to the printer output and the output queue.
When the printer output is ready to be sent to the printer it is picked up by a writer job. The writer job takes the data from printer output and prepares it to be printed.
For details about how the output queue gets selected see Controlling print activity in Chapter 1 of the Printer Device Programming manual.
You can create specific output queues or use the output queues shipped with the system. For more detailed information, see Creating an output queue.

Discuss This Question:  

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: