Create Subsystem Description (CRTSBSD)
|Where allowed to run: All environments (*ALL)
The Create Subsystem Description (CRTSBSD) command creates a subsystem description that defines the operational attributes of a subsystem. After the subsystem description is created, it can be specialized by commands that add, change, and remove work entries and routing entries in the subsystem description.
- To use this command, you must have:
- read (*READ) and add (*ADD) authority to the library where the subsystem description is to be created.
- all object (*ALLOBJ) and security administration (*SECADM) special authority to specify a value other than *NONE for a system library list entry.
- use (*USE) authority to all auxiliary storage pool (ASP) device descriptions in the ASP group to specify an ASP group name.
- Only a user with all object (*ALLOBJ) special authority is allowed to specify an ASP group name when the ASP device description does not exist.
|SBSD||Subsystem description||Qualified object name||Required, Positional 1|
|Qualifier 1: Subsystem description||Name|
|Qualifier 2: Library||Name, *CURLIB|
|POOLS||Storage pools||Values (up to 10 repetitions): Element list||Required, Positional 2|
|Element 1: Pool identifier||1-10|
|Element 2: Storage size||Integer, *BASE, *NOSTG, *INTERACT, *SPOOL, *SHRPOOL1, *SHRPOOL2, *SHRPOOL3, *SHRPOOL4, *SHRPOOL5, *SHRPOOL6, *SHRPOOL7, *SHRPOOL8, *SHRPOOL9, *SHRPOOL10, *SHRPOOL11, *SHRPOOL12, *SHRPOOL13, *SHRPOOL14, *SHRPOOL15, *SHRPOOL16, *SHRPOOL17, *SHRPOOL18, *SHRPOOL19, *SHRPOOL20, *SHRPOOL21, *SHRPOOL22, *SHRPOOL23, *SHRPOOL24, *SHRPOOL25, *SHRPOOL26, *SHRPOOL27, *SHRPOOL28, *SHRPOOL29, *SHRPOOL30, *SHRPOOL31, *SHRPOOL32, *SHRPOOL33, *SHRPOOL34, *SHRPOOL35, *SHRPOOL36, *SHRPOOL37, *SHRPOOL38, *SHRPOOL39, *SHRPOOL40, *SHRPOOL41, *SHRPOOL42, *SHRPOOL43, *SHRPOOL44, *SHRPOOL45, *SHRPOOL46, *SHRPOOL47, *SHRPOOL48, *SHRPOOL49, *SHRPOOL50, *SHRPOOL51, *SHRPOOL52, *SHRPOOL53, *SHRPOOL54, *SHRPOOL55, *SHRPOOL56, *SHRPOOL57, *SHRPOOL58, *SHRPOOL59, *SHRPOOL60|
|Element 3: Activity level||Integer|
|Element 4: Size unit of measure||*KB, *MB|
|MAXJOBS||Maximum jobs||0-32000, *NOMAX||Optional, Positional 3|
|TEXT||Text 'description'||Character value, *BLANK||Optional|
|SGNDSPF||Sign-on display file||Single values: *QDSIGNON
Other values: Qualified object name
|Qualifier 1: Sign-on display file||Name|
|Qualifier 2: Library||Name, *LIBL, *CURLIB|
|SYSLIBLE||Subsystem library||Name, *NONE||Optional|
|AUT||Authority||Name, *LIBCRTAUT, *CHANGE, *ALL, *USE, *EXCLUDE||Optional|
|ASPGRP||ASP group||Name, *NONE||Optional|
|WLCGRP||Workload group||Name, *NONE||Optional|
Subsystem description (SBSD)
Specifies the name and library of the subsystem description being created. The subsystem description is stored in the specified library.
This is a required parameter.
Qualifier 1: Subsystem description
- Specify the name of the subsystem description being created.
Qualifier 2: Library
- The current library of the thread is used. If no current library exists for the thread, library QGPL is used.
- Specify the library where the subsystem description will be created.
For more information on subsystem descriptions, see the Work Management Guide.
Storage pools (POOLS)
Specifies one or more storage pool definitions that are in this subsystem description. Each definition specifies for one storage pool:
- Pool definition identifier: The identifier inside the subsystem description, of the storage pool definition. The same identifiers (1 through 10) can be used for pool definitions in different subsystem descriptions.
- Size: The size of the storage pool, expressed in kilobyte (1K = 1024 bytes) or megabyte (1M = 1048576 bytes) multiples. This is the amount of main storage that can be used by the pool.
- Activity level: The maximum number of threads that can run at the same time in the pool.
A maximum of 10 storage pool definitions can be specified for the subsystem description being created. Although each subsystem description can have as many as 10, there is an operational limitation on how many active storage pools can be in the system. In the system, no more than 64 storage pools can be active at any time, including the base storage pool and the machine storage pool. (A storage pool for which *NOSTG has been specified is not considered active, and it is not allocated to any subsystem.)
If a subsystem is started for which all of its storage pools cannot be allocated without exceeding the 64-pool system maximum, the pools that can be allocated (up to the limit) are allocated and the remainder are not. Then, for each routing step started by that subsystem that normally is routed into one of the pools that was not allocated, the base pool is used instead.
This is a required parameter.
You can specify 10 values for this parameter.
Element 1: Pool identifier
- Specify the pool identifier of the storage pool definition to be in this subsystem. The attributes of the pool also must be specified by one of the following values. As many as 10 sets of values can be specified here to define as many as 10 storage pools in the subsystem.
Element 2: Storage size
- The specified pool definition is defined to be the base system pool, which can be shared with other subsystems. The minimum size and activity level of the base pool are specified in the system values QBASPOOL and QBASACTLVL.
- No storage and no activity level are assigned to the pool at first. (It is inactive.)
- The specified pool definition is defined to be the shared pool used for interactive work. The size and activity level of the shared pool are specified using the Change Shared Storage Pool (CHGSHRPOOL) command.
- The specified pool definition is defined to be the shared pool used for spooled writers. The size and activity level of the shared pool are specified using the CHGSHRPOOL command.
- The specified pool definition is defined to be a general-purpose shared pool. There are sixty general-purpose shared pools, identified by special values *SHRPOOL1 to *SHRPOOL60. The size and activity level of a shared pool are specified using the CHGSHRPOOL command.
- Specify the storage size of the specified storage pool. A value of at least 256 kilobytes must be specified. The size is specified in kilobytes or megabytes by using element 4: Size unit of measure.
Element 3: Activity level
- Specify the maximum number of threads that can run at the same time in the pool.
Element 4: Size unit of measure
- The specified storage size of the pool is in kilobytes units.
- The specified storage size of the pool is in megabytes units.
Maximum jobs (MAXJOBS)
Specifies the maximum number of jobs that can be active at the same time in the subsystem controlled by this subsystem description. The maximum applies to all jobs that are started and are waiting or running, except for jobs on the job queue or jobs that have finished running.
- There is no maximum number of jobs in this subsystem.
- Specify the maximum number of jobs allowed in this subsystem.
Text 'description' (TEXT)
Specifies the text that briefly describes the object.
- No text is specified.
- Specify no more than 50 characters of text, enclosed in apostrophes.
Sign-on display file (SGNDSPF)
Specifies the name and library of the sign-on display file that is used when showing sign-on displays at work stations allocated to the subsystem. If the specified sign-on display file does not exist when the subsystem description is created or changed, you must specify a library qualifier because the qualified sign-on display file name is kept by the system. The sign-on display file must contain a record format named SIGNON.
Note: The sign-on display file can be changed when the subsystem is active. However, the new sign-on display file is not used until the next time the subsystem is started.
Note: If the user invoking this command has use (*USE) authority to the display file and execute (*EXECUTE) authority to its library, format checks of the display file can be made. This helps predict that the display will work correctly when the subsystem is started. Otherwise, those format checks will not be performed.
- The sign-on display file value QDSIGNON in QSYS is used when showing sign-on displays at work stations that are allocated to the subsystem.
Qualifier 1: Sign-on display file
- Specify the name of the sign-on display file that is used.
Qualifier 2: Library
- All libraries in the thread's library list are searched until a match is found.
- The current library for the thread is used to locate the object. If no library is specified as the current library for the thread, the QGPL library is used.
- Specify the library where the sign-on display file is located.
Subsystem library (SYSLIBLE)
Specifies a library that is entered ahead of other libraries in the system portion of the library list. This parameter allows you to use a secondary language library.
- The secondary language library should not be specified in the QSYSLIBL or QUSRLIBL system values. QSYSLIBL must contain fewer than 15 libraries to allow the secondary language library to be added to the system portion of the library list.
- You must have *ALLOBJ and *SECADM special authority to specify a value other than *NONE for a system library list entry.
- The system library list is not changed.
- Specify the name of the library being added to the system library list.
Specifies the authority you are giving to users who do not have specific authority for the object, who are not on an authorization list, and whose group profile or supplemental group profiles do not have specific authority for the object.
- The authority to the object is the same as the value specified on the Create authority (CRTAUT) parameter of the library in which the object is being created. If the value specified on the CRTAUT parameter is changed, the new value will not affect any existing objects.
- The user can perform all operations on the object except those limited to the owner or controlled by object existence (*OBJEXIST) and object management (*OBJMGT) authorities. The user can change and perform basic functions on the object. *CHANGE authority provides object operational (*OBJOPR) authority and all data authority. If the object is an authorization list, the user cannot add, change, or remove users.
- The user can perform all operations except those limited to the owner or controlled by authorization list management (*AUTLMGT) authority. The user can control the object's existence, specify the security for the object, change the object, and perform basic functions on the object. The user also can change ownership of the object.
- The user can perform basic operations on the object, such as displaying its contents. The user cannot change the object. *USE authority provides object operational authority, read authority, and execute authority.
- The user cannot access the object.
- Specify the name of an authorization list to be used for authority to the object. Users included in the authorization list are granted authority to the object as specified in the list. The authorization list must exist when the object is created.
ASP group (ASPGRP)
Specifies the name of an auxiliary storage pool (ASP) group to be included in the library name space of the subsystem monitor job. The ASP group name is the name of the primary ASP device within the ASP group.
When the subsystem monitor job creates a user job, the job description is found using the library name space of the subsystem monitor job. Job queues, the sign-on display file, and the subsystem library are found in the library name space of the subsystem monitor job.
When the subsystem monitor job is doing work on behalf of a user job, the subsystem uses the library name space of the user job. The program and class are found in the library name space of the user job. For these objects, the ASPGRP parameter in the subsystem description has no effect.
When a subsystem monitor job uses an ASP group, the jobs in that subsystem should use the same ASP group. Use the Initial ASP group (INLASPGRP) parameter for the job description so that the ASP group is set during job creation and can be used to find other objects during job creation. Consistency between the subsystem monitor job and the user job is particularly important for prestart job entries because there are times the subsystem must find the program in order to determine which job description to use.
- The library name space of the subsystem monitor job for the controlling subsystem cannot include an ASPGRP. If a value other than *NONE is specified in the subsystem description for the controlling subsystem, it is ignored.
- The library name space of the subsystem monitor job for the QSYSWRK subsystem cannot include an ASPGRP. If a value other than *NONE is specified in the subsystem description for the QSYSWRK subsystem, it is ignored.
- The ASP group must be varied on and have a status of 'Available' before the subsystem is started.
- The subsystem must be ended before the ASP group can be varied off.
- This parameter cannot be changed while the subsystem is active.
- The library name space of the subsystem monitor job will not include an ASP group.
- Specify the name of the ASP group to be included in the library name space of the subsystem monitor job.
Workload group (WLCGRP)
Specifies the name of a workload group to be used for jobs in the subsystem.
- This parameter can be changed while the subsystem is active. Any changes you make take effect for new jobs that are started. The workload group of active jobs within the subsystem is not changed.
- The controlling subsystem does not use a workload group for jobs in the controlling subsystem. If a value other than *NONE is specified in the subsystem description for the controlling subsystem, it is ignored.
- A workload group will not be used for jobs in the subsystem.
- Specify the name of the workload group to be used for jobs in the subsystem.
Example 1: Creating a Description With a Signon Display File
CRTSBSD SBSD(BAKER) POOLS((1 *BASE) (2 2000 4)) SGNDSPF(*LIBL/NEWSGNON) TEXT('Subsystem for running Baker Department jobs')
This command creates a subsystem description named BAKER and stores it in the current library. If there is no current library, then it is stored in the general purpose library (QGPL). Storage pool definition 1 specifies that pool 1 is to share the base system pool; the definition of storage pool 2 is to have 2000K of storage and an activity level of 4. There is no limit in this subsystem description on the number of jobs that can be active at the same time. The activity levels in the subsystem may, however, be controlled by MAXACT parameters specified in work station entries, job queue entries, and routing entries that are in the subsystem description. The sign-on display file is NEWSGNON and is used when showing sign-on displays at work stations allocated to the BAKER subsystem. The user's library list is searched for the NEWSGNON display file.
Example 2: Creating a Description that Contains Three Storage Pool Definitions
CRTSBSD SBSD(MEDLIB/MEDICAL) POOLS((1 1500 2) (2 *BASE) (3 *NOSTG)) MAXJOBS(5) TEXT('Medical files inquiry and update')
This command creates a subsystem description named MEDICAL and stores it in the MEDLIB library. The subsystem description contains three storage pool definitions: storage pool 1 is defined to have 1500K of storage and an activity level of 2, pool 2 is to share the base system pool, and pool 3 is defined first to be inactive when the other pools are active--it has no storage and no activity level. Up to five jobs can be active at the same time in this subsystem. A text description briefly describes the subsystem.
- Subsystem description &1 not created.